Meet the Data Protection API

Encrypt your .NET data in a few simple steps.

Troubleshooting Tips

LANGUAGES: All .NET Languages

ASP.NET VERSIONS: 1.0 | 1.1

 

Meet the Data Protection API

Encrypt your .NET data in a few simple steps.

 

By Don Kiely

 

In the last installment of this column (see Encryption Made (Sort of) Easy) I examined a short example of encrypting and decrypting data using the .NET Framework. While the System.Security.Cryptography namespace has some powerful features that implement some of the best algorithms available, it is still way too hard. But what's hardest of all is that it provides very little support for key management. Cryptography is based on keeping secrets secret. This means that if you're using symmetric cryptographic techniques you have to share the secret - the key - securely. And if you're using public/private key pairs, you still have to keep your private key private. With spyware and viruses invading systems every day, how do you even keep stuff on your local machine secure?

 

Microsoft's answer is to let the operating system take care of it for you, and with Windows 2000 they introduced the Data Protection API, (DPAPI). DPAPI is part of the Crypto API implemented in Crypt32.dll, available with all installations of Windows 2000 and later. (There were some minor changes to the API after Windows 2000, so test your code on all the platforms where it will run.) That means that you don't even have to include the DLLs when you use it in your app, whether it is a server-based Web or a desktop app. The API uses TripleDES encryption and strong keys, which Windows takes care of further encrypting and storing within a user's profile. DPAPI isn't part of the .NET Framework, but it is simple to use from there and you can easily include it in .NET apps.

 

While DPAPI encrypts data, the real value of using it in applications is that it securely stores the critical secret of encryption - your private key - while making it available to your applications. You can store the keys in either of two stores on a local machine, either the user store or machine store. The user store is more secure but the machine store is more easily used from server applications like ASP.NET.

 

I'll talk more about how to use these stores in upcoming installments of this column, but let's start by looking at how the DPAPI process of encrypting data works. Your application - a desktop or Web app - starts with a piece of data that it needs to protect. Your code calls the DPAPI and passes the data to it. Remember that you're calling DPAPI on the local machine, so you don't have to transmit the data across any network, not even a local intranet. DPAPI passes your data to the Local Security Authority (LSA), which turns around and calls back into the DPAPI to actually encrypt the data. DPAPI then passes the encrypted data back to your application for whatever use you need to put it.

 

Why the intermediate step to use the LSA? The LSA is a system process that manages much of the Windows security infrastructure, and passing the data through it allows security auditing, among other services provided by LSA.

 

In the next installment I'll show you how to call and use the DPAPI in an application to securely encrypt data.

 

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

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.
Publish