Luks: diferència entre les revisions

De WikiMar
Salta a la navegació Salta a la cerca
Cap resum de modificació
Cap resum de modificació
Línia 17: Línia 17:
==List devices==
==List devices==
lsblk --fs
lsblk --fs
==Backup the LUKS header==
Backup and Restore a LUKS Header
From the cryptsetup man page:
“LUKS header: If the header of a LUKS volume gets damaged, all data is permanently lost unless you have a header-backup. If a key-slot is damaged, it can only be restored from a header-backup or if another active key-slot with k                                                nown passphrase is undamaged. Damaging the LUKS header is something people manage to do with surprising frequency. This risk is the result of a trade-off between security and safety, as LUKS is designed for fast and secure wipin                                                g by just overwriting header and key-slot area.”
Referencing LUKS FAQ, there are two critical components for decryption: the salt values in the header itself and the key-slots. If the salt values are overwritten or changed, nothing (in the cryptographically strong sense) can b                                                e done to access the data, unless there is a backup of the LUKS header. If a key-slot is damaged, the data can still be read with a different key-slot, if there is a remaining undamaged and used key-slot.
Making the long story short, if our LUKS header gets damaged, all data is gone. To prevent this from happening, we need to create a header backup. This can be done by issuing the following command:
# cryptsetup luksHeaderBackup <device> --header-backup-file <file>
Where <device> is a LUKS volume disk and <file> is a name of a header backup file to be created. In our case:
# cryptsetup luksHeaderBackup /dev/sdb2 --header-backup-file /root/sdb2-header-backup
Important note: a LUKS header backup can grant access to most or all data, therefore we need to make sure that nobody has access to it or at least reduce the possibility for that to happen. Storing a LUKS header backup file on a                                                n encrypted cloud storage (such as Spideroak) wouldn’t be a bad idea.
In case of disaster where our LUKS header gets broken, we can restore it by issuing the following command:
# cryptsetup luksHeaderRestore <device> --header-backup-file <file>
WARNING: LUKS header restoration procedure will replace all key-slots, therefore only the passphrases from the backup will work afterwards!

Revisió del 20:35, 29 oct 2017

Use a key-file instead of passphrase

cryptsetup luksDump /dev/sdb1
dd if=/dev/random of=/etc/keys/clauluks bs=1 count=32
sudo cryptsetup luksAddKey /dev/sdb1 /etc/keys/clauluks
sudo cryptsetup --key-file /etc/keys/clauluks luksOpen /dev/sdb1 X1000LUKS
sudo mount /dev/mapper/X1000LUKS /media/X1000LUKS

You can use the UUID: /dev/disk/by-uuid/e9d308a7-3a0e-4c92-ac79-601384754081 instead of /dev/sdb1


More info: http://www.finnie.org/2009/07/26/keyfile-based-luks-encryption-in-debian/


List devices

lsblk --fs


Backup the LUKS header

Backup and Restore a LUKS Header

From the cryptsetup man page:

“LUKS header: If the header of a LUKS volume gets damaged, all data is permanently lost unless you have a header-backup. If a key-slot is damaged, it can only be restored from a header-backup or if another active key-slot with k nown passphrase is undamaged. Damaging the LUKS header is something people manage to do with surprising frequency. This risk is the result of a trade-off between security and safety, as LUKS is designed for fast and secure wipin g by just overwriting header and key-slot area.”

Referencing LUKS FAQ, there are two critical components for decryption: the salt values in the header itself and the key-slots. If the salt values are overwritten or changed, nothing (in the cryptographically strong sense) can b e done to access the data, unless there is a backup of the LUKS header. If a key-slot is damaged, the data can still be read with a different key-slot, if there is a remaining undamaged and used key-slot.

Making the long story short, if our LUKS header gets damaged, all data is gone. To prevent this from happening, we need to create a header backup. This can be done by issuing the following command:

# cryptsetup luksHeaderBackup <device> --header-backup-file <file>

Where <device> is a LUKS volume disk and <file> is a name of a header backup file to be created. In our case:

# cryptsetup luksHeaderBackup /dev/sdb2 --header-backup-file /root/sdb2-header-backup

Important note: a LUKS header backup can grant access to most or all data, therefore we need to make sure that nobody has access to it or at least reduce the possibility for that to happen. Storing a LUKS header backup file on a n encrypted cloud storage (such as Spideroak) wouldn’t be a bad idea.

In case of disaster where our LUKS header gets broken, we can restore it by issuing the following command:

# cryptsetup luksHeaderRestore <device> --header-backup-file <file>

WARNING: LUKS header restoration procedure will replace all key-slots, therefore only the passphrases from the backup will work afterwards!