Loading howto/yubikey.md +30 −26 Original line number Diff line number Diff line Loading @@ -262,6 +262,36 @@ This guide assumes the following: * the YubiKey has been obtained from trusted channels and verified (see [Unpacking and authenticating a YubiKey](#unpacking-and-authenticating-a-yubikey) ### Special considerations for storing encryption keys Here we are storing a full OpenPGP secret keyring on the YubiKey. This implies that encryption keys end up stored on the device. Therefore, special care need to be taken as the loss of a YubiKey could be catastrophic: in such a case, while the encryption key can be revoked, that doesn't allow the operator to recover past material encrypted with the key. This can lead to severe data loss. Encryption keys, therefore, must *not* be generated on the YubiKey as they *MUST* be backed up. They therefore *MUST* be generated on another device. The general strategy here is to have three copies of the encryption key: 1. `main key`: a first YubiKey used for daily operation 2. `backup key`: a *second* YubiKey available as a backup 3. `backup disk`: a copy of the encryption key material stored on a normal disk, encrypted with itself The rationale here is that if the `main key` is lost, the `backup key` and `backup disk` can be *combined* to create a *new* `main key`. If the `backup disk` did not exist, it would be impossible to recreate a new `main key` and, when the `backup key` is eventually lost or destroyed, the encrypted contents will not be readable anymore. This is the strategy taken in this guide. ### Install software and preparation You will need to install [GnuPG](https://gnupg.org/), its `scdaemon` component and a Loading Loading @@ -812,32 +842,6 @@ In older, you can also use: TODO: using the YubiKey on a new computer ### Special considerations for storing encryption keys For *encryption* keys, however, special care need to be taken as the loss of a YubiKey could be catastrophic: in such a case, while the key can be revoked, that doesn't allow the operator to recover past material encrypted with the key. Encryption keys, therefore, must *not* be generated on the YubiKey as they *MUST* be backed up. They therefore *MUST* be generated on another device. The general strategy here is to have three copies of the encryption key: 1. `main key`: a first YubiKey used for daily operation 2. `backup key`: a *second* YubiKey available as a backup 3. `backup disk`: a copy of the encryption key material stored on a normal disk, encrypted with itself The rationale here is that if the `main key` is lost, the `backup key` and `backup disk` can be *combined* to create a *new* `main key`. If the `backup disk` did not exist, it would be impossible to recreate a new `main key` and, when the `backup key` is eventually lost or destroyed, the encrypted contents will not be readable anymore. TODO: talk about nylon vs steel ### preliminary performance evaluation Loading Loading
howto/yubikey.md +30 −26 Original line number Diff line number Diff line Loading @@ -262,6 +262,36 @@ This guide assumes the following: * the YubiKey has been obtained from trusted channels and verified (see [Unpacking and authenticating a YubiKey](#unpacking-and-authenticating-a-yubikey) ### Special considerations for storing encryption keys Here we are storing a full OpenPGP secret keyring on the YubiKey. This implies that encryption keys end up stored on the device. Therefore, special care need to be taken as the loss of a YubiKey could be catastrophic: in such a case, while the encryption key can be revoked, that doesn't allow the operator to recover past material encrypted with the key. This can lead to severe data loss. Encryption keys, therefore, must *not* be generated on the YubiKey as they *MUST* be backed up. They therefore *MUST* be generated on another device. The general strategy here is to have three copies of the encryption key: 1. `main key`: a first YubiKey used for daily operation 2. `backup key`: a *second* YubiKey available as a backup 3. `backup disk`: a copy of the encryption key material stored on a normal disk, encrypted with itself The rationale here is that if the `main key` is lost, the `backup key` and `backup disk` can be *combined* to create a *new* `main key`. If the `backup disk` did not exist, it would be impossible to recreate a new `main key` and, when the `backup key` is eventually lost or destroyed, the encrypted contents will not be readable anymore. This is the strategy taken in this guide. ### Install software and preparation You will need to install [GnuPG](https://gnupg.org/), its `scdaemon` component and a Loading Loading @@ -812,32 +842,6 @@ In older, you can also use: TODO: using the YubiKey on a new computer ### Special considerations for storing encryption keys For *encryption* keys, however, special care need to be taken as the loss of a YubiKey could be catastrophic: in such a case, while the key can be revoked, that doesn't allow the operator to recover past material encrypted with the key. Encryption keys, therefore, must *not* be generated on the YubiKey as they *MUST* be backed up. They therefore *MUST* be generated on another device. The general strategy here is to have three copies of the encryption key: 1. `main key`: a first YubiKey used for daily operation 2. `backup key`: a *second* YubiKey available as a backup 3. `backup disk`: a copy of the encryption key material stored on a normal disk, encrypted with itself The rationale here is that if the `main key` is lost, the `backup key` and `backup disk` can be *combined* to create a *new* `main key`. If the `backup disk` did not exist, it would be impossible to recreate a new `main key` and, when the `backup key` is eventually lost or destroyed, the encrypted contents will not be readable anymore. TODO: talk about nylon vs steel ### preliminary performance evaluation Loading