Encrypted content recovery

[0001] Information protection poses a complex problem for individuals and businesses. Businesses in particular may find it difficult to protect information from unauthorized access and at the same time allow easy access by authorized users.

[0002] For example, it may be difficult to ensure that encrypted information may be recovered in the event that the key to decrypt the information is unavailable. If the key or keys necessary to access the information are lost (e.g., if a hardware cryptographic device is misplaced or if a key stored in a memory or magnetic medium is lost when the memory is inaccessible for some reason), the data may become either temporarily or permanently inaccessible.

[0003] Key escrow systems may be used to enable content recovery of encrypted information. Key escrow systems store a key to access encrypted information in a safe location so that the encrypted information may be later recovered. For example, an employee may have a key for decryption of data. The same key may also be stored in a central repository and may be accessed when needed by an appropriate person.

[0004] Alternately, master key encryption systems may also be used to enable data recovery. A master key system may encrypt data using both a user's public key and a master public key. In a corporation, each employee may have a personal public key, and may access the company public key for encrypting electronic documents. Either of the user's private key or the company private key may be used to decrypt the data, so that if the user's key is unavailable for some reason, the data may still be accessed.

[0005] FIG. 1A shows an encryption process to enable content recovery.

[0006] FIG. 1B shows another encryption process to enable content recovery.

[0007] FIG. 2 shows how content recovery may be enabled in an encrypting email application.

[0008] FIG. 3 shows how content recovery may be enabled in an encrypting file system application.

[0009] FIG. 4 shows a system that may be used to enable content recovery.

[0010] Like reference symbols in the various drawings indicate like elements.

[0011] Existing encryption content recovery techniques may have certain limitations, particularly when used in a corporate environment.

[0012] For example, key escrow requires that a copy of the private key be stored in escrow. Therefore, systems that do not allow the private key to be copied (e.g., systems where a private key is stored on a removable cryptographic device such as a SmartCard) may not be used. Additionally, implementing a key escrow system may be costly, since people and processes may be required to administer the system. Further, since the people administering the system generally have access to the stored keys, key escrow systems may also pose a security risk.

[0013] Master key systems also pose a number of problems. An important problem is that since a single master key can decrypt all documents, a person who gains access to the master key may be able to access all encrypted documents.

[0014] FIG. 1A illustrates a process 100 for encrypting data that allows for efficient and secure data recovery, according to an implementation. The encryption process may include creating a session key at 110. The data may then be encrypted using the session key at 120. A directory may be queried to obtain a user's public key, the name or other identifier of his manager, and his manager's public key at 130. The query need only return the public keys; that is, the name of the person's manager need not be returned (although in some circumstances it may be helpful to have the query also return the manager's name). The session key may be encrypted with the user's public key and his manager's public key at 140.

[0015] More generally, data may be encrypted with a user's public key and with the public key of another user. The public keys may be obtained from one or more data objects in a data structure (e.g., from one or more directory entries in a directory). For example, a user's public key may be obtained by accessing a directory entry associated with the user. The name of other identifier of the user's manager (or other person associated with the user) may be obtained from the directory entry associated with the user. The public key of the user's manager may then be obtained from the directory entry of the user or the directory entry of his manager.

[0016] Directories such as Microsoft's Active Directory, Novell's eDirectory, or directories using the lightweight directory access protocol (LDAP), such as OpenLDAP, may be used. In some implementations, a directory may be integrated with another application such as an email application or an encrypting file system application.

[0017] Decrypting the data thus requires recovering the session key and subsequently using the session key to decrypt the data. Since there are two separate copies of the encrypted session key, either of the user's private key or his manager's private key may be used to decrypt the session key.

[0018] FIG. 1B shows an implementation that does not use a session key. A process 150 includes querying a directory for a user's public key, manager name, and manager's public key at 160. The data is then encrypted using both the user's public key and the manager's public key at 170. Although this process includes fewer steps, it may be inefficient in cases where a large amount of data is encrypted. Rather than encrypting the file once using the session key and encrypting only the session key twice, the large file is encrypted twice, producing two large encrypted files.

[0019] FIG. 2 shows an implementation for encrypting data using an email application 210. Encrypting email systems generally access one or more directories such as directory 220 storing a user's public key. Directory 220 may be included in email application 210 or may be separate. The directory entry for a particular user may also include information such as the name of the user's manager (e.g., the person to whom the user reports in the company's human resources hierarchy). When an encrypted email is to be sent to the user, directory 220 is queried for his public key, which is then used in the encryption (e.g., to encrypt the data or to encrypt a session key). Directory 220 is also queried for his manager's name (or other identifier, such as a pointer to a directory entry associated with the manager) and public key. The manager's public key is also used to encrypt the data or session key.

[0020] For example, when a user wants to send an encrypted email to Joe Smith, email application 210 queries directory 220 to determine Joe Smith's public key, his manager's name (or other identifier), and his manager's public key. The data to be encrypted (e.g., email text and/or one or more email attachments) is then encrypted using a technique such as those shown in FIGS. 1A and 1B.

[0021] If the email is to be sent to a number of recipients, the process may be used for each recipient or fewer than all recipients. That is, the data or session key may be encrypted with the public key of each email recipient and the public key of each of their managers, or may be encrypted with the public key of each email recipient but the public key of fewer than all of their managers.

[0022] Note that the email itself is sent to the recipients but is generally not sent to the manager(s). Although the system may be designed so that the manager receives emails as well as the intended recipient, such an implementation may lead to excessive email traffic in the manager's inbox, and so may not be desired.

[0023] FIG. 3 shows an implementation using an encrypting file system (EFS). Encrypting file systems may be used so that if an unauthorized person has access to the file's storage medium (e.g., the file is stored on the hard drive of a notebook computer that is subsequently stolen), the data is not compromised.

[0024] A user creates a file to be stored as an encrypted file using an EFS 310. The user may specify one or more persons who are to have access to the file. EFS 310 may access a directory 320 to obtain the public key of those persons, as well as the name and public keys of their managers.

[0025] Systems and techniques as described above may provide the advantage that removable cryptographic devices such as SmartCards may be used. Since the private key never leaves the SmartCard, data may be more secure than in a system where the private key is extractable (e.g., as in the key escrow system described above).

[0026] Additionally, the above-described systems and techniques may be easy to implement. Existing applications such as encryption applications, email applications, and encrypting file system applications may be modified to obtain the information above from a directory. The process may thus be implemented by upgrading existing infrastructure rather than requiring the addition of new applications.

[0027] For example, the implementation of FIG. 2 may be incorporated into existing email systems, such as email systems using standards such as S/MIME. Similarly, the implementation of FIG. 3 may be incorporated into existing EFS systems such as Microsoft's Encrypting File System. The processes of FIGS. 1A and 1B may be incorporated into other applications as well.

[0028] Systems and techniques described above may also provide a desirable balance between ease of access to encrypted documents and security. By encrypting the data or session key so that a user's manager can decrypt the data, the problem of inaccessible keys may be largely mitigated. Additionally, since the user's manager is generally authorized to access the user's files or other data, there may be no additional exposure of the data. In contrast, both key escrow and master key systems generally allow at least some system administrators access to the private keys.

[0029] FIG. 4 shows a system 400 for enabling content recovery. A user data processing system 410, such as a personal computer, notebook computer, PDA, or other data processing system, may store a document in a memory 420. System 410 may access a server 430 to access one or more memories on server 430 storing an encryption application 435 and a directory 437. For example, application 435 may be an encrypting email system or encrypting file system.

[0030] For an example where application 435 is an encrypting email system, a user may access application 435 via system 410. The user may choose one or more recipients of an encrypted email (e.g., the text of the email and/or any email attachments may be encrypted). Application 435 may access directory 437 to obtain the public keys of the recipients, the name of at least one recipient's manager, and the public key of the manager(s).

[0031] Application 435 may generate a session key, encrypt the appropriate data using the session key, and encrypt the session key itself using both the recipients public key and the public key of the manager(s). Application 435 may then send the email to the recipients, including the multiple copies of the encrypted session key. Although application 435 sends the email, it may be stored on server 430, to be read by the recipient via a recipient data processing system 440.

[0032] Upon receiving the email, the recipient may decrypt the data using his private key. However, if he doesn't have access to his private key, he may decrypt the data using the private key of his manager. If his manager's key is stored on data processing system 450, he may decrypt the email from system 450. If his manager's private key is stored on a SmartCard, he may decrypt the email using the SmartCard at his own system 440 or his manager's system 450.

[0033] Application 435 may be an encrypting file system application. A user may access application 435 from system 410 to store encrypted data in memory 420. The user may choose one or more persons to have access to the encrypted data. A default may be that the user himself has access to the encrypted data.

[0034] Application 435 may access directory 437 for the user's (and/or other person to have access to the data) public key, the user's manager's name or other identifier, and the user's manager's public key. Application 435 may produce a session key, encrypt the data using the session key, and encrypt the session key using the user's and his manager's public keys.

[0035] System 400 shows an example system that may be used. In other implementations, application 435 and/or directory 437 may be stored on separate systems or be stored on the user's system 410. Many other configurations are possible.

[0036] A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. The acts shown in the figures and/or recited in the claims may be performed in different orders than those shown/discussed. For example, in FIG. 1A, the directory may be queried prior to the creation of the session key and/or the encryption of data using the session key.

[0037] Additionally, the public key of persons other than the user's manager may be used to enable content recovery. For example, a directory entry for a first person may include his public key, and the name or identifier of a second person. Thus, the second person is associated with the first person by virtue of the directory entry. Note that the identifier of the second person may be a pointer to the directory entry of the second person or other similar object. Although using the manager's public key may enable efficient use of existing directory structures, some implementations may find it advantageous to use the key of a different person instead of (or in addition to) that of the user's manager. Accordingly, other implementations are within the scope of the following claims.