An Idea: Using External Devices to Encrypt Secret Data

Many people use handheld devices, such as the Windows CE powered Microsoft Pocket PC, to keep track of day-to-day events, take notes, play games, browse the Internet, and read e-mail. These devices are also excellent development platforms because they include a good range of Windows-based application programming interfaces. One such interface is CryptoAPI. Windows CE 3 powered devices, such as the Compaq iPAQ 3600 series, the CASIO EM-500, and the Hewlett-Packard Jornada 540 series, include excellent cryptographic support. And this got me thinking. What if I can use such a device to store a cryptographic key and I offload the cryptographic work to the device rather than the host PC? I set about writing a simple Pocket PC based tool named PPCKey. Let s look at a sample scenario for PPCKey.

A Sample Scenario Using PPCKey

We are all aware of the great timesaving aspects of the Remember My Password check box on many login dialog boxes. While this is certainly a great usability feature, it s also a potential security hole because the password is either stored in the clear on the computer or encrypted with a key that s held on the computer. On all operating systems, including Windows, it is difficult to protect the encryption key. In fact, many applications hard-code the key such that an attacker can gain any password. And once the key is discovered, the attacker can unlock all passwords encrypted with that key.

PPCKey gets around this issue by storing a secret cryptographic key on a Pocket PC and then allowing the Pocket PC to encrypt and decrypt sensitive information based on that key. Here s a scenario that shows how the PPCKey tool works:

A key-generation program executed on the Pocket PC derives a strong cryptographic key seed and writes it to the registry on the Pocket PC. This is performed once. The key is 128 bits long and is derived by calling CryptGenRandom.
While using a Windows-based application, a user is prompted to enter her credentials, which comprise her username and her password.
Once the user has entered her credentials, she selects the Remember My Password option.
The application takes the password from the dialog box and calls the PPCKey API, implemented as a C++ class, to encrypt the data.
The client-side PPCKey C++ class takes the password and sends it to the Pocket PC by using the Windows CE Remote API (RAPI) functionality.
The PPCKey DLL on the Pocket PC encrypts the password with a strong cryptographic key that is, one composed of a random stream of bits held on the device and returns the encrypted blob to the application.
The Windows-based application persists the encrypted blob in, for example, the registry.
At a future date, the user loads the Windows-based application, but rather than presenting the user with a credentials dialog box, the application takes the encrypted blob from the registry and calls the PPCKey C++ class to decrypt the data.
The client-side PPCKey C++ class passes the blob to the Pocket PC based PPCKey DLL by using RAPI.
The Pocket PC based PPCKey DLL decrypts the blob with the key held on the device and returns the password to the application.
The application uses the password and then discards the password.

Figure 7-2 shows how this process works.

Figure 7-2

The PPCKey end-to-end process.

The advantage of this solution is clear. If the Pocket PC is not present in the cradle or communicating by using an infrared link, for example the application cannot derive the password because the password is not held on the PC. Only an encrypted blob is stored. Also, the password cannot be derived from the Pocket PC if the Pocket PC is stolen because the encrypted password is not stored on the Pocket PC. Only the encryption key is stored on the Pocket PC. To correctly determine the key, an attacker must have physical access to both the desktop computer and the Pocket PC. That, of course, is possible, but it s much less likely than the attacker having access to only one of the two devices.

A PPCKey Threat Model

This section outlines a threat model for the PPCKey application. The threats to PPCKey include the following:

Attacker has access to both the Pocket PC and the Windows client
Attacker guesses key by watching the order of registry writes on the Pocket PC
Attacker performs a brute-force attack on ciphertext held on the PC
Attacker determines that two applications have the same password
Attacker looks for plaintext in memory
Attacker guesses key
Attacker enumerates the registry and tries all key values

Let s look at each in detail. Remember from Chapter 2, Designing Secure Systems, that risk is calculated by dividing criticality (ranked from 1 [least damage potential] to 10 [greatest damage potential]) by chance of attack (ranked from 1 [greatest likelihood] to 10 [least likelihood]).

Attacker Has Access to Both the Pocket PC and the Windows Client
Threats	Information disclosure
Threat subtarget	Encryption key
Risk	Criticality: Very high (10); Chance: Medium (4); Risk: Low (2.5)
Attack techniques	Attacker accesses unlocked workstation with Pocket PC cradled and attempts to decrypt data by using the provided C++ class.
Mitigation techniques	All bets are off. If the attacker has physical access to both devices and the desktop is unlocked, the attacker can do much more than just determine the key and hence the plaintext! Attack will fail if the Pocket PC is not connected to the PC.

Attacker Guesses Key by Watching the Order of Registry Writes on the Pocket PC
Threats	Information disclosure
Threat subtarget	Encryption key
Risk	Criticality: Very high (10); Chance: Medium (4); Risk: Low (2.5)
Attack techniques	A Trojan horse application is placed on the Pocket PC to watch the keys as they are written to the registry.
Mitigation techniques	The real key is mixed in with ten other random values, and the order they are written to the registry is also random. Attack will fail if the Pocket PC is not connected to the PC.

Attacker Can Perform Brute Force Attack on Ciphertext Held on PC
Threats	Information disclosure
Threat subtarget	Plaintext
Risk	Criticality: Very high (10); Chance: Medium (5); Risk: Low (2)
Attack techniques	Attacker accesses the ciphertext data to attempt to derive the plaintext, which is then the subject of an exhaustive brute-force key-guessing attack.
Mitigation techniques	Use stronger 128-bit CAPI, available at www.pocketpc.com, on the Pocket PC; the default is only 40-bit. Lock the workstation, and restrict access to the computer by remote users.

Attacker Determines That Two Applications Have the Same Password
Threats	Information disclosure
Threat subtarget	Plaintext
Risk	Criticality: Very high (10); Chance: Medium (5); Risk: Low (2)
Attack techniques	Attacker manages to access two or more encrypted data blobs. If they are the same, they must be the same password.
Mitigation techniques	The client application passes a salt to the Pocket PC the C++ class supports salting and this is used to derive the key. No two applications have the same encryption or decryption key.

Attacker Looks for Plaintext in Memory
Threats	Information disclosure
Threat subtarget	Plaintext
Risk	Criticality: Very high (10); Chance: Medium (5); Risk: Low (2)
Attack techniques	Attacker gains physical access to computer and looks for the plaintext in memory or perhaps in a paging file. This assumes, on Windows NT, Windows 2000, and Windows XP, that the attacker has logon rights to the computer or that the attacker stole the machine and the page file was not flushed at shutdown. If an attacker has physical control over the computer, all bets are off.
Mitigation techniques	Through education, instruct developers to call the C++ method CPPCKey::Scrub, which will purge the data from memory by overwriting it 32 times with different bit patterns.

Attacker Guesses Key
Threats	Information disclosure
Threat subtarget	Encryption key
Risk	Criticality: Very high (10); Chance: Medium (5); Risk: Low (2)
Attack techniques	Attacker works out what the key in the registry is.
Mitigation techniques	The key in the registry is not a cryptographic key; it s a seed. The attacker must also determine the name of the device and, if the device is a Compaq IPaq, the asset tag number. All of these are added to the key seed to create the real cryptographic key. The attack will fail if the Pocket PC is not connected to the PC.

Attacker Enumerates the Registry and Tries All Key Values
Threats	Information disclosure
Threat subtarget	Plaintext
Risk	Criticality: Medium (6); Chance: Medium (6); Risk: Very low (1)
Attack techniques	Attacker calls the client-side C++ class to decrypt the data.
Mitigation techniques	Each time the attacker calls the appropriate functions, the Pocket PC will pop up a dialog box to say that a process is attempting to decrypt the data, thereby providing an override mechanism and alert for the user. This attack will fail if the Pocket PC is not connected to the PC.

The following sample C++ client code shows the PPCKey key in action:

#include "StdAfx.h" #include "Ppckeyimp.h" // Get the version #. void GetPPCKeyVersion(CPPCKey &key) { key.Call(PPCKEY_ACTION_VERSION, NULL, 0); if (key.Error() == PPCKEY_OK) { printf("Version is: %s\n", reinterpret_cast<char*>(key.Data())); } else { key.PrintErrorInfo(); } } // Get the key data. void GetPPCKeyKeyInfo(CPPCKey &key) { key.Call(PPCKEY_ACTION_KEYINFO, NULL, 0); if (key.Error() == PPCKEY_OK) { puts(reinterpret_cast<char*>(key.Data())); } else { key.PrintErrorInfo(); } } void TestWords(CPPCKey &key) { // Encrypt the blob, in this case a normal string. BYTE bPlaintext[] = {"Hello, World!"}; DWORD cbPlaintext = sizeof(bPlaintext); key.Call(PPCKEY_ACTION_ENCRYPT, bPlaintext, cbPlaintext); if (key.Error() == PPCKEY_OK) { printf("Ciphertext: "); for (DWORD i= 0; i < key.Size(); i++) printf("%02X ", key.At(i)); } else { key.PrintErrorInfo(); } printf("\n"); BYTE bCipherText[sizeof PPCKEYBLOB]; DWORD cbCipherText = key.Size(); CopyMemory(bCipherText, key.Data(), cbCipherText); // Decrypt the blob returned from the previous step. key.Call(PPCKEY_ACTION_DECRYPT, bCipherText, cbCipherText); if (key.Error() == PPCKEY_OK) { printf("Plaintext: "); puts(reinterpret_cast<char*>(key.Data())); } else { key.PrintErrorInfo(); } } void main() { CPPCKey key; if (key.Init() != NOERROR) { puts("Error connecting to device"); return; } GetPPCKeyVersion(key); GetPPCKeyKeyInfo(key); TestWords(key); }

To compile this example, you need to install Microsoft Windows CE Platform SDK on your desktop computer. The output from this application is something like this:

Version is: PPCKey for PocketPC v1.00.18 (IPaq Enhanced) RC4 key length is 128 bits. Ciphertext: 33 3D E0 09 EC 90 8A 4B F2 37 0E 9F CF C4 B4

The source code and supporting documentation for this sample application are available on the companion CD in the Tools folder.


	The PPCKey solution is by no means perfect, but it does make it much harder for an attacker to determine the private data. Two-factor encryption of this nature takes great advantage of the extensive programming platform on the Pocket PC.