Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Public-key Hiberantion (and other Public-Key uses)

10101001 10101001 (732688) writes | more than 6 years ago

User Journal 0

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 hop

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.

cancel ×

0 comments

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...