KR20040098066A - Physical access control - Google Patents

Abstract

It works in conjunction with the standard certificate format and allows a certified certificate (CA) to prove the legitimacy status of each certificate C at any time interval (daily, hour, or second) beginning with the issue date of C, D1. A method and system for physical access through a digital certificate justification process has been described. The time granularity of C is specified within the certificate itself, unless it is the same as all certificates. For example, every certificate has a granularity of one day, with the Gaga certificate destroying 365 days after it is issued. At a given specific initialization input provided by the CA, the one-way hash function is used to calculate the value of the specified byte size contained in the digital certificate and to process other values used and justified in the process of justification.

Description

Physical access control {PHYSICAL ACCESS CONTROL}

In general, a digital certificate (C) consists of a digital signature from a certification authority (CA), which may be, for example, a serial number unique to a certificate (SN), a user's public key (PK), and a user's identifier (U). Safely combine some symbols, such as D ₁ (date of issue), D ₂ (expiration date), and additional items. Expressed symbolically, C = SIG _CA (SN, PK, U, D1, D2, ...).

It is widely recognized that digital certificates provide the best form of Internet and other access authentication. However, the digital certificate is also difficult to manage. A certificate may expire after one year (ie D ₂ -D ₂ = 1 year), but if the certificate holder leaves his company or takes on other tasks within the company, the certificate will Can be canceled. Thus, in each commerce made possible by a given digital certificate, it is necessary to properly verify the current validity of the certificate, and the verification needs to be kept as a safeguard against future claims.

Unfortunately, prior art techniques for validating issued certificates have not been very well evaluated. It will be difficult to securely validate future transactions and today's validity of digital certificates, and they will be too long to be expensive, especially in wireless environments. Verification of certificates is recognized as an important issue. If not resolved effectively, it will severely limit the growth or usefulness of the PKI.

Today, there are two main approaches to validating certificates: certificate revocation lists (CRLs) and online certificate status protocols (OCSPs).

CRL

CRLs are issued periodically. The CRL basically consists of a list of CA-signatures containing all the serial numbers of the revoked certificate. The digital certificate for which electronic commerce is provided is then compared with the most recent CRL. If a given certificate has not expired and is on the list, everyone knows from the CRL that the certificate is not valid and that the holder of the commerce transaction is no longer authorized. In addition, if a certificate does not appear in the CRL, the certificate is assumed to be valid (double negative).

CRLs didn't have much of an advantage because of the risk that they could be difficult to manage (the risks were only reduced by recent CRL-splitting technology). Commissioned a study on the construction and cost of a public key infrastructure (PKI) (see the 1994 PKI Final Report by MITER, International Standards Technology Association). The study concluded that CRLs constitute the largest item on the federal PKI cost list to date.

OCSP

In OCSP, the CA answers the inquiry about C by returning the digital signature of the validity of certificate C at the current time. OCSP is a problem in the following areas.

Bandwidth. Each validation generated by the OCSP has a significant length. If a signature scheme based on RSA or other factors is used, this verification actually requires the CA signature at least 2,048 bits.

Calculation. Digital signatures are computationally complex operations. In large applications such as maximum traffic, the OCSP needs to compute millions of signatures in a short time, which is very expensive to implement.

Communication (in case of concentration). Assume that a single verification server implements the OCSP in a centralized manner. Eventually, all authentication-validity lookups are routed to the single server, and the server becomes an important “network bottleneck,” causing significant congestion and delay. If a huge number of users query the single server, an unpleasant "denial of service" will continue.

Security (if distributed). In general, network congestion can be mitigated by balancing the load of a single server across several (eg, 100) servers strategically located throughout the world. However, in the case of the OCSP, load balancing causes a worse problem. In order to sign a response to a certificate inquiry, each of the 100 servers must have its own secret signing key. Thus, solving any of the 100 servers would solve the entire system. A secure vault can protect these distributed servers, but it is expensive.

The present invention relates to the field of digital certificates, and more particularly to the field of digital certificate verification that controls physical access.

1 illustrates, in relation to each issued but not yet expired certificate C ₁ , ... C _k , how the CA sends each Certificate Revocation Status Information (CRSi) to the directory, according to one embodiment of the invention. It is a schematic diagram of a.

2 is a schematic diagram of a commerce sequence in a typical OCSP environment.

3 is a schematic diagram of a major "network bottleneck" in a server causing significant congestion and delay.

4 is a schematic diagram showing how the OCSP has difficulty in servicing a certificate validity request from different security domains.

5 is a schematic diagram illustrating a service for requesting a certificate validity from different security domains according to an embodiment of the present invention.

6 is a schematic diagram of an RTC system according to one embodiment of the present invention.

7 is a schematic diagram showing how RTC-over-OCSP will be deployed in a cross-CA environment according to one embodiment of the invention.

8 is a schematic diagram showing operation of the system according to an embodiment of the present invention.

9 is a schematic diagram of a stolen computer timeline.

A system and method for controlling physical access through a digital certificate verification process is described, wherein the verification process is handled in a standard certificate format and the verification authority (CA) starts from the issue date (D ₁ ) of the certificate (C). At each time period (eg daily, every hour, every minute), the validity status of each certificate (C) is verified. If the time granularity of the certificate is not the same for all certificates, the time granularity can be specified within the certificate itself. For example, all certificates may have a granularity of one day when each certificate expires 365 days after issuance. When some initial inputs are given by the CA, a one-way hash function is used to calculate the values of a particular byte size contained on the digital certificate and to calculate other values used in the verification process while maintaining security.

Physical access control includes reviewing credentials in real time, wherein the real time certificate includes a fixed first portion and a second portion that is modified periodically, wherein the second portion indicates that the real time certificate is present. Verify, validate the real-time certificate by performing an operation on the second part and comparing the result with the first part, and permit physical access only when the real-time certificate is proven to be valid. The first portion may be digitally signed by an authority. The authority authority may provide a second part or the second part may be provided by an entity except an authority authority. The real time certificate may be provided on a smart card. The user may obtain a second portion of the real time certificate at the first location. The user may be allowed access to a second location that is different from and independent of the first location. At least one portion of the real time certificate may represent a unidirectional hash applied multiple times to a portion of the second portion of the real time certificate. The number of times may correspond to the amount of time that has elapsed since the first portion of the real-time certificate was issued. Control of physical access involves controlling access through the door.

It is very important that only authorized individuals have access to security areas (eg, airports, military installations, office buildings, etc.). Security zones can be defined by physical doors (especially doors that humans can pass through, doors of containers, safes, or vehicles, etc.) and walls, or by other means. For example, the security zone may be configured as a zone entrance that allows the detector to generate an intrusion signal (and generate a signal or sound an alarm if authentication is not made). At airports, entering the gate area through exit passageways can often trigger these signals, even if no doors or walls have been violated. Through this application, the door can be interpreted as including all other ways of access-control devices that can be implemented using conventional or modern keys. In particular, the key configuration is used to start the engine (the invention thus becomes a new way to allow only authorized users to start planes, trucks or access other valuables).

While an overview of the present invention has been described, in the future, in order to be specific and inconsistent, a "door" is referred to as a means of controlling access or setting boundaries, and "entering" accesses an area to be protected. Reference is made to the means.

Smart doors provide this access control. At the simplest level, the smart door is equipped with a keypad through which the user enters his or her PIN or password. The keypad has a secondary memory or basic processor in which a list of valid PINs / passwords is stored, so that it can be checked whether a currently entered PIN / password is in the list. If it is listed above, the door is opened, otherwise the door remains locked. This basic access control structure provides minimal security. In particular, an employee who has left the office may no longer pass through the door. But if the employee remembers his PIN, he will open these basic smart doors without any problems. Therefore, it will be necessary to deprogram PINs for employees who have left. However, this procedure is very cumbersome and expensive. The airport facility has hundreds of doors, so it is impractical to pass a specific team of workers and deprogram all doors whenever an employee leaves. More security is required without incurring excessive costs or inconveniences.

Of course, rather than relying on conventional keys or simple keypads, more modern smart doors can operate using a contactless device or a card such as smartcards and mag-strip cards. However, this enhanced set of tools does not, by itself, guarantee safety, convenience, and the low cost of an access-control system. These tools depend critically on how these tools are used in the overall security architecture.

Ideally, the smart door should identify the person's position and verify the authentication for that person to enter. Of the two tasks, the former is probably easier. The identification process can be performed in various ways. Especially

1. Using a PIN and password that can be entered from the keypad attached to the door,

2. Using biometrics that can be entered by the user through special readers attached to the door,

3. Using the traditional signature provided by the user through a special pad attached to the door,

4. Using a smart or contactless card (eg sending a PIN to the door via a special reader / receiver),

5. Identification can be made using a digital certificate stored, for example, in a smart card, contactless card, or wireless device and can be transmitted to the door via a card reader or other receiver.

Digital certificates are particularly useful in the system of the present invention, and therefore, some methods of using the digital certificate with smart statements will be described in more detail. Without specifically breaking out of consistency, we'll call a device owned by the person who wants access to be a "card." The card can store a digital certificate and a corresponding secret key. In accordance with appropriate instructions from the cardholder, for example, punching a secret code on the keypad, the card will transmit the digital certificate to the door structure and execute the identification protocol using the corresponding secret key (e.g., random challenge ( challenge). Preferably, the digital certificate and especially the corresponding secret key should be protected in the secure hardware portion of the card / device.

In some cases, people want to have anonymous and secure access control without exposing their identity. In this case, identity verification does not need to be performed, but the authentication process still needs to be performed. In most cases, however, some form of identification is mandatory. Thus identification can be made (eg, by one of the five methods described above) or can be assumed to have already been made. Two ways: how can the authentication process be performed? Even if the door clearly handles a person named John Dow, how can the door confirm that the person named John Doe is now authenticated for entry? Traditionally, smart statements query a database of currently authenticated users (eg, on a given date) to verify that an individual actually requires access. In this case, however, the smart statement needs to be connected to a remote database. In addition, this should be a secure network connection, not a regular network connection. In practice, you must use cryptographically protected communications to prevent anyone with impure intentions from using the database on the door, and also prevent intruders from attempting to cut the wires that connect to the door and the database. If the connection is lost, the door must make a bad choice: (a) always open or (b) always closed. However, a secure network connection does not easily reduce the cost of the electromechanical element of the door lock. The upper line element costs about $ 1,000 but the secure network connection will cost about $ 4,000 (especially if the wires need to be connected over long distances, such as at an airport). Moreover, after spending about $ 4,000, will it cost just this much for secure network connections in public places such as airports? Note that wireless connection of smart doors to remote databases is not a viable alternative. Firstly, long range radio transmitters and receivers are very expensive. Second, in some installations wireless bandwidth may be very limited (to avoid interference with other tools) or may be prohibited for such use. Third, the wireless communication can be easily blocked and the door can be disconnected from the database (thus making the two bad choices only). Fourth, if the door belongs to a container in the Atlantic, it will probably not be able to communicate wirelessly with any database on the coast.

Accordingly, one aspect of the present invention is to provide a low-cost, convenient, secure and disconnected smart card that is not connected to any database or authority (either wired or wireless).

Digital signatures and certificates

In a preferred embodiment, the invention relies on digital signatures and possibly 20 byte descriptions. A digital signature (eg RSA) is used to verify that a given message M originates from a given user U. To this end, the user U generates a pair of matching keys, namely a verification key PK and a signature key SK. The digital signature is generated via SK and verified via a matching key (PK). The user U must keep his SK secret (so that only the user can sign for him). In digital signatures, the PK does not reveal the matching key SK, that is, knowing the PK does not provide an intruder with the practical advantage of calculating SK. Therefore, the user U must make his / her PK as publicly as possible (so that everyone can verify U's signature). For this reason, PKs are often referred to as public keys. We will mark U's digital signature for message M as SIG _U (M). The digital signature is given to include a private-key signature, in which case the signer and verifier will share a common secret key.

Alphanumeric strings, called certificates, enable digital signatures by verifying that a given key (PK) is the public key of the user (U). The verification authority (CA) creates and issues a certificate to the user when the user's identity is verified. The certificate thus informs everyone that the CA has verified the identity of the certificate holder and possibly other features. (For example, if a company issues a certificate as a CA to its employees, the certificate allows the certificate holder to know the extent to which the certificate holder is authorized to associate with his employer.) The certificate expires after a certain time, Generally, a public CA expires after one year. In essence, the digital certificate (C) consists of a digital signature that securely combines several symbols. SN (serial number unique to the certificate), PK (user's public key), U (user's name), D ₁ (issue date), D ₂ (expiration date), and additional data. Expressed symbolically, C = SIG _CA (SN, PK, U, D1, D2, ...).

The certificate may also include the case where the PK becomes an encryption key. In this case, the user can prove his or her identity by sending the certificate C to the verifier V, the verifier V encrypts a random challenge (string) R having a key PK and After that, the user U is asked to return decryption. If the user responds with R, then V confirms that U is processing, since only user U needs to know the decryption key match (PK).

The preferred embodiment of the present invention provides a much better solution to access control. In particular, if the card comprises a digital certificate according to the invention, authentication can be made much cheaper. Instead of querying a central database for the validity of all digital certificates, the statement would need to obtain 20 byte validation according to the invention.

Example 1:

Let A be the authority (i.e. entity) that controls the smart doors, and U be the user who is allowed access to the given statement for a given time.

Each user carries a card (in the general sense described above).

Each smart door has an associated card reader (which can communicate with or receive information from the user's card) and, in fact, has an electromechanical lock for physical (non-virtual) doors. Preferably each statement also has a unique identifier (and each statement knows the identifier). The door has a card reader, a clock that cannot be easily changed, and a computing device with the authority A's public key (PKA), and can verify the signature of A.

The authority determines which statements a user can pass in a given time interval (e.g., assuming that each time interval is one day when inconsistent). For this purpose, the authority A can use his personal database DB1, storing all the authority as to who can pass through which door at any given time. A protects this database or the attacker can change the privileges stored in the database at his convenience. However, A computes a public database (PDB) from the DB as shown below. For each user U who is authorized to pass through door D on date d, A computes digital signature SUDd. For example, A computes SUDd = SIG _A (U, D, d). It should be noted that only A can compute this digital signature, while everything with A's public key (PKA) can verify the signature. Such a signature cannot be forged by anyone who does not know A's secret key (SKA), and also does not invalidate the signature in any way (e.g., converting U's authority to that of an unauthenticated user U). Cannot be modified). Thus A can compute these and send these signatures to the storage PR. A repository is a place that a user can access. For example, the server may be located at an employee entrance in a large facility (eg, an employee entrance at an airport). Since A's signatures cannot be forged, the connection between A and PR does not require security. A keeps moving his signature to the PR within a reasonable time.

When an employee U arrives at date d to reach a facility (eg, through the entry point where the PR is located), the employee can link his card to the PR (eg, the employee is connected to the PR). Or insert your card into a card reader / writer that communicates with the PR). In doing so, he obtains SIGUDd from his card, and the digital signature indicates that the employee is authorized to pass through door D on that date. It is necessary for the inlet point to be connected to A and this connection need not be secure. In fact, D does not have to represent a single statement. For example, D can refer to a set of doors (eg, baggage handling doors), and A's signature indicates that user U can pass through each door denoted by D. Alternatively, the plurality of doors D1, ..., Dn may be displayed one by one, and the fact that the user U can pass each of the plurality of doors that day is indicated by one or more A's signatures. Can be. For example, SIGUD1d ... SIGUDnd. In either case, all these signatures are delivered to the user's card.

It is assumed that user U walks through the facility during the date d and reaches the door D where he is authorized. Thus his card now stores SIGUDd. The user U then inserts his card C into the card reader in the door D. The processor associated with the statement then verifies that the SIGUDd is actually valid using A's public key. The processor then uses its clock to verify that the current date is actually d. If both items are verified to be true, door D is opened. It should be noted that the statement can verify the cardholder by actually performing identification in a variety of ways. In particular, the user also needs to enter his PIN on the keypad associated with the door. (Unlike the previous, the dismissed employee must be aware that he cannot enter door D even if he remembers his PIN. In this example, the door requires the PIN and the correct signature for the current date. However, after the user is dismissed, the user will not be able to grant this signature to the statement, since A does not create a signature SIGUDd for a later date d. Therefore, he can't let Door D open on any date after he is fired.) Alternatively, only when user U enters the correct PIN on the keypad at the back of card C. The card can deliver the SIGUDd to the inquiry card reader, and the storage PR will download the SIGUDd on the card only after the card C proves that it is actually the user's card. Alternatively, the user U can provide an identifier for the card C belonging to U, and when inserted into the card reader the card proves that it is indeed the user's card, for example by means of cryptographic protocols. do. Alternatively, U's card has a certificate for U, so that after the appropriate PIN is entered, the card verifies U's identity by decrypting the random challenge of the query. In this case, SIGUDd preferably indicates that the user has the right to pass through the door D by indicating that the U's certificate has authority to the U. For example, SIGUDd = SIGuDd, where u is an identifier for U's certificate, such as the serial number (and issuer) of U's certificate.

In all these ways, it should be noted that the statement is "disconnected" from A. The statement identifies U if possible and checks only if the user has access to A's public key and internal clock through an internal operation. The system is thus very safe and very economical.

Verification for such validity or authentication can be provided in many different ways. The following is an example of how this verification can be done.

Example 2:

The cardholder can obtain the validation of the validity at the appropriate time. For example, in a work environment, each individual can obtain current validation when reporting on work. In many workplaces (especially in security-sensitive locations such as airports), employees sign and record their work reports. This "sign in " involves obtaining a 20 byte valid SIGUDd and storing it on the card. The card can obtain the value through a wired or wireless connection.

Example 3:

The card may obtain validation via, for example, a wireless network such as a paper network. At the appropriate time, if the card is authorized to access, a 20 byte value is sent to the card. It should be noted that the bandwidth requirement is so small that the authentication value is shorter than a normal message sent by the paper network. At the appropriate time, if the card is granted access, SIGUDd is sent to the network.

Example 4:

The door can similarly obtain the validation via a wired or wireless network.

Example 5:

The door can obtain validation for the card when needed when the card interacts with the door.

None of the aforementioned methods require a secure connection between the door and the central server. This means that the validation is self-authenticating so that even if the statement receives validation from an insecure source and / or from an insecure connection, the statement can still verify its accuracy. Since these methods do not require any connection to the door, a much better means for access control is provided in large and remote areas (areas with multiple doors and moving areas such as airplanes or truck doors).

One skilled in the art can understand that the 20 byte validation is a special, limited way of digital signature, while the validation provides inherent advantages such as simplicity and efficiency, so that more advantages can be derived from applying the invention. Can be. Elements of the preferred embodiment of the present invention can (1) verify digital signals, and if successful verification, a door structure combined with the means for opening the door, and (2) entry through the door for a given period of time. An authority element that provides a digital signal whenever possible, and (3) a card or other wired / wireless device element capable of receiving and providing a digital signature.

Authentication for access can be performed by any of the following sequence of steps.

Sequence 1 :

(1) the authority element causes the card to receive the authentication signature,

(2) the card receives and stores the authentication signature,

(3) The card provides a door with the signature for authentication, wherein the door is opened only if the signature is verified and the authentication signature is valid.

Sequence 2 :

(1) The card is provided to a door that requires permission for access,

(2) the statement requires the signature for authentication,

(3) the authority element causes the statement to receive the authentication signature,

(4) The door opens only if the verification signature is valid and the verification signature is valid.

Sequence 3 :

(1) the card requires the signature for authentication from the authority element,

(2) the authority element sends the authentication signature to the card,

(3) the card receives and stores the signature for authentication,

(4) The card provides the door with the signature for authentication, wherein the door is opened only if the signature is verified and the certificate for authentication is valid.

Sequence 4 :

(1) the door receives in advance (when requested by the typeface or not) the authentication signatures encountered from the authority element for a number of cards;

(2) The card is provided at the door requesting permission for access,

(3) The door verifies the authenticating signature of the card and the door is opened only if the signature is valid.

These sequences are only some of the many examples. In addition, these sequences can be combined. For example, the statement may receive an information / permission part (eg 20 bytes) while the card may receive another part (eg digital certificate). The sequences may also be separated if appropriate: the card may receive the information / authorization part (eg digital certificate) first and later other parts (eg the 20 byte value every hour).

Moreover, the authentication digital signature can be combined with a cardholder's long term certificate. For example, the card may include a long term certificate that is valid every year, and the authority element may issue a daily signature to verify that the certificate is still valid at the current date.

The authority element can automatically generate a permission without any request. For example, every night the authority element may generate a signature for authentication of employees to be authorized the next day. This approach allows the authorization element to be non-interactive and thus securely built.

In addition, the authority element may use a separate but insecure device to distribute the authorizing signature to the card and / or door. This will allow the permission element to focus on only one task, namely permission creation. The authorization creation will obviate the need for cumbersome direct connections between the secure authority element and the door and card (which may be less secure). In particular, the distribution of authority can be done as follows: (1) the authority element creates the authority, and (2) the authority element transmits the authority to the distribution database through an insecure connection if possible. These databases can be in multiple locations, but do not need to be secure. For example, in a company with five employee entrances, each entrance might have one distributed database. (3) The distribution database transmits authority to the card and / or door upon request ("pull") or automatically ("push").

The property that enables the method is that the authority itself is stored and can only be generated by the authority element. So once created, the rights can be distributed without any security risk through the devices and devices, possibly insecure. This obviates the need for any other device to interact with the authority element, thus making it a cheaper solution than any connection requiring security.

Indeed, no connection between the elements in this system need be secure. (Only the authority element itself must be secure, so no inappropriate authority is created.) Thus, a fault-tolerant, distributed access authority structure can be built much easier. Moreover, as mentioned above, this structure can be constructed without any connection required for the door.

The access control system of the present invention may be combined with the borrowing CA of section 3. For example, some agencies (such as office buildings, parking authorities, laundry authorities, or multiple companies sharing occupancy in a building) can use the same certificate, but the certificate holder has access to various protected areas. Individual control over

Example 6:

The system can operate as follows. User U (or user's card) has a certificate (CERT), which includes a field (eg, D365) that validates the validity of each statement (D). The permission for user U to pass through door D at date j can be verified by emitting the stored 20 byte value X365-j. The statement D can confirm the permission by hashing the value j times and by checking that the result matches the validity field D365 of the CERT. If A needs to handle multiple statements (eg 1000 statements), the CERT will contain 1000 different validity fields, each of which corresponds to a different statement, and each statement (Dj) is a jth validity field. Check the operation for. In this case, although the user is individually authorized to pass through each door, each user only has at most 1000 validations on a given date. Therefore, at most, only 20K bytes need to be loaded into the user card on a given date.

The card here is a conventional card but can be a contactless card, a card reader can be a receiver, and the card need not be inserted into the reader, but needs to be transferred to the reader. It should be noted that the interaction of such a wireless card reader is quite local and differs from card-authority / database if A or the database is far away.

Moreover, the authentication digital signature can be coupled to the cardholder's long term certificate. For example, the card may include a long-term certificate that is valid every year, and the authority element may issue a daily signature that verifies that the certificate is still valid for the current date.

The authority element can automatically generate authority without any request. For example, every night the authority element may generate a signature for authentication of employees to be authorized the next day. This approach allows the authorization element to be non-interactive and thus securely built.

Indeed, no connection between the elements in this system need be secure. (Only the authority element itself must be secure, so no inappropriate authority is created.) Thus, a fault-tolerant, distributed access authority structure can be built much easier. Moreover, as mentioned above, this structure can be constructed without any connection required for the door.

The access control system of the present invention can be combined with the borrowing CA described above. For example, some agencies (such as office buildings, parking authorities, laundry authorities, or multiple companies sharing occupancy in a building) can use the same certificate, but the certificate holder has access to various protected areas. Individual control over

Verification to log access to unconnected doors

Smart cards, which are connectionless but very secure and low cost, are preferentially connected to smart doors, while smart doors provide the ability to record access through a given door. For example, it may be important to know who passed a given door on a given date. The access statement can easily tell who passed by sending the appropriate access information to a remote database or authority. But disconnected statements may not. Access information can be collected by sending the appropriate person to collect this information from door to door, which is not always convenient. However, the following system offers a very practical alternative.

When user U passes through statement D at time t, the statement generates the appropriate string LOGUDt and can store it locally (at least temporarily). To ensure that this information reaches the appropriate database, the door will use the card used to enter through the door. For example, door D may log (or cause LOGUDt to be recorded) on the card of another user U '(including U if possible). Each time U 'connects to a PR (e.g., the next day) or some other wired device, the PR or the device sends LOGUDt to the appropriate database. In this way, the appropriate database will receive the LOGUDt and then store it in a permanent and easily inspectable way. Where possible, the database will receive duplicate copies of LOGUDt, but it is easy to eliminate unwanted duplication and keep only pure copies.

The preferred LOGUDt is a LOGUDt containing the user's own digital signature. In this way, the user U cannot easily deny that he has passed a given statement at a given time and cannot claim that the statement access information is false. In fact, only you have a secret signing key that generates a LOGUDt. For example, LOGUDt consists of SIG _U (D, t), which indicates that it passed door D at time t. This is very easy to implement if the user's card has a secret signature key (SKU) that matches the public key (PKU). Preferably the card also has a digital certificate for the PKU, so LOGUD can include SIG _U (D, t) and a user certificate. Also preferably, the user card can generate SIG _U (D, t) according to a given time t on its clock, and the statement allows the user to make this successful access verification (SIG _U (D, t)). User U can only be imported (if possible, in addition to other authorization verifications as described above), and the time authenticated by U is measured by the door clock close enough to t '). Still, the user can claim that he passed through door (D) at time (t), but that door was elsewhere, so SIG _U (D, t) is the second floor of the third floor of a given building, You can't prove that you passed the door. To prevent this claim, or to protect the user against such lies, the user card (device) may include a GPS structure, and SIG _U (D, t) may be the local position (lp) measured by the card. ) May actually be included. In any case, the user validates access to the door and SIG _U (D, t, ps), which accepts the user only when the time is accurate and local. Rather than calculating the ps in the card / device, the user can use one or more elements that he trusts and can calculate the user's location using the information the elements receive from the user (and from the user's own location). have.

Basic system

As shown in Figure 1, the CA sends each certificate revocation status information (CRSi) to one directory for each certificate C ₁ ... Ck that has been issued but has not yet expired. The directory sends a CRSi to the user requesting a query regarding the certificate serial number "i" of the CA.

A system and method for controlling physical access through a digital certificate validation process is described, wherein the process is handled in a standard certificate format (e.g., X.509v3) and the CA is at some time period (e.g., daily). , Hourly, minutely) to verify the validity status of each certificate (C). If the time granularity of certificate C is not the same for all certificates, the time granularity can be specified within the certificate itself. Specifically, we assume 1 day granularity for all certificates, and assume that each certificate expires 365 days after issuance.

Generate certificate (C)

In addition to traditional symbols such as serial number (SN), public key (PK), user name (U), issue date (D ₁ ), expiration date (D ₂ ) (= D ₁ +365), certificate (C) Also contains only 20 byte values. In particular, before issuing certificate (C), the CA randomly selects two different 20-byte values (Y ₀ and X ₀ ), and from them uses a one-way hash function (H) with the following properties: The corresponding 20 byte values (Y ₁ and X ₃₆₅ ) are calculated. H is at least 10,000 times faster than a digital signature H produces a 20 byte output no matter how long its input is. And H is difficult to reverse. For a given Y, it is practically impossible to find X where H (X) = Y. (See Safe Hash Standards), FIPS PUB 180 revised on July 11, 1994 (Federal Registration, Vol. 59, No. 131, pp.35211-34460), revised August 5, 1994 (Federated Registration, Vol 59, No. 150, pp. 39937-40204). The value (Y ₁ ) is calculated as Y ₁ = H (Y ₀ ) by hashing Y _O once, and X ₃₆₅ is hashed by X ₀ 365 times, X ₁ = H (X ₀ ), X ₂ = H (X ₁ ), .., X ₃₆₅ = H (X ₃₆₄ ). Since H always produces a 20 byte output, Y ₁ , X ₃₆₅ and all intermediate values X _j are 20 bytes long. The values Y ₀ , X ₀ , X ₁ , ..., X ₃₆₄ are kept secret, while Y ₁ and X ₃₆₅ are included in the certificate. C = SIG _CA (SN, PK, U, D ₁ , D ₂ , ..., Y ₁ , X ₃₆₅ ). We will call Y ₁ as the cancellation target and X ₃₆₅ as the validation target.

Revoke and Validate Unexpired Certificate (C)

On the i th date after issuing C, the CA computes and distributes a 20 byte verification of the status for C as follows. If C is canceled, as verification of C's cancellation, CA distributes Y ₀ , which is the H-reciprocal of the cancellation target Y ₁ . In addition, as a verification of the validity of C on that date, the CA distributes X _365-i , which is the i-H-reciprocal of the validity X ₃₆₅ (for example, verifying that C is valid 100 days after publication) consists of _265.) the CA may distribute Y ₀ and X _365-i by expressing the value in providing a value that responds to the query or the World wide web.

Verification of Unexpired Certificate (C) Status

At some date, C's cancellation verification (Y ₀ ) can be verified by hashing Y ₀ once and verifying that the result is the same as C's cancellation target (Y ₁ ) (ie, the verifier can verify that Y _{0 is} actually Y). checks whether the inverse of the ₁ H-.) Y ₁ is there is a clear target for C, because the Y ₁ is authenticated in the C. On the i th date after the issuance of C, the validation of C is verified by hashing the value (X _365-i ) i times and verifying that the result is equal to the validity target of C (X ₃₆₅ ). (I.e., the verifier checks whether X _365-i is actually the i-th H-inverse of X _365. ) The verifier knows not only the current date (D) but also the issue date of C (D ₁ ) (since D ₁ Because it is authenticated in C), it immediately calculates i = DD ₁ .

security

Verification of cancellation cannot be forged.

The revocation verification of certificate C consists of the H-reciprocal of C's revocation subject Y ₁ . Since H is basically incapable of reversing, once the verifier verifies that the given 20 byte value (Y ₀ ) is actually a cancel verification of C, the verifier knows that Y _{0 has} been distributed by the CA. In fact, only CA can calculate the H-inverse of Y ₁ , not because CA can take H inversely better than others, but because CA starts with Y ₀ and hashes Y ₁ . Because it was calculated. As long as C is valid, the CA can never distribute C's revocation verification, so the attacker cannot fool the revocation verification.

Validation cannot be forged

On date i, validation of certificate C consists of the i-th H-reciprocal of validity object of C (X ₃₆₅ ). H cannot be reversed by default, so once the verifier verifies that a given 20-byte value (X _365-i ) is actually validating C at that date, the verifier then deploys X _365-i I know that. In fact, only the CA can calculate the i-th H-reciprocal of X ₃₆₅ , not because it allows CA to take the inverse of H better than elsewhere, but because it starts at X ₀ and starts 365 times. This is because X ₃₆₅ is computed by hashing. If C is canceled on i + 1 date, the CA has already deployed the values (X365-1, ..., X _365-i ) at the preceding i date but the value (X _365-i-1 ) (or j < Any other value X _j ) which is 365-i will never be released in the future. As a result, in order to forge the validation of C on an i + 1 date, the attacker would have to compute his i + 1 th H-reciprocal with respect to X ₃₆₅ (i.e., the H-reciprocal of X _365-i ). It is very difficult. To do so, the attacker would need to be able to have the inverse of H on input X _365-i . For example, if an attacker could compute the validation of C on an i + 2 date, hashing it once would easily yield the H-inverse of X _365-i-1 , or X _365-i .

efficiency

Certificate C has only two additional 20 byte values (Y ₁ and X ₃₆₅ ).

This is a negligible sacrifice. Recall that C already consists of a CA signature (at least 2048 bits long) of data that contains a public key (PK) (at least 1024 bits long). And C may include many other data besides SN, PK, U, D ₁ and D ₂ .

Generating Y ₁ and X ₃₆₅ requires a total of 366 hashes.

This is a negligible sacrifice. Recall that to issue a certificate, you need to calculate the signature.

Revocation validation and validation are 20 bytes long.

Twenty byte verifications are so trivial to transmit and store that the 20 byte technique makes it very ideal for wireless applications (as is the storage capacity of many mobile phones and other wireless devices, since the bandwidth here is still limited).

The verification according to an embodiment of the present invention is very short because it derives security from basic cryptographic elements, such as one-way functions, which shows an exponential amount of security. (Very different, digital signature schemes have complex security requirements. Typical number-theoretic implementations provide much longer sub-exponential functional amounts of security, requiring much longer keys.)

Regardless of the total number of certificates or billions of certificates, the verifications are 20 bytes long. In fact, there are 2 ¹⁶⁰ possible 20 byte long strings, and the possibility that two certificates can have common revocation verification or validation is negligible.

Verifications of 20 bytes in length are not incremented by encryption or authentication. The 20 byte verifications are public and do not need to be encrypted. Similarly, 20 byte verifications are self-authenticating: by hashing the verifications to an appropriate number of times, the verifications create a validity or revocation object in the certificate. If forged or altered the verification will not be generated and therefore does not need to be signed or authenticated in any way.

Finally, a 20 byte long validation (X _365-i ) on date i need not additionally include a value (i): in some sense the validation already contains its own timestamp. . Indeed, as explained above, i is the difference between the current date and the certificate issue date, and if hashing X _365-i i times creates a validity target for certificate (C), then X _365-i is date i Prove that C is a validation of C.

The 20 byte verifications are calculated immediately .

Revocation verification (Y ₀ ) or validation (X _365-i ) is retrieved from memory. (Alternatively, if, for example, by only 364 hashing, X _{0 is} stored during certificate issuance, each X _365-i can be recalculated in operation on date i. Surprisingly more efficient methods are discussed in the next section.)

Wireless environment

Embodiments of the present invention are ideal for wireless implementations. Its implementation range is so large that it can easily accommodate billions of certificates. The required bandwidth is negligible and basically requires 30 bits of serial number for the inquiry and 20 bytes for the response. The calculations that require bandwidth are negligible because the certificate-status lookup is answered by a table lookup and is immediately validated. Of course, large range, minimal bandwidth and minor calculations make the invention available in wireless environments.

However, there is another use case that provides additional advantages in wireless applications. That is, each morning the wireless user receives a 20-byte validation of his certificate for the remaining days. (The 20 byte value can be obtained at the user's request or automatically entered into the user's cellular device, for example, by an SMS message or other control message.) Due to the minor length, this verification is most likely for most cellular phones or PDAs. Can be easily stored in. Then whenever the user wants to trade on that day, the user simply needs to send his certificate with a 20-byte validation of the day. Since the validation is universally verifiable, the verifier of the certificate does not need to call any CA or responder. The verifier can operate completely offline. In a cellular environment where no calls cost money or time, this offline capability is very important.

Compare with OCSP

The invention and OCSP are both on demand systems. That is, the user sends an inquiry about the validity of the current date of the certificate and receives back a non-forgeable and generally verifiable verification as a response. However, there are differences in time accuracy, bandwidth, CA efficiency, security and operating costs.

Time accuracy

In principle, an OCSP response may specify time with no bounded accuracy, while a response according to a preferred embodiment of the present invention materializes time with a predetermined accuracy (1 day, 1 hour, 1 minute, etc.). . In applications with small values, the effectiveness of one day is sufficiently acceptable. In most financial applications, the digital signature trust takes into account four hours of accuracy. (This is probably less surprising than it seems. In most financial transactions, orders received in the morning are executed in the afternoon and orders received in the afternoon are executed the next day. In any case, time has infinitely many digits. It is not specified by a real number In an on-demand validation system, time accuracy less than one minute is almost insignificant because the clocks of the querying and responding sides cannot be synchronized. In 15 seconds the time accuracy is virtually real time.

To address this high degree of accuracy, the preferred embodiment of the present invention computes a hash chain that is nearly 1M long (i.e., it is necessary to calculate the field of validity of X _1M ), since at most 527,040 minutes per year. to be. If such long chains can be handled efficiently, the preferred embodiment of the invention will be in real time. Computing 1M hashing is not a problem in certificate issuance, because 1M hashing can be executed in less than one second using a very appropriate platform. And a certificate is usually issued only once a year, not under tremendous time pressure. Similarly, one second in calculation is not a problem for validators who validate certificates (eg, merchants that rely on certificates), given that merchants spend a lot of time in the field focusing on individual commerce. This is not a problem. However, calculating 1M hashing per certificate-status request affects the performance of the server generating validation because it handles a lot of commerce at once. Fortunately, these servers do not need to compute all these hashes online, starting from X ₀ , but have a complete hash-chain of all certificates in storage by table lookup. Nevertheless, storing a hash chain of 1M length can be problematic in applications with a huge number of certificates. But fortunately, as will be mentioned later, even a normal server can re-calculate a 1M long hash chain with incredible efficiency using better algorithms.

Bandwidth: The preferred embodiment of the present invention has certain bandwidth advantages on OCSP. The preferred embodiment uses a 20 byte response, but the OCSP uses 256 bytes.

CA efficiency: The validity lookup is answered by a complex digital signature in OCSP by a trivial table lookup in the present invention, as long as the CA stores the entire X-chain for each certificate.

For a group of one million certificates, the CA can afford to store the entire X-chain for each certificate if the time accuracy is one day or one hour. (In the first case, the CA would have to store 365 20 byte values, ie 7.3K bytes per certificate and thus 7.3B bytes for the entire certificate. In the second case, 175.2B bytes total.) If the time accuracy is 15 In seconds, each hash chain would consist of 20 byte values of 1M in length, and for the entire system the total storage would require approximately 10.5 terabytes of large storage.

To drastically reduce this storage requirement, the CA can only store one 20 byte value (ie X ₀ ) for each certificate, and re-calculate X _i from X ₀ by 1M hashing. Alternatively, Jacobsson [5] found a surprising time / storage trade-off. That is, the CA will recalculate all n X _i values sequentially by storing the log (n) hash value and executing the log (n) hash value each time. If n is 1M, this means store 20 hash values per certificate and execute 20 hashes each time the certificate needs validation. Other non-trivial tradeoffs are possible. In particular, for 1M chains, Reyzin [R] stores only three hashes and executes 100 hashes each time, allowing CA to calculate all X _i values (from i = 1M down to 1). Showed that there is.

In summary, even in real-time applications (i.e. using 15 seconds of time accuracy), the preferred embodiment of the invention can replace a complex digital signature process with a trivial 100 hash operation by storing 60 bytes per certificate. .

Security and Processing Costs: The last two differences are described taking into account the OCSP and the implementation manner of the preferred embodiment of the present invention.

Centralized implementation example: security analysis

If the process of validating a certificate relies on the confidentiality of a given key, a secure vault must protect the key, thereby ensuring the security of the entire system. By this invention or intensive implementation of the OCSP, we will have one vault respond to all validity inquiries. If the number of certificates used is small (e.g. around 100K), then a centralized implementation is preferred, so that even if almost all of the certificates are used in small time periods, the vault can handle the volume of generated queries, Generates an inquiry about the validity that occurs at the same time. In this embodiment, the preferred embodiment is superior to OCSP in the following respects.

Doomsday Protection: In conventional OCSP, if an attacker (in spite of bolts and security devices) breaks through the vault and compromises the secret signing key, he can revoke an already revoked certificate and revoke a still valid certificate. (Similarly, if a CRL signing key is compromised in a CRL system.) In contrast, in a preferred embodiment of the invention, breaking a secure vault does not forge the validity of an already revoked certificate. In fact, if the certificate is revoked on date i, the revocation verification of Y ₀ is published and all X _i values (or values from X ₀ to X _365-i ) are deleted at the same time. Thus, even if compromised, the attacker could not extend the validity of the revoked certificate. To do so, the attacker would have to be able to have the inverse of the one _- way hash H on X _365-i without any help. The worst thing an attacker could do in a system according to the invention after compromising it would be to forge the revocation of valid certificates, thus preventing a bona fide user from authenticating legitimate transactions. Of course, this is bad, but not as bad as an honest user authenticating illegal commerce.

Distributed implementation example: Security and processing cost analysis

Centralized implementations require that all queries about the validity of a certificate be routed to the same vault. This can be long delayed and easily shut down in applications where millions of certificates are in use. To prevent such congestion, delays, service outages, etc., the load in response to validity lookup can be distributed across several, geographically distributed, responder servers. However, in the case of OCSP, each added responder must have a secret signing key, which needs to be hosted in a vault, greatly increasing the cost of ownership of the OCSP system. High-grade bolts that meet financial cost requirements will cost at least $ 1 million to build and at least $ 1 million to operate. (Good bolts will include concrete, steel doors, backup power generators, and protected fuel reservoirs for potentially long-term operation of the generators. You will need at least four teams for supervision.) Applications requiring ten of these bolts will ensure fast response even at maximum traffic, but the cost of owning an OCSP system is an initial $ 10 million investment and $ 10 million annually. Will require an operating budget. Although less secure bolts and processing are used, millions of dollars will be required for initial and operational costs.

However, in a preferred embodiment of the present invention, a distributed implementation may consist of one vault and any number of insecure responders (ie, a normal server). In detail, according to the invention, it is assumed that (a) there are 10M certificates, (b) 1000 servers are strategically located around the world to minimize response time, and (c) the time granularity is 1 day. do.

CA processing (initialization cost): Start with the smallest serial number each morning and compile a 10M-entry array (F) as shown below. For each certificate C with serial number j, the 20 byte validity / cancellation verification of C is stored at location j. It then writes the date, signs it (F) and sends it to each of the 1000 servers.

User processing (query cost): To know the status of the certificate C, send the serial number j of C, and (if necessary, the CA ID) to the server S.

Server Processing (Response Cost): Every morning, when a properly dated and signed array F is received, the old array is replaced with a new array.

In any case, it responds to the inquiry about the serial number j by returning the 20 byte value to the position j of the current F.

Processing Procedures of Preferred Embodiments

1. Preparation of the array F takes place immediately.

If the entire hash chain is stored for each certificate, each entry is calculated by a simple table lookup operation. In an alternative embodiment, each entry is also calculated immediately.

2. F does not contain any secrets.

F still contains an accurate and complete description of valid and revoked certificates. (The purpose of the CA is to actually release this non-confidential information in the most efficient way possible.)

3. Sending F to the server is simple.

This is because F contains no secrets, no encryption process, and poses no security risks. Although 10M certificates are large, sending a 200M-byte file to 1000 servers at regular intervals may be sufficient.

4. Each server's response is 20 bytes long.

In other words, each response does not require any encryption process, signature or timestamp.

5. No dishonest suspension of service.

Since each value sent is 20 bytes long, each of these values is calculated immediately (by table lookup), and traffic can be distributed across 1000 servers, no service outages occur during legitimate system usage. Do not.

6. The server does not have to be secure.

The server sends 20 byte verifications received by the CA. Because they are self-authenticating, these verifications cannot be changed and still hash to the subject concerned.

Distributed implementations of the invention continue the same Doomsday protection of the centralized counterpart. That is, an intruder who successfully enters the vault can revoke the revoked certificate. But sophisticated intruders prefer software attacks if possible, instead of drilling holes in the bolts. Fortunately, software attacks against distributed / centralized OCSPs cannot be installed in response to distributed implementations of the invention.

Indeed at the OCSP, the CA needs to receive an external query from an insecure party and responds to the query with a digital signature and an important secret key. Thus, there is a possibility that the "window on the outside world" required by OCSP can be used maliciously to expose the secret signing key.

In contrast, such "windows" do not exist in distributed embodiments of the present invention. The CA is in the vault and does not receive or respond to any queries from outside. The CA only outputs non-secret data periodically. In fact, every day (every hour) the CA outputs a file F of public information. (The CA receives a cancellation request from the RA, but such RA comes from fewer security entities, for example through an authenticated channel such as a secure smart card.) The non-secure responder receives an inquiry from an insecure party, The non-secure responder responds to the inquiries by file F and by public data. Thus, in a software attack against a preferred embodiment of the present invention, an ordinary responder will only expose the publicly available information.

Simplified PKI Management

PKI management is not simple. (E.g., Internet Public Key Infrastructure, Part III: Certificate Management Protocols; by S. Farrel, A. Adams, and W. Ford; Internet Draft, 1996; Privacy Enhancement for Internet Electronic Mail-Part II: Certificate-Based Key Management ; by S.Kent and J.Linn; see 1989). A preferred embodiment of the present invention is by (1) reducing the number of certificates issued, (2) enabling privileged management on the certificate, and (3) sharing the registration function with a number of independent CAs. In many applications, however, PKI management can be improved.

The specific examples illustrate these improvements in PKI management. (The features and techniques used in one example can be readily applied to another example.)

To turn on / off (and pause) a certificate

Example 7: Downloading music

Suppose an Internet music provider wants users to download a song of their choice from one of the 1000 servers for $ 1 a day. This can be done effectively with a digital certificate. However, in this example, the user will know that he will only download music for a few days of the year and will not be able to predict when and how long the date will be. Thus, the music center will need to issue a different one-day certificate to the user whenever the user requests it. The user requests this certificate after paying a fee. The user then receives the certificate and then uses one of the 1000 music servers that day. However, issuing a one-day certificate is a management cost for both the supplier and the user. This cost must be duplicated each time the user wants to listen to music again.

In a preferred embodiment, the invention can reduce the following prices. The first time U contacts the supplier, he issues certificate C with issue date D1 = 0, expiration date D2 = 365 and validity field X ₃₆₅ , withdrawal target Y1, and stop field Z ₃₆₅ . (The provider's CA designs a static field just like the validity field: hashes 365 times by starting with any 20-byte value Z ₀ and then subdividing it into a day. Then it is the entire hash chain or Z _0. Save only or use the appropriate time / storage to generate the desired Zi, where U = 1, ......, 365, if U requests a "music day" for that day, The provider simply publishes a 20-byte value X _365-i to indicate that the certificate is valid, otherwise it publishes Z _365-i to indicate that the certificate is "suspended." unveils Y ₀ to indicate that withdrawal. Alternatively, if you agree to say "music week starting on the day I" U gonggeupjaeun and music, 20 for those seven days before the public at the appropriate time Sites are disclosed or the values X _i-365 to I day.

That is, whenever U wants to download music, rather than providing U with a new single-date certificate, the supplier provides U with a single, annual certificate. At any time, this single certificate can be turned ON for one day by only publishing the appropriate 20 byte value. Thus, for example, preferred embodiments of the invention, as it happens, are issued with a single single date by issuing a cert during the year so that it can be turned ON for 10 of 365 days a year. day) can replace certificates. The provider can also use the method to generate an authentication that specifies multiple days for which it can be ON (eg 10 days of 365 authentication). Because it is a more predictable price, and such certification is more suitable for futures.

ON / OFF of many certificates for the same user

Example 8: security-clarity management

Digital certificates work very well by allowing only appropriate users to access certain resources. In principle, privileges can be embodied in the authentication itself. For example, the state department has 10 different (L1, .... L10) security-clarity levels, and C = SIG _SD (SN, PK, U, L5, D1, D2, ....) Issuance of the same certificate C means that user U has security level 5 allowed. (D1 and D2 are again the issue and expiration dates.)

However, specifying the privileges of the certificate itself creates a nightmare for certificate management. Whenever its privileges change, authentication needs to be revoked. In addition, the security level of the employee varies with his / her transfer, which mainly changes in the same year. For example, the security-clarification level of U must be arbitrarily upgraded to 3, at which time the state department must withdraw the original C and issue a new certificate C '. This can be somewhat simplified by having U, so C 'holds the same public key (and expiration date) as before. E.g,

C '= SIG _SD (SN', PK, U, L3, D1 ', D2, ...).

But U still runs into "inserting" the new C 'into his browser in various places-his desk PC, his laptop-top, his cell phone, his PDA, and so on. Now, it is one thing to take an action for a CA to reissue a certificate in a slightly different form, but the counting on the user taking the action is entirely different!

This management problem is only exacerbated when short-lived certificates (eg, certificates that expire one day since issuance) are used. In the context of this embodiment, a single authentication allows an employee of the state department or user U to join a meeting that requires a higher level of security (such as in a cellular device, smart card or even mag striped card where U is suitable). If he is certified, he can, for example, open the door that leads to the meeting of the day.) Short-term certificates are more widely used and advocated. For it distributes the considerable difficulty of withdrawal. (There is no point on most devices to revoke a certificate that will expire within 24 hours.). However, by issuing short-term certificates, they live in the browser of every persistent user, making them administrative costs.

Such administrative costs can alleviate the use of preferred embodiments of the invention as follows. Assuming that the time accuracy of the day is sufficient, the state department issues a certificate to user U containing ten justification fields and one revocation field. E.g,

C = SIG _SD (SN, PK, U, D1, D2, A ₃₆₅ , B ₃₆₅ , C ₃₆₅ , D ₃₆₅ , E ₃₆₅ , F ₃₆₅ , G ₃₆₅ , H ₃₆₅ , I ₃₆₅ , J ₃₆₅ , Y1).

Therein generally, while Y1 is a revocation field of C, the first justification field A ₃₆₅ corresponds to security-clarity level 1, and the tenth justification field J ₃₆₅ corresponds to security-clarity level 10. Authentication C is used as follows. At date n, if U is in good condition (eg, authentication C is still valid), and if U has a security-clarity level of 5, then the state department publishes a 20 byte justification E _365-n . For example, in a distributed NOVOMODO implementation, send all its responders.) At date m, the state department announces B _365-m , if U has a security-clarity level of two. As soon as C is invalid (eg because U terminates as an employee or U's security key is negotiated), then the state department announces Y ₀ (and "future" A from its storage), Delete B, C, D, E, F, G, H, I and J).

In this way, Certificate C does not need to be revoked when these privileges are changed in the usual way, even though its own privileges are internally specified, and users do not need to load new certificates into their browser. Indeed, embodiments of the present invention have such a minimum footprint and when a single certificate can be issued very simply with a much higher likelihood that the CA (issuance, withdrawal and reissue of many related certificates) will not be withdrawn. to be. As a result, less phosphorus increases are issued and are issued or withdrawn to result in simpler PKI management in the application.

In summary, preferred embodiments of the present invention replace complex certificate management relative to a single certificate (with a minimum additional length) and a set of dynamically changing distributions or features by a single 20-byte value for distribution.

Telephone companies may use a method similar to that of Example 2 above for roaming purposes or for switching a given wireless device from one speed plan to another.

The main PKI cost is tied to the RA function. In addition, identifying user U requires an expensive personal interview and also requires that user U know the legitimate security key (corresponding to the public key PK to be authenticated). It would be desirable if this RA function could be shared among multiple CAs while maintaining totally independent control over unique certificates.

Example 9: Organization Certificate

Governments and larger organizations include horizontal and vertical sub-organizations. Employee may be related to more than one suborganization. For example, in the US government, employees can work for NIST and the Commerce Department. Issuing digital certificates for each of these relationships requires a lot of certificates and complicates PKI management. Whenever an employee loses or adds one of the relevant certificates, it is best to invalidate the corresponding certificate and issue a new certificate. In an ideal case, two alternatives should be harmonized. Two 1) The organization issues only one certificate per employee. 2) Each sub-organization issues and controls a separate certificate for each relevance.

These two alternatives can be harmonized as follows by the preferred embodiment of the present invention. First, a preferred embodiment of the present invention is compatible with separating the certification process from the validation process. The certification process is controlled by the CA and the validity process is controlled by the Validation Authority (VA). For example, assuming time accuracy of day, when CA wants to issue certificate C as serial number SN, CA sends SN to VA, and VA selects Y ₀ and X ₀ to triplet (SN, Y ₀ , X ₀ ) is stored in a secure manner, performs the same operations as the regular Y ₁ and X ₃₆₅ , and sends Y ₁ and X _{365 back} to the CA. The CA includes them in Certificate C. In this way, the CA does not have to bother to determine the validity of certificate C. The CA only needs to identify the user and issue Certificate C as appropriate, and the VA needs only to distinguish whether C is valid or retired. This separation can be used in a variety of ways to have organizational certificates that flexibly reflect natural changes in internal sub-organizations. The following is one of these methods, using government agencies as an example. The government as a whole will have its own CA, and each agency will have its own CA.

Assume k different institutions with corresponding CAs, that is, CA ¹ , CA ² ... CA ^k , with an accuracy of day time. Government certificate C takes the form:

C = SIG _GOV (SN, PK, U, D ₁ , D ₂ , X ₃₆₅ , Y ₁ , [X ₃₆₅ ¹ , Z ₃₆₅ ¹ ], ..., [X ₃₆₅ k, Z ₃₆₅ k])

Where SN is the serial number of the certificate, PK is the user's public key, U is the user's identity, D ₁ is the issue date, D ₂ is the expiration date, X ₃₆₅ is a valid field, Y ₁ is a discard field, and X ₃₆₅ ^j is It is a valid field of CA ^j and Z ₃₆₅ ^j is a right stop field of CA ^j .

This certificate is generated by the government CA with input from the authority CAs. After identifying user U and choosing a unique serial number SN, issue date D ₁ , expiration date D ₂ , the government CA sends SN, PK, D ₁ , D ₂ (preferred form is preferred) to each agency CA. The j th CA selects two confidential 20 byte values X ₀ ^j and Z ₀ ^j , and stores (SN, PK, U, D ₁ , D ₂ , X ₀ ^j , Z ₀ ^j ) locally, or more. Simply store (SN, X ₀ ^j , Z ₀ ^j ) locally and send back [X ₃₆₅ ^j , Z ₃₆₅ ^j ] to location j to integrate with the government certificate.

This certificate C is managed by a distributed implementation of the invention. That is, it operates with k independent certificates, such as 1 certificate, 2-certificate, 3-certificate, ..., k-certificate, one per institution. Assume 100 respondents on date n. The government CA sends a 20-byte value X _365-n to all 100 respondents if C is still valid. Otherwise, transmits Y ₀ . The j-th authority CA then sends all 20-byte values X _365-n ^j to 100 responders, showing that C can rely on j certificates. Otherwise it shows that you can rely on Z _365-n ^j .

Thus, government CAs are only responsible for identifying users and issuing certificates, but each institutional CA can manage its own, unique certificate independently. This is very important. If CA1 is the Department of Justice and CA2 is the Department of Defense, it is best that each act independently of each other, despite some overlapping concerns. The resulting certificate system works very economically. First, the number of certificates is greatly reduced (in principle, only one certificate per employee exists). Second, a given employee can leave or participate in different institutions without having to revoke the old certificate or obtain a new certificate. Third, different institutional CAs can share the same responder (in fact, the fact that a given user belongs to a given institution is not confidential. For most institutions this will be true. The server will only have "public information") will be). Thus, a question about the status of the j certificate is answered with two 20-byte values. One government certificate, one j-certificate. This can quickly invalidate C at "central-level" (eg if the user loses the secret key corresponding to the PK).

Example 10:

In this example, certificate C could only be revoked in a centralized manner. However, it is also easy for the abolition responsibility to be passed on to individual agencies. For example, to enable the j-th authority CA to revoke and revoke C with the j-certificate in a fully automatic manner, C may take the following form:

C = SIG _GOV (SN, PK, U, D ₁ , D ₂ , [X _N1 ¹ , Y ₁ ¹ , Z _N1 ¹ ], ..., [X _Nk ^k , Y ₁ ¹ , Z _Nk ^k ])

In addition, different institutions may have different time accuracy for their own certificates.

C = SIG _GOV (SN, PK, U, D ₁ , D ₂ , [TA ¹ , X _N1 ¹ , Y ₁ ¹ , Z _N1 ¹ ], ..., [TA ^k , X _Nk ^k , Y ₁ ¹ , Z _Nk ^k ])

TA ^j is the time accuracy of the j th CA and N ^j is the number of time units between D ₁ and D ₂ . For example, if TA ^j is one day and D ₁ -D ₂ = 1 year, then X _Nj ^j = X ₃₆₅ ^j .

Within a single organization, one important advantage of issuing certificates configured and managed as described above is that it is possible to keep a certificate "live" even if a user moves from one suborganization to another. Is there. However, the techniques can be applied outside of a single organizational domain. In addition, a government CA may be viewed as a "landlord" CA, k institutional CAs may be viewed as an unrelated organization (other than a sub-organization) "tenant" CA, and the certificate may be viewed as a rental certificate. This term is borrowed from a more familiar example that applies the advantages of "joint construction and independent control". Rental certificates are similar to speculative buildings with identical furniture specifications.

Rather than building your own apartment, it is better for an architect to build a 20-story building, rent one in a penthouse and rent or sell the rest of the furniture. Each of the 20 tenants serves as a single owner. Each tenant automatically decides who enters the architect and who provides the key without a lie. Of course, a 20-story building is cheaper than 20 single-story buildings. It may be 10 times cheaper. This economic principle is more evident in the loan certificate. In addition, the cost of issuing a regular certificate and the cost of issuing a rental certificate are generally the same. Thus, issuing a loan certificate to a "landlord" CA can be very beneficial, or issuing a loan certificate can fully reimburse the costs incurred for the unique certificate. On the other hand, a "tenant" CA can reduce the cost of issuing, share the cost of issuing a certificate in a k way, reduce infrastructure costs, and share the same respondents (with only public data). Because).

Natural candidates that serve as landlord CAs for external tenant CAs are credit card companies, large financial institutions, and governments. In many cases, they have close and long-lasting ties with millions of users and can easily issue digital certificates without investing too many resources for user identification (for example, a credit card company can offer customers Have been billing for years, and this knowledge can be alleviated). Credit card companies may prefer the idea of issuing certificates to a landlord CA in order to implement their own affinity program more effectively. The IRS may have already decided to use digital certificates, and loaned certificates may later provide a tax system that will repay the costs incurred in establishing a faster and better service.

Example 11:

So far, we have described that a Landlord CA needs to cooperate with its own tenant CAs during the issuance process, and therefore needs to identify that tenant CA in advance. However, it is also practical to issue loan certificates when a Landlord CA does not need to identify all or some of these tenants, for example assuming 20 tenant CAs. Moreover, future tenant CAs will be able to rent space on already issued certificates. This feature is ideal for new authentication implementation applications. Rather than deal with the costs of issuing certificates to millions of customers, the company that provides the new certificate-implemented item accesses Landlord CA with millions of certificates, rents space, and then uses a large number of Landlord CA users. Have the customer sign as a customer. This signature method turns on all corresponding certificates overnight, and then starts managing them according to their criteria. We will describe several techniques for implementing this functionality below.

Additional system

Device Validation System

How the techniques of the present invention can be applied to devices (eg, cellular phones, PDAs, RF identification tokens, PCs, laptops, VCRs, network devices, routers, firewalls, set-top boxes, CD players, game players, DVD devices, etc.) Look at the

Consider the features that turn these devices on and on. If the device is stolen, it is desirable that the device no longer operates. On the other hand, when the device is not stolen, it is desirable to operate normally. Similarly, when a user rents a device, pays a subscription fee, or uses a device on behalf of a company, the device is desirable to operate and no longer pay the rental fee, pay the subscription fee anymore, or use it for company use. If not, the device needs to be turned off and shut down. Otherwise, the device should function normally. These devices can be turned on, off and on in a dynamic way.

Of course, these functions can be achieved using a system according to a preferred embodiment of the present invention. In essence, given the day-by-day incrementality (which is an example), the device may carry a digital certificate to specify the valid field X, and that date only if the device has date-specific evidence of validity for X. Can work. The device may have a reliable / protected clock to prevent malfunction. This device (especially in the case of cellular phones) can issue proof of validity by date. Alternatively, the device may request the second entity for proof of its validity for that date. For example, the device may provide its serial number and receive proof of validity of the date accordingly.

This is true because the integrity of the valid fields is guaranteed by the certificate and thus by the X digital signature (with information such as date) of the CA. But we can protect the integrity of X in the following alternative ways. That is, the device can be protected by burning X in an immutable manner. For example, it can be protected by writing it to a ROM of the chip (chip set such as smart card / PDA / telephone / laptop). In this way, the user of the device cannot change X in any way. Evidence-validating algorithms can also be baked and embedded. If reduced evidence P of validity for that date is presented, P is hashed the appropriate number of times and then compared to what is baked with X. More generally, one-way function F can be used rather than one-way hash function. The entire process, including the production, is shown below.

The first entity generates an initial value IV and repeats the one-way function F for V a given number of times to obtain the final value FV. The second entity (which may be the same as the first entity) bakes X to apparatus D. The device D has means for repeating the function F. The device D later receives the reduced nth evidence of the value PV (where n is a positive integer) and confirms the PV. This check is done by repeating the function F n times for PV and checking that the final value is equal to the baked value X.

Device D may refer to its clock to ensure that the nth evidence value corresponds to the current date. The current date may be the nth date of the date sequence starting from a fixed date. A fixed date can be baked and stored on the device to protect its integrity.

In each iteration, function F may receive additional input as input. For example, an identifier of D may be entered at each iteration. These additional inputs may be different for each different iteration. For example, the integer k may be input in the iteration k.

Only one unidirectional function F can exist. There may be a sequence of unidirectional functions, and Fk may be a function applied in iteration k.

The validity of field X can also be used as an identifier of D, thus dividing D's serial number and individual handling of valid fields.

The system described above can be used to turn a given device D on or off. However, it can be used not only to turn on / off when a single function is given, but also to turn on / off when a single function is given among several functions. For example, X may be a valid field for function FX and Z may be a valid field for function FZ. In this case, receiving valid evidence for X (Z) means that function FX (FZ) is turned on for device D on that date. These additional valid fields Z, ... can be baked in device D. In addition, descriptions / identifiers with functions related to X / Z / ... etc. can also be baked.

If there are a large number of possible functions, the valid fields are Merkle hashed and then the root value of the Merkle tree can be baked. In this case, in order to turn on the function FX, the device can be provided with adequate evidence of validity for X along with the approval path from X to Merkle tree. Merkle admission path algorithms can also be baked.

Effective identification of clockless devices

As discussed above, the technique of the preferred embodiment can be used to validate a device by turning it on or off to prevent misuse. The security of this application is that the device has a clock that cannot be controlled by an intruder. The intruder can be the original owner of the device. For example, a dismissed employee who wants to access company data from a corporate laptop at home. In fact, if the company no longer issues proof of validity for date j, the attacker would rewind the clock on the device and induce the device to believe that the current date d is less than j, thus accurately validating the validity of date d. Evidence can be played back on the device. This allows the device to operate on date j.

The preferred embodiment provides a technique for performing device validation on devices that are either clock free or secure clock free.

This technique considers a validator, which is an entity that determines whether a given device should be validated on that date in a series of dates. Suppose that date is one of a series of dates. The device has a secure memory portion and a clock. Even if not secured, the device can tell if the clock was reset when it was turned on. For example, the device may say that 24 hours have elapsed while driving. Validation software is protected within the device to avoid changing it in any way. Some smartcards work in a similar way. For example, it may have a protected portion of memory, may have minimal power to maintain its value in the storage device, and may have a clock. However, it may not be possible to have a battery that can have a clock driven for some significant time. Thus, when inserted into the card reader, the clock of the smart card is activated and the card can accurately monitor the passage of time. However, when the card is ejected from the reader, the clock no longer works, and small values are still preserved in secure memory.

Example 12:

In this way, the validator and the device share the security key K. The key K is preferably located in the secure memory portion of the device. From this key K, the device and validator can generate an unpredictable series of values corresponding to the series of dates. For example, for each date, 1, 2, ..., the series of values consists of V1 = H (K, 1), V2 = H (K2), ... H is a one-way hash function or an encryption function that encrypts 1, 2, ... with the key K each time. If the validator on date j wants to activate the device for another day, the validity discriminator publishes the value Vj = H (K, j) (eg, sends it to the responder). After the device is activated on date d, it turns on on date j and then switches off to date j. The device then keeps in memory the value Vd = H (K, d), or an indicator of the last day activated (eg d). The device will not function again until validity evidence is obtained after date d. Alternatively, the device continues to store the working time as a single variable or the like during the date d. When the device is switched off, the device stores not only the date d but also for example up to six hours and ten minutes. Thus, when switched on again, operation continues for 17 hours and 50 minutes. The device will then need proof of validity for a date following date d. This time it is assumed that the device is switched on again when the date j> d. The device then obtains evidence of validity Vj for date j (eg, exports such evidence or receives such evidence after a request to the responder. The device determines whether Vj is validity evidence following evidence V in current memory). For example, the device generates Vd + 1, Vd + 2, ... using the security key K until the value Vj is generated (or until the total corresponding dates are passed). If this is the case, the device will be turned on for 24 hours, that is, it will keep the new Vj or j in memory, operate and monitor the clock normally, and when it reaches 24 hours, the new value Vj + 1 or VK (if k> j) is required.

The device can be turned off by not publishing or supplying subsequent proof of validity. Alternatively, it may be turned off by receiving a particular value, such as H, or by publishing or receiving a particular value Vnomore stored in memory. The device may be suspended on that date by receiving or publishing certain values such as H (K, suspend, j). The keys for validity, revocation, and suspension of authority evidence may be the same or may be different.

This already provides a great deal of protection. If the device is stolen after being used normally on date j-1, no validity evidence for date j is disclosed and nothing is available to the device. Thereafter, it will stop the start of operation on date j, regardless of whether the device was switched off prior to theft. In fact, if switched off, you will need proof of validity for dates after j-1 to turn on normally, and no such evidence appears. If stolen in a switched-on state, it will stop working anyway after 24 hours.

In a bad case, the device may be switched on after having switched on and having proof of validity of Vj-3. If the device was stolen at this point but did not know the lost date of j-1, or if the device was stolen on date j-1 and the attacker recorded the values Vj-2 and Vj-1 that the device knew. At best, these intruders can supply both of these values to the device, and only run them for an additional two days.

Example 13: This method is similar to the method disclosed in Example 11. Each set of dates, such as an unsecured clock, uses a set of unpredictable values that are made available or exposed to the device. For example, the device stores Xk and stores the result of repeating one (or more) one-way functions F k times for the initial value X0. It operates as described above and uses the same variables. Xk is then written to the firmware (unmodifiable) or stored in a secure part of the memory. Evidence of validity for date j corresponds to Xk-j in the underlying technique of the invention. Additional suspensions and revocations can occur in the same way.

ㅇ RTC physical access implementation

Managing Multiple Privileges in a Mixed Environment

Robust access control systems must answer two questions for all users. The first question addresses authentication or identification. "Who has told you?" This question is typically addressed either directly or indirectly via identification signs, key biological features, or passcodes. This provides a reasonable answer for long-lasting user identification but does not address the main question, which is more timely valid. "Do you do what you've been trying to do recently?"

For example, the identification sign may tell you that Alice has been employed as an employee for some time in the last decade, but she cannot independently determine whether she is still an employee to grant access to the computer server room.

For physical access control, the security lock must verify its identity through authentication, and then justify to determine if the user's current privileges permit entry. Some locks are performed by a wired network connection to a central trust authority. Physical access solutions based entirely on network wired locking have two significant limitations. The price of each wire lock includes the price of the security wiring, the field control panel, and the cost of labor, and varies by thousands of doors. Reaching a wired configuration is limited to locks that can be easily accessed by persistent networking. This prevents the use of robust access control for movement or makes it difficult to reach locks such as vehicles, storage containers, utility cabinets, and the like.

Real-time trust technology in accordance with a preferred embodiment of the present invention provides a security method for performing efficient verification for physical access on wired and disconnected locks. This allows AI door locks to verify current user privileges and permissions without requiring expensive network connections with each lock.

The present invention describes a number of implementations that can provide for disconnected confirmation based on a number of independent user privileges. Each implementation provides interoperability with access control hardware and software that exists for use in heterogeneous devices. For each implementation, this paper will explain how real-time trust provides increased flexibility while dramatically lowering the overall price of high-security.

All four configurations described below feature the same RTC verification process. The main difference between these structures is the user's authentication process, which affects price and compatibility along with existing access solutions.

ID / memory without contact

The first RTC verification implementation is an access control environment based on a contactless ID card with read / write memory access. This has been described using a card without a general MIFARE ^™ standard contact as an embodiment, but the verification solution is the same with any memory ID card.

When a MIFARE ID card is currently used in a network physical access environment, the lock reads the ID from the card and sends it to a nearby panel or server that checks its privileges and performs verification. The authentication process is the determination of the card ID, which is remotely controlled based on this ID.

The physical access solution of the present invention can maintain compatibility with this model for wired homes, but for disconnected homes by using the card's read / write memory to store digitally signed "verification evidence" for the card. Should be added. This evidence is periodically written to the card in any network reader and then it can be read in an unlocked lock to confirm the user's approval and current justification.

The following table shows the logical content of the RTC validation evidence stored on the card according to the approximate storage conditions for each component.

When the user enters the facility through a wired door, the door retrieves the user's full verification evidence in the above format and places it in the memory area on the card. Once the evidence is loaded on the card, an unconnected lock can justify the user's authorization through the following steps.

(1) Perform standardized authentication by searching the user's card ID

(2) retrieve the RTC verification evidence from memory

(3) Verify that the digital signature matches a known public key of a trusted certificate

(4) confirming that the evidence is current (using start and end times).

(5) Check if the card is valid

(6) checks for discretionary access control conditions based on privileges from evidence

The disconnected lock is implemented with a set of access control rules based on privileges rather than an individual user ID. For example, lockout is configured to only allow users with "parking" privileges only during business hours. Because individual user privileges can change through RTC verification evidence, the lock itself does not need to be changed as new users are added or removed to change access performance. In addition, the lock does not need to store any security keys or data, which means that individual locks can be broken down without any reduction in overall system security.

According to a preferred embodiment of the present invention, the RTC verification evidence has inherent features that make them uniquely robust for physical access control environments. Since the evidence is digitally signed, they are memorable and nosy-proof. Since the evidence does not contain any security keys, they can be made public and transmitted without security risk. The evidence is small enough to be stored on a low-end memory card.

These features allow RTC verification evidence to be used on cards such as the MIFARE standard, while still providing high security password verification with thousands of independent user privileges per card.

Price- MIFARE 1k standard cards range from $ 1 to $ 5 depending on manufacturer and volume. Unlocked locks and RTC identification techniques for MIFARE cards can be manufactured at less than $ 500 per house. In installation, a single door or container can be secured for less than $ 1000.

Security-Single ID authentication provides weak protection against nesting and forgery. Second and third component authentication in combination with PKI protection can be used to increase authentication security. The trustworthiness check is protected by strong PKI encryption, preventing unauthorized forgery or modification.

Distributed security without contact

RTC trusted verification can also be used with an identity card such as HID's iClass that performs verification using secure information distributed directly or indirectly with all readers. The lockdown will perform authentication with the card using a randomized challenge / response protocol that proves that the card knows the security response to its ID.

The RTC verification for a distributed security card is the same as the verification for a single ID card. When the user enters the wired door, the lock will record current RTC verification evidence on the user's card. This evidence is later retrieved by an unconnected reader for offline confirmation.

Price-A contactless dispensed security card with memory is available for $ 5 to $ 10 depending on manufacturer or volume. Unconnected locks based on distributed security cards and RTC verification technology can be manufactured for less than $ 500 per door. In installation, a single door or container can be secured under $ 1000.

Security-Distributed security authentication reduces the opportunity for the overlap of individual cards, but the negotiation of a single offline reader allows for the overlap of many cards. Trusted verification is protected by strong PKI encryption by preventing authorization forgery or modification.

Contactless PKI

Cards capable of performing public key digital signatures provide the highest level of authentication security. It is based on MIFARE PRO X chips, like many high end JavaCards. The locks authenticate the card based on the challenge / response protocol without requiring any sensitive information in the lock.

The RTC verification for the public key card is the same as the verification for a single ID card. When the user enters the wired door, the lock will record current RTC verification evidence on the user's card and this evidence will be retrieved from an unconnected reader for offline verification.

The public key of the card will be represented in particular by a digital certificate, which will be used for alternative applications such as computer access and email security. High-end public key cards provide additional devices such as information security or stored values, which help to reduce the overall price for each device.

Price-contact PKI cards are available from $ 10 to $ 20 depending on manufacturing and volume. Unconnected locks based on MIFARE cards and RTC identification technology can be manufactured for less than $ 500 per door. With installation, a single door or container can be secured for less than $ 1000.

Security-PKI cards can provide strong cryptographic authentication with a low risk lock of key negotiation or card overlap. Trusted verification is protected by strong PKI encryption to prevent unauthorized forgery or modification.

Technique to pass through a hash sequence

Let H be a one-way hash function. A hash chain of length n is a collection of values.

x0, x1, ....., xn is H (xi) = x _i-1 . While x _i-1 is easy from calculating this xi, the calculation in the opposite direction is not convenient because of the unidirectionality of H.

Here is the hash chain representation:

x0 (H) x1 (H) ... (H) x _n-1 (H) xn

In many applications (such as document verification and privilege management services), it is necessary to be able to traverse the hash chain. For example, the values x0, x1, ..., xn in order (from left to right in the chain above) for a specific interval of time (for example, to output a value of one day per year). It happens. Note that the order of left to right makes this problem difficult because of the unidirectionality of H. While it is easy to generate and output x0, x1, ..., xn in order by simply applying H repeatedly, the reverse order requires more time and / or memory.

Two obvious approaches,

Store only one value, x _n , and compute H ^n-1 (x _n ) to print xi.

Store all x0, x1, ..., xn values and delete them as they are printed.

The first approach requires two hash values (one for xn and another for the calculation of xi) and an n (n + 1) / 2 valuation or average, n / 2 valuation per output. The second approach requires the storage of n valuation values of n + 1 hash values and H totals, or 1 valuation value per average, output value.

We are interested in an immediate solution. It provides another tradeoff of memory (number of stored hash values) versus time (number of H valuations required).

Algorithms have been provided in the prior art that lead to the following tradeoffs: between stored [log ₂ n] hash values and [log ₂ n] calculation of H per hash value output (Almost Optimal of Don Coppersmith and Maruks Jakobsson). Hash Sequence Traversal, Editor, Financial Cryptography: Sixth International Conference (FC'02), Southhampton, Bermuda, 11-14, March 2002)

New Algorithm with Constant Storage

Jacobson's method requires storage for log ₂ n hash values, but cannot be used when less storage is available. Note that in a 365 chain of hash chains, this means that 9 values need to be stored, and a 1,000,000 length hash chain means that 20 values need to be stored. We want to have algorithms with lower storage requirements. In addition, we need to be able to specify storage requirements that are independent of hash chain length. In this way, the same amount of memory is needed to manage short chains and long chains. Thus, if the hash chain lengths change, there is no need for a new memory.

For convenience of reasoning about the algorithm, let's call the value xj where the algorithm stores "pebble" at position j. The pebble then is allowed the following: (1) moving to where the other pebble is located (corresponding to copying a value) (2) moving one step to the left of its current position (This corresponds to the valuation H.) For the first time, the pebbles start at any location on the hash chain.

Note that the number of pebbles corresponds to the number of hash values stored, and the number of times the pebble takes a step to the left corresponds to the number of H valuations. Our goal is to come up with an algorithm that reduces the number of pebble steps in a given number of pebbles.

Two pebbles

It is clear that the pebble is always needed at n. If xn is not stored, there is no way to recover it and therefore there is no way to output it when needed at the end of the traversal. It is also clear that the pebble is always needed to be able to output the output xi at the current position I. Therefore, more than two pebbles are needed.

If only two pebbles are used, one of them must stay at xn, and the other must start at xn, moving xi on each attempt. So the best algorithm for two pebbles is to take n (n + 1) / 2 full steps or n / 2 steps per output on average. For example, for a hash chain of 1,000,000 lengths, the average number of steps is 500,000 per output.

3 pebbles

If we add just one pebble to two absolutely necessary, it proves that we can be significantly improved in many stages.

We will proceed as follows. s = [sqrt {n}] (Note that there will be n / s sqrt {n} intervals) Divide the hash chain by s length intervals. Set the pebble number to 3 in xn and the pebble number to 2 in xs. The pebble number 1 is then used to traverse points x0, ... xs (starting each time at xs) using the algorithm for the two pebbles described above. Then let's call the pebble number 2 at x2s (starting at xn and moving to the left) and again use the algorithm for two pebble crossings xs + 1 ... x2s. Continuing in this manner, each time uses a two-pebble algorithm for the length s interval.

The overall level of this algorithm can be calculated as follows. In order to traverse each section using two pebbles we need s (s + 1) / 2 steps. In addition, we need (ns) + (n-2s) + .. + s + 0 (n / s) (n / 2) to move the pebble number 2 to the beginning of each leg before traversing it. .

Step-Remember that s = [sqrt {n}]. As a result, the average number of steps per output is s / 2 + (n / s) / 2 [sqrt {n}].

Thus, adding a third pebble to the minimum of only two will save time per output from n / 2 to sqrt {n}. This reduction is quite dramatic. For example, for a hash chain of 1,000,000 lengths, the average number of steps is 1,000 per output (as opposed to the 500,000 needed with two pebbles).

4 pebbles

If we have another available pebble, we can divide the hash chain again at intervals. At this point, we can set s = [sqrt {n ^(2/3) }] and divide the entire chain into n / sn ^(1/3) intervals of length s.

We will then call the pebble number 4 in n and use it as the starting point for the pebble number 3. This will move to the beginning of each section of size s in order from left to right. On each interval, we will use the three pebble crossing algorithms described above. That is, we will also subdivide each interval by size [sqrt {s}], and in each subinterval, in order from left to right (pebble number 2 will begin pebble number 3 at each time). The pebble number is called 2. The pebble number 1 will traverse the subinterval, each time starting at the pebble number 2.

Thus the cost of traversing each interval would be sqrt {s} or [n ^(1/3) ] per output. For that, we must add the cost of moving the pebble number 3 to the beginning of each interval. The pebble number 3 will be shifted n / s times, first with ns and then n-2s steps, giving a value of (n / s) / 2 n ^(1/3) .

Therefore, the average number of steps per output value is [1.5n ^(1/3) ]. Again, using an embodiment of a chain of 1,000,000 lengths, the average number of steps is 150 per output value.

More generalization of Pebble

The general description from the above embodiment is as follows. Given a c pebble, divide the hash chain into n ^{(1 / (c-1))} intervals of length n ^{((c-2) / (c-1))} , respectively. For each of these intervals we use the technique for c-1 pebble. For each output, the average price would be ((c-1) / 2) n ^{(1 / (c-1))} ).

This generalization can be taken into account not only in the pebble's integer, but also in the case of c = 1 + log ₂ n, for example. In that case, using the equation n ^log2n = 2, we will have the average price per output value log ₂ n using our algorithm.

Worst case price increases

Nevertheless, while the above techniques obtain average price per output, some outputs will take longer to calculate than others.

For example, consider the case of three pebbles. At every time we traverse the s pebble, we must relocate the pebble number 2. Thus, at the left end of the interval, the output will take longer to calculate. For example, to calculate X _{s + 1} , we will need to do n- (s + 1) steps. On the other hand, all other pebbles in the interval will at most go through the s phase.

Of course, this causes serious problems in some applications. The computing device involved should be fast enough to handle this "bad" case. But if it's not already that fast, it doesn't seem to exist at all. We will still need a powerful computing device, which simply sits slowly on average.

To avoid this problem, we need to make the worst case output value close to the average output value. In the case of three pebbles, this may be done by adding only one additional pebble. Bring up the pebble "2a". Its job is to move first to where Pebble 2 should be next. For example, when the pebble is placed at point s, pebble 2a will start at point n moving towards point 2s. It will reach exactly point 2s when Pebble 2 needs to be there, that is, until the value s is the output.

Thus, while a section of given size s is traversing, pebble 2a will start at position n and move to the left of the beginning of the next section. Note that Pebble 2a needs to take fewer steps than n steps to reach its destination. The obvious approach is that Pebble 2a takes at most n / s steps for each output in the interval. This will result in the worst case of s + n / s [2sqrt {n}] per output. But note that you can do better. Because Pebble 1 needs to take more steps for the value at the left end of the interval than at the right end of the interval to reduce the price in the worst case, Pebble 2a should start "slowly" and speed up . " The total number of steps taken by Pebble 1 and 2a will remain constant in this way. In particular, Pebble 2a must first take (n / s) / 2 steps and then up to 3 (n / s) / 2 steps when the last value of the interval is output by doing (n / s) 2 +1 steps Do it. This will reduce the worst case price by [1.5sqrt {n}].

Note the total number of steps and the average value per unit of output value does not increase in addition to this additional pebble. This means that the additional pebble does not do any additional work first rather than doing some work first. Thus, with a hash chain of length 1,000,000, the worst case price would be 1,500 while the average case price would be 1,000 per output.

This approach extends to more pebbles. If we take a solution with four pebbles, we first add the pebbles 2a and 3a, which move to the appropriate positions for pebble 2 and 4, respectively. We will reduce the price in the worst case by [2n ^1/3 ]. Taking the embodiment of a chain of 1,000,000 lengths again, the worst case price will be 200 while the average case price is 150 per output value.

Thus, in general, with 2c-2 pebbles, we have an average value of ((ca) / 2 n ^{{1 / (c-1)}} and (c / 2) n ^{{1 / (c-1} ) for a given output ^)} Can traverse the hash chain at the worst price.

Again, this generalization can be considered not only in the pebble's constant, but also in the case of, for example, c = 1+ log ₂ n. With 2log ₂ n Pebble in this case, our algorithm will be able to traverse the hash chains each having an average output value of log ₂ n and 1 + log ₂ n worst case price.

Optimal solution

For a given c pebble, below we describe a method for obtaining an algorithm that probably has the optimal overall calculation price. Note, however, that for a small value of c, this probably means that the best solution is to only reduce the number of slight steps compared to the above solution.

Suppose we have c pebble. We need to store xn, which takes one pebble. One or more pebbles will then be moved to Xk (if some k is determined below) by applying to Hn the number of Hn-k times. Then, inductively, we use the optimal solution for c-1 pebbles to output x0, x1, ..., xk in order. Note that this amounts to traversing one of the shorter chain-lengths k since the value of xk is stored. Then, inductively use the optimal solution for c pebble to output the values of X _{k + 1} , ..., Xn in order. Since the first k value has already been traversed, it again traverses one of the shorter chain-lengths nk.

Now define F (c, n) as the number of steps needed to traverse a hash chain of length n while storing only c pebbles at a given time. Clearly, if c ≥ 1 then F (c, 0) = 0 and F (0, n) = at any n. Then, in the above method, F (k, n) = min _k F (c-1, k) + F (c, nk-1) + nk, k is to minimize F (c, n) Should be chosen.

Finding the optimal location k for particular c and n is a matter of simple regression with memoization (a.k.a.dynamic programming). We represent C code that does this. Such optimal point can be easily found first and then integrated into the hash traversal code.

Implementation of an Optimal Solution for the Amount of Memory

Private key security physical access (real-time proof in Kerberos setting)

In general, the scenario includes multiple doors and multiple users. In addition, the access is controlled by multiple authentications (each authentication controls access through several statements, and sets of statements for other authentications can overlap). At the most general level, the access is controlled by having users presenting credentials to the door (confirmation of such credentials requires interaction between the user and the door, such as PIN entry, as is the exchange of messages between the door and the user card). do). In the case of a door, it is particularly important to support the security of access with the lowest price and without connection to the door to any particular server or network.)

One important observation, whatever credentials we use, allows our RTC technology to drive significant security, infrastructure and price advantages. RTCs can be used to match public key encryption methods (certificates, public key signatures, PKIs), just like private key cryptographic devices (symmetric or private key signing and encryption, Kerberos-type systems, etc.). Access control for disconnected homes using public-key technology has been addressed. Here we describe how to adapt such ideas with private-key techniques.

Basic primitive

Encryption, signature, pseudo-random function

In particular, private key encryption, private key signature (aka MAC), and private key random functions are typical private key primitives that we will use. For our purposes, these primitives can be used interchangeably. For example, deterministic private key signature structures (between two entities distributing secret signing key SK), and the random function Fs (its seed s is distributed between two entities) are considered substantially equal. Will be. Both produce an unpredictable output to a third party that knows the corresponding input, but not SK or s. For example, the function FSK (x), which returns the digital signal x with the security key SK, is substantially sufficient to be considered a pseudo-random function with the seed SK. On the other hand, at input x, the function Fs (x) returning the value at x of the pseudo-random function F with seed s can be considered a private key signature algorithm with security key s.

Unidirectional and Unidirectional Hash Functions

We also use another basic primitive-unidirectional function F and one-way hash function H. Substantially the function F is unidirectional if (1) at a given input X, it is possible to efficiently calculate F (X), and (2) during a given F (X) is arbitrarily sufficiently chosen so that X cannot be sufficiently foreseen. It is practically impossible to compute (e.g., because too many values for X must in principle be tried, and no efficient way exists to get close to many possible applicants). Case and it is difficult to find two separate inputs X and Y (although it is desirable to map a longer input to a shorter or arbitrarily long input—i.e. 160 bits), the function H is a one-way hash function. As a result, H (X) = H (Y).

In practice, we can use the one-way hash function H to construct other primitives. For example, the private-key signature can be constructed in the following simple way. By signing message M with security key SK, H (SK, M) is calculated and then the result is hashed. In other words, SK and M are combined as appropriate. Of course, with signature and date M, we can add date d to this combination and compute H (SK, M, d) instead. Similarly, pseudo-random functions can be established as follows. On input x, compute H (s, x) to produce the output of pseudo-random function F with seed s. That is, combine s and x as appropriate and then apply a one-way hash function to the result.

Secure physical approach

We only focused on the new aspects introduced by the private-key settings, and skipped the general aspects that can be applied to the new scenarios (eg everyday / normal computational aspects). We begin with a simple scenario.

Single organization

Let D be a statement (with the above structure). Organization A and User U (probably working for A) who want to control access to D again have a card, CU with appropriate identity and so on. A then controls access to D by distributing security key SK with D. If A wants to allow U access to D on date d (time interval d), it computes evidence PUDd, which is difficult for anyone except A to calculate but is easy for D to identify. We will see how this can be done using both private key encryption and private key signature.

Private-Key Cryptographic Solution (with Proof of Identity)

For example, PUDd may be d with a message embodying a cipher, EUDd, U, likewise possible D and a private encryption key SK according to some installed private key encryption algorithms such as DES.

Here, as elsewhere, U tends to indicate all of the users as well as suitable identifiers for U. If user U has a card (preferably secure) associated with it, then U is such a card or a suitable identifier thereof. In the latter case, for example, the inquiry card reader gets U from the card and gets EUDd EH, which reads the EUDd with the key SK and then ensures that they read the U provided by the card to be the same. Compare.

Note that EUDd approves statement D that allows user U to enter through it in time interval d, but does not prove that it handles user U for sure. Thus we must augment the basic structure of how U identifies his unique identity to the door. This can be done in a variety of ways. In particular, authority A provides EUDd only with U's card, U's card is provided with the keypad and only if a valid PIN enters its keypad (and the wrong PIN is entered more than a given number of times) Or EUDd can only be sent to door D if it enters its associated volatile memory content). In this way, every time a door receives EUDd, it knows that it is being received from U's card (because A sends only EUDd to U's card) and "the user behind the card" must be U (stealed). To fight against a malicious user with a U card). Because U's card does not work or U's PIN is not entered on its keypad it sends EUDd to D. The second way to prove his identity to D, where U consists of having U, is to provide his unique PIN directly to D. For example, Door D has its own keypad, and U uses it to enter its own PIN, PINu. The door has an internal way (e.g. a table) that maps PINu to U, so it can be realized that it is handling U correctly. If there are many statements in the system, however, it is impractical to provide or update a table for each statement (e.g. because of a new user joining the system). Therefore, it is preferable that the identifier of U be directly PINu. For example, EUDd becomes EPINuDd. When user U accesses door D, he enters PINu with D's keypad and his card EPINuDd is sent to door. The statement then checks whether the entered PIN is embodied in EPINuDd, in which case it is handled with a legitimate user and this same user is authorized by A to pass D without using the PIN-user table. . Certainly, the keypad tells D that a user who knows PINu is in front of it and EPINuDd tells D that PINu has recently been authorized to go through D. In the third method, the user PIN is certainly combined with EUDd rather than directly seen in EUDd. A provides EUDd as a card of encrypted U with a key PINu or a key K that can be reconstructed from PINu (e.g. k = H (PINu) or K = (PINu, d) or K = H (D In this case, door D will check that the PIN belongs to user authentication safely during time interval d. For example, it uses PINu to decrypt EUDd and checks that EUDd is a suitable authentication using a key SK that distributes it with certificate A.

Use of answering machine

But how does A transfer EUDd to U's card easily and reliably? We offer to use a responder. This is a device (a server or computer terminal / card reader that can be linked to the server). Preferably, such a transponder need not be skipped or protected. Such protection can add cost and inconvenience to a system that allows the system to work safely without having to secure the transponder. Ideally, certification A performs an update on every date d of the series of days. Each date preferably specifies a time period (eg, one day). For example, d is the date d or the beginning of date d. During update d, A determines which user U is allowed to access through and to D and calculates evidence that can be verified by D with this fact. For example, in a cipher-based distribution key system, this proof becomes the set of EUDds described above and A can be identified as A is used to calculate EUDd since A distributes the key SK with D. All this evidence is then sent to the responder. Such transponders are preferably arranged in convenient locations. For example, in an airport system, responders are located at the airport main entrance. User U then picks up his own authentication from the answering machine to go through door D (e.g., when he reaches work). Preferably, U's card authenticates itself to the responder to receive EUDd. This is very convenient. Because without wireless or other expensive system, the user picks up all the authentications of his mail for every door, at which time he grants the right to experience on a given day from frontal entry (somehow through what he has to pass) and The card reader (eg, to prove that he appeared at work) uses a traditional structure, such as inserting his own card. Thereafter, he is free to move around the airport and can easily pass through all protected doors D, and he has the right to use the certified EUDd he has been picked up. However, due to this convenience and the fact that the responder is unstable, the malicious user also picks up the authentic user's certificate. Thus (1) to prevent this from happening without the security of the responder, and / EH is needed to (2) to ensure that authentication for a true user cannot be used by anyone else. The latter case, as already described, can be sufficiently enforced by having the user enter the PIN at the door, and is preferably securely bound to the authentication released by the card. Thus, a malicious user, V, picking up UD's authenticated EUDd from the responder, cannot impersonate U at the door because it doesn't know U's PIN. The former protection can be enforced by encrypting it with the key SKCU and having certificate A transmit to the responder certificate EUDd after it is known to A. In this way, A posts an encrypted authentication EUDd in the responder that can only be converted to an authentication EUDd by the U's card, making it useless for the malicious V to download another person's authentication for a day. Even if V manufactures his own card in any way he wants, V still doesn't know SKCU.

It is also possible for A to distribute the security key SKU with security key SKD with door D and user U. The PUDd can then be the EUDdk value, which consists of the user U, the statement D, and the date d, as well as everything encrypted with some random secret k, the secret key SKD (by A). In addition, U receives Ek, i.e., k encrypted with the SKU (D and d may be known to U or communicate with U. For example, by the same responder at the main door) Since U knows the SKU, U likewise obtains the secret k. To enter door D, card U sends EUDdk to D. D responds with a random value q and card U then sends Eq. For example, q encrypted using secret k. Statement D decodes Eq and proves that the same q is used. And U is the same as specified in EUDdk, and if date d is current and all checks are confirmed, it will pass U. This structure can integrate the PIN structure as above while making it more secure (in particular, D can calculate and send Eq and send U back to the correct reading q). It also provides security when monitoring communication between doors.

However, the enemy who sees the PIN entered by the user at the door may impersonate U at least during the time interval d if U's card has EUDd in it, after stealing U's card. After that, if U reports his stolen card, A no longer makes EUDd available for U's card.

Private-Key Signature Solution

For example, PUDd becomes a private-key digital signature of a message that specifies both U and d (and possibly D as well) with a private key SK known to both A and D, depending on the installed private key signature algorithm. In particular, if H is to be a one-way hash function, then PUDd = H (SK, U, d). Upon receiving U from the card, the query reader signs U and d with its own private key SK and the result of this calculation matches a series of PUDds obtained from the card. Note that the door reader sending the clock knows what the current date d is and therefore does not need to receive it from the card. This works as long as A allows access for all days in time. In addition, the card also sends d (or selected time interval) to the reader, and the reader digitally signs U and d obtained with SK, checking that the result is exactly the same as PUDd, The current time (according to the clock of the door) is then within d. In that case it opens.

U again asks to enter the PIN as part of the process. In that case, the PIN can also be used as part of U. For example, U consists of u and PIN, where u is a series identifying the user, and the PIN password is known to the user. In this case, the card enters door reader u, and PUDd (and possibly D or d and additional quantities), the user enters the PIN into the door control or reader itself coupled to the reader, and then the reader Reconfigure with = (u PIN), and sign Ud with SK to check that PUDd is obtained. Again, if d is the provided card, it also checks that the current time is within d. This method combines his cards and the user in a harder way. As a result, it is difficult for a thief to steal a card and use it without a proper PIN.

Of course, the same SK can be used for a set of doors, then allowing A to automatically access him all of them by allowing access to U for one of them. Allows the finest granularity of access and each door D has a secret car SKD.

Combination of two approaches

As a combined embodiment of the two approaches, U receives a secret key SKUd for date d from A (eg, using the structure described above, in particular using encryption). He then "proves" with statement D a certificate using his identity and / or private key signature. That is, door D sends random message m to card U in response to sending m's signature-H (m, SKUd). Note that the calculation of this signature requires a PINu. Statement D then verifies the signature. This requires that statement D knows SKUd directly (e.g., receives it directly from A or computes it from other information, e.g. H (SKD, d, U), etc.) Encrypt the SKUd with the key A you distribute and obtain the ESKUd. ESKUd can then be given to U, and then U can send it to D with a signature.

Multiple organizations

As we have seen, organization / authentication A is sufficient to distribute the secret key SKD with statement D to control users U accessing D in a given time interval d. This process can be extended to control access independently through door D or sets of doors D1, D2, D3 to enable multiple organizations A, B, C, ...,. Each organization X distributes the secret key SKXD with statement D and then uses the solutions described above. For example, each tissue X selects SKXD and inserts it into the reader of D. Each Organization X must send a team of one or more employees / workers / contractors / subcontractors from door to door. However, doing so in a facility with many doors is impractical or wasteful. For other organizations have already done so. Thus, with or without authentication, the reader has difficulty storing all these keys. In addition, appropriate precautions should be taken. Otherwise, nothing prevents the thief from inserting his unique secret key into the reader of the query. Then, knowing it, you can use the above method to allow yourself or his colleagues access to the door. For this reason, we propose the following solution. Note that the same method can be applied in a single solution as well.

First solution

As we have seen, a user can pass through a secret door if he or his card breaks a secret key in a given time interval. Thus, users and statements distribute session keys. The Chebero and Needham-Schroeder protocols provide a structure for ensuring that entity pairs distribute secret session keys and can be applied here throughout the system. However, these protocols are based on an on-line key-distribution center and must be contacted whenever a distributed session key is needed. Therefore, we want to suggest an additional and more convenient way. To begin with, to implement a Cerberus / Nedham Schroeder based system, we need a method for central authentication to distribute keys to doors (which is more difficult than distributing keys to other certificates).

We imagine a special certification SA (e.g., airport certification, at an airport) to distribute keys securely to the door reader. Preferably, the SA is the only entity that can do so. For example, the door reader is transmitted and manufactured without any secret key inside, so that once the first set of secret keys (possibly a secret key set) is inserted, the readers store it for a long time and then later store it. To accept any other key. This way, by being the first key (shortly before, during, and after installation) to enter a key value into the door reader, the SA ensures that no one can install the security key into the door. Alternatively, a control PIN or key is needed to store another secret key with the door reader. As the door reader is delivered and manufactured without any control PIN or key, once the first control PIN or key (or possibly their set) is inserted, the reader stores it for a long time and any other control PIN or keys are then allowed I never do that. However, providing the correct control PIN / key is an input, after which any new key can be inserted and stored in the reader. This method is the first to insert any control PIN / key into the door reader (before, during or immediately after installation), so that the SA ensures that nothing else can be inserted into the door reader or store the secret key.

At this point, the SA knows all the security keys of the reader of Door D. For example, SKAD, SKBD, SKCD, etc. Rather than implement Cerberus, it is simpler for SA to provide SKAD to Certification A and SKBD to Certification B. At this point, authentication A / B / ... may control access to the user D by a private key encryption method or a private key signature method. Note that these certificates work independently on different sets of statements. E.g,

1. Door D1 has a secret key SKXD1 inside its reader and SA provides SKXD1 to authentication X.

2. Door D2 has a secret key SKXD2 inside its reader, and SA provides SKYD2 to authentication y.

3. SA does not provide any key to door D1 to Y and no key to door D2 to X.

Authorization X controls access to statement D1, while authorization Y controls statement D2 in a totally independent way.

Better solution

With the above features available, we can improve these systems in some important respects. In other words

Key-Storage Size- While it is desirable for the door reader to store different keys for each different organization that controls it, it raises a number of keys that the reader must store securely.

Addition of new controls-New control issues arise when new authorizations or new statements are introduced into the system. If door D does not store the key for organization X, then it is desirable for X to gain control of D, and the SA must insert the key for X into D's reader. For example, when a new organization emerges, the SA must rush the team of people working to insert SKXD into all doors D that must be controlled by the new organization. Such physical "travel" is such an inconvenience. To avoid that, the SA pre-installs additional keys with the reader of Door D and then binds them to a new organization that generates them or to an organization that must be controlled later by D. This strategy, however, only aggravates the point described in the first bullet. In addition, if a new door is introduced to be controlled by an existing authentication, the SA will have to insert a new key into the door reader and send the appropriate security keys with the existing authentication to control it. Despite that, passing a secret key is always a problem.

Revocation Control-Once the secret key SKXD is stored in Door D and known to Authentication X, X will continue to control access through D, even though certain point control for D is given exclusively to another organization. To avoid this, the SA again belongs to the physical journey and removes SKXD from door D (by means of DP, control PIN / key structure).

How to cause this additional improvement will be described below.

Basic system overview

At the beginning, we can have a system walk that gives a single key per door. For example, the SA stores a single key SKD in door D (and of course follows this information). Such a key can potentially be computed by the SA from the identifier of D and the secret seed s known only to the SA. For example, SKD = H (s, D) as a pseudo-random function with seed SKD evaluated at X. The SA then gives control to D to authentication X by providing X to key SKXD deterministically from SKD and X. (For simplicity, we assume that the entity matches its appropriate identifier.) In particular, we can have SKXD = H (SKD, X). Authentication X then uses SKXD to allow access of user U to D during the time interval (eg daily) d as before. In particular, by using SKXD as a signature key of the private key signature structure, for example, by calculating SKXDUd = H (SKXD, U, d) and SKXDUd to be stored on the card of U. When the card of U communicates with the reader of D, the card provides a reader with possibly other information, such as (a) X and (b) SKXDUd and d (as with information about user U). In receiving this information, in the above embodiment by hashing (U, d) after combining with SKXD, the reader calculates H (SKD, X) and then the same private-key signal structure and sine (U, Use the result (presumed equal to SKXD) as the signature key of d). If the result matches the value intended by the card (inferred, SKXDUd), if the time interval is correct for the reader clock (and if U is entered into a valid PIN, then the PINs are used appropriately in the above system). The door is opened.

Key storage, addition of control

A single key system per door not only minimizes the need for key storage, but greatly simplifies the problem of additional control. When authentication X needs gain for the first time control for statement D, the SA does not need to physically reach D and inserts a new D-X key into D's reader. Rather, if D has a key SKD known to SA, the SA simply computes a DX key from SKD (e.g. SKXD = H (SKD, X)) and passes it to such DX key (e.g. electrically) X. .

Retraction control

For Certificate X, which has the right to control D for each statement D and time interval (eg daily) d ', the SA calculates and makes a signature of this fact available. For example, this signature could be a private-key signature for the key SKD that the SA distributes with statement D. In particular, this signature can be the value D (SKD, valid, X, d '). Despite being a private key signature, the signature itself can be made public without worry. In addition, using the H-based implementation of the private-key signature described above, it is very difficult to calculate SKD from H (SKD, valid, X, d ') when H is a secure unidirectional hash function. Thus, when user U picks up the door-control permission of the date from his card, he picks up H (SKD, valid, X, d ') as well as SKXDUd for door D. The reader of Moon D then checks the SKXDUd as before, additionally ensuring that X has control of D during the interval d 'by certainly hashing with SKD, valid, X and d' to obtain the card. By checking the same value intended, it checks according to its clock that the current time is within d '. In fact, only SA (and D) knows the secret signing key SKD. Certification X knowing only H (SKD, X) and calculating SKD from H (SKD, X) and H (SKD, valid, X, d ') is very difficult. Note that the time intervals d and d 'are not the same. For example, while X allows access through D to a user on a daily basis, SA satisfies allowing control of D with X on a weekend basis. Alternatively, the system replaces the use of SKXD as above with its key: eg, time-dependent version of SKXDd = H (SKD, X, d). The SA must then deliver SKXDd to each authentication X before the time interval d. To control the revocation, the SA simply stops sending SKXDd during interval d, which decides to deny X control for door D.

Also note that the system allows some privacy in that the SA does not need to know their number as well as which user U is given by X as D. The structure can, of course, be achieved by eliminating this privacy (eg using a Cerberus system or reporting).

Example 14

Now let's build our preferred configuration for gaining secure physical access in a system with a super-certified SA, multiple doors (preferably not connected) D, multiple organizations X, and multiple users U. The preferred embodiment minimizes key storage and makes it very easy to add and withdraw control of door D with organization X.

In a preferred embodiment, the SA allows tissue X control for door D in a given time interval. During that interval, X allows access to user U's D by itself.

Design an SA (possibly another player) taking an action on each of a series of dates d corresponding to a series of time intervals. For example, d may be the start of a given day and the corresponding time period of a given day. For simplicity, we use d as meaning both date and corresponding time interval. For the sake of specificity, without any intended limitation, we assume that each date / time interval is a date.

We describe a preferred embodiment using a private key digital signature. It is not intended to be any limitation. Our preferred embodiment should be considered to be implemented with other private keys as described above. In more detail, we assume that the private key signature is implemented using the one-way hash function H. There is no intended limitation, and H (SK, DATA) is always considered a digital signature with the key SK of DATA.

Suppose we divide the secret key SKD with door D. The SA also divides the secret key SKX with organization X. (SKD may be generated by A via master secret key SK. Similar to SKX, for example, SKD may be equal to H (SK, D) and SKX may be equal to H (SK, X)). The SA then provides SKD to D, either personally or via encryption. Similar to X.

At each date d, if the SA wants to allow organization X access to door D, it computes and raises X to receive the secret key SKXDd. It is a key belonging securely to date d which can be proved by X, D, and D (e.g. inputs X and d).

For example, SKXDd = H (SKD, X, d), i.e., SA signs X, d with the key SKD. The SA then causes X to receive SKXDd. The SA allows X to receive SKXDd by sending SKXDd to X, preferably after encrypting it with the security key SKX that distributed X. So far, preferably, the SA sends SKXDd so encrypted with X, such that it is stored in the responder. X from it downloads it after that.

If X wants to allow user U access from time interval t to D within one day, X calculates and causes U to receive the secret key SKXDdUt. It is a key belonging to t that can be identified by X, D, U, and D.

For example, SKXDdUt = H (SKXDd, U, t), ie X signs U, t with key SKXDd and then causes U to receive SKXDdUt. X allows U to receive SKXDdUt by sending SKXDdUt to X. Preferably after encrypting the secret key SKU distributed with U with it. So far, preferably, X sends the encrypted SKXDdUt to U by having it stored in the responder, from which U then downloads it.

If U wants to approach D in time interval t, then U causes D to receive X, U, t (e.g. U's card moves to D's reader).

If D receives X, U, t on date d, it calculates SKXDd from its secret key SKD and then calculates SKXDdUt from SKXDd. D then makes sure that the time interval t is within date d and uses its own clock that surely the current time is within time interval t. In addition, D ensures that it is handled with a U / U 'card by a challenge-response structure by using the key SKXDdUt. If this confirmation passes, D is opened.

For example, D calculates SKXDd from the secret key SKD by calculating H (SKD, X, d) and then calculates SKXDdUt from SKXDd by calculating H (SKXDd, U, t). For example, the challenge-response structure using the key SKXDdUt sends a random string q and receives the encryption of q with SKXDdUt or the digital signature of q with the key SKXDdUT. Alternatively, D sends an encryption of q with Eq, key SKXDdUT and must receive q again.

It should be understood that the preferred structure includes using a PIN consistent with the above. In particular, the PIN usage described in the previous section is used within the preferred structure. Note that the preferred system offers a lot of flexibility in that d and t are different. For example, while X allows access to U of D for a day t within a week d, SA provides control over D with X for a week d. But we have d = t where t does not need to be specified or used separately in the preferred system.

Cerberus approach

Using Cerberus access directly does not work very well with our secure access devices. It is most natural to implement all doors and SAs as one kingdom (for that kingdom, the ticket granting service, the SA acts as the TGS). Each implementation and its employees then separate the kingdom. Each organization's certification then serves as its Kingdom (as its own TGS) certification service, AS. According to the Cerberus protocol, each user is then authenticated with each authentication / AS that obtained a ticket-granted ticket, TGT. This ticket TGT is then sent by the user to SA / TGS in response to a request for a service grant ticket for each statement to which the user belongs. The SA / TGS must then confirm the user's eligibility and if the user is all correct, the user provides this service-granted ticket. This protocol is obviously quite difficult and adds significant burden on the SA. In particular, it is the SA's responsibility to ascertain which statements belong to which users and which tickets are issued. In addition, it requires the SA to be on-line and participate in the protocol in real time. Having the channel to the user by SA also likewise represents an additional security risk.

Cerberus tickets without protocol

In principle, we can "ban" the Cerberus protocol and only use tickets. That is, all tickets can be pre-ordered and pre-computed. Users then pick them up without participating in the appropriate Cerberus protocol for the main door entry time.

However, for many of the above problems, it is natural that the SA removes the control of a particular statement, especially with a special authentication. (However, this control is easily returned, possibly at a later point.)

Use of RTC in Cerberus

One way to help address this problem is to use real-time certificates, RTCs. For example, we can use a ticket as in the above approach. But in this approach, we cannot generate tickets on a daily basis. Instead, we use long-term tickets and manage short-term access control via RTC that is passed in the ticket's authentication-data field.

The RTC can in this case serve in the same way as in the case of a public key certificate. However, some optimizations are likewise possible here.

Using the RTC as above brings a number of possible advantages. These are (but are not limited to)

1. Ease of Management

a. SA should be included relatively aperiodically.

b. Instead of a relatively larger ticket, the user needs to pick up much less RTC.

c. Generating the RTC may be represented by the corresponding authentication.

d. It is easy to withdraw: this can be done in more than one way. First, simpler and more immature, the tickets are not renewed by the SA when they flow out. More detailed structures will use two types of RTC. Issued by a different certificate than that issued by the SA, where each day the SA needs to issue a single RTC for each certificate, which remains (alternatively, it is a certificate-statement pair). For each user will also issue an RTC (alternatively, for each user-door pair, where the user opens the door). Right). Note that more conventional Cerberus access requires more tickets to be generated and passes around within the on-line protocol.

e. RTC allows for clear separation of roles and facilitates the use of many administrative aspects and infrastructures.

2. Efficiency

a. Space: The RTC is much smaller than the corresponding ticket.

b. Time: Because they are much shorter, communication is much faster, allowing the user to move through the door while picking up the RTC at the appropriate pace.

c. Load distribution: RTCs can be distributed by non-secure responders. The response of the RTC is also neither expensive nor dangerous.

3. Security

a. RTC is not security-sensitive. Once they are generated, they are much easier and can be managed without any risk to security.

b. Separation of ticket and authentication (via RTC) allows for greater security in key management (when keys / tickets are actually generated and communicated)

c. SA isolation: The SA never needs to have a direct communication line with the user.

Beyond Cerberus

The above structure is of considerable benefit from the core Cerberus feature (according to the fact that Cerberus is rescued for other devices). So here we develop how we can use RTC-based structures, which are not directly related to Cerberus. These structures can be similar to private key encryption and private key signature structures.

In this structure, the special authentication SAs share a secret with each other's organizations A (B, C, ...) and with each other's door D. This can be done, for example, by using the above method, so that the SA only needs to store a single secret s. The distributed secret between SA and A is SKD = Hash (s, D). Note that both A and D also need to store only one secret: SKA or SKD, respectively. Additionally, with each tissue-door pair (A, D), an additional secret SKAD = Hash (SKD, A) is mapped. This secret can be easily calculated by SK and D. It is necessary to provide SKAD to A, but it is not enough for A to control access by the door. In addition, A is needed to receive the RTC for the current time interval d from the SA. This RTC does not need to be secret, called RTCAd, and proves that A is standing with the SA.

Each user U employed by A and entitled to enter door D then receives a key SKAUD = Hash (SKAD, U) from A. Note that SKAUD can be easily calculated by both A and D without additional secrets. It is necessary to provide SKAUD to U, but not enough to allow U to open door D. In addition, U needs a separate RTC for the current time interval d: RTCAUDd.

Note that this approach already simplifies the flow of information considerably. At the beginning of each time interval d, the SA sends a single RTCAd for each tissue A. Each Organization A sends a single RTCAUDd for each user-door pair. All of these RTCs can be picked up by an employee entering the main gate. Suppose user U has the right to enter 100 doors within a facility. RTCAUDd for all statements will require less than 2KB-the amount that can be managed by a slow link.

To open door D, user U is required to represent RTCAd and RTCAUDd as well as performing authentication based on secret SKAUD (this authentication is a challenge-response type to protect the secret). Note: Since a relatively small number of RTCAd certificates will be represented in the system, the validity of these certificates need not be done on a per-user basis. Instead, each statement will validate each RTCAd, which receives and stores the results for use by other users.

The particular authority SA wants to implement finer granular control of the organization's access to the door. Instead of an organization proof RTCAd to obtain such, the SA issues an RTC for each tissue statement pair (A, D): RTCADd. It is then possible to allow the SA to control revocation of each statement by each organization on the basis of the mail. Note that this is at least double the amount of RTC data that each user needs to receive (while maintaining the transition time required for the above embodiment in a few minutes).

RTC Collection

You will observe that access control rights do not change dramatically from day to day. Therefore, much of the above structure is not utilized. We propose an RTC collection structure, which can be used in a relatively stable environment to increase efficiency.

Example 15:

Consider the case of 100 organizations, each with access to 1000 doors. Thus there are 100,000 tissue-door pairs, whereby an RTCADd certificate is issued and distributed by the SA every day. Moreover, if each organization employs about 1,000 people, this leads to 100 million RTCAUDd certificates being issued and distributed by all organizations.

All Organization-User-Contact Triplets Let's divide the AUD's into hierarchically arranged groups. For example, it is easy to visualize this: Let's map every AUD to the mouth of a balanced binary tree (arranged in the preferred type). Each node n in the tree then corresponds to a set of things corresponding to the mouth of the AUD in the subtree of n. With each such node and time interval d, let the three corresponding ones also be certificate RTCnd. The validity of the AUD triplet in period d can then be proved by certificate RTCnd for the ones of AUD ancestors n. Thus, if all AUD triplets remain valid on date d, a single certificate RTCr is sufficient for the entire system. R is the root of the tree.

In general, if there are 100 AUD triplets that are fragile, at least 1,500 certificates are sufficient to prove the whole system (ie instead of 100,000,000). More generally, at least k (26-1g k) certificates are useful for k triplets. If not, it is necessary for a certificate of the whole system.

This method can lead to significant improvements when the needs of the aggregate RTC are more valuable to be stored in the door and / or user. In the above embodiment, such overhead results in more than 26 overhead elements in the storage device while storing the dimension of size (4 or 5 in the above embodiment) in communication. More generally, the set of all entities to be authenticated contains N components, and k of this is excluded. And while the overhead for aggregation is lgN, k (lgN-lgk) proofs are needed to prove the whole system. More efficient representations of groups exist in the literature (eg, while the above is known as the subset cover method, we also use subset-difference cover and some of the recent results on it).

Thus, the validity of such aggregate certificates is optimized. For example, by storing the results for a larger group.

RTC implementation and optimization

Many other implementations for real time certificates are possible. These implementations of RTC also enable many other optimizations. For example, a real-time certificate can be implemented as follows. Let X0 be any value, for example 20 bytes long. Let Xi be defined as xi = Hash (xi). Let xn be a fixed public value in some cases (eg secure communication from SA to door D. where x _nd can be a real-time certificate RTCd for time interval d. Can be verified by applying d times to x _nd and proves that the result is equal to xn, which is actually how RTC's are implemented in the case of public key certificates-for example, xn as part of a certificate This may be included.

Here, the same implementation can be used substantially as well. Instead of including xn inside the certificate, here we include it as part of the Kerberos ticket. We communicate it by some other security method, such as encrypting it with the secret key SKD for D.

Another possible implementation of RTCd is just to set it equal to Hash (SKD, RTC, d), where RTC refers to the certificate ID. For example, to enable organization A to have control over door D on dated, the certificate RTCADd is used, where RTCADd can be set to RTCADd = Hash (SKAD, d). The certificate for user U to access door D on date d, such as issued by organization A, can be RTCAUDd = Hash (SKAD, U, d). Such a method first permits the certificate to be issued in advance on a particular date, does not allow access on any day, and is outside the desired time interval. (Even if this is not continuous)

The validity of the above certificate is straightforward. Note that the above justifications are actually symmetric signatures with appropriate keys. Throughout the above, encryption is used instead of Hash.

Note that we make the system more efficient at each step. Consider an airport with 1000 different, 100 certified and 10000 possible workers and for simplicity assume that the control is given on the basis of mail. Then, the Cerberus / Nidham-Schroeder system should be included in the 1 billion secret keys per day where central authentication is included in being calculated at each door-user key. The system described above is required for SAs to be generated and delivered with every authentication less than 100,000 secret keys per day.

Real time certificate for OCSP

We now describe using a preferred embodiment of the present invention for real-time certificate technology in an environment using Open Certificate Status Protocol (OCSP) for digital certificate validity. This demonstrates how the technology maintains compliance with the OCSP standard while the inventive technology provides a property that is significantly better in security and scaling than a conventional OCSP implementation.

Traditional OCSP Implementation

CRLs provide evidence of revocation of many of the certificates they have been put together. In contrast, the OCSP provides evidence of justification for individual certificates. OCSP services are primarily implemented by OCSP responders. Such a responder provides a digitally signed answer indicating both the time to answer and the status of the certificate, based on receiving a question from a client regarding the validity of a given certificate issued by a given CA. To do this, the OCSP responder needs to know the status of both CA certificates. This is because the CA can revoke its own certificate. If the OCSP responder is the CA itself, such knowledge is trivially required. Otherwise, another form of maintaining an updated OCSP responder on the status of the CA's certificate should be used. For example, the CA sends the responder to its most recent CRL, and the responder refers to the signed document to derive whether the associated certificate was recently valid or revoked, or is said to be in its signed response. It also displays the time, just like the next update time (where it is common for the update time to match the date of the CA's next CRL, because that CRL generates a different response).

Of course, the malicious responders provide arbitrarily signed answers to the certificate of the given CA without or with reference to the latter CRL. In order to rely on the OCSP responder's digitally signed answer to a given CA's certificate, the OCSP envisions that the CA provides a responder with a responder certificate, and a special digital certificate signed by the CA is essentially a CA. It is provided to other parties in order to trust in providing accurate proofs of their certificates.

Note that in this process for work, each OCSP responder must have a security signature key that must be protected.

2 shows a series of transactions in a trivial OCSP environment. The fact that the security signature keys are protected is graphically emphasized by placing them with some thick "border". In the case of signed data, the name of the signer is immediately displayed below. This form shows the various PKI-sensitive components of this transaction, such as the hatched box. The certificate authentication itself has a private key, SK1, which must be secured to prevent unauthorized authentication and revocation of the certificate. This key is used to sign the CRL issued to the OCSP responder. The security key of the responder 1A must be kept secure and is used to sign the OCSP response of the responder 1A.

OCSP Drawbacks

Defect 1: calculation

Digital signatures are computationally strong operations. The digital signature generated by the responder in each response is generated at the time of the request and is mostly computationally intensive part of the justification operation. It can be easily added anywhere from 50 milliseconds to 1 second for trading time.

If the responder stores its digital signature for digital certificate C, it sends the same signature when asked for C until the next update, and still delays the answer to the first user question for C significantly.

Defect 2: Communication (with Centralized Implementation)

Suppose a single legitimate server implements OCSP in a centralized way. At that time, all proof-justification questions must be ordered with it, and the server will be a major "network traffic congestion" causing significant congestion and delay as shown in FIG. If a large number of honest users suddenly ask the server, "denial of service" will continue to happen.

Defect 3: Security (for distributed configuration)

To avoid traffic problems caused by a centralized OCSP implementation, the CA considers distributing the request load generated by its certificate by distributing it to multiple OCSP servers. In general, it distributes the load of a single server across multiple servers and strategically deploys them around the world to reduce network congestion. In the OCSP case, however, load distribution introduces a worse problem than it can solve. To sign its response to the certificate questions it receives, each of the 100 servers has its own security signature key. Therefore, any 100 servers must compromise the entire system effectively.

If a conventional OCSP responder is compromised, the attacker can do one of three things. First, it can prevent the responder from issuing any response. This type of attack is detected in a trust meeting. So it's not too harsh. Secondly, it can use the found security signature key to sign the response indicating that the appropriate certificates have been revoked. Third, most destructively, it can cause the responder to generate signed responses indicating that the revoked certificate is still valid. This type of erroneous-positive response allows those who are dismissed to regain access to the system.

The best way to prevent what a transponder can contain is to run it from a secure vault with 24 * 7 surveillance. Unfortunately, this is an expensive choice. In fact, security vaults cost more than $ 1M / year for operation and more than $ 1M for installation, meeting all the requirements for an economical CA. Even if the intention is to incur such a cost, the vault cannot be built overnight. This is because reinforced concrete does not sell. Required Cark When you need some vault to reduce the load on the current transponder, you have to wait a few days before a new one can be constructed.

Moreover, even if a large number of expensive vaults are placed, they are still not secure. Thus, the OCSP structure is because the responder receives requests from untrusted sources and uses its security signature key. This possibility thus exists where a malicious agent prefers to exploit any weaknesses in the operating system on which the malicious agent lies and exposes the security signature key to drill at night through reinforced-concrete walls. In total, if there is no rounded or sufficiently expensive secure peripheral responder, the probability of the agreement is very high, but even for securely equipped secure building responders, the responder is still vulnerable to software attacks. For sophisticated digital enemies, the OCSP structure creates a vault in the "window" that closely resembles a bunker.

Defect 4: Trust Flow

OCSP has difficulty in servicing certificate legitimacy requests arising from other security domains. In the scenario shown in FIG. 4, the responder executed by organization # 1 may provide a response regarding the status of the certificate from CA # 1 while a responder executed by another organization may provide a response regarding the "foreign" certificate. It doesn't have enough information to do it. For example, responder 2A, executed by certificate certificate CA2, does not know how to respond to a request for a certificate with CA1.

This problem resulting from the lack of specific knowledge can be addressed in one of two ways.

First, relying on a party from organization # 2 may find a responder from organization # 1 to ask them about the status of the certificate from CA # 1. This limits performance, and the responders from organization # 1 are geographically separated from the trust party associated with organization # 2. Therefore, network times slow down the entire attestation process.

The second alternative allows creating a response to a certificate from Organization # 1 by having CA # 1 forwarding its CRL to "foreign" responders as well. It also does not pose any security risk. Because the CRLs are digitally signed and the CA wants to inform the largest possible audience about the validity of its own certificate. This provides enough information to the responder of Organization # 2 to respond to requests from a trust meeting on CA 1's certificate. But for trust meetings, digitally signed answers are very serious. CA1 must also validate Responder 2A to answer the validity questions for its own certificate. The entire process is shown in FIG.

This approach provides better scaling and performance, but it blurs the trust flow and security between the two organizations. In the above embodiment, responder # 2A is making an authenticated response to a trust meeting in which certificate # 321 of CA # 1 is still valid. Giving an incorrect response for any reason causes responder 2A to reverse the order from users from organization # 1. By allowing Responder # 2A to make an authenticated request for its own certificate, Organization # 1 gives up some of the previously held trust.

As an example, consider the case where the organization is a trust card issuer. Bank # 1 revokes the card certificate for user # 321 and it pays for its responders to be secure and reliable. Responders from bank # 2 are misunderstood, so when the trust meeting merchant asks for the validity of user # 321, they incorrectly reply that the user is valid. The merchant accepts this answer and allows the transaction to proceed for the withdrawn user.

This type of trust-representation between organizations may be acceptable in some cases, but it is generally not a useful alternative for large-scale heterogeneous deployment of conventional OCSP.

Real time certificate for OCSP

In view of the above problems, we want to propose an alternative certificate justification system. While maintaining compatibility with current OCSP standards, Real-Time Certificates (RTC) solve all of the described drawbacks of conventional OCSP. RTC technology differs from conventional OCSP in that respect.

1. It is not representative trust in an outpatient responder.

2. It focuses all justified trusts into a single certificate (RTC certificate).

3. It distributes the question load from a single authentication for an arbitrary number of unexpected responders.

4. It does not even reduce security in distributed implementations that rely on thousands of responders (and even if these responders are not protected).

5. It dramatically improves the response time to questions.

This provides a fundamental increase over conventional OCSPs in terms of security, performance, scaling, and heterogeneity.

The RTC system includes the following steps.

The CA verifies the RTCA. The new system is centered around RTC certification (RTCA). This is an entity that matches or does not match the CA of a given organization. Preferably, each CA provides its own RTC, RTCA certificate with a special certificate. The CA preferably digitally signs this certificate, empowers the RTCA to trust and further provide certificate justification information for its own certificate. Such a certificate makes a given certificate key PK belong to RTC authentication and in some cases specifies that the certificate actually grants RTC status and includes other customary certificate information and formats. In this case, it is still advantageous for the en entities to match, and they have separate signature keys. As a result, effectively, in either case, the CA only issues certificates and RTC certificates only manage them. This means that even if the CA and RTCA match, the RTCA certificate is still used. Preferably, despite the redundant purpose, each CA is advantageous to have only one RTC and to have more than one, whether using the same signature key or not.

RTCA protects its signing key. For example, by vaults or security provisions (as we will see, but no need for any additional vaults for certificate justification purposes), the RTCA shall protect its signing key. The RTCA hosts one or more servers, each hosted in the same facility protected by one or more servers embedded with its security signature key, securely storing a copy of the key, or each having a security signature key properly certified by the CA. .

The CA announces the RTCA of its certificate status. For example, on some changes in certificate validity in the on-line / real-time type it is evaluated. Alternatively, it sends its CRL to the RTCA when it occurs (such as sending a message indicating the RTCA of a change in certificate status as soon as it occurs).

The RTCA individually signs the validity status of each certificate irrespective of the request in a given time interval. -Preferably, periodically (or at any one of a series of dates), the RTCA, based on current justification knowledge (eg based on the CA's recent CRL) and independent of any trust meeting requests, processes the outstanding certificate of its CA and And digitally sign a declaration stating the status of the certificate. The result thus carries a time component indicating the next update for that certificate. If the RTC cycle depends on CA-issued CRLs, the update time is that of the next CRL. The time component also indicates the issue time of the CRL used in the process. In essence, the RTCA thus precomputes a digital signature that indicates the status of each certificate in a given time interval T. (Eg, if sufficient time is allowed from processing all the necessary information, from the time of the last CRL or close enough to the date of the next CRL or to the date closest to it). Such pre-calculation is performed independently of the trust meeting request for a certificate. In addition, preferably, the RTCA pre-calculates all such signed declarations of the certificate status before any question about the status of the certificate in the time interval before every time interval is made. In particular, the RTCA pre-processes all its signed sources with respect to time interval R before starting T. The fact of doing it so that it is not "synchronized" with the CRL is not very serious. The CRL itself is not real time, but is information about certificate revocation, and therefore there is a reason that it takes quite a long time for a certificate to be revoked. For example, a user may have been compromised that his security key has been compromised so that after his fact his unique certificate is revoked. In either case, therefore, the certificate is withdrawn with a delay of one day. Preferably, the signed RTCA declaration of certificate justification is in a standard OCSP format. That is, in essence, the RTCA preferably precomputes an OCSP-compliant response to an OCSP request that has not yet occurred. This is important because the OCSP software has already been deployed, and it is very convenient to use the RTC system without modifying existing trust group software.

The RTCA sends its pre-processed signature of validity to the unprotected responder. After such a signature is pre-processed, the RTCA makes it available to other meetings, which includes trust meetings. These responders do not need to be protected. In fact, they process RTCA-signed messages, and these cannot be modified or altered by tricking them in ways that are essentially undetectable. In addition, the RTCA easily sends them to foreign responders with dangerous security. The RTCA facilitates responder processing of its signature by representing them as responders in a suitably organized type. For example, it may represent a signed certificate authentication status arranged according to a certificate side number, or ensure that the signed portion of the data in the array or data is equally of equally closed length, and so forth. To ensure that all relatively pre-computed responses are received, the RTCA signs and meets all of its responses (eg everything for the same time interval and CA).

In addition, the RTCA preferably sends its own RTCA certificate to its responder. This transfer does not have to occur on every update. In particular it can only be carried out initially.

Responders store the RTCA-pre-processed signature. The responder stores the received pre-processed signature of the RTCA for a sufficient time. Preferably, if these signatures are associated with a given time interval T, they store them until the end of T. Also preferably, the responders are pro-active and check that they have received the appropriate RTCA signature correctly and on time. For example, the responder

(1) Confirm that a pre-processed response to time interval T is received at the beginning of T (or other suitable time related T).

(2) Verify received RTCA signatures (and also have a suitable RTCA certificate available)

(3) Verify that it has received all signatures (e.g. less than the expected number of signatures, less than the last transmission, etc.)

(4) Verify that it receives an RTCA-declared declaration of justification for a certificate previously declared to be revoked.

If no problem is detected, it informs the RTCA or another suitable entity.

The trust meeting asks the responder for justification status information: The trust meeting asks the respondent for the justification status of the certificate. Preferably, they use the OCSP format for their request.

Respondents answer questions with pre-computed answers. When questioning the validity of a given certificate, the responder derives an RTCA pre-processed answer from memory to prove and return it.

The responder also forwards the appropriate certificate for the RTCA that signed the pre-computed response.

Trust meetings confirm pre-processed answers (and RTCA credentials). The trust meeting receives a response to confirm the validity of the status of the relevant proof. Preferably, if the response is in OCSP format, they use OCSP software for such processing. Preferably they identify the appropriate RTCA certificate.

Through this application, it is understood that certificates become hierarchical certificates, evidence of the recent validity of the CA, and that CRTA certificates are added and justified whenever necessary.

6 shows an RTC system.

Advantages of RTC Systems

The RTCA periodically generates digitally signed validity declarations for all current certificates of the CA and then distributes them to relevant responders. (Each evidence is preferably constructed as a syntactically correct OCSP response, preferably in the RTCA private key. When a trust meeting asks about the status of a certificate, the RTC responder may go back to the corresponding pre-generated response in which it is stored. The trust group can verify the signature of the RTCA (in addition, it can also verify the certificate of the RTCA to ensure that it is handled with the real RTC signature for a given CA. Of course, all other Certificates can be hierarchical.)

Advantage 1: Calculation

Digital signatures are computationally powerful operations. However, the RTC system concentrates this difficulty on a single server (entity): RTCA. It is therefore relatively inexpensive to be equipped with a single entity that is very easy and powerful enough to handle all the required digital signatures. In contrast, the RTC responder performs only minor calculations. They actually (1) store the RTCA signature and (2) perform only extraction and forwarding operations on trust meeting questions, so they can be implemented with very cheap hardware. As a result, the overall RTC price is significantly lower than OCSP. At the same time, the response time is much faster. Thus, the time for a very cheap RTC responder to extract and send a precalculated RTCA response is relatively neglected to be taken by an OCSP responder that only has to perform a digital signature in response to a trust meeting request.

Advantage 2: Communication

In RTC systems, the responders use minor hardware and do not need to be secured. As a result, RTC responders are really very cheap and many are available. That is, there is always room to provide a distributed implementation of the RTC system. Thus, even if a large number of certificate-justification requests occur in a short period of time, this load can always be deployed for many RTC responders, eliminating the tender denial of service without the risk of congestion and high price. That is, the amount of work in the RTCA depends only on the number of certificates and it is not affected by the number of validity-state requests, so a single RCA can be used even if millions of justification requests are expected.)

Advantage 3: security

In an RTC system, only the RTCA (except for the CA, if it is another / differently located entity) is protected. In fact, responders do not need to store any security keys. They only need to store the digital signature of the RTCA, but above all, it is made public as a whole after the security objectives have been calculated by the RTCA. In contrast, each OCSP responder has a security signature key, one of which covers the entire system. Thus, keeping a single site is desirable and easier than keeping many equally important sites.

In addition, unlike in OCSP, trust meetings cannot be easily escalated into software attacks. In fact, the RTC responder serves the request of a trust meeting with non-secure information. In fact, they do not need to have any security keys of their own, only a pre-processed digital signature. So if a trust group succeeds in embedding some sort of trojan hose in the question of one, it can expose any. At best it can reveal what all RTC responders know and it is a precise calculation that is full, the certificate is valid and is withdrawn in a given time interval. And this is not only non-secure information, it is even information that certificate authentication wants to be known worldwide, and as a result no one incorrectly relies on one of its certificates.

Finally, note that software attacks cannot be easily mounted against RTCA. In fact, despite processing a secret signing key, the RTCA is not a processing request from an untrusted source. This is therefore because the RTCA does not answer any untrusted request, it simply receives input from a CA (a very trusted source) and periodically outputs data (signed justification statements). Therefore, the ability to inject the missing trojan hose from the RTC system! In other words, not only is a single vault sufficient for an RTC system, but this vault does not have a "anything" window.

Advantage 4: trust flow

In addition to these advantages, the RTC-OCSP approach allows for significant stretching within heterogeneous PKI deployments that enclose multiple tissues. The following diagram shows how the RTC-OCSP is deployed in a cross-CA environment.

FIG. 7 may replace (preferably, OCSP compliant) responses from Organization # 1 without the need to transfer trust from Organization # 1 to Organization # 2's responders. Because RTC responders are simple, unreliable relays of information, they are widely distributed and reflected without reducing overall system security. The trust meeting queries the Organization 2 (Responder 2B) Responder for the validity of the Certificate in Organization # 1. Note (preferably OCSP compliant), the response to get it back is assured. Because it is digitally signed by Organization # 1's RTCA. In addition, direct signatures from legitimate organizations (optimally placed to know if its unique certificate is still valid, and with the greatest interest to avoid making mistakes) should preferably indicate that the trust group is also the appropriate RTC certificate of Organization 1 Have a certificate of assurance RTCA1.

In summary, organization # 1 enables the responder of organization # 2 to provide evidence of justification for the organization # 1 certificate without giving up the amount of control over the justification status of its own certificate.

Advantage 5: Security Heterogeneity

FIG. 7 illustrates the last case, where responders are treated as transparent network infrastructure rather than enhanced trust points. It shows how the last case of the RTC enables a secure configuration of multiple heterogeneous responders capable of requesting service regarding the status of a certificate from many sources. This is similar to the service cloud provided by the Internet infrastructure. In that regard, a heterogeneous collection of transparent and interoperable name servers allows to find and store cache valid responses for questions.

This heterogeneity is a significant advantage of RTC systems over conventional OCSP. It allows a wide variety of organizations to interoperate so that trust meetings from other organizations can cross-justify certificates from other organizations in a secure, trusting, and efficient manner.

Real-time Certificate (RTC) is a cost-effective, secure, proportional and overall efficient certificate justification system. The RTC is optionally provided for (1) Open Certificate Status Protocol (OCSP), and (2) works within and enhances OCSP. RTC systems, in fact, provide significant advantages over OCSP to provide superior security and proportional reduction in nature, even when making choices to maintain compatibility with OCSP standards.

RTC optimization

2-Meet vs 3-Meeting Justification

Let U be a group with certificate Cu. As part of a transaction with G, U sends Cu to V (otherwise V already has it) and possibly performs additional work (for a public certificate key that is proven in Cu belonging to U). Displaying a digital signature, or identifying it by decrypting any challenge encrypted by V using a public cryptographic key that is proven in a Cu belonging to U.) For transactions that must be secured, V is sure of Cu's current legitimacy. And asks the justification question with the RTC responder. The responder answers this question by extracting and reverting the most recent RTCA-signature declaration for Cu. However, making a 3-party deal or asking a RTC responder that otherwise becomes a 2-party adds time to the desired U-V transaction.

Thanks to the predictable time intervals, the RTC is quite helpful. That is, the meeting U receives an RTCA-signature declaration Du that Cu is valid through T at the beginning of (or during) each time interval T. U can either receive Du in answering the request with his (eg, by making a routine trust-request) or become a pushed Du (for example, to the RTCA in daily updates on an automatic basis). Or by an RTC responder). In both cases, in trading with V during interval T, U forwards Du to V. In addition, all other steps or tasks are involved in the transaction. Therefore, U-V trading is quite fast. Because V does not need to call any third party to verify the current validity of U's certificate.

Nevertheless, in some cases, the "total time" including U, which includes Du, is not accelerated. There will be a U-V deal. Note that it is still very worthwhile to speed up only U-V transactions without saving the whole time. In fact, it is assumed that RTCA declarations are processed in the afternoon and materialize the entire day as their time period. U then forwards it to V during the time sensitive U-V transaction performed during the next working day when it is not essential to obtain Du and save time early during the day (when no actual pressure exists). In addition, efficiency is gained if the DU is acquired and stored and then forwarded it throughout the day when trading with multiple (eg, 100) meetings. This way, for example, a single trust-meeting question (U itself, possibly made at rest) successfully replaces 100 trust-meeting requests (possibly in time of pressure).

This optimization can also be obtained by meeting V. That is, after obtaining the response Du from the RTC responder in returning to the question of the validity of the certificate Cu of the meeting U, V can either give U or make Du available to others.

This adaptation mainly applies to the OCSP-compliant implementation of the preferred RTC. In fact, we propose to apply similar optimizations to conventional OCSP implementations as well. That is, the user requests or obtains an OCSP response to his own certificate and then forwards this OCSP response as part of his transaction to another meeting of the transaction for the appropriate time period. Alternatively, when requesting the first time by the trust meeting for the justification of the certificate Cu of meeting U, the OCSP responder calculates its response Ru and returns it to the trust meeting asking it and also forwards it to U. As a result U can store it and for a while, can forward it as part of its transaction based on Cu.

Certificate-Help Justification

The RTC system is implemented using data found in individual certificates and stores additional certificates and / or response lengths. As we have seen, the CA issues an RTCA certificate that authorizes a given RTCA to provide an authoritative answer regarding its own certificate validity. Such an RTCA certificate ideally specifies a public key that should be used to verify the RTCA-signed response. The CA, however, inserts into the RTCA public key within its own certificate. That is, the CA (OID, with appropriate format, etc.) also includes in the certificate Cu a public key PK that should be used to verify the digitally signed response regarding Cu's legitimacy. In this way, trust meetings do not need to receive separate RTCA certificates. When requesting an RTC responder with recent evidence of justification for Cu, it only obtains an RTCA-signed response. In fact, Cu embodies itself within the public justification key to confirm the evidence of justification for Cu. This is true for transmission (because the RTC responder does not need to send a separate RTCA certificate, which is much longer than the RTCA response) and for storage (because the trust group protects against future needs that rely on Cu). This is because there is no need to store RTCA certificates along the side with the RTCA response.

Similarly, the certificate Cu specifies its own time period. In this case, the RTCA response does not need to specify the beginning and end of the interval T. virtually. Starting along T alone (or other simplified implementation) clearly defines T. For example, if Cu specifies a daily update, it is sufficient to specify the whole day to any time on a given day or where the response is involved. Alternatively, if it is clear that the certificate has a justification interval that constitutes the whole day, this information need not be specified in the certificate, as is storage in the application of the RTCA response.

Detached retraction

While the RTC proof of justification or the reservation for a given certificate C specifies the time interval it refers to, the proof of revocation does not need to specify any time interval. That is enough to materialize a single point in time. In contrast to legitimacy and reservation, withdrawal is, in fact, a process that cannot be traditionally abolished. Thus, a single withdrawal time rt is sufficient to provide a revoked certificate. And rt need not be the beginning of a time interval T (eg any time in the "center of T"). In the case of a permanent withdrawal, the RTCA does not need to send proof of revocation of C on all update dates (eg D1, D2, etc.). In principle, the withdrawal evidence can only be sent once (or a few times for redundancy) and then stored by the RTC responder and returned only when a trust-meeting question about C is raised.

Also note that the RTCA immediately informs you that Certificate C has been withdrawn. For example, within a time interval T where an RTCA has already been generated and proof of justification for C is submitted to the RTC responder. Of course, with the next update, any evidence of such justification will be processed for C. But for the time being (for example, to the end of T), there is inaccurate evidence of justification. A good counter-measurement therefore consists of evidence of retraction which takes precedence over evidence of justification. That is, an honest trust group that sees both proof of justification for C for proof of revocation for some time intervals T and C considers C to be withdrawn (after time t). However, some trust groups never see such evidence, and C is still considered valid until the end of T. As we have seen, such problems can be avoided to some extent, and in the sense of conventional OCSP, news of C retraction takes some time to reach a responder. And it does not take longer to realize that C has been withdrawn. Nevertheless, these problems can be alleviated by having an RTCA, and as soon as it learns that it has been withdrawn, it processes the C withdrawal evidence and sends it to the RTC responder. A properly functioning RTC responder then erases any evidence of C's legitimacy from memory and replaces it with received new evidence of revocation. In this way, they will provide a trust meeting with accurate evidence of C's legitimacy.

System generality

The CA / RTCA / Responder / Meeting / User becomes an entity set or entity.

Certificates should be constructed to include all kinds of certificates, especially hierarchical certificates and flat certificates (US Patent No. 5,420,927, incorporated herein by reference). Evidence of justification and justification includes evidence of justification and justification for hierarchical certificates (eg evidence of justification and justification of all justifications within a set of justifications). Verifying the validity of Certificate C means verifying the validity of the CA Certificate for the CA with the issued C, just as the CRTA Certificate is justified for the RTCA for which the CRTA provides a signed response to the justification status of C. Include.

Although the certificate has traditionally bound a given key to a given user in accordance with US Patent No. 5,666,416, the certificate must include all digitally signed documents. For example, a provider acting like a CA verifies its price list by digitally signing it (possibly with date information). The justification of such a certificate is also very important. For example, a supplier wants to prove the current justification of a price list (reject the price given in the price list unless evidence of its current justification is shown). The consumer therefore wants to confirm the current justification of the price list document. In particular, the RTC system is ideal for providing the current justification of a web page (because of its proportional shrinkability and off-line processing). Besides. The generated RTCA evidence of current legitimacy is stored next (or related) on the next page itself (in this case, the meeting can be considered a computer file).

Sending the price of the data D (to the meeting X) should be interpreted to include making D available (or having X receive D).

3 factor authentication with real-time justification

The following is an efficient three-factor authentication with real-time justification and revocation that is performed without any connection to the infrastructure in trust meetings. This may work for statements such as file or application access or for physical access applications such as logical applications. Physical access scenarios are described below. Other applications are likely to be generalized from this model for those skilled in the art.

Example 16:

1. The user has a certificate stored on the wireless device (physical token). This token preferably has the ability to store digital certificates and private keys. Also preferably, the token has a method of long-range (WAN) connectivity (such as GPRS, SMS, pager, CDMA, GSM, etc.) and short range (PAN) connectivity (such as Bluetooth, IT, RF, etc.). The token also has one or more additional authentication elements (keypad or biological feature reader for a PIN). This embodiment assumes that the token is a Bluetooth cell phone.

2. The door has a control panel with a small CPU capable of standard PKI operation and a short-range (PAN) connectivity method for talking to physical tokens. This embodiment assumes a Bluetooth-enabled computer similar to our standard demo statement.

3. The user quickly enters the PIN number into her cell phone (or input his own biological information if a biometric reader is available). This swiftness can occur once a day, for the first time the user tries through the door, and every hour, based on the receipt of a special SMS message arbitrarily. The PIN (or biological measurement) acts as a second element of authentication (first being a certificate on the phone) and as "unlocked" the phone for use in physical access applications.

4. Once the user is within the range of the door (30ft for Bluetooth), the phone and the door recognize each other and start the initial authentication and justification sequence.

4.1 (Optional) The door justifies itself to the phone by sending the inquiry certificate to the phone via Bluetooth. The phone checks the certificate and justifies the statement using any of our standard methods (min-CRL is a good approach for all doors sent down the phone periodically). This solves the problem of "evil readers" and ensures that the door is a suitable reader before the phone contains any information.

4.2 The phone sends the user's certificate containing the user's biological minutiae to the door. The phone also sends RTC evidence (preferably justification-token, eg 20 bytes of justification or distributed OCSP proof) to prove its current justification. This evidence is disclosed in U.S. Patent No. As previously described in 5,666,416, "Certificate Revocation System," it was previously received over the WAN in a common CoreStreet method.

4.3 A statement authenticates and justifies a user's certificate in a common RTC type. The door does this for multiple (or even whole) phones in range (many employees are near the door).

5. As the user reaches the door, the previous steps are completed. The user scans her fingerprint (or other biological feature) on a reader mounted near or on the door (perhaps in a substantial door handle). The statement matches the biological minutiae for the data stored in all justified certificates within range. If the biological characteristics match, the door is opened. Otherwise the door stays closed.

This has the following advantages.

1. Strong authentication (three elements in this embodiment, more is possible)

2. Transparent to the user (no need for any card or PIN number just remember to walk to the door and open it).

3. Real time withdrawal and justification

4. There is no connection infrastructure required for the door. You can do this in the middle of the ocean or at 30,000 feet.

5. Can be installed with standard hardware and software components.

Step 4.1 is an independent invention of independent interest. It is because it solves a known problem where there is no current known solution (eg identified by the defense). The structure is augmented by having proof of travel or request for access to and / or from other people's cards / telephones with unconnected doors.

Protection of Moving Compute Resources

The preferred embodiment of the invention is based on 20 bytes, indelible, public "evidence". The 20-byte evidence is cryptographically protected using a one-way function called hashing. The process is simple, does not require a password, and does not use digital signatures. This feature makes this technology ideal for large scale deployments, bandwidth constrained applications (e.g. wireless applications), offline validation (e.g. no network connection is required).

Laptop theft may include replacement prices, loss of production, irreversible loss (non-backed up) data, sensitive / confidential data (e.g., sensitive optional information, suggestions to clients, emails, calendars, contacts, pending mergers, Loss of control over new commodity IPs, strategies and launch plans, economic operational results, personal compensation information, etc., and loss of network and infrastructure details (e.g. username and password, dial-in number, IP address) Structure, DNS name rally, and major mail servers) is a serious problem.

In one embodiment, the invention provides for lease. That is, a license for use during a specified time interval. At this time, the interval of the lease is a variable that can be implemented. The techniques of this invention force the presence of a valid "rent". A lease is a 20-byte, indelible, "public token": a valid token, a suspension token, and a retraction token. New leases are automatically received. The computer will not work temporarily and the system administrator EH will not allow the user to stop the laptop. The computer becomes permanently useless with the possible recovery by the system administrator. 8 is a structural diagram of system operation in accordance with one embodiment of the present invention.

While the device is still authenticated, a valid lease token is generated once per day (time, week, etc.) by central authentication. Having a valid lease token as a protected device can be performed in many different ways and is completely transparent to the end user. If the device is stolen, two things happen. Stops generating valid lease tokens. The withdrawal token is propagated to the network (immediately unavailable connection reader device). Stolen devices are turned off. Seconds (in the best case, with push capability), time (in average, as soon as a network connection is made), and day (in the worst case, no connection is possible)

The system protects against any theft as if stolen by an insider. Stolen your device is meaningless. This is because hardware is not available, software is not used, and data cannot be read. Similar to some card radio brands, it is not available if stolen, thus giving up theft.

Validity tokens are transmitted in the following way. Wired network, wireless network, SMS wireless "push", pager system, PDA via handheld phone / infrared port, Bluetooth device, passively received via alternative channel (eg "7G9L TC77 U8QL S2PS QK2Q EN9V PXXH" XPUL "), such as by fax, email or phone. 9 is a structural diagram of a stolen computer schedule.

Alternative protection methods are used, including the following. Physical anchor for prevention, asset trail service for recovery and dismissal, motion sensor, motion sensor and warning as disclaimer, access key as disclaimer, and software tracking for access control, disclaimer and recovery, and data encryption to protect data to be. Possible attacks and consequences

Removing / Surrounding the Software: Having "Administrative Privileges" But very difficult after revocation. Optional BIOS / hardware countermeasures provide nearly 100% security.

Replace / Rebuild Hard Drive: All secure data is lost and optional BIPS / Hardware hooks to prevent drive replacement.

Moving the hard drive to another machine for reading data: The data can be encrypted.

Prevent receipt of withdrawal tokens: Extend laptop operation until the end of the lease.

Claims (21)

A method for entity A for controlling the access of one or more users U to one or more unconnected doors D with means for determining the current time, For each time interval d of a series of dates, A produces a digital signature SIGUDd, indicating that user U can access door D during time interval d, Receive a SIGUDd during time interval d for representation by statement D so that U passes through D, U causes S to represent SIGHDd in statement D, and (I) SIGUDd is a digital signature of A indicating that U can access door D in time interval d, and (ii) allowing D to open after confirming that the current time is within time interval d. And a step for said entity A. The method of claim 1, wherein user U has a user card and D has a card reader coupled with an electromechanical lock, where U receives SIGUDd by storing it on his card and D read his card. And denotes SIGUDd by D by means of a card reader of D. The method of claim 1, wherein A posts SIGUDd to a U-accessible database so that A during time interval d causes SIGUDd to be received by U. 7. 2. The method of claim 1 wherein SIGUDd is a public key signature, and wherein D stores A's public-key. Method according to claim 1, wherein D also proves identification information about U. 2. The method of claim 1 wherein the identification information about U consists of one or more of an answer to a challenge of D and a PIN. In an access control system with entity A, one or more disconnected doors, a user who owns a user card to access the door, A method for an unconnected statement D to indicate to A that an attempt by a given user U to access D, Receive an information IU from U indicating that U wants to access door D, -D temporarily stores the IU, and For one or more subsequent users V, D causes V to temporarily store the IU in V's card for representation as entity A. A method for an unconnected statement D to indicate to A that an attempt to access D by a given user U characterized in that it comprises a step. 8. A given user U attempts to access D according to claim 7, wherein V represents the IU to A by moving the IU to a database accessible by A or by sending information to A. Method for statement D that is not connected for marking on. 8. The given system of claim 7, wherein the IU comprises at least one of (i) information provided to U to access statement D and (ii) information generated by U to access D. A method for an unconnected statement D to indicate to user A an attempt to access D by user U. 8. The method of claim 7, wherein the IU includes a digital signature generated by U, wherein a given user U is not connected to indicate to A an attempt to access D. 8. The method of claim 7, wherein the IU includes a digital signature of U, wherein a given user U is not connected to indicate to A an attempt to access D. As a method for controlling physical access, Review the real-time certificate, wherein the real-time certificate includes a fixed first portion and a modified second portion on a periodic basis, wherein the second portion provides proof that the real-time certificate is current, Verifying the validity of a real-time certificate by performing an operation on said first part and comparing the result with said second part, and Physical access only if the real-time certificate is verified to be valid And controlling the physical access. 13. The method of claim 12 wherein the first portion is digitally signed by authentication. 14. The method of claim 13 wherein fraud authentication provides the second portion. 15. The method of claim 14 wherein the second portion is provided by an entity other than an authentication. 13. The method of claim 12, wherein the real time certificate is provided on a smart card. 13. The method of claim 12, wherein the user obtains a second portion of the real time credential at the first location. 18. The method of claim 17 wherein the user is granted access to a second location different from the first location and is separated. 13. The method of claim 12, wherein the portion of the first portion of the real-time certificate represents a one-way hash that is applied a number of times to the portion of the second portion of the real-time certificate. . 20. The method of claim 19, wherein a number of times corresponds to the amount of time elapsed since the first portion of the real-time certificate is issued. 13. The method of claim 12 wherein controlling the physical access at this time includes access control through the door.