The Strategy That Allows You to Store PGP Keys Offline On Linux 

The population as a whole has almost no use of OpenPGP, this is a critical security element, especially for Linux distributions.

For example, the central Debian repository checks each package using the OpenPGP key of the maintainer and then signs it with its own key. If the packages that are included in the branch also have such signatures, then a full chain of trust is created from the original developer to the users. In addition, the Pull-Requests in the Linux kernel are also verified by digital signatures.

Therefore, the stakes are high: if the key for signing the release is compromised, or at least the key of a single maintainer, a devastating attack on many machines can result.

This led the Debian community to a better understanding of good practices with cryptographic signatures (which are usually created in the GNU Privacy Guard program, also known as GnuPG or GPG).

For example, weak (less than 2,048 bits) and vulnerable keys PGPv3 in 2015 removed from the keychains, and among the developers of Debian is the widespread practice of mutual signing of keys in person. But even Debian developers seem to have no generally accepted rules for storing critical secret material, as seen in the discussions from the list of the Debian-project mailing list.

• This discussion boils down to the only simple requirement: where to get the “guide for storing electronic keys for dummies”?

Electronic hardware keys or smart cards, as we call them here, are small devices that allow you to store keys offline and are one of the options for protecting sensitive material, that is, the key. In this article, we will try to share our experience in this area and explain the problem of how to store these precious secret keys, which in the event of compromise will harm the dangers of millions of computers around the world.

Why do we need to store keys offline?

Before we disassemble in detail the storage of passwords offline, it will be useful to briefly recall how the OpenPGP standard works. OpenPGP keys are created from the main public and private key pair, the certification key that signs the user IDs, and the subkey.

Our public key, shown below, contains the usual certificate/signature key (marked as SC), as well as the encryption cipher (marked as E), a separate signing key (S), and two authentication keys (labeled A) that I use as keys RSA for authorization on servers on SSH, thanks to the project Monkeysphere.

pub rsa4096/792152527B75921E 2009-05-29 [SC] [expires: 2018-04-19]
8DC901CE64146C048AD50FBB792152527B75921E
uid [ultimate] Antoine Beaupré <anarcat@anarc.at>
uid [ultimate] Antoine Beaupré <anarcat@koumbit.org>
uid [ultimate] Antoine Beaupré <anarcat@orangeseeds.org>
uid [ultimate] Antoine Beaupré <anarcat@debian.org>
sub rsa2048/B7F648FED2DF2587 2012-07-18 [A]
sub rsa2048/604E4B3EEE02855A 2012-07-20 [A]
sub rsa4096/A51D5B109C5A5581 2009-05-29 [E]
sub rsa2048/3EA1DDDDB261D97B 2017-08-23 [S] 

All subkeys and identifiers (UID) are linked by a master certification key using digital signatures with self-authentication. So although an attacker who has received a secret subkey can forge my signatures or perform authentication on other servers, this subkey can always be revoked using the primary certification key.

• But if the certification key is lost, everything is lost: an attacker can create or revoke identifiers or subkeys, as he wishes. In the most catastrophic scenario, an attacker will steal a key and erase your copies, gaining complete control over the key without any possibility of recovery from your side.

By the way, that’s why it’s so important to generate a revocation certificate and keep it offline.

So, by moving the certification key offline, we reduce the chances of attacking the OpenPGP trust chain: everyday keys (for example, for encrypting email or digital signatures) can remain online. If they are stolen, the certification key will recall these keys without problems, and it will remain safe.

Note that stealing the encryption key is another problem: even if we withdraw the encryption subkey, this will only affect future encrypted messages. With the help of a stolen subkey, an attacker will be able to read previous encrypted messages even if this subkey is recalled, so that the benefits of revocation of encryption certificates are more limited.

Key strategies for offline key storage

Taking into account compromises of safety, it is proposed to store critical keys offline in order to reduce the risk. But where exactly? Jonathan McDowell, a member of the Debian keychain service group, talks about three options: an external LUKS-encrypted volume, an isolated system or a key card disconnected from all communication channels.

• Full-disk encryption like LUKS adds an additional level of security, hiding the key from the attacker. Even though the secret keychains are usually protected with a password phrase, it’s easy to recognize that this is a bunch of keys.

But if the volume is completely encrypted, it is not immediately obvious to the attacker that there are keys on the device. According to Sean Witton, another advantage of LUKS over conventional encryption of a keychain in GnuPG is that when creating the LUKS partition, you can pass the argument –iter-time to increase the key derivation delay, which greatly complicates the brute force. In fact, GnuPG 2.x does not have an option for configuring the key generation algorithm, although a patch has recently been introduced that allows you to configure the key generation delay at compile time gpg-agent. He is now responsible for all transactions with a secret key.

• The lack of external volumes is unnecessary complexity. GnuPG complicates the process of extracting secrets from the keychain, which makes the initial installation wiser and error-prone. In versions 2.x, the procedure was simplified with the new storage system and the corresponding key grip files, but it still requires a secret knowledge of the internal GPG device. It’s also inconvenient to use secret keys that are stored outside of your main keychain. When they are really needed, GPG does not know where to find them now.

Another option is to establish a separate isolated system for certification operations. An example is the clean room project of PGP, it is a functioning Debian-based system developed by Daniel Pocock to launch the OpenPGP and X.509 certification center on conventional hardware. The basic principle is to store secret keys on a separate machine that never connects to the network and therefore is not subject to attack, at least in theory.

Personally, we reject this option, because it seems to me that isolated systems give a false sense of security: after all, the data must somehow get into the system and be extracted from there, even if it’s only about extracting signatures that expose the system to attacks.

• In the same way, OS updates are complicated: to keep the system safe, you need to install updates on a network isolated from the network. Usually, the information is distributed via USB-flash drives, which makes it possible to infect the system through vulnerabilities like BadUSB.

From the moment of infection, there is a bunch of exotic ways to shoot data using LEDs, infrared cameras or an old good TEMPEST attack. So I came to the conclusion that the benefits of simplifying the procedure that the isolated system gives are not worth it. Moreover, with isolated systems it’s actually not so easy to work: although PGP’s “clean room” has come a long way to develop, it still does not have simple scripts for the percentage of signing or keying, that is, the same problem as the approach with external encrypted volumes LUKS.

Advantages of Smart Cards

We chose an approach using cryptographic smart card: it is an external device that is usually connected via a USB connector, it stores a secret key and performs critical cryptographic operations on behalf of the host.

For example, the FST-01 smart card decrypts in asymmetric RSA and ECC encryption schemes, without giving out the secret key material to the host. In fact, a key card is a miniature computer that performs a limited set of calculations for another host. Key cards usually support several “slots” for storing subkeys.

• The OpenPGP standard sets three default subkeys: for signing, authentication, and encryption. In the end, a real physical keypad for entering passwords can be on the smart card, so that the potential keylogger is powerless here, although we did not get any smart cards with such keyboards.

It is easy to draw a parallel between the smart card and the isolated system; in fact, a smart card is an isolated system in a miniature that suffers from the same problems. An attacker can intercept data on the host and attack the device in the same way, if not easier because the smart card is in reality “online” (that is, not explicitly isolated) after the connection. However, an advantage over completely isolated computers is that the key card performs only a limited set of operations. So creating an open hardware and software architecture that has been audited and verified is much easier than with a general purpose computer.

• Like isolated systems, smart cards prevent an attacker from gaining access to a secret key. It can deceive the key card to sign or decrypt any data, but this is only possible when the device is physically connected to the computer and the smart card will ask the user for the password before the operation, although it may some time cache the password.

In effect, offline attacks are not possible: to pick up the password for the key with a brute force, the attacker must access the victim’s computer and try to pick up the password here, while the smart card allows only a limited number of attempts. It also provides a clear and standard interface for storing keys offline: with one GnuPG command, the secret key material is moved to the key card (the key to card command in the -edit-key interface), while moving material to the encrypted LUKS device or an isolated computer represents a more complicated procedure.

The smart cards are also more useful when working with multiple computers. A common problem with using GnuPG on several machines is how to safely copy and synchronize the secret key material on multiple devices, which generates new security issues. In the end, “the rule of good taste in a crime lab”, according to Robert Hansen from the GnuPG mailing list, is “to store as little personal data on your systems as possible.” The smart card here is good on both sides: you can use your secret key on several computers, but will not store its multiple copies. In fact, Mike Gerwitz is more categorical:

“For users who need a GPG key on several machines, I consider the smart card to be a necessary device. Otherwise, the user simply increases the risk of compromise.”

Disadvantages of the Smart Cards

As Gerwitz noted, there are some negative points in using a key card. Another developer Debian Voter Verhelst clearly formulated them:

“Smart cards are useful. They guarantee that the secret half of your key will never get on the hard drive or any other usual media, and therefore it can not be stolen (because there is only one copy).

Smart cards are also a pain in the ass. They guarantee that the secret half of your key will never get on the hard disk or any other usual media, and instead it lies in your purse, so every time you need access to it, you will have to get a purse, which takes more time than just run GnuPG. If your laptop does not have a built-in card reader, then you’ll also need to get a card reader from your backpack or from somewhere else. “

“Smart cards” here refer to old OpenPGP cards with IEC 7816 connectors that needed special card readers. A new smart card just uses the usual USB interface. In any case, the external device introduces new problems: an attacker can steal your key card, you can simply lose it or wash it with dirty laundry.

• Of course, a laptop or a computer can also be lost, but it’s much easier to lose a small USB smart card than a whole laptop – and I have not yet heard that someone has washed the whole laptop in a washing machine. When you lose a key card, if there is no separate revocation certificate, you completely lose control of the key, which will be a disaster. But even if you recall the lost key, you will need to create a new one, which means building a trust network from scratch for this key is quite an expensive operation, because usually, it includes a personal meeting with other OpenPGP users for sharing prints.

Therefore, you should consider creating a backup copy of the certification key.

The same problem exists for online keys. Of course, everyone has revocation certificates and backup copies of their OpenPGP keys … right? In the case of a smart card, several key cards distributed geographically may become backup copies.

Note that unlike isolated systems, a key generated by a card cannot be backed up by definition. For subkeys, this is not a problem, because they do not need backup copies (except encryption keys). But for the certification key, this means that the user must generate the key on the host and copy it to the card, that is, the host must provide sufficient entropy to generate cryptographically persistent random numbers.

Also, keep in mind the possibility of combining different approaches: for example, you can use a key card for everyday operations, but store a backup copy of the certification key on a LUKS-encrypted offline volume.

• The smart card represents a new element in the chain of trust: you must trust the device manufacturer that it has not included any malicious code in the firmware or hardware. In addition, you must believe in the correct implementation.
• The Smart cards are more difficult to update: the firmware can be intentionally closed for access from the host for security reasons or may require special software to manipulate it. Key cards can perform certain operations slower than the CPU because there are small built-in microcontrollers with limited processing power.

Finally, smart cards can encourage users to trust their secrets to many machines, which contradicts the principle of “minimum amount of personal data”. A completely opposite approach is called Trusted Physical Console (TPC): instead of trying to deliver a secret key to all machines, you have a single machine that is used for all cryptographic operations. Unlike a key card, TPC is a real computer, for example, a laptop, which does not require special procedures for key management. The disadvantage, of course, is that you have to carry this laptop with you everywhere, which can be problematic, especially in some corporate environments where it is forbidden to bring your own computers.

Brief practical tips on how to write/edit/using commands with smart cards

It’s easy to write keys to a card:

1. Start with a temporary key to test the procedure:

   export GNUPGHOME=$(mktemp -d)
   gpg --generate-key
   

2. Edit the key using the user ID (UID):

   gpg --edit-key UID
   

3. Use the key command to select the first subkey, then copy it to the card (you can also use the addcardkey command just to generate a new subkey directly on the map):

   gpg> key 1
   gpg> keytocard
   

4. If you want to migrate the subkey, use the save command, which will remove the local copy of the private key, so the only copy will be stored on the card. Otherwise, use the quit command to store the key in the bundle, but store the private key in your regular keychain; answer “n” to “Save changes?” and “y” to “exit without saving?”. In this way, the card will become a backup copy of your secret key.
5. If you are satisfied with the result, repeat steps 1 through 4 with your usual keychain ($GNUPGHOME reset)

After the key is transferred to the map, the command –list-secret-keys will show it as sec> (or ssb> for the subkeys) instead of the usual keyword sec. If the key is completely missing (for example, if you transferred it to the LUKS container), the # sign appears. If you need to use the key from a backup on the card, you simply run gpg -card-edit when the card is connected, then type fetch at the command line to extract the public key that corresponds to the secret key on the card (that remains on the card). The same procedure as when using a private key on another computer.

Conclusion

There are informal guidelines for the optimal use of OpenPGP, and in some places, it is recommended that keys be stored offline, but they rarely explain what exactly is meant. Keeping the main secret key offline is very important given the possible risks of compromise, and here we looked at the main ways of such storage: on an isolated system, in a LUKS-encrypted keychain or using key cards. Each of these methods has its drawbacks, but we recommend mastering the work with cards if you use several computers and want to get a standard interface with minimal configuration problems.

• And of course, these approaches can be combined. For example, this guide uses a key card on an isolated computer, which elegantly solves the problem of how to transfer signatures from an isolated computer to the outside world. But this is definitely not the way for the faint-hearted.

If we decide to use a key card, the next step will be to select a specific model. We’ll talk about this in the next article, where we will study performance, mechanical design, and other factors.