Cryptographic Vault

James F. Carter, 2004-11-14

Most machines have a whole family of unencrypted secrets, e.g. the SSH host key, the secret key that goes with the digital certificate used to send TLS mail, and the web browser's HTTPS secret key. How can these be protected properly?

Protected from what? On a datacenter machine, the main threat is that a hacker perpetrates a root exploit during normal operation. This threat is less, but not zero, on a personal laptop.

On a personal laptop the major threat is that it will be physically stolen, after which the Black Hats can run a rescue system or transfer the disc to a convenient other system, and apply whatever tools they please. Thus, when the laptop is stolen, the secrets must be encrypted. Most likely the laptop will not be running when stolen, but there is a high probability that it may be suspended. Let's deal with this case first.

Cryptographic Vault for Theft Resistance

Thus, the secrets in the Cryptographic Vault are accessible only when the machine is in active use, and (most likely) they are not accessible if the machine is physically stolen.

Objections to the Cryptographic Vault

Root Exploits in Normal Operation

Turning to the datacenter situation: In what is commonly called a root exploit, the usual procedure is to induce a system daemon to execute arbitrary hacker-provided code under its own permission, which often is the superuser (root). The exploit code will then do general hostile activity such as reproducing by attacking other vulnerable machines, installing a bot to which the hacker can open a connection and give commands, vandalizing the victim machine, or (of particular interest here) looking for secrets and mailing them back to the hacker.

The Cryptographic Vault is useless against root exploits (except possibly with SELinux), because the crypto filesystem is mounted and decryptable when the exploit happens.

It is not prudent to assume that system code is perfect; in other words, we have to assume that security holes are always present. However, the ones that are easy to find have already been found and fixed, and in many cases security holes are found by the developers or (for open-source software only) interested third parties, so-called White Hats. These are then fixed and are never exploited. But occasionally a new exploit is found circulating in the wild. Once it is recognized, the fix usually appears promptly.

These steps can mitigate the vulnerability of the datacenter machine to a security breach. The same steps are important for personal laptops.

Unattended Booting of Datacenter Machines

If you are serious about security, you should only run your machines, including booting them up, when a trusted operator or owner/user is in immediate attendance, and the operator can enter the password. However, there are many situations where an operator is not feasible, for example a small business, a commercial hosting company (colo) (which may have an operator, but not one trusted by you), an academic department, or a public computer lab where users may power cycle the machines. How can you use the Cryptographic Vault in this situation?

If the hacker can perpetrate a root exploit he can read the secrets directly (except possibly with SELinux), so these schemes are deemed sufficient if a root exploit is needed to break them.

Let's be clear what threat is being protected against: a hacker who breaks into an unattended datacenter or public lab, or an unscrupulous colo operator, physically working on the victim machine. This is the same type of threat as for a stolen personal laptop, but with more weaknesses since the machines have to boot unattended.

Conclusion

Appendix: Implementation Plan

Survey of Cryptographic Processes

Here is a complete survey of processes on a personal laptop, split up by cryptographic significance:

Requires cryptographic secrets, should use the vault:

Requires crypto but cannot use the vault:

Potential crypto but not encrypted on this system:

No cryptographic implications:

More Implementation Plan

As a compromise between useability, implementability and security, this alternative scheme is proposed for mounting and unmounting the vault. This is specifically for a personal laptop or workstation where all users (generally only one) are authorized to mount the root's portion of the crypto vault.

The exact protective mechanism is like this: each user including root has a vault, which is encrypted with a randomly generated key, which is contained in a file encrypted with GPG. Such a file can be encrypted with the public keys of multiple recipients, e.g. root and jimc both, and this is done for the root vault. A script running (setUID root) on behalf of the user who is logging in will use the login password to decrypt the user's GPG secret key, to decrypt root's vault key file, to attach root's vault to a loopback device, to mount root's vault. The system-wide secrets are in this vault. Other secrets such as the user's SSH key are in the user's own vault, which is mounted similarly via a second loopback device.

The above plan means that pam_runscript needs to be able to ask for the password by itself, which it is presently not able to do. This has been accomplished, and the Cryptographic Vault appears to operate successfully.