Authentication system and process

Details Authentication system and process Authentication system and process

1999-02-03

2001-05-08

Swann, Tod (Department: 2132)

Electrical computers and digital processing systems: support

Multiple computer communication using cryptography

Central trusted authority provides computer authentication

C713S156000

Reexamination Certificate

active

06230266

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to a computerized authentication system and process that utilize public key cryptography, and more specifically, to such a system and method that are able to re-establish authentication system security after compromise of same.
2. Brief Description of Related Prior Art
In a distributed data processing network system, a methodology employed to reliably verify the identity of a communicating device on the network prior to allowing the device to access system operations and resources is referred to as authentication. Access to the system may be, for example, for the purpose of communicating with other users, retrieving secure information, or receiving a service. Distributed systems generally include various computer nodes interconnected by a communications medium. The computer nodes may include nodes that are directly accessed by users, e.g., workstations, and nodes running specialized applications, e.g., servers. These nodes, the processes running on these nodes, and the users of the distributed system are referred to as “principals.” The authentication exchange is performed on behalf of the principals.
Public key cryptography is a method of secure communication in which each principal has a public encryption key and a private encryption key. An encryption key is a code or number which, when taken together with an encryption algorithm, defines a unique transformation that is used to encrypt or decrypt data. A public key system may be used in such a way as to ensure confidentiality of the information being transmitted, i.e., to ensure that the information may not be understood by an eavesdropper, as well as to ensure the authenticity of the sender of the information.
The manner in which a public key cryptography system operates to ensure authentication may be understood without reference to the mathematical transformations that are used for encryption and decryption. Public key cryptography is also referred to as “asymmetric” encryption because information encoded with a public key may be decoded only by using an associated private key and vice versa, the associated private and public keys defining a private/public key pair. According to this type of encryption, the private key is known only to the owner of the key, while the public key is known to other principals in the system.
Accordingly, to effect a secure transmission of information to a recipient, a principal encodes (“encrypts”) the information with the recipient's public key. Since only the intended recipient has the complementary private key, only that principal can decode (“decrypt”) it. On the other hand, to prove to a recipient of information that the sender is who he purports to be, the sender encodes (“signs”) the information with its private key. If the recipient can decode (“verify”) the information using the sender's public key, it knows that the sender has correctly identified itself. In public key cryptography, each principal is responsible for knowing its own private key and all the public keys are generally kept in a convenient location, typically a directory service (DS). Alternatively, each principal may store its own public key, furnishing it to a recipient during an authentication exchange.
It is essential to reliably know which public key belongs to which principal. The typical solution for this problem is to use a trusted entity known as a certificate authority (CA). A CA generates identity certificates, which are signed messages specifying a “subject,” i.e., the name of the principal whose public key is being certified, the certificate serial number, name of the CA issuing the certificate, the subject's public key, and also, typically, a certificate expiration date. This verification of the relationship between the public key and the principal to which it belongs precludes an intruder from compromising the system by posing as a valid principal. Since each certificate is signed by the private key of the CA to ensure the authenticity of the certificate itself, all principals in the network that are required to authenticate a principal must somehow securely learn the CA's public key so that they can verify its signature on the certificates. Certificates may be stored in any convenient location, such as a DS, or each node can store its own certificate and furnish it as part of the authentication exchange. Typically, in order to provide enhanced security, the CA is an off-line entity and communicates to network principals via secure off-line communications techniques.
For complete network security, every principal must have a certificate. Sometimes, however, it is desirable to later disable a certificate after it has been issued but prior to its expiration. For example, a principal's private key may be stolen, compromised or lost, etc. Under such circumstances, it is desirable to revoke the certificate, thereby disabling authentication via that certificate.
Various schemes have been developed to revoke unexpired certificates. In one conventional approach, all valid principal certificates are stored on-line in some location, such as a DS, and are publicly available for retrieval. For example, when a user needs to authenticate to a server, the server polls the DS to see if the user's certificate is present in the DS. If a user's certificate is not stored in the DS, then it is concluded that the certificate has been revoked.
Another conventional approach is to issue a list from the CA of unexpired certificates that should not be honored, referred to as a Certificate Revocation List (CRL). The Certificate Revocation List may have a format defined by the ITU-T Recommendation X.509, formally referred to as the ISO/IEC 9495-8: Information Technology-Open Systems Interconnection-The Directory-Authentication Framework, 1988 (revised 1993). An application considers a certificate as valid if it has not expired and is not listed in the CA's current CRL. Unfortunately, since a CRL can become quite large over time (i.e., as an ever greater number of certificates are revoked and added to the CRL), it can consume a large amount of network bandwidth, storage space, and CA processing power to distribute the CRL to all network nodes desiring the information contained in the CRL. Due to the difficulty involved in obtaining a CRL, this means that the CRL will typically not be compiled frequently, thus the CRL may be out of date.
One conventional approach to solving this problem involves use of an on-line revocation server (OLRS). The OLRS maintains a database of certificate revocation status information that may include, for instance, information derived from the version of CA's CRL that was most recently provided to it, and real-time information that it receives via secure channels that other unexpired certificates issued by the CA have been revoked. The OLRS makes its certificate revocation information available on-line to network principals that may ask the OLRS for it. That is, network principals may make on-line queries to the OLRS for certificate revocation information, and the OLRS provides responses to such queries based upon the OLRS' certificate revocation status information. Because the OLRS responds to specific on-line queries, its responses can be more timely than information provided by the off-line CA and be more efficient because it includes only the information requested.
Unfortunately, the relatively greater access to the OLRS provided by the fact that it is an on-line, and perhaps replicated entity (as opposed to the CA, which typically is off-line) inherently reduces OLRS security and increases likelihood of compromise of the OLRS (e.g., theft of the OLRS private key and/or unauthorized modification of the certificate revocation status information in the OLRS). Therefore, it is important that the OLRS have a different private key from the CA because the OLRS is more susceptible to compromise as a result of the OLRS being on-line; however, compromise of the OLRS pri

Affiliated with

Also associated with

Rating

Authentication system and process does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Authentication system and process, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Authentication system and process will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2512554