Getting by without passwords: LUKS with smart-cards (part II)

[continued from part I]

Unlocking the encrypted partition

During the boot sequence, the system will prompt for the smart-card PIN as part of the execution of pkcs15-crypt command:

After providing the correct PIN, the card uses the private-key stored on board to decrypt the LUKS key. That key is returned to LUKS which unlocks the volume and permits the boot process to continue.

One tricky aspect handled by the key-script is managing terminal windows via openvt. Because the partition will be unlocked during boot and OpenSC has to prompt users for smart-card PIN to perform private key operations, that process must have access to console. This can be difficult to guarantee when I/O is being redirected as part of the boot sequence. A cleaner approach is to invoke decryption on a different TTY and switch the display over. This also makes the PIN collection slightly more legible by separating it from the clutter of messages related to boot process and appearing on its own window as above.

Weak links and redundancy

Strictly speaking, the sequence of steps detailed earlier adds an option to unlock an encrypted disk using a smart-card. But much like enabling smart-card login via pam-pkcs11, it does not require using the card. As long as the original LUKS key-slot is still present, using a hardware token is at best a convenience option: connecting a token and typing a short PIN maybe preferable to typing in a complex passphrase. But if the user had picked a “weak” passphrase for that, disk encryption is still subject to offline grinding attacks. In that sense, user-chosen passwords remain the weakest link in that setup.

Realizing the security benefit requires going one step further to remove the original keyslot using via cryptsetup luksRemoveKey. After that point, the only way to unlock the volume is decrypting the random secret.

Doing so however a new set of failure modes. What if the user forgets their PIN? Or loses their card? Even assuming perfect user behavior, what if the card itself malfunctions? There are even legitimate scenarios where the private key on the card may have to be replaced. For example when the certificate expires, issuing a new one may call for generating a new key-pair as well. (In theory PIV standard accommodates this by allowing the card to retain “archived” version of the key-management key. Unlike authentication or signature keys, this is one case where simply replacing an expired credentials is not enough. The old key is still required to decrypt previously encrypted ciphertext.)

This has several solutions, since LUKS permits multiple key-slots.

1. In the simplest case, the user could create a new key-slot with a random passphrase that is printed on hard-copy and tucked away offline.
2. For more high-tech solutions, one can repeat the process above using additional public-keys, creating multiple encryptions of the same random secret. (The corresponding private-keys may or may not reside on hardware tokens; that is an implementation detail.) Corresponding ciphertexts could be stored alongside the primary, to be used in case of a hardware problem with the original card.
3. A slight tweak involves creating additional key-slots containing random secrets, with each one encrypted to a different public-key. By contrast option #2 involves a single key-slot, with the same secret encrypted to multiple public-keys. The latter approach is slightly less flexible for revocation: if one wanted to remove one of the backups (for example, because the corresponding private-key is assumed compromised) it requires  deleting all copies of the ciphertext which reside outside the encrypted volume, as opposed  the removing the key-slot that is part of the volume.

Getting by without PIV

One final note about the functionality required of the card here. As with the examples for local login and SSH authentication, we have used a PIV card or more specifically a PIV token in USB form-factor such as GoldKey or PIVKey. But there is nothing in the above examples that assume a specific card-edge. As long as the middleware can recognize the card— and OpenSC boasts an extensive list of supported hardware— the exact same steps apply. Alternatively one can switch to using pkcs11-tool for encryption/decryption, in conjunction with a PKCS#11 module for the hardware to work with a broader range of hardware including HSMs for example.

CP