Source: http://www.google.com/patents/US20080211624?dq=6,274,924
Timestamp: 2015-10-05 00:28:40
Document Index: 587805551

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']

Patent US20080211624 - Physical access control - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA system and method are disclosed for controlling physical access through a digital certificate validation process that works with standard certificate formats and that enables a certifying authority (CA) to prove the validity status of each certificate C at any time interval (e.g., every day, hour,...http://www.google.com/patents/US20080211624?utm_source=gb-gplus-sharePatent US20080211624 - Physical access controlAdvanced Patent SearchPublication numberUS20080211624 A1Publication typeApplicationApplication numberUS 12/069,227Publication dateSep 4, 2008Filing dateFeb 8, 2008Priority dateOct 2, 1995Also published asUS8171524Publication number069227, 12069227, US 2008/0211624 A1, US 2008/211624 A1, US 20080211624 A1, US 20080211624A1, US 2008211624 A1, US 2008211624A1, US-A1-20080211624, US-A1-2008211624, US2008/0211624A1, US2008/211624A1, US20080211624 A1, US20080211624A1, US2008211624 A1, US2008211624A1InventorsSilvio Micali, David Engberg, Phil Libin, Leo Reyzin, Alex SinelnikovOriginal AssigneeSilvio Micali, David Engberg, Phil Libin, Leo Reyzin, Alex SinelnikovExport CitationBiBTeX, EndNote, RefManPatent Citations (1), Referenced by (14), Classifications (12), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetPhysical access control
US 20080211624 A1Abstract
7. In an access control system with an entity A, at least one disconnected door, and users possessing user cards to access doors, a method for a disconnected door D to indicate to A that a given user U tried to access D, comprising the steps of:
having D receive from U information IU indicating that U wishes to access door D; having D at least temporarily store IU; and for at least one subsequent user V, having D cause V to at least temporarily store IU in V's card for presentation to entity A. 8. The method of claim 7, wherein V presents IU to A by transferring IU to a database accessible by A or transmitting information to A.
9. The method of claim 7, wherein IU includes at least one of: (i) information provided to U for accessing door D and (ii) information generated by U to access D.
10. The method of claim 7, wherein IU includes a digital signature generated by U.
11. The method of claim 7, wherein IU includes a digital signature of U.
12-21. (canceled) Description
The present application is a continuation in part of U.S. patent application Ser. No. 10/103,541, filed Mar. 20, 2002, entitled SCALABLE CERTIFICATE VALIDATION AND SIMPLIFIED MANAGEMENT, (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, entitled CERTIFICATE REVOCATION SYSTEM, (pending), and which is a continuation of U.S. patent application Ser. No. 09/483,125, filed Jan. 14, 2000, (pending), which is a continuation of U.S. patent application Ser. No. 09/356,745, filed Jul. 19, 1999, (pending), 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, which is based on U.S. Provisional 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, entitled CERTIFICATE REVOCATION SYSTEM, (abandoned), which is based on U.S. Provisional Application No. 60/004,796, filed Oct. 2, 1995, entitled CERTIFICATE REVOCATION SYSTEM. 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, entitled TREE-BASED CERTIFICATE REVOCATION SYSTEM, (now U.S. Pat. No. 6,097,811), which is based on U.S. Provisional Application No. 60/006,143, filed Nov. 2, 1995, entitled TREE BASED CERTIFICATE REVOCATION SYSTEM. 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, entitled TREE-BASED CERTIFICATE REVOCATION SYSTEM, (abandoned), which is a continuation of U.S. patent application Ser. No. 08/741,601, filed Nov. 1, 1996, entitled TREE-BASED CERTIFICATE REVOCATION SYSTEM, (abandoned), which is based on U.S. Provisional Application No. 60/006,143, filed Nov. 2, 1995, entitled TREE-BASED CERTIFICATE REVOCATION SYSTEM. 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, entitled WITNESS BASED CERTIFICATE REVOCATION SYSTEM, (abandoned), which is a continuation of U.S. patent application Ser. No. 08/746,007, filed Nov. 5, 1996, entitled CERTIFICATE REVOCATION SYSTEM, (now U.S. Pat. No. 5,793,868), which is based on U.S. Provisional Application No. 60/025,128, filed Aug. 29, 1996, entitled CERTIFICATE REVOCATION SYSTEM. U.S. patent application Ser. No. 08/992,897 is also based on U.S. Provisional Application No. 60/035,119, filed Feb. 3, 1997, entitled CERTIFICATE REVOCATION SYSTEM, and is also a continuation in part of U.S. patent application Ser. No. 08/906,464, filed Aug. 5, 1997, entitled WITNESS BASED CERTIFICATE REVOCATION SYSTEM, (abandoned), which is a continuation in part of U.S. patent application Ser. No. 08/763,536, filed Dec. 9, 1996, entitled WITNESS BASED CERTIFICATE REVOCATION SYSTEM, (now U.S. Pat. No. 5,717,758), which is based on U.S. Provisional Application No. 60/024,786, filed Sep. 10, 1996, entitled WITNESS BASED CERTIFICATE REVOCATION SYSTEM, and is based on 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 Application No. 60/025,128, filed, Aug. 29, 1996, entitled CERTIFICATE REVOCATION SYSTEM. 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, entitled SEGMENTED CERTIFICATE REVOCATION LISTS, (abandoned), which is based on U.S. Provisional Application No. 60/025,128, filed Aug. 29, 1996, entitled CERTIFICATE REVOCATION SYSTEM, and is also based on U.S. patent Ser. No. 08/715,712, filed Sep. 19, 1996, entitled CERTIFICATE REVOCATION SYSTEM, (abandoned), and is also based on 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, entitled CERTIFICATE ISSUE LISTS, (now U.S. Pat. No. 5,717,757), which is based on U.S. Provisional Application No. 60/025,128, filed Aug. 29, 1996, entitled CERTIFICATE REVOCATION SYSTEM, and is also a continuation in part of U.S. patent application Ser. No. 08/804,869, filed Feb. 24, 1997, entitled TREE-BASED CERTIFICATE REVOCATION SYSTEM, (abandoned), which is a continuation of U.S. patent application Ser. No. 08/741,601, filed Nov. 1, 1996, entitled TREE-BASED CERTIFICATE REVOCATION SYSTEM, (abandoned), which is based on U.S. Provisional Application No. 60/006,143, filed Nov. 2, 1995, entitled TREE-BASED CERTIFICATE REVOCATION SYSTEM. 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, entitled CERTIFICATE REVOCATION SYSTEM, (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, entitled CERTIFICATE REVOCATION SYSTEM, (now U.S. Pat. No. 5,666,416), which is based on U.S. Provisional Application No. 60/006,038, filed Oct. 24, 1995, entitled ENHANCED CERTIFICATE REVOCATION SYSTEM. U.S. patent application Ser. No. 10/103,541 is also based on U.S. Provisional Application No. 60/277,244, filed Mar. 20, 2001, and U.S. Provisional Application No. 60/300,621, filed Jun. 25, 2001, and U.S. Provisional Application No. 60/344,245, filed Dec. 27, 2001. All of the above are incorporated herein by reference.
Alphanumeric strings called certificates enable digital signatures by guaranteeing that a given key PK is indeed the public key of a user U. A Certifying Authority (CA) generates and issues a certificate to a user, once assured of the user's identity. Thus the certificate proves to everyone that the CA has verified the holder's identity, and possibly other attributes. (E.g., if a company acts as its own CA and issues certificates for its own employees, a certificate may prove the extent to which its holder is authorized to bind his/her employer.) 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 data. In symbols, C=SIGCA(SN,PK,U,D1,D2, . . . ).
The authority decides which users can go through which doors in a given time interval. (For instance, without loss of generality intended, we may assume that each interval of time of interest consists of a day.) To this end, A may use her own private database DB1, storing all permissions, that is who is authorized to go through which door at a given (or any foreseeable future day). Presumably, A protects this database, else an enemy could alter the permissions stored there to his advantage. However, A computes from DB a public database PDB as follows. For each user U having permission to go through door D at day d, A computes a digital signature SUDd indicating that indeed this is the case. For instance A computes SUDd=SIGA(U,D,d). Notice that only A can compute these digital signatures, while all having A's public key PKA can verify them. These signatures are unforgeable by someone not knowing A's secret key SKA, nor can they modified in any manner (e.g., by transforming U′ permission into permission for an unauthorized user U′) without making them invalid. Thus. A can timely compute and send (eg, at the beginning od a day) these signatures to a repository PR without much worry. A repository is a place that can be accessed by users. For instance a server located at the employee entrance of a large facility (such as an employee entrance at an airport). Because A's signatures are unforgeable, the connection between A and PR needs not be secure. It suffices that A succeeds to transfers its signatures to PR within a reasonable time.
When employee U arrives at work on day d at the facility (eg, through a point of entrance in which PR is located) he can connect his card with PR (eg, he inserts his card in a card reader/writer connected with or remotely communicating with PR). By doing this he picks up on his card SIGUDd, the digital signature indicating that that day he is authorized to go through door D. This requires that the point of entrance, rather than hundreds of doors, be connected with A, and this connection needs not be secure either. In reality, D needs not to indicate a single door. For instance, it can indicate a set of doors (eg, baggage handling doors) and the signature of A indicates that U can go through each door indicated by D. Alternatively, a plurality of doors, D1, . . . , Dn, can be indicated one by one, and the fact that U can go that day through each one of hem can be indicated by more than one signature of A. For example SIGUD1d . . . SIGUDnd. In which case, all such signatures are transferred to U's card.
Moreover, the authorizing digital signatures may be tied to the long-term certificate of the cardholder. For example, the card may contain a long-term certificate valid for each year, and the authority component may issue daily signatures verifying that the certificate is still valid on the current day.
The authority component may generate authorizations automatically, without any requests. For example, every night the authority component may generate authorizing signatures for the employees that will be authorized for the next day. This approach enables the authorization component to be non-interactive and thus easier to build securely.
In addition, the authority component may use separate, possibly insecure devices, for dissemination of authorizing signatures to cards and/or doors. This will enable the authorization component to focus on only one task: generation of authorizations. It will remove the need for the cumbersome direct connections between the secure authorization component and the (possibly less secure) doors and cards. Specifically, dissemination of authorizations may occur as follows: (1) The authority component generates authorizations; (2) The authority component transmits authorization, over possibly insecure connections, to dissemination databases. These databases may be at multiple locations, and need not be secured. For example, in a company with five employee entrances, there may be one dissemination database at each entrance; (3) The dissemination databases transmit authorizations to cards and/or doors, either upon request (“pull”) or automatically (“push”).
The property enabling the above methods is that the authorization itself is unforgettable—it can be produced only by the authority component. Therefore, once produced, it can be disseminated over possibly untrusted lines and devices without any risks to security. This removes the need for any other party or device to interact with the authority component, thus resulting in a much cheaper solution than any requiring secure connections.
In fact, no connections among any of the components in this system need to be secured. (Only the authority component itself has to be secured, so that inappropriate authorizations are not produced.) Thus, a fault-tolerant, distributed access authorization infrastructure can be much more easily built. Moreover, as stated above, it is possible to build such an infrastructure without any connections needed for the doors.
It should be appreciated that the inventive access control system can be combined with the tenant CAs of Section 3. For instance, several authorities (e.g., in an office building, the parking authority, the cleaning authority, or the multiple companies sharing occupancy in the building) may utilize the same certificate while retaining individual control over the ability of its holder to access the various protected areas.
The system could operate as follows. A user U (or his card) has a certificate CERT that contains a validation field—say D365—for each door D of interest. Permission that U can go through door D at day j can be proved by releasing the unforgettable 20-byte value X365−j. Door D can check that permission by hashing it j times and checking whether the result coincides with the validity field D365 of CERT. In case A must deal with a plurality of doors (eg, 1000 doors, then CERT may contain 1000 different validity fields, each corresponding to different doors, and each door Dj checks its computations relative to the jth validity field. In this case, even if permission for a user to go through each door is proved separately, each user has at most 1000 proofs on a given day. Thus at most 20K bytes need to be loaded on his card on a given day.
Notice that because cards are general cards here, the card can be a contactless card, the card reader may be a receiver, and the card need not be inserted into the reader but transmit to it. Notice that such a “wireless” card-reader interaction is still quite local, and very different from a card-authority/database interaction when A or the database is far away.
It should be appreciated that the inventive access control system can be combined with the tenant CAs as described. For instance, several authorities (e.g., in an office building, the parking authority, the cleaning authority, or the multiple companies sharing occupancy in the building) may utilize the same certificate while retaining individual control over the ability of its holder to access the various protected areas.
Logging Proofs of Access with Disconnected Doors
While disconnected (from authorities and databases) and yet very secure, low-cost and convenient smart doors are preferable to connected smart doors, the latter provide for the ability of logging access through a given door. For instance, it can be important to know who went through a given door on a given day. Connected doors may easily do this by sending proper “access information to a distant database or authority. But disconnected doors cannot quite do that. Access information can be gather by sending proper personal to collect such information from door to door. This may not be always convenient to do. However, the following system provides a very viable alternative.
When a user U passes (or attempts to pass) through a door D at a time t, the door may produce a proper string LOGUDt, and locally store it (at least temporarily). To ensure that this info reaches a proper database, the door may use the cards used to enter through it. For instance, D may write LOGUDt (or cause LOGUDt to be written) on the card(s) of other user(s) U′ (possibly including U himself). Whenever U′ makes a connection with PR (eg the next day of work) or with any other wired or well connected device, then PR or said device transmits LOGUDt to the proper database. This way a proper database will eventually receive and then store more permanently and in an easily auditable way LOGUDt. Possibly the database will receive redundant copies of LOGUDt, but it is easy for it to clear any unwanted redundancy and keep clean copies only.
A preferable LOGUDt, is one that consists or includes a digital signature of U himself. This way, U cannot easily deny that he went through a given door at a given time and claim that the access information of the door is a fabrication. Indeed, only he has the secret signing key for producing LOGUDt. For instance LOGUDt e consist of SIGU(D,t), indicating that U went through door D at time t. This is very easy to accomplish if user U's card carries the secret signing key SKU matching a public key PKU. Preferably the card also carries a digital certificate for PKU, and thus LOGUD may include not only SIGU(D,t), but also U's certificate. Preferably too, the user card may produce SIGU(D,t) according to the time t shown on its own clock, and the door may let U in only after he provides such a good access proof SIGU(D,t) (possibly in addition to other authorization proofs such as those discussed above), and provided that the time certified by U is sufficiently close to the current time t′ as measured by the door clock. Still the user may claim that he entered at time t door D, but that this door was somewhere else altogether, and thus that SIGU(D,t) does not at all prove that he went through—say—the second door of the third floor of a given building: someone went through the trouble to transfer to said location the door reader etc. To prevent this claim too, or to protect the user against such fraud, the user card (device) may incorporate a GPS mechanism, and SIGU(D,t) may actually include the local position lp as measured by the card. In which case, the user may tend to the door the proof of access SIGU(D,t, ps), and the door may accept it and let the user in only if not only the time looks correct but also the local position. Rather than computing ps inside the card/device, the user may use some one or more components, which he trusts, and which can compute his position from information they receive from him (and possibly their own positions).
As seen in the FIG. 1, the CA sends to a Directory individual certificate revocation status information CRSi about each of its issued, but not-yet expired certificates C1 . . . Ck. The Directory sends CRSi to a requestin