Layered security is often described as the practice of combining multiple mitigating security controls to protect resources and data. For example a properly configured service on a server may not prevent an intrusion if the server or the network does not have a securely configured firewall. One such security layer which is sometimes ignored is hard disk encryption. This is an additional layer on top of physical security of the device, i.e. it provides additional protection in case the device (server or laptop) is stolen.
LUKS serves as a standard for Linux hard disk encryption. By providing a standard on-disk-format, it not only facilitates compatibility among distributions, but also provides secure management of multiple user passwords. LUKS stores all necessary setup information in the partition header, enabling the user to transport or migrate data seamlessly.
For server devices which are always connected in a network, NBDE or Network Bound Disk Encryption is a solution which allows system administrators to manage LUKS encrypted disks remotely. The concept is simple: a client with a LUKS mount makes a remote call to a decryption key server. If the keys match, the mount happens without human interaction!
However there is no such management solution for laptops and a combination of LUKS based encryption and password or key based encryption is the only solution available. This however poses some interesting issues when deploying Linux on laptops in a corporate based environment.
Employees sometimes forget their passwords. This is especially a problem with LUKS passwords, since they cannot be controlled by a central authentication service like Kerberos, etc.
If employees leave the company in a hurry, or turn hostile, and you need to get access to the data on the laptop (assuming that data was not backed-up), there is no way you can decrypt the hard drive unless the LUKS password is known.
Key escrow is one method of implementing centralized control over LUKS based encryption of laptops (especially in a corporate based environment). Let's take a look at the steps it requires.
Installation and Partitioning process:
During installation of the laptop, which is often done using a standard common kickstart file in a corporate environment, use the following directives in the partition option:
--backuppassword: This will add a randomly-generated password to each encrypted volume. Each kickstarted laptop will have its own unique password. This password is created independently from the password which the user will use to decrypt his laptop.
--escrowcert: The random password created above is encrypted using a X.509 certificate and the encrypted file is stored in the
Before the installation process a certificate/private key pair is generated by the IT department to be used only for handling disk decryptions. The X.509 certificate is available during laptop kickstarts via an internally accessible URL. During partitioning, a per laptop, random, backup password is created, which is then immediately encrypted by using the certificate and stored in /root of the laptop. For example the partition part of the install looks something like this:
clearpart --all --initlabelpart /boot --fstype=ext4 --asprimary --size=200part pv.hd --grow --size=500 --encrypted --passphrase=”firsttime” --escrowcert http://someurl.corp.com/host.crt --backuppassphrase
The volume_key package is responsible for extracting the password from the LUKS header and encrypting it with the X.509 certificate provided.
--backuppassphrase options used in the kickstart file creates two separate files.
XXX-escrow-backup-passphrase, where XXX is the UUID of the partition which is encrypted. While the first contains data encryption, the second one contains the backup password.
Additional information like username, data/time stamp etc can be added to the filename. During post-install this escrow file is then uploaded to some management server or maybe some upload server (like ftp etc) where these files can be securely stored. These files are still encrypted with the certificate which was earlier created and as long as the private key is secure, brute force would be needed to decrypt these files.
Retrieval and password reset:
In the event that the user forgets his LUKS password or IT needs access to data on the laptop:
The relevant escrow file is located on the management server by using the earlier stored metadata like username, UUID of the partition, date/time stamp, etc.
The administrator then decrypts this escrow file, using the private key which may be in a local NSS database (more information about initial setup available here) on the server using something like:
volume_key --secrets [-d /path/to/nss/db] ./UUID-escrow-backup-passphrase
This will prompt for the private key password and print the backup password on the screen. The administrator then uses this to decrypt the user laptop.
volume_key --save [-c /path/to/cert] /path/to/volume --create-random-password escrow-packet-out
/path/to/volume is a LUKS device, not the plaintext device contained within: (
blkid -s TYPE /path/to/volume) should report
This new packet can again be copied to the escrow server and used in future scenarios when password is forgotten again, etc.
Apart from the above several other scenarios exists which can be used for centralising storage and backup of escrow password.
However there are some caveats which one needs to understand:
While hard disk encryption adds to the security of the laptop or server used, it is most effective when the machine is shut down. This is mainly because data contents in the memory is not encrypted and can be retrieved via attacks like the cold boot attack.
Backup passwords in the LUKS header can be reset or completely removed if the user has access to write directly to the drive (usually via root access). Thus these methods can only be effective if corporate policy prevents users from having privileged access.
Overall full hard disk encryption via LUKS and password management via
volume_key should provide an effective solution for the management of passwords on encrypted laptops