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.
ssh and gpg include an
agentwhich, given the user's passphrase, decrypts and stores in memory his secret key, so that the passphrase is not needed separately for every transaction. The key is more or less vulnerable to attacks against memory. The
rightway to handle this is for the user's secret key to be unencrypted in the vault, to be read on every transaction. This mode is particularly feasible for
gpg; less so for ssh.
While not feasible on a shared execution server, storing the user's personal
secret in the vault is particularly useful on a personal laptop.
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.
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.
ssh and
postfix, can execute their most risky parts as a special user, not
root, so that any damage is confined to files owned by the special user.
Attacking such a system is not worthwhile for a virus (or its author). This
feature should be used when available.
SELinuxset of kernel patches, which strip the root user of much of its power while still allowing the system to provide normal services, relatively unobtrusively and with low runtime overhead. Administering such a system takes extra work because normal system administration tools and training assumes that root has permission to do anything. Nonetheless, the enhanced security is worth the bother in administration.
SELinuxwould be much harder for a virus to exploit productively.
ssh entirely. Similarly, Sun's NFS was never
intended to resist hackers, and a more secure network filesystem like AFS
should be used.
su(activate the root user) on a personal laptop, you should exit from that shell before the laptop is stolen. Particularly you should not leave a root shell active when you suspend the machine.
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.
First, the BIOS should be password protected and configured so a CD-only rescue system cannot be booted, particularly in a public computer lab. The checksum of the nvram should be used in relevant cryptographic keys, so if a hacker opens the case and clears the nvram, enabling the rescue system to boot, steps listed below will fail.
You can get a lockbox card
. After a PCI bus reset (i.e. upon
boot), it will divulge a secret, but only once, and only if the operating
system sends in its own secret, which is typically a checksum over the kernel,
system libraries and the nvram. Exchanging one secret for another seems
not useful for the Cryptographic Vault.
Also one has to wonder whether the secret is stored in nvram that can be unsoldered and read by the Black Hats, having stolen the computer with the card in it. None of the protections in this section can withstand that intensity of attack.
During boot, you can communicate over the net (by an encrypted protocol using Diffie-Hellman key exchange) with a machine that stores the necessary secrets for all your servers or lab machines, similar to the lockbox card. However, the hacker can communicate too and receive the secret. These variants may have better security.
Thus, Ethernet with a MAC check is probably the most practical variant for the secret server. But the secret server has similar vulnerabilities as the clients, and it also has to boot unattended. This solution is probably only useful in a public lab where the secret server is physically better protected than the clients.
Suppose the secret needed to decrypt the Cryptographic Vault is simply a checksum over the nvram content, possibly concatenated with another file, different on every machine. Both of these elements would have UNIX file permissions locking out the hacker during normal operation (barring a root exploit). To boot a rescue system, the hacker would have to clear the nvram content, specifically its password, losing this essential part of the crypto secret. This is the simplest solution and is probably sufficient for the level of protection implied by the public lab or unattended datacenter model.
Unfortunately, when a BIOS password was set, /dev/nvram did not change.
Here is a complete survey of processes on a personal laptop, split up by cryptographic significance:
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.
When the system boots, services whose secret keys are in the vault will be deferred, not starting until after the vault is actually mounted (if ever).
As part of the PAM stack for the X display manager (kdm, etc), a module will run which mounts the vault. The proposed module is pam_runscript (by jimc), which runs an arbitrary script with (if so configured) the password piped in on an open file descriptor.
If root's crypto vault key file is not encrypted with the user's key (e.g. a guest account), the vault cannot be not mounted. Since Kerberos cannot start, the user cannot log in. However, if an authorized user logs in first, Kerberos can start, and it only needs its secret key at startup time. After that, unwashed users can log in.
For Kerberos, the vault will be mounted first as part of the PAM auth phase, then Kerberos will be allowed to start up, then the script will exit allowing the Kerberos auth module to check the user's identity. The vault will be mounted before Kerberos has authenticated the user. The user needs to give a correct password to decrypt the vault, and this is actually sufficient authentication so that Kerberos is redundant, but GSSAPI is needed to propagate the user's identity for some services.
The vault mounting script needs to positively verify (by fsck on the loopback device) that the password will decrypt the vault, so as not to try to mount random garbage, which could break something.
The user is required to lock his screen when not in immediate attendance
to the computer, including before suspending a laptop. Xlock has the -startCmd
command which it runs at that time, which would unmount the vault. It is
necessary that the vault mountpoint be configured with the user
attribute so the user can mount and unmount it. The startCmd should also reset
the ssh-agent and gpg-agent. It will not be possible to cause daemons such as
Postfix and Apache to forget their secrets. Beware, if the X-server cookie is
in the vault, eye candy (so-called screen savers) will not be able to run.
To unlock the screen, the user must type his password. Xlock has the -pipepassCmd command which can receive the password and remount the vault. It's assumed that there is no password on the ssh and gpg secrets, so it is trivial to then reload the respective agents.
On session tear-down, the vault will be dismounted. But a scenario can be envisioned where the auth phase mounts the vault but no session ensues, e.g. the account phase denies access. On the personal laptop this is not credible. Or if the display manager crashes, the session closing phase would not happen and the vault would remain mounted. If this is going to be a problem, a cron job can check for a live session and dismount the vault if a session is not apparent.
Crypto services will not be able to read their secrets when the vault is not mounted. It is hoped that they either cache the secret in memory, or fail gracefully and can be revived when the vault is remounted. See notes with the services on this point.
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.