9

I am testing out the idea of using .net v4's System.Security.Cryptography.ProtectedData() and UnprotectData() methods with the DataProtectionScope.LocalMachine scope to ensure that an file can only be encrypted/decrypted on a single machine. Here is the general idea of what I am doing...

//Encrypt    
byte[] outBytes = ProtectedData.Protect(File.ReadAllBytes(fileIn), null, DataProtectionScope.LocalMachine);
File.WriteAllBytes(fileOut, outBytes);

//Decrypt    
byte[] outBytes = ProtectedData.Unprotect(File.ReadAllBytes(fileIn), null, DataProtectionScope.LocalMachine);            
File.WriteAllBytes(fileOut, outBytes);

I have done loads of testing to ensure that I get the expected behavior when doing this and it appears to work perfectly in that any user on the same machine can encrypt/decrypt a file using the method calls listed above.

My question is what will happen if someone makes a disk image or clone (using Acronis, Ghost, etc...) of a system that contains a file encrypted using this mechanism, then restores that image to a different machine? (One example being and IT department pre-loading a single system that then becomes the base image for an army of machines with identical hardware configurations). Will the restored OS on a different piece of hardware be able to decrypt the file that was encrypted on the "original" system? My hope is that because of the different hardware, the decryption will fail, but it may make sense that if all of the necessary information to do the crypto exists in the registry or on the file system, it would work.

Obviously, I could test this for myself, but I do not really have the resources to do so right now and have been searching endlessly to see if anyone else out there might already know the answer. Any advice is much appreciated!

Christian Del'Aune
  • 101
  • 4

2 Answers2

4

My answer only applies to DataProtectionScope.LocalMachine because obviously DataProtectionScope.CurrentUser uses keys stored in Active Directory or some other roaming source and is explicitly, by-design, not tied to a single physical key.

As far as LocalMachine is concerned, a clone of a computer will be able to open the same files because the machine-key is stored on the machine's HDD and is generated using the "sysprep" stage of installing Windows (this is why a corporate Windows rollout can use the same system image, but so long as they run sysprep each system will have its own key).

A computer can re-create its machine key (and it can also preserve the old keys so older data is still decryptable). I don't know how to get it to recreate the key and then delete the old ones, however.

Source: http://www.windows-server-answers.com/microsoft/Security-Cryptography/30350079/local-machine-masterkey-in-dpapi.aspx

Dai
  • 141,631
  • 28
  • 261
  • 374
0

Good question - hunting around it seems that the master key is automatically regenerated every ca. 90 days. There's a very good analysis on Passcape.com - the heart of DPAPI security is linked to the system's SYSKEY which is stored in the registry under the SYSTEM hive.

Because one can apparently use the CryptProtectData() call with the CRYPT_PROTECT_REGENERATE flag to refresh the DPAPI master key on a cloned system it seems that your use-case for DPAPI protection represents a security risk.

My take on the matter is that while DPAPI is great for security on a local machine (but see this post on Epyx Forensics about password recovery), you'll probably need to implement additional security measures when cloning, especially if you can't control how the systems will be cloned.

This question would likely get a better answer on https://security.stackexchange.com/ so you may want to ask there as well.

Community
  • 1
  • 1
Anthill
  • 1,219
  • 10
  • 20