Encryption Yubikey.............................
A very sensibly minded Stuart Burns shows how to use Yubikey and two-factor authentication to significantly improve Linux system security.
John Lane expands your worldview with a dive into GnuPG’s key-based trust model.
Much has been mentioned recently about system security and effective system management. Putting into practice a two-factor authentication (2FA) capable device helps increase that security stance.
Using devices such as the Yubikey has many advantages including helping keep local disks encrypted, login details secure and SSH keys safe from hackers. These devices are designed to keep data secure and only expose the information from the device when it’s required.
The Yubikey can be used as a standalone device or it can also be registered with Yubikey and the company’s password service to provide secure password management and automatic web password management. The Yubikey can also be used with Facebook, Google and a range of other providers to provide secure 2FA logins to help prevent account hijacking. How to implement this will vary from site to site, but there are many tutorials available on how to achieve this.
Furthermore, pressing the capacitive device will generate an extremely long and secure password known as an OTP (one time password) in place of a memorable password to help make it hard for anyone trying to steal your information. This article looks at a number of specific uses of the Yubikey: secure full disk encryption; securing SSH keys; and lastly, using it as a secure means to log into other Linux computers via SSH.
For this tutorial, I’ll be making a number of assumptions. The first is that the reader has a Yubikey 4 and that the device isn’t being used for any other purposes. Secondly, I’ll approach the subject with the view that LUKS has already been set up and is working as expected. It’s also assumed that there’s a good, tested backup and that this is being tried on a non-production computer. These steps, if performed incorrectly, could result in the user permanently losing access to their encrypted data.
Get installing
There are additional packages that Yubikey needs to function correctly in Linux. This article uses Ubuntu 16.04. From a command terminal install these packages: sudo su - apt-get update -y apt-get install -y yubikey-luks yubikey-personalization scdaemon exit
Once installed, the user can configure the hardware key. It’s important to understand how the Yubikey works. There are several storage slots on the Yubikey device. Each slot can contain a specific encryption key/password. Technically, there are several slots but only the first two are officially supported for use with passwords. This is separate from the SSH storage locations.
The Yubikey will need to be configured to work with the LUKS encryption. First, insert the Yubikey. To initialise the second slot for use with LUKS issue the following command: sudo ykpersonalize -2 -ochal-resp -ochal-hmac -ohmac-lt64 -oserial-api-visible
Commit the changes by pressing Y. Before running the command below to configure Yubikey and LUKS, it makes sense to check that the correct encrypted partition is being used. This can be done simply by viewing the file /etc/ crypttab. Use the command below to verify the disk: cat /etc/crypttab
The encrypted partition can be found at the beginning of the first line. In my case the partition was /dev/sda5. The partition sda5 is always the encrypted disk if the Ubuntu defaults were chosen during the system installation. The last remaining item is to update the LUKS system to use slot seven from the Yubikey device. It adds a second LUKS key that won’t work without the hardware key and password: sudo yubikey-luks-enroll -d /dev/sda5 -s 7
At this point the user has to insert their Yubikey and enter a new additional password for use in conjunction with LUKS. Enter a new, unique password. It will ask to confirm it. Finally, it asks for the original passphrase for the LUKS disk. Be sure to enter this correctly or it won’t work as expected. Now it’s just a matter or rebooting the computer and testing that the new encryption setup has been applied properly.
On reboot the user should insert the Yubikey and enter the newly created LUKS passphrase. All being well, it should then boot as expected. If, for whatever reason, this doesn’t work the original LUKS passphrase can be used. This original password can be strengthened later (otherwise it negates the security provided by the Yubikey).
Secure your keys
It’s now time to start looking at using the Yubikey to secure the users private keys. If a user has several Linux-based computers that they routinely log into using passwords, they’re doing it wrong. Logging in using SSH keys makes the whole login process more difficult to gain illicit access.
Using SSH keys to log in is done by creating two keys: a public key and a private key. The public key is uploaded to the machines to be administered and the private key kept secure on the Yubikey and protected by a password. When the user tries to log on they use their private key that only they have, together with a password. When the system has both parts of the key it can verify the user’s identity. Without both parts of the key nothing is going to happen. The password is only there to unlock the private key for the duration of its use.
Yubikey doesn’t internally implement public/private key creation. To set up and configure the Yubikey requires using the opengpg2 package to create the keys and then transfer the private keys on to the Yubikey. Note there are two versions of gpg installed by default: gpg and gpg2. This article uses gpg2 because it has some major code enhancements and works much better with gpg-enabled cards such as Yubikey. Attempting to use the original gpg will cause several steps in this tutorial to not work correctly, if at all.
The key creation and setup process may seem long winded, but really it’s quite straightforward. The next several steps include: Creating a master key; Creating a revocation key; Adding a sub key that can be used for logins, signing and encrypting;
Removing the master key from the keyring so that it can’t be used to sign new keys; Put the private certificates onto the Yubikey; Export the SSH public keys; Copy them to the destination servers.
The first step is to create a master key. This key is essentially the equivalent of the root user in key management terms. With Debian derivatives, the server creates two keys: a master key that can be used for certifying sub keys; and a sub key that has encrypt and sign capabilities. It may seem odd, but doing this separates your master key (which proves your ultimate identity) from the day-to-day keys. There’s, however, a very real reason behind the decision. If the sub key is lost or compromised the user doesn’t have to build their identity from scratch. When the key creation process detailed below is complete there’ll be four keys: a master key, a signing and certifying key and an authorisation key. The authorisation key is used to connect to SSH devices.
To generate the master key use the following command: gpg2 --full-gen-key
This creates the keyring files and folders if they don’t exist, along with the master key. Because this tutorial is only using this as an example setup, we can use the defaults. Doing so isn’t recommended in a live environment for obvious reasons. For this key go with option 4: RSA sign only.
Once the first few questions about key lengths and expiration have been accepted (using defaults) the application will ask a name and email address to uniquely identify the key. For the purposes of this tutorial enter your name and email address. Comments are optional. Once the details are confirmed as correct press O to create the key. The system will also ask for a passphrase. This is used to
protect the key from being used if it’s stolen. The system will spit out a lot of text, but what we’re interested in is the public key. The key ID can be found to the right of rsa2046/.
As you can see from the base key generated it has the entry rsa2046/xxxxxx where x is a long number. This is the key identifier. Because this tutorial will use that key several times it makes life easier to alias it. It reduces all the copy/ paste operations or the potential fat-fingering of the number. In the terminal type: export KEYID=Your key ID.
Keep it secret, keep it safe
The next important step is to create a revocation key. This can be used to effectively cancel any keys that have been lost, stolen or compromised. The exported key shouldn’t be kept on the local device but rather on a memory stick in a secure location. To create the revocation file, do the following, substituting the location for the users usb stick: gpg2 --gen-revoke $KEYID > /path/to/usb/revoke.txt
In a similar way to the original key creation the process will ask several questions. When asked for a reason for revocation we can use “0”. Among other items, it’ll ask for the passphrase for the master key as well as a new passphrase for the revocation key. The next step is to export the “secretkeys”. Don’t get confused by the terminology. Secret keys essentially mean private key. It’s just a language thing! To export the key to the USB stick, use the command below, substituting locations as needed: gpg2 --armor --export-secret-keys $KEYID > /path/to/usb/ master.key
After we have set up the main keys you need to create the subkeys. Here we create the subkey for signing. Notice the use of the --expert switch. This enables several options that we will need: gpg2 --expert --edit-key $KEYID
To add the key use the addkey command. Select option 4 (RSA Sign only). Again, go with the defaults and a new passphrase. Notice at the bottom there’s now a new entry and its usage is marked “S”. This means that the key is a signing key.
The process is repeated to create the encryption key. Assuming the user is still in the gpg2 application type addkey. Select the option for RSA Encrypt only. Go with the defaults as per previous iterations. Ultimately, there should now be a new key marked usage E.
The last key to create is the authorisation key. This is the key that’s used to login as opposed to signing, revoking, and so on. Run the addkey command again. This time, however, we need to select “RSA (set your own capabilities)”. This is because the usage needs to be changed to be an authentication key. If this doesn’t appear you didn’t use expert mode!
With the authorisation key the capability of the key needs to be set to Authorize. The permitted actions can be turned on or off by toggling them using the S, E or A keys. Toggle as needed until only the Authenticate is showing. Press G to finish the configuration. Accept the defaults. Hopefully, there will be four keys: SC, S, E and A. Save all the work done by
typing save. This will dump the user at the command line. Once completed another subkey marked “usage A” should appear. All this setup now needs to be saved. Save it to disk by typing save. This will then place the user back at the Linux command prompt.
Now export the keys and subkeys private keys: gpg2 --armor --export-secret-keys $KEYID > /path/to/usb/ master_ and_ sub.key gpg2 --armor --export-secret-subkeys $KEYID > /path/to/usb/ sub.key Next it’s time to export the SSH keys. gpg2 has a tool to export SSH private and public keys from the OpenGPG keys: gpg2 --armor --export $KEYID > /path/to/usb/public_gpg.key gpg2 --export-ssh-key $KEYID > /path/to/usb/public_ssh.key At this point the Yubikey can be inserted. To check the card can be seen use the following command: gpg2 --card-edit
All being well it should show some pertinent information about the Yubikey in question. For our purposes we can ignore most of the entries. The only items I’d suggest you modify are the user pin and admin pin. To do this the key needs to be switched to admin mode. Do this by typing admin followed by passwd. The default user pin is ‘123456’ and the administrator pin is ‘12345678’. Change each of these items by choosing the appropriate number and modifying the pins. Don’t forget to save the items before leaving.
Load into Yubikey
The next job is to load the authorisation, encrypt and sign keys that were created earlier into the Yubikey. This is done using the keytocard command. This step has to repeated several times, once for each key, until the sign key, encryption key and authentication key are transferred: gpg2 --edit-key $KEYID
At this point the user needs to select the appropriate key. Type key 1. This selects key 1 on the key. To actually move the private key to the keycard type keytocard to enable moving the local keys to the Yubikey. It will ask where to store the key on the Yubikeys slots for private keys. Select Signature key from the selection. Type key 1 again and it will deselect the key. The selected key is denoted by a ‘*’ against the subkey.
Repeat the keytocard by using key 2 and keytocard selection 2. Repeat again using key 3 and selection 3 (It should be the only one available). At this point all the keys have been copied to the card. They do still exist on the computer! Best practice states that the root signing keys should be removed. At this point let me reiterate that deleting these keys should only be done when the backup is complete and you have a good copy: gpg2 --delete-secret-keys $KEYID
The gpg2 program will ask you several times to confirm you really, truly want to delete the master key. Once completed check the status of the Yubikey keys: gpg2 --list-secret-keys
The security key should now have a ‘#’ against it. This lets the user know that the key doesn’t exist on the device. Also the ‘>’ on the subkeys means that the key is on the card. At this point, because we’ve deleted the master key, we can now import the stub keys. On a separate machine, to set up the device run the command gpg2, followed by Ctrl+C. This is done to create some critical folders and files.
Once complete, import the public keys: gpg2 --import < /path/to/usb/public_gpg.key
Double-check those keys are available by using a gpg2 --list-secret-keys. We now need to trust the new key because we essentially took it away from its parent, therefore the chain of trust is missing. To make life easier use the export KEYID= the sec# key. To perform the trust option edit the key: gpg2 --edit-key $KEYID trust
When prompted to enter the trust level, select 5 (I trust ultimately). Agree to the trust by pressing Y. At this point, quit out by using quit.
At this point all the configuration for your Yubikey device is done. The last bit we need to look at is to enable the automatic “pass-through” of the private key functionality when needed. This is done with two commands: echo “enable-ssh-support” > ./gnupg/gpg-agent. configuration echo “export SSH_AUTH_SOCK=~/.gnupg/S.gpg-agent. ssh” >> ~/.bashrc
Reboot the machine at this point for the services to update the configuration. Once complete, open a new terminal window and use the command ssh-add -L. If the SSH pass-through is working then it should show a pair of entries. At this point you can use the command ssh-copy-id user@remotehost. Login using your normal password. This will copy your public key to the server. It will take only a moment to complete.
If the user now tries to ssh into the host it will pass the private key credentials and prompt for the private key password. To see this in more detail use the command: ssh -v user@remotehost
It will hopefully show the public key being used. If you try again without the Yubikey it should fail. In summary, the Yubikey and other hardware keys offer a whole range of useful functionality. While a lot of it may not seem easy, it’s certainly worth doing, if only for peace of mind.