EP1493131A2 - Commande d'acces physique - Google Patents

Commande d'acces physique

Info

Publication number
EP1493131A2
EP1493131A2 EP03726222A EP03726222A EP1493131A2 EP 1493131 A2 EP1493131 A2 EP 1493131A2 EP 03726222 A EP03726222 A EP 03726222A EP 03726222 A EP03726222 A EP 03726222A EP 1493131 A2 EP1493131 A2 EP 1493131A2
Authority
EP
European Patent Office
Prior art keywords
door
certificate
card
key
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP03726222A
Other languages
German (de)
English (en)
Inventor
Silvio Micali
David Engberg
Phil Libin
Leo Reyzin
Alex Sinelnikov
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Assa Abloy AB
Original Assignee
Corestreet Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/395,017 external-priority patent/US7337315B2/en
Application filed by Corestreet Ltd filed Critical Corestreet Ltd
Publication of EP1493131A2 publication Critical patent/EP1493131A2/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/20—Individual registration on entry or exit involving the use of a pass
    • G07C9/22—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder
    • G07C9/23—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder by means of a password
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/20—Individual registration on entry or exit involving the use of a pass
    • G07C9/22—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder
    • G07C9/25—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder using biometric data, e.g. fingerprints, iris scans or voice recognition
    • G07C9/257—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder using biometric data, e.g. fingerprints, iris scans or voice recognition electronically

Definitions

  • U.S. Patent Application No. 08/992,897 is also a continuation in part of U.S. Patent Application No.08/804,868, filed February 24, 1997, entitled TREE- BASED CERTIFICATE REVOCATION SYSTEM, (abandoned), which is a continuation of U.S. Patent Application No. 08/741,601, filed November 1, 1996, entitled TREE-BASED CERTIFICATE REVOCATION SYSTEM, (abandoned), which is based on U.S. Provisional Application No. 60/006,143, filed November 2, 1995, entitled TREE-BASED CERTIFICATE REVOCATION SYSTEM.
  • U.S. Patent Application No. 08/992,897 is also a continuation in part of U.S.
  • Patent Application No. 08/872,900 filed June 11, 1997, entitled WITNESS BASED CERTIFICATE REVOCATION SYSTEM, (abandoned), which is a continuation of U.S. Patent Application No. 08/746,007, filed November 5, 1996, entitled CERTIFICATE REVOCATION SYSTEM, (now U.S. Patent No. 5,793,868), which is based on U.S. Provisional Application No. 60/025,128, filed August 29, 1996, entitled CERTIFICATE REVOCATION SYSTEM.
  • U.S. Patent Application No. 08/992,897 is also based on U.S. Provisional Application No.
  • U.S. Patent Application No. 08/992,897 is also a continuation in part of U.S. Patent Application No. 08/756,720, filed November 26, 1996, entitled SEGMENTED CERTIFICATE REVOCATION LISTS, (abandoned), which is based on U.S. Provisional Application No.
  • the present invention relates to the field of digital certificates and more particularly to the field of digital certificate validation for controlling physical access.
  • a digital certificate consists of a certifying authority's (CA's) digital signature securely binding together several quantities: SN, a serial number unique to the certificate, PK, the public key of the user, U, the user's identifier, D ls the issue date, D 2 , the expiration date, and additional fields.
  • C SIG CA (SN, PK, U, D 1 , D 2 ,).
  • a CRL essentially consists of a CA-signed list containing all the serial numbers of the revoked certificates. The digital certificate presented with an electronic transaction is then compared to the most recent CRL. If the given certificate is not expired but is on the list, then everyone knows from the CRL that the certificate is not valid and the certificate holder is no longer authorized to conduct the transaction. Else, if the certificate does not appear in the CRL, then the certificate is deduced to be valid (a double negative). CRLs have not found much favor; for fear that they may become unmanageably long.
  • a CA answers a query about a certificate C by returning its own digital signature of C's validity status at the current time.
  • the OCSP is problematic in the following areas.
  • Each validity proof generated by the OCSP has a non-trivial length. If RSA or other factoring based signature schemes are used, such a proof in fact requires at a minimum 2,048 bits for the CA's signature.
  • a digital signature is a computationally complex operation.
  • the OCSP may require computing millions of signatures in a short time, which is computationally very expensive to do.
  • a system and method are disclosed for controlling physical access through a digital certificate validation process that works with standard certificate formats and that enables a certifying authority (CA) to prove the validity status of each certificate C at any time interval (e.g., every day, hour, or minute) starting with C's issue date, Di.
  • C's time granularity may be specified within the certificate itself, unless it is the same for all certificates. For example, all certificates may have a one-day granularity with each certificate expires 365 days after issuance.
  • a one-way hash function is utilized to compute values of a specified byte size that are included on the digital certificate and to compute other values that are kept secret and used in the validation process.
  • Controlling physical access includes reviewing real time credentials, where the real time credentials include a first part that is fixed and a second part that is modified on a periodic basis, where the second part provides a proof that the real time credentials are current, verifying validity of the real time credentials by performing an operation on the second part and comparing the result to the first part, and allowing physical access only if the real time credentials are verified as valid.
  • the first part may be digitally signed by an authority.
  • the authority may provide the second part or the second part may be provided by an entity other than the authority.
  • the real time credentials may be provided on a smart card. A user may obtain the second part of the real time credentials at a first location. The user may be allowed access to a second location different and separate from the first location.
  • At least a portion of the first part of the real time credentials may represent a one- way hash applied plurality of times to a portion of the second portion of the real time credentials.
  • the plurality of times may correspond to an amount of time elapsed since the first part of the real time credentials were issued.
  • Controlling physical access may include controlling access through a door.
  • FIG. 1 is a schematic illustration of how the CA sends to a Directory individual certificate revocation status information CRS, about each of its issued, but not-yet expired certificates Ci ... C , according to one embodiment of the invention
  • FIG. 2 is a schematic illustration of the sequence of transactions in a trivial
  • FIG. 3 is a schematic illustration a major "network bottleneck" in a server causing considerable congestion and delays;
  • FIG. 4 is a schematic illustration showing how OCSP has difficulties in servicing certificate validity requests originating from different security domains
  • FIG. 5 is a schematic illustration showing the servicing of certificate validity requests originating from different security domains according to one embodiment of the invention.
  • FIG. 6 is a schematic illustration of the RTC System according to one embodiment of the invention.
  • FIG. 7 is a schematic illustration showing how RTC-over-OCSP would be deployed in a cross-CA environment according to one embodiment of the invention.
  • FIG. 8 is a schematic illustration of the system operation according to one embodiment of the invention;
  • FIG. 9 is a schematic illustration of a stolen computer timeline.
  • Protected areas may be defined by physical doors (in particular doors through which a human may enter, or doors of a container, or safe, or vehicle, etc.) and walls, or may be virtually defined in other ways.
  • a protected area may consist of an area entering which causes a detector to signal intrusion (and possibly send a signal or sound an alarm if authorization is not provided).
  • often entering the gate area through an exit lane will trigger such a signal, even though no doors or walls have been violated.
  • doors should be construed to include all other types of access access-control devices implementable with a traditional or more modern type of a key.
  • key mechanisms used to start engines (so that our invention becomes a novel way to ensure that only currently authorized users may start a plane, a truck, or otherwise access other valuables).
  • Smart doors provide such access control.
  • a smart door may be equipped with a key pad, through which a user enters his/her PIN or password.
  • the key pad has an attached memory or elementary processor in which a list of valid PINs/passwords are stored, so that it can be checked whether the currently entered one belongs to the list. If so, the door opens, else it remains lock.
  • Such elementary access control mechanism offers minimum security. In particular a terminated employee may no longer be authorized to go trough that door; yet, if he still remembers his own PIN, he would have no trouble to open such an elementary smart door. Therefore, it would be necessary to "deprogram" the PIN of terminated employees.
  • a smart door should identify the person entering and verify that he is currently authorized to do so. Of the two tasks, the first is perhaps easier. Identification may be performed in a variety of ways: in particular:
  • a digital certificate ⁇ e.g., one stored in a smart card, contactless card or a wireless device, that can "communicate to the door” via a card reader or other receiver.
  • the card may store a digital certificate and the corresponding secret key(s).
  • the card Upon proper command from the cardholder (performed, for example, by punching a secret code on a key pad on the card), the card would transmit the digital certificate to the door mechanism and perform an identification protocol (e.g., decrypt a random challenge) by using the corresponding secret key.
  • an identification protocol e.g., decrypt a random challenge
  • the digital certificate, and particularly its corresponding secret key(s) should be protected within a secure- hardware portion of the card/device.
  • identification needs not be performed, but authorization still needs to be performed. In most cases, however, identification in some form is mandated: thus we can assume that identification can or has already been performed (e.g, by any one of the 5 methods described above). Either way: how can authorization be performed? Even if the door knows for certain that it is dealing with John Doe, how can the door make sure that John Doe is currently authorized to enter now? Traditionally, a smart door consults a database of currently (e.g., on a given day/date) authorized users to verify that so indeed is the individual requesting access. But this requires that the smart door to be connected to the distant database.
  • cryptographically protected communication to prevent an impostor from impersonating the database to the door, but must also prevent an enemy to cut the wire connecting the door to the database, else once disconnected a door must choose from equally bad options: (a) always open or (b) always remain closed.
  • a secure network connection easily dwarfs the cost of the electromechanical component of the door lock: a top of the line component may cost $ 1 ,000 while the secure network connection may cost $4,000 (more if a wire must securely connect large distance, such at an ai ⁇ ort.
  • the present invention relies on digital signatures, and preferably on 20-byte technology.
  • Digital signatures (such as RSA) are used to prove that a given message M originates from a given user U.
  • U produces a pair of matching keys: a verification key PK and a signature key SK.
  • Digital signatures are produced via SK, and verified via the matching key PK.
  • a user U should keep his own SK secret (so that only U can sign on U's behalf).
  • Digital signatures work because PK does not "betray" the matching key SK, that is, knowledge of PK does not give an enemy any practical advantage in computing SK. Therefore, a user U should make his own PK as public as possible (so that every one can verify U's signatures). For this reason PK is preferably called the public key.
  • Digital signature is intended to include private-key signatures, in which case signed and verifier may share a common secret key.
  • Alphanumeric strings called certificates enable digital signatures by guaranteeing that a given key PK is indeed the public key of a user U.
  • a Certifying Authority (CA) generates and issues a certificate to a user, once assured of the user's identity. Thus the certificate proves to everyone that the CA has verified the holder's identity, and possibly other attributes. (E.g., if a company acts as its own CA and issues certificates for its own employees, a certificate may prove the extent to which its holder is authorized to bind his/her employer.) Certificates expire after a specified amount of time, typically one year in the case of public CAs.
  • a digital certificate C consists of a CA's digital signature securely binding together several quantities: SN, a serial number unique to the certificate, PK, the public key of the user, U, the user's name, Di, the issue date, D 2 , the expiration date, and additional data.
  • C SIG CA (SN,PK,U,D ⁇ ,D 2 ,).
  • a certificate may also encompass the case where PK is an encryption key.
  • U may prove his identity to a verifier V by sending V the certificate C, by having V encrypt a random challenge (String) R with key PK, and then ask U to send back the decryption. If the user responds with R, then V is ensured that he is dealing with U, because only U should know the decryption key matching PK.
  • the preferred embodiment of the present invention provides a much better solution for access control. Specifically, if the card contains a digital certificate according to the present invention, then authorization can be performed much cheaper. Instead of consulting the central database about the validity of every digital certificate, the door would simply need to obtain the 20-byte validity proof according to the present invention that verifies the current validity of the card.
  • A be an authority (i.e., entity) controlling a set of smart doors and U a user to whom access to a given door should be granted for a given period of time.
  • Each user possesses a card (in the general sense discussed before).
  • Each smart door has an associated card reader (in the general sense capable of communicating or at least receiving information from a user card), coupled with an electromechanical lock in the case of a really physical (rather than virtual) door.
  • each door also has a unique identifier (and knows its own identifier).
  • the door has a card reader and a non-easily tamperable clock and a computing device possessing A's public key PKA and capable of verifying A's signatures.
  • a repository is a place that can be accesed by users. For instance a server located at the employee entrance of a large facility (such as an employee entrance at an ai ⁇ ort). Because A's signatures are unforgeable, the connection between A and PR needs not be secure. It suffices that A succeeds to transfers its signatures to PR within a reasonable time.
  • a plurality of doors, Dl,...,Dn can be indicated one by one, and the fact that U can go that day through each one of hem can be indicated by more than one signature of A.
  • SIGUDld ... SIGUDnd.
  • all such signatures are transferred to U's card.
  • U walks around the facility and reaches a door D for which he has granted permission. Therefore, his card now stores SIGUDd. Then U may insert his card C into a card reader at door D.
  • the processor associated with the door verifies that the SIGUDd indeed is valid using A's public key. Then verifies that the current day is indeed d using its own clock. If both items are true, then door D opens.
  • the card can transfer SIGUDd to D's card reader only if U inputs the right PIN on a key pad on the back of C, and the repository PR may download SIGUDd onto card C, only after the card proves that indeed it is U's card.
  • U may represent an identifier for card,C, belonging to U, and when inserted in the card reader, the card indeed proves -eg, by means of a cryptographic protocol, that indeed it is card C.
  • U's card carries a certificate for U, and after the proper PIN is entered, the card proves the identity of U by decrypting a random challenge of the door.
  • the door is "disconnected" from A.
  • the door only (possibly identifies U and) checks that the U has permission of entering via an internal computation and utilizing A's public key and its own internal clock.
  • the system therefore, not only is very secure, but also very economical.
  • This validity or authorization proof can be provided in a number of different ways. The following are just examples of how this can be done.
  • the card owner may "pick up" the validity proof at the appropriate time. For example, in a work environment, each person may pick up the current validity proof when reporting to work. In many work places (particularly those sensitive to security, such as ai ⁇ orts), employees sign in when reporting to work. This "sign in” may include obtaining the 20-byte validity, SIGUDd, and storing it on the card. value and storing it on the card. The card may obtain the value via a wired or a wireless connection.
  • the card may obtain the validity proof via a wireless network, such the pager network, for example. At the appropriate time, if the card is authorized for access, a 20-byte value is sent to it. Note that the bandwidth requirements are minimal: the authorization value is shorter than a typical message transmitted by the pager network. At the appropriate time, if the card is authorized for access, SIGUDd is sent to it.
  • the door may obtain the validity proof similarly via a wired or a wireless network, for every card that it expects to encounter, in advance.
  • the door may obtain the validity proof for a card on demand, when the card starts interacting with it.
  • door and protected areas should be construed to include all other types of access points that could be protected with a traditional or more modern type of key.
  • key mechanism that used to start engines (so that only currently authorized employees may start a plane, a truck, or other engine).
  • the components of the preferred embodiment of the present invention are: (1) A door mechanism capable of verifying digital signatures, coupled with means of opening the door upon successful verification; (2) An authority component, providing a digital signature signifying that authorization for entering through the door has been granted for a given time period; (3) A card or other wired/wireless device component capable of receiving a digital signature and presenting it.
  • the authorization of access may be accomplished by any of the following sequences of steps:
  • the authority component causes the card to receive the authorizing signature
  • the card receives and stores the authorizing signature; (3) The card presents the authorizing signature to the door, which verifies it and opens if and only if the authorizing signature is valid SEQUENCE 2:
  • the card requests the authorizing signature from the authority component
  • the authority component transmits the authorizing signature to the card; (3) The card receives and stores the authorizing signature;
  • the card presents the authorizing signature to the door, which verifies it and opens if and only if the authorizing signature is valid.
  • SEQUENCE 4 (1) The door receives in advance (either at its own request or not) authorizing signatures for a plurality of cards it is expected to encounter from the authority component;
  • the card presents itself to the door requesting authorization for access; (3) The door verifies the card's authorizing signature and opens if an only if it is valid.
  • the door may receive part of the information/authorization (e.g., the 20-byte value), while the card may receive another part (e.g., the digital certificate). They may also be separated in time: the card may receive part of the information/authorization (e.g., the digital certificate) at first, and then receive other parts (e.g., the 20-byte value for each hour) later.
  • the information/authorization e.g., the 20-byte value
  • the card may receive another part (e.g., the digital certificate).
  • the card may receive part of the information/authorization (e.g., the digital certificate) at first, and then receive other parts (e.g., the 20-byte value for each hour) later.
  • the authorizing digital signatures may be tied to the long-term certificate of the cardholder.
  • the card may contain a long-term certificate valid for each year, and the authority component may issue daily signatures verifying that the certificate is still valid on the current day.
  • the authority component may generate authorizations automatically, without any requests. For example, every night the authority component may generate authorizing signatures for the employees that will be authorized for the next day.
  • This approach enables the authorization component to be non-interactive and thus easier to build securely.
  • the authority component may use separate, possibly insecure devices, for dissemination of authorizing signatures to cards and/or doors. This will enable the authorization component to focus on only one task: generation of authorizations. It will remove the need for the cumbersome direct connections between the secure authorization component and the (possibly less secure) doors and cards.
  • dissemination of authorizations may occur as follows: (1) The authority component generates authorizations; (2) The authority component transmits authorization, over possibly insecure connections, to dissemination databases. These databases may be at multiple locations, and need not be secured. For example, in a company with five employee entrances, there may be one dissemination database at each entrance; (3) The dissemination databases transmit authorizations to cards and/or doors, either upon request ("pull") or automatically (“push").
  • the property enabling the above methods is that the authorization itself is innovative - it can be produced only by the authority component. Therefore, once produced, it can be disseminated over possibly untrusted lines and devices without any risks to security. This removes the need for any other party or device to interact with the authority component, thus resulting in a much cheaper solution than any requiring secure connections.
  • inventive access control system can be combined with the tenant CAs of Section 3.
  • authorities e.g., in an office building, the parking authority, the cleaning authority, or the multiple companies sharing occupancy in the building
  • the system could operate as follows.
  • a user U (or his card) has a certificate CERT that contains a validation field — say D365 — for each door D of interest. Permission that U can go through door D at day j can be proved by releasing the indispensable 20-byte value X365-J.
  • Door D can check that permission by hashing it j times and checking whether the result coincides with the validity field D365 of CERT.
  • A must deal with a plurality of doors (eg, 1000 doors, then CERT may contain 1000 different validity fields, each corresponding to different doors, and each door Dj checks its computations relative to the jth validity field. In this case, even if permission for a user to go through each door is proved separately, each user has at most 1000 proofs on a given day. Thus at most 20K bytes need to be loaded on his card on a given day.
  • the card can be a contactless card
  • the card reader may be a receiver
  • the card need not be inserted into the reader but transmit to it. Notice that such a "wireless" card-reader interaction is still quite local, and very different from a card-authority/database interaction when A or the database is far away.
  • the authorizing digital signatures may be tied to the long-term certificate of the cardholder.
  • the card may contain a long-term certificate valid for each year, and the authority component may issue daily signatures verifying that the certificate is still valid on the current day.
  • the authority component may generate authorizations automatically, without any requests. For example, every night the authority component may generate authorizing signatures for the employees that will be authorized for the next day. This approach enables the authorization component to be non-interactive and thus easier to build securely.
  • inventive access control system can be combined with the tenant CAs as described.
  • authorities e.g., in an office building, the parking authority, the cleaning authority, or the multiple companies sharing occupancy in the building
  • the door may produce a proper string LOGUDt, and locally store it (at least temporarily). To ensure that this info reaches a proper database, the door may use the cards used to enter through it. For instance, D may write LOGUDt (or cause LOGUDt to be written) on the card(s) of other user(s) U' (possibly including U himself).
  • PR eg the next day of work
  • PR or said device transmits LOGUDt to the proper database. This way a proper database will eventually receive and then store more permanently and in an easily auditable way LOGUDt. Possibly the database will receive redundant copies of LOGUDt, but it is easy for it to clear any unwanted redundancy and keep clean copies only.
  • a preferable LOGUDt is one that consists or includes a digital signature of U himself. This way, U cannot easily deny that he went through a given door at a given time and claim that the access information of the door is a fabrication. Indeed, only he has the secret signing key for producing LOGUDt. For instance LOGUDt e consist of SIG ⁇ j(D,t), indicating that U went through door D at time t. This is very easy to accomplish if user U's card carries the secret signing key SKU matching a public key PKU. Preferably the card also carries a digital certificate for PKU, and thus LOGUD may include not only SIGu(D,t), but also U's certificate.
  • the user card may produce SIG ⁇ j(D,t) according to the time t shown on its own clock, and the door may let U in only after he provides such a good access proof SIGu(D,t) (possibly in addition to other authorization proofs such as those discussed above), and provided that the time certified by U is sufficiently close to the current time t' as measured by the door clock. Still the user may claim that he entered at time t door D, but that this door was somewhere else altogether, and thus that SIG ⁇ j(D,t) does not at all prove that he went through — say — the second door of the third floor of a given building: someone went through the trouble to transfer to said location the door reader etc.
  • the user card may inco ⁇ orate a GPS mechanism, and SIG ⁇ j(D,t) may actually include the local position lp as measured by the card.
  • the user may tend to the door the proof of access SIGu(D,t, ps), and the door may accept it and let the user in only if not only the time looks correct but also the local position.
  • the user may use some one or more components, which he trusts, and which can compute his position from information they receive from him (and possibly their own positions).
  • the CA sends to a Directory individual certificate revocation status information CRS, about each of its issued, but not-yet expired certificates C ⁇ ... C .
  • the Directory sends CRS, to a requesting user who has inquired about certificate serial number "i" of that certifying authority.
  • a system and method are disclosed for controlling physical access through a digital certificate validation process that works with standard certificate formats (e.g., X.509v3) and that enables a certifying authority (CA) to prove the validity status of each certificate C at any time interval (e.g., every day, hour, or minute) starting with C's issue date, O ⁇ .
  • C'S time granularity may be specified within the certificate itself, unless it is the same for all certificates. To be concrete, but without limitation intended, below we assume a one-day granularity for all certificates, and that each certificate expires 365 days after issuance.
  • H See, for example, Secure Hash Standard; FIPS PUB 180, Revised July 11, 94 (Federal Register, Vol. 59, No. 131, pp. 35211-34460); revised August 5, 1994 (Federal Register Vol.
  • the CA releases X 65-dan that is, the i-th H-inverse of the validity target X 365 - (E.g., the proof that C is valid 100 days after issuance consists of X 265 .)
  • the CA may release Y 0 or X 65-] by providing the value in response to a query or by posting it on the World Wide Web.
  • C's revocation proof Y 0
  • Yi (I.e., the verifier tests for himself that Y 0 really is the H-inverse of Yj .)
  • Yi is guaranteed to be C's revocation target, because Yi is certified within C.
  • C's validity proof on that day, X 365-1 is verified by hashing i times the value X 65- , and checking that the result equals C's validity target, X 365 .
  • the proof of revocation of a certificate C consists of the H-inverse of C's revocation target Yi. Because H is essentially impossible to invert, once a verifier checks that a given 20-byte value Y 0 is indeed C's proof of revocation, it knows that Y 0 must have been released by the CA. In fact, only the CA can compute the H-inverse of Yi: not because the CA can invert H better than anyone else, but because it computed Yi by starting with Y 0 and hashing it! Because the CA never releases C's revocation proof as long as C remains valid, an enemy cannot fake a revocation proof. A proof of validity cannot be forged.
  • the proof of validity of a certificate C consists of the i-th H-inverse of C's validity target X 36 s. Because H is essentially impossible to invert, once a verifier checks that a given 20-byte value X 65- ⁇ is indeed C's proof of validity on day i, it knows that the CA must have released X365-i. In fact, only the CA can compute the i-th H-inverse of X 36 s: not because the CA can invert H better than anyone else, but because it computed X 36 5 by starting with X 0 and hashing it 365 times, thus computing along the way all the first 365 inverses of X 365 !
  • a certificate C includes only two additional 20-byte values, Y and X365.
  • C already consists of a CA signature (at least
  • C may include comments and plenty of other data in addition to SN, PK, U, DI and
  • Proofs according to embodiments of the present invention can be so short because they derive their security from elementary cryptographic components, such as one-way functions, which should exhibit an exponential amount of security. (Quite differently, digital signature schemes have complex security requirements. Their typical number-theoretic implementations offer at best a sub-exponential amount of security, and thus necessitate much longer keys.)
  • the proofs remain 20-bytes long whether the total number of certificates is a few hundred or a few billion. In fact there are 2 160 possible 20-byte strings, and the probability that two certificates may happen to have a common proof of revocation or validity is negligible.
  • our 20-byte proofs does not increase due to encryption or authentication.
  • Our 20-byte proofs are intended to be public and thus need not be encrypted.
  • our 20-byte proofs are self-authenticating: by hashing them the proper number of times they yield either the validity target or the revocation target specified within the certificate. They will not work if faked or altered, and thus need not be signed or authenticated in any manner.
  • a 20-byte proof of validity on day i, X 365-1 need not additionally include the value i: in a sense, it already includes its own time stamp! Indeed, as discussed before, i is the difference between the current day and the certificate's issue day, and if hashing X 365- , i times yields the validity target of certificate C, then this proves that X 365- , is C's proof of validity on day i.
  • the 20-byte proofs are computed instantly.
  • a proof of revocation Y 0 or a proof of validity X 365 - ⁇ is just retrieved from memory.
  • each X 365-1 could be recomputed on the fly on day i; for instance by at most 364 hashings, if just Xo is stored during certificate issuance. Su ⁇ risingly more efficient strategies are discussed in the next section.)
  • Embodiments of the present invention are ideal for wireless implementations. Its scalability is enormous: it could accommodate billions of certs with great ease.
  • the bandwidth it requires is negligible, essentially a 30-bit serial number for the query and 20-byte for the response.
  • the computation it requires is negligible, because a certificate-status query is answered by a single table look-up and is immediately verified.
  • great scalability, minimum bandwidth and trivial computation make the present invention a technology of choice in a wireless environment.
  • a wireless user may receive a 20-byte proof of the validity of his certificate for the remainder of the day. (This 20-byte value can be obtained upon request of the user, or pushed to the user's cellular device automatically -e.g., by means of a SMS message or other control message..) Due to its trivial length, this proof can be easily stored in most cellular telephones and PDAs. Then, whenever the user wants to transact on that day, the user simply sends its own certificate together with the cert's
  • the verifier can work totally off-line. In the cellular environment, in which any call translates into money and time costs, this off-line capability is of great value.
  • the present invention and OCSP are both on-demand systems: namely, a user sends a query about the current validity of a certificate and gets back an unforgeable and universally verifiable proof as a response. But there are differences in: Time accuracy; Bandwidth; CA efficiency; Security; and Operating costs.
  • Time Accuracy In principle, an OCSP response may specify time with unbounded accuracy, while a response according the preferred embodiment of the present invention specifies time with a predetermined accuracy: one day, one hour, one minute, etc. In low-value applications, one-day validity is plenty acceptable. For most financial applications, Digital Signature Trust considers a 4-hour accuracy sufficient.
  • the preferred embodiment of the present invention computes hash chains that are roughly IM long (i.e., needs to compute validity fields of the type X I M ), because there are at most 527,040 minutes in a year. If chains so long could be handled efficiently, preferred embodiments of the present invention would de facto be real time.
  • Computing IM hashings is not problematic at certificate issuance: IM hashings can be performed in less than 1 second even using very reasonable platforms, and a certificate is typically issued only once a year, and not under tremendous time pressure.
  • Bandwidth The preferred embodiment of the present invention has an obvious bandwidth advantage over OCSP.
  • the former uses 20-byte answers, while the latter typically uses 256 bytes.
  • CA Efficiency A validity query is answered by a (complex) digital signature in the OCSP case, and by a (trivial) table look-up in the case of the present invention, as long as the CA stores the entire X-chain for each certificate.
  • the CA can afford to store the entire X-chain for each certificate when the time accuracy is one day or one hour.
  • the CA would have to store 365 20-bytes values; that is, 7.3K bytes per cert, and thus 7.3B bytes overall.
  • the time accuracy were 15 seconds, then each hash chain would consist of IM 20- byte values, and for the entire system the overall storage requirement would be around 10.5 tera-bytes: a sizable storage.
  • the CA may store just a single 20-byte value (i.e., Xn) for each cert, and re-compute from it each Xj value by at most IM hashings.
  • Jacobsson [5] has found a su ⁇ rising time/storage tradeoff. Namely, the CA may re-compute all n X, values, in the right order, by storing log (n) hash values and performing log(n) hashings each time. If n were IM, this implies just storing 20 hash values per cert and performing only 20 hashings each time the cert needs validation. Other non-trivial tradeoffs are possible.
  • the preferred embodiment of the present invention can, by just storing 60 bytes per certificate, replace a complex digital signature operation with a trivial 100- hash operation.
  • a secure vault ought to protect that key, so as to guarantee the integrity of the entire system.
  • a centralized implementation of the present invention or OCSP we mean one in which a single vault answers all validity queries.
  • Centralized implementations are preferable if the number of deployed certificates is small (e.g., no more than 100K), so that the vault could handle the query volumes generated even if almost all certificates are used in a small time interval, triggering almost simultaneous validity queries.
  • the preferred embodiment is preferable to OCSP in the following respects.
  • Doomsday Protection In the traditional OCSP, if (despite vaults and armored guards) an enemy succeeds in penetrating the vault and compromises the secret signing key, then he can both "resurrect" a previously revoked certificate and
  • penetrating the secure vault does not help an adversary to forge the validity of any previously revoked certificate.
  • a certificate becomes revoked at day i not only is its revocation proof Y 0 made public, but, simultaneously, all its Xj values
  • Centralized implementations require all queries about certificate validity to be routed to the same vault. This easily results in long delays and denial of service in applications with millions of active certificates. To protect against such congestion, delays, and denial of service, one might spread the load of answering validity queries across several, geographically dispersed, responder servers. However, in the case of the OCSP each additional responder needs to have a secret signing key, and thus needs to be hosted in a vault, making the cost of ownership of an OCSP system very onerous. A high-grade vault meeting the requirements of financial institutions costs at least $1M to build and $1M to run. (A good vault would involve armored concrete, steel doors, back-up power generators, protected fuel depot to run the generator for potentially a long time, etc.
  • a distributed implementation can be achieved with a single vault (which a CA would have anyway) and an arbitrary number of "un-trusted responders" (i.e., ordinary servers).
  • a distributed system according to the present invention assuming, to be concrete, that (a) there are 10M certs; (b) there are 1,000 servers, strategically located around the globe so as to minimize response time; and (3) the time granularity is one-day.
  • CA Operations Initialization Cost: Every morning, starting with the smallest serial number, compile a lOM-entry array F as follows: For each certificate C having serial number j, store C's 20-byte validity/revocation proof in location j. Then, date and sign F and send it to each of the 1,000 servers.
  • each entry is computed by a mere table look-up operation. In an alternative embodiment, it can also be computed on the spot.
  • each value sent is just 20-byte long, because each such a value is immediately computed (by a table look up), and because the traffic can be spread across 1000 servers, no denial of service should occur, at least during legitimate use of the system.
  • Distributed implementations of the present invention continue to enjoy the same doomsday protection of its centralized counte ⁇ art: namely, an enemy successfully entering the vault cannot revive a revoked certificate. Sophisticated adversaries, however, refrain from drilling holes in a vault, and prefer software attacks whenever possible. Fortunately, software attacks, though possible against the distributed/centralized OCSP, cannot be mounted against distributed implementations of the present invention.
  • the CA is required to receive outside queries from untrusted parties, and to answer them by a digital signature, and thus by means of its precious secret key. Therefore, the possibility exists that OCSP's required "window on the outside world" may be maliciously exploited for exposing the secret signing key.
  • the CA is in the vault and never receives or answers any queries from the outside; it only outputs non-secret data at periodic intervals. Indeed, every day (or hour) it outputs a file F consisting of public information.
  • the CA may receive revocations requests from its RAs, but these come from fewer trusted entities via authenticated channels — e.g., using secure smart cards.
  • the untrusted responders do receive queries from untrusted parties, but they answer those queries by means of their file F, and thus by public data. Therefore, in a software attack against the preferred embodiment of the present invention ordinary responders may only "expose" public information.
  • SIMPLIFIED PKI MANAGEMENT PKI management is not trivial. (See, for example, Internet Public Key
  • the preferred embodiment of the present invention may improve PKI management in many applications by: (1) reducing the number of issued certs; (2) enabling privilege management on the cert; and (3) sharing the registration function with multiple independent CAs.
  • the present invention can alleviate these costs as follows.
  • the vendor's CA builds the suspension field very much as a validity field: by starting with a random 20-byte value Z 0 and then hashing it 365 times, in case of one-day granularity.
  • the vendor rather than giving U a new single-day certificate whenever U wishes to download music, the vendor gives U a single, yearly certificate. At any time, this single certificate can be turned ON for a day, by just releasing the proper 20-byte value.
  • the preferred embodiment of the present invention replaces issuing (and embedding in the user's browser) 10 single-day certificates by issuing a single yearly cert that, as it may happen, will be turned ON for 10 out of the 365 days of the year.
  • the vendor could also use the method above to issue a cert that specifies a priori the number of days for which it can be turned ON (e.g., a 10- day-out-of 365 cert). Because it has a more predictable cost, such certs are more suitable for a gift.
  • the State Department may have 10 different security-clearance levels, L1,...L10, and signify that it has granted security level 5 to a user U by issuing a certificate C like:
  • short-lived certificates e.g. certificates expiring one day after issuance
  • single-day certs may enable a State Department employee or user U to attend a meeting where a higher security level is needed.
  • U had such a cert in a proper cellular device, smart card or even mag stripe card he could, for instance, use it to open the door leading to the meeting that day.
  • the use of short-lived certificates is much broader, and has been advocated because it dispenses with the difficulty of revocation to a large extent (no point revoking a cert that will expire in 24hours, at least in most applications).
  • the first validity field, A 3 ⁇ s corresponds to security-clearance level 1 ... and the 10th validity field, J 365 , corresponds to security-clearance level 10, while, as usual, Yi is C's revocation field.
  • Cert C is used as follows. If, on day n, U is in good standing (i.e., cert C is still valid), and U's security-clearance level is 5, then the State Department publicizes (e.g., sends to all its responders in a distributed NOVOMODO implementation) the 20-byte validity proof E 365 . n . If, on day m, U's security-clearance level becomes 2, then the State Department publicizes B 3 6s -m . And so on.
  • cert C though internally specifying its own privileges, needs not be revoked when these privileges change in a normal way, and users need not load new certs in their browsers.
  • the preferred embodiment of the present invention has such minimal footprint, that a CA (rather than issuing, revoking, and re-issuing many related certs) can issue with great simplicity a single cert, having a much higher probability of not being revoked (because changes of security- clearance level do not translate into revocation).
  • fewer certs will end up been issued or revoked in this application, resulting in simpler PKI management.
  • the preferred embodiment of the present invention replaces the complex certificate management relative to a set of dynamically changing properties or attributes by a single certificate (with minimum extra length) and a single 20-byte value for attribute.
  • Telecom companies may use a method similar to that of Example 2 to switch a given wireless device from one rate plan to another, or for roaming pu ⁇ oses.
  • a main PKI cost is associated to the RA function. Indeed, identifying a user U may require an expensive personal interview and verifying that indeed U knows the right secret key (corresponding to the to-be-certified public key PK). It would be nice if this RA function could be shared across many CAs, while enabling them to retain total independent control over their own certs.
  • the Government and big organizations consist of both parallel and hierarchical sub-organizations: departments, business units, etc.
  • An employee may be affiliated with two or more sub-organizations.
  • he may work for NIST and the Department of Commerce. Issuing a digital certificate for each such affiliation results in a high total number of certificates and a complex PKI management: every time an employee drops/adds one of his/her affiliations, it is best to revoke the corresponding cert/issue a new one.
  • two opposites should be reconciled: (1) The Organization issues only one cert per employee, and (2) Each Sub-Organization issues and controls a separate cert for each of its affiliates.
  • the preferred embodiment of the present invention is compatible with de-coupling the process of certification from that of validation, the first process being controlled by a CA and the second by a validation authority (VA).
  • VA validation authority
  • a CA once a CA is ready to issue a certificate C with serial number SN, it sends SN to a VA, who selects Yo and Xo, secretly stores the triplet (SN, Y0,X0), computes as usual Yi and X 365 , and then returns Yi and X365 to the CA, who includes them within C.
  • the CA need not bother validating C: the CA is solely responsible for identifying the user and properly issuing C, while the VA is the only one who can prove C valid or revoked.
  • This de-coupling may be exploited in a variety of ways in order to have organization certificates that flexibly reflect internal sub-organization dynamics. The following is just one of these ways, and uses Government and Departments as running examples. The Government as a whole will have its own CA, and so will each Department.
  • a Government certificate C has the following form:
  • SN is the cert's serial number
  • PK the public key of the user
  • U the user's identity
  • Di the issue date
  • D 2 the expiration date
  • X 365 the validity field
  • Yi Yi the revocation field
  • ⁇ is the validation field of CA
  • Z, ⁇ is the suspension field of CA J .
  • Such a certificate is generated by the Government CA with input from the Department CAs. After identifying the user U and choosing a unique serial number SN, the issue date Di, and the expiration date D 2 , the Government CA sends SN, PK, U, Di, D 2 (preferably in authenticated form) to each of the Department CAs.
  • the jth such CA then: chooses two secret 20-byte values X ⁇ J and Zo J ; locally stores (SN,PK,U, Di, D 2 , Xo J , Z 0 J ) or, more simply, (SN, Xo J , Z 0 ); and returns [ 36 i, Z i6 i] for inco ⁇ oration in the Government certificate in position j (or with "label" j).
  • This certificate C is managed with Distributed implementations of the present invention as follows, so as to work as a 1-cert, a 2-cert,..., a k-cert; that is, as k independent certs, one per Department.
  • the Government CA sends all 100 responders the 20-byte value X 36 5-11 if C is still valid, and Y 0 otherwise.
  • the jth Department CA sends all 100 responders the 20- byte value X365 -n J to signify that C can be relied upon as a j-cert and Z365- n J otherwise.
  • the Government CA is solely responsible for identifying the user and issuing the certificate, but each of the Department CAs can independently manage what de facto is its own certificate. (This is absolutely crucial. If CA 1 were the Justice Department and CA 2 the DOD, then, despite some overlapping interests, it is best that each acts independently of the other).
  • the resulting certificate system is very economical to run. First, the number of certs is greatly reduced (in principle, there may be just one cert for employee). Second, a given employee can leave and join different Departments without the need of revoking old certs or issuing new ones. Third, different Department CAs may share the same responders.
  • certificate C was only revocable in a central way, but it could easily be arranged that the responsibility of revocation is push down to individual Departments.
  • C may take the following form:
  • one major advantage of issuing certs structured and managed as above consists in enabling the cert to stay alive though the user moves from one sub-organization to another. It should be realized, however, that the above techniques are also applicable outside a single-organization domain. Indeed, the Government CA can be viewed as a landlord CA, the k Department CAs as tenant CAs servicing unrelated organizations (rather than sub-organizations), and the certificate can be viewed as a leased cert. This terminology is borrowed from a more familiar example where the advantages of "joint construction and independent control" apply. Leased certs are in fact analogous to spec buildings having the identical floor footprints.
  • a builder is better off constructing a 20-floor building, setting himself up in the penthouse apartment and renting or selling out right the other floors.
  • Each of the 20 tenants then acts as a single owner. He decides in full autonomy and with no liability to the builder whom to let into his flat, and whom to give the keys.
  • a 20-story building is of course less expensive than 20 times a single-story one: it may very well cost 10 times that. This economy of scale is even more pronounced in a leased cert. Indeed, the cost of issuing a regular cert and that of issuing a leased one is pretty much the same. Thus issuing leased certs could be very profitable to a landlord CA, or at least repay it completely of the costs incurred for its own certs.
  • tenant CAs have their advantage too, in fact: they save on issuance costs: they share the cost of issuing a cert k ways; and they save on infrastructure costs: they share the same responders (since they contain only public data).
  • Natural candidates to act as landlord CAs for external tenant CAs are: credit card companies; large financial institutions, and again the Government (e.g., via the
  • Example 11 So far, the way we have described landlord and tenant CAs requires that the landlord CA cooperates with its own tenant CAs during the issuance process, and thus that it has already identified its tenant CAs beforehand. It is actually possible, however, for a landlord CA to issue rental certs envisioning -say — 20 tenant CAs, without having identified all or any of these tenants. Rather, future tenant CAs will be able to rent space in already issued certs. This capability is ideal for new cert- enabled applications.
  • a company offering a new certificate-enabled product may approach a landlord CA having issued millions of certs, rent space in them after the facs, and then sign on as customers a large portion of the landlord-CA users by turning ON all their corresponding certs overnight (without any customer identification and other issuing costs) and then starting managing them according to its own criteria.
  • the device may carry a digital certificate C, specifying a validity field X, and the device may work on a given day only if it has the daily proof of validity relative to X.
  • the device may have a trusted/protected clock to avoid being fooled.
  • the device (especially if a cellular device) may be "pushed" its own daily validity proof.
  • the device may request to a second entity its own validity proof for the day. For instance, the device may provide its serial number and receive in response the proof of validity of that day.
  • a first entity generates an initial value IV, and iterates a one-way function F on V a given number of times so as to obtain a final value FV.
  • a second entity (possibly equal to the first) burns X into a device D.
  • Device D has means to iterate the function F.
  • Device D later receives an alleged n-th proof value PV, where n is a positive integer, and verifies PV by iterating the function F on PV n times and checking that the resulting value equals the burnt-in value X.
  • the Device D may consult its own clock to ensure that the n-th proof value corresponds to the current date.
  • the current date may in fact be the n-th date in a sequence of dates starting from a fixed date.
  • the fixed date may be burnt-in the device as well to protect its integrity as well.
  • function F may receive as input (not only the previously computed value but also) additional input.
  • D's identifier may be an input at each iteration.
  • additional inputs may be different at each different iteration as well.
  • integer k may be an input at iteration k.
  • F there may not be a single one-way function F. Indeed there may be a sequence of one-way functions, and Fk may be the function applied at iteration k.
  • the validity field X (being essentially unique to D) could also be used as D's identifier (or part of it), so as to spare dealing with D's serial number and validity field separately.
  • the described system can be used so far to turn a given device D ON or OFF altogether. But it can also be used to turn ON or OFF a given just a single functionality, or a single functionality of out several possible functionalities.
  • X may be a validity field for functionality FX, Z a validity field for functionality FZ and so on. In this case receiving a validity proof relative to X (Z) means that functionality FX (FZ) is turned ON for that day on device D.
  • Such additional validity fields Z,... can also be burned-in the device D.
  • a description identifier of which functionality is associated to X/Z/... can also be burnt-in.
  • the validity fields can be Merkle hashed and then the root value of the Merkle tree may be burnt-in.
  • the device may provide the device with a proper proof of validity relative to X (for that day), together with the authentication path from X to the root in the Merkle tree.
  • the Merkle authenticating path algorithm may also be burnt-in.
  • the technology of the preferred embodiment can be used to validate devices and by turning them ON or OFF so as to prevent their misuse.
  • the security of this application lies in the fact that the device has a clock not controllable by an enemy, possibly the very owner of the device (e.g., a fired employee who, after being fired, wishes to access company data from his company laptop that still lies at home).
  • the preferred embodiment provides technology that performs device validation even for devices which clock-less, that is, having no clocks, or no secure clocks.
  • the technology envisages a validator, an entity deciding whether a given device should be validated -i.e., turned ON or OFF — at a given date in a sequence of dates.
  • a given date is a given day in a sequence of days.
  • the device preferably has a secure memory portion and a clock. Though not secure, the device can tell whether the given clock has been reset at least while turned on. For instance, the device can tell, as long as it remains running, that 24hours have passed.
  • the validation software preferably is protected in the device (e.g., running in a protected memory portion, or is burnt in, or resides in firmware), so as to avoid being altered in any way. Notice that some smart cards work in similar way.
  • the smart card's clock becomes active, and the card may monitor the passage of time accurately (e.g., because the clock also is in secure memory), but once the card is taken out of the reader the clock no longer works, though a small value may still be preserved in secure memory.
  • the Validator and the device share a secret key K.
  • the device can be turned OFF by not publishing or feeding it with future proof of validity, or can be turned OFF for good by publishing or causing it to receive a special value such as H(K, ⁇ O MORE), or a special value Vnomore stored in memory, etc.
  • the device can be suspended on a given day by publishing or causing it to receiving a special value, eg., H(K,suspendj).
  • the keys for the validity, revocation and suspension proofs can be the same or different.
  • This method works essentially as the method disclosed in Example 11, using a sequence of unpredictable values, published or otherwise made available to the device at each of a sequence of dates (e.g., without limitation, days), a clock not secure, etc. but does not use a secret key in the device.
  • the device stores Xk, the result of iterating one (or more) one-way function F k times on an initial value XO as discussed above and with the same variants.
  • Xk is written in firmware (e.g., in a non-alterable way) or stored in a protected portion of memory.
  • the proof of validity for day j simply is Xk-j as in the basic scheme of the present invention. Again suspension and revocation can occur in similar ways.
  • a robust access control system must answer two questions for every user.
  • the first question addresses authentication or identification: "Are you who you say you are?" This question is typically addressed directly or indirectly through identification badges, keys biometrics, or passcodes. These provide reasonable answers for long-lasting user identification, but don't address the more time critical question of validation: "Are you currently allowed to do what you are trying to do?" For example, an identification badge can tell you that Alice was hired as an employee some time in the last decade, but cannot independently determine whether she is still an employee with access permissions for the computer server room.
  • a secure lock For physical access control, a secure lock must determine identity through authentication, and then perform validation to determine whether a user's current privileges allow entry. Some locks perform this validation through wired network connections to a central trusted permissions authority.
  • a physical access solution based entirely on network wired locks has two significant limitations. The cost of each wired lock includes the costs of secure wiring, field control panels, and labor, totaling several thousand dollars per door. The reach of a wired configuration is limited to locks that can be easily accessed by permanent networking. This prevents the use of robust access control for mobile or hard to reach locks such as those on vehicles, storage containers, utility cabinets, etc.
  • the Real Time Credentials technology provides a secure way to perform efficient validation for physical access on both wired and disconnected locks. This allows intelligent door locks to validate current user privileges and permissions without requiring expensive network connections to each lock.
  • the present disclosure describes several configurations that can be used to provide disconnected validation based on large numbers of independent user privileges.
  • Each configuration offers interoperability with existing access control hardware and software for use in heterogeneous installations.
  • this paper will describe how Real Time Credentials offer increased flexibility while dramatically lowering the total cost of high security.
  • the first RTC validation configuration is an access control environment based on contactless ID cards with read/write memory access. This is described using the common MIFARETM Standard contactless card as an example, but the validation solution would be identical with any memory ID card.
  • the lock When a MIFARE ID card is used in current networked physical access environments, the lock reads the ID from a card and transmits it to a nearby panel or server that checks privileges and performs validation.
  • the authentication process is the determination of the card ID, and the validation process is handled remotely based on this ID.
  • the physical access solution of the present invention can maintain compatibility with this model for wired doors, but adds support for disconnected doors by using the card's read/write memory to store a digitally signed "validation proof for that card. This proof is periodically written to the card at any networked reader, and then it can be read at any disconnected lock to establish the current validity and permissions of the user.
  • Locker 53 1 bit to 10 bytes Terminal B 1 bit to 10 bytes
  • a disconnected lock can validate the user's permissions through the following steps: (1) Perform standard authentication by retrieving the user's card ID; (2) retrieve the RTC validation proof from memory;
  • the disconnected lock is configured with a set of access control rules based on privileges, rather than individual user ID.
  • a lock may be configured to only admit users with the "Parking" privilege, and only during business hours. Since the individual user privileges can be changed through the RTC validation proofs, the locks themselves do not need to be changed as new users are added and removed to change access permissions. In addition, the locks do not need to store any secret keys or data, which means that an individual lock can be disassembled without any reduction in overall system security.
  • the RTC validation proofs according to a preferred embodiment of the present invention have certain characteristics that make them uniquely powerful for physical access control environments. Since the proofs are digitally signed, they are unforgeable and tamper-proof. Since the proofs do not contain any secret keys, they can be public, and transmitted without security risk. The proofs are small enough to be stored on a low-end memory card. These characteristics allow the RTC validation proofs to be used in cards like MIFARE Standard, while still offering high security cryptographic validation with thousands of independent user privileges per card.
  • MIFARE Ik Standard cards are available for between $1 and $5, depending on manufacturer and volume.
  • a disconnected lock based on MIFARE cards and RTC validation technology could be manufactured for under $500 per door. With installation, a single door or container could be secured for under $1000.
  • Simple ID authentication offers weak protection against duplication and forgery.
  • Second and third factor authentication combined with PKI protections can be used to increase authentication security. Credential validation is protected by strong PK encryption, preventing permission forgery or modification.
  • RTC Credential validation can also be used with identification cards such as
  • HID's iClass that perform validation using secret information that is directly or indirectly shared with all readers.
  • a lock will perform authentication to a card using a randomized challenge/response protocol which proves that the card knows the secret correspondence to its ID.
  • the RCT validation for a shared secret card is identical to the validation for a simple ID card.
  • the lock will write the current RTC validation proof onto the user's card. This proof is later retrieved by disconnected readers for offline validation.
  • Cards capable of performing public key digital signatures offer the highest level of authentication security. This includes cards based on MIFARE PRO X chips as well as many high end JavaCards. Locks may authenticate a card based on a challenge/response protocol without requiring any sensitive information in the locks. This significantly reduces the risk of key duplication.
  • the RTC validation for a public key card is identical to validation for a simple ID card.
  • the lock When a user enters a wired door, the lock will write the current RTC validation proof onto the user's card, and this proof will be retrieved by disconnected readers for offline validation.
  • the card's public key will typically be represented by a digital certificate, which can be used for alternate applications such as computer access and email security.
  • High-end public key cards may support additional applications such as information security or stored value, which helps reduce the total cost for each application.
  • PKI cards are able to provide strong cryptographic authentication to locks with low risk of key compromise or card duplication. Credential validation is protected by strong PKI encryption, preventing permission forgery or modification.
  • H be a one-way hash function.
  • the first approach requires storage of two hash values (one for x n and the other for the computation of x,) and n(n+l)/2 evaluations of H total, or, on average, n/2 evaluations per value output.
  • the second approach requires storage of n+1 hash values and n evaluations of H total, or, on average, 1 evaluation per value output.
  • Jakobsson's method requires storage of about log 2 n hash values, and cannot be used when less storage is available. Note that for a hash chain of length 365, this means that 9 values need to be stored, and for a hash chain of length 1,000,000, this means that 20 values need to be stored. We would like to have an algorithm with lower storage requirements. Moreover, we would like to be able to specify storage requirements that are independent of the hash chain length. This way, the same amount of memory would be needed to manage short chains and long chains; thus, one would not need to acquire new memory if hash chain lengths change.
  • pebbles may start out in arbitrary positions on the hash chain.
  • the best algorithm for two pebbles takes n(n+l)/2 total steps, or n/2 steps per output on average. For example, for a hash chain of length 1,000,000, the average number of steps is 500,000 per value output.
  • pebble number 4 will move to the beginning point of each interval of size s, in order from left to right.
  • pebble number 2 will start, each time, and pebble number 3.
  • pebble number 1 will traverse the subinterval, each time starting at pebble number 2.
  • the cost of traversing each interval will be sqrt ⁇ s ⁇ , or
  • Pebble number 3 will be moved n/s times: n-s steps at first, n-2s steps next, and so on, giving the average cost of (n/s)/2 n (1/3) /2 per value output.
  • the average number of steps per value output is
  • the average number of steps is 150 per value output.
  • pebble 2a While any given interval of size s is being traversed, pebble 2a will start at position n and move left to the beginning of the next interval. Note that pebble 2a needs to take fewer than n steps in order to get to its destination. The obvious approach would be for pebble 2a to take at most n/s steps for each output value in the interval. This would result in a worst-case cost of s+n/s r2sqrt ⁇ n ⁇ l steps per output value.
  • pebble 2a should start out “slowly” and then "speed up.” This way, the total number of steps taken by pebbles 1 and 2a will stay constant. Specifically, pebble 2a should take (n/s)/2 steps at first, (n/s)/2+l steps the next time, and so on, up to 3(n/s)/2 steps when the last value of the interval is being output. This will reduce the worst-case cost further to
  • T2n 1 3 1. Taking again the example of the chain of length 1,000,000, the worst-case cost would be 200, while the average-case cost would 150 per output value.
  • F(c, n) the number of steps necessary to traverse a hash chain of length n while storing no more than c pebbles at any given time.
  • F(c, 0) 0 for any c > 1
  • F(0, n) for any n.
  • F(k, n) min k F(c-1, k)+ F(c, n-k-1) + n-k, and k should be chosen to minimize (c, n).
  • the scenarios may include multiple doors, and multiple users.
  • the access might be controlled by multiple authorities (each authority controlling access through some doors, the sets of doors for different authorities possibly overlapping).
  • the access is controlled by having the users presenting credentials to the doors (verification of such a credential may require interaction between the user and the door, such as PIN entry, as well as an exchange of messages between the door and the user's card).
  • credentials may require interaction between the user and the door, such as PIN entry, as well as an exchange of messages between the door and the user's card.
  • PIN entry a credential
  • the doors it is especially important to support the security of the access with the least cost and even without connectivity of the door to a network or any specific server.
  • RTCs can be utilized in conjunction with either public key cryptography methods (certificates, public key signatures, PKI) as well as the private key cryptographic tools (symmetric or private key signatures and encryption, Kerberos-like systems, etc.)
  • private-key encryption In particular, private-key encryption, private-key signatures (aka MACs), private key random functions, are typical private-key primitives that we shall be using. For many of our pu ⁇ oses, these primitives could be used interchangeably. For instance, deterministic private-key signature schemes (between two entities who share a secret signing key SK), and random functions Fs (whose seed s is shared between two entities) can actually be considered equivalent. Both produce outputs that are unpredictable to third parties who might know the corresponding inputs, but not SK or s. For instance, the functions FSK(x) that returns the digital signature of x with secret key SK can, in practice, be considered a good enough pseudo-random function with seed SK. On the other hand, the function Fs(x), that on input x returns the value at x of pseudo-random function F with seed s, could be considered a private-key signature algorithm with secret key s.
  • a function F is one-way if (1) given an input X, one can efficiently compute F(X), while (2) given F(X), where X has preferably been chosen sufficiently at random so as to be sufficiently unpredictable, computing X is practically impossible (e.g., because too many values for X would have to be tried in principle, and no efficient method exists to narrow the number of possible candidates).
  • H a one-way hash function
  • private-key signatures can be constructed in the following simple way. To sign a message M with secret key SK, one computes H(SK,M); that is, one properly combines SK and M — eg, concatenates them — and then hashes the result. Of course, to sign and date M, one can add a date d to this combination and thus compute H(SK,M,d) instead.
  • pseudo-random functions can be constructed as follows. On input x, to produce the output of a pseudo-random function F with seed s, one may compute H(s,x); that is, one may properly combine s and x, and then apply a one-way hash function to the result. Secure Physical Access
  • D be a door (with the said mechanism), A an organization that whishes to control access to D, and U a user (possibly working for A), again having a card, CU, with proper identifiers, etc. Then A may control access to D by sharing a secret key SK with D. If A wishes to grant U access to D on day d (time interval d), it computes a proof PUDd, that it is hard for anyone other than A (and possibly D) to compute but easy for D to verify. Let us see how this can be done, both using private-key encryption and private-key signatures.
  • PUDd may be the encryption, EUDd, of a message specifying
  • U possibly D as well, and d with the private encryption key SK according to some established private-key encryption algorithm such as DES.
  • D decrypts it with key SK, and if the result specifies both U and the current day (time interval) d, then the door opens.
  • the door may use its own clock to determine whether its own time falls within time interval d.
  • U is intended to denote both the user as well as a proper identifier for U. If user U has a card (preferably securely) associated with him, then U may be such card or a proper identifier of it. In the latter case, for instance, the door's card reader may get U from the card and also get EUDd, then it decrypts EUDd with key SK and compares the decrypted U with that furnished by the card, to ensure that they are equal.
  • the door's card reader may get U from the card and also get EUDd, then it decrypts EUDd with key SK and compares the decrypted U with that furnished by the card, to ensure that they are equal.
  • EUDd proves to the door D that user U is authorized to enter through it on time interval d, but this does not prove to D that it is indeed dealing with user U.
  • authority A may provide EUDd only to U's card, and U's card is provided with a key pad, and can transfer EUDd to the door D only if the right PIN is entered on its key pad (and the card may self-destroy, or erase its relevant volatile memory content if the wrong PIN is entered more than a given number of times).
  • U's card Because A only transfers EUDd to U's card, and it knows that the "user behind the card" must be U (as opposed to a malicious user having stolen U's card) because U's card would not work or transfer EUDd to D unless U's PIN has been entered on its key pad.
  • a second way for U to prove his identity to D consists of having U provide his own PIN directly to D. For instance, door D may have its own key pad, and U uses it to enter his own PIN, PINu.
  • the door may have an internal way (e.g., a table) that maps PINu to U, and thus can realize that it is indeed dealing with U.
  • U's identifier may directly be PINu.
  • EUDd might be EPINuDd.
  • the door then checks whether the PIN entered equals that specified in EPINuDd, and in this case it is dealing with the right user and that this same user is authorized by A to go through door D without using any PIN-user table: indeed, the key pad tells D that a user knowing PINu is in front of it, and EPINuDd tells D that the user knowing PINu is currently authorized to go through D.
  • the user PIN may be securely coupled with EUDd.
  • door D will check that the PIN is securely bound to the user's authorization for time interval d.
  • it uses PINu to decrypt EUDd and checks that EUDd is a proper authorization using the key SK it shares with authority A.
  • responders These are devices (such as servers or computer terminals/card readers capable of being linked to a server). Preferably these responders need not be vaulted or protected. Such protection could add so much cost and inconvenience to the system that it is crucial to have the system work securely without securing the responders!
  • authority A performs an update at every date d of a series of dates. Each date preferably specifies a time interval (e.g., a day). For instance d may be day d or the beginning of day d.
  • A decides which user U should be granted access to/through D, and computes a proof verifiable by D of this fact.
  • this proof may be the string EUDd discussed above and can be verified because A shares with D the key SK that A used to compute EUDd. All these proofs are then send to the responders.
  • These responders are preferably located in convenient locations. For instance, in an ai ⁇ ort system, responders may be located at the ai ⁇ ort main entrances. User U then (e.g., when arriving at work) picks up from a responder his own authorization to go through door D. Preferably, U's card may authenticate itself to the responder in order to receive EUDd.
  • PUDd can be a value EUDdk, consisting of indications of user U, door D and day d, as well as some random secret k, all encrypted (by A) with the secret key SKD.
  • EUDdk a value of indications of user U, door D and day d, as well as some random secret k, all encrypted (by A) with the secret key SKD.
  • U cannot decrypt EUDdk.
  • U would receive Ek - namely, k encrypted with SKU. (D and d might be known to U, or could be communicated to U -e.g., by the same responders at the main door.) This way, because U knows SKU, U obtains secret k as well.
  • card U In order to enter the door D, card U would send EUDdk to D. D would respond with a random value q, and card U would then send Eq, i.e., q encrypted using secret k. The door D would decrypt Eq, verify that the same q was used, and U is the same as that specified in EUDdk, and that the date d is current and if all the checks are confirmed, will let U through. This mechanism could inco ⁇ orate PIN mechanism as above, making it even more secure. Alternative Challenge-Response methods based on k are possible. (In particular, D can compute and send Eq and ask U to send back the correct decryption q.) Such mechanisms provide security even if the attacker monitors the communication between the card and the door.
  • PUDd may be the private-key digital signature of a message specifying both U and d (and possibly D as well) with private key SK, known to both A and D, according to some established private-key signature algorithm.
  • H be a one-way hash function
  • PUDd H(SK,U,d).
  • the door's reader may sign U and d with its own private key SK and compare whether the result of this computation matches the string PUDd obtained from the card.
  • the door reader, carrying a clock may know what is the current day d, and thus needs not to receive it from the card. This works as long as A grants access for full days at a time.
  • the card also sends d (or the chosen time interval) to the reader, and then the reader digitally signs with SK the obtained U and d, checks that the result indeed equals PUDd, and then that the current time (according to the door's clock) is within d. If so it opens.
  • U may be asked to enter a PIN as part of the transaction.
  • the PIN may also be used as part of U.
  • U may consist of u and PIN, where u is a string identifying the user, and PIN a password known to the user.
  • d is card-supplied, it also checks that the current time is within d. This method makes couples a user and his card in a tighter way, so that a enemy that steals the card would have hard time using it without the proper PIN.
  • each door D may have secret key SKD.
  • U may receive from A (e.g., using mechanisms discussed above, in particular, utilizing encryption) a secret key SKUd for the day d. He may then "prove" to the door D his identity and/or authorization using private-key signatures. Namely, the door D would send to the card U a random message m; in response card U would send the signature of m: H(m,SKUd). Note: computation of this signature may require the PINu. The door D then verifies the signature. This may require that the door D knows SKUd (e.g., having received it from A directly, or compute it from some other information: e.g.
  • A may encrypt SKUd with a key A shares with D, obtaining ESKUd. Then ESKUd can be given to U (e.g., as described above), and then U can send it to D together with the signature.
  • each organization X shares a secret key SKXD with door D, and then use on the solutions described above. For instance, each organization X may choose SKXD and insert it into D's reader. Each organization X may have to send a team of one or more employee/hired workers/contractors/subcontractors from door to door.
  • Kerberos and Needham-Schroeder protocols provide a mechanism for ensuring that pairs of entities share secret session keys, and could be applied here within the overall system. However, these protocols are based on a key-distribution center that is on-line and must be contacted whenever a shared session key is needed. Thus, we wish to put forward additional and more convenient methods. To begin with, even for implementing a Kerberos/Needham-Schroeder based system, we need a way for a central authority to distribute keys to doors (which may be harder than distributing keys to other authorities).
  • SA may be the only entity that can do so.
  • the door reader is delivered with no secret keys inside, and is manufactured so that once the first set of secret keys (possibly a set of a single key) is inserted, then the readers stores it for a long time, and accepts no other keys for storage in the future.
  • SA ensures that no one else can install secret keys into the door.
  • a control PIN or key is needed for storing other secret keys into a door reader.
  • the door reader is delivered without any control PINs or keys, and is manufactured so that once the first control PIN or key (or possibly a set of them) is inserted, then the reader stores it for a long time, and accepts no other control PINs or keys in the future. However, provided the right control PIN/key is input, then any new key could be inserted and stored into the reader. This way, by being the first one to insert any control PIN/key into the door reader (before, during, or soon after installation), SA ensures that no one else can insert and store a secret key into a door reader.
  • authority X may control access to door DI and authority Y may control door D2 in a totally independent manner.
  • Key-storage size While it is preferable that a door reader stores different keys for each different organization controlling it, this drives up the number of keys that a reader should securely store.
  • Adding new control issues may come up when a new authority or a new door is introduced in the system. If a door D does not store a key for organization X, and later on it is desired that X gains control over D, then SA must insert a key for X into D's reader. For instance, if a new organization comes up, then the SA must dispatch a team of workers to insert SKXD into every door D that should be control by the new organization. Such physical "tours," however, may be inconvenient. To avoid them, the SA may pre-install additional keys into a door D's reader, and then bind them to new organizations that arise, or to organization that later on must control access through D. This strategy, however, only exacerbates the point described in the first bullet. Furthermore, if a new door is introduced, to be controlled by some already existing authorities, then the SA will have to insert new keys in the door reader, and then deliver the proper secret keys to the already existing authorities that must control it. Though doable, delivering secret keys always is problematic.
  • the SA stores in door D the single key SKD (and of course keeps track of this information).
  • the SA then gives control over D to authority X by giving X a key SKXD chosen deterministically from SKD and X, for instance as a pseudo-random function with seed SKD evaluated at X (for simplicity we assume throughout that an entity coincides with a proper identifier of it).
  • SKXD H(SKD,X).
  • Authority X uses SKXD to grant user U access to D for a time interval (e.g., day) d as before.
  • U's card communicates with D's reader, then the card provides the reader with (a) X and (b) SKXDUd and possibly other information, such as d (as well as information about the user U).
  • the reader Upon receiving this information, the reader computes H(SKD,X) and then uses the result (allegedly equal to SKXD ) as the signing key of the same private-key signature scheme and signs (U,d) — in the example above by hashing (U,d) after combining it with SKXD. If the result matches the value tended by the card (allegedly, SKXDUd), if the time interval is right relative to the reader clock (and if U entered the right PIN, if PINs are properly used within the above system), then the door opens.
  • this signature may be a private-key signature relative to a key SKD that SA shares with door D.
  • this signature could be the value H(SKD,valid,X,d'). Notice that even if though being a private-key signature, the signature itself can be made public without worries. Indeed, using the H-based implementation of a private-key signature described above, if H is a secure one-way hash function, then computing SKD from H(SKD,valid,X,d') is very hard.
  • time intervals d and d' may not be the same.
  • SA may be satisfied to grant control over D to X on a weekly basis, while X may grant access through D to users on a daily basis.
  • SA simply stops sending SKXDd for the periods d for which SA decides to deny X control over door D.
  • SA grants organization X control over door D for a given time interval. During that time interval, X may itself grant a user U access to D.
  • d could be the beginning of a given day and the corresponding time interval the given day.
  • d we may use d to mean both the date and the corresponding time interval. (It should be understood, however, that this is not a limitation: for instance, a date could be a given day, and the time interval corresponding to the date the following day.)
  • each date/time interval is a day.
  • SA shares a secret key SKD with door D.
  • SA may also share a secret key SKX with organization X.
  • SKD could be generated by A via a master secret key SK.
  • SKX For instance, SKD could equal H(SK,D) and
  • SKX could equal H(SK,X).
  • SA may then privately -or via encryption — provide D with SKD. Similarly for X.)
  • SKXDd secret key
  • the SA At each day d, if the SA wishes to grant organization X access to door D, it computes and causes X to receive secret key SKXDd, that is a key securely bound to X,D, and day d that is verifiable by D (e.g., on inputs X and d).
  • SKXDd H(SKD,X,d), that is, SA signs X,d with key SKD.
  • SA then causes X to receive SKXDd.
  • SA may cause X to receive SKXDd by sending
  • SKXDd to X, preferably after encrypting it with a secret key SKX shared with X.
  • SA sends the so encrypted SKXDd to X by causing it to be stored in a responder, from which X then downloads it.
  • X If X wishes to grant user U access to D in time interval t within day d, X computes and causes U to receive a secret key SKXDdUt, that is a key securely bound to X, D, U and t that is verifiable by D.
  • SKXDdUt a secret key securely bound to X, D, U and t that is verifiable by D.
  • SKXDdUt H(SKXDd,U,t), that is, X signs U,t with key
  • SKXDd. X then causes U to receive SKXDdUt. X may cause U to receive
  • SKXDdUt by sending SKXDdUt to X, preferably after encrypting it with a secret key SKU shared with U.
  • X sends the so encrypted SKXDdUt to U by causing it to be stored in a responder, from which U then downloads it.
  • U If U wishes to access D at time interval t, U causes D to receive X, U, t (e.g., U's card transfers the to D's reader).
  • D receives X, U, t at day d, it computes SKXDd from its secret key SKD and then computes SKXDdUt from SKXDd. D then verifies that time interval t is indeed within day d, and using its own clock that indeed the current time is within time interval t. Further, D verifies that it is dealing with U/U's card by a challenge- response mechanism using key SKXDdUt. If these verifications are passed, D opens. For instance, D may compute SKXDd from its secret key SKD by computing H(SKD,X,d), and then compute SKXDdUt from SKXDd by computing H(SKXDd,U,t).
  • the challenge-response mechanism using key SKXDdUt may consist of having D send a random string q and receive back the encryption of q with key SKXDdUt, or a digital signature of q with key SKXDdUt.
  • D may send Eq, the encryption of q with key SKXDdUt, and must receive back q.
  • the preferred scheme should be understood to include using a PIN in conjunction with the above.
  • any PIN use described in prior sections may be used within the preferred scheme.
  • Kerberos approach directly would not work very well in our secure access application. It is most natural to implement all the doors and the SA as one realm (with SA acting as a Ticket Granting Service, TGS, for that realm). Each organization and its employees would then be a separate realm. The authority for each organization would then act as the Authentication Service, AS, for that realm (as well as possibly its own TGS). According to the Kerberos protocols, each user would then authenticate to the respective authority/AS obtaining a ticket-granting ticket, TGT. This ticket TGT would then be sent by the user to the SA TGS, along with the request for a service granting ticket for each of the doors the user is entitled to.
  • the SA/TGS would then have to verify the user's eligibility and, if the user -if all is correct- provide these service-granting tickets.
  • This protocol is obviously quite laborious, and places much of the burden on the SA. In particular, it will be SA's responsibility to verify which doors the particular user is entitled to and issue the respective tickets. Moreover, it demands that SA be on-line and engage in the protocols in real-time. Having the users a channel to the SA presents an extra security threat as well.
  • RTCs For example, we could use the tickets as in the above approach. However, in this approach we may not generate the tickets on a daily basis. Instead, we may use long-range tickets, managing the short-range access controls via RTCs passed in the Authorization-Data field of the ticket.
  • the RTCs could work in this case exactly the same way as in the case of the public key certificates. However, some optimizations are possible here as well.
  • RTCs As above brings a number of possible benefits. These include (but are not limited to):
  • RTCs allow a clear separation of roles, facilitating many aspects of management and infrastructure.
  • Efficiency a. Space: an RTC is much smaller than a corresponding ticket.
  • Time Because they are much shorter (and there are fewer of them and fewer numbers of communication rounds) the communication would be much faster, enabling the users to move through the doors while picking up the RTCs at a reasonable pace.
  • Load distribution RTCs can be distributed by non-secured responders. Replication of RTCs would also be neither expensive, nor dangerous.
  • RTCs are not security-sensitive, once they are generated, and can be managed with greater ease (e.g., by unsecured responders) and without any threat to security.
  • RTC The separation of tickets and authorizations (via RTC) allows for a greater security in key management (when the keys/tickets are actually generated and communicated)
  • SA isolation SA never really needs to have a direct communication line with any of the users. Beyond Kerberos
  • the special authority SA would share a secret with each organization A (B,C, ...) and with each door D. This can be done, for example, using methods as above so that SA needs to store only a single secret s.
  • both A and D also need to store only one secret: SKA or SKD, respectively.
  • SKA or SKD secret to each organization- door pair (A,D)
  • SKAD Hash(SKD, A). This secret can be easily computed by both SK and D. Giving SKAD to A can be necessary but possibly not sufficient for A to control access to the door.
  • A may need to receive from SA (or from another party) an RTC for the current time period d. This RTC, termed RTCAd, need not be secret and may certify that A is still in good standing with SA.
  • the user U may need to present the RTCAd and RTCAUDd, as well as perform the authentication based on the secret SKAUD (this authentication may be of the challenge-response type to protect the secret).
  • this authentication may be of the challenge-response type to protect the secret.
  • each door may validate each RTCAd it receives and cache the result, to be used for other users' validation.
  • the special authority SA may wish to exercise a finer grain control of the organizations' access to the doors.
  • SA may issue an RTC per each organization door pair (A,D): RTCADd.
  • RTC per each organization door pair
  • S A it would be possible for S A to grant and take back control over each door by each organization on a daily basis. Note that this may at most double the amount of RTC data that each user would need to receive (still keeping the required transition time for the above example at a fraction of a second).
  • RTCAUDd credentials to be issued and distributed by all the organizations. Let us divide all the organization-user-door triplets AUD's into hierarchically arranged groups. It may be easy to visualize these for example as follows. Let all the AUD's correspond to the leaves of a balanced binary tree (ordered in a preferred fashion). Than each node n of the tree corresponds to a set of all the AUD's corresponding to the leaves in the subtree of n. To each such node and a time period d, let there correspond also a credential RTCnd. Then the validity of AUD triplet in the period d can be certified by any of the credentials RTCnd, for any of the AUD ancestors n. Thus, if all the AUD triplets remain valid on day d, then a single credential RTCr, where r is the root of the tree, is sufficient for the whole system.
  • validation of such aggregate credentials may be optimized, e.g., by caching the results at least for the larger groups.
  • RTCd refers to the credential ID.
  • RTC refers to the credential ID.
  • RTC refers to the credential ID.
  • RTCAUDd Hash(SKAD,U,d).
  • CRLs may grow big because they provide proofs of revocation (and thus, indirectly, of validity) about many certificates lumped together.
  • the OCSP provides proofs of validity of for individual certificate.
  • OCSP services are typically implemented by OCSP Responders.
  • a responder is a server that, upon receiving a question from a client (aka Relying Party) about the validity of a given certificate issued by a given CA, provides a digitally signed answer indicating both the status of the certificate and the time of the answer. For doing this, it is necessary for the OCSP responder to know the status of all of the CA's certificates, since it is the CA that can revoke its own certificates. If the OCSP responder were the CA itself, such knowledge is trivially acquired.
  • the CA may send the responder its most recent CRL, and the responder may consult that signed document to deduce whether the certificate of interest is currently valid or revoked and so say in its signed response, also indicating the time, as well the time of the next update. (Here it is natural for this update time to coincide with the date of the next CRL of the CA, since it is that CRL that may trigger a different response.)
  • a malicious responder may provide arbitrary signed answers about the certificates of a given CA, with or without consulting the latter' s CRLs.
  • the OCSP envisages that the CA providing the responder with a responder certificate, a special digital certificate —signed by the CA- that essentially proves to other parties that the CA trusts the responder to provide accurate proofs about its certificates.
  • each OCSP responder (as well as every CA) must have a secret signing key, and this key must be protected (ideally by placing it or the server using it in a vault).
  • FIG. 2 shows this sequence of transactions in a trivial OCSP environment.
  • the fact that secret signing keys are protected is graphically emphasized by putting them with some thick "borders.”
  • the name of the signer is indicated immediately below.
  • This figure shows the various PKI-sensitive elements of this transaction as shaded boxes.
  • the Certificate Authority itself has a private key, SKI, that must be kept secure to prevent the unauthorized issuance and revocation of certificates. This key is used to sign the CRL that is published to the OCSP Responders.
  • the secret key of responder 1A must also be kept secure, and is used for signing the OCSP responses of responder 1A.
  • Digital signatures are computationally intensive operations.
  • the digital signature created by the Responder on each response is generated at the time of the request, and is by far the most computationally intensive part of the validation operation: it can easily add anywhere from 50 milliseconds to 1 second to the transaction time.
  • DRAWBACK 2 Communication (with centralized implementations)
  • DRAWBACK 3 Security (if distributed implementations)
  • a CA may consider distributing the request load generated by its certificates by distributing it across several OCSP servers (that it properly certifies).
  • load distribution introduces worse problems than those it solves.
  • each of the 100 servers should have its own secret signing key. Thus, compromising any of the 100 servers would effectively compromise the entire system.
  • OCSP has difficulties in servicing certificate validity requests originating from different security domains.
  • the Responder run by organization #1 is able to provide responses about the status of certificates from CA #1, but Responders run by another organization may not have enough information to provide responses about the "foreign" certificates.
  • Responder 2A run by certification authority CA 2 does not know how to answer requests about CA l's certificates.
  • the Relying Parties from organization #2 could find the Responders from organization #1 to ask them about the status of certificates from CA #1. This limits performance however, since the Responders from organization #1 may be geographically distant from Relying Parties interested in organization #2, so network times may greatly slow overall validation processing.
  • the second alternative is to allow Responders from organization #2 to make responses about certificates from organization #1, by having CA #1 forward its CRLs also to "foreign" responders.
  • CA 1 should also certify Responder 2A as trustworthy for answering validity queries about its own certificates. The whole process is illustrated by FIG. 5.
  • Responder #2A is making an authoritative response to the Relying Party that the certificate #321 of CA #1 is still good. Making an incorrect response for any reason (misconfiguration, hostile attack, or straightforward dishonesty), Responder 2A may cause adverse consequences for users from organization #1.
  • Responder #2 A By allowing Responder #2 A to make authoritative claims about its own certificates, organization #1 is relinquishing some of the trust that it previously held.
  • the organizations are credit card issuers.
  • Bank #1 revokes the card certificate for user #321, and it pays to ensure that its Responders are secure and reliable.
  • the Responders from Bank #2 are misconfigured, so when a merchant Relying Party asks about the validity of user #321, they incorrectly respond that the user is valid. The merchant accepts this answer and allows a transaction to proceed for the revoked user.
  • This type of delegation-of-trust between organizations may be acceptable in some cases, but it is not a generally useful alternative for any large-scale heterogeneous deployment of traditional OCSP.
  • RTC Real Time Credentials
  • the RTC System comprises the following steps: 77ze CA certifies the RTCA:
  • the new system is centered around the RTC authority (RTCA).
  • RTCA RTC authority
  • each CA provides its own RTC with a special certificate, the RTCA certificate.
  • the CA preferably digitally signs this certificate, indicating that it trusts and indeed empowers the RTCA to provide certificate validity information about its own certificates.
  • Such a certificate may bind a given verification key PK (for which the RTCA possesses a corresponding secret signing key) to the RTC authority (e.g., identified by a given identifier, OID number) and specify in some fashion that the certificate essentially confers RTC status, and may include other traditional certificate information and formats.
  • each CA has only one RTC, though for redundancy pu ⁇ oses, it may be advantageous to have more than one, whether or not using the same signing key.
  • the RTCA protects its signing key:
  • the RTCA must protect its signing key, for instance by means of a vault or secure facility. (As we shall see, however, there is no need of additional vaults for certificate validation pu ⁇ oses!
  • the RTCA may host in the same protected facility more than one server embedding its secret signing key, or securely store (e.g., in Banks' safe security boxes) copies of the key, or host more than one server each having a secret signing key properly certified by the C A.
  • the CA informs the RTCA of the status of its certificates. For instance, it keeps it appraised on any change in certificate validity in an on-line/real-time fashion (such as sending a message informing the RTCA of a change in certificate status as soon as it occurs). Alternatively, it may send the RTCA its CRLs when produced.
  • the RTCA individually signs the validity status of each certificate for a given interval of time, independent of any request: Preferably periodically (or at any date of a sequence of dates), the RTCA, based on its current validation knowledge (e.g., based on the latest CRL of the CA) and independent of any Relying Party request, processes each outstanding certificate of its CA, and digitally signs a declaration stating the status of that certificate.
  • the result therefore carries a time component indicating the next update for that certificate. If the period of the RTC depends on the CA-issued CRLs, the update time may be that of the next CRL.
  • the time component may also indicate the issuance time of the CRL used in the processing.
  • the RTCA pre-computes a digital signature indicating the status of each certificate for a given time interval T (e.g., from the date of the latest CRL — or from a date sufficiently close to it — to the date of the next CRL — or to a date sufficiently close to it, in either case so as to allow time sufficient from processing all the necessary information).
  • T time interval
  • the RTCA pre-computes all such signed declaration of certificate status before any queries about certificate status in that time interval are made, or before that time interval altogether.
  • the RTCA may pre-compute all its signed declarations about time interval T one minute before T starts.
  • the RTCA signed declarations of certificate validity are in standard OCSP format. That is, in essence, the RTCA preferably pre-computing OCSP- compliant responses to OCSP requests that have not yet been generated. This is important because OCSP software is already in place, and it would be very convenient to take advantage of the RTC system without having to modify any of the existing relying party software.
  • the RTCA sends his pre-computed signatures of validity status to unprotected responder: After pre-computing such a signature, the RTCA makes it available (e.g., sends it to) to other parties, including relying parties (e.g., in response to requests of theirs), but, in particular, to responders. These responders need not be protected. In fact they handle RTCA-signed messages, and these cannot in essence be fraudulently modified or altered in an undetectable way. Indeed, the RTCA may easily send them to foreign responders (responders belonging to other organizations) with any jeopardizing security. The RTCA may facilitate the responder processing of its signatures by presenting them to the responder in a suitably organized fashion.
  • the RTCA may sign and date the totality of its responses (e.g., all those relative to the same time interval and CA).
  • an RTCA preferably sends to its responders its own RTCA certificate. This transmission needs not occur at every update. In particular can be performed only initially.
  • the responders store the RTCA-pre-computed signatures:
  • a responder stores the received pre-computed signatures of the RTCA for a sufficient time. Preferably, if these signatures relate to a given time interval T, they store them at least until the end of T.
  • the responders (especially those belonging to the same organization as the RTCA) may be pro-active and check that they received the proper RTCA signatures correctly and on time. For instance, a responder may: (1) Verify that the pre-computed responses about a time interval T are received by the beginning of T (or other suitable time related T);
  • Relying parties ask responders for validity status information Relying parties ask responders for the validity status of certificates. Preferably, they do so using the OCSP format for their requests.
  • Responders answer queries with pre-computed responses: When asked about the validity of a given certificate, the responder fetches from memory the RTCA pre-computed answer for that certificate and returns it.
  • a responder may also forward the proper certificate for the RTCA that has signed the pre-computed response
  • Relying parties process the receive responses to ascertain the validity status of the certificate of interest.
  • the response is in OCSP format, they use OCSP software for such processing.
  • they verify the proper RTCA certificates.
  • certificates may be hierarchical certificates and that proofs of the currently validity of CA certificates and CRTA certificates may be added and verified whenever needed.
  • FIG. 6 illustrates the RTC System.
  • the RTCA periodically generates digitally signed validity declarations
  • each proof is preferably structured as a syntactically correct OCSP response, signed by the RTCA private key.
  • the RTC responder When a relying party asks about the status of a certificate, the RTC responder is able to return the corresponding pre-generated response which it has cached. The relying party can verify the signature of the RTCA. (In addition, it can also verify the RTCA's certificate, to ensure tat it is dealing with an authentic RTC authority for the given CA. Of course, this like all other certificates can be hierarchical.
  • Digital signatures are computationally intensive operations. But the RTC system concentrates this difficulty on a single server (entity): the RTCA. It is therefore very easy and relatively inexpensive to equip with this single entity with a computer sufficiently powerful to handle all required digital signatures.
  • the RTC responders perform only trivial computations. They essentially (1) store the RTCA signatures and (2) perform just fetch-and-forward operations in response to relying parties queries. Therefore they can be implemented with very inexpensive hardware. As a result, the total RTC cost may be significantly lower than that of the OCSP! At the same time, response time is much quicker. Indeed, the time for a very inexpensive RTC responder for fetching and sending a pre-computed RTCA response is negligible relative to that taken by an OCSP responder which must perform a digital signature in response to a relying party request.
  • responders may employ trivial hardware and do not need to be secure. Consequently RTC responders are very cheap indeed, and can be deployed in great numbers. That is, one can always afford distributed implementations of RTC system. Therefore, even if enormously many certificate- validity requests are generated in a short amount of time, this load can always be spread across many RTC responders, eliminating the risk of congestion and benign denial of service without incurring much cost. (Notice that the amount of work of the RTCA solely depends on the number of certificates and is not affected by the number of validity-status requests. Thus a single RCA can be used even if millions and millions of validity requested are expected.) ADVANTAGE 3: Security
  • the responders do not store any secret key: they only store the digital signatures of the RTCA, but for all security pu ⁇ oses may be made totally public after being computed by the RTCA.
  • each OCSP responder has a secret signing key, compromising which one may compromise the entire system. Therefore defending a single site is preferable and easier than defending many and equally important sites.
  • relying parties cannot easily mount software attacks.
  • the RTC responders service relying parties' requests with non-secret information. In fact they do not have any secret keys themselves and need only store pre-computed digital signatures. Thus, even if a relying party succeeded in embedding in its query some kind of Trojan horse, it would be able to expose nothing. At most it can expose all a RTC responder knows, and that is the full and accurate account of which certificates are valid and which are revoked in a given time interval. And this not only is non-secret information, but it is even information that a certification authority would like to be universally known, so that no one may rely incorrectly on one of its certificates!
  • ADVANTAGE 4 Trust Flow
  • the following diagram shows how RTC-over-OCSP would be deployed in a cross-CA environment.
  • FIG. 7 shows how a responder from organization #2 can relay (preferably, OCSP compliant) responses from organization #1 without needing to transfer any trust from organization #1 to responders of organization #2.
  • RTC responders are simple, non-trusted relays of information, they can be widely distributed and mrrrored without reducing overall system security.
  • a relying party queries a responder of organization 2 (Responder 2B) about the validity of a certificate of organization #1. Notice that the (preferably OCSP compliant) response that it gets back it convincing because it is digitally signed by an RTCA of organization #1 (RTCA1).
  • the direct digital signature from the right organization (which is best positioned to know which of its own certificates are still valid, and which has the greatest interest in not making mistakes) is preferably co ⁇ oborated by the fact that the relying party also gets RTCAl 's certificate (preferably signed by CA1) that vouches that RTCA1 is indeed a proper RTC authority of organization 1.
  • organization #1 enables the responders of organization #2 to provide convincing proofs of validity for organization #l's certificates without relinquishing any amount of control over the validity status of its own certificates. That is, in the RTC system trust may flow from one organization to another with any associated loss of neither security nor control.
  • FIG. 7 shows the extreme case, where Responders are treated as transparent network infrastructure rather than hardened trust points. It shows how the extreme case of RTC enabling the secure construction of a heterogeneous cloud of Responders that are capable of servicing requests about the status of certificates from many sources. This is similar to the service cloud offered by the Internet's DNS infrastructure, in that it allows for a heterogeneous collection of name servers that transparently interoperate to discover and cache valid responses for queries.
  • This heterogeneity is a significant advantage of the RTC system over traditional OCSP. It allows a wide variety of organizations to interoperate so that relying parties from different organizations can cross-validate certificates from other organizations in a secure, reliable, efficient manner.
  • RTC Real Time Credentials
  • OCSP Open Certificate Status Protocol
  • RTC systems in fact, even when exercising the option of maintaining compatibility with the OCSP standards, provide significant advantages over the OCSP, so as to offer qualitatively superior security and scalability.
  • U be a party having a certificate Cu.
  • U may send Cu to V (unless V already has it), and possibly perform additional tasks (such as exhibiting a digital signature relative to a public verification key certified in Cu to belong to U, or being identified by decrypting a random challenge encrypted by V using a public encryption key certified in Cu to belong to U).
  • V might ascertain the current validity of Cu and make a validity query to a RTC responder. The responder would answer this query by fetching and returning the most cu ⁇ ent RTCA-signed declaration about Cu.
  • querying an RTC responder makes 3-party a transaction that would otherwise be 2-party, increasing the time of the desired U-V transaction.
  • RTC may significantly help.
  • party U may, at the beginning of each time interval T (or during it anyway), receive an RTCA-signed declaration Du that Cu is valid throughout T.
  • U can receive Du in response to a request to his (e.g., by making a ordinary relying-party request) or may be pushed Du (e.g, by an RTC responder or by an RTCA at every update on an automatic basis).
  • Du e.g., by an RTC responder or by an RTCA at every update on an automatic basis.
  • transacting with V during interval T U may forward Du to V, in addition to all other steps or tasks the transaction entails. Therefore, the U-V transaction is significantly sped up, since V needs not call any third party in order to ascertain the current validity of U's certificate.
  • the "overall time,” which includes U obtaining Du, may not be sped up, the U-V transaction will be. Notice that speeding up only the U- V transaction without saving in overall time, may still be quite valuable.
  • RTCA declarations are computed at midnight and specify an entire day as their time interval. Then, U may obtain Du early in the day (when no real pressure exists) and then forward it to V during a time sensitive U-V transaction conducted during working hours, when saving time could be essential. Further efficiency is gained, if U, after obtaining and caching DU, forwards it throughout the day when transacting with several (e.g., 100) parties. This way, for instance, a single relying- party query (that of U itself, possibly made at a relaxed time) successfully replaces 100 relying-party requests (possibly at times of pressure).
  • party V can give to U, or make Du available for others to use.
  • the RTC system may be implemented using data found in the individual certificates, thereby saving additional certificates and/or response length.
  • the CA may issue an RTCA certificate that empowers a given RTCA to provide authoritative answers about the validity of its own certificates.
  • Such an RTCA certificate ideally specifies the public key that must be used for verifying the RTCA-signed responses.
  • the CA may however, embed this RTCA public key within its own certificates. That is, the CA (with proper format, OID, etc.) may include in a certificate Cu also the public key PK that should be used for verifying the digitally signed responses about Cu's validity. This way, a relying party needs not receive a separate RTCA certificate.
  • Cu specifies within itself the public verification key that a relying party may use for verifying a proof of validity for Cu. This may yield significant savings in transmission (since the RTC responder may not need to send a separate RTCA certificate, which may be much longer than an RTCA response) and in storage (since the relying party may not need to store the RTCA certificate alongside with the RTCA response, as protection against future claims for having relied on Cu).
  • a certificate Cu may specify its own time intervals.
  • an RTCA response may not need to specify both the beginning and end of an interval T.
  • the beginning of T alone may pin-down T.
  • Cu specifies daily updates, then any time within a given day suffices to specify the entire day to which a response refers.
  • it is clear e.g., from the CA's general policies
  • the certificates have validity intervals consisting of a full day, then there is no need for this information to be specified within a certificate, and yet the same savings in RTCA responses apply.
  • a proof of revocation needs not specify any time interval: it suffices for it to specify a single point in time (e.g., the actual time of revocation).
  • revocation traditionally is an irrevocable process.
  • a single revocation time rt may suffice for proving a certificate revoked.
  • rt needs not be the beginning of any time interval T (e.g., it could be any time in "the middle of T").
  • the RTCA needs not send C's revocation proof at all updates dates (e.g., DI, D2, etc.).
  • a revocation proof could be sent only once (or a few times for redundancy) and then cached by an RTC responder and then returned whenever a relying-party query about C is made.
  • a good counter-measure consists of having proofs of revocation take precedence over proofs of validity. That is, an honest relying party that sees both a proof of validity for C for some time interval T and a proof of revocation for C (at whatever time t), should regard C as revoked (after time t).
  • CA/RTCA/ responder/party/user may be any entity (e.g., person, organization, server, device, computer program, computer file) or a collection of entities.
  • Certificates should be construed to include all kinds of certificates, and in particular hierarchical certificates and flat certificates (cfr. U.S. Patent No. 5,420,927 herein inco ⁇ orated by reference).
  • Validity status and proofs of validity status may include validity status and proofs of validity status for hierarchical certificates (e.g., validity status and proofs of validity status of all certificates in a chain of certificates).
  • Verifying the validity of a certificate C may include verifying the validity of the CA certificate for the CA having issued C, as well as the validity of the CRTA certificate for the RTCA that providing a signed response about the validity status of C.
  • certificates should include all kinds of digitally signed documents.
  • a vendor acting as a CA, may certify a price lists of its by digitally signing it (possibly together with date information). Validity status for such certificates is also very crucial.
  • a vendor may want to prove the cunent validity of a price list (and refuse honor a given price in a price lists, unless a proof of its currently validity is shown).
  • a customer may wish to ascertain the current validity of a price list document.
  • the RTC system is ideal (for its scalability and off-line processing) for proving the current validity of web pages.
  • RTCA generated proofs of current validity may be stored next (or in association with) the pages themselves.
  • a party can be considered a computer file.
  • Sending a piece of data D (to party X) should be construed to include making D available (or causing X to receive D).
  • the user has a credential stored on a wireless device (physical token).
  • This token preferably has the capability of securely storing a digital certificate and private key.
  • the token has a method of long-range (WAN) connectivity (such as GPRS, SMS, pager, CDMA, GSM, etc.) and a method of short-range (PAN) connectivity (such as Bluetooth, IR, RF, etc.)
  • WAN long-range
  • PAN long-range
  • PAN short-range
  • the token may also have one or more additional authentication factors (such as a keypad for a PIN or a biometric reader). This example assumes that the token is a bluetooth cell phone.
  • the door has a control panel with a small CPU capable of performing standard PKI operations and a method of short-range (PAN) connectivity to talk to the physical token.
  • PAN short-range
  • the user is prompted to enter a PIN number into her cell phone (or enter his own biometric info if a biometric reader is available). This prompt can happen once a day, the first time the user tries to go through a door, every few hours, randomly, upon receipt of a special SMS message, etc.
  • the PIN serves as a second factor of authentication (first being the certificate on the phone) and "unlocks" the phone for use in the physical access application. 4.
  • the phone and the door recognize each other and begin the initial authentication and validation sequence:
  • the door validates itself to the phone by sending the door's certificate via bluetooth to the phone.
  • the phone checks the certificate and validates the door using any of our standard methods (min-CRL of all doors periodically sent down to the phone is a good approach.) This solves the problem of "rogue readers” and makes sure that the door is a legitimate reader before the phone discloses any information.
  • the phone sends the door the user's certificate which contains the user's biometric minutiae.
  • the phone also sends an RTC proof (preferably, either Validation-token — i.e., a 20-byte proof of validity — or a Distributed-OCSP proof) to prove its current validity.
  • RTC proof preferably, either Validation-token — i.e., a 20-byte proof of validity — or a Distributed-OCSP proof
  • the door may do this for multiple (or even all) phones currently within range (multiple employees may be near the door).
  • Step 4.1 is an independent invention of independent interest, since it solves a known problem (eg. identified by the Department of Defense) for which there is no currently known solution.
  • the scheme may be augmented by having "revocation proofs or access logs travel to and/or from other people's cards/phones to disconnected doors".
  • a prefe ⁇ ed embodiment of the present invention is based on 20 byte, unforgeable, public "proofs". 20-byte proofs are cryptographically protected using a one-way function called hashing. The process is simple, does not need encryption and does not use digital signatures. These properties make this technology ideal for: large scale deployments (scales to 100s millions); bandwidth limited applications (e.g. wireless applications); offline validation (i.e., network connection not required).
  • Laptop theft is a serious problem that imposes replacement costs, loss of productivity, loss of unrecoverable (unbacked-up) data, loss of control over sensitive/confidential data (e.g. sensitive operational info, proposals to clients, email, calendar, contacts, pending mergers, new product IP, strategies, and launch plans, financial operating results, private compensation info.), and loss of network and infrastructure details (e.g. user names & passwords, dial-in numbers, IP addressing schemes, DNS naming conventions, and primary mail serves).
  • the present invention provides for leases, that is licenses to use for a specified period of time wherein the duration of the lease is a configurable parameter.
  • the technology of the present invention forces presence of valid "leases”.
  • Leases are 20 byte, unforgable, "public tokens": valid token, suspension token, and revocation token. New leases are received automatically.
  • a computer may be temporarily disabled and a system administrator or user can unsuspend a laptop.
  • a computer may be permanent disabled with possible recovery by the System Administrator.
  • FIG. 8 is a schematic illustration of the system operation according to one embodiment of the invention.
  • a valid lease token is produced once a day (hour, week etc.) by the central authority.
  • Getting a valid lease token onto the protected device can be accomplished in many different ways and is completely transparent to the end user.
  • valid lease tokens cease to be generated (no way to extend use past the current day); revocation token is propagated to the network (any connection renders device immediately unusable).
  • Stolen devices are turned off within: seconds (best case, if push capability is present); hours (average cast, as soon as any network connection is made); one day (worst case, no connection possible).
  • the system protects against random theft as well as theft by insiders. Stealing a device makes no sense, since: the hardware is unusable; the software is unusable; and the data is unreadable. Similar to some card radio brands, unusable if stolen and therefore deters theft.
  • Validity tokens are delivered by the following methods: wired network; wireless network; SMS wireless "push”; pager system; handheld telephone/PDA via infrared port; Bluetooth device; Manually typed in as received via alternate channel
  • FIG. 9 is a schematic illustration of a stolen computer timeline.
  • Alternative protection methods may be used including: physical anchor for prevention; asset tracking service for recover and as a detenent; motion sensor and alarm as deterrent; access keys as a deterrent and access control; tracking software for recover and as a deterrent; and data encryption which protects data only.
  • Potential attacks and results include:
  • Removing/circumventing software Possible if have "administrative privileges" but extremely difficult after revocation.
  • Optional BIOS/hardware countermeasures offer nearly 100% protection.
  • Replacement/reformat hard drive All secure data lost and optional BIPS/hardware hooks to prevent drive replacement.
  • Data can be encrypted.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Lock And Its Accessories (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention porte sur un système et sur un procédé de commande d'accès physique par l'intermédiaire d'un processus de validation de certificat numérique qui fonctionne avec des formats de certificat standards et qui permet à une autorité de certification (CA) de prouver l'état de validité de chaque certificat C dans n'importe quel intervalle de temps (par ex. jour, heure ou minute) à partir d'une date d'émission du certificat C, D1. La granularité du temps de C peut être déterminée dans le certificat lui-même, à moins qu'elle ne soit identique pour tous les certificats. Par exemple, tous les certificats peuvent avoir une granularité d'un jour, chaque certificat expirant 365 jours après son émission. Etant donné certaines entrées initiales produites par l'autorité de certification, une fonction de hachage unidirectionnelle est utilisée pour calculer des valeurs d'une taille d'octet déterminée qui sont gardées secrètes et utilisées dans le processus de validation.
EP03726222A 2002-04-08 2003-04-08 Commande d'acces physique Ceased EP1493131A2 (fr)

Applications Claiming Priority (25)

Application Number Priority Date Filing Date Title
US37086702P 2002-04-08 2002-04-08
US370867P 2002-04-08
US37295102P 2002-04-16 2002-04-16
US372951P 2002-04-16
US37321802P 2002-04-17 2002-04-17
US373218P 2002-04-17
US37486102P 2002-04-23 2002-04-23
US374861P 2002-04-23
US42079502P 2002-10-23 2002-10-23
US420795P 2002-10-23
US42119702P 2002-10-25 2002-10-25
US421197P 2002-10-25
US42175602P 2002-10-28 2002-10-28
US421756P 2002-10-28
US42241602P 2002-10-30 2002-10-30
US422416P 2002-10-30
US42750402P 2002-11-19 2002-11-19
US427504P 2002-11-19
US44340703P 2003-01-29 2003-01-29
US443407P 2003-01-29
US44614903P 2003-02-10 2003-02-10
US446149P 2003-02-10
US395017 2003-03-21
US10/395,017 US7337315B2 (en) 1995-10-02 2003-03-21 Efficient certificate revocation
PCT/US2003/010748 WO2003088166A2 (fr) 2002-04-08 2003-04-08 Commande d'acces physique

Publications (1)

Publication Number Publication Date
EP1493131A2 true EP1493131A2 (fr) 2005-01-05

Family

ID=29255792

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03726222A Ceased EP1493131A2 (fr) 2002-04-08 2003-04-08 Commande d'acces physique

Country Status (6)

Country Link
EP (1) EP1493131A2 (fr)
JP (1) JP2005525731A (fr)
CN (1) CN100473002C (fr)
AU (2) AU2003228468B2 (fr)
CA (1) CA2479869C (fr)
WO (1) WO2003088166A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11263711B2 (en) 2018-03-22 2022-03-01 Honeywell International Inc. Revocable certificates for guestroom access and guestroom controls by mobile devices

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7840994B2 (en) * 2003-09-19 2010-11-23 Ntt Docomo, Inc. Method and apparatus for efficient certificate revocation
CN101124765B (zh) * 2003-11-19 2013-08-07 科尔街有限公司 分布式代表路径发现与确认
US20050154879A1 (en) 2004-01-09 2005-07-14 David Engberg Batch OCSP and batch distributed OCSP
CN1922815B (zh) * 2004-01-09 2011-03-23 科尔街有限公司 用于ocsp和分布式ocsp的签名有效实时凭证
US8166532B2 (en) 2006-10-10 2012-04-24 Honeywell International Inc. Decentralized access control framework
CN101241610B (zh) * 2007-02-08 2011-03-23 黄金富 采用无线射频识别技术的行李查核系统和方法
PT2043055T (pt) 2007-09-28 2020-09-29 Iloq Oy Sistema de administração de fechaduras
US9369285B2 (en) * 2011-04-28 2016-06-14 Qualcomm Incorporated Social network based PKI authentication
CN104282068A (zh) * 2012-03-15 2015-01-14 江苏省电力公司常州供电公司 变电所防误锁具的许可装置
US9807161B2 (en) * 2013-09-16 2017-10-31 Axis Ab Distributed events in an access control system
US10540835B2 (en) * 2014-12-02 2020-01-21 Carrier Corporation Access control system with virtual card data
EP3208777A1 (fr) * 2016-02-16 2017-08-23 ILESO Engineering GmbH Panneau de commande, utilisation, et procédé pour la fabrication de celui-ci
US11328543B2 (en) 2016-09-02 2022-05-10 Assa Abloy Ab Key delegation for controlling access
US11263840B2 (en) 2017-02-24 2022-03-01 Assa Abloy Ab Delegation and auxiliary condition for physical access
US10505917B2 (en) 2017-06-05 2019-12-10 Amazon Technologies, Inc. Secure device-to-device process for granting access to a physical space
US11410177B1 (en) 2017-07-21 2022-08-09 Zonar Systems, Inc. System and method for facilitating investigation of expense card fraud
CN110086623B (zh) * 2019-03-13 2022-06-03 捷德(中国)科技有限公司 一种基于安全元件的固件防伪方法及安全元件
CN111127706B (zh) * 2019-11-28 2022-04-22 深圳指芯物联技术有限公司 智能锁控制方法、智能锁、云服务器及计算设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4453074A (en) * 1981-10-19 1984-06-05 American Express Company Protection system for intelligent cards
US4837822A (en) * 1986-04-08 1989-06-06 Schlage Lock Company Cryptographic based electronic lock system and method of operation

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2752097B2 (ja) * 1987-09-18 1998-05-18 エヌ・ティ・ティ・データ通信株式会社 入退室管理装置
NL9300566A (nl) * 1993-03-31 1994-10-17 Nedap Nv Toegangsverleningssysteem met decentrale autorisaties.
FR2722596A1 (fr) * 1994-07-13 1996-01-19 France Telecom Systeme de controle d'acces limites a des places horaires autorisees et renouvables au moyen d'un support de memorisation portable
EP0723251A3 (fr) * 1995-01-20 1998-12-30 Tandem Computers Incorporated Procédé et appareil pour un utilisateur et dispositif de sécurité d'authentification
DE19611632A1 (de) * 1996-03-25 1997-10-02 Deutsche Telekom Ag Off-Line-Datenstationen mit virtueller On-Line-Fähigkeit
US5742035A (en) * 1996-04-19 1998-04-21 Kohut; Michael L. Memory aiding device for credit card pin numbers
JP3907078B2 (ja) * 1996-12-26 2007-04-18 ホーチキ株式会社 入出退管理システム
US6038666A (en) * 1997-12-22 2000-03-14 Trw Inc. Remote identity verification technique using a personal identification device
FR2774833B1 (fr) 1998-02-09 2003-02-21 France Telecom Protocole de controle d'acces entre une cle et une serrure electroniques
JP3659791B2 (ja) * 1998-03-23 2005-06-15 インターナショナル・ビジネス・マシーンズ・コーポレーション 小時間鍵生成の方法及びシステム
EP1024239B1 (fr) * 1999-01-28 2005-03-23 International Business Machines Corporation Système de contrôle d'accès électronique et méthode
JP2001148037A (ja) * 1999-11-19 2001-05-29 Open Loop:Kk 電子チケット利用システム、電子チケット発券装置、電子チケット保持装置、電子チケット検札装置、電子チケット利用方法及び記録媒体
JP2001257668A (ja) * 2000-03-14 2001-09-21 Ntt Data Corp 認証システム、携帯端末、認証方法及び記録媒体

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4453074A (en) * 1981-10-19 1984-06-05 American Express Company Protection system for intelligent cards
US4837822A (en) * 1986-04-08 1989-06-06 Schlage Lock Company Cryptographic based electronic lock system and method of operation

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO03088166A3 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11263711B2 (en) 2018-03-22 2022-03-01 Honeywell International Inc. Revocable certificates for guestroom access and guestroom controls by mobile devices

Also Published As

Publication number Publication date
WO2003088166A2 (fr) 2003-10-23
CA2479869A1 (fr) 2003-10-23
JP2005525731A (ja) 2005-08-25
CN100473002C (zh) 2009-03-25
AU2010200020A1 (en) 2010-01-28
WO2003088166A8 (fr) 2004-08-05
CA2479869C (fr) 2013-07-09
AU2010200020B2 (en) 2012-12-13
CN1659597A (zh) 2005-08-24
AU2003228468B2 (en) 2009-10-01
AU2003228468A1 (en) 2003-10-27
WO2003088166A3 (fr) 2004-04-01

Similar Documents

Publication Publication Date Title
US9230375B2 (en) Physical access control
US7353396B2 (en) Physical access control
US8171524B2 (en) Physical access control
AU2010200020B2 (en) Physical access control
US8732457B2 (en) Scalable certificate validation and simplified PKI management
Micali Scalable certificate validation and simplified pki management
EP1325476B1 (fr) Systeme de verrouillage sans fil
CN100469000C (zh) 利用批量设备的身份凭证创建安全网络的系统和方法
US7822989B2 (en) Controlling access to an area
US20130061055A1 (en) Apparatus and Methods for Providing Scalable, Dynamic, Individualized Credential Services Using Mobile Telephones
US20040199469A1 (en) Biometric transaction system and method
US20050044402A1 (en) Logging access attempts to an area
US20050044376A1 (en) Disseminating additional data used for controlling access
GB2345232A (en) Remote administration of smart cards for secure access systems
CN110169031A (zh) 具有本地移动密钥分配的门禁控制系统
US20050021954A1 (en) Personal authentication device and system and method thereof
GB2427055A (en) Portable token device with privacy control
US9769164B2 (en) Universal validation module for access control systems
CN113781689A (zh) 一种基于区块链的门禁系统
CA2814254C (fr) Commande d'acces physique
EP1371171B1 (fr) Validation échelonnable de certificat et gestion simplifiée d'ICP
US20230267426A1 (en) Payment system, coin register, participant unit, transaction register, monitoring register and method for payment with electronic coin data sets
KR20040098066A (ko) 물리적 액세스 제어
Chinowsky XKMS Panel

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20041005

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

17Q First examination report despatched

Effective date: 20080612

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ASSA ABLOY AB

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20170207