Cryptography – Key management
Reexamination Certificate
1999-06-30
2001-02-20
Swann, Tod (Department: 2767)
Cryptography
Key management
C380S001000, C380S286000, C380S280000, C705S076000, C705S071000, C705S066000, C713S158000, C713S157000, C713S178000
Reexamination Certificate
active
06192130
ABSTRACT:
FIELD OF THE INVENTION
The invention relates generally to systems employing cryptography based information security, and more particularly to systems employing public key encryption.
BACKGROUND OF THE INVENTION
Communication systems such as computer networks, telecommunication systems, and other systems are increasingly using cryptography to encrypt information sent electronically. With the increase in electronic commerce, electronic mail communication, and other information for which users may wish to keep secret, public key cryptography systems employ an encryption key pair, such as a decryption private key and an encryption public key to decrypt and encrypt data. The decryption private keys are secret keys that are protected by the use of encryption techniques and other techniques to help ensure that an attacker cannot readily obtain this critical key. In communications that employ many users, it is not uncommon that a given software application has its own encryption and decryption keys as well as the user of a computer.
Referring to
FIG. 1
, a trust authority, such as a certification authority in a public key infrastructure, maintains private encryption key history data
10
for one or more subscribers. The certification authority
5
serves as the originating trust authority (trust anchor for the subscriber). The cryptographic engine
12
includes a session key generator
14
, a subscriber encryption key pair generator
16
, a certification authority signing key pair generator
18
, and a remote session key pair generator
20
. As known, the key pairs that are generated may all generate from a common key pair generator algorithm if desired. In a public key based system, a subscriber sends a signed request using a private signing key to the originating certification authority
5
requesting a new encryption key pair using a session key generated from the session key generator
14
. When transferring the encryption private key from the trust authority to the subscriber, the session key generator is used to create a session key to encrypt the private decryption key. If the subscriber request is password-based, the session key is based on the password which both the subscriber and trust authority know, and is generated independently by the subscriber and the trust authority. If the subscriber request is public key-based, the session key is a random key generated by the trust authority and is transferred to the subscriber encrypted with an existing public key for which the subscriber has the private decryption key in its local storage. The client requests a new encryption certificate and private decryption key. When a key such as a public encryption key expires, the certification authority
5
keeps the history of private encryption keys on a per user basis to allow the user to decrypt old messages. After a client sends the request, the certification authority
5
verifies the signature on the request and generates a new encryption key pair using the subscriber encryption key pair generator
16
. The certification authority locally stores the private decryption keys as part of the key history for the subscriber. The certification authority
5
then generates an encryption certificate and sends a new certificate that is signed with the trust authority private signing key generated by the signing key pair generator
18
. It encrypts this information using the session public key as known in the art(the private decryption key is encrypted with the session key). As part of the new certificate, a new decryption private key is also sent to the subscriber. The remote session key pair generator
20
generates session key pairs to facilitate secure communication with a subscriber, for example, to send other information to the trusted authority as known in the art.
Conventional public cryptography based security systems may store a user's decryption private key and other user-specific data, such as program settings or user preferences, in secure storage of a server. The storage of such user-specific data in a centralized location accommodates central generation and/or updating of data. This allows updates to be locally accessible to the user from various locations, and may serve as a master copy in case the local data storage or program employing such data is lost or upgraded. Each time a user (subscriber) accesses the server/directory with appropriate identification or access permission, the subscriber obtains access to its user-specific data. A problem with such systems, is that there is typically no history of previous decryption private keys so a subscriber cannot read older encrypted data. For example if a previous e-mail was encrypted using an older encryption key of the subscriber, and the encryption key was subsequently updated or replaced after a period of time, which is common, the e-mail cannot be read using the new decryption private key because it is no longer paired with the older public encryption key.
To overcome this problem, other public key cryptography based security systems store the history of decryption private keys locally in a user's computer memory units and protect this information (for example by encryption) to avoid access by an attacker. In addition, the history of the decryption private keys is stored in a master copy form in the security manager server. In such a system however, such backed-up decryption private keys are only accessible through the manager server and not directly to the user.
Upon loss of a previous decryption private key, which may be 1,024 or 2048 bits long (for example if the RSA algorithm is used), a subscriber or user identified as having the proper access for the community can be allowed to access the stored history data to obtain a previously lost decryption private key. A user may need to recover multiple keys, that is a key history, because the validity of certificates expires periodically, and thus over time users have a number of different key pairs. A new key pair is automatically generated either by the manager server or the user computer upon the expiration of the validity period of the certificates. In order for a user to obtain a copy of the key history from the manager server, the subscriber must prove through special procedures which provide access control, such as a manual telephone call or personal appearance or other mechanism to obtain a new password to gain access to the key history. Because access to the manager server key history is particularly sensitive, such procedures are typically designed to be inappropriate for frequent use, and therefore are inconvenient as a mechanism of regular access to the key history.
Also, a problem arises in moving a public key infrastructure user or other information security user from one originating trust authority (e.g., server) domain to another trust authority domain while preserving the subscriber's ability to decrypt old documents and verify previously signed files. Known systems do not generally provide a system coordinated facility for moving users from one trusted authority, such as a certification authority, to another. Information security systems that maintain decryption key histories or other cryptographic key histories, may have the capability to export decryption keys from a subscriber, such as a software application, network node, stand alone data processing unit or other entity. This may be done, for example, using PKCS #12 Standard protocol which is generally used to transfer private keys and certificates to allow other software applications, for example, in a common node to use private keys. However, such systems typically require the subscriber to export a single decryption key and another software program to import this single key. This becomes disadvantageous because it requires the subscriber to individually manage the process and typically there is no central backup of the users' decryption keys. In addition, the trust anchor or originating certification authority, is typically not changed.
Typically, subscribers are given a system
Entrust Technologies Limited
Markison & Reckamp, P.C.
Sulpizio, Jr. Ronald F.
Swann Tod
LandOfFree
Information security subscriber trust authority transfer... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Information security subscriber trust authority transfer..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Information security subscriber trust authority transfer... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2574754