Abstract:
A method is provided for a enabling a user to initiate a password protected backup copy of the user&#39;s credentials. The method includes providing a user with a credential store containing information relating to the user&#39;s identity, generating a different recovery password of any length for each recovery authority, encrypting the recovery password for each recovery authority, storing the encrypted recovery passwords in the credential store, and sending a copy of the information by the user from the credential store to a central repository.

Description:
COPYRIGHT NOTICE  
       [0001]     A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosures, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.  
       BACKGROUND OF THE INVENTION  
       [0002]     The invention disclosed herein relates generally to the ability for a user to initiate a password protected backup of his credentials and, more particularly, to recovering his credentials even if the user forgets his password.  
         [0003]      FIG. 1  shows a block diagram of an example Public Key Infrastructure (PKI) system architecture, according to the prior art. A PKI is a collection of servers and software that enables an organization, company, or enterprise to distribute and manage thousands of unique public/private cryptographic keys in a manner that allows users to reliably determine the identity of the owner of each public/private key pair. Public/private key pairs have the property that for any given public key there exists one and only one private key, and vice versa. If a particular message can be decrypted using one member of the key pair, then the assumption is that the message must have been encrypted using the other member.  
         [0004]     Certificates may contain information identifying the owner of the key pair, the public component of the pair and the period of time for which the certificate is valid. The certificate may also identify technical information about the key itself, such as the algorithm used to generate the key, and the key length. Certificates are generated by organizations, companies, or enterprises that are responsible for verifying the identity of individuals to which certificates are issued. The certifying authority  100 , in  FIG. 1 , signs each certificate using a private key known only to the certifying authority itself. By issuing a certificate, a certifying authority  100  is stating that it has verified that the public key that appears in the certificate belongs to the individual listed in the certificate.  
         [0005]     Current PKIs that provide strong authentication of user identity accomplish this via the use of a Local Registration Authority Officer (LRAO)  120 . LRAO  120  operates at a workstation or server platform  135  that runs a local registration authority  130 . Server platform  135  may be any known computing device that may serve as a server, e.g. computer, workstation, etc. The local registration authority  130  interfaces with other server platforms that may contain applications such as the certifying authority  100  and registration authority  110 .  
         [0006]     A user  140 , that is using or desires access to the PKI system architecture, accesses the system via a web browser  150  on a client platform  155 . Typically, in current systems, user  140  presents a photo I.D. to the LRAO  120  in order to authenticate the user&#39;s identity. LRAO  120  then uses workstation  135  and local registration authority  130  to signal registration authority  110  to register new user  140  in the system.  
         [0007]     A person&#39;s certificates and corresponding private or secret keys are typically included in the person&#39;s credentials.  FIG. 2  shows a block diagram of a system in which a backup copy of user&#39;s credentials  220  being sent automatically from a credential store  200  to a central repository  240 . The credential store  200  stores information concerning all the users who are registered with the central credential management and authorization center  230 . Each user has its own credentials  220 , which are stored within central database  210 . The credential store  200  maintains the security of credentials  220  it has issued because it controls their storage, updating, revocation and also proxying. A copy of credential store  200  is automatically sent to central repository  240  each time something important changes in credential store  200 . Central repository  240  then stores credentials  220  into storage  260 .  
         [0008]      FIG. 3  shows a block diagram of a recovery authority, according to one embodiment of the invention. Recovery authority  300  stores credentials  220  into storage systems  310 . Each credential store  200 , stored in the storage system  310 , contains a number of unique recovery passwords for their own credential store  200 . If a user  140  forgets his password to his credentials  220 , he would contact a number of recovery authorities  300  to get the needed recovery passwords to open his credentials  220  and reset the password to a new one.  
         [0009]     Prior to the present invention invention, these systems automatically initiated password protected backups of the user&#39;s credential store according to a fixed algorithm, without any involvement or input on the part of users or administrators. However, this created a problem because the only time user credentials  220  were sent to the credential store  200  was when something changed in the credential store  200 . There is therefore a need for users to be able to initiate and control aspects of the backup process through a button in the user interface, which would increase flexibility and result in a more robust behavior in environments where the hard-coded algorithm is not satisfactory. In addition, in the past, recovery passwords were a hard coded length of 16 characters. Users were having trouble typing in 16 characters so they wanted recovery passwords of shorter length. There is therefore a need for more flexibility so that recovery authorities will not need to relay long information to users to recover credentials.  
       SUMMARY OF THE INVENTION  
       [0010]     The present invention provides a method for enabling a user to initiate a password protected backup copy of the user&#39;s credentials. The method includes providing a user with a credential store containing information relating to the user&#39;s identity, generating a different recovery password of any length for each recovery authority, encrypting the recovery password for each recovery authority, storing the encrypted recovery passwords in the credential store, and sending a copy of the information by the user from the credential store to a central repository.  
         [0011]     In another embodiment, a symmetric key is based on a password. The portion of information is encrypted with the public key. The private key is then encrypted with the symmetric key. The recovery password is also encrypted with each recovery authority&#39;s public key.  
         [0012]     In another embodiment, the user manually initiates a backup copy of the user&#39;s credentials. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0013]     The invention is illustrated in the figures of the accompanying drawings which are meant to be exemplary and not limiting, in which like references are intended to refer to like or corresponding parts, and in which:  
         [0014]      FIG. 1  shows a block diagram of an example PKI system architecture, according to the prior art;  
         [0015]      FIG. 2  shows a block diagram of a backup copy being sent automatically from the credential store to the central repository, according to the prior art;  FIG. 3  shows a block diagram of a recovery authority, according to one embodiment of the invention;  
         [0016]      FIG. 3  shows a block diagram of a recovery authority, according to one embodiment of the invention;  
         [0017]      FIG. 4  shows a block diagram of an exemplary system architecture in which PKI processes may be practiced according to one embodiment of the invention;  
         [0018]      FIG. 5  illustrates a flowchart of an example process for enabling a user to initiate a password protected backup of his credentials according to one embodiment of the invention; and  
         [0019]      FIG. 6  illustrates a flowchart of an example process for restoring user credentials, according to one embodiment of the invention. 
     
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS  
       [0020]     In the following description of the preferred embodiment, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration a specific embodiment in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.  
         [0021]      FIG. 4  shows a block diagram of an exemplary system architecture in which PKI processes may be practiced according to one embodiment of the invention. As mentioned above, certifying authority  400  provides storage of certificates and related information. Certifying Authority  400  may be software executed on server platform  405 . Certifying Authority  400  is configured with recovery information such as a quorum number, a location of the credential store, a length of recovery passwords and a list of recovery authorities. The quorum number is used to determine how many recovery authorities, explained further below, are needed to recover a credential store  440  from the central repository  430 . An administrator determines this quorum number based on the number of people he thinks are needed to be convinced that the user requesting the recovery password is who they are. Registration authority  410  may also be software executed on server platform  415 . Recovery authority  420  may also be software executed on server platform  425  and may provide the function of recovering keys as will be described below. Central repository  430  may also be software executed on server platform  435 . Credential store  440  may also be software executed on server platform  445 .  
         [0022]      FIG. 5  illustrates a flowchart of an example process for enabling a user to initiate a password-protected backup of his credentials according to one embodiment of the invention. The certifying authority  400  is configured with recovery information, step  500 . The user  470  is registered by registration authority  410  and his credentials are certified by certifying authority  400 , step  510 . During step  510 , recovery information is embedded in the credentials. When the user  470  initiates a backup of his credentials, the recovery information is retrieved from the credentials, step  520 . The backup copy of credentials  220  is multi-password protected and encrypted for each configured recovery authority, step  530 , that is, a different recovery password is assigned to each recovery authority, and then mailed to central repository  430 , step  540 . Recovery passwords are generated randomly by the software during the importing of the recovery information into the user&#39;s credentials.  
         [0023]     The following steps will describe the process of  FIG. 5  in more detail. User  470  is assigned by Registration Authority  410  a credential store  440  that contains his private information. To protect the private information in credential store  440 , user  470  encrypts the private information. The user then thinks of a password, which is used to create a symmetric key cryptographically (i.e. f(x)=z; z is unique and x is the password—if the user provides x then z can be obtained as a function of x at any time). This symmetric key may either be a 64-bit RC2 key or a 128-bit RC2 key or other such keys as known to those of skill in the art. User  470  also generates a random public and private key pair. The pair is typically a 1024-bit Basic Encoding Rules (BER)-formatted Rivest Shamir Adleman (RSA) key pair. User  470  encrypts the private information with the public key, so only the private key can decrypt it. User  470  encrypts the private key with the symmetric key, so only the symmetric key can decrypt it. A standard RSA encryption may be used. User  470  then stores the encrypted private key and public key into credential store  440 . Anytime user  470  needs to get his private information in credential store  440 , he provides the password, to the software, which is used to create the symmetric key, which is used by RSA Data Security Inc. cryptographic Application Program Interfaces (APIs) to decrypt the private key in credential store  440 , which in turn is used by RSA to decrypt the private information in credential store  440 .  
         [0024]     The Recovery Authority  420  is configured to help recover the user&#39;s credentials if he lost or forgot his credential store password that enables the user to get his credentials. To safeguard the user from forgetting his password and not being able to eventually get to the private key, recovery authorities  420  are added to the process in the following manner. User  470  decides on a list of recovery authorities. User  470  then looks up the public key for each recovery authority  420 . The public keys are typically 512 bytes long or longer. User  470  then thinks of a recovery password for each recovery authority  420 . Traditionally, the first 8 bytes of each recovery password was converted into a 16 character long hex string. At the time, it was believed that this password would be more secure. In embodiments of the present invention, the recovery password may be converted to any length at the cost of security. In other words, the administrator can decide whether he wants more security and harder to use recovery passwords (longer length passwords) or less secure and easier to use passwords (shorter length passwords).  
         [0025]     User  470  takes those recovery passwords and encrypts the symmetric key mentioned above with a quorum requirement. This may be accomplished using a k/n encryption scheme introduced for multi-password-protected ID files. User  470  then stores this encrypted symmetric key in credential store  440 . Each recovery password is encrypted with the public key of each recovery authority, respectively. User  470  stores those encrypted recovery passwords in credential store  440 . A hash of the credential store&#39;s password is also stored in the credential store. Each recovery authority can then get its recovery password by decrypting it with its private key. Traditionally, any time critical information in the credential store was changed, a new “encrypted backup” was automatically sent to central repository  430 . In this invention, a user interface button enables user  470  to send a copy of credential store  440  to central repository  430  without changing the contents of credential store  440 . Credential store  440  contains the password and encrypted recovery password(s) along with information related to the user&#39;s identity. All this information will be sent to central repository  430 .  
         [0026]     The central repository  430  serves as a central location where a group of user&#39;s credential stores  440  can be easily found by one or more recovery authorities  420 . It also serves as a central backup to the user  470  who loses his own copy of the credential store  440 . The user  470  could access the central repository  430  and find a backup copy of the credential store  440  and the password would still be valid to access the user&#39;s credentials  220 .  
         [0027]      FIG. 6  illustrates a flowchart of an example process for restoring user credentials according to an embodiment of the present invention. In the future, user  470  could request restoration of his credentials  220  from central repository  430 , step  600 , by contacting a recovery authority  420 . The recovery authority  420  retrieves the password protected credentials and sends it to user  470 , step  610 . User  470  must now enter the quorum number of recovery passwords, step  620 , by contacting the quorum of recovery authorities  420 , each of which will provide a unique recovery password to user  470 . When the quorum number of recovery passwords has been entered, user  470  is asked to set a new password on the credentials, step  630 .  
         [0028]     While the invention has been described and illustrated in connection with preferred embodiments, many variations and modifications as will be evident to those skilled in this art may be made without departing from the spirit and scope of the invention, and the invention is thus not to be limited to the precise details of methodology or construction set forth above as such variations and modification are intended to be included within the scope of the invention.