Source: http://www.google.com/patents/US20050044376?dq=6,163,776
Timestamp: 2017-08-22 10:33:30
Document Index: 574911562

Matched Legal Cases: ['application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'art 120']

Patent US20050044376 - Disseminating additional data used for controlling access - Google Patents
Issuing and disseminating a data about a credential includes having an entity issue authenticated data indicating that the credential has been revoked, causing the authenticated data to be stored in a first card of a first user, utilizing the first card for transferring the authenticated data to a first...http://www.google.com/patents/US20050044376?utm_source=gb-gplus-sharePatent US20050044376 - Disseminating additional data used for controlling access
Publication number US20050044376 A1
Application number US 10/893,165
Also published as US8015597
Publication number 10893165, 893165, US 2005/0044376 A1, US 2005/044376 A1, US 20050044376 A1, US 20050044376A1, US 2005044376 A1, US 2005044376A1, US-A1-20050044376, US-A1-2005044376, US2005/0044376A1, US2005/044376A1, US20050044376 A1, US20050044376A1, US2005044376 A1, US2005044376A1
Patent Citations (37), Referenced by (23), Classifications (7), Legal Events (6)
US 20050044376 A1
1. A method for issuing and disseminating a data about a credential, comprising:
(a) having an entity issue authenticated data indicating that the credential has been revoked;
(d) having the first door store information about the authenticated data; and
(e) having the first door rely on information about the authenticated data to deny access to the credential.
2. A method according to claim 1, wherein the authenticated data is authenticated by a digital signature and the first door verifies the digital signature.
3. A method according to claim 2, wherein the digital signature is a public-key digital signature.
4. A method according to claim 3, wherein the public key for the digital signature is associated with the credential.
5. A method according to claim 2, wherein the digital signature is a private-key digital signature.
6. A method according to claim 1, wherein the credential and the first card both belong to the first user.
7. A method according to claim 1, wherein the credential is stored in a second card different from the first card, and wherein the first door relies on information about the authenticated data by retrieving such information from storage.
8. A method according to claim 1, wherein the credential belongs to a second user different from the first user.
9. A method according to claim 1, wherein the authenticated data is first stored in at least one other card different from the first card and wherein the authenticated data is transferred from the at least one other card to the first card.
10. A method according to claim 9, wherein the authenticated data is transferred from the at least one other card to the first card by first being transferred to at least one other door different from the first door.
11. A method according to claim 1, wherein the entity causes the authenticated data to be stored in the first card by first causing the authenticated data to be stored on a responder and then having the first card obtain the authenticated data from the responder.
12. A method according to claim 11, wherein the responder is unprotected.
13. A method according to claim 1, wherein the first door receives information about the authenticated data from the first card by the authenticated data first being transferred to at least one other card different from the first card.
14. A method according to claim 13, wherein the at least one other card receives information about the authenticated data from the first card by the authenticated data first being transferred to at least one other door different from the first door.
15. A method according to claim 1, wherein the first door is totally disconnected.
16. A method according to claim 1, wherein the first door is intermittently connected.
17. A method for a first door to receive an authenticated data about a credential of a first user, comprising
(a) receiving the authenticated data from a first card belonging to a second user different than the first user;
(b) storing information about the authenticated data;
(c) receiving the credential; and
(d) relying on the stored information about the authenticated data to deny access to the credential.
18. A method according to claim 17, wherein the authenticated data is authenticated by a digital signature and the first door verifies the digital signature.
19. A method according to claim 18, wherein the digital signature is a public-key digital signature.
20. A method according to claim 19, wherein the public key for the digital signature is associated with the credential.
21. A method according to claim 18, wherein the digital signature is a private-key digital signature.
22. A method according to claim 17, wherein the authenticated data is stored in the first card by being first stored in at least one other card and then transferred from the at least one other card to the first card.
23. A method according to claim 22, wherein the authenticated data is transferred from the at least one other card to the first card by first being transferred to at least one door different from the first door.
24. A method according to claim 17, wherein the authenticated data is stored in the first card by first being stored on a responder and then obtained by the first card from the responder.
25. A method according to claim 24, wherein the responder is unprotected.
26. A method according to claim 17, wherein the first door receives information about the authenticated data from the first card by the authenticated data first being transferred to at least one other card different from the first card.
27. A method according to claim 26, wherein the at least one other card receives information about the authenticated data from the first card by the authenticated data first being transferred to at least one other door different from the first door.
28. A method according to claim 17, wherein the first door is totally disconnected.
29. A method according to claim 17, wherein the first door is intermittently connected.
30. A method for assisting in an immediate revocation of access, comprising:
(a) receiving authenticated data about a credential;
(b) storing information about the authenticated data on a first card; and
(c) causing a first door to receive information about the authenticated data.
31. A method according to claim 30, wherein the authenticated data is authenticated by a digital signature.
32. A method according to claim 31, wherein the digital signature is a public-key digital signature.
33. A method according to claim 32, wherein the public key for the digital signature is associated with the credential.
34. A method according to claim 31, wherein the digital signature is a private-key digital signature.
35. A method according to claim 30, wherein the credential and the card both belong to a first user.
36. A method according to claim 35, wherein the first card becomes unusable for access if the first card fails to receive a prespecified type of signal in a prespecified amount of time.
37. A method according to claim 30, wherein the credential belongs to an other user different from the first user.
38. A method according to claim 30, wherein the authenticated data is received by the first card by being first stored in at least one other card different from the first card and then transferred from the at least one other card to the first card.
39. A method according to claim 38, wherein the authenticated data is transferred from the at least one other card to the first card by first being transferred to at least one other door different from the first door.
40. A method according to claim 30, wherein the first card obtains the authenticated data from a responder.
41. A method according to claim 40, wherein the responder is unprotected.
42. A method according to claim 30, wherein the first card causes the first door to receive information about the authenticated data by first transferring the authenticated data to at least one other card different from the first card.
43. A method according to claim 42, wherein the first card causes the at least one other card to receive information about the authenticated data by first transferring the authenticated data to at least one other door different from the first door.
44. A method according to claim 30, wherein the first door is totally disconnected.
45. A method according to claim 30, wherein the first door is intermittently connected.
46. A method according to claim 30, wherein the first card eventually removes the stored information about the authenticated data from storage.
47. A method according to claim 46, wherein the credential has an expiration date, and first card removes the stored information about the authenticated data from storage after the credential expires.
48. A method according to claim 47, wherein the expiration date of the credential is inferred from information specified within the credential.
This application claims priority to U.S. provisional patent application No. 60/488,645 filed on Jul. 18, 2003, which is incorporated by reference herein, and claims priority to U.S. provisional patent application No. 60/505,640 filed on Sep. 24, 2003, which is incorporated by reference herein, and is a continuation-in-part of U.S. patent application Ser. No. 10/876,275 filed on Jun. 24, 2004 (pending) which claims priority to U.S. provisional patent application No. 60/482,179 filed on Jun. 24, 2003, and which is a continuation-in-part of U.S. patent application Ser. No. 09/915,180 filed on Jul. 25, 2001 (pending), which is a continuation of U.S. patent application Ser. No. 09/483,125 filed Jan. 14, 2000 (now U.S. Pat. No. 6,292,893), which is a continuation of U.S. patent application Ser. No. 09/356,745 filed Jul. 19, 1999 (abandoned), which is a continuation of U.S. patent application Ser. No. 08/823,354 filed Mar. 24, 1997 (now U.S. Pat. No. 5,960,083), which is a continuation of U.S. patent application Ser. No. 08/559,533 filed Nov. 16, 1995 (now U.S. Pat. No. 5,666,416) which claims priority to U.S. provisional patent application No. 60/006,038 filed on Oct. 24, 1995, and is a continuation-in-part of U.S. patent application Ser. No. 10/409,638, filed on Apr. 8, 2003 (pending) which claims priority to U.S. provisional patent application No. 60/370,867, filed Apr. 8, 2002, U.S. provisional patent application No. 60/372,951, filed Apr. 16, 2002, U.S. provisional patent application No. 60/373,218, filed Apr. 17, 2002, U.S. provisional patent application No. 60/374,861, filed Apr. 23, 2002, U.S. provisional patent application No. 60/420,795, filed Oct. 23, 2002, U.S. provisional patent application No. 60/421,197, filed Oct. 25, 2002, U.S. provisional patent application No. 60/421,756, filed Oct. 28, 2002, U.S. provisional patent application No. 60/422,416, filed Oct. 30, 2002, U.S. provisional patent application No. 60/427,504, filed Nov. 19, 2002, U.S. provisional patent application No. 60/443,407, filed Jan. 29, 2003, and U.S. provisional patent application No. 60/446,149, filed Feb. 10, 2003; the teachings of all of which are incorporated herein by reference. And which is a continuation-in-part of U.S. patent application Ser. No. 10/103,541, filed Mar. 20, 2002 (pending), the teachings of which are incorporated herein by reference, which itself is a continuation-in-part of U.S. patent application Ser. No. 09/915,180, filed Jul. 25, 2001 (pending), and which is a continuation of U.S. patent application Ser. No. 09/483,125, filed Jan. 14, 2000, (now U.S. Pat. No. 6,292,893), which is a continuation of U.S. patent application Ser. No. 09/356,745, filed Jul. 19, 1999, (abandoned), which is a continuation of U.S. patent application Ser. No. 08/823,354, filed Mar. 24, 1997, (now U.S. Pat. No. 5,960,083), which is a continuation of U.S. patent application Ser. No. 08/559,533, filed Nov. 16, 1995, (now U.S. Pat. No. 5,666,416), which is based on U.S. provisional patent application No. 60/006,038, filed Oct. 24, 1995. U.S. patent application Ser. No. 10/103,541 is also a continuation-in-part of U.S. patent application Ser. No. 08/992,897, filed Dec. 18, 1997, (now U.S. Pat. No. 6,487,658), which is based on U.S. provisional patent application No. 60/033,415, filed Dec. 18, 1996, and which is a continuation-in-part of U.S. patent application Ser. No. 08/715,712, filed Sep. 19, 1996 (abandoned), which is based on U.S. provisional patent application No. 60/004,796, filed Oct. 2, 1995. U.S. patent application Ser. No. 08/992,897 is also a continuation-in-part of U.S. patent application Ser. No. 08/729,619, filed Oct. 11, 1996, (now U.S. Pat. No. 6,097,811), which is based on U.S. provisional application No. 60/006,143, filed Nov. 2, 1995. U.S. patent application Ser. No. 08/992,897 is also a continuation-in-part of U.S. patent application Ser. No. 08/804,868, filed Feb. 24, 1997 (abandoned), which is a continuation of U.S. patent application Ser. No. 08/741,601, filed Nov. 1, 1996 (abandoned), which is based on U.S. provisional patent application No. 60/006,143, filed Nov. 2, 1995. U.S. patent application Ser. No. 08/992,897, is also a continuation-in-part of U.S. patent application Ser. No. 08/872,900, filed Jun. 11, 1997 (abandoned), which is a continuation of U.S. patent application Ser. No. 08/746,007, filed Nov. 5, 1996 (now U.S. Pat. No. 5,793,868), which is based on U.S. provisional patent application No. 60/025,128, filed Aug. 29, 1996. U.S. patent application Ser. No. 08/992,897 is also based on U.S. provisional patent application No. 60/035,119, filed Feb. 3, 1997, and is also a continuation-in-part of U.S. patent application Ser. No. 08/906,464, filed Aug. 5, 1997 (abandoned), which is a continuation-in-part of U.S. patent application Ser. No. 08/763,536, filed Dec. 9, 1996 (now U.S. Pat. No. 5,717,758), which is based on U.S. provisional patent application No. 60/024,786, filed Sep. 10, 1996, and is a continuation-in-part of U.S. patent application Ser. No. 08/636,854, filed Apr. 23, 1996, (now U.S. Pat. No. 5,604,804), and is also based on U.S. provisional patent application No. 60/025,128, filed Aug. 29, 1996. U.S. patent application Ser. No. 08/992,897 is also a continuation-in-part of U.S. patent application Ser. No. 08/756,720, filed Nov. 26, 1996 (abandoned), which is based on U.S. provisional patent application No. 60/025,128, filed Aug. 29, 1996, and is a continuation-in-part of U.S. patent application Ser. No. 08/715,712, filed Sep. 19, 1996 (abandoned), and is also a continuation-in-part of U.S. patent application Ser. No. 08/559,533, filed Nov. 16, 1995, (now U.S. Pat. No. 5,666,416). U.S. patent application Ser. No. 08/992,897 is also a continuation-in-part of U.S. patent application Ser. No. 08/752,223, filed Nov. 19, 1996 (now U.S. Pat. No. 5,717,757), which is based on U.S. provisional patent application No. 60/025,128, filed Aug. 29, 1996, and is also a continuation-in-part of U.S. patent application Ser. No. 08/804,869, filed Feb. 24, 1997 (abandoned), which is a continuation of U.S. patent application Ser. No. 08/741,601, filed Nov. 1, 1996 (abandoned), which is based on U.S. provisional patent application No. 60/006,143, filed Nov. 2, 1995. U.S. patent application Ser. No. 08/992,897, is also a continuation-in-part of U.S. patent application Ser. No. 08/823,354, filed Mar. 24, 1997 (now U.S. Pat. No. 5,960,083), which is a continuation of U.S. patent application Ser. No. 08/559,533, filed Nov. 16, 1995 (now U.S. Pat. No. 5,666,416), which is based on U.S. provisional application No. 60/006,038, filed Oct. 24, 1995. U.S. patent application Ser. No. 10/103,541 is also based on U.S. provisional patent application No. 60/277,244, filed Mar. 20, 2001, and U.S. provisional patent application No. 60/300,621, filed Jun. 25, 2001, and U.S. provisional patent application No. 60/344,245, filed Dec. 27, 2001. All of the above are incorporated herein by reference. U.S. patent application Ser. No. 10/409,638 is also a continuation-in-part of U.S. patent application Ser. No. 09/915,180, filed Jun. 25, 2001 (pending), the teachings of which are incorporated herein by reference, which itself is a continuation of U.S. patent application Ser. No. 09/483,125, filed Jan. 14, 2000 (now U.S. Pat. No. 6,292,893), which is a continuation of U.S. patent application Ser. No. 09/356,745, filed Jul. 19, 1999, (abandoned), which is a continuation of U.S. patent application Ser. No. 08/823,354, filed Mar. 24, 1997, (now U.S. Pat. No. 5,960,083), which is a continuation of U.S. patent application Ser. No. 08/559,533, filed Nov. 16, 1995, (now U.S. Pat. No. 5,666,416), which is based on U.S. provisional application No. 60/006,038, filed Oct. 24, 1995. The teachings of all of the above are incorporated herein by reference. U.S. patent application Ser. No. 10/409,638 is also a continuation-in-part of U.S. patent application Ser. No. 10/395,017, filed Mar. 21, 2003 (pending), the teachings of which are incorporated herein by reference, which itself is a continuation of U.S. patent application Ser. No. 10/244,695 filed Sep. 16, 2002 (abandoned), which is a continuation of U.S. patent application Ser. No. 08/992,897 filed Dec. 18, 1997, (now U.S. Pat. No. 6,487,658), which is based on U.S. provisional patent application No. 60/033,415, filed Dec. 18, 1996, and which is a continuation-in-part of U.S. patent application Ser. No. 08/715,712, filed Sep. 19, 1996 (abandoned), which is based on U.S. provisional patent application No. 60/004,796, filed on Oct. 2, 1995, and which is also a continuation-in-part of U.S. patent application Ser. No. 08/729,619, filed Oct. 10, 1996 (now U.S. Pat. No. 6,097,811), which is based on U.S. provisional patent application No. 60/006,143, filed Nov. 2, 1995, and which is also a continuation-in-part of U.S. patent application Ser. No. 08/804,868, filed Feb. 24, 1997 (abandoned), which is a continuation of U.S. patent application Ser. No. 08/741,601, filed Nov. 1, 1996 (abandoned), which is based on U.S. provisional patent application No. 60/006,143, filed Nov. 2, 1995, and which is also a continuation-in-part of U.S. patent application Ser. No. 08/872,900, filed Jun. 11, 1997 (abandoned), which is a continuation of U.S. patent application Ser. No. 08/746,007 filed Nov. 5, 1996 (Now U.S. Pat. No. 5,793,868), which is based on U.S. provisional patent application No. 60/025,128, filed Aug. 29, 1996, and which is also based on U.S. provisional patent application No. 60/035,119, filed Feb. 3, 1997, and which is also a continuation-in-part of U.S. patent application Ser. No. 08/906,464, filed Aug. 5, 1997(abandoned), which is a continuation of U.S. patent application Ser. No. 08/763,536 filed Dec. 9, 1996 (now U.S. Pat. No. 5,717,758), which is based on U.S. provisional patent application No. 60/024,786, filed Sep. 10, 1996, and is also a continuation of U.S. patent application Ser. No. 08/636,854, filed Apr. 23, 1997, (now U.S. Pat. No. 5,604,804), and U.S. provisional patent application No. 60/025,128, filed Aug. 29, 1996, and which is also a continuation-in-part of U.S. patent application Ser. No. 08/756,720, filed Nov. 26, 1996(abandoned), which is based on U.S. provisional patent application No. 60/025,128, filed Aug. 29, 1996, and is also a continuation-in-part of U.S. patent application Ser. No. 08/715,712, filed Sep. 19, 1996 (abandoned), and is also a continuation-in-part of U.S. patent application Ser. No. 08/559,533, filed Nov. 16, 1995, (now U.S. Pat. No. 5,666,416), and which is also a continuation-in-part of U.S. patent application Ser. No. 08/752,223, filed Nov. 19, 1996 (now U.S. Pat. No. 5,717,757), which is based on U.S. provisional patent application No. 60/025,128, filed Aug. 29, 1996, and is also a continuation-in-part of U.S. patent application Ser. No. 08/804,869, filed Feb. 24, 1997 (abandoned), which is a continuation of U.S. patent application Ser. No. 08/741,601, filed Nov. 1, 1996 (abandoned), which is based on U.S. provisional patent application No. 60/006,143, filed Nov. 2, 1995, and which is also a continuation-in-part of U.S. patent application Ser. No. 08/823,354 filed Mar. 24, 1997 (now U.S. Pat. No. 5,960,083) which is a continuation of U.S. patent application Ser. No. 08/559,533, filed Nov. 16, 1995 (Now U.S. Pat. No. 5,666,416), which is based on U.S. provisional patent application No. 60/006,038, filed Oct. 24, 1995. The teachings of all of the above are incorporated herein by reference.
In addition, an unauthorized user in possession of legitimate proofs P1−PN may not generate a new proof PN+1. This is advantageous in a number of instances. For example, a terminated employee may not himself generate new proofs to provide unauthorized access to his corporate laptop after termination even though he is still in possession of all of the previous legitimate proofs he used for the laptop while he was still employed by the corporation.
Processing begins at a first step 122 where a random value, RV, is generated. Following the step 132 is a step 134 where the index variable, I, is incremented. Following the step 134, control transfers back to the test step 128, discussed above. If it is determined at the test step 128 that I is greater than IEND, then control transfers from the test step 128 to a step 136 where a final value, FV, is set equal to Y(I−1). Note that one is subtracted from I because I was incremented beyond IEND. Following the step 136 is a step 138 where the administration entity 28 (or some other entity that generates the proofs and the credentials) digitally signs the final value, the current date, and other information that is used in connection with the proofs. In an embodiment herein, the other information may be used to identify the particular electronic device (e.g., laptop), the particular user, or any other information that binds the credentials and the proof to a particular electronic device and/or user and/or some other property. Optionally, the date and/or the FV may be combined with the other information. For example, it is possible to use an OCSP-like signed message that simply says, “device #123456 is valid on Jan. 1, 2004” or have a bit in a miniCRL that corresponds to a specific device being on or off. In those case, the credential on the device may authenticate the device (i.e., determine that the device really is device #123456, etc.). OCSP and miniCRL's are know in the art. Following the step 138, processing is complete.
Digital signatures may provide an effective form of Internet authentication. Unlike traditional passwords and PINs, digital signatures may provide authentication that may be universally verifiable and non-repudiable. Digital signatures may be produced via a signing key, SK, and verified via a matching verification key, PK. A user U keeps his own SK secret (so that only U can sign on U's behalf). Fortunately, key PK does not “betray” the matching key SK, that is, knowledge of PK does not give an enemy any practical advantage in computing SK. Therefore, a user U could make his own PK as public as possible (so that every one can verify U's signatures). For this reason PK is preferably called the public key. Note that the term “user” may signify a user, an entity, a device, or a collection of users. devices and/or entities.
Alphanumeric strings called certificates provide that a given key PK is a public key of a given user U. An entity, often called certification authority (CA), generates and issues a certificate to a user. Certificates expire after a specified amount of time, typically one year in the case of public CAs. In essence, a digital certificate C consists of a CA's digital signature securely binding together several quantities: SN, a serial number unique to the certificate, PK, the public key of the user, U, the user's name, D1, the issue date, D2, the expiration date, and additional information (including no information), Al. In symbols, C=SIGCA(SN,PK,U,D1,D2,AI).
A PROOF of E may consist of a digital signature of E indicating in an authenticated manner that a given credential is valid for a given interval of time, for instance: SIGE(ID, Day, Valid, AI), where ID is information identifying the credential (e.g., the credential's serial number), Day is an indication of the given time interval (without loss of generality intended, a given day), Valid is an indication that the credential is deemed valid (this indication can be omitted if E never signs a similar data string unless the credential is deemed valid), and AI indicates any additional information (including no information) deemed useful. In some instances, the signature of E may be a public-key signature. (But it could also be a private-key signature, that is, one that may be produced and verified via a single, secret key, known both to the signer and the verifier.) If the credential consists of a digital certificate, one sub-embodiment may consist of a short-lived certificate, that is, a digital signature that re-issues the credential for the desired time interval (e.g., a digital certificate specifying the same public key, the same user U and some other basic information as before, but specifying the start date and the expiration date so to identify the desired—-without loss of generality intended—day). For instance, letting, without loss of generality intended, a short-lived certificate last for a day, in such sub-embodiment a PROOF may take the form SIGE(PK, U, D1,D2, AI), where start-date D1 indicates the beginning of a given day D and end-date D2 the corresponding end of day D, or where D1=D2=D; or more simply using a single date-information field to identify the day in question, SIGE(PK, U, Day, AI). If E coincides with the original certification authority, a short-lived-certificate PROOF may take the form SIGCA(PK, U, D1,D2, AI) or SIGCA(PK, U, Day, AI).
Being authenticated, a user may not manufacture his own PROOF of the day (i.e., the PROOF of the day of his own credential), nor can he change his PROOF of yesterday into his own PROOF of today, nor the PROOF of another user for today into his own for today. Because PROOFs are essentially unforgeable and inalterable, these PROOFs need not be protected. Thus, entity E may make the PROOFs available with negligible cost. For instance, E may post all the PROOFs of a given day on the Internet (e.g., make the PROOFs available via Akamai servers or the equivalent), or send the PROOFs to responders/servers that may be easily reached by the users. For instance, to a server located at the entrance of an airport (or office building) where many of the doors to be correctly accessed are located. This way, an employee coming to work may easily pick up his own PROOF (e.g., by inserting his own card into a card reader coupled with the server) and—-say—store the PROOF onto his own card, together with his own credential. This way, when the user presents his card to a door that his credential authorizes to access, the door can not only verify the credential but also receives and verifies a PROOF of current authorization, without needing to be connected at all! The door verifies the PROOF (e.g., the digital signature of E via E's pubic key that it may store since installation) and that the time interval specified by the PROOF is proper (e.g., via its own local clock). If all is fine, the door grants access else, the door denies access. In essence, the door may be disconnected and yet its PROOF verification may be both relatively easy (because the door may receive the PROOF by the most available party: the very user demanding access) and relatively secure (though the door receives the PROOF from arguably the most suspicious party: the very user demanding access). In fact, a user demanding access may typically be in physical proximity of the door, and thus can provide the PROOF very easily, without using any connection to a distant site, and thus operate independent of the door's connectivity. At the same time, the user demanding access may be the least trustworthy source of information at that crucial time. Nonetheless, because the user may not manufacture or alter a PROOF of his own current validity in any way, the door may be sure that a properly verified PROOF must be produced by E, and E would have not produced the PROOF if E knew the user to be not authorized for the given time interval. When a user stops being authorized, E will stop issuing PROOFs of authorization for the user, and thus the user can no longer enter even disconnected doors, because the user will lack the PROOF that a door needs to verify in order to grant access. Thus, by utilizing the user demanding access to prove proper and current authorization, the system described herein dispenses with inconveniences associated with other systems, i.e., the need to dispatch a crew to re-program disconnected doors.
This approach also enables one to manage disconnected-door access by “role” (or by “privilege”). That is, rather than having a credential specify the door(s) that its user is authorized to enter, and then issue —e.g., daily—a PROOF of current validity of a credential (or rather than issuing a PROOF specifying that a given credential authorizes his user to enter some door(s) on a given time interval), disconnected doors may be programmed (e.g., at installation time) to grant access only to users having a given role. For instance, a cockpit door in an airplane may be programmed to grant access only to PILOTS and INSPECTORS. The credentials may be issued to employees primarily to vouch for their identity (which does not change), while each PROOF that E—e.g., daily—issues for a given credential may also specify (e.g., in the Al field) the role(s) of its corresponding user on that day. For instance, PROOF=SIGE(ID, Day, PILOT, AI) proves on day Day the user corresponding to credential identified by ID is a pilot. This way, employees may “migrate” from one role to the next without having their credential reissued, and without any need to specify within a user credential or in its corresponding daily PROOF which doors the user may access that day. Note that the number of such doors may be huge. Thus, specifying within a user credential all the doors a user may be authorized to access may be cumbersome. Moreover, if new doors are added (e.g., because new airplanes are bought) then the pilot's credential may have to be reissued, which is cumbersome too, to specify the additional doors.
4. a digital certificate for a public key PK (e.g., such a credential can be stored in a user's card and the right user/card may use the corresponding secret key SK to authenticate/identify itself to the door—e.g., via a challenge response protocol). For instance, if PK is a signature public key, the door may ask to have signed a given message and the right user—the only one who knows the corresponding secret signing key SK-may provide the correct requested signature; if PK is a public encryption key, the door may request to a have a given challenge ciphertext decrypted, which can be done by the right user, who knows the corresponding secret decryption key SK;
In another example, the user's credentials include a digital certificate with hash-chain validity proofs similar to those generated in connection with the flow chart 120 of FIG. 5. This example utilizes public-key signatures and a one-way hash function H (implementing a special type of digital signature). A central authority has a key pair: a public key PK (known to the doors) and a secret key SK that is not generally known. For a user U, the authority generates a random secret value X0 and a computes values X1=H(X0), X2=H(X1), . . . , X365=H(X364). Because H is a one-way hash function, each value of X cannot be computed from the next value of X. The authority issues to U a digital certificate Cert, signed using SK and containing the value X365, valid for one year. Then, when U reports to work on day i, the authority causes the user's card to receive the day's validation value Xj, where j=365-i. When U attempts to access a door, the card communicates the validation value Xj and certificate Cert containing X365 to the door. The door verifies the validity of the Cert with public key PK of the authority and also checks that H applied i times to Xj produces X365. Note that the “one year” and 365 may be replaced with any other time period.
It is useful if HRA's are authenticated so that an entity to which an HRA is presented may be relatively certain that the HRA is genuine. Letting ID be an identifier for the revoked credentials/proofs C (in particular, ID may coincide with C itself), then SIG(ID, “REVOKED”, AI) may be an HRA, where “REVOKED” stands for any way of signaling that C has been revoked (“REVOKED” may possibly be the empty string if the fact that the credentials/proofs are revoked could be inferred by other means —such as a system-wide convention that such signed messages are not sent except in case of revocation), and AI stands for any additional information (possibly date information-such as the time when the credentials/proofs have been revoked and/or the time when the HRA was produced- or no information). The digital signature SIG may be, in particular, a public-key digital signature, a secret-key digital signature, or a message authentication code. It is also possible to issue an authenticated HRA by properly encrypting the information. For example, an authenticated HRA may take the form ENC(ID, “REVOKED”, AI).
Removable HRAs may significantly reduce the storage required at the door. Using the above example of 10,000,000 users and 10% annual revocation rate, then, if HRAs expire and are removed, on average, in one day, only 2,740 (instead of 1,000,000). HRAs may need to be stored. This reduced storage requirement is a great potential advantage of removable HRAs.
This may be enhanced by having a door reached by Card 1 communicate the learned HRA2 to another card, Card 3, that subsequently accesses it or communicates with the door. This is useful because Card 3 may reach doors that Card 1 will not reach or will reach later than Card 3. This process may continue by having these additionally reached doors communicate to other cards, etc. Moreover, it is possible that some doors, even though not fully connected to a central database, may have connections to each other. Such doors thus may exchange available HRAs similarly. If cards have communication capability with each other —e.g., when in proximity—they may also exchange information about HRAs that they store.
4. When U′ attempts to access a door D, his card transmits his credential/proof along with A to D 5. D verifies the authenticity of A and, if verification succeeds, stores A;
SEOUENCE 3 (From “Authority” to Another Door to a User's Card to Door):
3. When U attempts to access a door D, his card transmits A along with C to D 4. D verifies the authenticity of A and, if verification succeeds, stores A and denies access to U;
Log entries may also contain operational data or information on any unusual events, such as current or voltage fluctuations, sensor failures, switch positions, etc. One way to produce an indisputable log includes having the door digitally sign event information by means of a secret key (SK). The resulting indisputable log may be represented by SIG(event, AI), where Al stands for any additional information. The signature method used by door D may be public-key or private-key.
In a first example, the correlation information CI of the log entries may include sequentially numbering the log entries. The corresponding correlation-detection scheme may consist of noticing the presence of a gap in the numbering sequence. But to obtain a deletion-detectable log system, a proper binding between CI and the log entries is found, which may not be easy to do, even if secure digital signatures are used for the authentication component of the system. For instance, having the i-th log entry consist of (i, SIG(event, AI)), is not secure, because an enemy could, after deleting a log entry modify the numbering of subsequent entries so as to hide the gap. In particular, after deleting log entry number 100, the adversary may decrease by one the numbers of log entries 101, 102, etc. The enemy may so hide his deletions because, even though the integrity of the event information is protected by a digital signature, the numbering itself may not be. Moreover, even digitally signing also the numbers may not work. For instance, assume that the i-th log entry consists of (SIG(i),SIG(event, AI)). Then an enemy could: (1) observe and remember SIG(100), (2) delete entry number 100, (3) substitute SIG(100) in place of SIG(101) in original entry 101, while remembering SIG(10 l), and so on, so as to hide the deletion completely.
Neither of the above two methods produces the desired secure binding of CI and log entries. Indeed, by securely binding (1) the numbering information together with (2) the event being numbered, we mean that an enemy may not manufacture the binding of some number j together with event information about the i-th event Ei, when j is different than i, even if provided with (a) a secure binding of number i and Ei and (b) a secure binding of number j and Ej. For instance, the i-th log entry may consist of SIG(i,Ei, AI). This way, the deletion of the i-th log entry will be detected given later log entries. This is so because a later log entry may carry with it a number greater than i, which cannot be removed, modified or switched with another log-entry numbering information by the adversary, because it is securely bound to the log entry. For instance, assume the adversary deletes the log entry number 100: SIG(100,E100,AI). As long as the adversary cannot delete all subsequent log entries (which would require continual access to the database), to hide his deletion, the adversary would need to create another log entry with the same number 100. However, this may be difficult because (a) the adversary cannot generate a brand new 100th log entry SIG(100, E′, AI′) since he does not have the door's secret signing key; (b) the adversary cannot modify an existing log entry without invalidating the digital signature (e.g., cannot change SIG(101, El01, AI100) into SIG(100, E101, AI101) even if he remembers the deleted entry SIG(100, E100, AI100)); (c) the adversary cannot extract a signature of a portion of the log entry indicating the number 100 and bind it with a digital signature to another log entry.
Deletion-detectable logs may also be achieved by securely binding with the log entry correlation information other than sequential numbering information. For instance, one can include in log entry i some identifying information from a prior log entry, for example, entry i−1. Such information may be a collision-resistant hash of entry i−1 (or a portion of log entry i−1): symbolically, log entry i can be represented as SIG(H(log entry i-i), Ei, AI). Then if the adversary attempts to remove log entry i-l, such removal would be detected when log entry i is received, because the hash of the previously received log entry, H(log entry i-2), would not match H(log entry i−1) (because of the collision-resistance of H), whereas H(log entry i−1), because it is securely bound to log entry-i, could not be modified by the adversary without destroying the validity of a digital signature. Here by log entry i we may also mean a subset of its information, such as Ei.
Other correlation information may also be used. For instance, each log entry i may have securely bound with it two values (e.g., random values or nonces) xi and xi+1: symbolically, e.g., SIG(xi, Xi+1, E,AI). Then two consecutive log entries may always share one x value: for instance, entries i and i+1 will share xi+1. However, if a log entry is deleted, this will no longer hold (because the adversary cannot modify signed log entries without detection unless it knows the secret key for the signature). For instance, if entry number 100 is deleted, the database will contain SIG(x99, x100, E99, AI) and SIG(x101, x102, E101, AI) and one can observe that they are not sharing a common x value. Such correlation information may take other forms: in fact, a log entry may be correlated with multiple other log entries. This can be accomplished, in particular, by use of polynomials to generate correlation information (e.g., two or more log entries may each contain the result of evaluating the same polynomial at different inputs). Such correlation information may also make use of a hash chain: for instance, starting with a value yl, let y2=H(y1), y3=H(y2), . . . , etc., and then securely bind yi with Ei: e.g., the i-th log entry may be symbolically represented as SIG(yi, Ei, AI). Then consecutive log entries i and i+1 may have correlation values yi and yi+1 such that yi+1=H(yi). If the adversary deletes a log entry, however, this may no longer hold and thus deletion can be detected. For instance, if entry 100 is deleted, the database will contain SIG(y99g, E99, AI) and SIG(y101, E101, AI) (which, as before cannot be modified by the adversary without distorting the digital signatures). Then the deletion can be detected because H(y101) will not match y99. Use of multiple hash chains, perhaps used non-consecutive entries and in both directions, may also provide such correlation information.
In another embodiment, each log entry may contain an indication of some or all of the previous or even subsesquent events, thus making logs not only deletion-detectable, but also reconstructible in case of deletions. Reconstructible log systems may be built by using (1) an authentication scheme (e.g., a digital signature scheme), (2) a reconstruction-information-generating scheme and (3) a reconstructing scheme as follows. Given one log event E (part of a sequence of—possibly past and/or future—events), the reconstruction-information-generating scheme is used to generate reconstruction information RI, which is then securely bound to other log entries by means of the authentication scheme. The reconstruction-information-generating scheme ensures that, even if the log entry corresponding to event i is lost, other log entries contain sufficient information about E so as to allow reconstruction of E from RI present in other log entries. For instance, the i+lSt entry may contain information about all or some of the previous i events, generated by the reconstruction-information-generating scheme. Therefore, if an enemy succeeded somehow in erasing the j-th log entry from the database, information about the j-th event Ej will show up in one or more subsequent entries, making it possible to reconstruct information Ej even in the absence of the j-th log entry, using the reconstructing scheme. Thus, it would not be enough for an enemy to have temporary access to the database: he would have to monitor the database “all the time” and delete multiple log entries to prevent information about the j-th event from being revealed. Choosing which events to include into a log entry can be done by the reconstruction-information-generating scheme in a randomized fashion, so as to make it harder for an enemy to predict when information about a given event will show up in successive logs. Preferably, the system for reconstructible logs may also be deletion-detectable and indisputable.
In particular, a card C1 may collect events logs for events unrelated to C1, such as access by another card C2, or a malfunction of a door D. Moreover, event logs for one door D1 may be stored (perhaps temporarily) on another door D2 (perhaps carried there by a card C 1). Then, when another card C2 communicated with D2, it may receive some of these log entries and later communicate them to another door or to a central location. This broad dissemination may ensure that event logs reach the central point faster. (Moreover, it is possible that some doors, even though not fully connected to a central database, may have connections to each other. Such doors thus may exchange available event logs similarly. If cards have communication capability with each other —e.g., when in proximity—they may also exchange information about event logs that they store.) In such collecting process, indisputable logs are advantageous, because they do not need to be carried over secured channels, as they cannot be falsified. Therefore, they do not rely on the security of cards or connections between cards and doors. Deletion-detectable logs provide additional advantages by ensuring that, if some log entries are not collected (perhaps because some cards never reach a connected door), this fact may be detected. Reconstructible logs may additionally allow for reconstruction of log entries in case some log entries do not reach a central database (again, perhaps because some cards never reach a connected door).
3. Later, U presents his card C for access to another (connected) door D′.
D′, in addition to verifying credentials and granting access if appropriate, receives E from C. D′ may or may not verify the authenticity of E.
US20070219950 * Feb 21, 2007 Sep 20, 2007 Crawford C S L Systems and methods for controlling access within a system of networked and non-networked processor-based systems
Cooperative Classification H04L9/3268, H04L2209/80, H04L9/3247
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LIBIN, PHIL;MICALI, SILVIO;ENGBERG, DAVID;AND OTHERS;REEL/FRAME:015906/0654;SIGNING DATES FROM 20040810 TO 20040830
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LIBIN, PHIL;MICALI, SILVIO;ENGBERG, DAVID;AND OTHERS;SIGNING DATES FROM 20040810 TO 20040830;REEL/FRAME:015906/0654