ES2367435T3 - ACCESS CONTROL TO A ZONE. - Google Patents

Abstract

An access control method, comprising: the use of an access barrier provided with a controller that allows selective access; at least one administration entity that generates identity credentials and identity proofs, where the credentials include a final value and a date, where the final value is obtained by applying, several times, a unidirectional function to a random value, each being One of the tests associated with a particular time interval, where different tests are obtained by applying the unidirectional function to the random value, in a different number of times, where a test to be presented to the controller at a given time, is the result of applying the unidirectional function to a test to be presented to the controller in the future; the controller receives the identity card of at least one of the tests corresponding to the access attempt made by a user; In response to the attempt of access by the user, the controller determines if the access is currently authorized by applying the unidirectional function to at least one of the tests, a certain number of times and comparing the result with the final value, corresponding the number from times to a period of time elapsed since the date associated with the credentials and if the access is currently authorized, the controller authorizes the access.

Description

BACKGROUND OF THE INVENTION

TECHNICAL FIELD

This patent application refers to the field of physical access control and more particularly, to the field of physical access control using processor-driven locks and related data.

DESCRIPTION OF THE RELATED TECHNIQUE

Ensuring that only authorized persons can access protected areas and devices under protection can be important in many cases, such as in the case of access to an airport, military installation, office building, etc. Traditional doors and walls can be used to protect sensitive areas, but doors with traditional locks and keys can take up excessive space to manage in an installation with numerous users. For example, once an employee is fired, it can be difficult to recover the physical keys that the previous employee had issued while hired. In addition, it may be dangerous for copies of these keys to be made and never returned in return.

Smart doors provide access control. In some cases, a smart door may be provided with a keypad through which a user enters their PIN number or password. The keypad can have a connected memory and / or an elementary processor in which a list of valid PIN numbers / passwords can be stored. In this way, a door can check if the PIN number, currently entered, belongs, or not, to the list valid at that time. If so, the door can be opened. Otherwise, the door may remain locked. Of course, instead of relying solely on traditional keys or simple keyboards, a more modern smart door can work with cards (such as smart cards and magnetic stripe cards) or contactless devices (eg, PDAs, mobile phones , etc.). Such cards or devices may be used in addition to, or instead of, traditional keys or electronic keyboards. Such magnetic stripe cards, smart cards or contactless devices, designed to be transported by users, may have the ability to store information transmitted to the doors. More advanced cards may also have the ability to calculate and communicate. The corresponding devices at the doors may be able to read information from the cards and perhaps establish interactive protocols with the cards, communicate with computers, etc.

One aspect of a door is its level of connectivity. A fully connected door is a door that is, at all times, connected to a database (or other computer system). For example, the database may contain information about currently valid cards, users, PIN numbers, etc. In some cases, to prevent an intruder from modifying the information that flows to the door, said connection is secured (e.g., by installing the connecting wire, from the door to the database, inside a steel tube). On the other hand, a completely disconnected door does not communicate with the outside of its immediate proximity. Between these two extremes, there may be doors that have intermittent connectivity (eg, a “mobile” door connected wirelessly, which can communicate with the outside only when within the range of a ground station, such as the door of an aircraft or of a land transport vehicle).

Traditional access control mechanisms have numerous drawbacks. Fully connected doors can be very expensive. The cost of installing a secure pipe, to a distant smart door, can greatly exceed the cost of the smart door itself. Cryptographic protection of a connection thread may be cheaper, but it still has its own costs (e.g., protection and management of cryptographic keys). In addition, cryptography without steel conduits and security guards cannot prevent the cutting of a connecting wire, in which case the door that is no longer connected can be forced to choose between two extreme alternatives: namely, always remain closed or always open , none of which are desirable conditions. In any case, the complete connection of a door is usually not a viable option. (For example, the door of a cargo container, below sea level, in the middle of the Atlantic Ocean is, for all practical purposes, a completely disconnected door).

Smart disconnected doors can be cheaper than connected doors. However, traditional methods for smart doors have their own problem. Consider, for example, a disconnected smart door capable of recognizing a PIN number. A fired employee may no longer be authorized to pass through said door, but if he still remembers his own PIN, he may not have difficulty opening said elementary smart door. Therefore, it would be necessary to "deprogram" the PIN numbers of dismissed employees, which is difficult for disconnected doors. In fact, such a procedure can be very space-consuming and expensive: an airport facility can have hundreds of doors and the transfer of a special team of employees to deprogram all of those doors, provided that an employee leaves, or is fired, It may also be unfeasible.

The problem of the invention is to increase a level of security without incurring its additional costs.

This problem is solved by the method according to claim 1.

Access control may include providing a barrier to access, including a controller that allows selective access, at least one administration entity that generates credentials / identity proofs where no valid proof is determinable with the sole presentation of credentials and Values for expired tests, the controller receiving credentials / identity tests, determining the controller whether access is currently authorized or not and, if access is currently authorized, the controller will allow access. The credentials / proof of identity can constitute a single part or they can be in separate parts. There may be a first administration entity that generates the credentials and other administration entities that generate proof of identity. The first administration entity may also generate proof of identity or the first administration entity may not generate evidence. The credentials may correspond to a digital certificate that includes a final value that is a result of applying a unidirectional function to a first of the tests. Each of the tests can be a result of applying a unidirectional function to a future one of the tests. The digital certificate may include an identifier for the electronic device. Credentials may include a final value that is a result of applying a unidirectional function to a first of the tests. Each of the tests can be a result of applying a unidirectional function to a future one of the tests. Credentials can include an identifier for a user requesting access. Credentials / proof of identity may include a digital signature. The access barrier may include walls and a door. Access control may also include providing a door lock coupled to the controller, wherein the controller that allows access includes the controller that drives the door lock to allow the opening of said door. Access control may also include providing a reader coupled to the controller, where the controller receives identity credentials / proofs from the reader. The credentials / proof of identity can be provided on a smart card presented by a user. Access control may also include providing an external connection to the controller. The external connection can be intermittent. The controller can receive at least a portion of the credentials / proof of identity using the external connection or the controller can receive all of the credentials / proof of identity using the external connection. Access control may also include providing a reader coupled to the controller, where the controller receives a remaining portion of the identity credentials / proofs from the reader. Credentials / proof of identity may include a password entered by a user. The credentials / proof of identity may include a biometric information of the user. Credentials / proof of identity may include a handwritten signature. Credentials / proofs may include a secret value provided on a card held by a user. Credentials / proof of identity may expire at a predetermined time.

In addition, an entity that controls the access of a plurality of users to at least one disconnected door may comprise matching the plurality of users with a group, for each time interval d of a sequence of dates, which has a authorization to present a digital signature SIGUDd, which indicates that the members of the group can access the door during the time interval d, which makes at least one of the members of the group receive SIGUDd during the time interval d for presentation to the door in order to pass through it, the at least one member of the group having to submit the NEXT to the door D and making the door be after verifying that: (i) SIGUDd is a digital signature of the authority indicating that group members can access the door in the time interval dy (ii) that the current time is within the time interval d. The at least one member of the group can have a user card and the door can have a card reader attached to an electromechanical lock and the at least one member of the group can receive the NEXT memorizing it in the user card and can present the NEXT to the door being the user's card read by the card reader. The authority may have SIGUDd received by the at least one member of the group during the time interval d by registering SIGUDd in a database accessible by the at least one member of the group. NEXT can be a public key signature and the door can store the public key of the authority. The door can also check the identity information about the at least one member of the group. The identity information about the at least one member of the group may include at least one of: a PIN number and the response to a so-called operational challenge of the door.

In addition, physical access control may also include the assignment of credentials in real time to a group of users, the review of credentials in real time, where real-time credentials comprise a first part that is fixed and a second part which is modified on a periodic basis, where the second part provides proof that the credentials in real time are in progress, checking the validity of the credentials in real time by performing an operation in the first part and comparing the result with the second part and allowing physical access to group members only if the real-time credentials are verified as valid. The first part can be digitally signed by an authority. The authority can provide the second part. The second part may be provided by an entity other than the authority. Real-time credentials can be provided on a smart card. Group members can obtain the second part of the credentials in real time at a first location. Group members may be allowed access to a second location that is different and separate from the first. At least a portion of the first part of the credentials in real time may represent an identification summary function, called hash, unidirectional applied, several times, to a portion of the second part of the credentials in real time. The plurality of times may correspond to an amount of time elapsed since the first part of the credentials were issued in real time. The physical access control may also include access control through a door.

In addition, the determination of access may comprise the determination of whether particular credentials / proofs of identity indicate that access is allowed, the determination of whether there is additional data associated with the credentials / proof of identity, where the additional data is separated from credentials / proof of identity and, if the credentials / proof of identity indicate that access is allowed and if there is additional data associated with the credentials / proof of identity, then decide whether or not to deny access based on the information provided by additional data. The credentials / tests can be in one part or in separate parts. There may be a first administration entity that generates the credentials and other administration entities that generate evidence. The first administration entity may also generate tests or may not generate tests. The credentials may correspond to a digital certificate that includes a final value, which is a result of applying a unidirectional function to a first of the tests. Each of the tests can be a result of applying a unidirectional function to a future one among the tests. The digital certificate may comprise an identifier for the electronic device. Credentials may include a final value that is a result of applying a unidirectional function to a first of the tests. Each of the tests can be a result of applying a unidirectional function to a future one of the tests. Credentials may comprise an identifier for a user requesting access. Credentials / proofs may include a digital signature.

Access can be access to an area closed by walls and doors. The determination of access may include providing a door lock, where the lock is operated depending on whether the access is denied or is not. The determination of access may also include providing a reader who receives the credentials / proof of identity. Such credentials / proofs can be provided on a smart card presented by a user. Credentials / proofs may include a password entered by a user. The credentials / proofs may also include a user's biometric information as well as a handwritten signature. Credentials / proofs may include a secret value provided on a card held by a user. Credentials / tests may expire at a predetermined time. Additional data may have a digital signature and may be a message that is linked to credentials / evidence. The message may identify the particular credentials / evidence in including an indication of whether such particular credentials / evidence has been revoked or not. The indication can be an empty string. Additional data may include a date. In addition, the additional data may be a message that contains information about the particular credentials / tests and that contains information about one or more of among other credentials / tests. The determination of access may also include the storage of additional data. Additional data may include an expiration time that indicates the period of time in which additional data is to be stored. The expiration time may correspond to an expiration of the particular credentials / tests. The determination of access may also include the storage of additional data for a predetermined period of time. Credentials / tests can expire all after a predetermined time. Additional data can be provided using a smart card. The smart card can be presented by a user who tries to access an area. Access to the area can be restricted using walls and at least one door. Additional data may be for a user other than the user trying to gain access. The determination of access may further comprise providing a communication link and transmitting additional data using said communication link. The communication link may be provided with additional data by means of a smart card. The smart card may require periodic communication with the communications link in order to remain operational. The smart card can be provided with additional data through another smart card. Additional data can be provided, selectively, to a subset of smart cards. The determination of access may also include providing a level of priority to additional data. Additional data can be provided, selectively, to a subset of smart cards depending on the level of priority provided to the additional data. Additional data can be provided, randomly, to a subset of smart cards.

In addition, the issuance and dissemination of data on a credential may include the provision of an entity that issues authenticated data indicating that the credential has been canceled, which causes said authenticated data to be stored on a first card of a first user, using the first card to transmit the authenticated data to a first door, said first door having to store information about the authenticated data, and said first door depending on the information about the authenticated data to deny access to the credential. Authenticated data can be authenticated by a digital signature and the first door can verify said digital signature. The digital signature can be a digital public key signature. The public key for the digital signature may be associated with the credential. The digital signature can be a private key digital signature. The credential and the first card can both belong to the first user. The credential can be stored on a second card other than the first card and the first door can be based on information about the authenticated data by retrieving said information from the storage medium. The credential can belong to a second user different from the first user. Authenticated data can be stored first on at least one other card than the first card and authenticated data can be transmitted from the at least one other card to the first card. Authenticated data can be transmitted from the at least one other card to the first card by first transmitting to at least one other door other than the first door. The entity may have the authenticated data stored on the first card by first having the authenticated data stored on a responder and then having the first card obtain the authenticated data from the responder. The responder may be unprotected. The first door can receive information about the authenticated data from the first card by the authenticated data that is first transferred to at least one other card than the first card. The at least one other different card can receive information about the authenticated data from the first card by means of the authenticated data that is first transmitted to at least one other door different from the first door. The first door can be completely disconnected or can be intermittently connected.

In addition, a first door can receive authenticated data on a credential of a first user, including the process of receiving the authenticated data from a first card belonging to a second user different from the first user, storing information about the authenticated data, the receipt of the credential and the dependence of the information stored on the authenticated data to deny access to the credential. Authenticated data can be authenticated by a digital signature and the first door verifies the digital signature. The digital signature can a digital public key signature. The public key for the digital signature may be associated with the credential. The digital signature can be a private key digital signature. Authenticated data can be stored on the first card by first storing it on at least one other card and then transmitting it from the at least one other card to the first card. Authenticated data can be transmitted from the at least one other card to the first card by first transmitting at least one different door from the first door. Authenticated data can be memorized on the first card by storing them first in a responder and then obtained by the first card from the responder. The responder may be unprotected. The first door can receive information about the authenticated data from the first card by means of the authenticated data that is first transmitted to at least one other card other than the first card. The at least one other card can receive information about the authenticated data from the first card by first transmitting the authenticated data to at least one other door other than the first door. The first door can be completely disconnected or can be intermittently connected.

In addition, assistance in an immediate revocation of access may include receiving authenticated data on a credential, storing information about the authenticated data on a first card and making a first door receive information about the authenticated data. Authenticated data can be authenticated by a digital signature. The digital signature can be a digital public key signature. The public key for the digital signature may be associated with the credential. The digital signature can be a private key digital signature. The card and card can both belong to a first user. The first card can be rendered unusable for access if the first card stops receiving a pre-specified type of signal in a pre-specified amount of time. The credential may belong to another user other than the first user. Authenticated data can be received by the first card by memorizing first, on at least one other card different from the first card, and then transmitted from the at least one other card to the first card. Authenticated data can be transmitted from the at least one other card to the first card by first transmitting to at least one other door other than the first door. The first card can obtain the authenticated data from an responder. The responder may be unprotected. The first card can cause the first door to receive information about the authenticated data by first transmitting the authenticated data to at least one other card other than the first card. The first card may cause the at least one other card to receive information about the authenticated data by first transmitting the authenticated data to at least one other door other than the first door. The first door can be completely disconnected or can be intermittently connected. The first card may occasionally delete the information stored on the authenticated data from the storage medium. The credential can have an expiration date and the first card can delete the information stored on the authenticated data from the storage medium once the credential is expired. The expiration date of the credential can be deducted from the information specified within the credential.

In addition to the present invention, the record of operational events associated with access to a zone may include the record of an operational event associated with access to the zone to provide an event log and authentication of at least the log of events for Provide an authenticated record. The recording of an operational event may include the recording of an event time. The registration of an operational event may include the registration of an event type. The event can be an attempt to access the area. The registration of an event may include the registration of credentials / tests used in connection with the attempt to access the area. The registration of an event may include the recording of a result of the attempt. The registration of an event may include the registration of the existence of data other than credentials / evidence indicating that access should be denied. The registration of an event may include the registration of additional data related to the area. Registration authentication may include the digital signature of said registration. Authentication of at least the event log may include authentication of the event log and authentication of other event logs to provide a single authenticated log. The unique authenticated registration can be stored on a card. Authenticated registration can be stored on a card. The card may have another authenticated record stored. The other authenticated record can be provided by the card in relation to the card used to access the area. Access can be denied if the other authenticated record cannot be verified. A controller can be provided in relation to access to the zone and where the controller performs authentication, in addition, to the other authenticated record. The other authenticated record can be authenticated using a digital certificate. The operational event log may also include a user presenting a card to try to access the area. The event log may also include the card that performs the authentication, in addition to the authenticated record in relation to the user trying to access the area. A controller may be provided in connection with access to the zone and where the controller and the card perform a joint authentication of the authenticated registration. The operational event log may include providing correlation generation data indicating the content of the authenticated log. The correlation generation data may be linked to the authenticated record. The correlation generation data can be linked to the authenticated record and the resulting link can also be authenticated. The resulting link can have a digital signature. The correlation generation data can be a sequence of numbers and in particular, one of the numbers can be assigned to the operational event. The event log may also comprise the authentication of a link of the particular number and the event. Link authentication can include the digital signature of the link. Authentication can also include a form of the link hashing function and then the digital signature of its result. The correlation generation data for the event may include information that identifies another event. The other event may be a previous event. The other event may also be a future event. The event log may further comprise the association of a first and a second random value for the event, the association of at least one of the first and second random values with the other event and the link in at least one of the first and Second values for the other event. The provision of correlation generation data may include the use of a polynomial to generate the correlation information. The provision of correlation generation data may further comprise the use of a hash chain of functions to generate the correlation information. The correlation generation data may include information about a plurality of other events. The correlation generation data may include error correction codes. The event log may also include the dissemination of the authenticated record. The dissemination of the authenticated record may include providing the authenticated record on cards presented by users attempting to access the area. The area can be defined by walls and a door.

In addition, at least one administration entity can control access to an electronic device by the at least one administration entity that generates credentials and a plurality of corresponding tests for the electronic device, where no valid test is determined only by giving the credentials and values for expired tests, with the receipt by the electronic device of the credentials, if access is authorized at a particular time, the electronic device that receives a proof corresponding to that particular moment and the electronic device that confirms the test using the credentials The at least one administration entity can generate tests after generating the credentials. A single administration entity can generate the credentials and generate the evidence. There may be a first administration entity that generates the credentials and other administration entities that generate evidence. The first administration entity may also generate tests or may not. The credentials can be a digital certificate that includes a final value, which is a result of applying a unidirectional function to a first of the tests. Each of the tests can be a result of applying a unidirectional function to a future one of the tests. The digital certificate may include an identifier for the electronic device. Credentials may include a final value, which is a result of applying a unidirectional function to a first of the tests. Each of the tests can be a result of applying a unidirectional function to a future one of the tests. Credentials may include an identifier for the electronic device. The electronic device can be a computer, which can be initialized only if access is authorized. The electronic device can be a disk drive. At least one administration entity, which controls access to an electronic device, may include the provision of evidence using at least one evidence distribution entity separate from the at least one administrative entity. There may be a single test distribution entity or a plurality of test distribution entities. At least one administration entity, which controls access to an electronic device, may include the provision of evidence using a connection to the electronic device. The connection can be through the Internet. At least some of the tests can be stored, locally, on the electronic device. At least one administration entity, which controls access to an electronic device may include, if the test corresponding to the time it is not available locally, the electronic device requests the tests through an external connection. Each of the tests may be associated with a particular time interval. After a particular time interval associated with a particular one of the tests with satisfactory result has elapsed, the electronic device may receive a new test. Said time interval may be one day.

In addition, an electronic device can control its access by receiving credentials and at least one of a plurality of corresponding tests for the electronic device, where no valid test is subject to determination only by providing the credentials and values for expired tests and verifying that at least One of a plurality of tests is using credentials. The credentials can be a digital certificate that includes a final value that is a result of applying a unidirectional function to a first of the tests. Each of the tests can be a result of applying a unidirectional function to a future one of the tests. The digital certificate may include an identifier for the electronic device. Credentials may include a final value that is a result of applying a unidirectional function to a first of the tests. Each of the tests can be a result of applying a unidirectional function to a future one of the tests. Credentials may include an identifier for the electronic device. The electronic device can be a computer. An electronic device that controls your access can also comprise the initialization of the computer only if access is authorized. The electronic device can be a disk drive. An electronic device that controls your access may further comprise obtaining evidence using a connection to the electronic device. The connection can be through the Internet. At least some of the tests can be stored locally on the electronic device. An electronic device that controls your access may further comprise, if the current test is not available locally, the electronic device requesting the tests through an external connection. Each of the tests can be associated for a particular time interval. After a particular time interval has elapsed, associated with a particular one of the satisfactory result tests, the electronic device may receive a new test. Said time interval may be one day.

In addition, control of access to an electronic device may include the provision of credentials to the electronic device and, if access is permitted at a particular time, provide proof to the electronic device corresponding to that particular time, where the test is not susceptible of determination providing only the credentials and values for expired tests. The credentials can be a digital certificate that includes a final value that is a result of applying a unidirectional function to a first of the tests. Each of the tests can be the result of applying a unidirectional function to a future one of the tests. The digital certificate may include an identifier for the electronic device. Credentials may include a final value that is a result of applying a unidirectional function to a first of the tests. Each of the tests can be a result of applying a unidirectional function to a future one of the tests. Credentials can include an identifier for the electronic device. The electronic device can be a computer. Control of access to an electronic device may include initialization of the computer only if access is authorized. The electronic device can be a disk drive. Control of access to an electronic device may include the provision of evidence using at least one evidence distribution entity separate from the at least one administrative entity. There may be a single test distribution entity. There may also be a plurality of test distribution entities. Control of access to an electronic device may include the provision of evidence using a connection to that electronic device. The connection can be through the Internet. At least some of the tests can be stored, locally, on the electronic device. The control of access to an electronic device may include, if the current test is not available locally, the electronic device requesting the tests through an external connection. Each of the tests may be associated with a particular time interval. After a particular time interval has elapsed, associated with a particular one of the satisfactory result tests, the electronic device may receive a new test. Said time interval may be one day.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1A is a diagram illustrating an embodiment that includes a connection, a plurality of electronic devices, an administration entity and a test distribution entity according to the system described herein.

Figure 1B is a diagram illustrating an alternative embodiment that includes a connection, a plurality of electronic devices, an administration entity and a test distribution entity according to the system described herein.

Figure 1C is a diagram illustrating an alternative embodiment that includes a connection, a plurality of electronic devices, an administration entity and a test distribution entity according to the system described herein.

Figure 1D is a diagram illustrating an alternative embodiment that includes a connection, a plurality of electronic devices, an administration entity and a test distribution entity according to the system described herein.

Figure 2 is a diagram representing an electronic device, in more detail, according to the system described herein.

Figure 3 is a flow chart illustrating the steps performed in relation to an electronic device that determines whether or not to perform the validation according to the system described herein.

Figure 4 is a flow chart illustrating the steps performed in relation to the execution of the validation according to the system described herein.

Figure 5 is a flow chart illustrating the steps performed in relation to credential generation according to the system described herein.

Figure 6 is a flow chart illustrating the steps performed in relation to the verification of the evidence regarding credentials according to the system described herein.

Figure 7 is a diagram illustrating a system that includes an area where your physical access has to be restricted according to the system described here.

DETAILED DESCRIPTION OF VARIOUS FORMS OF REALIZATION

Referring to Figure 1A, a diagram 20 illustrates a general connection 22 having a plurality of electronic devices 24 to 26 coupled. Although diagram 20 illustrates three electronic devices 24 to 26, the system described herein can work with any number of electronic devices. The connection 22 can be implemented through a direct connection of electronic data, a connection via telephone lines, a LAN network, a WAN network, the Internet network, a virtual private network or any other mechanism for providing data communication. Electronic devices 24 to 26 may represent one or more laptops, desktops (in an office or at an employee's home or other location), PDAs, mobile phones, disk drives, mass storage devices or any other electronic device where it may be useful to restrict your access. In one embodiment of the present invention, electronic devices 24 to 26 represent laptops or desktops that are used by employees of an organization that wishes to restrict their access in case a user / employee leaves the organization and / or one of computers being lost or stolen. Of course, there may be other reasons for restricting access to one or more of the electronic devices 24 to 26 and the system described herein may be used in connection with any suitable implementation.

An administration entity 28 establishes a policy to allow users to access electronic devices 24 to 26. For example, the administration entity 28 may determine that a particular user, U1, can no longer access any of the devices. electronic 24 to 26, while another user U2, can access the electronic device 24 but not the other electronic devices 25, 26. The administrative entity 28 can use any policy to establish user access.

The administrative entity 28 provides a plurality of tests that are transmitted to the electronic devices 24 to 26 through the connection 22. The tests can be provided to the electronic devices 24 to 26 by other means, which are examined in more detail below. . The electronic devices 24 to 26 receive the distributed tests and, using the credentials stored inside them (described in more detail elsewhere in this description), determine whether or not their access should be allowed. Optionally, a test distribution entity 32 can also be coupled to the connection 22 and the administration entity 28. The test distribution entity 32 provides tests to the electronic devices 24 to 26. In an embodiment of the invention, a test would only be effective for one user and one of the electronic devices 24 to 26 and, optionally, only for a given date or a range of dates.

Evidence can be provided using a mechanism similar to that disclosed in U.S. Patent No. 5,666,416, where each of the electronic devices 24 to 26 receives, as credentials, a digital certificate signed by the administrative entity 28 ( or other authorized entity), where the digital certificate contains a special value that represents an initial value that has a unidirectional function applied N times. In each new time interval, electronic devices can be presented with a test consisting of one of the values from among the set of N values obtained by the application of the unidirectional function. In this case, electronic devices 24 to 26 can confirm that the test is legitimate by applying the unidirectional function, several times, to obtain the special value provided in the digital certificate. This and other possible mechanisms are described in more detail below.

Likewise, it is possible to use one or more of the products provided by CoreStreet, Ltd. of Cambridge, MA to provide the appropriate credentials and evidence as set forth herein or use any other mechanism to generate unique tests that 1) could only have been generated by a administrative authority (in the absence of a breach of administrative security) and 2) cannot be used to generate any other evidence. Consequently, the tests are such that, given a legitimate P1 test, an unauthorized user cannot generate another apparently legitimate P2 test for a different purpose (e.g., for a different time interval, a different device, etc.). In this way, the issued tests can be memorized and distributed in an unsafe way, which greatly reduces the costs associated with the system. Of course, it is convenient to maintain adequate security for the entity or entities that generate the credentials and / or proofs as well as maintain appropriate security for any evidence not issued (e.g., future).

In addition, an unauthorized user, in possession of legitimate P1-PN tests, cannot generate a new PN + 1 test. This is advantageous in several cases. For example, a fired employee cannot, on his own, generate new evidence to provide unauthorized access to his company laptop after dismissal, even if he is still in possession of all other previous legitimate tests he used for the laptop , while I was still employed by the company.

In one embodiment of the present invention, electronic devices 24 to 26 are computers that have firmware and / or operating system. The software that performs the processing described here, where the tests are used to present a record to the unauthorized entry and / or its access. Upon initialization and / or after a sufficient period of time has elapsed, the computers would require an adequate test to start their operation. In this embodiment, the functionality described herein can be integrated with the standard Windows login system (as well as in BIOS or PXE environments). The administration entity 28 may be integrated with the normal user management tools of Microsoft corporate networks and to allow administrators to establish login policies for each user. In numerous cases, the administration entity 28 may be able to derive all the necessary information from the existing administrative information, which makes this new functionality almost transparent to the administrator and the costs of professional training and adoption are reduced. The management entity 28 can be run within an enterprise network or concentrated as an ASP model by a laptop manufacturer, BIOS manufacturer or other trusted partner. The test distribution entity 32 can be partially executed within the corporate network and partly in a global site. Since the tests are not sensitive information, the globally accessible deposits of the test distribution system can be made as web services, thereby obtaining the tests available to users outside their corporate networks.

In other embodiments of the present invention, each of the computers would require a new test every day. However, it will be appreciated by experts in this field that the increase in time can be changed so that, for example, computers can demand a new test every week or demand a new test every hour.

In addition, it is also possible to take advantage of a little used feature of IDE hard drives, which allows the establishment of a password on a drive, which must be presented to the drive before it becomes operational and allow access to its contents. If the firmware for the drive was modified to use the system described here, it is possible that access to a hard disk drive may be restricted so that, for example, it would not be possible to access a computer's hard disk drive even by placing it on a different computer This feature can be implemented with other types of hard disk drives.

In other embodiments, the system can be used in relation to access to data files, physical storage volumes, logical volumes, etc. In some cases, such restriction of access to files may be useful to provide appropriate modifications to the corresponding operating system.

Referring to Figure 1B, a diagram 20 'illustrates an alternative embodiment with a plurality of administrative entities 28a-28c. Although diagram 20 'represents three administrative entities 28a-28c, the system described herein can work with any number of administrative entities. In the embodiment illustrated by diagram 20 ', it is possible for one of the administrative entities 28a-28c (eg, the administrative entity 28a) to generate the credentials while others of the administrative entities 28a-28c (eg, the administrative entities 28b, 28c) generate the tests or all of the administrative entities 28a-28c generate the tests. Optionally, the test distribution entity 32 can be used in this regard.

Referring to Figure 1C, a diagram 20 "illustrates an alternative embodiment with a plurality of test distribution entities 32a-32c. Although diagram 20" illustrates three test distribution entities 32a-32c, the system described herein It can work with any number of test distribution entities. The embodiment illustrated by diagram 20 "can be implemented using the technology provided by Akamai Technologies Incorporated, of Cambridge, Massachusetts.

Referring to Figure 1D, a diagram 20 "'illustrates an alternative embodiment with a plurality of administrative entities 28a'-28c' and a plurality of test distribution entities 32a'-32c '. Although diagram 20'" illustrates three administrative entities 28a'-28c 'and three test distribution entities 32a'-32c', the system described herein may work with any number of administration entities and test distribution entities. The embodiment illustrated by diagram 20 '"combines features of the embodiment illustrated by Figure 1B with features of the embodiment illustrated by Figure 1C.

Referring to Figure 2, a diagram illustrates the electronic device 24 in more detail including a validation unit 42, credential data 44 and test data 46. The validation unit 42 can be implemented using hardware, software, firmware , or any of its combinations. Under certain conditions, such as in an initialization, the validation unit 42 receives an initialization signal that causes the validation unit 42 to examine the credential data 44 and the test data 46 and, based on its result, generate a step signal indicating that a legitimate test has been submitted or otherwise, generates a failed access signal. The output of the validation unit 42 can be used following a certain processing / devices such as computer initiation firmware to determine whether or not the operation can be continued.

In another embodiment, the electronic device 24 comprises an external interface 48 that is controlled by the validation unit 42. As in the case of the validation unit 42, the external interface 48 can be implemented using hardware, software, firmware, or any of its combinations. The external interface 48 is coupled to, for example, the connection 22 and is used for the search of new tests that can be stored in the test data 46. Thus, if the validation unit 42 determines that the tests stored in the test data 46 is not sufficient (eg, they have expired), the validation unit 42 provides a signal to the external interface 48 to make the external interface 48 request new tests via connection 22. Of course, if the device electronic 24 has been lost and / or stolen or if the user is a dismissed employee or if there is any other reason to deny access to electronic device 24, in such case, external interface 48 will not be able to obtain a valid proof. In some embodiments, the external interface 48 asks a user to make a suitable electronic connection (e.g., the connection of a laptop to a network).

In another embodiment of the present invention, the time data 52 provides information to the validation unit 42 to indicate the last time a valid test was submitted to the validation unit 42. This information can be used to prevent the request. Test too often and at the same time, avoid waiting too long before requesting a new test. The interaction and use of the validation unit 42, the external interface 48, the credential data 44, the test data 46 and the time data 52 are described in more detail below.

Referring to Figure 3, a flowchart 70 illustrates the steps taken in relation to determining whether or not to send the start signal to the validation unit 42 to determine whether the validation unit 42 should examine, or no, credential data 44 and test data 46 to generate a failed pass or access signal. The processing begins in a first stage 72 where it is determined whether or not an initialization operation is performed. In another embodiment, the tests are always checked in relation to an initialization operation. Accordingly, if it is determined in the test stage 72 that an initialization is being performed, in that case, the control is transferred from the stage 72 to a stage 74 where the start signal is sent to the validation unit 42. After step 74, step 76 is performed where the process waits for a predetermined amount of time before performing a cyclic operation again. In another embodiment, the predetermined amount of time may be one day, although other time quantities may also be used. After step 76, the control is transferred back to test stage 72, described above.

It is determined, in the test stage 72, that an initialization operation is not being carried out, in which case, the control is transferred from the test stage 72 to a test stage 78 where it is determined whether a quantity of predetermined time since the last run by the validation unit 42. This operational circumstance is determined using the time data element 52 and perhaps the current system time. In another embodiment, the predetermined amount of time used in test stage 78 is one day. If it is determined, in the test stage 78, that the amount of time since the last execution of the validation unit 42 is greater than the predetermined amount of time, in this case, the control is transferred from the test stage 78 to step 74, where the start signal is sent to the validation unit 42. After step 74 or after test stage 78, if the amount of time is not greater than the predetermined amount of time, it is passed to step 76, previously examined.

Referring to Figure 4, a flowchart 90 illustrates the steps performed in relation to the validation unit 42 to determine whether a sufficient test has been received. As described elsewhere herein, the validation unit 42 sends a step signal or a failed attempt signal for processing / device tracking (such as a computer initialization firmware or disk drive firmware). The processing begins in a first stage 92 where the validation unit 42 determines the necessary test. The necessary test is the test determined by the validation unit 42 sufficient to be able to send a step signal. The validation unit 42 determines the necessary test by examining the credential data 44, the test data 46, the time data 52 and perhaps even the system / internal clock. After step 92 there is a test stage 94 that determines whether the appropriate test is available at the local level (that is, in the test data 46) and if the test provided, at the local level, meets the necessary requirements (described in another place of the present). If so, then the control is transferred from step 94 to a stage 96, where the validation unit 42 emits a step signal. After step 96, the processing is completed.

In some embodiments, it is possible and desirable to obtain and store future evidence in the test data 46. For example, a user who expects to be without a connection to the administration entity 28 and / or the test distribution entity 32 may Obtain and store future evidence. In this embodiment, the electronic device can automatically poll for future tests, when connected to the administration entity 28 and / or the test distribution entity 32, which can be provided according to a predefined policy. As an alternative (or in addition), it may be possible for a user and / or electronic device to specifically request future tests that may or may not be provided in accordance with current policy.

If it is determined, in the test stage 94, that the appropriate test is not available locally (that is, in the test data 46), in that case, the control is transferred from the test stage 94 to a stage test 98 wherein the validation unit 42 determines whether a suitable test is available externally by providing, for example, a signal to make the external interface 48 attempt the test search, as described above. If it is determined that test stage 98, and that the test provided externally meets the necessary requirements (examined elsewhere here), in that case, control is transferred from test stage 98 to step 96, above described, wherein the validation unit 42 emits a step signal. In another embodiment, the externally provided test is stored in the test data 46.

If it is determined, in test stage 98, that a suitable test is not available externally, since there is no suitable condition or for some other reason, in that case, the control is transferred from test stage 98 to a stage 102, where the user is asked to enter a suitable test. In another embodiment, if a user is in a position without a suitable electrical connection, the user can call a particular telephone number and receive a suitable proof in the form of a number that can be manually entered into the electronic device in relation with the request provided in step 102. Of course, the user can receive the proof by other means, such as handwritten or typed or even published in a newspaper (eg, in the classified ads section).

After step 102 it is a test 104 which determines whether the user has entered a test that meets the necessary requirements (as described elsewhere here). If so, then the control is transferred from test stage 104 to step 96, described above, where the validation unit 42 emits a step signal. Otherwise, the control is transferred from the test stage 104 to a stage 106 where the validation unit 42 emits a fault signal. After step 106, the processing is completed.

Referring to Figure 5, a flowchart 120 illustrates the steps performed in relation to the generation of credentials used by the validation unit 42. The stages of the flowchart 120 can be performed by the management entity 28 that generates the credentials (and a series of tests) and provides the credentials to the electronic device 24. Other suitable entities (eg, entities authorized by the administration entity 28) may generate the credentials. The random value is used in relation to the generation of credentials and evidence and, in another embodiment, is usually unpredictable. After stage 122 there is a stage 124 where an index variable, I, is set to ‘one’. In another embodiment, the credentials provided are used for a full year and a new test is needed each day so that three hundred and sixty-five separate tests can be generated in relation to the generation of the credentials. The index variable, I, is used to keep a record of the number of tests that are generated. After step 124 there is a stage 126 where the initial test value, Y (0) is set equal to the random RV value determined in step 122.

After step 126 there is a test stage 128 that determines whether the index variable, I, is greater than an ending value, IEND. As discussed above, in another embodiment, three hundred and sixty-five tests are generated in relation to the generation of credentials so that, in this embodiment, IEND, has a value of three hundred and sixty-five. However, for other embodiments, it is possible to set the value of IEND in any other number.

If it is determined, in test stage 128, that the value of I is not greater than that of IEND, in that case, the control is transferred from step 128 to a stage 132 where Y (I) is set equal to the unidirectional function applied to Y (I1). The unidirectional function used in step 132 is such that, given the result of applying the unidirectional function, it is almost impossible to determine the value that was entered for the unidirectional function. Thus, for the unidirectional function used in step 132, given Y (I), it is very difficult, if not impossible, to find out the value of the input (in this case Y (I-1)). As used herein, the term unidirectional function includes any function or operation that adequately provides this property including, without limitation, conventional unidirectional hash functions and digital signatures. This property of the unidirectional function used in step 132 is useful in relation to its ability to store and distribute evidence issued in an insecure manner, as discussed elsewhere in this description. The credentials and proofs can be generated at different times or the proofs can be regenerated at a later date by the entity that generated the credentials or by another entity. It should be noted that, for other embodiments, it is possible to have Y (I) not being a function of Y (I-1) or any other value of Y in that regard.

Processing begins in a first stage 122 where a random value, RV, is generated. After step 132 there is a stage 134 where the index variable is increased, I. After step 134, the control is transferred back to test step 128, described above. If it is determined, in test stage 128, that I is greater than IEND, in this case the control is transferred from test stage 128 to a stage 136 where a final value, FV, is set equal to Y (I -one). It should be noted that "1" is subtracted from the value I because I was increased beyond IEND. After step 136 there is a step 138 where the management entity 28 (or some other entity that generates the evidence and credentials) performs a digital signature of the final value, the current date and other information that is used in relation to the tests. In another embodiment, said other information may be used to identify the particular electronic device (eg, laptop), the particular user or any other information that is linked to the credentials and the proof for a particular electronic device and / or user. and / or some other property. Optionally, the date and / or the PV value can be combined with the other information. For example, it is possible to use a message signed as OCSP that simply states "device no. 123456 is valid on 1/1/2004" or has a bit in a miniCRL that corresponds to a specific device that is enabled or disabled. In such cases, the credential on the device can perform the authentication of the device (that is, determine that the device is really device # 123456, etc.). OCSP and miniCRLs are known in this technique. After step 138, the processing is completed.

Referring to Figure 6, a flow chart 150 illustrates the steps performed by the validation unit 42 in relation to determining the validity of a test. The processing begins in a first stage 152 where the validation unit 42 receives the test (e.g., by reading the test from the test data 44). After step 152 there is a stage 154 where the validation unit 42 receives the credentials (e.g., by reading the credential data 46).

After step 154 there is a test stage 156 that determines whether the other information provided with the credentials is correct. As described elsewhere in this description, the other information includes, for example, an identification of the electronic device, an identification of the user, or other property that identifies the information. If it is determined, at test stage 156, that the other information associated with the credentials does not match the particular property described by the other information (eg, the credentials are for a different electronic device or a different user), in that case the control is transferred from test stage 156 to a stage 158 where a fault signal is provided. After step 158, the processing is completed.

If it is determined, in test stage 156, that the other information associated with the credentials is correct, then control is transferred from test stage 156 to a stage 162, where a variable N is set equal to the current date minus the date associated with the credentials (that is, the number of days elapsed since the credentials were issued). After step 162 there is a stage 164 where the test value provided in step 152 has a unidirectional function applied N times. The unidirectional function, used in step 164, corresponds to the unidirectional function used in step 132, described above.

After step 164 there is a test stage 166 that determines whether the result obtained in step 164 is equal to the final PV value, which is part of the credentials received in step 154. If so, then the control is transferred from test stage 166 to a stage 168 where a signal is passed through the validation unit

42. If not, if it is determined, in test stage 166, that the result obtained in step 164 is not equal to the final PV value provided with the credentials in step 154, in that case, control is transferred from test stage 166 to a stage 172 where a fault signal is generated by the validation unit 42. After step 172, the processing is completed.

Digital signatures can provide an effective form of Internet authentication. Unlike traditional passwords and PIN numbers, digital signatures can provide authentication that can be universally verifiable and non-repudiable. Digital signatures can be produced using a signature key, SK, and verified by a match verification key, PK. A user U keeps his own secret SK key (so that only user U can sign on behalf of U). Unfortunately, the PK key does not "reveal" the SK match key, that is, knowledge of the PK key does not provide an intruder with any practical advantage in calculating SK. Therefore, a user U could make his own PK as public as possible (so that anyone can verify the signatures of U) For this reason, PK is preferably called the public key It should be noted that the term "user" can mean a user, an entity, a device or a set of users, devices and / or entities.

Public keys can also be used for asymmetric encryption. A public PK encryption key can be generated together with an SK match decryption key. Again, knowledge of PK does not reveal SK. Any message can be easily encrypted with the PK key, but the encrypted text so determined can only be easily decrypted by knowledge of the SK key. Therefore, a user U could make his own PK as public as possible (so that anyone can encrypt messages for U), but keep the SK key private (so that only U can read encrypted messages for U).

The RSA system, well known in this technique, provides an example of both digital signatures and asymmetric encryption.

Alphanumeric strings, called certificates, establish that a given PK key is a public key of a given user U. An entity, often called a certification authority (CA), generates and issues a certificate for a user. Certificates expire after a specified period of time, which is usually one year in the case of public CA authorities. Essentially, a digital certificate C consists of a digital signature of CAs that is securely linked, together with several magnitudes: SN, a unique serial number for the certificate, PK, the user's public key, U, the name of the user, D1, the date of issue, D2, the expiration date and additional information (including no information), AI. In symbols, C = NEXT (SN, PK, U, D1, D2, AI).

Public encryption keys can also provide a means of authentication / identification. For example, a party that knows that a private public encryption key PK belongs to a given user U (eg, because the party has verified a corresponding digital certificate for U and PK) and if you want to identify U, you can use the PK key to encrypt a random challenge C and ask U to respond with the correct decryption. Since only the SK key holder (and therefore, U) can perform this operation, if the answer to the challenge is correct, U is properly identified.

It is possible to provide a system to control physical access to an area using an intelligent door (and / or an intelligent virtual door; see the corresponding description elsewhere here). An intelligent door can verify that the person entering is currently authorized to do so. It may be convenient to provide the door not only with the credential of a given user, but also with a separate proof that the credential / user is still valid in a way that can be used safely, even by a disconnected door. In one embodiment, said tests are generated as follows. Assuming that a credential specifies the doors, a user can enter. In that case, for each credential and each time interval (eg, each day), an appropriate entity E (eg, the same entity that decides who is authorized for which door at any time, or a second entity that works for that entity ) calculates an authenticated test indication (PROOF), that a given credential is valid in the given time interval. (If the credentials do not identify the doors for which users are authorized to enter, a PROOF indication can also specify the doors for which the credential is appropriate in the given time interval).

A PROOF of E may consist of a digital signature of E indicating, in an authenticated form, that a given credential is valid for a given time interval, for example: SIGE (ID, Day, Valid, AI), where ID is the information that identifies the credential (eg, the serial number of the credential), Day is an indication of the given time interval (without loss of expected generality, a given day), Valid is an indication that the credential is considered valid (this indication can be omitted if E never signs a similar data string unless the credential is considered valid) and AI indicates any additional information (including no information) deemed useful. In some cases, the signature of E may be a public key signature. (However, it could also be a private key signature, that is, a signature that can be generated and verified by a unique secret key, known to the signer and the verifier). If the credential consists of a digital certificate, a sub-embodiment may consist of a short life certificate, that is, a digital signature that re-issues the credential for the desired time interval (eg, a digital certificate that it specifies the same public key, the same user U and some other basic information as before, but which specifies the start date and the expiration date in order to identify the desired day - without loss of expected generality). For example, to allow, without loss of anticipated generality, a last short-term certificate for one day, in said sub-embodiment, a PROOF may take the form of SIGE (PK, U, D1, D2, AI), in where the start date D1 indicates the beginning of a given day D and the end date D2 the corresponding end of day D, or where D1 = D2 = D; or more simply, using a single date information field in order to identify the day in question, SIGE (PK, U, Day, AI). If E matches the original certification authority, a short-term PROOF certificate may take the form SIGCA (PK, U, D1, D2, AI) or SIGCA (PK, U, Day, AI).

Being authenticated, a user cannot manufacture his own PROOF of the day (that is, the PROOF of the day of his own credential), nor can he change his PROOF of yesterday in his own PROOF of today, nor the PROOF of another user to today on your own for today. Since PROOFs are essentially not susceptible to forgetfulness or modification, these PROOFs do not need to be protected. In this way, entity E can make PROOFs available at an insignificant cost. For example, E can register all PROOF tests of a given day on the Internet (eg, make PROOFs available through Akamai servers or equivalent), or send PROOFs to responders / servers that can be easily reached by users . For example, for a server located at the entrance of an airport (or office building) where most of the doors are located to be accessed correctly. In this way, an employee who arrives at his job can easily pick up his own PROOF (eg, by inserting his own card into a card reader attached to the server) and also memorize the PROOF on his own card, along with his own credential. . Thus, when the user presents his card to a door that his credential authorizes him to access, the door can not only verify the credential but also receives and verifies a current authorization PROOF, without needing to connect at all. The door verifies the PROOF (e.g., the digital signature of E by means of a public key of E that can be memorized from its installation) and that the time interval specified by the PROOF is adequate (e.g., by its own local clock). If everything is correct, the door grants access and if it is not, the door denies access. In essence, the door can be disconnected and nevertheless, its verification of PROOF can be relatively easy (because the door can receive the PROOF for the most available part: the user himself who demands access) and at the same time, relatively secure ( although the door receives the PROOF from the most suspicious part: the user who demands access). In fact, a user who demands access can normally be in the physical proximity of the door and thus, can provide the PROOF with ease, without using any connection to a distant location and thus, operate independently of connectivity of the door. At the same time, the user who demands access can be the least reliable source of information at that crucial moment. However, since the user cannot manufacture or modify a PROOF of its own current validity in any way, the door can be assured that a properly verified PROOF must be produced by E, and E would not have produced the PROOF if E knew that the user is not authorized during the given time interval. When a user is no longer authorized, E will interrupt the issuance of authorization PROOF for the user and in this way, the user can no longer enter through doors even disconnected, because the user will lack the PROOF that a door needs to verify for be able to grant your access Thus, using the user who demands access to proper and current authorization tests, the system described here dispenses the inconveniences associated with other systems, that is, the need to instruct a work group to reprogram the disconnected doors.

This method also allows managing access to disconnected doors by "charge" (or by "privilege"). That is, instead of having a credential that specifies the doors that your user is authorized to enter and then issue eg, each day - a current valid PROOF of a credential (or instead of issuing a PROOF that specifies that a given credential authorizes its user to enter through some doors in a given time interval), the disconnected doors can be programmed (eg, at the time of installation) to grant access only to users who have a given professional position. For example, a cabin door on an airplane can be programmed to grant access only to PILOTS and INSPECTORS. Credentials can be issued to employees primarily to verify their identity (that is not changed), while each PROOF that E-pe, issues daily for a given credential, can also specify (eg, in field AI) the charges of their corresponding user on that day. For example, PROOF = NEXT (ID, Day, PILOT, AI) proves on the Day indicated that the user corresponding to the credential identified by ID is a pilot. In this way, employees can “migrate” from one position to the next without having to reissue their credential and without having to specify within a user credential or in their corresponding daily PROOF, what doors the user can access that day . It should be noted that the number of such doors can be very large. Thus, specifying within a user credential all the doors that a user may be authorized to access, can be a task that requires excessive time. In addition, if new doors are added (e.g., because new aircraft are acquired), then the pilot's credential may have to be reissued, which is also burdensome, to specify additional doors.

The appropriate time intervals for a given credential can be specified within the credential itself or can be specified by the credential and the PROOF together. For example, a credential can specify a given start day and needs to be proven valid every day, while the PROOF can specify the time interval 244, which means that the PROOF refers to day 244 after the start day specified in The credential itself.

The system described here may also be advantageous in relation to higher cost connected door systems. For example, assuming that all doors were securely connected to a central database and that an unexpected technical shutdown occurs (e.g., by sabotage). In this case, the connected doors may be forced to choose between two extreme alternatives: ALWAYS OPEN (good for security, but poor protection, in particular, if the terrorists caused the technical shutdown) and ALWAYS CLOSED (bad for security but good for personal protection). In contrast, in case of an unexpected technical shutdown, the system described here offers a much more flexible response, some (not already) connected doors can always remain closed, others always open and others, however, can continue to function according to the control of access of disconnected doors described here. That is, the doors, which run on batteries, can only be opened if the correct credential and the correct PROOFs are presented. In fact, before the technical shutdown occurs, it is possible for all employees to periodically receive their planned PROOFs.

Of course, entity E can generate PROOFs that specify different time intervals for different credentials. For example, at an airport facility, police officers and emergency personnel may, every day, have a PROOF that specifies the following two weeks as the relevant time interval, while all ordinary employees may have, every day , PROOFs that specify only the day in question. Such a system can provide better control in case of a long and unexpected technical stop. If such a technical shutdown occurs, the usual daily distribution of PROOFs may be interrupted and ordinary employees may not receive their daily PROOFs, but police officers and those responsible for emergency case management may still have, on their cards, evidence of two weeks they received the day before and therefore, they can continue to operate all the doors for which they are authorized to enter (eg, all doors).

It should be understood that the method described herein encompasses the use of credentials that consist of a form of reduced certificate, which can be referred to as minimum certificates. A minimum certificate can essentially omit the user's name and / or the ID of the certificate or replace the username and / or the ID with a public key of the certificate (which may be unique for each certificate). For example, a minimum certificate credential can take the form C = SIGCA (PK, D1, D2, AI), with the understanding that the proper presentation of this credential includes testing knowledge of the secret key SK corresponding to PK (eg , using a challenge-response method). The door can know, in advance, if the proper presentation (or not) of a PK-related credential (preferably, if it is currently validated) should result in the granting of access. Alternatively, a minimum C credential can specify (e.g., in AI) whether a user who knows the corresponding SK is authorized, or not, to enter through a given door. A PROOF relative to a minimum certificate whose public key is PK, can take the form SIGE (ID, Day, Valid, AI) or SIGE (PK, Day, Valid, AI) or SIGE (ID, Day, AI) if understood that any similar signature indicates validity by implication. Alternatively, a valid PROOF of a minimum certificate may take the form of the re-issuance of a minimum certificate of short duration: eg, SIGE (PK, D1, D2, AI), where the start date D1 indicates the beginning of a given day D and D2 the corresponding end of day D, or D1 = D2 = D; o FOLLOW (PK, Day, AI); or allowing E to match the original certification authority, SIGCA (PK, D1, D2, AI) or SIGCA (PK, Day, AI). In general, any method described here addressed to certificates should be understood to apply also to minimum certificates.

An intelligent door can verify the validity and validity of a user's credentials, which may be accompanied by a corresponding proof. The credentials / tests used by a user, to gain access to an area, may be similar to the credentials / tests used in relation to the control of access to electronic devices, as described elsewhere herein. The following are examples of credentials / tests, some of which can be combined with others:

one.

A PIN number or password, entered through a keypad associated with the door or communicated to the door by a user card;

2.

Biometric information, provided by a user through a special reader associated with the door;

3.

A traditional (handwritten) signature, provided by a user through a special keyboard associated with the door;

Four.

A digital certificate for a PK public key (eg, such credential can be memorized in a user card and the correct user / card can use the corresponding secret key SK to authenticate / identify itself to the door -pe, by means of a protocol challenge-response). For example, if PK is a public signature key, the door may require the signature of a given message and the correct user is the only one who knows the corresponding SK secret signature key that can thus provide the correct requested signature; if PK is a public encryption key, the door may require the presentation of a given decrypted encrypted text, which can be done by the correct user, who knows the corresponding secret decryption key SK;

5.

An improved digital certificate that includes a daily "validation value" (which guarantees that the certificate is valid on this particular date), memorized on a user card and communicated to the door;

6.

A digital signature of a central authority confirming that a user certificate is valid at the present time, communicated to the door by a server or responder;

7.

A digital certificate that is memorized on a user card and communicated to the door, as well as a daily "validation value" communicated to the door by a server or responder;

8.

A secret value, stored in a user card, whose knowledge is checked for the door by means of an interactive protocol (possibly zero knowledge) with the door;

9.

A secret key signature of an authority, memorized on a user card, indicating that the user is authorized to enter a particular day.

Thus, in some cases, credentials / proofs are provided in a single part while, in other cases, credentials / proofs are provided in separate parts, on the one hand credentials and separately, proofs. For example, where the credentials / tests consist of an enhanced digital certificate that includes a daily validation value that indicates that the certificate is valid on that particular date and is associated with a user and communicated to the door, the credentials (the certificate Enhanced digital) can be provided separately (by different means and / or at different times) of the tests (the daily validation value). Similarly, credentials and evidence can all be generated by the same authority or can be generated by different authorities.

Referring to Figure 7, a diagram illustrates a system 200 that includes a zone 202 in which its physical access has to be restricted. Zone 202 is enclosed by a plurality of walls 204-207. The wall 207 has a door 212 to provide exit to the zone 202. In other embodiments, more than one door can be used. The walls 204-207 and the door 212 provide a barrier for access to the area 202. The door 212 can be locked using an electronic lock that prevents the opening of the door 212 unless and until the electronic lock 214 receives An adequate signal. The electronic lock 214 can be implemented using any suitable element that provides the functionality described herein, including, without limitation, the use of electronic locks of ordinary use.

The electronic lock 214 can be coupled to a controller 216, which provides a signal suitable for the electronic lock 214 to allow the opening of the door 212. In some embodiments, the electronic lock 214 and the controller 216 can be provided in a single unit. . The controller 216 can be coupled with an input unit 218, which can receive credentials from a user and optionally also receive a corresponding proof indicating that a user is currently authorized to enter zone 202. The input unit 218 can also receive a direct revocation alert (HRA) indicating that the user is no longer allowed to enter zone 202. HRA alerts are described in more detail below. The input unit 218 can be any suitable input device, such as a keyboard, a card reader, a biometric unit, etc.

Optionally, the controller 216 may have an external connection 222 that can be used to transmit data to and from the controller 216. The external connection 222 may be secure although, in some embodiments, the external connection 222 may not need to be secure. . In addition, external connection 222 may not be necessary because the functionality described herein may be provided using autonomous units that do not have external connections. In those cases where the external connection 222 is provided, said external connection 222 can be used to transmit credentials, tests, HRAs and / or can be used in connection with the registration of access to the zone

202. The access registry is described in more detail elsewhere in this same description. It should be noted that the external connection 222 may be intermittent so that, for example, at some times the external connection 222 provides connectivity for the controller 216 while, at other times, there may be no external connection for the controller 216. At some times cases, external connection 222 can be used to transmit a part of the credentials / tests (eg, a PKI digital certificate) while a user presents to the input unit 218 a remaining part of the credentials / tests (eg, a value of daily validation used in relation to the digital certificate).

In some embodiments, a user may present a card 224 to the input unit. As described elsewhere herein, the card 224 may be a smart card, a PDA, etc. which provides data (eg, credentials / evidence) to the input unit 218. The card 224 can obtain some or all of the data from a transponder 226. In other cases, the card 224 can obtain data from other cards (not shown) ), from the input unit 218 (or some other mechanism associated with access to zone 202), or some other suitable source.

In a first example, credentials and proofs can be maintained using a physically protected PIN / password number. In this example, each morning a server generates a new secret SU password for each authorized user U and communicates the new SU to specific doors that user U is allowed to access. Communication can be encrypted to be sent using unsecured lines or It can be transmitted to the doors through some other secure means. When the user U reports that he has to work in the morning, the central server causes the user card U to receive the current secret password SU. The secret SU password is stored in the card's security memory, which can only be read when the card is properly authorized (eg, by the user entering a secret PIN number in relation to the card or by connecting with the hardware of the card). trust in the server or the doors). Whenever the user tries to access through a door, the card securely communicates the SU password to the door. The door then checks if the SU value received from the card matches the value received from the server in the morning and, if so, allows access.

Thus, SU is the user's credential for one day. This system has the advantage that each credential is of limited duration: if an employee is dismissed or his card is stolen, his credentials will not be useful on the following day. The system, however, requires some connectivity: at least a short period of connectivity (preferably every morning) is needed to update the door. This transmission must be ensured (e.g., physically or cryptographically).

In another example, the user's credentials include signatures with secret keys. This example uses signatures, which can be public key signatures (e.g., RSA signatures) or secret key signatures (e.g., Message Authentication Codes

or MACs). For example, an access control server uses a secret SK key to generate signatures and the door has means to verify those signatures (e.g., by means of a corresponding public key or by sharing knowledge of the same SK key). When a user U informs that he will work in the morning on a D day, the server causes the user's card to receive a Sig signature that authenticates the user identification information U (eg, the unique card number or password) secret of user U or biometric information, such as fingerprints of user U) and date D. When user U tries to access through a door, the card communicates the signature Sig to the door, which verifies its validity possibly in conjunction with the identification information provided by the user U himself and the date supplied by the local clock on the door. If all this is correct, the door allows access.

In this technique, the Sig signature can be considered as the user's credentials and their proof together. This method has its own advantages: the cards do not need to memorize secrets and the doors do not need to maintain secure connections with a central server, nor a long list of valid credentials.

In another example, user credentials include a digital certificate with chain validity tests of hash functions similar to those generated in relation to flowchart 120 in Figure 5. This example uses public key signatures and a summary function unidirectional hash H (which implements a special type of digital signature). A central authority has a pair of keys: a public key PK (known for doors) and a secret key SK that is not usually known. For a user U, the authority generates a random secret value X0 and a calculated value X1 = H (X0), X2 = H (X1), ..., X365 = H (X364). Since H is a unidirectional hash function, each value of X cannot be calculated from the following value of X. The authority issues for the user U a digital certificate Cert, signed using the SK key and containing the valid X365 value for a year In this case, when user U informs that he will work on day i, the authority causes the user's card to receive the validation value of that day Xj, where j = 365 - i. When U tries to access a door, the card communicates the Xj validation value and the Cert certificate containing X365 to the door. The door verifies the validity of the Cert certificate with the public key PK of the authority and also verifies that H applied ix times to Xj produces X365. It should be noted that the term "one year" and 365 may be substituted for any other period of time.

Thus, the user's Cert certificate as well as the validation value Xj constitute the user's credentials / tests. This system has numerous advantages: neither the door nor the card need to memorize any secrets; the door does not need to have any secure connection; the certificate can be issued once a year and thereafter, the daily calculation burden on the central authority is minimal (because the authority only needs to recover Xj); Daily validation values can be provided by non-secure (low-cost) distributed responders because they do not need to be secret.

A credential / proof for a user U is usually limited in duration, which is useful in various circumstances. For example, if user U is an employee of an airport and is subject to dismissal, his credentials / tests may expire at the end of the day and he will no longer be able to access the airport doors. For more precise access control, it may be desirable to have credentials of shorter duration. For example, if the credential / proof for U includes the time and minutes as well as the date, then user U can be locked with respect to access to the airport after only one minute from his dismissal. However, shorter credentials / tests require a more frequent update, which adds expenses to the system. It could be inconvenient if each employee, at an airport, had to load new credentials / tests on his card every minute. In this way, there can be an inherent conflict between the desire to have short-term credentials and to have a lower cost system, which can lead to credentials that are sometimes no longer desired. For example, user U may need to block access to the airport immediately, but his credential does not expire until midnight. Therefore, it is desirable to provide immediate cancellation of credentials that have not yet expired.

It should be noted that if the credentials / tests are always stored in a secure database, which is consulted by the doors every time access is requested, it is relatively easy to cancel the credentials / tests by, for example, the elimination of the credentials / tests canceled from the database. However, having a door to check a secure database every time, is expensive. First, because this adds a significant delay to the operation since the user needs to access the door immediately, but has to wait for the query to be properly concluded. Secondly, because this communication is preferably carried out through a secure channel, which can easily cost $ 4,000 per door (or more) or be completely unavailable in some cases (e.g., for airplane doors or cargo containers). Thirdly, because a single secure database can only handle a limited query load and replication of a secure database is itself costly and time-consuming (eg, because the costs of maintaining the Secure database should be duplicated and effort should be measured to keep these copies synchronized.) Therefore, unlike the fully connected method, disconnected or intermittently connected methods (such as those described in the previous examples) need less communication and often memorize credentials / tests on unsecured responders or on the cards themselves. In such a case, simply removing credentials / evidence from the database may not be enough. To refer again to the previous examples, the SU password, or the signature of the competent authority or the validation value Xj would have to be removed, in some way, from a user card or from the doors. Furthermore, even such deletion may not always guarantee the revocation of a credential, since a credential memorized in an unsecured responder may be available to any user, including a malicious intruder who could save it and attempt to use it after its removal from the card. Username. Thus, even if there are lower cost solutions with limited duration credentials, these solutions, by themselves, do not necessarily provide a sufficient revocation of an unexpired credential / proof.

The cancellation of credentials / tests can be performed using a Direct Revocation Alert (HRA), which is an element of data (preferably authenticated) that is transmitted to the door that will prevent the door from granting access to a user with canceled credentials / tests. (although possibly not expired). For example, an HRA may consist of a digitally signed message stating that the credentials / tests given have been canceled. It should be noted, however, that a firm may not always be involved in an HRA. For example, in the case of a door with a secure connection, simply sending an HRA along the protected connection may be sufficient. However, as indicated above, doors with secure connection can be expensive in some cases and impossible (or almost impossible) in other cases.

It is useful for HRAs to be authenticated so that an entity to which an HRA is presented can have a relative certainty that the HRA is authentic. Allowing the ID identifier to be an identifier for the canceled C credentials / tests (in particular, the ID identifier may match C itself), then SIG (ID, "CANCELED", AI) can be an HRA, where "CANCELED "means any way of signaling that C has been canceled (" CANCELED "is possibly the empty string if the fact that the credentials / tests are canceled could be deduced by other means, such as an agreement at the system level that such messages signed are not sent except in case of cancellation), and AI means any additional information (possibly date information, such as when the credentials / proofs have been canceled and / or the time the HRA was produced or any information ). The SIG digital signature may be, in particular, a public key digital signature, a secret secret digital signature or a message authentication code. It is also possible to issue an authenticated HRA by properly encrypting the information. For example, an authenticated HRA can take the form ENC (ID, "CANCELED", AI).

Another notable example of an authenticated HRA is described in US Patent 5,666,416, which is incorporated herein by reference. The issuing authority incorporates in a credential / proof C a public key PK (of a digital signature system) that is unique to C, so that a digital signature relative to that PK key indicates that C is canceled. In a special embodiment of said system, PK may consist of a Y1 value calculated as Y1 = H (Y0), where H is a unidirectional function (preferably hashing function) and Y0 is a secret value. When the credential / test C is canceled, the HRA consisting of only Y0 is issued. This HRA can be verified by the Y0 hashing function and checking that the result matches the value Y1 that belongs to the credential / test C.

It should be noted that a signature may not be required for an HRA. For example, in case of a securely connected door, simply sending (ID, "CANCELED", AI) along the protected connection may be sufficient as an HRA. However, the advantage of authenticated HRAs is that the HRAs themselves do not need to be secret. Authenticated HRAs, once authenticated by the competent authority, can be memorized in one or more responders (possibly geographically dispersed). In addition, these responders may not be protected (unlike the issuing authority), because they are not memorizing secret information. Higher reliability can be provided, at a lower cost, by replicating multiple unprotected responders. Some additional advantages of the authenticated HRA example of US Patent 5,666,416 are: (1) the HRA is relatively short (it can be as short as 20 bytes), (2) it is calculated with relative ease (simply a query from the previously memorized Y0) and (3) is relatively easy to verify (simply an application of a unidirectional hash summary function).

Authenticated HRAs can be particularly advantageous for broad efficient dissemination, as described below. When an HRA transits through multiple points in the direction of the door, there may be multiple possibilities of an incorrect HRA to be inserted into the system. In reality, an HRA received by the door not directly through or from the sender, through a secure connection, may be no more than a simple rumor of cancellation of a particular credential. If the HRA is authenticated, however, this rumor can be easily confirmed by the door, which can verify its authenticity.

In general, an HRA may be specific to a single credential / proof or may provide cancellation information in relation to a multiplicity of credentials / evidence. For example, ID1, ... IDk are identifiers for canceled credentials, an HRA can consist of the unique digital signature SIG (ID1, ... IDk; "CANCELED"; AI). Consider the case of a door that memorizes information that identifies the credentials / evidence that you have the right to access the door. If that door receives an HRA that indicates that one or more credentials / tests are canceled, the door does not need to memorize the HRA. It is enough for the door to erase the credentials / tests identified from its memory (or mark them as "CANCELED" in some other way). Then, if a user with a canceled credential / test tries to access, the door will not allow access because the credential / proof presented is not currently stored or, if stored, is marked "REVOKED" (CANCELED) .

Consider now a case of a door that does not memorize information that identifies all credentials / proofs allowed, but verifies if a credential / proof is allowed when it is presented. When a user presents a credential / proof to said door, the door can first verify if the credential / proof is valid, discarding the HRAs. (For example, if the credential / proof includes a digital signature, the door verifies the signature. In addition, if the credential / proof includes an expiration time, the gate can also verify that the credential / proof is not expired, eg, using an internal clock). However, even if all checks are passed, the door may still deny access if the credential / proof is indicated as being canceled by an HRA. Therefore, it is useful if that door has information regarding the relevant HRAs. One way to achieve this is, for the door, to memorize all the HRAs presented to the door. On the other hand, in some cases, this operation may become unfeasible. Consider a system where numerous credentials / proofs could be used to pass through that door. For example, the US Department of Transportation is considering the possibility of a 10,000,000 credential system for a variety of people (including pilots, airport personnel, airline employees, mechanics, baggage handlers, wheelbarrow drivers elevators, police, etc.) that may at one time or another have access allowed for a given door. At a reduced annual cancellation rate of 10%, the door can have a 1,000,000 HRAs to memorize at the end of a year, which can be a burdensome (if not, unworkable) task. In addition, if the amount of HRAs cannot be determined accurately in advance, system designers may have to overestimate the magnitude of storage for HRAs in order to be on the safe side and build even more storage capacity (e even more cost) at the door.

This problem can be solved by means of the so-called removable HRAs. This means having an HRA that indicates a time component that specifies when the HRA can be safely removed from storage. For example, in a system with limited duration credentials / tests, this can be achieved: (1) by having a credential / proof include an expiration time after which the credential / proof must not be admitted through the door as valid for its access; (2) have an HRA that cancels the credentials / proof that include the expiration time and (3) have the door delete from its memory the HRA that cancels the credentials / tests after the expiration time. For example, the expiration time for a credential / proof could be the time at which the credential / proof expires (and the expiration time could be explicitly included and authenticated within the credential / proof or could be implied by conventions at the level of system). The elimination of said HRA after its expiration time has elapsed does not undermine security. Actually, if the door does not memorize the HRA that cancels a particular credential / proof, it may be because the door deleted the HRA from memory after its expiration, at which time the obsolete credential / proof will have its access denied by the door in any way.

It should be noted that step (2) above may be optional in cases where the expiration time can be indicated in an HRA implicitly or indirectly. For example, the HRA may take the form GIS (C, "CANCELED", AI), and credentials / tests may include its own expiration date. In addition, step (1) above may be optional since removable HRAs can also be performed with HRAs that do not indicate expiration times for credentials canceled at all. For example, if all credentials, in a particular system, are valid for a maximum of one day, in that case, all HRAs can be deleted after being memorized for one day. (More generally, if the maximum duration of a credential / proof can be deducted in some way, then a corresponding HRA can be deleted after being memorized for that amount of time). As another example, when presented with the credential / test with a particular expiration time, the door can search for an HRA that cancels the credential. If it exists and the expiration time has already elapsed, then the door can safely eliminate the HRA. In any other case, the door can memorize the expiration time in relation to the memorized HRA and eliminate the HRA after that time.

A door can eliminate HRAs after expiration in a variety of ways. In some cases, HRA removal can be done efficiently by maintaining a data structure (such as a priority queue) of HRAs based on expiration times. Alternatively, the door can periodically review all memory HRAs and purge those that are no longer needed. As another alternative, the door can erase an HRA if, when it finds the HRA, the door finds that the HRA is no longer relevant. For example, HRAs can be memorized in a list that is checked every time a credential is presented for verification. Whenever an expired HRA is on that list, the expired HRA can be deleted. In another alternative, the door can eliminate HRAs only when necessary, when memory needs free space (perhaps for other HRAs).

Removable HRAs can greatly reduce the storage capacity required at the door. Using the previous example of 10,000,000 users and an annual cancellation rate of 10%, in this case, if the HRAs expire and are eliminated, on average, in one day, only 2,740 (instead of 1,000,000) , it may be necessary to memorize the HRAs. This reduced storage requirement is a great potential advantage of removable HRAs.

It is useful for HRAs to make themselves available for doors as quickly as possible, in order to inform the doors of credentials / evidence that are no longer admissible. This can be a problem for disconnected doors, but it can also be a problem for fully connected doors. Of course, an HRA can be sent to a fully connected door through the door connection when the HRA is issued. However, this transmission can still be blocked or hindered by a particular intruder (eg, if the connection to the door is secured by cryptographic means, an intruder can simply cut the connecting wire or modify / filter the displacement signals. the door is secured by installing a connecting wire in a steel tube, so such obstruction and blockage may be more difficult, but still not impossible). Such another obstacle and malicious blocking of an HRA may be even easier to perform for doors with intermittent connectivity (e.g., wireless).

In order to make it more difficult for an intruder to prevent a door from receiving an HRA, an HRA can be transmitted by its own canceled card. For example, when a card communicates with a database or a connected door (or any door that has knowledge of the relevant HRA), the door can send the HRA to the card, which can memorize the HRA. In particular, this operation can be performed without any indication to the user for the purpose of protection against users who may wish to individually manipulate the card and eliminate the HRA. This method is more effective if the card transmits a tamper-proof hardware component or data (e.g., encrypted data) that is not easily read / deleted by the user. When the card is subsequently used in an attempt to access any door (even completely disconnected), the card can communicate its HRA to the door, which, after proper verification, may deny access (and, in some cases, memorize the HRA).

The HRA can be sent via a wireless channel (e.g., through a pager device or a cellular or satellite network) to the card. This operation can be performed even if the card has limited communications capabilities - for example, by placing a wireless transmitter in a place where each user is likely to pass. For example, in a building, said transmitter can be placed at each entrance of the building to provide an opportunity for each card to receive the transmission whenever a user of one of the cards enters the building. Alternatively, the transmitter can be located at the entrances of the parking lot, etc.

To prevent a malicious user from blocking the transmission (by, for example, wrapping the card in material that is impenetrable by the transmitted signal), the card may, in fact, require that it receive periodic transmissions in order to function properly. For example, the card can wait for a signal every five minutes to be able to synchronize its clock with that of the systems, or it can expect to receive another periodic signal (preferably with digital signature) such as a GPS signal, or simply wait for an appropriate noise to the appropriate frequencies If this signal is not received with a reasonable time interval, the card can be "blocked" and simply reject communication with any door, which makes it unfit for access. It should be noted that such a system can be more economical and convenient than simply spreading all the HRAs for all the cards, because the HRAs are personalized and continuously changing messages. Thus, the dissemination of HRAs to all cards may require the establishment of a special-use satellite or the customization of an existing one. The previous method, on the other hand, has the advantage of already having signals for wide transmissions and installs local level transmitters for personalized messages.

Alternatively, a user can be prevented from blocking transmissions to a card if the security police require the user to carry the card in a visible place, such as a security identification card or to present it in a suitable place (within a margin of transmission) to a watchman. An additional technique for disseminating an HRA for a particular card / credential / proof may include the use of OTHER cards to transmit the HRA to the doors. In one of its versions, Card 1 can (eg, when you collect your own credential / test daily or wirelessly or when communicating with a connected door or when making any kind of connection) receive an HRA, HRA2, that cancels a credential / proof associated with a different card, Card 2. Card 1 can then memorize HRA2 and communicate HRA2 to a door, which then also memorizes HRA2. Card 1 can, in fact, provide HRA2 to multiple doors, for example, to all doors or to all disconnected doors that are accessed or communicated with Card 2 for a particular period of time (eg, for a full day ). At this point, any door (even when disconnected), reached by Card 1 may be able to deny access to the Card 2 holder that contains the canceled credential / proof. In a preferred embodiment, HRA2 has a digital signature or its own authentication and any door reached by Card 1 verifies the authenticity of HRA2, so as to prevent the malicious diffusion of false HRAs.

The above can be perfected by having a door reached by Card 1 communicate the HRA2 learned to another card, Card 3, which subsequently accesses or communicates with the door. This is useful because Card 3 can reach doors that Card 1 will not reach or do so after Card 3. This process can continue making these additionally reached doors communicate with other cards, etc. In addition, it is possible that some doors, even if they are not completely connected to a central database, may have connections to each other. Such doors, in this way, can exchange available HRAs in a similar way. If the cards have a capacity to communicate with each other, for example, when they are in proximity, they can also exchange information about the HRAs they memorize.

It should be noted that authenticated HRAs can be especially advantageous with the HRA dissemination techniques examined here. In reality, sending HRAs through multiple intermediaries (cards and doors) can provide multiple points of failure where the HRAs can be modified or false HRAs that can be injected by an intruder. In a sense, unauthenticated HRAs can become simple rumors the moment they reach the doors. On the contrary, authenticated HRAs can be guaranteed to be correct no matter what the doors reach.

In those cases where resources are not a major concern, all HRAs could be memorized and disseminated in this way. It may also be possible to adopt some organizations. For example, a card can manage HRA storage as a door and eliminate expired HRAs to free up internal card memory and to avoid unnecessary communication with other doors. Minimizing storage and communication tasks can be useful within that system because, when the number of canceled credentials not expired may be small, it is possible that some components (eg, some cards or doors) may not have enough memory or bandwidth to manage all non-expired HRAs.

Another possibility to minimize storage and communication tasks includes the selection of which HRAs are to be disseminated through which cards. For example, HRAs may contain priority information, which indicates the relative importance of disseminating knowledge about a particular credential / proof as quickly as possible. For example, some HRAs may be labeled as "urgent" while others may be labeled as "routine." (A priority ranking can be as fine or approximate as appropriate.) Devices with limited memory or bandwidth can record and exchange information about the highest priority HRAs and only if resources allow, can they devote their attention to the lowest priority. By way of another example, an HRA that prevents a card from accessing a given door can be disseminated through cards that are more likely to reach that door quickly (eg, cards whose credentials allow access to that door or doors in its proximity). Actually, the card and the door can establish a communication with the objective of establishing which HRAs support their storage and / or subsequent diffusion. Alternatively, the HRAs or cards for their memorization can be selected in a way that implies a randomness or a door can provide an HRA for a certain number of cards (eg, the first k cards that the door "finds").

The use of such diffusion techniques can reduce the likelihood that a user with canceled credentials / tests will be able to obtain access since, even for a disconnected door, a user would have to obtain from the door, before any other user provides HRA suitable with an update card. The exchange of information between cards and doors can help ensure that numerous cards are quickly informed of a cancellation. This method can also be used as a countermeasure against “impeding” attacks that attempt to disconnect a connected door and prevent the door from receiving the HRA. Even if such an attack is successful and the door is never informed of the HRA by the central servers or responders, an individual user card can probably inform the HRA door in any other way. It should be noted that the actual method of exchanging HRAs between cards and doors may vary. In the case of short-term HRAs, it may be more efficient to exchange and compare all known HRAs. If numerous HRAs are put together in a single list, the list may contain a time that indicates when the list was issued by the server. In that case, cards and doors can first compare the issuance times of their HRA lists and whichever is the oldest list can be substituted with the most recent list. In other cases, more sophisticated algorithms can be used to find and reconcile differences.

An efficient HRA broadcast can be done:

(one)

issuing an authenticated HRA;

(2)

sending the authenticated HRA to one or more cards;

(3)

having the cards sent the authenticated HRA to other cards and / or doors;

(4) by having the doors memorize and / or transmit the received HRAs to other cards. It can be useful, in detail, some use of HRA shows:

SEQUENCE 1 (directly from the "authority" at the door):

one.

Entity E cancels a credential / proof for a user U and issues an HRA A containing the information that the credential / proof has been canceled;

2.

A is transmitted through a wired or wireless combination to a gate D;

3.

D verifies the authenticity of A, and if the verification is successful, it memorizes the information about A;

Four.

When U attempts to access D by presenting the credential / proof, gate D observes that the information memorized on A indicates that the credential / proof is canceled and access is denied.

SEQUENCE 2 (from "authority" to a user card for the door):

one.

Entity E cancels a credential / proof for a user U and issues an HRA A containing the information that the credential / proof has been canceled;

2.

Another user U 'informs that he is going to work and preset his card for E in order to obtain his current credential / proof;

3.

Together with the credential / proof for U ', HRA A is transmitted to the user card U'; the card memorizes A (the card may or may not verify the authenticity of A, depending on the capabilities of the card itself);

Four.

When U 'tries to access a gate D, his card transmits the credential / proof along with A to D;

5.

D verifies the authenticity of A and, if the verification is successful, memorize A;

6.

When user U tries to access D by presenting a credential / proof, gate D observes that A has the cancellation of the credential / proof of user U and denies access.

SEQUENCE 3 (from "authority" to another door for a user card at the door):

one.

Entity E cancels a credential / proof for a user U and issues an HRA A containing the information that the credential / proof of U ’has been canceled;

2.

A is transmitted through a wired or wireless combination to a gate D ';

3.

D 'verifies the authenticity of A and, if the verification is successful, memorize A;

Four.

Another user U ', with his own credential / proof, presents his card to the door D' in order to gain access to D '. Gate D ', in addition to verifying the credentials / tests of user U' and granting access if appropriate, transmits A to the U 'card. The card memorizes A (the card may or may not memorize the authenticity of A, depending on the card's capabilities);

5.

When user U 'tries to access a gate D, his card transmits his own credential / proof along with A to D;

6.

Door D 'verifies the authenticity of A and, if the verification is successful, memorize A;

7.

When user U attempts to access door D by presenting his / her credential / proof, door D observes A, canceling the user's credential / proof U and denies access.

SEQUENCE 4 (from the "authority" to the user card in the door):

one.

Entity E cancels a credential C for a user U and issues an HRA A containing the information that C has been canceled;

2.

The user U, bearer of his card, passes a transmission point located near the entrance of the building, which causes his card to receive A; the card memorizes A (the card may or may not verify the authenticity of A, depending on the card's capabilities);

3.

When U tries to access a gate D, his card transmits A along with C to D;

Four.

D verifies the authenticity of A and, if the verification is successful, memorize A and deny access to user U;

5.

If user U tries again to access D by presenting C, gate D observes the previously memorized A that cancels C and denies access.

Sometimes, it may be useful to establish, after the fact, that you tried to access a particular door, at what time, what credentials / tests were presented and if access was denied or granted. It may also be useful to know if the mechanism of a door became hindered, if a switch or sensor had failures, etc. For this purpose, it may be desirable to keep records of the events that take place. Such records can be particularly useful if they are readily available at any central location, so that they can be inspected and acted upon accordingly. For example, in case of hardware failure, a repair team may need to move promptly. There are, however, two important problems with such records.

First, if a door is connected, it may be easier to collect records by sending them through the connection. However, collecting event logs can be more difficult for disconnected doors. Of course, one way to collect records is to send a person for each disconnected door to physically deliver the records back to the central location, but this method is expensive.

Secondly, for an event log to be created, the integrity of the entire system surrounding the generation, collection and storage of the records must be guaranteed. Otherwise, for example, an intruder can create false registry entries or delete valid ones. Traditional methods, such as physically securing distribution channels and data storage facilities, are very expensive (and may not be sufficient by themselves).

Conventional registries can verify that "a certain user was moved to a certain door" by the mere existence of said registry entry, which must be assumed to be valid. However, this may not be appropriate for a high security application. Consider the case of a user U accused of deteriorating some property behind a locked door D. A traditional registry entry can only provide weak evidence that U entered through D: he would have to trust that no entry was made. maliciously falsified record. Consequently, it is desirable to have records that provide much stronger evidence, because they cannot be "fabricated" by an intruder. In particular, indisputable records can prove that gate D (possibly with the cooperation of user card U) created the record in its agenda.

The system described here solves this problem as follows: When a door receives a credential / proof presented as part of an access request, the door can create a registry entry (eg, a data string) that contains information about the event, for example:

Request time; Type of request (if more than one request is possible - for example, if the request is for departure or for entry or to activate or deactivate the engine, etc.); Credential / proof and identity presented (if any); If the credential / proof was successful in its verification; If the credential / proof had a corresponding HRA; If access was granted or denied.

The log entries may also contain operational data or information on any unusual events, such as voltage current fluctuations, sensor failures, switch positions, etc. One way to obtain an indisputable record includes making the doors have event information with digital signature through a secret key (SK). The resulting indisputable record can be represented by GIS (event, AI), where AI means any additional information. The signature method used by gate D can be a public key or a private key.

If it were useful to highlight the public key PK relative to the validity of the signature, or the secret key SK used in the generation of the signature or the door that generated the signature, the record undisputed by SIGPK (event, AI) could be represented symbolically ), SIGSK (event, AI), or SIGD (event, AI). Such registration can be indisputable because an intruder cannot falsify the signature of the door without knowing the relevant secret key. In another way, the authenticity of the registry could be verified by any adequately informed verifier (eg one that knows the PK key of the door or the SK key of the door) without having to rely on the integrity of the database it stores the record or that of the system transmitting the record. In general, registrations can be made indisputable not only by digitally signing each entry, but also using a digital authentication stage for multiple entries. For example, the door could authenticate a multiplicity of events E1, E2, ... by means of a digital signature: symbolically, SIG (E1, ... E2, AI). As usual, anywhere in this application, a digital signature can mean the process of the digital signature of the unidirectional hash of the data to be authenticated. In particular, continuous authentication can be considered as a special case of digital signature. For example, each authenticated entry could be used to authenticate the next (or the previous one). One way to do this is to have an authenticated entry include the public key (in particular, the public key of a one-time digital signature) used to authenticate the next or other entries.

Ordinary registrations and indisputable registrations can also be made by means of cards (in particular, a card can be made an indisputable record by means of information with digital signature on an event E: in symbols, SIG (E, AI)). All of the registration techniques, described here, can also be interpreted as related to registrations made of cards.

In addition, other ordinary records and indisputable records can be obtained by involving the door and the card. For example, during a door access request, the card may provide the door with the card registration entry itself (possibly undisputed) to the door. The door can inspect the registry entry and grant access only if the door finds that the registry entry is "admissible." For example, the door can verify the digital signature of the card that authenticates the registration entry or the door can verify that the time information included in the card registration entry is correct based on a clock accessible to the door.

Other types of indisputable registrations can be obtained by having the door and the card contribute to the generation and / or authentication of a registry entry. For example, the card can authenticate a registration entry and the door can then also authenticate at least part of the registration entry information and vice versa. In a particular embodiment, a card C can provide the door with its signature, x = SIGC (E, AI), of the registration entry, which the door will contrafirm in symbols, SIGD (x; AI ') and vice versa. Alternatively, the door and the card can calculate a joint digital signature of the event information (eg, calculated by means of a secret signature key divided between the door and the card or by combining the signature of the door with that of the card in a single "multifirma"). Several multifirma systems can be used in particular those of Micali, Ohta and Reyzin.

It is possible to include additional information in the records. You can then check if the information that communicates with the card and that communicates with the door agrees. For example, the card and the door can include weather information in the registration entries, using clocks available in this regard. In addition, the card (and possibly also the door) may include location information (such as that obtained from GPS) in the registration entry. Alternatively, if the current location is not available (e.g., because GPS reception capability is unavailable), information on the most recent known location (and possibly how long it has been from your establishment) may be included. Thus, particularly in the case of a mobile door (such as the door of an airplane), it may be possible to establish where the door and the card were located when the event occurred.

Of course, even an undisputed registry entry, like the one above, can be maliciously deleted from the database or prevented from reaching the database together. To protect against such deletions, it is useful to provide detectable suppression recording systems. These systems can be built using:

(1) an authentication system (e.g., a digital signature system), (2) a generation-correlation system and (3) a detection-correlation system as follows. Given an E record event (part of a sequence of possibly past and / or future events), the generation-correlation system can be used to generate correlation information CI, which is then safely linked to E through generation-correlation system that can guarantee that, even if the events themselves are not correlated and the existence of an event cannot be deduced from the existence of other events, CI is generated in such a way that guarantees that for the registry entries nonexistent, no properly correlated information is presented, which can be detected using the detection-correlation system. In some cases, the system can also guarantee that even if some registry entries are missing, others can be guaranteed as authentic / individually indisputable.

In a first example, the correlation information CI of the registry entries may include sequential numbering of said registry entries. The corresponding detection-correlation system may consist of notifying the presence of an operational gap in the numbering sequence. However, to have a detectable deletion registration system, an appropriate link is found between CI and the registry entries, which may not be easy to perform, even when secure digital signatures are used for the authentication component of the system. For example, having the i-th registry entry consisting of (i, SIG (event, AI)), is not safe, because an intruder could, after deleting a registry entry, modify the numbering of subsequent entries so that hide this operational gap. In particular, after deleting the registration entry number 100, the intruder may decrease the number of registration entries 101, 102, etc. by one. The intruder can thus hide his deletions because, even if the integrity of the event information is protected by a digital signature, the numbering itself may not be. In addition, even with the digital signature also the numbers may not work properly. For example, suppose that the i-th registry entry consists of (SIG (i), SIG (event, AI)). In such a case, an intruder could: (1) observe and remember GIS (100), (2) suppress input number 100, (3) replace GIS (100) instead of GIS (101) in original input 101, while remembering GIS (101), and so on, so that it completely conceals the suppression.

Neither of the above two methods produces the desired secure CI link and registry entries. Actually, by safely linking (1) the numbering information together with (2) the numbering event, it is intended to highlight that an intruder cannot obtain the link of any number j together with the information of the event about the i-th event Ei, when j is different from i, even if it is provided with (a) a secure link of number i and Ei and (b) a secure link of number j and Ex. For example, the i-th entry of Registration can consist of GIS (i, Ei, AI). In this way, the deletion of the i-th registry entry will be detected given the subsequent registry entries. This is because a subsequent registry entry can transmit with it a number greater than i, which cannot be deleted, modified or switched with other registration entry numbering information by the intruder, because it is securely linked to the entry register. For example, assuming the intruder deletes the registry entry number 100: SIG (100, E100, AI). As long as the intruder cannot delete all subsequent registry entries (which could require continuous access to the database), to hide its deletion, the intruder would need to create another registry entry with the same number 100. However This can be difficult because (a) the intruder cannot generate a new 100-next mark of GIS registration entry (100, E ', AI') since it does not have the secret door signature key; (b) the intruder cannot modify an existing registry entry without invalidating the digital signature (eg, it cannot change SIG (101, E101, AI101) in GIS (100, E101, AI101) even if it remembers the suppressed entry SIG (100 , E100, AI100)); (c) the intruder cannot extract a signature from a part of the registry entry that indicates the number 100 and link it with a digital signature for another registry entry.

Said secure linking can also be achieved through other digital signatures along with the entry number and the numbering event. For example, it can be achieved through a unidirectional hashing-summary function of the entry number and the event that is numbered and then, symbolically sign the hash, with SIG (H (i, Ei, AI)). As another example, it can be achieved by including the hash function of the number in the digital signature of the event or vice versa: e.g., symbolically SIG (i, H (Ei), AI)). It can also be obtained by signing the numbering information together with the digital signature of the event information: e.g., symbolically GIS (i, SIG (Ei), AI)). In another alternative, the numbering information can be signed separately (1) along with a single string x, and (2) the event information along with the string x, symbolically (SIG (i, x), SIG (x, Ei, AI)). (This string x could be a random data called nonce).

Detectable deletion records can also be achieved by secure linking with the correlation input of the record entry other than the sequential numbering information. For example, some identification information can be included in the registry entry and from a previous registry entry, for example, the i-1 entry. Said information may be a collision-resistant hash function of input i-1 (or a part of log entry symbolically, the log entry i can be represented as SIG (H (log entry i + 1), Ei, AI Then, if the intruder tries to delete the registry entry, such deletion would be detected when the registry entry i is received, because the hash function of the previously received registry entry, H (registry entry i-2), does not it would coincide with H (I-1 registration input) (due to the collision resistance of H), while H (I1 registration input), since it is securely linked to I-registration input, could not be modified by the intruder without destroying the validity of a digital signature In this case, by registration entry i can also mean a subset of your information, such as Ei.

It should be noted that the i-1 registry entry is not needed whose information is linked to the i entry: it may be another previous or future entry or, in fact, a multitude of other entries. In addition, which registry entries are linked to those that can be chosen with the use of randomness.

Other correlation information can also be used. For example, each registry entry i may have been securely linked to two values (e.g., random values or nonces) xi and xi + 1: symbolically, e.g., GIS (xi, xi + 1, Ei, AI). Then, two consecutive registry entries can always share a single x value; for example, the i and i + 1 entries will share xi + 1. However, if a registry entry is deleted, it will no longer be maintained (since the intruder cannot modify the signed registry entries without detection, unless he knows the secret key for the signature). For example, if the entry number 100 is deleted, the database will contain GIS (Xgg, x100, E99, AI) and SIG (x101, x102, E101, AI) and it can be seen that they are not sharing a common x value . Such correlation information may take other forms: in fact, a registry entry may be correlated with multiple other registry entries. This can be done, in particular, by using polynomials to generate correlation information (e.g., two or more registry entries can each contain the result of evaluating the same polynomial on different entries). Such correlation information can also make use of a hash string of functions: for example, starting with a value y1, which allows y2 = H (y1), y3 = H (y2), ... etc. and then, securely linking yi to Ei: e.g., the i-th registry entry can be symbolically represented as GIS (yi, Ei, AI). Then, consecutive registry entries i and i + 1 can have correlation values yi and yi + 1 so that yi + 1 = H (yi). If the intruder deletes a registry entry, however, it can no longer be maintained and consequently, the deletion can be detected. For example, if entry 100 is deleted, the database will contain SIG (y99, E99, AI) and SIG (y101, E101; AI) (which, as before, cannot be modified by the intruder without distorting the signatures digital). Then, suppression can be detected because H (y101) will not match y99. The use of multiple hash-summary function chains, perhaps non-consecutive entries used and in both directions, can also provide such correlation information.

In another embodiment, each registry entry may contain an indication of some or all of the previous or even subsequent events, so that the realization of records will not only be with detectable deletion, but also rebuildable in case of deletions. Rebuildable record systems can be constructed using: (1) an authentication system (e.g., a digital signature system), (2) an information generation-reconstruction system and (3) a reconstruction system as follows. Given an E record event (part of a sequence of possibly past and / or future events), the information generation-reconstruction system is used to generate RI reconstruction information, which is then linked securely to other inputs Registration through the authentication system. The information generation-reconstruction system guarantees that, even if the registry entry corresponding to event i is lost, other registry entries contain sufficient information about E, so they will allow the reconstruction of E from the RI information present in Other registry entries. For example, the i + 1-next entry may contain information about all or some of the previous events, which is generated by the information generation-reconstruction system. Therefore, if an intruder succeeds in deleting the j-th entry from the database, the information about the j-th event Ex will be displayed in one or more subsequent entries, which will allow the reconstruction of The information eg even in the absence of the j-th registration entry, using the reconstruction system. In this way, it would not be enough for an intruder to have temporary access to the database: he would have to control the database "at all times" and delete multiple registry entries to prevent the disclosure of information about the next event. . The choice of what events to include in a log entry can be made by the information generation-reconstruction system in a random way, which would make it more difficult for an intruder to predict when information about a given event will appear in successive records. In a preferred embodiment, the system for rebuildable events may also be susceptible to suppression detection and indisputable.

It should also be noted that the reconstruction information about the event j included in another registry entry does not need to be direct. It may consist of a partial entry jo its hash function value hj (in particular, calculated by the information generation-reconstruction system through a collision-resistant / unidirectional hash function), or its digital signature or any other indication. In particular, if a collision-resistant / unidirectional H hash function is used, then it will be possible to reestablish, indisputably, information about the j-th event from a registry entry i containing hj: symbolically, if the i- next entry is signed, the corresponding indisputable record can take the form GIS (hj, Ei, AI). For example, if it is suspected that a particular user entered through a particular door at a particular time, it is possible to check if the value hj coincides with that of the hash function H (Ex) of a registry entry Ex, which would have created in response to that event. This is indisputable due to the collision resistance property of H: the appearance of an input E'j different from Ex is essentially impossible, such that: H (E'j) = H (Ex).

The registry entries Ex can be created in such a way as to make it easier for someone to guess (and therefore verify), what the registry entry should be for a given event (for example, using a standardized format for the registry entries , using an approximate temporal granularity, etc.). A unidirectional hash function may be useful in particular because of its small size: it may be possible to perform the hash function of numerous or even all previous registry entries for inclusion in a later entry. For example, the input i + 1 can include h1 = H (E1), h2 = H (E2),…. hi = H (Ei). Alternatively, the grouping of (some of) the hash functions can be done, thereby reducing the amount of space required. For example, if they are grouped in their entirety, in that case, the second registry entry would include h1 = H (E1), the third registry entry would include h2 = H (E2, h1) .....

In this way, the registry entries 1 to i-1 and the registry entry i + 1 can be reconstructed or observed, then the registry entry i can be indisputably reconstructed. This system can be improved by encrypting (part of) the information in a registry entry (eg, with a key known only to the database), so that the intruder cannot know what information he must destroy to put in compromise the possibility of rebuilding a particular event: in reality, once the record is protected by encryption, said encrypted records (preferably undisputed encrypted records) can be sent to another (second) database without any loss of privacy. This makes deletions even more difficult for an intruder: you now have to get access to two or more databases to falsify records.

Rebuildable records can also be achieved through the use of error correction codes. In particular, this can be done by generating multiple components ("shares") of each registry entry and proceeding to send them separately (perhaps with other registry entries) in such a way that, when a sufficient number of shares has been received, The registry entry can be rebuilt using the rebuild system, which can invoke a decoding algorithm for the error correction code. These participations can be dispersed randomly or pseudo-randomly, which makes it even more difficult for the intruder to eliminate a sufficient amount of it to prevent the reconstruction of a registry entry when sufficient participations occasionally arrive.

Event logs (created by cards, by doors or jointly by both) can be transmitted by cards to facilitate their collection. When a card reaches a connected door, or communicates with a central server or in any other way, it is able to communicate with the central database, it can send the records it memorizes. This operation can be performed, similarly, for the dissemination of HRAs, with the exception that HRAs can be sent from a central point to a card, while records can be sent from the card to the central point. All HRA dissemination methods, therefore, apply to the collection of event records. More specifically, a method for disseminating HRAs can be transformed into a method for collecting event records (1) by replacing a sender with the receiver and vice versa; (2) replacing an HRA with a registry entry.

In particular, a C1 card can collect event logs for non-C1 related events, such as access by another C2 card, or an anomalous operation of a D gate. In addition, the event logs for a D1 gate can be memorized. (maybe temporarily) on another D2 gate (maybe transmitted by a C1 card). Then, when another C2 card is in communication with D2, you can receive some of these registry entries and later, communicate them to another door or to a central position. This wide dissemination can ensure that event logs reach, more quickly, the central point. (In addition, it is possible that some doors, even if they are not completely connected to a central database, may have connections to each other. Such doors can thus exchange available event logs in a similar way. If the cards have an ability to communicate with each other - eg, when they are in proximity - can also exchange information about the events records they memorize). In said collection process, the indisputable records are advantageous, since they do not need to be transmitted through secured channels, given that they cannot be falsified. Therefore, they do not need to rely on the security of cards or connections between cards and doors. Records with detectable deletions provide additional advantages by ensuring that, if some registry entries are not collected (perhaps because some cards never reach a connected door), this fact can be detected. Rebuildable records can also allow reconstruction of registry entries in case some registry entries do not reach a central database (again, perhaps because some cards never reach a connected door).

In some cases, all event logs could be memorized and disseminated in this way. Otherwise, it may be useful to adopt some optimizations. An optimization method is to make the event logs arrive with priority information, thus indicating the relative importance of informing a central authority about a particular event. Some registry entries may be of more urgent interest than others: For example, if a door is fixed in an open or closed position, if unauthorized access is attempted or if an unusual access model is detected. In order to accelerate the delivery of such important information to the place where it can act, the information in the access records can be provided with labels that indicate its importance (or its importance can be deduced from the information itself). For example, some registry entries can be labeled "urgent" while others can be labeled "routine" or they can be tagged by numbers or code words, indicating their degree of importance. (A gradation of priorities can be as fine or approximate as appropriate), more effort or higher priority can be devoted to disseminating information of the greatest importance. For example, higher priority may be given in the information for more cards and / or doors in order to increase the probability that they reach their destination more quickly or safely. In addition, a card or a door, when receiving high priority information, can dedicate space for it by eliminating low priority information from its memory. Similarly, a door may decide to give high priority information to each card that passes through it, while it may provide low priority information to only a few cards or wait until the moment the door is connected.

Alternatively, or in addition to the prior art, cards can be selected to memorize particular registry entries in such a way as to imply randomness or, a door can provide a registration entry to a certain number of cards (eg, the first k cards you "find"). The use of such dissemination techniques can greatly reduce the likelihood that an important entry, in an event log, will be unable to reach the central point where it can act. In particular, it can be used as an effective countermeasure against “obstructing” attacks that attempt to prevent a broken door from communicating this circumstance. The actual method of exchanging records between cards and doors may vary depending on the circumstances. In the case of a few entries, it may be more efficient to exchange and compare all known entries. In other cases, more sophisticated algorithms to find and reconcile differences may be appropriate.

It may be useful to present, in detail, some sample forms in which event records can be collected. Next, the term "authority" A includes some central point or database where records of events are collected.

SEQUENCE 1 (directly from the door to the authority):

one.

The connected door D creates an undisputed log entry E, in response to an event.

2.

Registration entry E is transmitted, by wired or wireless combination, to authority A.

3.

Authority A verifies the authenticity of E and, if the verification is successful, memorize E.

SEQUENCE 2 (from the door to a user card and to the authority):

one.

Gate D creates an undisputed registry entry E in response to an event.

2.

A card C of a user U, which is presented for access to the gate D, receives and memorizes E (in addition to the access related communication). The card can verify, or not, the authenticity of E.

3.

When user U leaves his job and presents his card to A at the end of the business day, E is transmitted to A through the card.

4. A verifies the authenticity of E and, if the verification is positive, memorize E.

SEQUENCE 3 (from the door to a user card to another door (connected) to the authority):

one.

Gate D creates an undisputed registry entry E, in response to an event.

2.

A card C of a user U, which is presented for access to the gate D, receives and memorizes E (in addition to the access related communication). The card can verify, or not, the authenticity of E.

3.

Later, user U presents his card C for access to another (connected) door of D '. Door D ', in addition to verifying credentials and granting access, if appropriate, receives E from C. Door D' can verify, or not, the authenticity of E.

Four.

E is transmitted through gate D 'through a wired or wireless combination to authority A.

5.

A verifies the authenticity of E and, if the verification is positive, memorize E.

Protected areas can be defined by physical walls and doors, such as doors through which a person or doors can enter a container, a safe, a vehicle, etc. Protected areas can also be defined by virtual doors and walls. For example, a zone can be protected by a detector that can detect an intrusion and possibly sound an alarm or send another signal if the corresponding authorization is not provided. Said alarm system is an example of a virtual door: in an airport, the door area is usually penetrated through an exit corridor which will trigger said alarm, even if no physical door or wall has been violated. Another example of a virtual door is a toll booth: even if many toll booths do not contain physical bars or gates, a given vehicle may or may not be authorized to pass through the cab. Such authorization may depend, for example, on the validity of an electronic toll payment form for a vehicle. Another example is that of a traffic control zone. For example, to enter the suburbs of a given city, or on a road leading to a nuclear installation, an army barrier or other sensitive area, a vehicle must have adequate authorization, for purposes such as billing, security or control. of traffic congestion.

In addition, protection may not be necessary only for areas, but also for devices, such as aircraft engines or military equipment. For example, it may be necessary to ensure that only an authorized person can start the engines of an aircraft or a vehicle that carries hazardous materials.

There are numerous ways to use credentials / tests for access control. It should be noted that, in these areas, the term "day" should be understood as meaning a general period of time in a sequence of time periods and the term "tomorrow" means the beginning of a period of time.

Throughout this patent application the term "doors" should be construed as including all types of access areas (e.g., physical and / or virtual), access control devices / systems and monitoring devices / systems. In particular, they include the locked mechanisms used for starting engines and control equipment (so our invention, in particular, can be used to ensure that only users with current authorization can start an aircraft, operate an excavator or otherwise, access and control various dangerous and / or valuable items, as well as devices and machinery elements). Consistent with this agreement, we will refer to the "entry" as being granted for the desired access (physical or virtual).

Similarly, for greater specificity, but without loss of anticipated generality, a card can be understood as meaning any user access device. It is to be understood that the notion of a card is general enough to include mobile phones, PDAs and other wireless devices and / or advanced technology and a card may include or act in conjunction with other security measures, such as PIN numbers, passwords and biometrics, although some of them may "reside" in the brain or body of the holder and not on the card itself.

In addition, the expression "user" (usually referred to as "he" or "she"), in broad terms, can be understood to encompass not only users and people, but also devices, entities (and sets of users, devices and entities) including, without limitation, user cards.

The system described herein can be implemented using any suitable combination of hardware and software including, without limitation, the software memorized on a computer-readable media that is accessed by one or more processors. In addition, the techniques used for encryption, authentication, etc. They can be combined and used interchangeably, when convenient.

Claims (25)

1. An access control method, comprising: the use of an access barrier provided with a controller that allows selective access; at least one administration entity that generates identity credentials and identity proofs, where the credentials include a final value and a date, where the final value is obtained by applying, several times, a unidirectional function to a random value, each being One of the tests associated with a particular time interval, where different tests are obtained by applying the unidirectional function to the random value, in a different number of times, where a test to be presented to the controller at a given time, is the result of applying the unidirectional function to a test to be presented to the controller in the future; the controller receives the identity card of at least one of the tests corresponding to the access attempt made by a user; In response to the attempt of access by the user, the controller determines if the access is currently authorized by applying the unidirectional function to at least one of the tests, a certain number of times and comparing the result with the final value, corresponding the number of times to a duration of time elapsed since the date associated with the credentials and If access is currently authorized, the controller authorizes access.

2.

A method according to claim 1, wherein the credentials and proof of identity are a single part.

3.

A method according to claim 1, wherein the credentials and tests are distinct parts.

Four.

A method according to claim 3, wherein there is a first administration entity that generates the credentials and other administration entities that generate the identity proof.

5.

A method according to claim 4, wherein the first administration entity also generates proof of identity.

6.

A method according to claim 4, wherein the first administration entity does not generate evidence.

7.

A method according to claim 1, wherein the credentials correspond to a digital certificate.

8.

A method according to claim 7, wherein the digital certificate includes an identifier for the electronic device.

9.

A method according to claim 1, wherein the credentials include an identifier for a user requesting access.

10.

A method according to claim 1, wherein the identity credentials / proofs include a digital signature.

eleven.

A method according to claim 1, wherein the access barrier includes walls and a door.

12.

A method according to claim 11, further comprising:

A door lock coupled to the controller, wherein the controller, which allows access, includes the controller that operates the door lock to allow the opening of said door.

13.

A method according to claim 1 further comprising: provide a reader coupled to the controller, where the controller receives credentials / proofs from the reader.

14.

A method according to claim 13, wherein the credentials / proofs are provided on a smart card presented by a user.

fifteen.

A method according to claim 1 further comprising: providing an external connection to the controller.

16.

A method according to claim 15, wherein the external connection is intermittent.

17.

A method according to claim 15, wherein the controller receives at least a portion of the identity credentials / proofs using the external connection.

18.

A method according to claim 17, wherein the controller receives all identity credentials / proofs using the external connection.

19.

A method according to claim 17, further comprising:

provide a reader coupled to the controller, where the controller receives a remaining portion of the credentials / proof of identity from the reader.

twenty.

A method according to claim 19, wherein the identity credentials / proofs are provided on a smart card presented by a user.

twenty-one.

A method according to claim 1, wherein the identity credentials / proofs include a password entered by a user.

22

A method according to claim 1, wherein the identity credentials / proofs include user biometric information.

2. 3.

A method according to claim 1, wherein the identity credentials / proofs include a handwritten signature.

24.

A method according to claim 1, wherein the identity credentials / proofs include a secret value provided on a card held by a user.

25.

A method according to claim 1, wherein the identity credentials / proofs expire at a predetermined instant.