Title of Invention

A DEVICE AND SYSTEM INTENDED TO USE SECRET INFORMATION TO ACCESS TO A DIGITAL CONTENT

Abstract

This invention relates to a device intended to use secret information to access to a digital content, said device containing a memory space (101) able to contain a list of identifiers (InflDuser i) of secret information items, said secret information items being stored in a tamper-proof memory space (21) of a server (20) remote from said device; a tamper-proof memory (113) able to store secret information items; and means for retrieving a secret information from said remote server (20) when said secret information is not available in the tamper-proof memory (113) of said device.

Full Text

Field of the invention The invention relates generally to secure storage of secret information and more particularly to a system and a process for securely storing secret information and to an apparatus and a server to be used in said system. The invention also relates to a method for distribution of a digital content. Background art With the advent of digital TV, and copy protection, the access to content will be protected by rights. These rights may have many forms like entitlements, or dedicated decryption keys. The notion of rights might be extended to any secret information. All these type of data have in common that they need to be stored in a safe place. Today none of the consumer devices has such tamper proof place. The price would be prohibitive. Only smart cards offer sufficient security. Unfortunately the size of memory of smart cards, and thus their storage capability, is limited. Furthermore a smart card can break down, or be lost. So today, once the user mislays his secret data, he will have no simple way to retrieve them. If these data represent user's rights acquired on digital content (for example the right to view a film or to listen to music) it may be prejudicial to the user if he loses these rights he has paid for. Summary of the invention The present invention is therefore directed to the problem of finding a way of safely and securely storing secret data to be used by a single device or by a device in a network. Another problem to be solved by the invention is to find a way of retrieving these secret data if the device or the network has lost them. The invention relates to a system for securely storing secret information to be used by a device wherein said secret information is stored in a remote server. The device may be part of a home network and preferably the secret information is used by said device to access to a digital content. Therefore, the remote server acts as a bank which maintains in a safe place digital secrets. The invention proposes an apparatus containing secret information to be used by a device to decrypt a digital content and having means for sending said secret information to a remote server in order to store said information in said remote server, said server being remote from said device. The invention also proposes a system for securely storing secret information comprising an apparatus containing said secret information, a device meant to use said secret information to decrypt a digital content and a server remote from said apparatus and from said device, wherein said apparatus comprises means for sending said secret information to said server and wherein said server comprises means for storing said secret information. The apparatus may be part of said device, or may belong to the same home network as said device. In such cases, the apparatus is thereafter called the remote safe gateway. The apparatus may alternatively belong to a local network generating said secret information (i.e. belong to the secret provider). According to another aspect of the invention, a server for securely storing secret information to be used by a device remote from said server to decrypt a digital content has means for receiving said secret information through a remote communication A process is proposed for securely storing secret information to be used by a device to decrypt a digital content: this process comprises the steps of: - initiating a remote communication between an apparatus containing said secret information and a server remote from said device ; - sending said secret information from said apparatus to said server; - storing said secret information on said server. The invention also relates to a method for distribution of a digital content to be used by a device comprising the steps of: - encrypting the digital content to thereby generate an encrypted digital content and secret information meant to later decrypt the encrypted digital content; - sending said secret information to a server remote from said device for storing said secret information on said server; - providing means for said device to retrieve said secret information from said server and to decrypt the encrypted digital content with said secret information. Brief description of the accompanying drawings Fig. 1 illustrates the general architecture of a system according to the invention. Fig. 2 illustrates the architecture of a device used in the system of Fig. 1. Fig. 3 illustrates a process for storing secret information according to a first embodiment of the invention. Fig. 4 illustrates a process for retrieving a secret information stored according to the process illustrated in Fig. 3. Fig. 5 illustrates a second embodiment of the invention. Fig. 6 illustrates a process for storing a secret information in the second embodiment of the invention. Description of the preferred embodiments In Fig. 1, we have illustrated a first embodiment of a system according to the invention. In this embodiment, the user has a Set Top Box device 10 (STB) with a return channel such as a PSTN (for "Public Switched Telephone Network") modem or a cable modem. We assume that all the information to store securely can be carried to this STB. For instance, we can envisage that a complete home network can benefit from the remote safe facility. In this case, preferably, a unique device of the network will be able to store and retrieve secret information according to the invention. This unique dedicated STB is used as an apparatus called the remote safe gateway. Obviously it could be another type of device, for example a computer. Through its return channel, each remote safe gateway interacts with a remote server 20 called the remote safe server. The remote server has direct access to its own secure database 21. The secure database will store safely and securely the secret information. In a preferred embodiment of the system, the secure database will be duplicated at least once in different locations. This will avoid loss of data due to natural or malicious crashes. Nevertheless, only one occurrence of the secure database will be considered in the following in order to simplify the presentation of the invention. The user receives his secrets from a secret provider 1 which is consider here as having generated the secret information. It may be for example a content provider which provides, with an encrypted content, a secret to decrypt this content. The secret provider 1 provides the information directly to the remote safe gateway 10. The user may receive information from many secret providers. The characteristics of the system are as follows : - A user must be identified uniquely. It must not be possible to impersonate him. - A user must be able to transfer the secret digital information stored in his home system to the safe server 20. No information must leak from this transfer. For that purpose, the remote safe gateway 10 is used to make this transfer. - The user must be able to retrieve one, part, or all the information stored in his remote safe. No information must leak from this transaction. For that purpose, the remote safe gateway 10 is also used for this transaction. - There must be no constraint on the format of the stored information. We will now describe how the system is working. A first stage of the process consists in the registration of the user. Prior to use the remote safe, the user must sign on the remote safe server's operator. For that purpose, he provides a set of personal information. The definition of these data depends on the operator and is out of the scope of this invention. In return the operator returns a set of secret user identity information (Sluser) used in the next stages. Among this set of information is the unique identifier (IDuser) that thoroughly defines a given user. The channel used for this communication can be different from the return channel of the remote safe gateway. In any case the transfer of the secret user identity information (Sluser) needs to be secured. There are several possible ways: mailing of a smart card, encrypted information sent through the return channel, ... In the last case, the decryption key is transferred through a secure separate channel such as phone or post mail. A second stage of the process consists in the storage of secret information in the safe. This requires several steps. In a first step, the remote safe gateway authenticates the remote safe server using known authentication methods. If the authentication fails, then the storage operation fails. In a second step, the remote safe server authenticates the remote safe gateway. If the authentication fails, then the storage operation fails. In a third step, they define a common session key Ksession. This means a remote communication is initiated between the remote safe server and the remote safe gateway. Then, in a fourth step, the remote safe server creates a unique identifier, lnflDuser_i for the information i to be stored. InflDuser_i is unique for each information stored by the user. Its choice is fully under the control of the remote safe server. It can be either a "random" number, or a number dedicated to the user, following a given rule f, so that f(lnflDuser_i, IDuser)=true. In a fifth step, the remote safe gateway sends the information i to store to the remote safe server. The information i is encrypted using the session key Ksession before being sent. In an optional step, the remote safe gateway encrypts the information i using a secret key of the remote safe gateway before using the session key. Thus, with this optional step, the remote safe server will not have access to the plain text information. Then, in the last step, the remote safe server decrypts the received information using the session key Ksession and stores it into its secure database. The transfer may be secured against transmission errors, or message tampering. In that case, the remote safe server checks the integrity of the decrypted message before its eventual storage. A third stage of the process consists in the retrieval of the secret information from the remote safe server. This operation requires the following steps. In a first step, the remote safe server authenticates the remote safe gateway. If the authentication fails, then the retrieval operation fails. In a second step, they define a common session key Ksession. Then, in a third step, the remote safe gateway provides the remote safe server with the unique identifier of the information to retrieve InflDuser_i. In a fourth step, the remote safe server checks the validity of InflDuser_i. It checks if the corresponding information exists in the database and if this is the case, the remote safe server sends back the requested information to the requesting remote safe gateway in a fifth step. The information is encrypted using the session key Ksession before being sent to the remote safe gateway. Then, in a last step, the remote safe gateway decrypts the received message using the session key Ksession. Preferably, the transfer is secured against transmission errors, or message tampering. In that case, the remote safe gateway checks the integrity of the decrypted message before using it. According to one preferred aspect of the invention, all the operations, except the registration phase, should be transparent to the user. In other words, the retrieval of the stored secrets should be automatic and should not request any interaction from the user. Fig. 2 illustrates a possible architecture for the remote safe gateway. In this figure, only the elements which are necessary for the understanding of the invention have been represented. The remote safe gateway has a Central Processing Unit (CPU) 100. It is assumed that the CPU has its own volatile memory and non-volatile memory where its program is stored. In addition, the remote safe gateway has a non-volatile memory space 101 called the identifiers' memory. The CPU 100 can read and write the content of this space. The remote safe gateway has also a secure processor 102. This secure processor is a tamper proof device that has at least a dedicated CPU 110, a non volatile memory 111 (ROM - Read Only Memory) to store program and persistent data, a volatile memory 112 (RAM - Random Access Memory), and a dedicated non-volatile memory area 113, called the secret cache memory. The secure processor 102 is, in a preferred embodiment, a smart card. The CPU 100 never handles actual secrets. It handles only information identifiers InflDuserj. It maintains a list of the secret information through a list of their corresponding InflDuserj. This list is stored in the identifiers' memory. This space needs not to be tamper-proofed. Therefore it is not costly. The size of the identifiers' memory should be chosen to be large enough to store the expected amount of information identifiers. The secure processor's CPU 110 handles the actual secrets. It stores them in its secret cache memory 113. Unfortunately this space is limited in size due to cost. Therefore it will employ memory-caching techniques that optimize the use of the space. It will store the most recently used secrets and some of the most frequently used secrets. If the remote safe gateway needs a secret information which is not readily available in the secret cache memory 113, then the secure processor's CPU 110 requests it to the remote safe server. In one embodiment of the invention, the remote safe gateway is part of a digital home network where other devices are connected. Some of these devices can also handle secrets. In that case they may reproduce the architecture of Fig. 2. Nevertheless, only the remote safe gateway is able to communicate with the remote safe server. The other devices exchange, through secure communication, with the remote safe gateway their secrets to store or to retrieve. We will now enter into more details of this first embodiment. Registration of the user. When signing on, the user receives the secret user identity information as follows: - A unique identifier IDuser. - A pair of public (PUBuser) and private (PRIuser) keys; the remote safe server encrypts with a public key cryptosystem that we will call CS1. RSA (Rivest-Shamir-Adleman public key cryptosystem) could be such a system. - A public key certificate CERTuser signed by the remote safe server using its private signature key PRISafe_sign. The remote safe server signs with a public key cryptosystem that we will call CS2. RSA could be such a system. CS2 can be identical to CS1. - The public key of the remote safe server PUBsafe_enc using cryptosystem CS1. These data must be transferred safely to the user. It is especially important that his private key, PRIuser, is kept secret. He may for example receive these data in a smart card sent to him via mail. Storage of the secret information. The format of the message to store is preferably defined as follows: Info_To_Store = { InfIDuser_i Length_clear_text Clear_Text Length_secret for I=0 to Length_secret-1 Secret_data[i] Checksum } where : - InflDuser_i is a unique identifier of the information stored by the user. This identifier is unique to the user and delivered by the safe server; - Clear_Text is an ASCII text that describes the stored secret information. Its content is user defined. It could be envisaged that the secret provider delivers a default value for this secret; - Length_clear_text defines the length in bytes of Clear_Text; - Secret_data is the secret to store in the remote safe ; - Length_secret defines the length in bytes of Secret_data ; - Checksum is the sum of all previous bytes of the packet. The process for storing a secret information is illustrated in Fig. 3 and explained in the following. The mutual authentication and key exchange uses the Authenticated DIFFIE HELLMAN Key Exchange Protocol. The protocol generates a common key Kcom. The common session key Ksession is the set of the 112 lower bits of the hash of Kcom through the Secure Hash Algorithm (SHA-1). The remote safe server defines a new value for the information identifier, InflDuser_i. It sends it to the remote safe gateway. The remote safe gateway builds the message lnfo_To_Store with its secret data and InflDuser_i. It encrypts it with the Triple DES algorithm using the common session key Ksession. It sends the encrypted message to the remote safe server that decrypts it using the common key Ksession. The remote safe server checks the validity of Checksum. If the received message is valid, the remote safe server sends it to the secure database. If the operation was successful, the remote safe server returns an acknowledgement to the remote safe gateway, else it returns a non- acknowledgement. Retrieving the secret information. The process for retrieving a secret information stored in the remote safe server is illustrated by Fig. 4 and will be explained in the following. The mutual authentication and key exchange uses the Authenticated DIFFIE HELLMAN Key Exchange Protocol. The protocol generates a common key Kcom. The common session key Ksession is the set of the 112 lower bits of the hash of Kcom through the Secure Hash Algorithm (SHA-1). The remote safe gateway sends the reference of the data to retrieve: InflDuser_i. On receipt of the information identifier InflDuserj, the remote safe server passes it to the secure database. The secure database checks if the message exists, i.e., if there is an information, own by the user, that has the right identification. If it is the case, then it returns the requested information lnfo_To_Retrieve to the remote safe server. The remote safe server encrypts the received data using Triple DES with the session key Ksession and It sends the encrypted message to the remote safe gateway. The remote safe gateway decrypts the received message using the session key Ksession. It checks the validity of Checksum and if it is valid, the remote safe gateway uses the retrieved secret information lnfo_To_Retrieve. We will now describe a second embodiment of the invention which is illustrated in Fig. 5. In this embodiment, the secret provider can provide the information directly to the remote safe gateway or by an indirect way using the remote safe server. The user may receive information from many secret providers. The additional characteristics of the system are as follows: - A third party, known as the secret provider, can deposit a secret to the remote safe server on behalf of a user. No information must leak from this transaction. - It is not possible to impersonate a secret provider. - Once a secret as been deposited by a secret provider, the secret provider has no possible access to it. - A secret provider cannot retrieve any information stored on the account of a user. - Only an authorized secret provider can deposit a secret onto the account of a user. In this embodiment, the process for the secret provider has two stages : The first stage consists in the registration of the secret provider. As for the remote safe gateway, the secret provider needs to sign on the remote safe server. He signs on as secret provider. In return, it receives a set of information known as secret provider identity information (Slprov). The second stage consists in the storage of a secret information on behalf of a user. This stage requires several steps. In a first step, the secret provider, through an apparatus of a local network of its own, authenticates the remote safe server. If the authentication fails, then the storage operation fails. In a second step, the remote safe server authenticates the secret provider. If the authentication fails, then the storage operation fails. In a third step, the remote safe server and the secret provider's apparatus define a common session key Ksession. Then, in a fourth step, the secret provider provides the identity of the user that he is acting for: IDuser. In a fifth step, the remote safe server creates a unique identifier, InflDuser_i for the information to be stored. InflDuserj is unique for each information stored by the user identified by IDuser. Its choice is fully under the control of the remote safe server. It can be either a "random" number, or a number dedicated to the user, following a given rule. In a sixth step, the secret provider sends the information to store to the remote safe server. The sent information is encrypted using the session key Ksession. In a last step, the remote safe server decrypts the received information using the session key Ksession and stores it into its secure database. The transfer may be secured against transmission errors, or message tampering using known techniques. In that case, the remote safe server checks the integrity of the decrypted message before its eventual storage. Once the operation was successfully ended, then the secret provider sends the information identifier InflDuser_i to the corresponding remote safe gateway. The secret provider does not keep any copy of it. Therefore, it is impossible for the secret provider to access any more to the secret information to retrieve it or to modify it. Details of this second embodiment are explained bellow: Registration of the secret provider When signing on, the secret provider receives the following secret provider identity information: - A unique identifier IDprov. - A pair of public (PUBprov) and private (PRIprov) keys; the remote safe server encrypts with the public key cryptosystem CS1. - A public key certificate CERTprov signed by the remote safe server using its private signature key PRISafe_sign_2; the safe server signs with the public key cryptosystem CS2. - The public key of the remote safe server PUBsafe_enc. These information must be transferred safely to the secret provider. It is especially important that his private key is kept secret Storage of an information on behalf of a user. This process, which is illustrated in Fig. 6, is similar to the process described previously in view of Fig. 3. The main differences are: - Prior to exchange the secret information, the secret provider has to identify the user to whom is it depositing. The identification uses the user's unique identifier IDuser. - Once the secret provider successfully stored the information, it sends the reference of the information to the user, that is to its remote safe gateway. The system if the invention may be applied to a new distribution , model. For example, a content provider wants to distribute in a controlled manner a content. This content can be any digital content such as video, MP3 files, software, etc. For that purpose it distributes the content encrypted with an encryption key Kenc_conu_i. To read this encrypted content, the user must have access to the decryption key Kdec_cont_i. The decryption key may be equal to the encryption if we use a symmetric cryptosystem. The user contacts the content provider and buys the right to access the content. Acting as a secret provider, the content provider deposits the decryption key in the user's remote safe. In return the user receives the information identifier of the decryption key. Another possible application of the system of the invention is a small footprint backup of a jukebox. The jukebox will be a future new type of consumer device. It will probably be successful. Nevertheless with the jukebox, a major risk is introduced: loss of all the contents stored in the jukebox. Currently it is envisaged to use hard disks as storage units. In the field of software, it is well known that regular backup of the hard disk is a safe practice. But it is not reasonable to expect the same feature in a consumer device. The system of the invention will provide a backup facility based on the remote safe as a new service. For each legally delivered content, the content provider will provide an additional information called a digital purchase proof. The digital purchase proof is the result of a one way cryptographic function using as input parameter a unique identifier of the owned content, and the user identifier IDuser. Instead of backing up all his contents, the user stores in his remote safe all his digital purchase proofs. If he loses one content, the user returns to the content provider the corresponding digital proof. The content provider checks if the digital proof is consistent with the claimed content and the identity of the user. If it is the case, then the content provider sends back to the user a copy of the content. In conclusion, the invention offers the following advantages: - the possibility to handle in a safe and secure manner a large quantity of secret data without requesting an in-house large tamper-proof space; - a simple new model of distribution of digital content that could fit for IP streaming, or even prerecorded contents; - a small size backup of large library of digital contents. WE CLAIMS --------- 1. Device intended to use secret information to access to a digital content; said device containing: - a memory space (101) able to contain a list of identifiers (InflDuser i) of secret information items, said secret information items being stared in a tamper-proof memory space (21) of a server (20) remote from said device; - a tamper-proof memory (113) able to store secret information items; and - means for retrieving a secret information from said remote server (20) when said secret information is not available in the tamper-proof memory (113) of said device. 2. Device as claimed in claim 1, comprising means for sending a secret information to said remote server (20) in order to store said secret information in said remote server, wherein said secret information is provided to said device by a secret provider (1). 3. Device as claimed in claim 2, comprising means for encrypting said secret information using a secret key of said device before sending said secret information to said remote server. 4. Device as claimed in any one of claims 1 to 3, wherein each identifier (InflDuser i) is unique for each secret information item stored in the remote server and is delivered to said device by the remote server. 5. Device as claimed in any one of the preceding claims, wherein the secret information is a content decryption key. 6. Device as claimed in any one of claims 1 to 4, wherein the secret information is a purchase proof. 7. System for securely storing secret information comprising: - a device as claimed in claim 1; and - a server (20), remote from said device having a tamper- proof memory space (21) to store said secret information, wherein said secret information is provided to said remote server by a secret provider (1) and wherein each identifier (InflDuser i), stored in the memory space (101) of said device, is created by the remote server and is unique for each secret information item stored in the remote server, said identifier (InflDuser i) being sent to said device by the secret provider.

Documents:

IN-PCT-2002-1232-KOL-ABSTRACT 1.1.pdf

in-pct-2002-1232-kol-abstract.pdf

IN-PCT-2002-1232-KOL-CLAIMS.pdf

IN-PCT-2002-1232-KOL-CORRESPONDENCE 1.1.pdf

IN-PCT-2002-1232-KOL-CORRESPONDENCE-1.2.pdf

in-pct-2002-1232-kol-correspondence-1.3.pdf

IN-PCT-2002-1232-KOL-CORRESPONDENCE.pdf

in-pct-2002-1232-kol-description (complete).pdf

in-pct-2002-1232-kol-drawings.pdf

in-pct-2002-1232-kol-examination report.pdf

IN-PCT-2002-1232-KOL-FORM 1.pdf

in-pct-2002-1232-kol-form 18.pdf

IN-PCT-2002-1232-KOL-FORM 2.pdf

IN-PCT-2002-1232-KOL-FORM 3-1.1.pdf

in-pct-2002-1232-kol-form 3-1.2.pdf

IN-PCT-2002-1232-KOL-FORM 3.pdf

in-pct-2002-1232-kol-form 5-1.1.pdf

in-pct-2002-1232-kol-form 5.pdf

in-pct-2002-1232-kol-granted-abstract.pdf

in-pct-2002-1232-kol-granted-claims.pdf

in-pct-2002-1232-kol-granted-description (complete).pdf

in-pct-2002-1232-kol-granted-drawings.pdf

in-pct-2002-1232-kol-granted-form 1.pdf

in-pct-2002-1232-kol-granted-form 2.pdf

in-pct-2002-1232-kol-granted-specification.pdf

IN-PCT-2002-1232-KOL-OTHERS-1.1.pdf

IN-PCT-2002-1232-KOL-OTHERS.pdf

in-pct-2002-1232-kol-petition under rule 137.pdf

in-pct-2002-1232-kol-reply to examination report.pdf

in-pct-2002-1232-kol-specification.pdf

in-pct-2002-1232-kol-translated copy of priority document.pdf