CN101268649B - Controlling access using additional data - Google Patents

Abstract

Determining access includes determining whether a particular credential/attestation indicates that access is allowed; determining whether additional data is associated with the credential/attestation, wherein the additional data is independent of the credential/attestation; and if the particular credential/credential indicates that access has been granted and additional data is associated with the particular credential/credential, determining whether to deny access based on information provided by the additional data. The credentials/proofs may be integral or separate parts. It may be that the first management entity generates credentials and the other management entities generate proofs. The first management entity may also generate proof or not. The credential may correspond to a digital certificate that includes a final value that is the result of applying the one-way function to the first proof.

Description

Use additional data to control access

Related application cross-references

This application claims priority to U.S. Provisional Patent Application 60/488,645, filed July 18, 2003, which is hereby incorporated by reference, and also claims priority to U.S. Provisional Patent Application 60/505,640, filed September 24, 2003 , which is incorporated herein by reference and is a continuation of U.S. Patent Application 10/876,275 (pending), filed June 24, 2004, which claims priority over U.S. Provisional Patent Application 60/482,179, filed June 24, 2003 and itself a continuation-in-part of U.S. Patent Application 09/915,180, filed July 25, 2001, which is a continuation of U.S. Patent Application 09/483,125, filed January 14, 2000 (now U.S. Patent 6,292,893) , which is a continuation of U.S. Patent Application 09/356,745, filed July 19, 1999 (abandoned), which is a continuation of U.S. Patent Application 08/823,354, filed March 24, 1997 (now U.S. Patent 5,960,083), It is a continuation of U.S. Patent Application 08/559,533, filed November 16, 1995 (now U.S. Patent 5,666,416), which claimed priority to U.S. Provisional Application 60/006,038, filed October 24, 1995, and was filed in 2003 Continuation (pending) of U.S. Patent Application 10/409,638, filed April 8, which claims priority to: U.S. Provisional Application 60/370,867, filed April 8, 2002; U.S. Provisional Application 60/372,951 filed April 17, 2002; U.S. Provisional Application 60/374,861 filed April 23, 2002; U.S. Provisional Application 60 filed October 23, 2002 /420,795; U.S. Provisional Application 60/421,197, filed October 25, 2002; U.S. Provisional Application 60/421,756, filed October 28, 2002; U.S. Provisional Application 60/422,416, filed October 30, 2002; U.S. Provisional Application 60/427,504, filed November 19; U.S. Provisional Application 60/443,407, filed January 29, 2003; and U.S. Provisional Application 60/446,149, filed February 10, 2003; teachings of all of these applications Both are incorporated herein by reference. and is a continuation-in-part of U.S. Patent Application 10/103,541 (pending) filed March 20, 2002, the teachings of which are incorporated herein by reference, itself U.S. Patent Application 09 filed July 25, 2001 /915,180 (pending), and which is a continuation-in-part of U.S. Patent Application 09/483,125, filed January 14, 2000 (now U.S. Patent 6,292,893), which is a U.S. Patent filed on July 19, 1999 Continuation (Abandoned) of Application 09/356,745, which was a continuation of U.S. Patent Application 08/823,354, filed March 24, 1997 (now U.S. Patent 5,960,083), which was a U.S. Patent Application, filed November 16, 1995 Continuation of 08/559,533 (now US Patent 5,666,416), which is based on US Provisional Application 60/006,038 filed October 24,1995. U.S. Patent Application 10/103,541 is also a continuation of U.S. Patent Application 08/992,897, filed December 18, 1997 (now U.S. Patent 6,487,658), which is based on U.S. Provisional Application 60/033,415, filed December 18, 1996, and which is a continuation-in-part of US Patent Application 08/715,712 (abandoned), filed September 19, 1996, which is based on a continuation of US Provisional Application 60/004,796, filed October 2, 1995. US Patent Application 08/992,897 is also a continuation-in-part of US Patent Application 08/729,619, filed October 11, 1996 (now US Patent 6,097,811), which is based on US Provisional Application 60/006,143, filed November 2, 1995. US patent application 08/992,897 is also a continuation-in-part of US patent application 08/804,868 (abandoned), filed February 24, 1997, which is a continuation of US patent application 08/741,601 (abandoned), filed November 1, 1996 A continuation of US Provisional Application 60/006,143 filed November 2, 1995. U.S. Patent Application 08/992,897 is also a continuation-in-part of U.S. Patent Application 08/872,900 (abandoned), filed June 11, 1997, which is U.S. Patent Application 08/746,007, filed November 5, 1996 (now U.S. Continuation of Patent 5,793,868) based on US Provisional Application 60/025,128 filed August 29, 1996. U.S. Patent Application 08/992,897 is also based on U.S. Provisional Application 60/035,119, filed February 3, 1997, which is also a continuation of U.S. Patent Application 08/906,464 (abandoned), filed August 5, 1997, which was filed in part in 1996 Continuation of U.S. Patent Application 08/763,536 (now U.S. Patent 5,717,758), filed December 9, 1996, based on U.S. Provisional Application 60/024,786, filed September 10, 1996, and based on U.S. Patent Application 08/636,854 (now U.S. Patent 5,604,804), and also based on U.S. Provisional Application 60/025,128 filed August 29, 1996. U.S. Patent Application 08/992,897 is also a continuation in part of U.S. Patent Application 08/756,720 (abandoned), filed November 26, 1996, based on U.S. Provisional Application 60/025,128, filed August 29, 1996, and based on US Patent Application 08/715,712, filed September 19, 1996 (abandoned), and also based on US Patent Application 08/559,533, filed November 16, 1995 (now US Patent 5,666,416). U.S. Patent Application 08/992,897 is also a continuation in part of U.S. Patent Application 08/752,223 filed November 19, 1996 (now U.S. Patent 5,717,757), which is based on U.S. Provisional Application 60 filed August 29, 1996 /025,128, and is also a continuation in part of U.S. Patent Application Serial No. 08/804,869 (abandoned), filed February 24, 1997, which is a continuation of U.S. Patent Application Serial No. 08/741,601 (abandoned), filed November 1, 1996, It is based on US Provisional Application 60/006,143 filed November 2,1995. US Patent Application 08/992,897 is also a continuation in part of US Patent Application 08/823,354, filed March 24, 1997 (now US Patent 5,960,083), which is a continuation of US Patent Application 08/559,533, filed November 16, 1995 ( Now a continuation of US Patent 5,666,416) based on US Provisional Application 60/006,038 filed October 24,1995. U.S. Patent Application 10/103,541 is also based on U.S. Provisional Application 60/277,244, filed March 20, 2001, and U.S. Provisional Application 60/300,621, filed June 25, 2001, and U.S. Provisional Application Apply 60/344,245. All of the above applications are hereby incorporated by reference. U.S. Patent Application 10/409,638 is also a continuation of U.S. Patent Application 09/915,180 (pending), filed June 25, 2001, the teachings of which are incorporated herein by reference, itself U.S. Patent Application No. 1, January 2000. Continuation of Patent Application 09/483,125 (now U.S. Patent 6,292,893), which was a continuation of U.S. Patent Application 09/356,745 (abandoned), filed July 19, 1999, which was a U.S. Patent filed March 24, 1997 Continuation of Application 08/823,354 (now U.S. Patent 5,960,083), which is a continuation of U.S. Patent Application 08/559,533 (now U.S. Patent 5,666,416), filed November 16, 1995, based on US provisional application 60/006,038. The teachings of all of the above applications are incorporated herein by reference. U.S. Patent Application 10/409,638 is also a continuation of U.S. Patent Application 10/395,017 (pending), filed March 21, 2003, the teachings of which are incorporated herein by reference, itself filed September 16, 2002 Continuation of U.S. Patent Application 10/244,695 (Abandoned), which is a continuation of U.S. Patent Application 08/992,897, filed December 18, 1997 (now U.S. Patent 6,487,658), based on U.S. Patent Application No. 1, filed December 18, 1996 Provisional Patent Application 60/033,415, a continuation in part of U.S. Patent Application 08/715,712 (abandoned), filed September 19, 1996, based on U.S. Patent Application 60/004,796, filed October 2, 1995, and Also a continuation in part of U.S. Patent Application 08/729,619 filed October 10, 1996 (now U.S. Patent 6,097,811), which is based on U.S. Patent Application 60/006,143 filed November 2, 1995, also in part 1997 Continuation of U.S. Patent Application Serial No. 08/804,868 (Abandoned), filed February 24, which is a continuation of U.S. Patent Application Serial No. 08/741,601 (Abandoned), filed November 1, 1996, based on November 2, 1995 filed U.S. Patent Application 60/006,143, which is also a continuation in part of U.S. Patent Application No. 08/872,900 (abandoned), filed June 11, 1997, which was U.S. Patent Application No. 08/746,007, filed November 5, 1996 (now U.S. Patent 5,793,868), which is based on U.S. Patent Application 60/025,128, filed August 29, 1996, which is also based on U.S. Patent Application 60/035,119, filed February 3, 1997, and is also based in part on Continuation of U.S. Patent Application Serial No. 08/906,464 (abandoned), filed August 5, 1997, which is a continuation of U.S. Patent Application Serial No. 08/763,536, filed December 9, 1996 (now U.S. Patent No. 5,717,758), based on 1996 U.S. Patent Application 60/024,786, filed September 10, 1997, and also based on U.S. Patent Application 08/636,854, filed April 23, 1997 (now U.S. Patent 5,604,804) and U.S. Patent Application, filed August 29, 1996 60/025,128, and a continuation in part of U.S. Patent Application 08/756,720, filed November 26, 1996 (abandoned), based on U.S. Patent Application 60/025,128, filed August 29, 1996, and also based on 1996 U.S. Patent Application 08/715,712 (abandoned) filed September 19, 1995 and also based on U.S. Patent Application filed November 16, 1995 08/559,533 (now U.S. Patent 5,666,416), and in part, a continuation of U.S. Patent Application 08/752,223 (now U.S. Patent 5,717,757), filed November 19, 1996, based on U.S. Patent application 60/025,128, which is also a continuation in part of U.S. patent application 08/804,869 (abandoned), filed February 24, 1997, which is a continuation of U.S. patent application 08/741,601 (abandoned), filed November 1, 1996 A continuation of U.S. Patent Application 60/006,143, filed November 2, 1995, and in part, U.S. Patent Application 08/823,354, filed March 24, 1997 (now U.S. Patent 5,960,083), which is Continuation of US Patent Application Serial No. 08/559,533, filed November 16, 1995 (now US Patent No. 5,666,416), which is based on US Patent Application Serial No. 60/006,038, filed October 24, 1995. The teachings of all of the above applications are hereby incorporated by reference. the

Background of the invention

1. Technical field

This application relates to the field of physical access control, particularly using processor-manipulated locks and associated data. the

2. Background technology

In many situations, such as when visiting airports, military installations, office buildings, etc., it is important to ensure that only authorized individuals have access to protected areas and equipment. Traditional doors and walls can be used to secure sensitive areas, but doors with traditional locks and keys can be cumbersome to manage settings for many users. For example, once an employee is terminated, it is very difficult to recover the physical keys issued to the former employee upon employment. In addition, there is a risk that such keys will be copied multiple times and never handed over. the

Smart gates provide access control. In some cases, smart doors can be equipped with keypads through which users can enter their PIN or password. The keypad may have additional memory and/or base processor in which a list of valid PIN/passwords may be kept. Thus, the gate can check whether the currently entered PIN belongs to the current valid list. If it belongs, the door opens. Otherwise, the door can remain locked. Of course, rather than (only) relying on traditional keys or simple keypads, more modern smart doors work with cards (such as smart cards and magnetic stripe cards) or contactless devices (such as PDAs, mobile phones, etc.). Such cards or devices can be used in addition to or in place of traditional keys or electronic keypads. These magnetic stripe cards, smart cards or contactless devices designed to be carried by the user may have the ability to hold information which may be transmitted to the door. More advanced cards may also have computing and communication capabilities. The corresponding device on the door is able to read the information from the card and possibly participate in an interactive protocol with the card, communicate with the computer, etc. the

One aspect of a door is its connectivity class. A fully connected gate is one that is always connected to some database (or other computer system). For example, the database may contain information about currently valid cards, users, PINs, and the like. In some cases, such connections are secured (for example, by placing wires from the gate to the database within steel pipes) to prevent an adversary from altering the information flowing into the gate. A fully disconnected door, on the other hand, does not communicate with the outside of its immediate immediate vicinity. Between these two extremes, there are also doors with intermittent connectivity (e.g., wirelessly connected "mobile" doors that can only communicate with the outside when within range of a ground station, such as the doors of airplanes or trucks) ). the

Traditional access control mechanisms have many disadvantages. Fully connected doors are very expensive. The cost of connecting a security tube to a remote smart door can far outweigh the cost of the smart door itself. Cryptographically securing wires, while potentially less expensive, has its own costs (eg, the cost of securing and managing keys). Furthermore, a coded system without steel pipes and security guards does not protect against wires being cut, in which case doors that are not permanently connected may be forced to choose between two extreme choices: namely, always remain closed or always open , but neither is desirable. In some cases, fully connected doors are usually not a viable option. (For example, the doors of cargo containers below sea level in the mid-Atlantic are virtually completely disconnected.)

A non-connected smart door may be less expensive than a connected door. However, conventional access to smart doors has its own problems. For example, suppose a disconnected smart door is able to recognize a PIN. The terminated employee is no longer authorized to pass through the door, however, if he still remembers his own PIN, he will have no difficulty opening as a basic smart door. Therefore, the effect of the terminated employee's PIN must be "neutralized", which is difficult with disconnected doors. In fact, such a process can be cumbersome and expensive: an airport facility has hundreds of doors, and the old procedure of dispatching special teams of workers out and removing all of these doors whenever an employee leaves or is terminated is too inappropriate. practical. the

Therefore, it is desirable to provide the level of security associated with fully connected doors without incurring additional costs. As demonstrated, disconnected smart doors and cards alone do not guarantee the security, convenience and low cost of an access control system. the

Contents of the invention

According to the invention, controlling access includes providing access barriers, including a controller that selectively allows access, at least one management entity generates a credential/certificate, wherein if only the value of the credential and expired certificate is given, it cannot be determined as a valid certificate, the control The credential/certificate is received by the controller, the controller determines whether access is currently authorized, and if access is currently authorized, the controller allows access. Credentials/proofs can be one piece or separate parts. It may be that the first management entity generates the credential and the other management entities generate the certificate. The first managing entity may also generate certificates or the first managing entity may not generate certificates. A credential may correspond to a digital certificate that includes a terminal value that is the result of applying a one-way function to the first certificate. Each proof may be the result of applying a one-way function to one of future proofs. A digital certificate may include an identifier for the electronic device. The credential may include a terminal value that is the result of applying the one-way function to the first proof. Each proof may be the result of applying a one-way function to one of future proofs. Credentials may include an identifier for which the user requests access. Credentials/proofs may include digital signatures. Barriers to access can include walls and doors. Controlling access may also include providing a door lock connected to the controller, wherein the controller allowing access includes the controller actuating the door lock to allow the door to open. Controlling access may also include providing a card reader connected to the controller, wherein the controller receives credentials/proof from the card reader. Credentials/proofs may be provided on a smart card presented by the user. Controlling access may also include providing external connections to the controller. External connections can be intermittent. The controller may receive at least some of the credentials/proofs using the external connection, or the controller may receive all the credentials/proofs using the external connection. Controlling access may also include providing a card reader connected to the controller, the controller receiving the remainder of the credential/proof from the card reader. Credentials/proofs may be provided on a smart card presented by the user. Credentials/proofs may include user-entered passwords. Credentials/proofs may include user biometric information. Credentials/proofs may include handwritten signatures. Credentials/proofs may include a secret value provided on a card held by the user. Vouchers/proofs can expire after a predetermined time. the

According to the invention, an entity controlling access of a plurality of users to at least one disconnected door comprises mapping the plurality of users to groups, for each interval d of a series of dates, causing the authority to generate a digital signature SIGUDd indicating that the group Members of the group have access to the gate during time interval d, have at least one member of the group receive SIGUDd to present to the gate during time interval d to pass through the gate, have at least one member of the group present SIGUDd to gate D, and verify The door is opened after (i) SIGUDd is the authority's digital signature indicating that the group member has access to the door for time interval d, and (ii) the current time is within time interval d. At least one member of the group may have a user card and the door may have a card reader connected to an electromechanical lock, at least one member of the group may receive SIGUDd by storing SIGUDd in the user card, and by having the user card read Machine readable and presents SIGUDd to the gate. The authority may cause SIGUDd to be received by at least one member of the group during time interval d by logging SIGUDd in a database accessible by at least one member of the group. SIGUDd may be a public key signature, and the gate may hold the governing body's public key. The gate may also verify identity information of at least one member of the group. The identity information about at least one member of the group may include at least one of: a PIN and answers to complex questions about the door. the

According to the present invention, controlling physical access further includes assigning a real-time credential to a group of users, checking the real-time credential, wherein the real-time credential includes a fixed first part and a second part that is periodically modified, wherein the second part provides proof that the real-time credential is current , verify the validity of the live credential by performing an operation on the first part and comparing the result to the second part; and only allow physical access to members of the group if the live credential is verified as valid. The first part may be digitally signed by the governing body. The governing body may provide the second part. The second part may be provided by an entity other than the governing body. Real-time credentials can be provided on the smart card. Members of the group can obtain the second portion of the real-time credential at the first location. Members of the group may be allowed access to a second location that is different and separate from the first location. At least a portion of the first portion of the real-time credential may represent a one-way hash applied multiple times to a portion of the second portion of the real-time credential. The number of times may correspond to the amount of time that has elapsed since the first portion of the real-time credential was issued. Controlling physical access may also include controlling access through doors. the

According to the present invention, determining access includes determining whether a particular credential/certificate indicates that access is permitted, determining whether additional data is associated with the credential/certificate, wherein the additional data is independent of the credential/certificate, and determining whether a particular credential/certificate indicates access has been permitted and additional data is associated with a specific credential/certificate, it is decided whether to deny access based on the information provided by the additional data. Credentials/proofs can be one piece or separate parts. It may be that the first management entity generates the credential and the other management entities generate the certificate. The first managing entity may also generate certificates or the first managing entity may not generate certificates. A credential may correspond to a digital certificate that includes a terminal value that is the result of applying a one-way function to the first certificate. Each proof may be the result of applying a one-way function to one of future proofs. A digital certificate may include an identifier for the electronic device. The credential may include a terminal value that is the result of applying the one-way function to the first proof. Each proof may be the result of applying a one-way function to one of future proofs. Credentials may include an identifier for which the user requests access. Credentials/proofs may include digital signatures. Access can be to areas enclosed by walls and doors. Determining access may include providing a door lock, wherein the door lock is unlocked based on whether access is denied. Determining access may also include providing a card reader to receive the credential/proof. Credentials/proofs may be provided on a smart card presented by the user. Credentials/proofs may include user-entered passwords. Credentials/proofs may include user biometric information. Credentials/proofs may include handwritten signatures. Credentials/proofs may include a secret value provided on a card held by the user. Vouchers/proofs can expire after a predetermined time. Additional data may be digitally signed. Additional data may be messages tied to credentials/proofs. The message may identify the particular credential/certificate and include an indication of whether the particular credential/certificate has been revoked. Indication can be an empty string. Additional data may include dates. Additional data may be messages containing information about a particular credential/certificate and containing information about one or more other credential/certificates. Determining access may also include saving additional data. The additional data may include an expiration time indicating how long the additional data will be kept. An expiration time may correspond to the expiration of a particular credential/proof. Determining access may also include saving the additional data for a predetermined length of time. Vouchers/Certificates may both expire after a predetermined time. Additional data can be provided using a smart card. A smart card can be presented by a user attempting to access a zone. Access to areas may be restricted using walls and at least one door. Additional data is available for a user other than the user attempting to access. Determining access may also include providing a communication link and using the communication link to transmit additional data. A communication link may be provided by the smart card with additional data. A smart card may require periodic communication with the communication link to remain valid. A smart card can be provided with additional data by another smart card. Additional data can be selectively provided to a small group of smart cards. Determining access may also include providing priority to additional data. Additional data may be selectively provided to a small group of smart cards according to the priority given to the additional data. Additional data can be randomly provided to a small group of smart cards. the

According to the invention, issuing and disseminating data about the voucher includes causing the entity to issue authenticated data indicating that the voucher has been cancelled, so that the authenticated data is stored in the first card of the first user, using the first card to transfer the authenticated The data is transmitted to the first gate, causing the first gate to store information about the authenticated data, and causing the first gate to deny access credentials relying on the information about the authenticated data. Authenticated data can be authenticated by a digital signature, and the first gate can verify the digital signature. The digital signature may be a public key digital signature. A digitally signed public key can be associated with a certificate. The digital signature may be a private key digital signature. Both the voucher and the first card belong to the first user. The credential may be stored in a second card different from the first card and the first gate may rely on information about the authenticated data by retrieving such information from memory. The credential may belong to a second user different from the first user. The authenticated data may first be stored in at least one other card than the first card, and the authenticated data may be transferred from the at least one other card to the first card. Authenticated data may be transmitted from at least one other card to the first card by first transmitting to at least one other gate different from the first gate. The entity may cause the authenticated data to be stored in the first card by first having the authenticated data stored on the transponder and then causing the first card to obtain the authenticated data from the transponder. The transponder may be unprotected. The first gate may receive information about authenticated data from the first card by causing the authenticated data to be first transmitted to at least one other card than the first card. At least one other card may receive information about authenticated data from the first card by having the authenticated data first transmitted to at least one other door than the first door. The first gate can be completely disconnected or intermittently connected. the

According to the invention, the first gate receives authenticated data on credentials of a first user, the process comprising receiving authenticated data from a first card belonging to a second user different from the first user, saving authenticated data on information, receive credentials, and deny access credentials by virtue of stored information about authenticated data. Authenticated data may be authenticated by a digital signature, and the first gate verifies the digital signature. The digital signature may be a public key digital signature. A digitally signed public key can be associated with a certificate. The digital signature may be a private key digital signature. Authenticated data may be stored in the first card by first being stored in at least one other card and then being transferred from the at least one other card to the first card. Authenticated data can be transmitted from at least one other card to the first card by first transmitting to at least one other door different from the first door. Authenticated data may be stored in the first card by first storing on the transponder and then having the first card obtain it from the transponder. The transponder may be unprotected. The first gate may receive information about authenticated data from the first card by causing the authenticated data to be first transmitted to at least one other card than the first card. At least one other card may receive information about authenticated data from the first card by having the authenticated data first transmitted to at least one other door than the first door. The first gate can be completely disconnected or intermittently connected. the

According to the invention, facilitating immediate revocation of access comprises receiving authenticated data about the credential, storing information about the authenticated data on the first card, and causing the first gate to receive information about the authenticated data. Authenticated data can be authenticated by a digital signature. The digital signature may be a public key digital signature. A digitally signed public key can be associated with a certificate. The digital signature may be a private key digital signature. Both the credential and the card belong to the first user. If the first card fails to receive a pre-specified type of signal within a pre-specified time, the first card will become unavailable for access. The credential may belong to another user than the first user. Authenticated data may be received by the first card by first being stored in at least one other card different from the first card and then being transmitted from the at least one other card to the first card. Authenticated data may be transmitted from at least one other card to the first card by first transmitting to at least one other gate different from the first gate. The first card can obtain authenticated data from the transponder. The transponder may be unprotected. The first card may cause the first gate to receive information about the authenticated data by first transmitting the authenticated data to at least one other card different from the first card. The first card may cause at least one other card to receive information about the authenticated data by first transmitting the authenticated data to at least one other door different from the first door. The first gate can be completely unconnected or intermittently connected. Finally the first card can delete the saved information about the authenticated data from the memory. The voucher may have an expiration date and the first card may delete the saved information about the authenticated data from the memory after the voucher has expired. The expiration date for a voucher can be inferred from the information specified within the voucher. the

According to the invention, recording events related to the visited area includes recording events related to the visited area to provide an event record and authenticating at least one event record to provide an authenticated record. Logging an event may include logging a time of the event. Logging an event may include logging a type of event. An event can be an attempt to access a region. Logging events may include logging the credentials/proofs used in connection with the access zone attempt. Logging the event may include logging a result of the attempt. Logging an event may include logging the presence of data other than credentials/proofs indicating that access should be denied. Logging the event may include logging additional data related to the zone. Authentication records may include digitally signed records. Authenticating at least one event record may include authenticating the event record and authenticating other event records to provide a single authenticated record. A single authenticated record can be saved on the card. Authenticated records can be saved on the card. The card may have another authenticated record kept on it. Another authenticated record may be provided by the card along with the card used to access the zone. Access may be denied if another authenticated record is not verified. The controller may be provided with an access zone, where the controller further authenticates another authenticated record. Another authenticated record can be authenticated using a digital certificate. Logging an event may also include the user presenting the card in an attempt to access the area. Logging events may also include card further authenticating authenticated logging when a user attempts to access a zone. In relation to the access zone, a controller may be provided, wherein the controller and the card cooperate to further authenticate the authenticated record. Recording an event may include providing associated generated data indicating the content of the authenticated record. Associated production data can be tied to authenticated records. Associated production data can be bound to the authenticated record and the resulting binding can be authenticated. The resulting binding can be digitally signed. The associated generated data can be a series of numbers, and a specific one of the numbers can be assigned to the event. Logging events may also include identifying specific numbers and bindings to events. Authentication bindings may include digitally signing bindings. Authentication binding may include one-way hash binding and then digitally signing the result. Related generation data for an event may include information identifying another event. Another event may be a preceding event. Another event may be a future event. Logging an event may also include associating the first and second random values of the event, associating at least one of the first and second random values with another event, and associating at least one of the first and second values with another Event binding. Providing the correlation generated data may include generating the correlation information using a polynomial. Providing the associated generated data may include generating associated information using a hash chain. Related generation data may include information about a number of other events. The associated generated data may include error correction codes. Logging events may also include propagating authenticated records. Propagating the authenticated record may include providing the authenticated record on a card presented by a user attempting to access the area. Areas can be defined by walls and doors. the

According to the invention, at least one management entity controls the access of the electronic equipment, which generates a credential and a plurality of corresponding certificates for the electronic equipment through at least one management entity, wherein if only given

The value of the credential and expired certificate, which cannot be determined to be valid, the electronic device receives the credential, if access is authorized at a specific time, the electronic device receives the certificate corresponding to the specific time, and the electronic device uses the credential to confirm the certificate. At least one managing entity may generate the certificate after generating the credential. A single governing entity can generate credentials and generate certificates. It is also possible that the first management entity generates the credential, and the other management entities generate certificates. The first management entity may or may not generate certificates as well. The credential may be a digital certificate that includes a terminal value that is the result of applying a one-way function to the first certificate. Each proof may be the result of applying a one-way function to one of future proofs. A digital certificate may include an identifier for the electronic device. The credential may include an end value that is the result of applying the one-way function to the first proof. Each proof may be the result of applying a one-way function to one of future proofs. Credentials may include an identifier for the electronic device. An electronic device may be a computer, which only starts up when access is authorized. The electronic device may be a disk drive. At least one management entity controlling access to the electronic device may include providing certification using at least one certification distribution entity independent of the at least one management entity. There may be only one certificate distribution entity or multiple certificate distribution entities. At least one management entity controlling access to the electronic device may include providing credentials using a connection to the electronic device. The connection can be the Internet. At least a portion of the certificate may be locally stored on the electronic device. The at least one management entity controlling access to the electronic device may include, if the certificate corresponding to the time is not available locally, the electronic device requesting the certificate via an external connection. Each proof can be associated with a specific time interval. After a particular time interval associated with a particular certificate has elapsed, the electronic device may receive a new certificate. The time interval can be one day. the

According to the invention, the electronic device controls access thereto by receiving at least one of a plurality of corresponding certificates and a credential for the electronic device, wherein no valid certificate can be determined if only the values of the credential and the expired certificate are given, and At least one of the plurality of proofs is tested using the credential. The credential may be a digital certificate that includes a terminal value that is the result of applying a one-way function to the first certificate. Each proof may be the result of applying a one-way function to one of future proofs. A digital certificate may include an identifier for the electronic device. The credential may include an end value that is the result of applying the one-way function to the first proof. Each proof may be the result of applying a one-way function to one of future proofs. Credentials may include an identifier for the electronic device. The electronic device may be a computer. Controlling access thereto by the electronic device may also include starting the computer only when access is authorized. The electronic device may be a disk drive. Controlling access thereto by the electronic device may include obtaining credentials using a connection to the electronic device. The connection can be the Internet. At least a portion of the certificate may be locally stored on the electronic device. Controlling access thereto by the electronic device may include, if the certificate corresponding to the time is not available locally, the electronic device requesting the certificate via an external connection. Each proof can be associated with a specific time interval. After a particular time interval associated with a particular certificate has elapsed, the electronic device may receive a new certificate. The time interval can be one day. the

According to the invention, controlling access to an electronic device includes providing a credential to the electronic device, and if access is allowed at a specific time, providing a certificate corresponding to a specific time, wherein the value of the certificate and the expired certificate cannot be determined if only the value of the certificate and the expired certificate are given. prove. The credential may be a digital certificate that includes a terminal value that is the result of applying a one-way function to the first certificate. Each proof may be the result of applying a one-way function to one of future proofs. A digital certificate may include an identifier for the electronic device. The credential may include an end value that is the result of applying the one-way function to the first proof. Each proof may be the result of applying a one-way function to one of future proofs. Credentials may include an identifier for the electronic device. The electronic device may be a computer. Controlling access to electronic devices may include computer booting only when access is authorized. The electronic device may be a disk drive. Controlling access to the electronic device may include providing the certificate using at least one certificate distribution entity independent of the at least one management entity. There may be only one certificate allocation entity. There can be multiple attestation allocation entities. Controlling access to the electronic device may include providing proof using a connection to the electronic device. The connection can be the Internet. At least a portion of the certificate may be locally stored on the electronic device. Controlling access to the electronic device may include, if the certificate corresponding to the time is not available locally, the electronic device requesting the certificate via an external connection. Each proof can be associated with a specific time interval. After a particular time interval associated with a particular certificate has elapsed, the electronic device may receive a new certificate. The time interval can be one day. the

Description of drawings

FIG. 1A is a schematic diagram according to an embodiment of the system described herein, which includes a connection, a plurality of electronic devices, a management entity, and a certificate distribution entity. the

FIG. 1B is a schematic diagram according to another embodiment of the system described herein, which includes a connection, a plurality of electronic devices, a management entity, and a certificate distribution entity. the

Fig. 1C is a schematic diagram according to another embodiment of the system described herein, which includes a connection, a plurality of electronic devices, a management entity, and a certificate distribution entity. the

1D is a schematic diagram according to another embodiment of the system described herein, which includes a connection, a plurality of electronic devices, a management entity, and a certificate distribution entity. the

2 is a detailed diagram of an electronic device in accordance with the system described herein. the

3 is a flow diagram of steps in conjunction with an electronic device determining whether to execute a confirmation execution according to the system described herein. the

FIG. 4 is a flow diagram of steps performed in connection with performing validation in accordance with the system described herein. the

Figure 5 is a flowchart of the steps performed in connection with generating a credential according to the system described herein. the

FIG. 6 is a flowchart of the steps performed in connection with checking proofs against credentials, according to the system described herein. the

Fig. 7 is a schematic diagram according to the system described herein, including an area to which physical access is to be restricted. the

Detailed ways

Referring to FIG. 1A , FIG. 20 shows a general connection 22 with a plurality of electronic devices 24 - 26 connected to the connection. Although FIG. 20 shows three electronic devices 24-26, the system described herein may work with any number of electronic devices. Connection 22 may be implemented as a direct electronic data connection, a connection over a telephone line, a LAN, a WAN, the Internet, a virtual private network, or any other mechanism for providing data communication. Electronic devices 24-26 may represent one or more laptop computers, desktop computers (in an office or at an employee's home or other location), PDAs, mobile phones, disk drives, mass storage devices, or any other devices that may be used to limit access to its access to electronic devices. In the embodiment herein, the electronic devices 24-26 represent desktop or laptop computers that may be used by employees of the institution, and the institution wishes to restrict access to the electronic device when the user/employee leaves the institution and/or one of the computers is lost or stolen. Access. Of course, there may be other reasons for restricting access to one or more electronic devices 24-26, and the system described herein may be used with any suitable implementation. the

The management entity 28 sets policies that allow users to access the electronic devices 24-26. For example, the management entity 28 may determine that a particular user U1 no longer has access to any of the electronic devices 24-26, while another user U2 has access to the electronic device 24 but not to the other electronic devices 25,26. The management entity 28 may use any policy for setting user access. the

The management entity 28 provides certificates, which are transmitted via the connection 22 to the electronic devices 24-26. Credentials may be provided to electronic devices 24-26 by other means, which are described in detail below. The electronic device 24-26 receives the assigned certificate and, using internally held credentials (described in detail elsewhere in this specification), determines whether access thereto should be permitted. Optionally, certificate distribution entity 32 may also be connected to connection 22 and management entity 28 . The certificate distribution entity 32 provides certificates to the electronic devices 24-26. In the embodiment herein, the certificate is only valid for one user and one of the electronic devices 24-26, optionally only for a certain date or range of dates. the

Proof can be provided using a mechanism similar to that disclosed in U.S. Patent 5,666,416, which is incorporated herein by reference, wherein each electronic device 24-26 receives as a credential a digital certificate signed by the managing entity 28 (or other authorized entity) , the digital certificate contains a special value representing the value of the one-way function applied N times to the initial value. At each new time interval, the electronic device can be presented with a proof consisting of one of N values obtained by applying a one-way function. In this example, the electronic device 24-26 may confirm that the certificate is legitimate by applying the one-way function multiple times to obtain the particular value provided in the digital certificate. This mechanism, and other possible mechanisms, are described in detail elsewhere in this specification. the

Appropriate credentials and proofs set forth herein may also be provided using one or more of the products provided by CoreStreet, Ltd. of Cambridge, MA, or any other mechanism for generating unique proofs that 1) can only be obtained by Generated by a regulatory authority (no regulatory security violation exists); and 2) cannot be used to generate any other proofs. Thus, the proof is such that, given a legitimate proof P1, an unauthorized user cannot generate another apparently legitimate proof P2 for a different purpose (eg, for a different time interval, different device, etc.). Thus, issued proofs can be stored and distributed in a non-secure manner, which substantially reduces system cost. Of course, it is advantageous to maintain appropriate security for the entity generating the credential and/or certificate, as well as for any unissued (eg future) certificates. the

Furthermore, an unauthorized user possessing a valid proof P1-PN cannot generate a new proof PN+1. This is advantageous in many situations. For example, a terminated employee may not himself generate new certificates to provide certification for his company laptop after termination even if he still has all the previous legal certificates he used for the laptop while employed by the company. Unauthorized access. the

In the embodiments herein, electronic devices 24-26 are computers having firmware and/or operating system software that performs the processes described herein, certified to prevent unauthorized login and/or access thereto. On a boot basis and/or after sufficient time has elapsed, the computer should require appropriate certification to function. In this embodiment, the functionality described herein can be combined with a standard Windows login system (and BIOS or PXE environment). The management entity 28 can integrate with the common user management tools of the corporate Microsoft network and allow the administrator to set login policies for each user. In many cases, the management entity 28 is able to derive all required information from existing management information, which makes this new functionality nearly transparent to administrators and reduces training and adoption costs. Management entity 28 may run within an enterprise network or be hosted as an ASP model by a laptop manufacturer, BIOS manufacturer, or other trusted partner. The certificate distribution entity 32 may operate partly within the corporate network and partly at global sites. Since the certificates are not sensitive information, the globally accessible repository of the certificate distribution system can be run as a web service, making the certificates available to users outside the corporate network. the

In the embodiments herein, each computer should require a new certificate every day. However, one of ordinary skill in the art will appreciate that the time increments may be varied such that the computer may request a new certificate every week or every hour. the

In addition, it is also possible to take advantage of a rarely used feature of IDE hard drives which allows a password to be set on the drive, which must be presented to the drive before it will spin up and allow access to the content. If the drive's firmware is modified to use the system described herein, access to the hard drive may be restricted such that the computer hard drive cannot be accessed even if the hard drive is placed in a different computer. This feature can be implemented with other types of hard drives. the

In other embodiments, the system can be used to access data files, actual disk volumes, logical volumes, and the like. In some cases, such as in the case of restricted access files, it can be used to make appropriate modifications to the corresponding operating system. the

Referring to FIG. 1B , FIG. 20' illustrates another embodiment having multiple management entities 28a-28c. Although FIG. 20' shows three management entities 28a-28c, the system described herein can work with any number of management entities. In the embodiment shown in FIG. 20', it is possible that one of the managing entities 28a-28c (e.g., managing entity 28a) generates a credential, while the other of the managing entities 28a-28c (e.g., managing entities 28b, 28c) generates a certificate, or All management entities 28a-28c generate certificates. Optionally, a certificate distribution entity 32 may be used. the

Referring to FIG. 1C, FIG. 20" shows another embodiment with multiple certificate distribution entities 32a-32c. Although FIG. 20" only shows three certificate distribution entities 32a-32c, the system described herein can be used with any Number of proofs assigned entities to work together. The embodiment shown in Figure 20" can be implemented using technology provided by Akamai Technologies Incorporated of Cambridge, Massachusetts.

Referring to FIG. 1D, FIG. 20"' shows another embodiment having multiple management entities 28a'-28c' and multiple certificate distribution entities 32a'-32c'. While 20"' only shows three management entities 28a'-28c' and three certificate distribution entities 32a'-32c', the system described herein can work with any number of management entities and certificate distribution entities. The embodiment shown in Figure 20 "' has combined the feature of the embodiment shown in Figure 1B and the feature of the embodiment shown in Figure 1C.

Referring to FIG. 2 , there is shown in detail the electronic device 24 comprising a validation unit 42 , credential data 44 and certification data 46 . The validation unit 42 can be implemented using hardware, software, firmware or a combination thereof. Based on certain conditions, such as activation, validation unit 42 receives an activation signal which causes validation unit 42 to check credential data 44 and certification data 46 and, based on the results of the check, generate a pass signal indicating that legal proof has been presented or generate a fail signal. The output of validation unit 42 is used by continuing processing/devices such as computer boot firmware to determine whether operations can continue. the

In the embodiment herein, the electronic device 24 includes an external interface 48 which is controlled by the confirmation unit 42 . Like validation unit 42, external interface 48 may be implemented using hardware, software, firmware, or a combination thereof. An external interface 48 is connected to the connection 22 and is used to retrieve new certificates which may be saved in the certificate data 46 . Thus, if validation unit 42 determines that the certification stored in certification data 46 is insufficient (e.g. expired), validation unit 42 provides a signal to external interface 48 to cause external interface 48 to request a new certification via connection 22. Of course, if the electronic device 24 has been lost and/or stolen or if the user is a terminated employee or if there are any other reasons for not allowing access to the electronic device 24, then the external interface 48 will not be able to obtain valid certification. In some embodiments, external interface 48 prompts the user to make the appropriate electronic connections (eg, connecting a laptop computer to a network). the

In the embodiment herein, time data 52 provides information to validation unit 42 to indicate the last time a valid certificate was presented to validation unit 42 . This information can be used to discourage attestations from being requested too often, while preventing waiting too long before requesting new attestations. The interaction and use of validation unit 42, external interface 48, credential data 44, certification data 46, and time data 52 are described in detail elsewhere in this specification. the

Referring to FIG. 3 , a flowchart 70 shows the steps performed to determine whether to send an initiation signal to validation unit 42 to determine whether validation unit 42 should check credential data 44 and certification data 46 to generate a pass or fail signal. Processing begins with a first step 72, which determines whether a start-up operation is being performed. In the embodiments herein, proofs are always checked along with the start-up operation. Thus, if at test step 72 it is determined that a start is being performed, then control passes from step 72 to step 74 and a start signal is sent to confirmation unit 42 . Following step 74 is step 76 where the process waits for a predetermined amount of time before looping again. In this embodiment the predetermined period of time may be one day, although other periods of time may be used. After step 76, control passes back to test step 72 as described above. the

If it is determined at test step 72 that a start-up operation has not been performed, control passes from test step 72 to a test step 78 which determines whether a predetermined amount of time has elapsed since the validation unit 42 was last run. This can be determined using the time data element 52 and perhaps the current system time. In the embodiment herein, the predetermined amount of time used in the testing step 78 is one day. If at test step 78 it is determined that the amount of time since validation unit 42 was last run is greater than a predetermined amount of time, then control passes from test step 78 to step 74 where an activation signal is sent to validation unit 42 . Following step 74 or after test step 78 (if the amount of time is not greater than a predetermined amount of time) is step 76 as described above. the

Referring to FIG. 4, a flowchart 90 shows the steps performed by validation unit 42 to determine whether sufficient proof has been received. As described elsewhere in this specification, validation unit 42 sends either pass or fail signals to subsequent processes/devices (such as computer boot firmware or disk drive firmware). Processing starts in a first step 92 where the validation unit 42 determines the necessary certifications. It is necessary to prove the proof determined for the validation unit 42 that is sufficient to be able to send a pass signal. Validation unit 42 determines that certification is necessary by checking credential data 44, certification data 46, time data 52, and even an internal/system clock. Following step 92 is a test step 94 which determines whether appropriate certificates are available locally (ie, in certificate data 46) and whether locally provided certificates meet the necessary requirements (described elsewhere in this specification). If so, control passes from step 94 to step 96 where validation unit 42 issues a pass signal. After step 96, processing ends. the

In some embodiments, it is possible and desirable to obtain and store future proofs in proof data 46 . For example, users who are not expected to be connected to the management entity 28 and/or the certificate distribution entity 32 may obtain and store future certificates. In these embodiments, when an electronic device is connected to the management entity 28 and/or the certificate distribution entity 32, it may automatically poll for future certificates, which may be provided according to redefined policies, or (or in addition), the user and/or Or it is also possible for the electronic device to explicitly request future proof, which may or may not be provided according to the control policy. the

If at test step 94 it is determined that suitable certificates are not available locally (i.e. in the certificate data 46), control passes from test step 94 to test step 98 where validation unit 42 determines whether suitable certificates are externally available, e.g. as described above , by providing a signal for the external interface 48 to attempt to retrieve the certificate. If it is determined at test step 98 that the externally provided certification meets the necessary requirements (described elsewhere in this specification), control passes from test step 98 to step 96 where validation unit 42 issues a pass signal as described above. In the exemplary embodiment here, externally provided certificates are stored in certificate data 46 . the

If it is determined at test step 98 that appropriate data is not available externally, either because there is no proper connection or for other reasons, then control passes from test step 98 to step 102 where the user is prompted to enter appropriate credentials. In an embodiment herein, if the user is in a location without a proper electrical connection, the user can call a specific phone number and receive appropriate identification in digital form, which can be manually entered into the electronic device along with the prompt provided by step 102 . Of course, the user may receive proof by other means, such as being handwritten, typed, or even published in a newspaper (for example, in a classifieds area). the

Following step 102 is a test step 104 which determines whether the user has entered proof that the necessary requirements are met (as described elsewhere in this specification). If so, control passes from test step 104 to step 96 where validation unit 42 issues a pass signal as described above. Otherwise, control passes from test step 104 to step 106, where validation unit 42 signals a failure. After step 106, the process ends. the

Referring to FIG. 5 , a flowchart 120 shows the steps performed to generate a credential for use by the validation unit 42 . The steps of flowchart 120 may be performed by management entity 28 that generates a credential (and a series of certificates) and provides the credential to electronic device 24 . Other suitable entities, such as those authorized by the management entity 28, may generate credentials. In embodiments herein, random values may be used in conjunction with generating credentials and proofs, generally unpredictable. Following step 122 is step 124 in which the index variable I is set to one. In the example herein, the certificates provided are used throughout the year and new certificates are required each day, so that 365 separate certificates can be generated along with the generated certificates. The subscript variable I is used to keep track of the number of certificates being generated. Following step 124 is step 126 where an initial proof value Y(0) is set equal to the random value RV determined at step 122 . the

Following step 126 is a test step 128 which determines whether the index variable I is greater than the endpoint IEND. As mentioned above, in the embodiment herein, 365 certificates are generated along with the generation voucher, so, in this embodiment, the IEND is 365. However, for other embodiments, IEND may be set to any number. the

If at test step 128 it is determined that the value of I is not greater than IEND, then control passes from step 128 to step 132 where Y(I) is set equal to the one-way function applied to Y(I-1). The one-way function used at step 132 is one that, given the result of applying the one-way function, makes it nearly impossible to determine the value entered into the one-way function. Thus, for the one-way function used at step 132, given Y(I), it is very difficult if not impossible to determine the input value (Y(I-1) in this example). As used herein, the term one-way function includes any function or operation that suitably provides this property, including but not limited to conventional one-way hash functions and digital signatures. This property of the one-way function used at step 132 can be used to enable storage and distribution of issued certificates in a non-secure manner, as described elsewhere in this specification. The voucher and certificate may be generated at different times or the certificate may be generated at a later date by the entity that generated the voucher or by another entity. Note that for other embodiments, it is possible to have Y(I) not be Y(I-1) or any other function of Y in this regard. the

Processing starts in a first step 122 where a random value RV is generated. After step 132 is step 134, the subscript variable I is incremented by 1. After step 134, control passes back to test step 128, as described above. If it is determined at test step 128 that I is greater than IEND, then control passes from test step 128 to step 136 where the final value FV is set equal to Y(I-1). Note that I is decremented by 1 because I was incremented beyond IEND. Following step 136 is step 138 in which the managing entity 28 (or other entity generating the certificate and voucher) digitally signs the end value, current date, and other information to be used with the certificate. In embodiments herein, other information may be used to identify a particular electronic device (such as a laptop), a particular user, or bind credentials and proofs to a particular electronic device and/or user and/or to some other property Other Information. Optionally, date and/or FV can be combined with other information. For example, an OCSP-like signed message could be used that simply says "device#123456 is valid on 1/1/2004" or turns on or off a bit in the miniCRL corresponding to a particular device. In these cases, the credentials on the device may authenticate the device (ie determine that the device is really device #123456, etc.). Both OCSP and miniCRL are well known in the prior art. After step 138, processing ends. the

Referring to FIG. 6 , a flowchart 150 shows the steps performed by validation unit 42 in determining the validity of a certificate. Processing starts in a first step 152 where the validation unit 42 receives a certificate (eg by reading the certificate from the certificate data 44). Following step 152 is step 154 in which validation unit 42 receives the voucher (eg, by reading voucher data 46). the

Following step 154 is a test step 156 which determines whether other information provided along with the voucher matches. As described elsewhere in this specification, other information includes the identification of the electronic device, the identification of the user, or other property identifying information. If at test step 156 it is determined that other information associated with the credential does not match the particular property described by the other information (e.g., the credential is for a different electronic device or a different user), then control passes from test step 156 to step 158, failure signal is provided. After step 158, processing ends. the

If at test step 156 it is determined that other information associated with the voucher matches, then control passes from test step 156 to step 162, where variable N is set equal to the current date minus the date associated with the voucher (i.e., the number of days since the voucher was issued). days). Following step 162 is step 164 where the proof value provided at step 152 has the one-way function applied to it N times. The one-way function used at step 164 corresponds to the one-way function used at step 132, as described above. the

Following step 164 is a test step 166 which determines whether the result obtained at step 164 is equal to the final value FV, which is part of the voucher received at step 154 . If so, control passes from test step 166 to step 168 where validation unit 42 provides a pass signal. Otherwise, if it is determined at test step 166 that the result obtained at step 164 is not equal to the final value FV supplied with the voucher of step 154, then control passes from test step 166 to step 172 where validation unit 42 provides a failure signal. After step 172, processing ends. the

Digital signatures provide an efficient form of Internet authentication. Unlike traditional passwords and PINs, digital signatures provide ubiquitously verifiable and undeniable authentication of authority. A digital signature can be generated via the signing key SK and verified via the matching verification key PK. User U keeps his own SK secret (so that only U can sign on U's behalf). Fortunately, the key PK does not "betray" the matching key SK, i.e., knowing PK does not give the enemy any real benefit in computing SK. Thus, user U can make his own PK as public as possible (so everyone can verify U's signature). For this reason, the PK is best called a public key. Note that the term "user" may refer to a user, entity, device or collection of users, devices and/or entities. the

Public keys can also be used for asymmetric encryption. A public encryption key PK can be generated together with a matching decryption key SK. Again, knowing that PK will not betray SK. Any message can be easily encrypted using PK, but the ciphertext computed in that way can be easily decrypted only by knowing the key SK. Thus, user U can make his own PK as public as possible (so that everyone can encrypt messages for U), but keep the SK private (so that only U can read messages encrypted for U). the

The well known RSA system provides examples of digital signatures and asymmetric encryption. the

A certificate called by an alphanumeric string specifies that the given key PK is the public key of the given user U. An entity, often called a certificate authority (CA), generates and issues certificates to users. Certificates expire after a specified time, usually one year in the case of public CAs. In fact, a digital certificate (C) is composed of several values securely bound together by the digital signature of the CA: SN-the serial number unique to the certificate, PK-the user's public key, U-the user's name, D ₁ -issuance Date, _D2 - expiration date, and AI - additional information (including no information). Denoted notationally, C = SIG _CA (SN, PK, U, D ₁ , D ₂ , AI).

A public encryption key may also provide a means of authentication/identification. For example, a party who knows that a particular public encryption key PK belongs to a particular user U (e.g. because the party has verified U's corresponding digital certificate and PK) and desires to identify U can randomly challenge C using the PK encryption and ask U to decrypt it with the correct answer. Since only SK's processor (and thus U) can do this work, U is fully identified if the answer to the challenge is correct. the

A system may be provided to control physical access to areas using smart doors (and/or smart virtual doors, as described elsewhere in this specification). A smart gate verifies that the person entering is currently authorized to enter. It is advantageous to provide the door not only with a user-specific credential but also with a separate certificate, the credential/user still valid to some extent, which can be safely used even by disconnected doors. In the Examples, such proof was generated as follows. Assume that the credentials indicate to the door that the user has access. Then, for each credential and each time interval (e.g., every day), the appropriate entity E (e.g., the entity that decides who is authorized to access the door at any time or a second entity working for the entity) calculates an authenticated indication ( PROOF), which is an indication that a particular credential is valid for a particular time interval. (PROOF can also indicate to the door that the credential is valid for a specific time interval if the credential does not establish that the door user is authorized to enter). the

E's PROOF may consist of E's digital signature, which specifies in an authenticated manner that a specific credential is valid at a specific time interval, for example: SIG _E (ID, Day, Valid, AI), where ID is the information identifying the credential (such as The serial number of the certificate), Day is an indication of a specific time interval (ordinary specific day), Valid is an indication that the certificate is considered valid (if E has never signed a similar data string, the indication can be omitted, unless the certificate is considered valid ), the AI indicates any additional information deemed useful (including no information). In some cases, E's signature may be a public key signature (but it may also be a private key signature, ie, a signature that can be generated and verified via a single secret key, known only to the signer and verifier). If the credential includes a digital certificate, a primary embodiment may include a short-lived certificate, i.e., a digital signature that reissues the credential for a desired time interval (e.g., the digital certificate specifies the same public key, the same user U, and some other basic information, but also specifies start date and expiration date to determine desired, common days). For example, in an inferior embodiment, where short-term certificates generally last for one day, PROOF may take the form _SIGE (PK, U, D ₁ , D ₂ , AI ), where the start date D ₁ designates the beginning of a particular day D, End date _D2 designates the corresponding end of day D, or _D1 = _D2 = D; or, more simply, use a single date info field to determine the day in question, _SIGE (PK, U, Day, AI). If E matches the original issuing authority, the short-term certificate PROOF can take the following forms: SIG _CA (PK, U, D ₁ , D ₂ , AI) or SIG _CA (PK, U, Day, AI).

As an authenticated user, it is not possible to generate its own PROOF at that time (that is, the PROOF of its own certificate at that time), nor can it change its yesterday's PROOF to today's own PROOF, nor can it change another user's today's PROOF to its own PROOF today. Because PROOFs are essentially inductive and cannot be changed, these PROOFs do not have to be protected. Thus, entity E can make PROOF available at negligible cost. For example, E can post all PROOFs for a particular day on the Internet (eg make the PROOFs available via an Akamai server or similar), or send the PROOFs to a responder/server that is easily accessible to the user. For example, to a server located at the entrance of an airport (or office building), where many doors should be properly accessed. In this way, an employee coming to work can easily obtain his own PROOF (eg, by inserting his own card into a card reader connected to the server) and expressly save the PROOF on his own card, along with his own credentials. This way, when a user presents their card to a door whose credentials authorize access, the door not only verifies the credentials but also receives and verifies the PROOF of the current authorization, no connection required at all. The gate verifies PROOF (e.g. verifying E's digital signature via E's public key which can be preserved since installation) and whether the time interval specified by PROOF is correct (e.g. via its own local clock). If all is well, the door grants access, otherwise the door denies access. In essence, a gate can be a disconnected gate, whose PROOF verification is relatively easy (because the gate receives PROOFs from most available parties: real users require access) and relatively secure (although the gates receive PROOFs from arguably most suspicious parties: real user requesting access). In fact, the user's required access can often be physically close to the door, so PROOF can be provided very easily without using any connections to remote sites, and thus can operate independently of the door's connectivity. At the same time, when it matters most, users demand access to perhaps the most untrustworthy source of information. However, since a user cannot generate or change its own current valid PROOF in any way, gates may note that a properly authenticated PROOF must be generated by E, and that E should not generate a PROOF if E knows that the user will not be authorized for a certain time interval . When a user is de-authenticated, E will stop issuing the PROOF authorized by that user, so the user can no longer enter the corresponding door (even a door that is not connected), because the user will lack the PROOF that the door needs to authenticate to grant access. Thus, by using the user to require access to demonstrate proper and current authorization, the same as described herein dispenses with the inconvenience associated with other systems of not needing to dispatch crews to reprogram disconnected doors. the

The method also enables one to manage access to disconnected doors by "role" (or by "privilege"). That is, instead of using a credential to specify the doors a user is authorized to enter and then issuing a PROOF as daily as a proof of the credential's current validity (nor issuing a PROOF specifying that a particular credential authorizes its user to enter certain doors at specific time intervals), disconnected doors may Programmed (eg, at install time) to grant entry only to users with specific roles. For example, the cockpit door of an aircraft may be programmed to grant access only to the pilot (PILOT) and inspectors. Credentials may be issued to employees to primarily guarantee their identity (which will not change), while each PROOF issued eg on a specific credential each day may also specify (eg in an AI field) its corresponding user's role on that day. For example, PROOF= _SIGE (ID, Day, PILOT, AI) proves that the user corresponding to the credential identified by ID is a pilot on that day. In this way, employees can "transition" from one role to the next without having their credentials reissued and without specifying in the user's credentials or their corresponding daily PROOF which doors the user can enter that day. It should be noted that the number of such gates can be very large. Thus, it is very cumbersome to specify within the user credentials all the doors the user is granted access to. Furthermore, if new doors are added (eg because of a new aircraft purchase), the pilot's credentials have to be reissued to specify the additional doors, which is also very cumbersome.

The time interval appropriate for a particular credential may be specified within the credential itself, or may be specified by the credential along with the PROOF. For example, a voucher may specify a specific start date and it needs to be proven valid every day, while a PROOF may specify a time interval 244, meaning that the PROOF refers to the days 244 after the start date specified in the voucher. the

The system described herein is also advantageous over more expensive interconnecting door systems. For example, assume that all doors are securely connected to a central database, and assume that a sudden power outage occurs (eg due to sabotage). Then the connecting door may be forced to choose between two extreme options: always open (good for safety but bad for secrecy, especially in the case of terrorists causing power outages) and always closed (bad for safety but good for secrecy) . By contrast, in the event of a sudden power failure, the system described herein provides a more flexible response, some (no longer) connected doors can remain closed while others remain open, and others can continue to be pressed in. The disconnected door access control described operates. That is, as long as the correct credentials and the correct PROOF are presented, the battery-dependent door can be opened. In fact, all employees may have normally received their expected PROOF before the outage occurred. the

Of course, entity E may generate PROOFs specifying different time intervals for different credentials. For example, in an airport facility, police officers and emergency personnel may have daily PROOFs specifying the next two weeks as respective time intervals, while all regular employees may have daily PROOFs specifying only those days. Such a system would provide better control in the event of prolonged and unexpected power outages. In the event of a power outage like that, the usual daily distribution of PROOF may be interrupted and general employees may not receive their daily PROOF, but police and emergency personnel may still enter into their cards the two weeks they received the previous day certificate, and thus continue to function at all doors (eg, all doors) they were granted access to. the

It should be appreciated that the methods described herein involve the use of credentials consisting of a simplified form of credentials, which may be referred to as minimal credentials. A minimal certificate may essentially omit the username and/or identifier ID of the certificate (or replace the username and/or identifier ID with the certificate's public key, which is unique per certificate). For example, a minimal certificate credential may take the form of C=SIG _CA (PK, D ₁ , D ₂ , AI), with the understanding that correct presentation of this credential includes proving knowledge of the secret key SK corresponding to PK (e.g. via a challenge-response method). The gate knows in advance whether the correct presentation of credentials on the PK (preferably if currently validated) should result in granting entry. Alternatively, a minimum credential C may specify (as in an AI) whether a user who knows the corresponding SK is authorized to enter a particular door. If it is understood that any similar signature indicates validity by implication, a PROOF for a minimal certificate whose public key is PK can be of the form: SIG _E (ID, Day, Valid, AI) or SIG _E (PK, Day, Valid, AI) or SIG _E (ID, Day, AI). Alternatively, the current PROOF of the minimum certificate may take the form of reissuing the minimum short-term certificate: e.g., SIG _E (PK, D ₁ , D ₂ , AI ), where the start date D ₁ refers to the beginning of a particular day D, and D ₂ corresponds to the day End of D, or D1 = D2 = D; or, SIG _E (PK, Day, AI); or, let E coincide with the original issuing authority, SIG _CA (PK, D ₁ , D ₂ , AI) or SIG _CA (PK, Day, AI). In conclusion, any approach to credentials described herein should be understood to apply minimal credentials as well.

The smart gate can verify the validity and circulation of the user's credentials, which can be accompanied by corresponding proofs. Use of credentials/proofs by users to gain access to zones is similar to using credentials/proofs in controlling access to electronic devices, as described elsewhere in this specification. The following are examples of credentials/proofs, some of which may be combined with others:

1. PIN or password, input on the key pad associated with the door or communicated to the door through the user card;

2. Biometric information, provided by the user via a special input machine associated with the door;

3. The traditional (handwritten) signature is provided by the user through the special signature blog associated with the door;

4. Digital certificate for public key PK (e.g. such credential can be stored in user card, correct user/card can authenticate/recognize its identity to door using corresponding secret key SK - if challenged protocol). For example, if the PK is a signing public key, the gate can require that a particular message has been signed, and that the correct user - the only one who knows the corresponding secret signing key SK - can provide the correct requested signature; if the PK is a public encryption key key, the gate can request that a particular challenge encrypted ciphertext be decrypted, which can be done by the correct user who knows the corresponding secret decryption key SK. the

5. An enhanced digital certificate including a daily "confirmation value" (which ensures that the certificate is valid on that particular date), stored in the user card and communicated to the door;

6. The digital signature of the central authority confirming that the user's certificate is valid at the current time, which provides the server or transponder to communicate to the gate;

7. The digital certificate stored in the user card and communicated to the door and the daily "confirmation value" communicated to the door through the server or transponder;

8. The secret stored in the user card, whose knowledge is proved to the door by the interactive (possibly zero-knowledge) protocol possessed by the door;

9. The agency's secret key signature, stored on the user's card, which indicates that the user is authorized to enter on specific days. the

Thus, in some cases the voucher/proof is provided as one piece, while in other cases the voucher/proof is provided in separate parts: the voucher and the separate certificate. For example, where the credential/certificate consists of an enhanced digital certificate that includes a daily confirmation value indicating that the credential is valid on that particular date and is associated with the user and communicated to the gate, the credential (enhanced digital certificate) can be independent of the attestation ( daily confirmed value) provided (by different means and/or at different times). Similarly, credentials and certificates may both be generated by the same institution or by different institutions. the

Referring to FIG. 7 , a system 200 is shown that includes an area 202 where physical access to the area 202 is to be restricted. Area 202 is enclosed by a plurality of walls 204-207. Wall 207 has a door 212 to provide egress from area 202 . In other embodiments, more than one door may be used. Walls 204 - 207 and door 212 provide an access barrier to area 202 . Door 212 may be locked using electronic lock 214, which prevents door 212 from opening until electronic lock 214 receives an appropriate signal. Electronic lock 214 may be implemented using any suitable component that provides the functionality described herein, including but not limited to using an off-the-shelf electronic lock. the

Electronic lock 214 may be connected to a controller 216 that provides appropriate signals to electronic lock 214 to allow door 212 to be opened. In some embodiments, electronic lock 214 and controller 216 may be provided in a single device. The controller 216 may be connected to an input device 218 which may receive the user's credentials and, optionally, a corresponding certificate indicating that the user is currently granted access to the area 202 . The input device 218 may also receive an emergency legal revocation alert (HRA), which indicates that the user is no longer permitted to enter the area 202 . HRA will be described in detail below. The input device 218 may be any suitable input device such as a keypad, card reader, biometric device, or the like. the

Optionally, the controller 216 may have an external connection 222 that may be used to transfer data to or from the controller 216 . External connection 222 may be private, although in some embodiments external connection 222 need not be private. Furthermore, external connections 222 may not be required, as the functionality described herein may be provided using stand-alone devices having no external connections. In instances where external connection 222 is provided, external connection 222 may be used to transfer credentials, certificates, HRAs, and/or for online access to area 202 . Online access is described in detail elsewhere in this note. It should be noted that the external connection 222 may be an intermittent connection such that, for example, at certain times the external connection 222 provides connectivity to the controller 216 and at other times the controller 216 has no external connection. In some cases, external connection 222 may be used to transmit a portion of the credential/certificate (such as a PKI digital certificate), while the user presents the remainder of the credential/certificate (such as a daily confirmation value used with the digital certificate) to input device 218 . the

In some embodiments, a user may present card 224 to an input device. As described elsewhere in this specification, card 224 may be a smart card, PDA, etc. that provides data (eg, credentials/certification) to input device 218 . Card 224 may obtain some or all of the data from transponder 225 . In other examples, card 224 may obtain data from other cards (not shown), input device 218 (or some other mechanism associated with access area 202 ), or some other suitable source. the

In a first example, credentials and proofs can be maintained using a physically protected pin/password. In this example, each morning the server generates a new secret password SU for each authorized user U and communicates the new SU to the specific doors U is allowed to access. Communications can be sent encrypted using an unsecured line or can be transmitted to the gate via some other secure means. When U comes to work in the morning, the central server causes U's card to receive the current secret password SU. The secret password SU is stored in the card's secure memory, which can only be read when the card is properly authorized (eg by the user entering a secret PIN associated with the card or by connecting to a server or trusted hardware on the door). Whenever the user attempts to enter the door, the card securely communicates the SU to the door. The gate then checks whether the value SU received from the card matches the value received from the server in the morning, and if so, allows entry. the

Thus, SU is the user credential for the current day. The advantage of this system is that each voucher has only a limited duration: if an employee is terminated or his card is stolen, his voucher will not be useful the next day. However, the system requires some connectivity: at least short-term connectivity (preferably every morning) is required to update the gates. This transmission should be kept secure (eg physically or using a password). the

In another example, the user credentials include a secret key signature. This example uses signatures, either public key signatures (such as RSA signatures) or secret key signatures (such as Message Authentication Code or MAC). For example, the access control server generates a signature using the secret key SK, and the gate has means of verifying such a signature (eg via the corresponding public key or by sharing knowledge of the same SK). When user U comes to work on the morning of day D, the server causes the user card to receive a signature Sig, which identifies U's identifying information (such as a unique card number, or U's secret password, or biometric information such as U's fingerprint) and date D . When U tries to enter the door, the card communicates the signature Sig to the door, which verifies the validity of the Sig and even the identification information provided by U, and the date provided by the door lock. If all are correct, the door allows entry. the

In this technique, the signature Sig can be regarded as the user's credential along with the proof. This approach has its own advantages: cards don't need to keep secrets, doors don't need to maintain a secure connection to a central server, and there's no long list of valid credentials. the

In another example, the user's credentials include a digital certificate with hash chain validity proofs similar to those produced by flowchart 120 of FIG. 5 . This example uses public key signatures and a one-way hash function H (to implement a special type of digital signature). The central authority has a pair of keys: a public key PK (known to the gate) and a secret key SK which is generally not known. For user U, the institution generates a random secret value X0 and calculates the values X1=H(X0), X2=H(X1), . . . , X365=H(X364). Since H is a one-way hash function, each value of X cannot be computed from the next value of X. The organization issues a digital certificate Cert to U, signed with SK and contains the value X365, which is valid for one year. Next, when U comes to work on day i, the organization makes the user card receive the confirmation value Xj for that day, where j=365-i. When U tries to enter the door, the card communicates to the door a confirmation value Xj and a certificate Cert containing X365. The door verifies the validity of Cert with the institution's public key PK and also checks whether applying H to Xj i times produces X365. It should be noted that "one year" and 365 may be replaced by any other time period. the

Thus, the user's certificate Cert and the confirmation value Xj constitute the user's credential/proof. This system has many advantages: neither the door nor the card needs to keep any secrets; the door does not need to have any secure connections; certificates can be issued once a year, and thereafter the daily computational load on the central authority is minimal (since the authority only needs to retrieve Xj ); daily confirmation values can be provided by non-secure (cheap) deployed transponders, since they do not require secrecy. the

The duration of user U's credentials/proofs is usually limited, which is useful in many situations. For example, if U is an employee of the airport and is terminated, his credential/proof may expire at the end of the day and he can no longer enter the gates of the airport. Credentials with a shorter duration may be desired for more precise access control. For example, U can be locked out of the airport within one minute of being terminated if U's credential/proof includes hours and minutes and date. However, credentials/proofs of shorter duration require more frequent updates, which increases the cost of the system. Thus, there is an inherent balance between desiring to have short-term credentials and having a low-cost system, which can result in credentials sometimes lasting longer than desired. For example, U may need to be outside the airport immediately, but his credential does not expire until midnight. Therefore, it is desirable to be able to immediately revoke credentials that have not expired. the

It should be noted that if the credentials/proofs are kept in a secure database that is queried every time access is requested, it is fairly straightforward to revoke the credentials/proofs by removing revoked credentials/proofs from the database. However, it is expensive to make the gate query the security database every time. First, because this adds a significant delay to the transaction processing, since the user wants to get in the door right away, but he has to wait for the query to be properly completed. Second, because the communication is preferred to be over a secure passage, this can easily cost $4,000 (or more) per door or in some cases not reach at all (eg aircraft or cargo container doors). Third, because a single secure database can only handle a limited query load, and duplicating a secure database is itself very expensive and time-consuming (eg, because the cost of keeping the database secure must double and the effort to keep these copies in sync must also increase). Thus, unlike full-flow methods, disconnected or intermittent-connection methods (such as the above examples) require less communication and typically store credentials/proofs on non-secure transponders or cards. In this case, simply removing the credential/certificate from the database is not sufficient. Referring again to the above example, the password SU or authority signature or confirmation value Xj has to be deleted from the user card or door for some reason. Furthermore, even such deletion does not always guarantee the cancellation of the credentials, since credentials stored in unsecured transponders can be obtained by anyone, including malicious attackers, who save the credentials and attempt to Use that credential. Thus, even if cost-effective solutions with limited duration vouchers exist, these solutions do not necessarily provide sufficient cancellation of non-expired vouchers/proofs by themselves. the

Revocation of credentials/proofs can be performed using an urgent legality revocation alert (HRA), which is a piece of data (preferably authenticated) transmitted to a door that will prevent the door from authorizing with a revoked (though possibly not expired) credential/proof user access. For example, an HRA may consist of a digitally signed message indicating that a particular certificate/designation has been revoked. However, it should be noted that in the case of securely connected gates, it may not be sufficient to just send the HRA along the protected connection. However, as noted above, in some cases secure communication doors are very expensive, while in other cases it is impossible (or nearly impossible) to use such a door. the

It is useful if the HRA is identified so that the entity to which the HRA is presented can be relatively certain that the HRA is authentic. Let ID be the identifier of the revoked credential/proof C (specifically, ID can be consistent with C itself), then SIG(ID, "REVOKED", AI) can be HRA, where "REVOKED" means that C has been revoked in any way Signaling of being revoked ("REVOKED" may be the empty string if the fact that the credential/proof is revoked can be inferred by other means - as system-wide agreement that such signed messages are not sent except in the case of revoke), and the AI representative Any additional information (possibly date information - such as time when the credential/proof has been canceled and/or time when the HRA was generated or no information). Specifically, the digital signature SIG may be a public key signature, a private key digital signature, or a message authentication code. It is also possible to issue authenticated HRAs by encrypting the information appropriately. For example, an identified HRA may take the form of ENC(ID, "REVOKED", AI). the

Another notable example of an identified HRA is described in US Patent 5,666,416, which is incorporated herein by reference. The issuing authority combines the certificate/proof C into a public key (of the digital signature scheme) unique to C, PK, such that the digital signature on PK indicates that C is revoked. In a particular embodiment of such a scheme, PK may consist of a value Y1 calculated as Y1=H(Y0), where H is a (preferably hashed) one-way function and Y0 is a secret value. When credential/certificate C is revoked, an HRA consisting only of Y0 is issued. Such an HRA can be verified by hashing Y0 and checking if the result matches the value Y1 belonging to the credential/certificate C. the

It should be noted that a signature may not be required for the HRA. For example, in the case of a secure access gate, just sending (ID, "REVOKED", AI) along the protected connection is sufficient as an HRA. However, the advantage of an authenticated HRA is that the HRA itself need not be secret. Authenticated HRAs, once authenticated by the appropriate agency, may be maintained on more than one (possibly geographically dispersed) transponder. Furthermore, these transponders can be left unprotected (unlike the issuing authority), since they do not hold secret information. Higher reliability can be provided at lower cost by duplicating multiple unprotected transponders. Some other advantages of the identified HRA example of US Patent 5,666,416 are: (1) the HRA is fairly short (can be as short as 20 bytes); (2) is fairly easy to compute (simply, a look-up table of Y0 previously saved); and (3) are fairly easy to verify (only apply the one-way hash function once). the

Identified HRAs are particularly advantageous for efficient broad dissemination, as described further below. When an HRA is transmitted through multiple points close to the door, there may be multiple possibilities for an incorrect HRA to be inserted into the system. In fact, the HRA received by the gate not directly through or from the issuer over the secure connection is nothing but purely unverified information of specific credential cancellation. However, if the HRA is authenticated, this unverified information can be easily confirmed by the gate, which can verify its reliability. the

In summary, the HRA can be specific for a single voucher/certificate or can provide cancellation information for multiple vouchers/certificates. For example, if ID1, . . . , IDk are identifiers of revoked certificates, the HRA may consist of a single digital signature SIG(ID1, . . . , IDk; "REVOKED"; AI). Consider the case where a door holds information that establishes a credential/certification of the right to enter the door. If such a gate receives an HRA indicating that one or more credentials/certifications are revoked, the gate need not save the HRA. It is sufficient for the gate to delete the determined credentials/proofs from its memory (or mark them as "REVOKED" somehow). Then, if a user with a revoked credential/proof attempts to access, the door will not allow access because the presented credential/proof is not currently held in the door, or if held there, has been marked as "REVOKED". the

Now consider that the gate does not hold information determining all allowed credentials/proofs, but instead verifies whether the credentials/proofs are allowed when presented. When a user presents a credential/certificate to such a door, the gate may first verify that the credential/certificate is valid, regardless of the HRA. (For example, if the credential/proof includes a digital signature, the gate verifies the signature. Additionally, if the credential/proof includes an expiration time, the gate also verifies that the credential/proof has not expired, such as using an internal clock.) But even if all checks pass, If the credential/proof is indicated as revoked by the HRA, the door can still deny access. Therefore, it is helpful if such gates have information about the corresponding HRA. One way to achieve this is for the gate to keep all HRAs presented to it. On the other hand, in some cases, this may not be practical. Consider a system where many credentials/proofs can be used to pass through a door. For example, the Department of Transportation is envisioning a 10,000,000 credential scale system for the various individuals (including pilots, airport maintenance personnel, airline employees, pilots, porters, managers, truck drivers, police officers, etc.) ). Prudently estimating a cancellation rate of 10% per year leaves 1,000,000 HRA saved by the end of the year, a very expensive undertaking (if feasible). Furthermore, if the number of HRAs cannot be accurately determined in advance, the system designer has to overestimate the memory capacity for the HRAs to be safe, and build more memory capacity (at higher cost) inside the gate. the

This problem can be solved by means of deletable HRA. This means having the HRA specify a time component that specifies when the HRA can be safely deleted from memory. For example, in a system where the credential/indication has a limited duration, this can be accomplished by: (1) having the credential/certificate include an expiration time after which the credential/proof should not be accepted by the gate as valid (2) cause the HRA of the revoked credential/certificate to include an expiration time; and (3) cause the gate to delete the HRA of the revoked credential/certificate from its memory after the expiration time. For example, the expiration time of the credential/certificate may be the time at which the credential/certificate expires (and the expiry time may be explicitly included in the credential/certificate and authenticated or it may be implied by a system-wide agreement). Deleting the HRA after the expiration time does not compromise security. In practice, if the gate does not hold an HRA that revokes a particular credential/certificate, the expired credential/certificate will be denied access by the gate, possibly because the gate has deleted the HRA from memory after expiration. the

It should be noted that step (2) above is an optional step where the expiration time may be indicated implicitly or indirectly in the HRA. For example, HRA is of the form SIG(C, "REVOKED", AI), and the credential/certificate may include its own expiry date. Furthermore, step (1) above is an optional step, since a deletable HRA can also be implemented using an HRA that does not specify an expiration time for canceled credentials at all. For example, if all credentials in a particular system are valid for at most one day, all HRAs can be erased after being kept for one day (more generally, if the maximum lifetime of credentials/proofs can be inferred somehow, then the corresponding HRA can be in are erased after being saved for the aforementioned amount of time). As another example, when presented with a voucher/certificate with a specific expiration time, the gate may look for an HRA that cancels the voucher. The gate safely deletes the HRA if it exists and the expiration time has elapsed. Otherwise, the gate may save an expiration time associated with the saved HRA and delete the HRA after that time. the

Gates can delete HRAs in a number of ways after they expire. In some cases, HRA deletion can be efficiently implemented by maintaining the HRA's data structure (such as a priority queue) based on expiration time. Alternatively, the gate can periodically look at all HRAs in memory and clear those that are no longer needed. Alternatively, when an HRA is encountered, the gate can delete the HRA if the gate realizes that the HRA is no longer relevant. For example, the HRA may be kept in a list that is checked each time a credential is presented for verification. Whenever an expired HRA is encountered in the list, the expired HRA can be deleted. Alternatively, the gate only deletes HRAs on demand when memory needs to be freed (perhaps for other HRAs). the

The HRA can be removed to greatly reduce the storage capacity required for the gate. Using the above example of 10,000,000 users and a 10% annual cancellation rate, if an HRA expires and is deleted, on average only 2,740 (instead of 1,000,000) HRAs need to be saved per day. This reduced storage capacity requirement is the biggest potential advantage of the removable HRA. the

It can be useful for the HRA to get the door as quickly as possible to notify the door of credentials/certifications that are no longer acceptable. This is a problem with disconnected gates, but it can also be a problem with fully connected gates. Of course, fully connected gates can send HRAs on the gate's connections when HRAs are issued. However, this transmission can be blocked or interfered with by a determined enemy (e.g. if the connection to the door is secured by encryption, the enemy can only cut the wire or alter/filter the signal going on. protection, such interference and blocking may be more difficult, but not impossible). Such malicious HRA jamming and blocking of doors on intermittent (eg wireless) connectivity can be more easily implemented. the

To make it more difficult for enemies to prevent the door from receiving HRA, HRA can be carried by the canceled card itself. For example, when a card communicates with a database or a connected door (or any door that knows the corresponding HRA), the door can send the HRA to the card, and the card can save the HRA. In particular, this can be done without any instructions to the user to protect the HRA from users wishing to tamper with the card and delete the HRA. This method is more effective if the card carries tamper-resistant hardware components or data that cannot be easily read/deleted by the user, such as encrypted data. When the card is subsequently used to attempt to enter any (even completely disconnected) door, the card can communicate its HRA to the door, and based on proper authentication, the card can deny access (and in some cases save the HRA). the

The HRA can be sent to the card over a wireless channel such as via a pager or mobile network or via satellite. This can be done even if the card has only limited communication capabilities, eg by placing wireless transmitters where each user is likely to pass. For example, in a building, such a transmitter could be placed at each building entrance to provide each card with an opportunity to receive a transmission whenever the user of the card enters the building. Alternatively, the transmitter could be placed at the entrance of a parking lot or the like. the

To prevent a malicious user from blocking the transmission (for example, by wrapping the card in a material impenetrable to the transmission signal), the card may in fact require it to receive periodic transmissions in order to be fully functional. For example, the card may expect a signal every 5 minutes to synchronize its clock with the system clock, or it may expect to receive another periodic (preferably digitally signed) signal, such as a GPS signal, or approximately the appropriate noise at the appropriate frequency. If such a signal is not received within a reasonable time interval, the card can "block" and simply refuse to communicate with any door, making itself unsuitable for access. It should be noted that such a system may be more economical and convenient than simply propagating all HRAs to all cards, since HRAs are constantly changing messages. Thus, propagating the HRA to all cards may require building a special purpose satellite or customizing an already existing satellite. The above approach instead utilizes already available widely transmitted signals and installs local transmitters for regular messages. the

Alternatively, if the security policy requires the user to visibly wear the card such as a security badge or present the card to a guard in place (within transmission range), then the user may be prevented from taking actions that would prevent transfers to the card. Other techniques for propagating the HRA for a particular card/credential/proof include using other cards to communicate the HRA to the door. In this technique, card 1 can receive HRA, HRA2, cancellation and difference (for example when obtaining its own daily credential/certification, or wirelessly or when communicating with a connected door or when making any type of connection) The card is the credential/proof associated with Card 2. Card 1 can then save HRA2 and communicate HRA2 to the door, which then also saves HRA2. In practice, Card 1 may be provided to multiple doors, for example to all doors or to all disconnected doors that Card 2 accesses or communicates with during a certain period of time, such as throughout the day. Here, any door (even if not communicated) accessible by card 1 can deny entry to the holder of card 2 containing the canceled voucher/proof. Preferably, HRA2 is digitally signed or self-authenticating, and any door accessible by card 1 can check the authenticity of HRA2 to prevent malicious propagation of fake HRAs. the

This can be enhanced by having the door that card 1 arrives at communicate the learned HRA2 to another card, card 3, which then accesses or communicates with the door. This is useful because card 3 can reach doors that card 1 will not or will reach after card 3. The process can continue by having these additional arriving doors communicate with other cards. Furthermore, certain gates may have connections to each other, even if they are not fully connected to the central database. Thus, such gates can similarly be exchanged for available HRAs. If the cards are capable of communicating with each other - eg when in proximity - they may also exchange information about the HRAs they hold. the

It should be noted that certified HRAs are particularly beneficial for the HRA propagation techniques described herein. In fact, sending HRAs through multiple mediums (cards and doors) may provide multiple points of failure where HRAs may be modified by an adversary or fake HRAs may be injected by an adversary. In a sense, unauthenticated HRAs may have become pure unverified information by the time they hit the gate. Authenticated HRAs, on the other hand, are guaranteed to be correct no matter how they arrive at the gate. the

All HRAs can be preserved and disseminated in this manner without significant consideration of resources. It is also possible to employ some optimizations. For example, a card can manage HRA storage like a door, and delete expired HRAs to free up internal card storage and prevent unnecessary communication with other doors. It is useful to keep memory communication and minimum in such a system, because, even if the number of unexpired but canceled credentials is not large, it may be that some components (such as some cards or doors) do not have enough memory or bandwidth to process all outstanding credentials. Expired HRAs. the

Another possibility to minimize storage and communication includes choosing which HRAs will propagate via which cards. For example, the HRA may be provided with priority information indicating the relative importance of distributing knowledge about a particular credential/proof as quickly as possible. For example, some HRAs may be marked as "Urgent" while others may be marked as "Routine" (priority levels may be as precise or approximate as possible). Devices with limited bandwidth or memory can record and exchange information on higher priority HRAs and can concentrate on lower priority HRAs as long as resources allow. As another example, an HRA that blocks a card from accessing a particular door may be propagated via cards that are more likely to reach that door sooner (eg, cards whose credentials enable access to that door in its vicinity). In fact, the cards and gates may serve to establish which HRA accepts objects for storage and/or otherwise dissemination. Alternatively, the HRA or the cards holding them could be chosen to some degree, which includes randomness, or the gate could provide the HRA to a certain number of cards (eg, the first k cards the gate "encounters"). the

The use of such propagation techniques can reduce the likelihood that a user with a revoked credential/proof will be able to enter, because even with a disconnected door, the user would have to reach the door before any other user presents the appropriate HRA to the door with an updated card . The exchange of information between the card and the door can help ensure that many cards can be notified about cancellations quickly. This method can also be used as a countermeasure against "jamming" attacks that attempt to disconnect a connected gate and prevent the gate from receiving the HRA. Even if the jamming attack is successful and the door is never notified by the HRA from the central server or transponder, it is possible for the door to be notified by the card of an individual user to the HRA. It should be noted that the actual method of exchanging HRAs between cards and doors may vary. In the case of few short HRAs, it is most efficient to swap and compare all known HRAs. If many HRAs are made in a list, the list may contain a time indicating when the list was sent by the server. Then, the cards and doors can first compare the issue times of their HRA lists, and the older lists can be replaced with newer lists. In other cases, more complex algorithms for finding and reconciling differences may be used. the

Efficient HRA propagation can be accomplished by: (1) issuing a certified HRA; (2) sending the certified HRA to one or more cards; (3) causing the card to send the certified HRA to other cards and/or the gate; (4) cause the gate to save the received HRA and/or transmit the received HRA to other cards. the

It is useful to detail some sample HRA usage:

Sequence 1 (directly from "governing body" to the gate) :

1. Entity E cancels user U’s credential/certificate and issues HRA A, which contains information that the credential/certificate has been cancelled;

2. A transmits to door D via wired or wireless communication;

3. D verifies the reliability of A, and if the verification is successful, saves the information about A;

4. When U tries to access D by presenting the credential/certificate, door D notices that the saved information about A indicates that the credential/certificate has been revoked and denies access. the

Sequence 2 (from "Administrative Authority" to user card to door) :

1. Entity E cancels user U’s credential/certificate and issues HRA A, which contains information that the credential/certificate has been cancelled;

2. Another user U' comes to work and presents his card to E to get his current credential/proof;

3. Together with U''s current credential/proof, HRA A is transmitted to U''s card; the card saves A (the card may or may not verify the reliability of A, depending on the card's ability);

4. When U' tries to access door D, its card transmits its credential/proof along with A to D;

5. D verifies the reliability of A, if the verification is successful, save A;

6. When U tries to access D by presenting his credential/proof, gate D notices that A revokes U's credential/proof and denies access. the

Sequence 3 (from "Administrative Authority" to another door to user card to door) :

1. Entity E cancels user U's credential/certificate and issues HRA A, which contains the information that U's credential/certificate has been cancelled;

2. A transmits to door D’ through wired or wireless communication;

3. D' verify the reliability of A, if the verification is successful, save A;

4. Another user U' with his own credentials/proofs presents his card to D' to enter D'. D' transmits A to U''s card in addition to verifying U''s credential/proof and granting entry when appropriate. The card saves A (the card may or may not verify the reliability of A, depending on the ability of the card);

5. When U' tries to access door D, its card transmits its credential/proof along with A to D;

6. D'verifies the reliability of A, if the verification is successful, save A;

7. When U tries to access D by presenting his credential/proof, gate D notices that A revokes U's credential/proof and denies access. the

Sequence 4 (from "management agency" to user card to door) :

1. Entity E cancels user U's credential C and issues HRA A, which contains the information that C has been cancelled;

2. The user U carries his card through the transmission point located near the entrance of the building, which makes his card receive A; the card saves A (the card may or may not verify the reliability of A, depending on the ability of the card);

3. When U tries to access door D, its card transfers A together with C to D;

4. D verifies the reliability of A. If the verification is successful, save A and deny U's access;

5. If U tries again to access D by presenting C, gate D notices that previously saved A has canceled C and denies access. the

Sometimes, following a crime, it is useful to establish who attempted to access a particular door, at what time, what credentials/proofs were presented, and whether access was denied or granted. It is also useful to know if the door mechanism is blocked, if a switch or sensitive element is malfunctioning, etc. Eventually, it may be desirable to maintain an event log of events that occur. It is especially useful if such a log is readily available at some central location so that it can be checked and acted upon. For example, in the event of a hardware failure, a repair crew may need to be dispatched quickly. However, such logs have two major problems. the

First, if the gates are connected, it is easier to collect logs by sending them over the connection. However, collecting event logs is more difficult for disconnected doors. Of course, one way to collect the logs would be to send someone to each disconnected door to physically transfer the logs back to the central location, but that would be too costly. the

Second, for event logs to be trusted, the integrity of the entire system including log generation, collection, and storage should be guaranteed. Otherwise, for example, an adversary could create fake log records or delete valid logs. Traditional methods such as physically securing communication channels and data storage facilities are very costly (and insufficiently secure by themselves). the

By the existence of such a log record, assuming that the log record is valid, the traditional log can conclude that "a certain user went to a certain door". However, this is not suitable for high security applications. Assume that user U is accused of damaging some property behind locked door D. Traditional logging provides only weak evidence that U enters D: one has to believe that no one maliciously falsified the logging. Thus, it is desirable to make logs provide stronger evidence, since logs cannot be "artificial" by an enemy. Specifically, an undisputed log can prove that door D (possibly in cooperation with U's card) created a record in the log. the

The system described here solves this problem in the following way: Whenever a door receives a credential/proof as part of an access request, the door can create a log record (such as a data string) that contains information about the event, such as:

request time;

request type (if more than one request is possible - for example, if the request is for exit or entry, or to turn an engine on or off, etc.);

Credentials/proof and identity presented (if any);

whether the credential/proof was successfully verified;

Whether the credential/proof has a corresponding HRA;

Whether access is authorized or resolved. the

Log records can also contain operational data or information on any unusual events such as current or voltage fluctuations, sensitive component failures, switch positions, etc. One way to generate a non-controversial log involves having the gate digitally sign event information by means of a secret key (SK). The resulting uncontested log can be denoted by SIG(event, AI), where AI represents any additional information. The signature method used by door D can be public key or private key. the

It is useful to emphasize that the signature is valid with respect to the public key PK, or the secret key SK used to generate the signature, or the gate that generated the signature, and thus the undisputed log can be represented symbolically as . SIG _PK (event, AI), SIG _SK (event, AI), or SIG _D (event, AI). Such a log is non-controversial, since it is impossible for an adversary to forge the signature of a door without knowing the corresponding secret key. On the other hand, the reliability of the log can be checked by any properly informed verifier (such as a verifier who knows the PK of the door or the SK of the door), without any hope of the integrity of the database holding the log or the integrity of the system transmitting the log. . In summary, logs can be made indisputable not only by digitally signing each record, but also by using a digital authentication step for multiple records. For example, a gate can authenticate a plurality of events E1, E2, ... by means of a digital signature SIG(E1, . . . , E2, AI). As usual, here and elsewhere in this application, digital signature may mean the process of digitally signing a one-way hash of data to be authenticated. In particular, flow authentication can be seen as a special case of digital signatures. For example, each authenticated record can be used to authenticate the next (or previous) record. One way of accomplishing this involves having the authenticated record contain the public key (specifically, the public key of the previous digital signature) used to authenticate the next or other record.

Logs and non-contested logs can also be generated by the card (in particular, the card can generate non-contested logs by digitally signing information on the event E: denoted by the notation SIG(E, AI)). All logging techniques described here can also be considered in relation to card generated logs. the

In addition, other logs and non-controversial logs are available by door and card. For example, during a door access request, the card may provide the card's own (possibly non-controversial) log records to the door. The gate can examine the log records and only grant access if the gate finds the log records "acceptable". For example, the gate may verify the card's digital signature thereby authenticating the log record; or the gate may verify that the time information included in the card's log record is correct based on a clock accessible to the gate. the

Other types of non-controversial logs can also be obtained by dedicating both the door and the card to the generation and/or authentication of log records. For example, the card can authenticate the logging and the gate can also authenticate at least a portion of the logging information, and vice versa. In a specific embodiment, the card C may give the gate its log-recorded signature x = SIG _C (E, AI), which the gate will countersign, denoted by the notation SIG _D (x, AI'), and vice versa. Alternatively, the door and the card may compute a joint digital signature of the event message (e.g. computed by means of key splitting of the secret signing between the door and the card, or by combining the door's signature with the card's signature into a single "multiple" signature) . Several multi-signature schemes are available, specifically those of Micali, Ohta and Reyzin.

Additional information may be included in the log. Additional information can be checked if the information reported by the card and the door agree. For example, cards and doors can use their available clocks to include time information in log records. Additionally, the card (and possibly the door) may include location information (eg, from GPS) in the log record. Alternatively, if the current location is difficult to obtain (eg because GPS reception capability is unavailable), last known location information (and how long ago it was established) may be included. In this way, in particular in the case of moving doors, such as those of an airplane, it is possible to determine where the door and card were located when the event occurred. the

Of course, even uncontroversial log records as described above can be maliciously deleted from the database or prevented from reaching the database. To prevent such deletions, it is useful to provide a deletion-detectable logging system. Such a system can be built by using the following schemes: (1) authentication schemes (such as digital signature schemes); (2) association generation schemes; and (3) association detection schemes. Given a log event E (part of a sequence of past and/or future events), the correlation generation scheme can be used to generate correlation information CI, which is then securely bound to E by means of an authentication scheme to generate deletion-detectable log records. The correlation generation scheme ensures that, even if the events themselves are uncorrelated and the existence of one event cannot be inferred from the existence of other events, CIs are generated in such a way that missing log records exist without proper correlation information, some of which can use correlation Detection scheme detection. In some cases, the system can also guarantee that even if some log records are missing, other log records can be guaranteed to be trusted and/or individually indisputable. the

In a first example, the associated information CI of log records may include sequentially numbered log records. A corresponding association detection scheme may include notifying the presence of gaps in the sequence. But to get a delete-detectable logging system, a proper binding between CI and logging is found, which may not be easy to achieve, even if secure digital signatures are used for the authentication part of the system. For example, it is not safe to have the i-th log record consist of (i, SIG(event, AI)) because an adversary can modify the number of subsequent records after deleting the log record to hide the interval. Specifically, after deleting log record number 100, the adversary may decrement the number of log records 101, 102, etc. by 1. The adversary can thus hide its deletion because, even though the integrity of the event information is protected by a digital signature, the number itself cannot be protected. Also, even digitally signing the number may not work. For example, assume the i-th log record consists of (SIG(i), SIG(event, AI)). Next, the enemy can: (1) observe and remember SIG(100); (2) delete record number 100; (3) replace SIG(100) with SIG(101) of the original record 101, and remember SIG(101 ), and so on, to completely hide the delete. the

Neither of the above approaches produces the desired secure binding of CI and logging. In fact, by securely binding (1) numbered information with (2) numbered events, we mean that when j is different from i, even if providing (a) secure binding of number i and Ei and (b) number j With the safe binding of Ej, the enemy cannot also create a binding between the number j and the event information about the i-th event Ei. For example, the i-th log record may consist of SIG(i, Ei, AI). This way, deletion of the i-th log record will be detected by a specific later log record. This is because later log records carry numbers greater than i, which cannot be deleted, modified, or replaced with another log record number information by an adversary since it is securely bound to the log record. For example, assume the enemy deletes log record number 100: SIG(100, E100, AI). As long as the adversary cannot delete all subsequent log records (which would require constant access to the database), the adversary will need to create another log record with the same number 100 in order to hide its deletion. However, this is hard because: (a) the adversary cannot generate a brand new 100th log record SIG(100,E',AI') because he does not have the secret signing key for the gate; (b) the adversary is at Cannot modify existing log records without invalidating the digital signature (for example, cannot change SIG(101, E101, AI101) to SIG(100, E101, AI101), even if he remembers the deleted record SIG(100, E100, AI100)); (c) the adversary cannot extract the signature indicating the portion of the log record numbered 100 and bind it with the digital signature to generate another log record. the

Such secure binding may also be achieved by means other than co-digitally signing the record number and the event being numbered. For example, this can be achieved by one-way hashing the record number and the numbered event and then signing the hash, notationally denoted as SIG(H(i,Ei,AI)). As another example, this can be achieved by including a hash of the number in the digital signature of the event, and vice versa: eg in notation SIG(i, H(Ei), AI)). It can also be achieved by digitally signing the number information and the event information: eg in notation SIG(i, SIG(Ei), AI)). As another example, one can separately sign (1) number information and unique string x; and (2) event information and string x, notationally expressed as (SIG(i,x), SIG(x,Ei , AI)) (such a string x can be the current time). the

Removal of detectable logs may also be accomplished through secure binding of log record association information other than sequential number information. For example, some identifying information from previous log records such as record i-1 may be included in log record i. Such information can be a collision-resistant hash of record i-1 (or a portion of log record i-1): notationally, log record i can be denoted as SIG(H(log record i-1),Ei,AI ). Then, if an adversary tries to delete log record i-1, such deletion will be detected upon receipt of log record i, since the hash H(log record i-2) of the previously received log record is identical to H(log record i- 1) Mismatch (due to the anti-collision of H), conversely, H(log record i-1), since it is securely bound to log record i, it cannot be modified by an adversary without destroying the validity of the digital signature . Here, a log record i can also mean a subset of its information such as Ei. the

It should be noted that it is not necessary that the information of log record i−1 is bound to record i, it could be another previous or future record, or indeed, multiple other records. Furthermore, which log record is bound to which record can be chosen randomly. the

Other associated information may also be used. For example, each log record i may have a security binding to two values (such as a random value or the current time) x _i and x _i+1 : notationally expressed as SIG(xi _, x _i+1 , Ei, AI). Then, two consecutive log records may always share a value of x: for example, records i and i+1 will share x _i+1 . However, if the log record is deleted, this will no longer work (since an adversary cannot modify a signed log record without detection unless it knows the secret key that signed it). For example, if record number 100 is deleted, the database will contain SIG(x ₉₉ , x ₁₀₀ , E99, AI) and SIG(x ₁₀₁ , x ₁₀₂ , E101 , AI), and it will be noted that they do not share a common x value. Such associated information may take other forms: indeed, a log record may be associated with multiple other log records. In particular, this may be achieved using polynomials to generate associated information (eg, each of two or more log records may contain the result of evaluating the same polynomial with different inputs). Such association information can also utilize hash chains: for example, starting with the value y ₁ , let y ₂ =H(y ₁ ), y ₃ =H(y ₂ ), ... etc., and then let y _i and Ei Security Binding: For example, the i-th log record can be denoted notationally as SIG(y _i , Ei, AI). Then, successive log records i and i+1 may have associated values y _i and y _i+1 , appropriately y _i+1 =H(y _i ). However, if an adversary deletes the log record, this may no longer be valid and the deletion can be detected. For example, if record 100 is deleted, the database will contain SIG( _y99 , E99, AI) and SIG( _y101 , E1101, AI) (which, as stated earlier, cannot be modified by an adversary without breaking the digital signature) . Then, deletions can be detected because H(y ₁₀₁ ) will not match y ₉₉ . Using multiple hash chains, perhaps using non-sequential records and bi-directional, can also provide such associated information.

In another embodiment, each log record may contain an indication of some or all previous or even subsequent events, thus making the log not only detectable for deletion, but rebuildable when deleted. A rebuildable log system can be built by using the following schemes: (1) an authentication scheme (such as a digital signature scheme); (2) a reconstruction information generation scheme; and (3) a reconstruction scheme. Given a log event E (part of a series of past and/or future events), the reconstruction information generation scheme is used to generate reconstruction information RI, which can then be securely bound with other log records by means of the authentication scheme. The reconstruction information generation scheme ensures that, even if the log record corresponding to event i is lost, the other log records contain enough information about E to allow reconstruction of E from the RI present in the other log records. For example, the i+1th record may contain information about all or part of the previous i events, generated by the reconstruction information generation scheme. Thus, if an adversary somehow succeeds in erasing the jth log record from the database, information Ej about the jth event will be revealed in one or more subsequent records such that even in the absence of the jth log record Next, the information Ej can also be reconstructed using the reconstruction scheme. Thus, temporary access to the database is not enough for the enemy: he has to monitor the database "always" and delete several log records to prevent information about the jth event from being revealed. The selection of which events to include in a log record may be done in a random fashion by the reconstruction information generation scheme, making it difficult for an adversary to predict when information about a particular event will be revealed in subsequent logs. Preferably, the rebuildable logging system can also be deletion detectable and indisputable. the

It should also be noted that the reconstructed information about event j included in another log record need not be direct information. It may consist of a partial record j, or its hash value h _j (in particular, computed by the reconstruction information generation scheme via a one-way/collision-proof hash function), or its digital signature, or any other indication. Specifically, if a one-way collision-resistant hash function H is used, it is possible to uncontroversially recover information about the j-th event from a log record i containing h _j : notationally, if the i-th record is signed, the corresponding An uncontested log may take the form SIG(h _j , Ei, AI). For example, if a particular user is suspected of entering a particular door at a particular time, it can be tested whether the value _hj matches the hash H(Ej) of the log record Ej that has been created in response to that event. This is indisputable because of the anti-collision properties of H: it is virtually impossible to come up with a record E'j different from Ej such that H(E'j)=H(Ej).

Log records Ej may be created in a way that should make it easy to guess (and thus verify) what log records should be for a particular event (eg, by using a standardized format for log records, using approximate time intervals, etc.). One-way hashes are particularly useful because of their small size: many or even all previous log records can be hashed for inclusion in subsequent records. For example, record i+1 may include h ₁ =H(E ₁ ), h ₂ =H(E ₂ ), . . . , h _i =H(E _i ). Alternatively, (partial) hashes can be nested, thereby reducing the amount of space required. For example, if all hashes are nested, the second log record should include h ₁ =H(E ₁ ), the third log record should include h ₂ =H(E ₂ ,h ₁ ) . . . . Thus, if log record i is created or viewed by i−1 and log record i+1, log record i can be created without dispute. This system can be improved by encrypting (eg using a key known only to the database) the (part of) information in the log records, so that the enemy cannot see which information he has to compromise to jeopardize the reconstructability of a particular event. In fact, once a log is cryptographically protected, such an encrypted log (preferably a non-controversial encrypted log) can be sent to another (secondary) database without any loss of secrets. This makes it harder for the enemy to delete: now he has to go into two or more databases to forge logs.

Reconstructable logging can also be achieved through the use of error-correcting code. Specifically, this can be done by generating multiple components ("parts") of each log record and sending them separately (perhaps with other log records) in such a way that when enough parts have been received, the log record Can be reconstructed by a reconstruction scheme, which may invoke decoding algorithms for error-correcting codes. These parts may be spread randomly or pseudo-randomly, thus making it difficult for an adversary to delete enough parts to prevent reconstruction of the log record when enough parts actually arrive. the

Event logs (whether created by cards or doors or a combination of cards and doors) can be carried by cards to facilitate their collection. When a card reaches a communicating door or communicates with a central server or otherwise is able to communicate with a central database, it can send the log it keeps there. This can be accomplished similarly to the propagation of the HRA, except that the HRA can be sent to the card from a central point, while the log can be sent from the card to the central point. Therefore, all methods of propagating HRA are applied to the collection of event logs. Specifically, the method of propagating HRAs can be transformed into a method of collecting event logs by: (1) replacing senders with receivers, and vice versa; (2) replacing HRAs with log records. the

In particular, card C1 may collect an event log of events not related to C1, such as an access by another card C2 or a failure of door D. Furthermore, the event log of one door D1 may be kept (perhaps temporarily) on another door D2 (perhaps carried there by card C1). Then, when another card C2 communicates with D2, it can receive portions of these log records and then communicate them to another door or to a central location. This wide spread ensures that event logs reach the central point more quickly. (Furthermore, some gates, although not fully connected to the central database, may have connections between each other. Thus, such gates may similarly exchange available event logs. If the cards have the ability to communicate with each other - for example when in proximity - they may also exchange information about The information of the event logs they hold. In such a collection process undisputed logs are advantageous because they do not have to be transmitted on a secure channel, as they cannot be forged. Therefore, they are not dependent on cards or cards and doors The security of the connection between. Removing the detectable log provides an additional advantage, if some log records are not collected (perhaps because some cards never reach the connected door), it ensures that the fact can be detected. Reconstructable Logging may allow reconstruction of log records in the event that some log records do not reach the central database (again, perhaps because some cards never reached connected gates).

In some cases, all event logs can be saved and propagated in this manner. Otherwise, it is useful to employ some optimizations. One optimization approach is to have event logs provided with priority information indicating the relative importance of notifying a central authority about a particular event. Some log entries may be more urgent than others: for example, if a door is maintained in an open or closed position, if unauthorized access is attempted, or if unusual access patterns are detected. To expedite the delivery of such important information to where it can be acted upon, information in the access log may be tagged with a flag indicating its importance (or its importance may be inferred from its own information). For example, some log records may be marked as "urgent" while others may be marked as "routine". Or they may be marked by a number or code word indicating their degree of importance (priority as exact or as close as possible). For example, higher priority information may be given more cards and/or doors to increase the likelihood that it will reach its destination faster or more safely. Likewise, a card or door, when receiving a high priority message, can make room for the high priority message by deleting the low priority message from its memory. Likewise, a gate may decide to give high priority information to every card passing through it, while low priority information is given to only a few cards or may wait until the gate is connected. the

Alternatively or in addition to the above techniques, cards may be selected to save certain logging to some extent, including random saving, or gates may provide logging to a certain number of cards (e.g., the first k of the gate "encounters" Card). The use of such propagation techniques can greatly reduce the likelihood that important records in the event log will not reach the central location where they are acted upon. In particular, it can be used as an effective countermeasure against "jamming" attacks that attempt to prevent damaged doors from communicating their distress messages. The actual method of exchanging logs between the card and the door may vary. In the case of few records, it is most efficient to swap and compare all known records. In other cases, more complex algorithms for finding and reconciling differences may be used. the

It is useful to detail some sample ways in which event logs can be collected. Next, "Administrative Authority" A includes some central point or database where event logs are collected. the

Sequence 1 (directly from gate to governing body) :

1. A connected gate D creates an indisputable log record E in response to an event. the

2. E is transmitted to management institution A via wired or wireless communication. the

3. A verifies the reliability of E, and saves E if the verification is successful. the

Sequence 2 (from door to user card to authority) :

1. Gate D creates an uncontested log record E in response to an event. the

2. The card C of the user U presented for access D receives and stores E (except for communications related to the access). The card may or may not verify the authenticity of E. the

3. When U is off duty and presents his card to A at the end of the working day, E is transferred to A by the card. the

4. A verifies the reliability of E, and saves E if the verification is successful. the

Sequence 3 (from door to user card to another (connected) door to authority) :

1. Gate D creates an uncontested log record E in response to an event. the

2. The card C of the user U presented for access D receives and stores E (except for communications related to the access). The card may or may not verify the authenticity of E. the

3. U then presents his card C for access to another (connected) door D'. D', receives E from C in addition to validating credentials and authorizing access when appropriate. D' may or may not verify the reliability of E. the

4. E is transmitted from D' to management agency A via wired or wireless communication. the

5. A verifies the reliability of E, and saves E if the verification is successful. the

Protected areas may be defined by walls and physical doors, such as doors through which people can enter, or doors of containers, security doors, doors of vehicles, etc. Protected areas can also be defined by virtual doors and walls. For example, an area may be guarded by detectors which may sense intrusion and which may sound an alarm or send another signal if authorization is not provided. Such an alarm system is an example of a virtual door: in an airport, often entering a gate area through an exit roadway will trigger such an alarm even though no physical door or wall has been violated. Another example of a virtual gate is a toll booth: Although many toll booths do not contain physical barriers or gates, a particular car may or may not be authorized to pass through a toll booth. For example, such authorization may rely on the validity of the car's electronic toll payment token. Another example is a restricted traffic area. For example, to enter the center of a particular city or a road leading to a nuclear facility, a military barracks, or another sensitive area, vehicles must have appropriate authorizations for billing, security, or congestion control purposes. the

Furthermore, protection is not only required for areas, but also for equipment, such as aircraft engines or military equipment. For example, it must be ensured that only authorized individuals start the engines of airplanes or trucks carrying hazardous materials. the

There are many ways to use credentials/proofs for access control. It should be noted that for the approaches disclosed herein, the term "day" should be understood as a general time period in a series of time periods, and "morning" means the beginning of a time period. the

In this application, "gate" shall be considered to include all types of entrances (eg, physical and/or virtual), access control systems/devices, and surveillance systems/devices. In particular, they include key mechanisms for starting engines and controls (specifically, so that the present invention can be used to ensure that only current authorized users can start an aircraft, operate a bulldozer, or access and control various important and/or dangerous items, equipment and components). Consistent with this convention, we refer to "entry" as the access (either physical or virtual) desired by an authorized person. the

Similarly, in particular but without loss of generality, a card may be understood as any access device of a user. It should be appreciated that the concept of a card is broad enough to include mobile phones, PDAs, or other wireless and/or advanced devices, and that a card may include or work in conjunction with other security measures, such as PINs, passwords, and biometrics, although these Parts of the measure may be "located" in the card holder's brain or body rather than in the card itself. the

Furthermore, the term "user" (often referred to as "he" or "she") may be interpreted broadly to include not only users and persons, but also devices, entities (and collections of users, devices and entities), including but not limited to user card. the

The systems described herein can be implemented using any suitable combination of hardware and software, including but not limited to software stored on a computer-readable medium that can be accessed by one or more processors. Furthermore, techniques for encryption, authentication, etc. may be appropriately combined and used interchangeably. In that regard, each of the following U.S. patents and applications are hereby incorporated by reference:

U.S. Provisional Patent Application 60/004,796, filed October 2, 1995;

U.S. Provisional Patent Application 60/006,038, filed October 24, 1995;

U.S. Provisional Patent Application 60/006,143, filed November 2, 1995;

U.S. Provisional Patent Application 60/024,786, filed September 10, 1996;

U.S. Provisional Patent Application 60/025,128 filed August 29, 1996;

U.S. Provisional Patent Application 60/033,415, filed December 18, 1996;

U.S. Provisional Patent Application 60/035,119, filed February 3, 1997;

U.S. Provisional Patent Application 60/277,244, filed March 20, 2001;

U.S. Provisional Patent Application 60/300,621 filed June 25, 2001;

U.S. Provisional Patent Application 60/344,245 filed December 27, 2001;

U.S. Provisional Patent Application 60/370,867, filed April 8, 2002;

U.S. Provisional Patent Application 60/372,951 filed April 16, 2002;

U.S. Provisional Patent Application 60/373,218 filed April 17, 2002;

U.S. Provisional Patent Application 60/374,861 filed April 23, 2002;

U.S. Provisional Patent Application 60/420,795, filed October 23, 2002;

U.S. Provisional Patent Application 60/421,197, filed October 25, 2002;

U.S. Provisional Patent Application 60/421,756, filed October 28, 2002;

U.S. Provisional Patent Application 60/422,416, filed October 30, 2002;

U.S. Provisional Patent Application 60/427,504, filed November 19, 2002;

U.S. Provisional Patent Application 60/443,407, filed January 29, 2003;

U.S. Provisional Patent Application 60/446,149 filed February 10, 2003;

U.S. Provisional Patent Application 60/482,179 filed June 24, 2003;

U.S. Provisional Patent Application 60/488,645, filed July 18, 2003;

U.S. Provisional Patent Application 60/505,640, filed September 24, 2003;

U.S. Patent Application 08/715,712 filed September 19, 1996;

U.S. Patent Application 08/741,601 filed November 1, 1996;

U.S. Patent Application 08/756,720 filed November 26, 1996;

U.S. Patent Application 08/804,868 filed February 24, 1997;

U.S. Patent Application 08/804,869 filed February 24, 1997;

U.S. Patent Application 08/872,900 filed June 11, 1997;

U.S. Patent Application 08/906,464, filed August 5, 1997;

U.S. Patent Application 09/915,180 filed July 25, 2001;

U.S. Patent Application 10/103,541 filed March 20, 2002;

U.S. Patent Application 10/244,695 filed September 16, 2002;

U.S. Patent Application 10/409,638 filed April 8, 2003;

U.S. Patent Application 10/876,275 filed June 24, 2004;

US Patent 5,604,804;

US Patent 5,666,416;

US Patent 5,717,757;

US Patent 5,717,758;

US Patent 5,793,868;

US Patent 5,960,083;

US Patent 6,097,811; and

US Patent 6,487,658. the

While the invention has been disclosed in connection with a number of embodiments, modifications thereof will be readily apparent to those skilled in the art. Accordingly, the spirit and scope of the present invention are indicated by the following claims. the

Claims (45)

1. confirm the method for visit, comprising:

Confirm whether voucher/prove shows that visit is allowed to wherein said voucher/prove to comprise voucher and proof;

Confirm and said voucher/prove whether the specific other data that are associated are received that wherein said specific other data are independent of voucher/prove and are to be transferred to the data that accessing points, the mandate of prevention accessing points have the user capture of the voucher of cancellation/prove; And

Determine whether according to the said voucher that receives/prove and said specific other data denied access; If wherein said voucher/prove not show that visit has been allowed to then denied access; If directly showing to call off a visit, the secret value that reaching wherein said specific other data provides weighs then denied access; Wherein said secret value is carried out one-way function, and whether the result who wherein said secret value fill order is obtained to function through inspection matees with the value that belongs to voucher/prove and in the said result that the secret value fill order is obtained to function of accessing points local verification.

2. according to the process of claim 1 wherein voucher/prove one.

3. according to the process of claim 1 wherein voucher/prove divided portion.

4. according to the method for claim 3, wherein produce voucher and other management entity generation proof by first management entity.

5. according to the method for claim 4, wherein first management entity also produces proof.

6. according to the method for claim 4, wherein first management entity does not produce proof.

7. according to the process of claim 1 wherein voucher corresponding to the digital certificate that comprises final value, final value is the result who one-way function is applied to first proof.

8. according to the method for claim 7, wherein each proves the result who one-way function is applied to one of following proof.

9. according to the method for claim 7, wherein digital certificate comprises the identifier of electronic equipment.

10. according to the process of claim 1 wherein that voucher comprises final value, final value is for being applied to one-way function the result of first proof.

11. according to the method for claim 10, wherein each proves the result who one-way function is applied to one of following proof.

12. according to the process of claim 1 wherein that voucher comprises that the user asks the identifier of visiting.

13. according to the process of claim 1 wherein voucher/prove to comprise digital signature.

14. according to the process of claim 1 wherein that visit is to the visit by wall and door enclosed areas.

15. the method according to claim 14 also comprises:

Door lock is provided, and wherein whether door lock is rejected according to visit and opens.

16. the method according to claim 1 also comprises:

The card reader of reception voucher/prove is provided.

17. according to the method for claim 16, wherein voucher/prove is provided on the smart card that the user appears.

18. according to the process of claim 1 wherein voucher/the prove password that comprises that the user inputs.

19. according to the process of claim 1 wherein voucher/prove to comprise user biometrics information.

20. according to the process of claim 1 wherein voucher/prove to comprise handwritten signature.

21. according to the secret value that the process of claim 1 wherein that voucher/prove is included in to be provided on the card that the user holds.

22. the back is expired at the fixed time according to the process of claim 1 wherein voucher/prove.

23. according to the process of claim 1 wherein that other data are by digital signing.

24. according to the process of claim 1 wherein that other data are the message of binding with voucher/prove.

25. according to the method for claim 24, the specific voucher of message identification/prove and comprise specific credential/the prove indication that whether has been cancelled wherein.

26. according to the method for claim 25, wherein indication is an empty string.

27. according to the process of claim 1 wherein that other data comprise the date.

28. according to the process of claim 1 wherein that other data are to comprise about the information of specific credential/prove and comprise the message about the information of one or more other vouchers/prove.

29. the method according to claim 1 also comprises:

Preserve other data.

30. according to the method for claim 29, wherein other data comprise expiration time, it shows how long other data will be preserved.

31. according to the method for claim 30, expiration time expiring wherein corresponding to specific credential/prove.

32. the method according to claim 1 also comprises:

Other data are preserved the predetermined long time.

33. according to the method for claim 32, wherein voucher/prove all expires after at the fixed time.

34. according to the process of claim 1 wherein that other data use smart card provides.

35. according to the method for claim 34, wherein smart card is appeared by the user who attempts access region.

36., wherein use wall and at least one door to limit to the visit in zone according to the method for claim 35.

37. according to the method for claim 35, wherein other data are used to be different from the user's who attempts to visit user.

38. the method according to claim 1 also comprises:

Communication link is provided; And

Use the other data of communication link transmission.

39. according to the method for claim 38, wherein communication link is provided with other data by smart card.

40. according to the method for claim 39, wherein smart card requirement and communication link periodic communication are to remain valid.

41. according to the method for claim 39, wherein smart card is provided with other data by another smart card.

42. according to the method for claim 39, wherein other data are offered group's smart card selectively.

43. the method according to claim 39 also comprises:

Provide priority to other data.

44., wherein other data basedly offer the priority of other data and offered group's smart card selectively according to the method for claim 43.

45. according to the method for claim 39, wherein other data are offered group's smart card at random.

Images