PGP offline key storage strategies
LWN Subscribers Article
Although the general public practically does not use OpenPGP , but it is a critical element of security, especially for Linux distributions. For example, the central Debian repository checks each package with the OpenPGP keys of the maintainer, and then signs it with its key. If packages that are included in a branch also have such signatures, then a complete chain of trust is created from the original developer to the users. In addition, pull requests to the Linux kernel are also verified with digital signatures. Therefore, the stakes are high: if a key for signing a release is compromised, or at least the key of a single maintainer, a destructive attack on many machines can result.
This has 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 2048 bits) and vulnerable PGPv3 keys were removed from keychains in 2015, and the common practice of signing keys in person is common among Debian developers. But even Debian developers seem to have no generally accepted rules for storing critical classified material, as seen in the debian-project mailing list. This discussion boils down to a single simple requirement: where do you get the “electronic key storage guide for dummies”? Electronic hardware keys or key cards, as we call them here, are small devices that allow you to store your keys offline and constitute one of the options for protecting the secret material, that is, the key. In this article I will try to share my experience in this area and clarify the problem of how to store these precious secret keys, which in case of compromise endanger millions of computers around the world.
Before we take a detailed look at storing passwords offline, it is helpful to briefly recall how the OpenPGP standard works. OpenPGP keys are created from a main pair of public and private keys, a certification key that signs user IDs, and a subkey. My public key, shown below, contains the usual certification / signature key (labeled SC), as well as an encryption subkey (labeled E), a separate signature key (S) and two authentication keys (labeled A), which I use as RSA keys for authorization on servers via SSH, thanks to the Monkeysphere project .
')
All sub (sub) and identifiers (uid) are linked by the main certification key using digital signatures with self-authentication. So although an attacker who has received a secret subkey can forge my signatures or authenticate to other servers, this subkey can always be revoked using the main certification key. But if the certification key is lost, everything is lost: an attacker can create or recall indenters or plug-ins as he wishes. In the most disastrous scenario, the attacker steals the key and erases your copies, gaining full control over the key without any possibility of recovery on your part. By the way, this is why it is so important to generate a certificate of revocation and keep it offline.
So, by moving the certification key offline, we reduce the possibility of an attack on the OpenPGP trust chain: everyday keys (for example, for encrypting mail or a digital signature) can remain online. If they are stolen, the certification key will revoke these keys without problems, and it will remain safe. Note that stealing an encryption key is another problem: even if we revoke an encryption subkey, it only affects future encrypted messages. With the help of a stolen subkey, an attacker can read previous encrypted messages even if the subkey is revoked, so the benefits of revoking encryption certificates are more limited.
Given the security tradeoffs, it is proposed to keep critical keys offline 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 that is disconnected from all communication channels.
Full disk encryption like LUKS adds an extra level of security, hiding the key from the attacker. Even though secret keychains are usually protected with a passphrase, it is easy to recognize that this is a keychain. But if the volume is completely encrypted, then it is not immediately obvious to the attacker that the device has keys. According to Shaun Whitton, another advantage of LUKS over regular keychain encryption in GnuPG is that when creating a LUKS partition, you can pass the
Lack of external volumes - excessive complexity. GnuPG complicates the process of extracting secrets from a bunch of keys, which makes the initial installation tricky and error-prone. In versions 2.x, the procedure is simplified thanks to the new storage system and the corresponding
Another option is to install a separate isolated system for certification operations. An example of this is the clean room PGP project, which is the current Debian-based system developed by Daniel Pocock to run the OpenPGP and X.509 certificate authority on conventional hardware. The basic principle is to keep secret keys on a separate machine that never connects to the network and therefore is not subject to attacks, at least in theory. Personally, I 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 we are talking only about extracting signatures, which exposes the system to attacks.
In the same way, OS updates are complicated: to keep the system safe, you need to install updates on a computer isolated from the network in a timely manner. 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 are a bunch of exotic ways to capture data using LEDs , infrared cameras, or the good old TEMPEST attack. Therefore, I came to the conclusion that the benefits of simplifying the procedures that an isolated system provides are not worth it. Moreover, isolated systems are actually not so easy to work with: even though the “clean room” of PGP has come a long way of development, it still doesn’t have simple scripts to share signatures or pass keys, so there’s the same problem as the approach with external encrypted volumes LUKS.
I chose an approach using cryptographic key-cards: this is an external device, which is usually connected via a USB connector, it stores the secret key and performs critical cryptographic operations on behalf of the host. For example, the FST-01 key card decrypts in asymmetric RSA and ECC encryption schemes without giving the host secret material. In essence, a key card is a miniature computer that performs a limited set of calculations for another host. Key cards typically support multiple “slots” for sub-key storage. The OpenPGP standard installs three default subkeys: for signing, authentication, and encryption. In the end, the key card can contain a real physical keypad for entering passwords, so the potential keylogger is powerless here, although I did not come across key cards with such keyboards.
It is easy to draw a parallel between key cards and an isolated system; in essence, a key card is an isolated system in 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 simpler, because the key card is in reality “online” (that is, clearly not isolated) after being connected. However, the advantage over a fully isolated computer 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 tested is much easier than with a general-purpose computer.
Like isolated systems, key cards prevent an attacker from gaining access to the private key. He can trick the key card into signing or decrypting some data, but this is possible only when the device is physically connected to the computer, and the key card asks the user for a password before performing the operation, although it may cache the password for a while. In essence, offline attacks become impossible: to brute-force a password to a key, an attacker must gain access to the victim's computer and try to find the password here, while the key card allows only a limited number of attempts. It also provides a clear and standard interface for storing keys offline: with a single GnuPG command, the secret key material is moved to the key card (the
Key cards are also more useful when working with multiple computers. A common problem with using GnuPG on multiple machines is how to safely copy and synchronize secret key material on multiple devices, which creates new security issues. After all, the “good tone rule in the crime lab,” according to Robert Hansen from the GnuPG mailing list, is “store as little personal data as possible on their systems.” The key card here is good on both sides: you can use your secret key on several computers, but you will not keep multiple copies of it. In fact, Mike Gervits more categorical:
As Gervits noted, there are still some negative points in using the key card. Another Debian developer Wouter Verhelst clearly formulated them:
By "smart cards" here are meant old OpenPGP cards with IEC 7816 connectors , which needed special card readers. New key cards simply use the usual USB interface. In any case, the external device introduces new problems: an attacker can steal your key card, you can just lose it or wash it with dirty laundry. Of course, you can also lose a laptop or a computer, but it is much easier to lose a small USB key card than a whole laptop — and I have not heard anyone wash the whole laptop in the washing machine. When you lose a key card, if there is no separate revocation certificate, then you completely lose control of the key, which will be a disaster. But even if you take back the lost key, you will need to create a new one, which means building a network of trust from scratch for this key is quite an expensive operation, because it usually involves a personal meeting with other OpenPGP users to exchange fingerprints.
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 backups of their OpenPGP keys ... right? In the case of a key card, several key cards distributed geographically can become backup copies.
Note that, unlike isolated systems, the key generated by the card cannot be backed up by definition. It is not a problem to connect, because they do not need backup copies (except encryption keys). But for a certification key, this means that the user must generate a key on the host and copy it to the card, that is, the host must provide sufficient entropy to generate cryptographically stable random numbers, for example. 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.
Key cards represent 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. Key cards are more difficult to update: the firmware may be intentionally closed for access from the host for security reasons or it may require special software to manipulate it. Key cards can perform certain operations more slowly than the CPU, because there are small built-in microcontrollers with limited computing power.
Finally, key cards can encourage users to trust their secrets to many machines, which is contrary to the principle of “minimal personal data”. The completely opposite approach is called Trusted Physical Console (TPC): here, instead of trying to deliver the secret key to all machines, you have the only machine that is used for all cryptographic operations. Unlike a key card, a TPC is a real computer, for example, a laptop, which does not require special procedures for managing keys. 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.
Write the keys on the card is quite simple:
After the key is transferred to the map, the command
There are informal guidelines for the optimal use of OpenPGP , and in some places they recommend storing keys offline, but they rarely explain what exactly is meant. Keeping the primary secret key offline is very important in view of the possible risks of compromise, and here we looked at the basic methods of such storage: on an isolated system, in a LUKS-encrypted keychain, or using key-cards. Each of these methods has its drawbacks, but I recommend mastering the work with maps 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 a way for the faint of heart.
If we decide to use a key card, the next step is to select a particular model. We will discuss this in the next article, where I will study performance, mechanical design, and other factors.
Although the general public practically does not use OpenPGP , but it is a critical element of security, especially for Linux distributions. For example, the central Debian repository checks each package with the OpenPGP keys of the maintainer, and then signs it with its key. If packages that are included in a branch also have such signatures, then a complete chain of trust is created from the original developer to the users. In addition, pull requests to the Linux kernel are also verified with digital signatures. Therefore, the stakes are high: if a key for signing a release is compromised, or at least the key of a single maintainer, a destructive attack on many machines can result.
This has 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 2048 bits) and vulnerable PGPv3 keys were removed from keychains in 2015, and the common practice of signing keys in person is common among Debian developers. But even Debian developers seem to have no generally accepted rules for storing critical classified material, as seen in the debian-project mailing list. This discussion boils down to a single simple requirement: where do you get the “electronic key storage guide for dummies”? Electronic hardware keys or key cards, as we call them here, are small devices that allow you to store your keys offline and constitute one of the options for protecting the secret material, that is, the key. In this article I will try to share my experience in this area and clarify the problem of how to store these precious secret keys, which in case of compromise endanger millions of computers around the world.
Why keep your keys offline?
Before we take a detailed look at storing passwords offline, it is helpful to briefly recall how the OpenPGP standard works. OpenPGP keys are created from a main pair of public and private keys, a certification key that signs user IDs, and a subkey. My public key, shown below, contains the usual certification / signature key (labeled SC), as well as an encryption subkey (labeled E), a separate signature key (S) and two authentication keys (labeled A), which I use as RSA keys for authorization on servers via SSH, thanks to the Monkeysphere project .
')
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 sub (sub) and identifiers (uid) are linked by the main certification key using digital signatures with self-authentication. So although an attacker who has received a secret subkey can forge my signatures or authenticate to other servers, this subkey can always be revoked using the main certification key. But if the certification key is lost, everything is lost: an attacker can create or recall indenters or plug-ins as he wishes. In the most disastrous scenario, the attacker steals the key and erases your copies, gaining full control over the key without any possibility of recovery on your part. By the way, this is why it is so important to generate a certificate of revocation and keep it offline.
So, by moving the certification key offline, we reduce the possibility of an attack on the OpenPGP trust chain: everyday keys (for example, for encrypting mail or a digital signature) can remain online. If they are stolen, the certification key will revoke these keys without problems, and it will remain safe. Note that stealing an encryption key is another problem: even if we revoke an encryption subkey, it only affects future encrypted messages. With the help of a stolen subkey, an attacker can read previous encrypted messages even if the subkey is revoked, so the benefits of revoking encryption certificates are more limited.
Basic strategies for offline key storage
Given the security tradeoffs, it is proposed to keep critical keys offline 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 that is disconnected from all communication channels.
Full disk encryption like LUKS adds an extra level of security, hiding the key from the attacker. Even though secret keychains are usually protected with a passphrase, it is easy to recognize that this is a keychain. But if the volume is completely encrypted, then it is not immediately obvious to the attacker that the device has keys. According to Shaun Whitton, another advantage of LUKS over regular keychain encryption in GnuPG is that when creating a LUKS partition, you can pass the
--iter-time argument to increase key derivation, which greatly complicates brute force. In fact, GnuPG 2.x does not have an option to configure the key generation algorithm, although a patch was recently introduced that allows you to configure the key generation delay during the compilation of gpg-agent . He is now responsible for all operations with the secret key.
Lack of external volumes - excessive complexity. GnuPG complicates the process of extracting secrets from a bunch of keys, which makes the initial installation tricky and error-prone. In versions 2.x, the procedure is simplified thanks to the new storage system and the corresponding
keygrip files, but it still requires secret knowledge of the internal structure of the GPG. It is 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 install a separate isolated system for certification operations. An example of this is the clean room PGP project, which is the current Debian-based system developed by Daniel Pocock to run the OpenPGP and X.509 certificate authority on conventional hardware. The basic principle is to keep secret keys on a separate machine that never connects to the network and therefore is not subject to attacks, at least in theory. Personally, I 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 we are talking only about extracting signatures, which exposes the system to attacks.
In the same way, OS updates are complicated: to keep the system safe, you need to install updates on a computer isolated from the network in a timely manner. 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 are a bunch of exotic ways to capture data using LEDs , infrared cameras, or the good old TEMPEST attack. Therefore, I came to the conclusion that the benefits of simplifying the procedures that an isolated system provides are not worth it. Moreover, isolated systems are actually not so easy to work with: even though the “clean room” of PGP has come a long way of development, it still doesn’t have simple scripts to share signatures or pass keys, so there’s the same problem as the approach with external encrypted volumes LUKS.
Key Card Benefits
I chose an approach using cryptographic key-cards: this is an external device, which is usually connected via a USB connector, it stores the secret key and performs critical cryptographic operations on behalf of the host. For example, the FST-01 key card decrypts in asymmetric RSA and ECC encryption schemes without giving the host secret material. In essence, a key card is a miniature computer that performs a limited set of calculations for another host. Key cards typically support multiple “slots” for sub-key storage. The OpenPGP standard installs three default subkeys: for signing, authentication, and encryption. In the end, the key card can contain a real physical keypad for entering passwords, so the potential keylogger is powerless here, although I did not come across key cards with such keyboards.
It is easy to draw a parallel between key cards and an isolated system; in essence, a key card is an isolated system in 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 simpler, because the key card is in reality “online” (that is, clearly not isolated) after being connected. However, the advantage over a fully isolated computer 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 tested is much easier than with a general-purpose computer.
Like isolated systems, key cards prevent an attacker from gaining access to the private key. He can trick the key card into signing or decrypting some data, but this is possible only when the device is physically connected to the computer, and the key card asks the user for a password before performing the operation, although it may cache the password for a while. In essence, offline attacks become impossible: to brute-force a password to a key, an attacker must gain access to the victim's computer and try to find the password here, while the key card allows only a limited number of attempts. It also provides a clear and standard interface for storing keys offline: with a single GnuPG command, the secret key material is moved to the key card (the
keytocard command in the --edit-key interface), while moving the material to an encrypted LUKS device or an isolated computer represents a more complicated procedure.
Key cards are also more useful when working with multiple computers. A common problem with using GnuPG on multiple machines is how to safely copy and synchronize secret key material on multiple devices, which creates new security issues. After all, the “good tone rule in the crime lab,” according to Robert Hansen from the GnuPG mailing list, is “store as little personal data as possible on their systems.” The key card here is good on both sides: you can use your secret key on several computers, but you will not keep multiple copies of it. In fact, Mike Gervits more categorical:
“For users who need a GPG key on multiple machines, I consider a smart card to be a necessary device. Otherwise, the user simply increases the risk of compromise. ”
Key Card Disadvantages
As Gervits noted, there are still some negative points in using the key card. Another Debian developer Wouter Verhelst clearly formulated them:
“Smart cards are useful. They ensure that the secret half of your key never gets on your hard drive or any other regular media, and therefore cannot be stolen (because there is only one copy).
Smart cards are also a pain in the ass. They ensure that the secret half of your key never gets on your hard drive or any other regular media, and instead lies in your wallet, so that every time you need access to it, you have to get a wallet that takes longer than just running GnuPG. If your laptop does not have a built-in card reader, you will have to get the card reader from a backpack or from somewhere else. ”
By "smart cards" here are meant old OpenPGP cards with IEC 7816 connectors , which needed special card readers. New key cards simply use the usual USB interface. In any case, the external device introduces new problems: an attacker can steal your key card, you can just lose it or wash it with dirty laundry. Of course, you can also lose a laptop or a computer, but it is much easier to lose a small USB key card than a whole laptop — and I have not heard anyone wash the whole laptop in the washing machine. When you lose a key card, if there is no separate revocation certificate, then you completely lose control of the key, which will be a disaster. But even if you take back the lost key, you will need to create a new one, which means building a network of trust from scratch for this key is quite an expensive operation, because it usually involves a personal meeting with other OpenPGP users to exchange fingerprints.
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 backups of their OpenPGP keys ... right? In the case of a key card, several key cards distributed geographically can become backup copies.
Note that, unlike isolated systems, the key generated by the card cannot be backed up by definition. It is not a problem to connect, because they do not need backup copies (except encryption keys). But for a certification key, this means that the user must generate a key on the host and copy it to the card, that is, the host must provide sufficient entropy to generate cryptographically stable random numbers, for example. 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.
Key cards represent 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. Key cards are more difficult to update: the firmware may be intentionally closed for access from the host for security reasons or it may require special software to manipulate it. Key cards can perform certain operations more slowly than the CPU, because there are small built-in microcontrollers with limited computing power.
Finally, key cards can encourage users to trust their secrets to many machines, which is contrary to the principle of “minimal personal data”. The completely opposite approach is called Trusted Physical Console (TPC): here, instead of trying to deliver the secret key to all machines, you have the only machine that is used for all cryptographic operations. Unlike a key card, a TPC is a real computer, for example, a laptop, which does not require special procedures for managing keys. 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.
Short practical tips on key cards
Write the keys on the card is quite simple:
- Start with a temporary key to verify the procedure:
export GNUPGHOME=$(mktemp -d)
gpg --generate-key - Edit the key using the user ID (UID):
gpg --edit-key UID - Use the
keycommand to select the first subkey, then copy it to the card (you can also use theaddcardkeycommand just to generate a new subkey directly on the card):
gpg> key 1
gpg> keytocard - If you want to move the subkey, use the
savecommand, which will delete the local copy of the private key, so that the only copy will be stored on the card. Otherwise, use thequitcommand to save the key in a bundle, but store the secret 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 of your secret key. - If you are happy with the result, repeat steps 1 through 4 with your regular keychain (reset
$GNUPGHOME)
After the key is transferred to the map, the command
--list-secret-keys will show it as sec> (or ssb> for subkeys) instead of the usual sec keyword. If the key is completely missing (for example, if you moved it to the LUKS container), then the # sign appears. If you need to use the key from the backup on the card, you simply run gpg --card-edit when the card is connected, then type the command fetch in the command line to extract the public key that corresponds to the private key on the card (it remains on the card). The same procedure as using a private key on another computer .
Conclusion
There are informal guidelines for the optimal use of OpenPGP , and in some places they recommend storing keys offline, but they rarely explain what exactly is meant. Keeping the primary secret key offline is very important in view of the possible risks of compromise, and here we looked at the basic methods of such storage: on an isolated system, in a LUKS-encrypted keychain, or using key-cards. Each of these methods has its drawbacks, but I recommend mastering the work with maps 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 a way for the faint of heart.
If we decide to use a key card, the next step is to select a particular model. We will discuss this in the next article, where I will study performance, mechanical design, and other factors.
Source: https://habr.com/ru/post/339612/
All Articles