Raising the Security Bar

Raising the Security Bar

This section focuses on the different ways of storing secret data and describes the effort required by an attacker to read the data (information disclosure threat) or to modify the data (tampering with data threat). In all cases, a secret file, Secret.txt, is used to store secret data. In each scenario, the bar is raised further and the attacker has a more difficult time.

Storing the Data in a File on a FAT File System

In this example, if the file is stored on an unprotected disk drive as an XML configuration file, for example all the attacker needs to do is read the file, using either file access or possibly through a Web server. This is very weak security indeed if the attacker can access the computer locally or remotely, she can probably read the file.

Using an Embedded Key and XOR to Encode the Data

The details in this case are the same as in the previous scenario, but a key embedded in the application that reads the file is used to XOR the data. If the attacker can read the file, he can break the XOR in a matter of minutes, especially if he knows the file contains text. It's even worse if the attacker knows a portion of the text for example, a header, such as the header in a Word file or a GIF file. All the attacker need do is XOR the known text with the encoded text, and he will determine the key or at least have enough information to determine the key.

Using an Embedded Key and 3DES to Encrypt the Data

Same details as in the previous scenario, but a 3DES (Triple-DES) key is embedded in the application. This is also trivial to break. All the attacker need do is scan the application looking for something that looks like a key.

Using 3DES to Encrypt the Data and Storing a Password in the Registry

Same as in the previous scenario, but the key used to encrypt the data is held in the registry rather than embedded in the application. If the attacker can read the registry, she can read the encrypted data. Also note that if the attacker can read the file and you're using a weak password as the key, the attacker can perform a password-guessing attack.

Using 3DES to Encrypt the Data and Storing a Strong Key in the Registry

Same as the previous scenario, but now the attacker has a much harder time unless he can read the key from the registry. A brute-force attack is required, which might take a long time. However, if the attacker can read the registry, he can break the file.

Using 3DES to Encrypt the Data, Storing a Strong Key in the Registry, and ACLing the File and the Registry Key

In this case, if the ACLs are good for example, the ACL contains only the Administrators (Read, Write) ACE the attacker cannot read the key or the file if the attacker doesn't have administrator privileges. However, if a vulnerability in the system gives the attacker administrator privileges, he can read the data. Some would say that all bets are off if the attacker is an administrator on the box. This is true, but there's no harm in putting up a fight! Or can you protect against a rogue administrator? Read on.

Using 3DES to Encrypt the Data, Storing a Strong Key in the Registry, Requiring the User to Enter a Password, and ACLing the File and the Registry Key

This is similar to the previous example. However, even an administrator cannot disclose the data because the key is derived from a key in the registry and a password known to the data owner. You could argue that the registry key is moot because of the user's password. However, the registry entry is useful in the case of two users encrypting the same data if the users share the same registry encryption key. The addition of the user's password, albeit inconvenient, creates different ciphertext for each user.

Ultimately, you have to consider using alternative ways of storing keys, preferably keys not held on the computer. You can do this in numerous ways, including using special hardware from companies such as nCipher (http://www.ncipher.com).