WO2009018513A1

WO2009018513A1 - Systems and methods for implementing a mutating lock box

Info

Publication number: WO2009018513A1
Application number: PCT/US2008/071895
Authority: WO
Inventors: Richard Malina; William Cochran; Stuart Stubblebine
Original assignee: Imagineer Software, Inc.
Priority date: 2007-08-02
Filing date: 2008-08-01
Publication date: 2009-02-05

Abstract

A computer-readable storage medium associated with a first computing device, the computer-readable storage medium having stored thereon a data structure. The data structure includes at least one secret drawer including encrypted content, and an identifier associated with a cryptographic key, the cryptographic key capable of decrypting the encrypted content. The data structure also includes a request drawer including an identifier associated with the data structure, and data used to generate authentication information, the authentication information used to verify the identity of the first device. The first computing device is configured to communicate with a second computing device having a database populated with a one or more keys, where at least one of the keys enables the decryption of the content in the at least one secret drawer.

Description

SYSTEMS AND METHODS FOR IMPLEMENTING A MUTATING LOCK BOX

BACKGROUND OF THE INVENTION [0001] It is sometimes useful to distribute confidential or protected digital content to one or more electronic devices. For example, a company may place files containing proprietary information on one or more computers. Of course, proprietary software can be installed on one or more computers. In these situations, access to the digital content is often controlled or restricted. The company may wish to restrict access to its confidential files to a small group of its employees. The software company may wish to restrict access to its software to those who have paid for or registered the software. One common way of protecting such confidential information is with the use of a secret password. Under this scheme, digital content is encrypted so that it cannot be accessed unless the user of the device enters a pre- established password.

[0002] This password protection scheme is vulnerable to so-called "dictionary attacks." Password dictionary attacks are possible because computer users most often employ "weak" passwords, which are either very short or use easily recognizable words or patterns that are easy to remember. During a dictionary attack, a malicious third party will systematically try every possible password in an attempt to unlock the digital content, usually starting with the those passwords that are most likely to be successful. Dictionary attacks are relatively easy to carry out and, depending on the size of the password, often successful. [0003] In many circumstances, a password is all that the user needs to unlock digital content. In such a case, a malicious third party that has obtained a copy of the password protected digital content may engage in an offline dictionary attack without alerting the content owners. For example, a malicious third party may obtain a device having a copy of the password protected digital content through illegitimate means. The third party can take the device offline (so that it cannot access a computer network) and carry out a dictionary attack without alerting anyone.

SUMMARY OF THE INVENTION

[0004] In light of problems with securing digital content, it would be useful to have a device that reduces the ability of malicious persons to obtain unauthorized access to such content. One embodiment of the invention provides a mutating lock box. A mutating lock box is a software construct that allows for digital content to be stored securely on a device. The digital content is encrypted with a strong encryption mechanism (e.g., one that uses a key that is so large that a brute force attack is impractical) and stored on the user device. The only way that a user may view the digital content is to obtain an appropriate cryptographic key, and that cryptographic key is not stored on the user device. Therefore, even if a malicious third party is able to gain access to the protected digital content, they will not be able to access the data without first obtaining the key.

[0005] The cryptographic key that is required to decrypt the digital content is stored on a trusted key server. The user device transmits a request for the appropriate cryptographic key to the key server. This request performs two functions: 1) it identifies the encrypted digital content whose cryptographic key is requested, and 2) it authenticates the user of the device, for example, by requiring a password from the party that is requesting the key. The trusted key server verifies the identity of the requestor and responds by transmitting the cryptographic key that is associated with the encrypted digital content to the device. [0006] A mutating lock box architecture decreases the possibility of a successful password dictionary attack. First, the key used to encrypt the information on the lock box is relatively large. As a consequence, a dictionary attack requires an increased level of effort. Second, in order to carry out a dictionary attack on the password, the third party must submit a separate request for the cryptographic key to the key server for each possible password value. Thus, the trasted key server can determine when a dictionary attack is taking place, because it will receive a large number of requests for the cryptographic key that belongs to a particular piece of digital content.

[0007] Embodiments of the invention implement technology described in U.S. Patent

Publication 2006/0195402 (the "'402 Publication") the contents of which are fully incorporated by reference as if set forth herein. The "402 Publication described Mutating

Identifiers and Black Content Protocols, which uses keys for "white" and "black" data. In one embodiment, digital content in a mutating lock box includes cryptographic elements (i.e., mutating identifiers, cryptographic keys for white data, cryptographic keys for black data, and a large shared secret) which permit the user device to use a Mutating Identifier Protocol and, in some cases, Black Content Protocol.

[0008] In order to use encrypted content, the user or user device must first open the mutating lock box.

[0009] In one embodiment, the client device is configured with a mutating lock box that includes encrypted content. The key server includes the cryptographic key that decrypts the encrypted content.

[0010] The client device requests the cryptographic key for the encrypted content by transmitting a request to the key server. The request includes the identifier for the encrypted content and an encrypted authentication value. The authentication value is a hash of the password provided by the user of the client device.

[0011] The key server receives the request and verifies that the authentication value is correct. The key server also locates a cryptographic key which corresponds to the content identifier. The key server transmits a response to the client device that includes the requested cryptographic key. The client device uses the cryptographic key to decrypt the encrypted mutating information. [0012] In another embodiment, the client device includes at least one secret drawer, which includes the encrypted content, and at least one request drawer, which includes information which the client device uses to request a cryptographic key for the content in the drawer. The key server includes the cryptographic key that is associated with the content in the request drawer and an authentication value which it can use to verify the identity of the client device.

[0013] The client device transmits a first request to the key server. The first request includes an identifier for the lock box and an identifier for the request drawer. The key server receives the first request from the client device, and transmits a first response. The first response includes information that the client device uses to discover a cryptographic key that allows it to open the request drawer in its mutating lock box.

[0014] The client device transmits a second request to the key server. The second request includes authentication information that the key server can use to verify the identity of the client device. The second request includes an encrypted pre-master secret and an authentication value. The authentication value is generated using information which includes a password entered by the user of the client device, values unique to the mutating lock box on the client device, and values unique to the client device itself.

[0015] The key server receives the second request and uses the authentication value to verify the client device's identity. The key server transmits a second response to the client device. The second response includes the cryptographic key that is used to decrypt the encrypted information in the client device's request drawer.

[0016] The client device receives the second response and extracts the cryptographic key. The client device uses the cryptographic key to decrypt the encrypted mutating content. [0017] In one embodiment, the invention is a computer-readable storage medium associated with a first computing device, the computer-readable storage medium having stored thereon a data structure. The data structure includes at least one secret drawer including encrypted content, and an identifier associated with a cryptographic key, the cryptographic key capable of decrypting the encrypted content. The data structure also includes a request drawer including an identifier associated with the data structure, and data used to generate authentication information, the authentication information used to verify the identity of the first device. The first computing device is configured to communicate with a second computing device having a database populated with a one or more keys, where at least one of the keys enables the decryption of the content in the at least one secret drawer. [0018] In another embodiment, the invention is a computer-based method for using a mutating lock box that is stored on a first device. The method includes transmitting a first request from the first device to a second device, the first request including a secret drawer identifier, which corresponds to encrypted content that is stored in a secret drawer in the mutating lock box, and a mutating lock box identifier, which corresponds to the mutating lock box. The method also includes transmitting a first response from the second device to the first device, the first response including cryptographic information used by the first device to generate authentication information; generating authentication information on the first device; transmitting a second request from the first device to the second device, the second request including the authentication information; and verifying the identity of the first device on the second device, using the authentication information. The method also includes transmitting a second response from the second device to the first device, the second response including a cryptographic key that is suitable for decrypting the encrypted content in the secret drawer; and decrypting the cryptographic content in the secret drawer using the cryptographic key on the first device.

[0019] In yet another embodiment, the invention is a computer-based method of decrypting encrypted digital content by a device. The method includes sending identification information, wherein the identification information includes the identity of encrypted digital content to be decrypted; receiving a response to sending identification information, wherein said response includes a first data needed to decrypt the encrypted digital content; executing code on the first device to obtain a second data, wherein second data includes data devoid from contents of any computer files accessible by the device; and decrypting encrypted digital content, wherein decrypting requires at least first data and second data. [0020] In still another embodiment, the invention is a computer-based method of decrypting encrypted digital content by a device. The method includes sending identification information, wherein the identification information includes the identity of encrypted digital content to be decrypted and sending authentication information, wherein successful verification of the authentication information is necessary for authorization to decrypt encrypted digital content. The method also includes receiving decryption data in response to sending identification information and sending authentication information wherein decryption data is needed to decrypt the encrypted digital content; and decrypting encrypted digital content, wherein decrypting requires the decryption data.

[0021] In yet another embodiment, the invention is a computer-based method of decrypting encrypted digital content that is stored on a first device. The method includes transmitting a first request from the first device to a second device, wherein the first request includes at least one identifier that is associated with the digital content and transmitting a first response from the second device to the first device, wherein the first response includes a first cryptographic key. The method also includes receiving the first response on the first device and using information in the first response to generate a first cryptographic key; decrypting encrypted authentication information that is stored on the first device using the first cryptographic key; transmitting a second request from the first device to the second device, wherein the second request includes the authentication information, and using the authentication information to verify the identity of the first device; transmitting a second response from the second device to the first device, wherein the second response includes a second cryptographic key; and receiving the second response on the first device and using the cryptographic key to decrypt the encrypted digital content.

[0022] In still another embodiment, the invention is a system for decrypting encrypted digital content. The system includes a first device configured to transmit an identifier that is associated with the encrypted digital content and an authentication value to a second device, receive a cryptographic key from the second device, and decrypt the encrypted content using the cryptographic key. The system also includes a second device configured to receive the identifier from the first device, verify the identity of the first device using the authentication value, locate the cryptographic key that is associated with the identifier, and transmit the cryptographic key to the first device.

[0023] In yet another embodiment, the invention is a system for decrypting encrypted digital content, the system including a first device and a second device, the first device being in operative communication with the second device. The first device is configured to transmit a first request to a second device, the first request including at least one identifier that is associated with the encrypted digital content; receive a first response from the second device, the first response including a first cryptographic key and a message authentication code; decrypt encrypted authentication information using a cryptographic key that is derived using the first response; transmit a second request to the second device, the second request including the authentication information; receive a second response from the second device, the second response including a second cryptographic key; and decrypt the encrypted digital content using the second cryptographic key. The second device is configured to receive the first request from the first device, the first request including the identifier that is associated with the encrypted digital content; transmit a first response to the first device, the first response including the first cryptographic key and the message authentication code; receive a second request from the first device, the second request including the authentication information; verify the identity of the first device using the authentication information; and transmit a second response to the first device, the second response including the second cryptographic key.

[0024] In still another embodiment, the invention is a first device configured to store encrypted digital information, the first device comprising a processor and a memory module. The processor is configured to transmit an identifier that is associated with the digital content and authentication information to a second device; receive a cryptographic key from the second device; and decrypt the encrypted digital information using the cryptographic key. The memory module is configured to store the encrypted digital information and an identifier that is associated with the encrypted digital information.

[0025] In yet another embodiment, the invention is a first device configured to store encrypted digital information, the first device including a processor and a memory module. The processor is configured to transmit a first request to a second device, wherein the first request includes at least one identifier associated with the encrypted digital information; receive a first response from a second device, wherein the first response includes cryptographic information; derive a first cryptographic key suitable for decrypting encrypted authentication information that is stored on the memory module of the first device using the cryptographic information in the first response; transmit a second request to the second device, wherein the second request includes the authentication information; receive a second response from the second device, wherein the second response includes a second cryptographic key; and decrypt the encrypted digital information using the second cryptographic key. The memory module is configured to store the encrypted digital information; at least one identifier that is associated with the encrypted digital information; and the encrypted authentication information.

[0026] In still another embodiment, the invention is a key server configured to implement a mutating lock box protocol for decrypting encrypted digital information stored on a client device, the key server including a processor and a memory module. The processor is configured to receive a first request from the client device, wherein the first request includes at least one identifier associated with the encrypted digital information; transmit a first response to the client device, wherein the first response includes cryptographic information for deriving a first cryptographic key suitable for decrypting encrypted authentication information that is stored on the client device; receive a second request from the client device, wherein the second request includes the authentication information; transmit a second response to the client device, wherein the second response includes a second cryptographic key for decrypting the encrypted digital information. The memory module is configured to store the cryptographic information for deriving the first cryptographic key and the second cryptographic key.

BRIEF DESCRIPTION OF THE DRAWINGS

[0027] FIG. 1 is a schematic representation of a system that is configured to use Mutating Identifier and Black Content Protocols.

[0028] FIG. 2 is a schematic representation of a system configured to use a mutating lock box.

[0029] FIG. 3 A is a schematic representation of a first embodiment of a mutating lock box.

[0030] FIG. 3B is a schematic representation of an alternative first embodiment of a mutating lock box. [0031] FIG. 4 is a schematic representation of a first embodiment of a trusted key server. [0032] FIG. 5 is a schematic depiction of a first embodiment of an open mutating lock box transaction.

[0033] FIG. 6 is a schematic depiction of a second embodiment of a mutating lock box.

[0034] FIG. 7 is a schematic representation of a second embodiment of the trusted key server.

[0035] FIG. 8 is a schematic depiction of an authentication value that is used by the mutating lock box of FIG. 6.

[0036] FIG. 9 is a schematic depiction of a first embodiment of an open mutating lock box transaction.

[0037] FIG. 10 is a flow chart depicting a process that is used by the client device to generate a cryptographic key for the request drawer.

DETAILED DESCRIPTION

[0038] Before any embodiments of the invention are explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the drawings. The invention is capable of other embodiments and of being practiced or of being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. For example, some terms in the specification are capitalized to conform to naming conventions used in the applicable art, but no special meaning is intended simply due to the use of capital letters, unless the text clearly indicates otherwise.

[0039] It should also be understood that some embodiments are implemented using various computer devices, such as personal or home computers, servers, and other devices that have processors or that are capable of executing programs or sets of instructions, including special purpose devices such as set top boxes (e.g., digital cable or satellite decoders). In general, some embodiments may be implemented using existing hardware or hardware that could be readily created by those of ordinary skill in the art. Thus, the architecture of exemplary devices will not be explained in detail, except to note that the devices will generally have a processor, memory (of some kind), and input and output devices or interfaces. The input devices, which can include a keyboard, mouse, touch screen, or the like can be used by a user to input commands and data into a system. The output devices, which can include a CRT or LCD monitor or the like, can be used to inform the user of the result of the methods that are run on the systems disclosed herein. In some cases, the devices may also have operating systems and application programs that are managed by the operating systems. In some embodiments, the hardware devices or software executed by the hardware devices also provides some ability, depending on the role of the device in the particular embodiment of the invention implemented, to compress or decompress data or to encode data or decode encrypted data. In some instances, a decompression capability may be provided using available codecs, such as hardware-implemented Moving Picture Experts Group ("MPEG") codecs. A decryption capability may be provided using a decryption hardware or software module capable of decrypting data that is encrypted using a particular encryption algorithm.

[0040] Before discussing any embodiments of the invention, the reader should be familiar with certain encryption protocols and techniques described in the '402 Publication. To that end, this Detailed Description is arranged in three sections: 1) Mutating Identifier Protocol, 2) Black Content Protocol, and 3) Mutating Lock Box Architecture. The first two subsections (i.e., Mutating Identifier Protocol and Black Content Protocol) are intended to summarize encryption techniques that are described in the '402 Publication, and are not intended to introduce any new subject matter. The third section (e.g., Mutating Lock Box Architecture) provides a detailed description of embodiments of the invention. MUTATING IDENTIFIER PROTOCOL

[0041] FIG. 1 depicts a system 20, that is suitable for using the Mutating Identifier Protocol as disclosed in the '402 Publication. The system 20 includes a first device 22, a second device 24, and an authenticator device 28. It will be assumed that the first device 22 has data that it wants to transmit to the second device 24. The first device 22, the second device 24, and the authenticator device are connected by two-way links 30, 32, and 38 which can include all or part of one or more of computer networks such as the Internet. In addition, in some embodiments the system 20 may include a random number generator 39 which is a specialized device designed to produce numbers that are truly random (i.e., numbers that are as random as is possible with the particular technology used to implement the invention of the '402 Publication). In some embodiments, the authenticator device 28 uses the random number generator 39 to generate numbers used by a protocol implemented or followed by the system 20.

[0042] The system 20, can use mutating identifiers ("mutating IDs") to facilitate the transfer of information from the first device 22 to the second device 24. A mutating ID is an identifier that has at least two portions: 1) an identifying number and 2) a secret key. Preferably, both portions of the mutating ID are random values. Mutating IDs are generated and tracked by the authenticator device 28. Therefore, before the first device 22 and the second device 24 can communicate they must first obtain at least one mutating ID from the authenticator device 28. hi addition, each mutating ID can only be used one time, and when the first device 22 or the second device 24 has used its supply of mutating IDs, it must obtain additional mutating IDs from the authenticator device 28 before it can continue to communicate. [0043] In one embodiment of the invention disclosed in the '402 Publication, mutating IDs are used to exchange a session key between the first device 22 and the second device 24. An example of this embodiment is described below. As with many descriptions of communication protocols, names are assigned to the various devices (or computer systems associated with those devices) used in the protocol. In one embodiment, Alice (A) and Bob (B) represent the first device 22 and the second device 24, respectively, and Trent (T) represents the authenticator 28, a trusted arbiter of communication. The following table, Table 1, is a list of other symbols used in this document to explain multiple embodiments of the proposed protocol.

Table 1

[0044] Assume that Trent has assigned Alice a mutating ID that includes a random number N_A and a secret key K_A for some symmetric cipher and Bob a mutating ID that includes a number N_B and a secret key K_B for some symmetric cipher. In addition, Alice and Bob each have credentials (e.g., A_cred and B_cred, respectively) that are known only to Trent and to the respective holder of the credential.

[0045] Alice can request a session key (e.g., K_AB) from Trent by encrypting her credentials and a publicly known identifier for Bob (e.g., Bi_d) with her secret key K_A and append her number to the result. Alice transmits the result to Bob. A → B: N_AE(K_A, AcredBi_d)

[0046] Bob concatenates his credentials B_cred and a publicly known identifier of Alice (e.g., Aid) with the message from Alice and encrypts the result with his secret key K_B. Bob appends his number K_B to the result of the encryption and sends the resulting message to Trent.

B → T: NBE(KB, B_credA_idN_AE(K_A, A_credB_id)) [0047] Trent identifies that the message has come from Bob because Trent knows that the number N_B is associated with Bob. Trent decrypts the message using K_B and verifies Bob's credentials B_cred. Trent also decrypts and verifies the part of the message constructed by Alice. If Bob's credentials B_cred match his number N_B and his identifier Bi_d provided by Alice and Alice's credentials A_cred match her number N_A and her identifier Ai_d provided by Bob, Trent verifies the request. After verifying the request, Trent generates a message for Alice and a message for Bob. The message for Alice includes a new number N_A ', a new secret key K_A ', Alice's credentials A_cred, and a session key K_AB- Trent encrypts the message for Alice with Alice's current secret key K_A. The message for Bob includes a new number N_B ', a new secret key K_B ', Bob's credentials B_cred, and a session key K_AB- Trent encrypts the message for Bob with Bob's current secret key K_B. Trent sends the messages to Alice and Bob.

T → A: E(K_A, N_A ' K_A ' A_credK_AB)

T → B: E(KB, NB ' KB ' B_credKAB)

[0048] Alice receives her message and decrypts it using her current secret key K_A and retrieves the session key K_AB, her new number N_A ', and her new secret key K_A '■ Bob also receives his message and decrypts it using his current secret key K_B and retrieves the session key K_AB, his new number N_B ', and her new secret key K_B '.

BLACKCONTENT PROTOCOL

[0049] Embodiments of the invention may also implement the Black Content Protocol disclosed in the '402 Publication. The secret keys of mutating IDs (e.g., K_A and K_B) need to remain secret in order to protect the security of transmitted data encrypted with the secret keys. For example, if Trent provides Alice with a new mutating ID encrypted with Alice's current secret key (e.g., K_A), an eavesdropper who has determined Alice's current secret key can obtain Alice's new mutating ID. The eavesdropper can then use the new mutating ID to send false data and/or to obtain the plaintext of future data exchanged between Alice and Trent.

[0050] Eavesdroppers can determine (or attempt to determine) a key used to encrypt particular data by performing an attack. For example, an eavesdropper can perform a brute force attack. A brute force attack includes decrypting ciphertext with every possible key until a key is found that produces coherent or recognizable data (e.g., human readable data). If the eavesdropper obtains or knows the plaintext (or a portion or pattern thereof) corresponding to obtained ciphertext, the eavesdropper can more easily determine whether a correct candidate key has been found. For example, if the eavesdropper obtains ciphertext and knows that the ciphertext includes an individual's name followed by a 4-digit personal identification number ("PIN"), the eavesdropper can apply candidate keys until a candidate key produces the plaintext including the individual's name. The eavesdropper can then assume, with some certainty, that the remaining information included in the generated plaintext corresponds to the PIN.

[0051] However, if the eavesdropper has no knowledge of the plaintext or a pattern of the plaintext (i.e., has no content hint), the eavesdropper's ability to determine whether a correct candidate key has been found is greatly reduced and, perhaps, eliminated. For example, if plaintext includes a random number encrypted with a particular key, no matter how many keys the eavesdropper attempts in a brute force attack, the eavesdropper will have no way to determine whether candidate plaintext is the true plaintext corresponding to the ciphertext. Decrypting an encrypted random number with any candidate key will produce a random number that is equally likely to be the original random number as every other random number produced by every other candidate key. [0052] Referring to the session key example described above involving Alice, Bob, and Trent, if any portion of an encrypted message is recognizable, known, becomes known, or includes any content hints, an eavesdropper could possibly perform a plaintext or partial- plaintext attack on the encrypted message and uncover a secret key of Alice or Bob used to encrypt the message. For example, assume that Alice sends the following message to Bob that is intercepted by an eavesdropper.

A → B: N_AE(K_A, A_cred B_id)

[0053] The eavesdropper can perform a brute force attack on the intercepted message because Bob's identifier Bi_d and the format of the above message are known or public. Thus, the eavesdropper can obtain Alice's secret key K_A and her credentials A_cred- Furthermore, once the eavesdropper obtains Alice's current secret key K_A, the eavesdropper can use Alice's current secret key K_A to obtain all data encrypted with Alice's current secret key K_A, such as her next mutating ID (e.g., N_A ' and K_A ").

[0054] An eavesdropper can use other knowledge about an encrypted message or the communication protocol used to generate an encrypted message to perform brute force attacks. For example, an eavesdropper can use the mutating ID number (e.g., N^), which is passed in the clear, to perform a brute force attack. An eavesdropper could also use knowledge of the algorithm used to generate the mutating ID numbers to perform a brute force attack.

[0055] As pointed out above, keys used to encrypt undiscoverable or "black" data (i.e., data that is random or has no content hints) cannot be easily determined or discovered using a brute force attack, since an eavesdropper will be unable to determine when a correct candidate key is found. Keys used to encrypt discoverable or "white" data (i.e., data that is known, may be later disclosed, is recognizable, or has a known or easily guessed format), however, can (theoretically) be determined using a brute force attack. When the discoverable data and the undiscoverable data are encrypted together or with the same encryption key (e.g., a recognizable name and a corresponding possibly random PIN encrypted with the same key), a key determined through a brute force attack using the discoverable data is also the key used to encrypt the undiscoverable data and, therefore, the undiscoverable data can be discovered.

[0056] To increase the security of the undiscoverable or secret data, separate keys can be used to encrypt the different types of data (hereinafter referred to as the "Black Content Protocol"). Data included in the black data class can be encrypted with one or more keys that are used only to encrypt black data (hereinafter referred to in this example as "black data keys"). Optionally, data included in the white data class can be encrypted with one ore more keys that are only used to encrypt white data (hereinafter referred to in this example as "white data keys"). It should be understood that the black data keys cannot be determined from (or are unrelated to) the white data keys. In other words, the black and white data keys are chosen (e.g., randomly) so as to avoid creating an predetermined relationship to one another, which differs, for example, from the way in which public and private key pairs are created in public key infrastructure systems. Such private and public keys have a predetermined relationship to one another, often a complex mathematical inverse. It should also be that the data does not need to be separated and placed in contiguous blocks of data according to the data class that the portions of data belong to. For example, one or more keys (e.g., one or more mutating IDs) can be used to encrypt the undiscoverable data (e.g., the secret keys K_A, K_B, and Kc) and one or more keys (e.g., one or more mutating IDs) can be used to encrypt the discoverable data (e.g., BiJ). Since the same keys are never used to encrypt undiscoverable data and discoverable data, the possibility of an eavesdropper determining undiscoverable date is reduced. [0057] As more fully described in the '402 Publication, the Black Content Protocol can be used by the system 20, as shown in FIG. 1, to exchange requests and responses between entities (e.g., the first device 22 and the second device 24) and an authenticator (such as the authenticator device 28). Implementations of the protocol can be used by an entity to request a periodic mutation of a mutating ID, to request an encryption key, and to request a decryption key. Further, an entity (such as the first device 22) can communicate with another entity (such as the second device 24) using the responses from the authenticator device 28. For example, the first device 22 can request an encryption key from the authenticator device 28, use the encryption key to encrypt a message for the second device 24, and send the encrypted message to the second device 24. The second device 24 receives the encrypted message and can request a decryption key from the authenticator device 28, receive a decryption key from the authenticator device 28, and use the decryption key to decrypt the encrypted message.

MUTATEVGLOCKBOXARCHITECTURE

[0058] As disclosed in the '402 Publication, the mutating identifiers on the first device 22 and the second device 24 may be stored in a secure memory device, referred to as a mutating lock box. The mutating identifiers stored in the mutating lock box can be encrypted to reduce the possibility of being compromised by a brute force attack. Further, in some embodiments, the data stored in the mutating lock box is separately encrypted, as described above and in the '402 Publication, such that black data and white data are not encrypted using the same keys. Activating or opening the mutating lock box can require multiple steps or factors. For example, an entity attempting to activate the mutating lock box may be required to provide a user password or a personal identification number. Two alternative embodiments of a mutating lock box are described below. [0059] FIG. 2 is a depiction of a system 40 configured to use a mutating lock box. The system 40 includes a client device 42, which corresponds to the first device 22 or second device 24 discussed above, and a trusted key server 44, which corresponds to the authenticator device 28 discussed above. As described above, both the first device 22 and the second device 24 have mutating identifiers and other cryptographic content associated with the use of the Mutating Identifier and, perhaps, Black Content Protocols stored on their memory modules. For the purposes of this description of the mutating lock box architecture, it is assumed that the mutating identifiers and other cryptographic elements are stored in mutating lock boxes on both the first device 22 and the second device 24. In order to use the mutating identifiers and other cryptographic elements, the first device 22 and the second device 24 must first open their mutating lock boxes using the techniques described below. The client device 42 will be used to discuss the systems and processes that are used by both the first device 22 and the second device 24 when they need to open their mutating lock boxes and extract their mutating identifiers and other cryptographic elements. [0060] As depicted in FIG. 2, the client device 42 and the key server 44 are connected to each other via a two-way communication link 46. The two-way communication link 46 may include one or more networks or communication systems, such as a private network (i.e., an intranet), the Internet, the telephone system, wireless networks, satellite networks, cable TV networks, and various other private and public networks and systems, used in various combinations. The two-way communication link 46 may transfer data between the client device 42 and the key server 44 using wired communications and/or wireless communications or other physical media suitable for carrying data from one entity to another. [0061] The client device 42 and the trusted key server 44 each include a processor 52 (e.g., 52a ad 52b), a computer-readable storage medium such as a memory module 54 (e.g., 54a and 54b), and an input/output module 56 (e.g., 56a and 56b). It should be understood that the components shown in FIG. 2 are exemplary and can be combined and distributed in various arrangements and configurations. For example, a memory module 54 can be included in a processor 52 and/or an input/output module 56 in place of or in addition to being included as a separate component. The input/output modules 56 can also be located in an apparatus external to the device housing the corresponding processor 52. Other computer- readable storage media, for example optical, electronic, magnetic, or other types of storage media, can also be used.

[0062] The processor 52 can include one or more processors or similar circuitry. The memory modules 54 store instructions and data retrieved and executed by the processor 52. The functions performed by each processor 52, and consequently the instructions and data stored in the memory module 54 of each device, can be configured based on the role a particular device.

[0063] In one embodiment (the "first embodiment"), the processor 52a for the client device 42 is configured to run software that implements the mutating lock box. FIG. 3 A is a depiction of one embodiment of the mutating lock box 60. The mutating lock box 60 includes mutating content 62 that is encrypted with a strong encryption mechanism (i.e., an encryption mechanism that uses a large enough key that a brute force attack is impractical). The mutating content 62 may include one or more mutating identifiers, one or more cryptographic keys for encrypting white data, one or more cryptographic keys for encrypting black data, and one or more shared secrets. The cryptographic key that is used to decrypt the mutating content 62 is not stored on the memory module 54a of the client device 42. Thus, the user of the client device 42 is unable to access the mutating content 62 without first obtaining the appropriate cryptographic key from the key server 44. In addition, the mutating lock box includes a mutating content identifier 64, which the key server 44 uses to identify the cryptographic keys associated with the digital content 62. [0064] FIG. 3B is an alternative embodiment of a mutating lock box 60b. In the embodiment of FIG. 3B, the lock box includes multiple drawers 66. Each drawer 66 includes its own mutating content 62. The mutating content 62 in each drawer 66 is encrypted with a strong encryption mechanism which uses a cryptographic key that is known only to the key server 44. In addition, each drawer 66 includes its own mutating content identifier 64, which the key server 44 uses to identify the cryptographic keys associated with the mutating content 62.

[0065] The processor 52b for the key server 44, is configured to run software which is capable of responding to a requests for the appropriate key from the client device 42. FIG. 4 is a depiction of one embodiment of the key server software 70. The key server software 70 includes a database 72 which stores a number of associated mutating content identifier/cryptographic key pairs 74. The database 72 allows the processor 52b for the key server 44 to identify the cryptographic key 76 that is associated with a given mutating content identifier 64. It should be understood that other embodiments of the invention may include other mechanisms or data structures that are suitable for associating a content identifier 62 with a cryptographic key.

[0066] As shown in FIG. 2, each device includes an input/output module 56 that interfaces with the communication link 46. It should be understood that although the devices as shown are connected to each other by a single, direct connection, the devices may be connected via one or more wired or wireless connections over one or more networks or communication systems. Each input/output module 56 can also interface with additional devices over the same or additional communication links. As directed by a processor 52, each input/output module 56 can output data to another device. Similarly, each input/output module 56 can receive data from another device and forward the data to the associated processor 52 and/or memory module 54. As noted above, the input/output module 56 of a particular apparatus can be located external to the apparatus housing the processor 52 and/or the memory module 54.

[0067] An example of an open mutating lock box transaction for this first embodiment is described below. In this example, the client device 42 requests a cryptographic key from the key server 44 which the client device 42 uses to decrypt the mutating content 62. Alice (A) represents the client device 42 and Trent (T) represents the trusted key server 44. Carol (C) can also represent a third device included in the system 40. The symbols listed in Table 1 are also used to describe this embodiment.

[0068] FIG. 5 is a depiction of the first embodiment of an open lock box transaction 80. The open lock box transaction 80 includes a request 82 and a response 84. Alice initiates the open lock box transaction 80 by transmitting the request 82 to Trent. The request 82 includes a content identifier 82a (contentID), an encrypted pre-master secret 82b, an encrypted authorization message 82c, and a message authentication code 82d (MAC_Req). Alice prepares the request 82 by retrieving the mutating content identifier 64 from the lock box on her memory module 54a. As described above (referring to FIG. 3A), this mutating content identifier 64 (contentID) is a unique value that corresponds to a cryptographic key that is stored on Trent's memory module 54b. The mutating lock box on Alice's memory module 54a may include only one piece of mutating content 62, in which case Alice may have only one mutating content identifier 64 that she can send to Trent. Alternatively, (referring to FIG. 3B) the lock box on Alice's memory module 54a may include multiple pieces of digital content 62, each stored in a drawer 66 as described above. In this case, Alice may have more than one content identifier 64 stored on her memory module 54a and chooses the content identifier 64 that corresponds to the mutating content 62 that she wishes to access. [0069] Next, Alice prepares the encrypted pre-master secret 82b. Alice generates a pre- master secret (secret) which is a random value of a certain size (i.e., 48 bytes). Alice may generate the pre-master secret using a random number generating device, a pseudo-random number generating function, or any other device or method that is suitable for generating data that is generally random. In one embodiment, Alice uses a pseudo-random number generating function (F(x)) to generate the pre-master secret.

F(x) = secret

The pseudo-random number generating function (F(x)) accepts a value (x) as its input and produces a value (secret) as its output. As described below, the disclosed embodiments of the open mutating lock box transaction utilize pseudo-random number generating functions to produce cryptographic keys. These are one-way functions (e.g., hashes) that produce the same output for any given input, allowing Alice and Trent to separately produce the same cryptographic keys by providing the same input to the same pseudo-random number generating function. The pseudo-random number generating functions described below may each be distinct one-way functions or the same one-way functions that use a slightly modified and pre-established seed value (in addition to at least a portion of the pre-shared secret) as inputs.

[0070] Alice uses a public key cryptographic algorithm, such as RSA (E_RSA), and Trent's public key (K_pubiic) to encrypt the pre-master secret.

ERSA(Kpubiic, secret)

[0071] Alice prepares the encrypted authorization message 82c. Alice's authorization message (Auth) includes information that is known only to Alice and to Trent. In one embodiment, the authorization message (Auth) consists of a cryptographic hash of a password that Alice's user entered prior to the preparation of the request 82. Alice uses a pseudo-random number generating function (F_Auth) (the "authorization value function") and the pre-master secret (secret) to generate a cryptographic key (K_Auth) (the "authorization value key"). Fauth (secret) = K_auth

Alice uses the authorization value key (K_AUΛ) and a symmetric encryption algorithm (E) to encrypt the her authorization message.

E(KAuth, Auth)

[0072] Finally, Alice creates the message authentication code for the request 82d (MACReq). Alice generates a cryptographic key (K.MACReq) (the "request message authentication key") using a pseudo-random number generating function (F_MACReq) (the "request message authentication function") and the pre-shared secret.

FMACReq (secret) = KitfACReq

Alice uses the request message authentication key (K.M_ACReq) to generate the message authentication code for the request 82d (MAC_req) by computing a cryptographic hash of the content identifier, the encrypted pre-master secret, and the encrypted authorization code.

H(K_MACReq, contentID + ERSA(K_pubι_ic,secret) + E(K_Auth, Auth)) = MAC_Req Alice transmits the request 82 to Trent.

A → T(contentID + E_RS_A(K_pubι_ic, secret) + E(K_Auth, Auth) + MAC_Req)

[0073] Trent receives the request 82 and determines whether the content identifier 82a is valid (e.g., that it is associated with a cryptographic key on Trent's memory module 54b). If Trent determines that content identifier is valid, Trent uses his private key (Kpήva_te) and the public key cryptographic algorithm (E_RSA) to decrypt the encrypted pre-master secret (secret). Next, Trent generates the request message authentication key (K.MACR_eq) using the request message authentication function (F_MACReq) and the pre-master secret, as described above. Trent uses the request message authentication key (K_MACReq) and the cryptographic hash function to compute the request message authentication code for the request 82 that he received (MACτ_rent).

Ffiash (KMAC, contentID +

+ E(K_Auth + Auth)) = MAC_Trent If the value of the message authentication code that Trent calculates (MACτ_rent) is equal to the message authentication code 82d that was transmitted as part of the request 82, Trent determines that the request 82 is valid and was not altered by a third party (i.e., Carol) or otherwise corrupted during transmission.

[0074] Trent uses the authorization value function (F_Auth) and the pre-master secret (secret) to generate the authorization value key (K_AUΛ)-

F_Auth(secret) = K_Auth

Trent then uses the authorization value key (K_AUΛ) to decrypt the encrypted authorization information 82c that was transmitted as part of the request 82. Trent verifies that the authorization information (Auth) is valid (e.g., that the hash of the user password matches the value that Trent associates with Alice's user). If Trent determines that Alice's authorization information is valid, he prepares the response 84.

[0075] The response 84 includes the encrypted cryptographic key that corresponds to the content identifier (K_content) 84a, optional mutation information 84b, and a message authentication code for the request 84c (MACRe_sp).

[0076] First, Trent prepares the encrypted cryptographic key 84a. Trent retrieves the cryptographic key that is associated with the mutating content identifier 64

(the "content identifier key"). Next, Trent uses a pseudo-random number generating function (FR_esp) (the "response key function) and the pre-master secret to generate an encryption key (K_Resp) (the "response key").

F_Resp(secret) = K_Resp

Trent uses a symmetric encryption algorithm (E) and the response key (K_Resp) to encrypt the content key.

E(K._Resp, K_content) [0077] Second, Trent prepares the encrypted mutating information 84b, if necessary. The response 84 may include mutating information (M_lnf0), for example, to change the mutating content identifier 64 or the encryption key that is associated with the mutating content 62. Trent generates the mutating information (M_1Of0) (e.g., a new content identifier or a new copy of the mutated content encrypted with a new cryptographic key) and uses a pseudo-random number generating function (F_MUO (the "mutating function") and the pre-shared secret to generate a cryptographic key (K_MUO (the "mutating key").

F_Mut(secret) = K_Mut

Trent encrypts the mutating information (Mw₀) with a symmetric algorithm (E) and the mutating key (K_Mutatin_g).

E(K_Mut, Mlnfo)

[0078] Finally, Trent prepares a message authentication code for the response 84c (MACResp). Trent uses a pseudo-random number generating function (FM_ACResp) (the "response message authentication function") and the pre-master secret to generate a cryptographic key (K_MACR∞_P) (the "response message authentication key").

FMACResp(secret) = KMACResp

Trent uses a cryptographic hash function and the response message authentication key (K.MACResp) to generate a message authentication code for the response(MACRe_sp).

H(KMACResp, E(KR_esp,K_contenl) + [ E(KMutMlnfo)]) ⁼ MACR_esp

Trent transmits the response 54 to Alice.

T→A(E(K_Resp,K_content} + [ E(K_Muta, Minfo)] + MAC_Resp)

[0079] Alice receives the response 84 and uses the response message authentication function (FMACResp) and the pre-master secret to generate the response message authentication key (K_MACResp).

FMACResp(secret) = K_MACResp Alice uses the cryptographic hash function and the response message authentication key to compute a message authentication code (MAC _Ali_ce) for the response 84 that she received from Trent.

H(K-MACR_esp, E(K.R_esponse,K_contenJ + [ E(KMu_t, Mfφ)]) = MAC Alice

If the value of the message authentication code that Alice calculates (M AC Alice) is equal to the message authentication code that was transmitted as part of the response 84, Trent determines that the response 54 was not altered by a third party (i.e., Carol) or otherwise corrupted during transmission.

[0080] Alice generates the response key (K_Resp) using the response key function (F_Resp) and the pre-master secret.

F_Resp(secret) = K_Resp

Alice then uses the response key (K_R^_P) to decrypt the cryptographic key (K-content) that is associated with the content identifier. Alice uses the cryptographic key (Kcontent) to decrypt the mutating content 62 associated with the mutating content identifier 64 (contentID). [0081] Finally, Alice generates the mutating information key (K_MUO using the mutating information function (F_MUO and the pre-master secret.

F_Mut(secret) = K_Mut

Alice uses the mutating information key to decrypt the encrypted mutating information (M_1Hf0) that was included in the response 54 and uses the mutating information to update her mutating lock box (e.g., by replacing the content identifier or the encrypted data). [0082] As explained above, the cryptographic method used to protect the mutating content 64 in the mutating lock box 60 is strong enough that a brute force attack is impractical. Therefore, even if Carol is able to obtain a copy of the encrypted mutating content 62 she will not be able to access it without the appropriate cryptographic key (Kcontent)- Further, Carol can only obtain the appropriate cryptographic key (Kcontent) if she knows the password or personal identification number that is associated with the mutating content 62.

[0083] One method that Carol may use decrypt the mutating content 62 is to attempt to discover the appropriate password using a dictionary attack. For example, Carol could systematically request a cryptographic key (K_content) from Trent using every possible password value until she obtains the key that decrypts the mutating content 62. However, this suspicious behavior will alert Trent that an attack is under way and he can respond accordingly (e.g., by blocking all future communications with Carol or by noting that the cryptographic key (K_cOntent) for the protected digital content 62 in question has been compromised). Therefore, in this first embodiment, even is she obtains an illegitimate copy of the protected content, Carol is not able to use it.

[0084] However, Carol may be able to monitor the transmissions between Alice and Trent and discover the password. For example, referring again to FIG. 5, Carol may have access to a request 82 that is transmitted from Alice to Trent. As described above, this request 82 includes a pre-master secret (secret) that is encrypted with Trent's public key (Kp_ut,), and Alice's encrypted authentication value. To engage in an attack on this request 82 Carol may generate a large number of possible values for the pre-master secret (secret) and encrypt them using Trent's public key (which should not be hard to obtain as it is meant to be used by certain members of the public). In addition, Carol may prepare a hash of each possible password value and store it for later use as described below. Carol then compares each one of the encrypted candidate pre-master secrets that she has generated with the encrypted pre-master secret in the request 52. If Carol finds a match, then she has discovered the value of the pre-master secret (secret) used by Alice and Trent during the open mutating lock box transaction 80 in question. Carol can use this pre-master secret and the authorization key function (K_AUΛ) to decrypt the authentication information and obtain the password hash. Carol can then compare each one of the possible password hashes that she generated to the decrypted password hash. Once again, if Carol finds a match then she has discovered Alice's password. Once Carol has access both to the encrypted mutating content 64 and the authentication value (Auth), she may engage in an open mutating lock box transaction with Trent and he will provide her with appropriate cryptographic key (K_con_ten_t)- [0085] In one alternative embodiment (the "second embodiment"), the mutating lock box is modified to address this and other vulnerabilities. In this second embodiment of the mutating lock box, the authentication value includes, in addition to a user password, information that is embedded into the mutating lock box and the client device 42. Therefore, even if Carol has obtained Alice's password, she will not be able to reproduce the authentication value without obtaining the client device 42 and disassembling all of its software to obtain the appropriate authentication information. Thus, this second embodiment of the present invention is intended to make a pre-computational attack on Alice's password less feasible.

[0086] Referring again to FIG. 2, the second embodiment of the mutating lock box is implemented by a system 40 having a client device 42 and a trusted key server 44 which communicate with one another using a two-way communication link 46. FIG. 6 is a depiction of a first device 42 that is configured with the second embodiment of the mutating lock box 100. This second embodiment of the mutating lock box 100 includes a number (e.g., 2 as shown) of secret drawers 102, a request drawer 104, as well as other cryptographic elements that will be described below. Each secret drawer 102 includes a secret drawer identifier 106 (ID_N), a length variable 108 (length_N), and the encrypted mutating content 110. The secret drawer identifier 106 is a unique value that is associated with the request drawer 102 in which it is stored. The length variable 108 indicates the length (in bytes) of the secret drawer 102. The mutating content is encrypted with a symmetric encryption algorithm (E) and a key 109 (K_N) that is stored on the key server 44, and is not available on the client device 42.

[0087] The information in the request drawer 104 is used by the client device 42 to request a key 109 (K_N) to decrypt one of the secret drawers 102a. The request drawer 104 includes a mutating lock box identifier 112 (ID_BOX) which is a unique value that is associated with the mutating lock box on the key server 44. In addition, the request drawer 104 includes the following information which is encrypted with a cryptographic key 113 (K_RD) (the "request drawer key"): 1) a client/server key 114 (K_cS), a client/server hash key 116 (K_h- _cs), and a password random number 118 (Rp). The client/server key 114 (K_cS) is a cryptographic key which is also stored on the key server 44 and used to encrypt a message that the key server 44 transmits to the client device 42 as described below. The client/server hash key 116 (K_h-cs) is also stored on the key server 44 and is used to create message authentication codes for the messages that are transmitted between the client device 42 and the key server 44 as described below. The password random number (P_R) is a random value that is used by the client device 42 to create an authentication value as described below. The request drawer key 113 (K_RD) is not known by the client device 42. To discover the request drawer key 113 (K_RD) the client device 42 must utilize information in the message that it receives from the key server 44. The process used by the client device 42 to discover this message is described below.

[0088] In addition to the secret drawers 102 and the request drawer 104, the memory module 54a for the second embodiment of the mutating lock box 100 includes other information that is stored within the mutating lock box 100 or elsewhere on the client device 42. The mutating lock box 100 also includes a first mutating lock box random number 120 (RLBI), a second mutating lock box random number (R_LBΣ), and a public key that is used in connection with a public key encryption algorithm, such as RSA, for the key server 44 (Kp_ub). [0089] The memory module 54a of the client device 42 includes a client device random value 126 (R_CD) which is a unique value that is associated with the client device 42 by the key server 44. Further, the memory module 54a of the client device includes system information 128 (sysinfo). The system information is a cryptographic hash of information about the client device, including: 1) persistent information stored on the client device 42 and 2) information gathered during the installation of mutating lock box 100 on the client device 42. The client device random value 126 (R_CD) and the system information are stored in a location on the memory module 54a of the client device 42 that is not associated with the mutating lock box 100.

[0090] The processor 52b on the key server 44 in this second embodiment is configured to run the key server software. FIG. 7 is a depiction of one embodiment of the key server software 200. The key server software 200 includes a secret drawer key database 210, an authentication value database 212, and a client/server key database 214. The secret drawer database 210 associates a cryptographic key 109 (K_N) with a lock box identifier 112 (ID_BOX) and a secret drawer identifier 106 (ID_N)- The secret drawer database 210 is configured such that if the key server 44 is provided with a mutating lock box identifier 112 (ID_BOX) and a secret drawer identifier 106 (ID_N), it can retrieve the appropriate cryptographic key 109 (K_N) for the secret drawer 102 in question.

[0091] The authentication value database 212 associates a mutating lock box identifier (ID_BOX) with an authentication value 213 (Auth). FIG. 8 is a depiction of the authentication value 213 (Auth) of this second embodiment. The authentication value 213 (Auth) includes: 1) a password salt 213a (saltpw), 2) a password hash 213b, 3) the second mutating lock box random value 122 (R_LB2), 4) a key server random value 213c (R_s), and the system information value 128 (sysinfo).

H (salt pw + H(Rp + pwd), R_LB2 + sysinfo) = Auth The password salt value 213a (saltpw) is a random value known to the client device 42 and the key server 44. The password salt value (saltpw) adds randomness and increases the possible search space for the authentication value. The password hash is a cryptographic hash of the client device's password random value 118 (Rp) and a password value (pwd), that may be a password that is entered by the user of the client device 42. The key server random value 213c (R₅) is a random value that is generated by the key server 44 and distributed to the client device 42 as part of the open mutating lock box transaction. The other values used to compute the authentication value 213 (Auth) are described above.

[0092] Finally, the client/server key database 214 associates a client/server key 114 (Kc₈) and a client/server hash key 116 (Kh_-cs) with a mutating lock box identifier 106 (IDB_0X). [0093] An example of an open mutating lock box transaction of this second embodiment is described below. In this transaction, the client device 42, which corresponds to the first device 22 or the second device 24 as described above, requests a cryptographic key 109 (KN) for the encrypted mutating content in one of the secret drawers 102 in its mutating lock box 100 from the key server 44, which corresponds to the authenticator device 28 described above. In this example, Alice (A) represents the client device 42 and Trent (B) represents the trusted key server 44. Carol (C) can also represent a third device (not shown). The symbols listed in Table 1 are also used in this description.

[0094] FIG. 9 is a depiction of the open mutating lock box transaction 240 of the second embodiment of the present invention. The open mutating lock box transaction 240 includes four messages, a first request 242, a first response 244, a second request 246, and a second response 248. Alice initiates the open mutating lock box transaction 240 by transmitting a first request 242 to Trent. The first request includes the mutating lock box identifier 112 (IDβox) from the request drawer 104, the secret drawer identifier 106 (ID_N) for the secret drawer 102 that is being opened, and a nonce ("Alice's nonce") 250 (NEAiice) generated by Alice for the open mutating lock box transaction 240.

A → T (ID_Box + ID_N + N_AHce)

[0095] Trent receives the first request 242 and uses the mutating lock box identifier (ID_BOX) 112 and the secret drawer identifier 106 (ID_N) to identify the appropriate client/server key 114 (Kcs) and client/server hash key 116 (Kh_-cs) on his memory module 54b. Trent prepares the first response 244. The first response 244 includes a nonce which is generated by Trent ("Trent's nonce") 260 (NEτ_rent) and the key server random number 213c (R_s), both of which are encrypted using a symmetric encryption algorithm (E) and the client/server key 114 (K_cs). In addition, the first response 244 includes a message authentication code (MACRespO 264 which is generated using the client/server hash key 116 (κh-cs)-

H(K_h__cs, E(K_CSI N_Trent + Rr_ren_t)) = MAC_Resp,

[0096] Trent transmits the first response to Alice.

T→ A (E(Kc₅, Η Trent + ΛϊW + MAC_Respl)

[0097] Alice receives the first response 244. As discussed above, both the client/server key 114 (Kc₅) and the client/server hash key 116 (Kh_-cs) are stored in the request drawer 104 of the mutating lock box 100. However, they are encrypted with an encryption algorithm (E) and the request drawer key 113 (K_RD) and Alice cannot decrypt them because she does not know the request drawer key. However, Alice may discover the request drawer key 113 (K_RD) by using the first response 244. The request drawer key is generated using a pseudorandom number generating function (F_RD(X)) (the "request drawer function") and the following information: 1) a request drawer salt value (salt_Ro), 2) the client device random number 126 (R_CD), 3) the first mutating lock box random number 120 (R_LBI), and 4) a the system information (sysinfo).

F_R1)(SaIt_RD + Rc_D + RLBI + sysinfo) = KR₀ The request drawer salt value (salt_Ro) is a random value of a certain length that is unknown to Alice. In order to generate the correct request drawer key, Alice must determine the correct request drawer salt value (salt_Ro). FIG. 10 is a flow chart which depicts the process 280 that Alice uses to generate the request drawer key 113 (K_RD). Alice generates a potential request drawer salt value (saltRo') 282. Next, Alice uses the potential salt value (salt_Ro') to generate a candidate request drawer key (K_RD') 284.

Fju)(saltRD ' + RcD + RLBI + Syslnfo) = KRD '

Alice then uses the candidate request drawer key (K_RD') to decrypt the encrypted portion of the request drawer 104, generating a candidate client/server key (K_c8') and a candidate client/server hash key (K_cS-h') 286. Alice uses the candidate client/server hash key (K_cS-h') to generate a potential message authentication code (MAC) for the first response 288.

H(K_h-_cs ', E(K_CS, Nrrent + RjrenJ) = MAC

Alice then compares the potential message authentication code (MAC) that she generated using the candidate client/server hash key (K_h-cs') to the message authentication code for the first response 244 (MACRespO 290. If both message authentication codes are equal 292, then Alice has discovered the appropriate request drawer key 113 (K_RD), client/server key (K_cS), and client/server hash key (K_cS-h) and the process is complete 294. If the codes are not equal, Alice must start the process again 296 (i.e., by generating the next potential value for the request drawer salt value (salt_Ro)). The process described above requires that Alice generate and test a number of potential request drawer salt values (salt_Ro) which involves some computational expense. However, this computational expense is relatively small when compared to the computational expense for a third party (i.e., Carol) that attempts to derive the request drawer key 113 (K_RD).

[0098] Alice uses the client/server key 114 (K_c5) to decrypt the encrypted portion of the first response 244 and extracts Trent's nonce 260 (NEτ_rent) and the key server random value 213c (R_s). Alice then prepares the second request 246. The second request 246 includes: 1) an encrypted pre-master secret 300 (secret), 2) an encrypted authentication value 213 (Auth), and 3) a message authentication code for the second request 302 (MAC_Req₂). Alice generates the encrypted pre-master secret 300 (secret). She generates the pre-master secret (secret) (using the same method described in the previous embodiment) and encrypts it with a public- key encryption algorithm, such as RSA, and Trent's public key (Kp_ub).

ERSA(K_pub, secret)

[0099] Next Alice prepares the authentication value 213 (Auth). Referring again to FIG. 8, the authentication value 213 (Auth) is a cryptographic hash including: 1) a password salt value 213a (saltpw), 2) the password hash 213b, 3) the second mutating lock box random number 122 (R_LB2), 4) the key server random value 213c (Rs), and 5) and the system information (sysinfo). Alice generates a cryptographic key for the authentication value (KA_UHI) (the "authentication value key") using a random function (F_AuthOO) and the following information: 1) Alice's nonce 250 (NEAiice), 2) Trent's nonce 260 (NEτ_rent)₅ and 3) the pre- master secret (secret).

F_Auth(NE_An_ce + NErrent + secret) = K_Auth

Alice uses the authentication value key (K_Auth) and a symmetric encryption algorithm (E) to encrypt the authentication value.

E(K_Authι salted + H(Rp + pwd) + R_LB2 + R_s + sysinfo)

Finally, Alice generates a message authentication code 302 (MAC_Req2) for the second request, using the client/server hash key (K_cS-h).

H(K_cs-_h, Ens^K_pub, secret) +

E(K_Auth, salt_pwd + H(Rp + pwd) + R_LB2 + Rs ⁺ sysinfo)) = MAC_Req2

Alice transmits the second request 246 to Trent. A → T (E_nSA(K_pUt, secret)

+ E(K_Auth, salt_pwd + H(Rp + pwd) + R_LB2 + Rs + sysinfo) + MAC_Req2

[00100] Trent receives the second request 246 and uses the message authentication code (MAC_req2) to verify that it was not corrupted or modified by a third party (e.g., Carol) during transmission using the client server hash key (H_h-cs)- If Trent finds that the second request 246 is valid, Trent uses the public key encryption algorithm (E_RSA) and his private key (Kpn_V) to decrypt the encrypted pre-master secret 300 (secret) that was included in the second request 246. Trent then generates the authorization value key (K_Auth) using the authorization value function (FA_UΛOO) and the following: 1) Alice's nonce 250 (NEAiice) (which Trent received in the first request 242), 2) Trent's nonce 260 (NEτ_rent) (which Trent generated as part of the first response 244), and 3) the pre-master secret (secret).

F_Auth(NE_Aι_ice, NExrent, secret) = K_Auth

Trent uses the authentication value key (K_Auth) to decrypt the encrypted authentication value 213 (Auth) that was included as part of the second request 246 and verifies that it is the correct authentication value for Alice (i.e., that the authentication value 213 (Auth) in the second request 246 matches the authentication value 213 stored in the authentication value database 212 on Trent's memory module 54b).

[00101] Trent then generates a second response 248. The second response 248 includes an authentication confirmation code 320 (Y/N) which indicates whether he successfully verified the authentication value in the second request 246, an encrypted new secret drawer identifier 322 (IU_N-_new), an encrypted cryptographic key for the secret drawer 109 (K_N), and a message authentication code 326 (MAC_R^). It should be noted that if Trent could not verify the authentication information 213 (Auth), information in this second response 248 will not contain valid data (i.e., it may contain all zeroes or a random value). If Trent is able to verify the authentication data, Trent generates a cryptographic key for the second response 248 (K_ResP2) (the "second response key") using a pseudo-random number generating function (F_resp2(x)) (the "second response function") and the following information: 1) Alice's nonce 250 (NEAh_ce), 2) Trent's nonce 260 (NEτ_rent) , and the pre-master secret (secret).

F_Resp₂(NE_An_ce + NEtre_nt + Secret) = K_Resp2

[00102] Trent uses the second response key (K_Resp₂) and a symmetric encryption algorithm (E) to encrypt a new secret drawer identifier 322 (IUN-n_ew) which replaces the current secret drawer identifier 106 (ID_N) and a cryptographic key to decrypt the information in the secret drawer 109 (K_N).

E(K_Resp2,

+ K_N)

Finally, Trent prepares a message authentication code 326 (MAC_ReSp2) using the client/server hash key l l6 (K_h-cs).

H(K_h._cs, Y/N + E(K_resp2, ID_N-_new + K_N)) = MAC_Resp2 Trent transmits the second response 248 to Alice.

T→ A (Y/N) + E(K_Resp2, ID_N._new + K_N) + MAC_Resp2

In other embodiments, Trent will also include key material to be used to mutate values in the current secret drawer, as in Black Content Protocols. The key material is chosen at random or through the use of a pseudorandom function by Trent. This key material is encrypted with ID_N._new and K_N in the message. In these embodiments, Trent sends this message to Alice.

T→ A (Y/N) + E(K_Resp2, ID_N._new + K_N + KeyMaterial) + MAC_Resp2

[00103] Alice receives the second response 248 and verifies that it is valid using the message authentication code 326 (MAC_R^). Alice generates the second response key (K._Resp2), using the same method as Trent. Alice then uses the second response key (K_Resp2) to decrypt the encrypted portion of the second response 248, and extract the new secret drawer identifier 322 (IU_N-_new) and the cryptographic key for the secret drawer 109 (KN). Alice uses the cryptographic key 190 (K_N) to decrypt the mutating content in her secret drawer 102a. In addition, Alice replaces the old secret drawer identifier 106 (ID_N) with the new secret drawer identifier 322 (IDN-new) value.

[00104] In addition, as part of this embodiment of the open mutating lock box, Alice and Trent may mutate certain components of the mutating lock box 100. Mutating these values adds additional security by ensuring that no two consecutive open mutating lock box transactions 240 are the same. Therefore, any cryptographic information that Carol discovers with respect to one open mutating lock box transaction 240, will not be useful to open the secret drawers after the open mutating lock box transaction 240 has ends. In one embodiment, Alice and Trent mutate the client/server key 114 (K_c5) and the client/server hash key 116 (K_h-cs). The new values for these keys are generated by Alice and Trent using a pseudo-random number generating function and a portion of a large secret from the secret drawer 102 in Alice's mutating lock box 100. Alice places the new client/server key 114 (K_cs) and the client/server hash key 114 (Kh_-C3) in the request drawer 104 of her mutating lock box 100. In addition Alice may generate a new request drawer salt value (salt_Ro') and a new client side random number 126 (R_CD') and create a new request drawer key (K_RDNCW) using the request drawer function.

F_Rn(SaIt_RD ' + R_CD ' + RLBI + Syslnfo) = Kiφ_New

Alice encrypts the request drawer contents, including the mutated client/server key 114 (K_c5) and client/server hash key 116 (K_h-cs) using request drawer key 113 (K_RD) (or the new request drawer key (KR_DNCW) if she created one) and deletes the request drawer key 113 (K_RD) from her memory module 54a. Trent associates the new client/server key 114 (K_cS) and client server hash key 116 (K_h-cs) with Alice's mutating lock box identifier (IDβox) on his memory module 54b so that they can be retrieved during a later open mutating lock box transaction. [00105] In addition, Alice and Trent may mutate the cryptographic key 109 (K_N) that is used to encrypt the secret drawer. The new key (K_N') is generated using a pseudo-random number generating function and a portion of the large shared secret in Alice's secret drawer 102. The contents of the secret drawer are encrypted using the new key (K_N') on Alice's mutating lock box. Both the original key (K_N) and the new key (K_N') are deleted from Alice's memory module 54a. Trent associates the new key with the secret drawer on his memory module 54b.

[00106] In other embodiments, Alice and Trent may wish to mutate the contents of the secret drawer. In these embodiments, the data in the lockbox may be a large secret used for Black Content Protocols or other application. This secret is known by both Alice and Trent. Both Alice and Trent will change the contents in the secret drawer by applying the key material to the unencrypted data. For instance, both could combine the data through bit- wise exclusive-OR, or any other function. In some embodiments, the amount of key material sent is less than the size of the drawer and only a small portion of the data is changed. [00107] Finally, Alice may transmit an acknowledgement 330 to Trent when any mutation is complete and the mutating lock box 100 is closed. For many applications, a particular lockbox should be able to move from one computing environment to another. The protocol is designed to handle two types of lockbox mobility: one that allows authentication of a portable device and one that does not.

[00108] Moving a lockbox from environment to another affects the use oϊSysInfo and software random numbers. If, for instance, the software random number is stored within the client, the client software must follow the lockbox. Further, if the lockbox is on a portable storage device like a USB mass storage class device, then Syslnfo must be computed solely from the USB device. Concerns such as these can be easily resolved, depending on the particular application of the lockbox.

[00109] Consider a lockbox that stores sensitive credit card information used to authenticate purchases. Assume this lockbox is stored on a cell phone along with an application to open the lockbox. Then, the standard lockbox protocol can be implemented without changing.

[00110] However, there may be applications where the lockbox can move from one medium to another. In this case, there is no guarantee that any reasonable Syslnfo can be computed across all computing environments. For these applications, Syslnfo is not used at a cost to security. For instance, the random number that hides the password is now protected solely by the salt and random numbers of the client application. Similarly, for applications that require different instances of client software for one lockbox, the use of R_swi and R_SW2 is compromised.

Claims

CLAIMS What is claimed is:

1. A computer-readable storage medium associated with a first computing device, the computer-readable storage medium having stored thereon a data structure, the data structure comprising: at least one secret drawer including encrypted content, and an identifier associated with a cryptographic key, the cryptographic key capable of decrypting the encrypted content; a request drawer including an identifier associated with the data structure, and data used to generate authentication information, the authentication information used to verify the identity of the first device; wherein the first computing device is configured to communicate with a second computing device having a database populated with a one or more keys, where at least one of the keys enables the decryption of the content in the at least one secret drawer.

2. A computer-readable storage medium as claimed in claim 1, wherein the computer- readable storage medium is a USB memory device and wherein the first computing device is configured with a USB interface.

3. A computer-based method for using a mutating lock box that is stored on a first device, the method comprising: transmitting a first request from the first device to a second device, the first request including a secret drawer identifier, which corresponds to encrypted content that is stored in a secret drawer in the mutating lock box, and a mutating lock box identifier, which corresponds to the mutating lock box; transmitting a first response from the second device to the first device, the first response including cryptographic information used by the first device to generate authentication information; generating authentication information on the first device; transmitting a second request from the first device to the second device, the second request including the authentication information; verifying the identity of the first device on the second device, using the authentication information; transmitting a second response from the second device to the first device, the second response including a cryptographic key that is suitable for decrypting the encrypted content in the secret drawer; and decrypting the cryptographic content in the secret drawer using the cryptographic key on the first device.

4. A computer-based method as claimed in claim 3, wherein generating authentication information includes generating information that is specific to the use of the first device, information that is specific to the second device, and information that is specific to the mutating lock box.

5. A computer-based method as claimed in claim 3, further comprising configuring encrypted content with at least one mutating identifier;

6. A computer-based method as claimed in claim 3, further comprising configuring the second response to include a new identifier for the secret drawer.

7. A computer-based method as claimed in claim 3, further comprising: generating a new encryption key for the secret drawer using an encryption method and cryptographic information which is included n the secret drawer and on the second device; deleting the cryptographic key from the first device; storing the cryptographic key on the second device and associating the cryptographic key with the identifier for the secret drawer; and transmitting an acknowledgement to the second device that the content is encrypted.

8. A computer-based method of decrypting encrypted digital content by a device, the method comprising: sending identification information, wherein the identification information includes the identity of encrypted digital content to be decrypted; receiving a response to sending identification information, wherein said response includes a first data needed to decrypt the encrypted digital content; executing code on the first device to obtain a second data, wherein second data includes data devoid from contents of any computer files accessible by the device; and decrypting encrypted digital content, wherein decrypting requires at least first data and second data.

9. A computer-based method as claimed in claim 8, wherein a user is authenticated prior to decrypting encrypted digital content.

10. A computer-based method as claimed in claim 8, wherein the encrypted the authentication value is derived from a password entered by the user of the first device.

11. A computer-based method as claimed in claim 8, wherein the request includes a new identifier that replaced the original identifier and is associated with the encrypted digital content.

12. A computer-based method as claimed in claim 8, wherein the request includes new encrypted digital content that replaces the original encrypted digital content.

13. A computer-based method as claimed in claim 8, wherein the encrypted digital content includes at least one mutating identifier.

14. A computer-based method of decrypting encrypted digital content by a device, the method comprising: sending identification information, wherein the identification information includes the identity of encrypted digital content to be decrypted; sending authentication information, wherein successful verification of the authentication information is necessary for authorization to decrypt encrypted digital content; receiving decryption data in response to sending identification information and sending authentication information wherein decryption data is needed to decrypt the encrypted digital content; and decrypting encrypted digital content, wherein decrypting requires the decryption data.

15. A computer-based method as claimed in claim 14, wherein said sending steps are combined.

16. A computer-based method as claimed in claim 14, further comprising: executing code on the first device to obtain a second data, wherein second data includes data devoid from contents of any computer files accessible by the device; and decrypting encrypted digital content further requires second data.

17. A computer-based method of decrypting encrypted digital content that is stored on a first device, the method comprising: transmitting a first request from the first device to a second device, wherein the first request includes at least one identifier that is associated with the digital content; transmitting a first response from the second device to the first device, wherein the first response includes a first cryptographic key; receiving the first response on the first device and using information in the first response to generate a first cryptographic key; decrypting encrypted authentication information that is stored on the first device using the first cryptographic key; transmitting a second request from the first device to the second device, wherein the second request includes the authentication information, and using the authentication information to verify the identity of the first device; transmitting a second response from the second device to the first device, wherein the second response includes a second cryptographic key; and receiving the second response on the first device and using the cryptographic key to decrypt the encrypted digital content.

18. A computer-based method as claimed in claim 17, wherein the authentication information includes data that is unique to the first device.

19. A computer-based method as claimed in claim 18, wherein the authentication information includes a value that is derived from a password entered by the user of the first device.

20. A computer-based method as claimed in claim 19, wherein the password cannot be derived from the authentication information stored on the second computing device.

21. A computer-based method as claimed in claim 19, wherein the password cannot be derived from the second request.

22. A computer-based method as claimed in claim 17, wherein the encrypted digital content includes at least one mutating identifier.

23. A system for decrypting encrypted digital content, the system comprising: a first device configured to transmit an identifier that is associated with the encrypted digital content and an authentication value to a second device, receive a cryptographic key from the second device, and decrypt the encrypted content using the cryptographic key; and a second device configured to receive the identifier from the first device, verify the identity of the first device using the authentication value, locate the cryptographic key that is associated with the identifier, and transmit the cryptographic key to the first device.

24. A system as claimed in claim 23, wherein the authentication value is derived from a password that is entered by the user of the first device.

25. A system as claim in claim 23, wherein the encrypted digital content includes at least one mutating identifier.

26. A system for decrypting encrypted digital content, the system comprising a first device and a second device, the first device being in operative communication with the second device, wherein: the first device is configured to transmit a first request to a second device, the first request including at least one identifier that is associated with the encrypted digital content; receive a first response from the second device, the first response including a first cryptographic key and a message authentication code; decrypt encrypted authentication information using a cryptographic key that is derived using the first response; transmit a second request to the second device, the second request including the authentication information; receive a second response from the second device, the second response including a second cryptographic key; and decrypt the encrypted digital content using the second cryptographic key; and the second device is configured to receive the first request from the first device, the first request including the identifier that is associated with the encrypted digital content; transmit a first response to the first device, the first response including the first cryptographic key and the message authentication code; receive a second request from the first device, the second request including the authentication information; verify the identity of the first device using the authentication information; and transmit a second response to the first device, the second response including the second cryptographic key.

27. A system as claimed in claim 26, wherein the authentication information includes data that is unique to the client device.

28. A system as claimed in claim 26, wherein the authentication information includes a value that is derived from a password that is entered by the user of the first device.

29. A system as claimed in claim 28, wherein the encrypted information includes at least one mutating identifier.

30. A first device configured to store encrypted digital information, the first device comprising a processor and a memory module, wherein: the processor is configured to transmit an identifier that is associated with the digital content and authentication information to a second device; receive a cryptographic key from the second device; and decrypt the encrypted digital information using the cryptographic key; and the memory module is configured to store the encrypted digital information; and an identifier that is associated with the encrypted digital information.

31. A first device as claimed in claim 30, wherein the encrypted digital information includes at least one mutating identifier.

32. A first device configured to store encrypted digital information, the first device comprising a processor and a memory module, wherein: the processor is configured to transmit a first request to a second device, wherein the first request includes at least one identifier associated with the encrypted digital information; receive a first response from a second device, wherein the first response includes cryptographic information; derive a first cryptographic key suitable for decrypting encrypted authentication information that is stored on the memory module of the first device using the cryptographic information in the first response; transmit a second request to the second device, wherein the second request includes the authentication information; receive a second response from the second device, wherein the second response includes a second cryptographic key; and decrypt the encrypted digital information using the second cryptographic key; and the memory module is configured to store the encrypted digital information; at least one identifier that is associated with the encrypted digital information; and the encrypted authentication information.

33. A first device as claimed in claim 32, wherein the first device is a client and the second device is a key server.

34. A key server configured to implement a mutating lock box protocol for decrypting encrypted digital information stored on a client device, the key server comprising a processor and a memory module, wherein: the processor is configured to receive a first request from the client device, wherein the first request includes at least one identifier associated with the encrypted digital information; transmit a first response to the client device, wherein the first response includes cryptographic information for deriving a first cryptographic key suitable for decrypting encrypted authentication information that is stored on the client device; receive a second request from the client device, wherein the second request includes the authentication information; transmit a second response to the client device, wherein the second response includes a second cryptographic key for decrypting the encrypted digital information; and the memory module is configured to store the cryptographic information for deriving the first cryptographic key, and the second cryptographic key.