System and method to securely store information in a recoverable manner on an untrusted system

• US 6,920,563 B2
• Filed: 01/05/2001
• Issued: 07/19/2005
• Est. Priority Date: 01/05/2001
• Status: Expired due to Fees

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Kohl, Ulrich, Lotspiech, Jeffrey Bruce, Nusser, Stefan
• Primary Examiner(s): Song, Hosuk
• Application Number:
  US09/754,396
• Publication Number:
  US 20020091930A1
• Time in Patent Office: 1,656 Days
• Field of Search: 380277-281, 380284-286, 380/46, 713/165, 713/189, 713/193, 713/191, 705/50, 705/59, 705/71, 707/1, 707/9, 707/10, 707200-202
• US Class Current: 713/189
• CPC Class Codes: H04L 9/0894 Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage

Abstract

A method (and system) for storing information in a recoverable manner on an untrusted system, includes sending, by a client, a request to a recovery server for recovery of a failed database, determining whether the request is legitimate, based on the determining, sending a local key to the client, decrypting by the client the failed database with the local key, to recover the failed database, and re-encrypting the recovered database with a new key.

Claims

1. A method for storing information in a recoverable manner on an untrusted system, comprising:

sending, by a client, a request to a recovery server for recovery of a failed database;

determining whether said request is legitimate;

based on said determining, sending an old local key to the client;

decrypting by said client the failed database with the old local key, to recover the failed database; and

re-encrypting the recovered database with a new local key,

wherein at least one of said old local key and said new local key is based upon at least one unique characteristic of a hardware component associated with said database.

2. The method of claim 1, further comprising:

verifying whether a key database identification has been tampered with.

3. The method of claim 1, wherein said database is associated with content which is purchased from a content owner and stored, along with a keyword or codeword, on the database of the client.

4. The method of claim 3, wherein the client can access the recovery server with the keyword to restore the database.

5. The method of claim 1, wherein said at least one of said old local key and said new local key comprises one of a unique key for each piece of content in said database and an overall key for the entire database.

6. The method of claim 1, wherein at least one of said old local key and said new local key is based on at least one of a processor identification, a particular sector of a system file and random data stored in a non-volatile area of a computer system of said client.

7. The method of claim 6, wherein said random data comprises values placed in a secret location comprising any of a system'"'"'s basic input/output system (BIOS), a nonvolatile RAM (NVRAM), and a hard disk.

8. The method of claim 6, said non-volatile area of said computer system comprises an area of a computer system that is not protected by a backup operation.

9. The method of claim 1, wherein said at least one of said old local key and said new local key is further based on a value in at least one secret location which changes every time a predetermined action occurs.

10. The method of claim 9, further comprising:

storing a counter in the secret, nonvolatile location; and

incrementing the counter.

11. The method of claim 9, further comprising;

incrementing a counter periodically; and

storing the counter to the nonvolatile location such that a restored value will be saved with a wrong key.

12. The method of claim 1, wherein said local key is based on a combination of values stored in a local storage and a nonvolatile location of a computer system of said client.

13. The method of claim 1, wherein the database is encrypted with said local key, and said local key is decryptable only by the recovery server.

14. The method of claim 13, further comprising decrypting the old local key at the recovery server using public key cryptography.

15. The method of claim 1, wherein said recovery server automatically provides said old local key in response to a first request.

16. The method of claim 15, wherein said request is sent from the client to the recovery server if the old local key is not correct, wherein said request further comprises the encrypted old local key.

17. The method of claim 16, wherein if the recovery server determines that said request is legitimate said method further comprises:

decrypting the old local key.

18. The method of claim 1, wherein data is stored in a non-volatile area of a machine of said client, and further comprising:

changing data and said old local key every time a count changes.

19. The method of claim 1, wherein re-encrypting the recovered database with the new local key comprises:

encrypting a random key using said new local key; and

re-encrypting the recovered database using said random key.

20. The method of claim 1, wherein counters are kept in records of the database, and the local key is used to encrypt the counters.

21. The method of claim 1, wherein the request comprises a header and a body, and wherein all but a first portion of the header is encrypted with said old local key.

22. The method of claim 21, wherein said header comprises a cleartext portion of the header that comprises a unique database identification.

23. The method of claim 22, wherein said header further comprises a second portion comprising said old local key and the database identification, wherein said second portion of said header is encrypted with a public key from the recovery server.

24. The method of claim 23, wherein said failed database comprises said header and fields which are encrypted with the old local key wherein said header further comprises a codeword.

25. The method of claim 24, wherein said failed database comprises a body encrypted with the old local key.

26. The method of claim 25, wherein said old local key for the database cannot be reconstructed locally and must explicitly be recovered, such that a client application program extracts said second portion from said cleartext portion of the header,

wherein said second portion comprises said old local key that is encrypted with said public key, wherein sending said request from said client comprises sending the second portion to the recovery server.

27. The method of claim 1, wherein said determining whether said request is legitimate comprises:

determining based on any of whether a normal user upgrade is due, and whether a predetermined tune period has elapsed between a user recovery of a failing machine.

28. The method of claim 1, wherein said determining whether said request is legitimate comprises:

resetting parameters in a decision logic; and

requesting another request from the client.

29. A method of allowing recovery of a proprietary database, comprising:

receiving, from a client at a recovery server, a request to restore a database;

determining, by the recovery server, whether the request is legitimate by verifying a key database identification included in the request of the user;

if the key database identification matches a predetermined identification, then applying a recovery decision logic, and granting the restore request to the client by the recovery server;

forwarding an old local key to a user; and

calculating a new local key by decrypting the database with said old local key by said client,

wherein at least one of said old local key and said new local key is based upon at least one unique characteristic of a hardware component associated with said database.

30. The method of claim 29, further comprising:

resetting certain parameters in the decision logic; and

requesting another request from the client.

31. A system for storing information in a recoverable manner on an untrusted system, comprising:

means for sending, by a client, a request to a recovery server for recovery of a failed database;

means for determining whether said request is legitimate;

based on an output from said means for determining, means for sending an old local key to the client;

means for decrypting, by said client, the failed database with the old local key; and

means for re-encrypting the recovered database with a new local key,

wherein at least one of said old local key and said new local key is based upon at least one unique characteristic of a hardware component associated with said database.

32. The system of claim 31, further comprising:

means for resetting parameters in a decision logic; and

means for requesting another request from the client.

33. A system of allowing recovery of a proprietary database, comprising:

means for receiving, by a recovery server, a request from a client to restore a database;

means for determining whether the request is legitimate by verifying a key database identification included in the request of the client;

means for applying a recovery decision logic based on the key database identification matching a predetermined identification, and for granting the restore request to the client by the recovery server;

means for forwarding an old local key to said client;

means for decrypting the database with the old local key, and calculating a new local key,

wherein at least one of said old local key and said new local key is based upon at least one unique characteristic of a hardware component associated with said database.

34. The system of claim 33, further comprising

means for resetting parameters in a decision logic;

and

means for requesting another request from the client.

35. A signal-bearing medium tangibly embodying a program of machine-readable instructions executable by a digital processing apparatus to perform a method of storing information in a recoverable manner on an untrusted system, comprising:

sending, by a client, a request to a recovery server for recovery of a failed database;

determining whether said request is legitimate;

based on said determining, sending a local key to the client;

decrypting by said client the failed database with the local key; and

re-encrypting the decrypted database with a new key,

wherein at least one of said local key and said new key is based upon at least one unique characteristic of a hardware component associated with said database.

36. A signal-bearing medium tangibly embodying a program of machine-readable instructions executable by a digital processing apparatus to perform a method of allowing recovery of a proprietary database, comprising:

receiving a restore request from a client, by a recovery server;

determining, by the recovery server, whether the request is legitimate by verifying a key database identification included in the request of the client;

based on the key database identification matching a predetermined identification, applying a recovery decision logic, and granting the restore request by the recovery server;

forwarding an old local key from said recovery server to said client;

decrypting the database using the old local key; and

calculating a new local key,

wherein at least one of said old local key and said new local key is based upon at least one unique characteristic of a hardware component associated with said database.