Keep Your Secrets ... Secret

Key management is one of the hardest parts of encryption. DPAPI makes it easy.

Troubleshooting Tips




Keep Your Secrets ... Secret

Key management is one of the hardest parts of encryption. DPAPI makes it easy.


By Don Kiely


In my last column about DPAPI (Can You Keep a Secret?), I demonstrated an example of how easy it is to use DPAPI to encrypt information used and stored on the local Web server. That's pretty cool, but it isn't exactly rocket science. There are plenty of wrappers around that simplify encryption in .NET applications, even beyond the significant simplification the framework itself provides. What's really cool about DPAPI is that it takes care of one of the hardest things about encryption: key management.


Key management, simply put, is how you keep your secrets secret. Pretty much all industrial-strength encryption requires that you use a key. You might use symmetrical keys, where one key is used for both encrypting and decrypting data. This is referred to as a shared secret, since both you as the sender/encrypter and the receiver/decrypter have to know the key. This kind of scheme then requires that you have a very secure way to share the secret. All of the efforts by participants in World War II to break or steal the "enemy's" "keys" show just how risky symmetry can be.


The other option is asymmetric keys, or public/private key pairs. With this scheme you don't have to share secrets, because the key used to encrypt data is different from that used to decrypt it. Someone else can use your public key - you don't care who has access to it - to send you data that only you can decrypt with your private key. And you can use your private key to encrypt data that anyone can decrypt with your public key. This is more secure than symmetric keys, since you don't have to communicate a shared secret and risk detection while in transit.


But even if you go to great lengths to protect your private key - which doesn't ever have to leave your computer - someone can break into your computer and steal it. So you still have to be careful to put it in a safe, protected place, perhaps on a floppy disk (remember those?) you store in your underground vault. But even there, evil molemen could burrow in and steal it.


This is all a long-winded way of saying that key management is a pain and is easy to mess up. Flawed key management is one of the major ways that otherwise secure applications can be breeched. Fortunately, this is the major benefit of DPAPI. It stores and manages keys for you, deep within the bowels of Windows.


DPAPI Key Management

Here's how it works. DPAPI generates a strong key called a MasterKey using a Password-Based Key Derivation. This key is protected by the user's password, using Triple-DES, and stored in users' profile directory. The MasterKey isn't used directly to encrypt data. Instead, DPAPI generates a symmetric session key based on MasterKey, random data, and secondary entropy (if you choose to provide any). It is this session key that is used to encrypt data. The session key itself is never stored anywhere, and random data is included in the data blob (the encrypted data), which is then later used to derive the session key again.


MasterKeys expire, by default, every three months, at which time DPAPI automatically generates another MaskerKey that is used thereafter. This scheme prevents an attacker from compromising one key and gaining access to all of a user's data for all history and all future data.


But what about all the user's data protected by an earlier MasterKey after the system starts using a new MasterKey? Windows saves all prior MasterKeys forever and ever. Each MasterKey has a GUID associated with it, and it stores the GUID of the MasterKey used to encrypt a data blob in the blob itself. This lets it automatically retrieve the proper MasterKey.


But what if the user changes the password? Now we really start to see the benefit of DPAPI. All MasterKeys are automatically re-encrypted with the new password and stored in a credential history. Each new password is added to a file and the whole thing is encrypted with the new password. This way, if a MasterKey from, say, 14 months ago is needed to read data from back then, DPAPI uses the current password to decrypt the history and the previous password to decrypt the MasterKey, going back as far as necessary. DPAPI keeps nesting the keys as deeply as necessary.


Backing Up Keys

So if you hadn't yet been convinced that you need to do regular backups of your local machine, this should convince you. Nevertheless, Windows provides some failsafe options. Which is used depends on whether you are a member of a domain or not.


With domain membership, the domain controller (DC) has a public/private key pair for DPAPI. DPAPI automatically encrypts the MasterKey with the DC key and stores it with the version encrypted with the user's password. To decrypt data, it sends that encrypted MasterKey to the DC for decryption. All communication is via "protected" RPC calls, which have been the target of many attacks lately. But keep in mind that this scheme is used only if you lose the backups of the MasterKeys on the local machine.


If it's a standalone computer or a member of a workgroup only, you need to rely on the Password Reset Disk in Windows XP, which you create from Control Panel | User Accounts. When you create this disk, it gives you a way to reset the user's password, which automatically re-encrypts MasterKeys. See KB article 305478 for more information, but be aware that you're hosed without a removable disk drive. I don't have one on one of my laptops, so I can't create a reset disk. Sheesh.


DPAPI provides secure key management so you don't have to worry about it. And hey, if someone pierces DPAPI key management and gets access to your private key, you can always blame Microsoft rather than take the blame yourself!


Next time in this series I'll cover the data storage options with DPAPI, and how they affect using DPAPI with ASP.NET.


Don Kiely is senior technology consultant for Information Insights, a business and technology consultancy in Fairbanks, Alaska. E-mail him at mailto:[email protected].





Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.