10101001 10101001's Journal: Public-key Hiberantion (and other Public-Key uses)

Before I begin, I should give some credit where credit is due. Some time ago, Raymond Chen's OldNewThing blog had a post about the dangers of using locked pages to try to keep a secret key from leaking onto the HD. In short, something like hibernation would allow even locked pages to be written out, thereby allowing those with enough intent to potentially override the intended protection. And while the offered suggestion provided by a friend, to use a key to encrypt the information and hopefully obfuscate the information, was dubious at best, it did eventually lead me to thinking about how to properly address the situation and many *other* situations like it.

Having said all that, I very much doubt I'm the first person to suggest the following ideas. But, I'm throwing them out here as I've yet to see anyone suggest them publically enough to have run across them.

Idea one is rather simple, and it relates to the hibernation problem. In general, the problem with hibernation is a public/private problem. That is to say, there is a fear that the hibernated information might be made available to the public, yet there is a strong desire to keep the information private. And while there is the obvious suggestion, to have a user provide a key each time hibernation occurs, it is a very impractical solution. Instead, a more practical solution is offered.

Pre-Hibernation Steps
1. Create a public/private-key pair
2. Encrypt the private key with a strong symmetric cipher (aes-256, for example) using a user provided password
3. Write the public key and encrypted private key to the HD

Hibernation Steps
1. Randomly generate a one-use key for a strong symmetric cipher (aes-256, for example)
2. Use the one-use key to encrypt memory as is written out to the HD
3. Encrypt the one-use key with the public key and write the encrypted key to the HD

Unhibernation Steps
1. Read in the encrypted private key
2. Read in the encrypted one-use key
3. Read in the password for the encrypted private key
4. Decrypt the one-use key with the private key
4. Use the decrypted one-use key to read in memory

The real thing of note is, this idea can be extended into many other fields. Let's consider the example of automated backups. While the cost and hassle of automated backups is one major reason that people resist having a rigorous backup system, another major reason is privacy concerns. Medical records and financial data need protected, although the reasonably paranoid would likely prefer that backups are encrypted by default instead of relying upon the user to do so manually. Things like EFS have the right idea in principle, but EFS's implementation seems focused on the short-term usability of a HD without enough consideration on long-term backup; there have been efforts by backup-programs to support use of EFS, however. In short, something like EFS could be tweaked slightly to be a great automated backup solution.

Generally, in any situation where the question comes up "but how do we keep this information private while allowing people access to the (possibly encrypted) data", the answer is a public/private key with the use of symmetric encryption of the private key. The only major limitations is whatever weaknesses exist in the encryption algorithms. But, that's another can of worms.