Storing Secrets in Windows 95, Windows 98, Windows Me, and Windows CE

Windows 95, Windows 98, Windows Me, and Windows CE all have CryptoAPI support, but none have ACLs. Although it s easy to save secret data in a resource such as the registry or a file, where do you store the key used to encrypt the data? In the registry too? How do you secure that, especially with no ACL support? This is a difficult problem. These platforms cannot be used in secure environments. You can hide secrets, but they will be much easier to find than on Windows NT 4, Windows 2000, or Windows XP. In short, if the data being secured is high-risk (such as medical data), use Windows 95, Windows 98, Windows Me, or Windows CE only if you get a key from a user or an external source to encrypt and decrypt the data.

When using these less-secure platforms, you could derive the key by calling CryptGenRandom, storing this key in the registry, and encrypting it with a key derived from something held on the device, such as a volume name, a device name, a video card name, and so on. (I bet you wish Intel had stuck with shipping their Pentium III serial numbers enabled, don t you?) Your code can read the device to get the key to unlock the registry key. However, if an attacker can determine what you are using as key material, he can derive the key. Still, you ve made the task more difficult for the attacker, as he has to go through more steps to get the plaintext. Also, if the user changes hardware, the key material might be lost also. This solution is hardly perfect, but it might be good enough for noncritical data.

The HKEY_LOCAL_MACHINE\HARDWARE portion of the registry in Windows 95, Windows 98, and Windows Me computers is full of hardware-specific data you can use to derive an encryption key. It s not perfect, but again, the bar is raised somewhat.

It s important to realize that none of this is truly secure it just might be secure enough for the data you re trying to protect. That last point again: it might be secure enough.


	It is important to notify the user in Help files or documentation that the platform stores secrets on a best-effort basis.

Finally, when handling secret information in your code, you should keep the time it is in cleartext that is, unencrypted in memory to a minimum. This is to reduce the risk that the secret will be leaked out to a paging file. Once you ve used the secret in your code, overwrite the buffer with bogus data by using memset. Here s an example:

 for (int i = 0; i < 8; i++) { memset(pBlob, 0xAA, cbBlob); // 10101010 memset(pBlob, 0x55, cbBlob); // 01010101 memset(pBlob, 0xFF, cbBlob); // All 1's memset(pBlob, 0x00, cbBlob); // All 0's }


	Storing secret information securely in software is hard to do. In fact, it is impossible to achieve perfection. Make sure you take advantage of the operating system security functionality, and do not store secret information if you do not have to.