... | ... | @@ -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
|
... | ... | @@ -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
|
... | ... | |