In my previous blog post, Managing File System Encryption with LUKS, I showed how to create an encrypted partition (of disk) using LUKS.
Today, I’d like to show you how we can change the passphrase on this LUKS encrypted partition and keeping this passphrase (key) in the same slot.
While I’m writing this blog post, I cannot remember how to do this, and I’m going to try to figure this out without doing the Google search. :)
First, let’s verify the encrypted disk and make sure that our existing passphrase is working.
[root@servera ~]# blkid | grep -i luks
/dev/vdb1: UUID="a3149833-3c52-4d06-8bdc-9a73fcdd4968" TYPE="crypto_LUKS"
We can use cryptsetup luksDump command to display the encryption information for the encryped device or partition.
[root@servera ~]# cryptsetup luksDump /dev/vdb1
LUKS header information for /dev/vdb1
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 256
MK digest: 9a e5 3b a4 b0 fa f9 62 df c0 71 db 39 60 47 9a d3 c1 7c 31
MK salt: 92 7b b7 d2 d8 c0 f1 4e 3d f5 18 72 9b 2a 44 46
c5 97 fe d7 a7 15 a5 73 8d b1 82 58 3b ab 16 cb
MK iterations: 47421
UUID: a3149833-3c52-4d06-8bdc-9a73fcdd4968
Key Slot 0: ENABLED
Iterations: 767624
Salt: a1 a5 f7 d5 e8 a5 f1 71 a5 0a 12 2e a3 0a 39 43
d0 fd a1 99 d7 e5 d8 df 99 9a 0e 5a e7 56 e6 f7
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
From the above output, we can see that the passphrase is saved in Key Slot 0.
Now, let’s verify that our existing passphrase (key?) does work.
[root@servera ~]# cryptsetup luksOpen /dev/vdb1 encryptedvdb1
Enter passphrase for /dev/vdb1:
[root@servera ~]# blkid
...omitted...
/dev/vdb1: UUID="a3149833-3c52-4d06-8bdc-9a73fcdd4968" TYPE="crypto_LUKS"
/dev/mapper/encryptedvdb1: UUID="708c21ad-b730-4886-9342-6d551effef49" TYPE="xfs"
[root@servera ~]# cryptsetup luksClose encryptedvdb1
Since we’re able to open the encrypted device, it means the current passphrase works.
Now, how do we update this current passphrase to “new-passphrase”? Well, let’s check the manual page for cryptsetup command, and search for “passphrase” (by entering /passphrase + Enter, and n).
[root@servera ~]# man cryptsetup
I found 2 sections in the manpage which looks interesting:
luksAddKey <device> [<key file with new key>]
Adds a new passphrase. An existing passphrase must be supplied interactively or via --key-file. The new passphrase to be added can be
specified interactively or read from the file given as positional argument.
NOTE: with --unbound option the action creates new unbound LUKS2 keyslot. The keyslot cannot be used for device activation. If you don't
pass new key via --master-key-file option, new random key is generated. Existing passphrase for any active keyslot is not required.
<options> can be [--key-file, --keyfile-offset, --keyfile-size, --new-keyfile-offset, --new-keyfile-size, --key-slot, --master-key-file,
--iter-time, --force-password, --header, --disable-locks, --unbound, --type].
and
luksChangeKey <device> [<new key file>]
Changes an existing passphrase. The passphrase to be changed must be supplied interactively or via --key-file. The new passphrase can be
supplied interactively or in a file given as positional argument.
If a key-slot is specified (via --key-slot), the passphrase for that key-slot must be given and the new passphrase will overwrite the
specified key-slot. If no key-slot is specified and there is still a free key-slot, then the new passphrase will be put into a free key-
slot before the key-slot containing the old passphrase is purged. If there is no free key-slot, then the key-slot with the old passphrase
is overwritten directly.
WARNING: If a key-slot is overwritten, a media failure during this operation can cause the overwrite to fail after the old passphrase has
been wiped and make the LUKS container inaccessible.
<options> can be [--key-file, --keyfile-offset, --keyfile-size, --new-keyfile-offset, --new-keyfile-size, --key-slot, --force-password,
--header, --disable-locks, --type].
Since we’re going to change an existing passphrase, the luksChangeKey looks more suitable. Well, let’s find out. (Update: Warning… this command is not correct!)
[root@servera ~]# cryptsetup luksChangeKey /dev/vdb1
Enter passphrase to be changed:
Enter new passphrase:
Verify passphrase:
[root@servera ~]#
Let’s verify if the passphrase is changed as intended:
[root@servera ~]# cryptsetup luksDump /dev/vdb1
LUKS header information for /dev/vdb1
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 256
MK digest: 9a e5 3b a4 b0 fa f9 62 df c0 71 db 39 60 47 9a d3 c1 7c 31
MK salt: 92 7b b7 d2 d8 c0 f1 4e 3d f5 18 72 9b 2a 44 46
c5 97 fe d7 a7 15 a5 73 8d b1 82 58 3b ab 16 cb
MK iterations: 47421
UUID: a3149833-3c52-4d06-8bdc-9a73fcdd4968
Key Slot 0: DISABLED
Key Slot 1: ENABLED
Iterations: 758738
Salt: d6 0b 4d da 28 f3 03 5b 69 94 8e 24 d7 51 ff aa
2f d4 87 a8 c3 67 72 ed b5 ca c4 52 79 af 7f f0
Key material offset: 264
AF stripes: 4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Though the passphrase has been updated correctly, the key has moved to Slot 1. :( This is not what I wanted.
With some magics (by adding luksAddKey /dev/vdb1 --key-slot 0 and removing luksRemoveKey /dev/vdb1 --key-slot 1), we’re back to the original condition.
[root@servera ~]# cryptsetup luksDump /dev/vdb1
LUKS header information for /dev/vdb1
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 256
MK digest: 9a e5 3b a4 b0 fa f9 62 df c0 71 db 39 60 47 9a d3 c1 7c 31
MK salt: 92 7b b7 d2 d8 c0 f1 4e 3d f5 18 72 9b 2a 44 46
c5 97 fe d7 a7 15 a5 73 8d b1 82 58 3b ab 16 cb
MK iterations: 47421
UUID: a3149833-3c52-4d06-8bdc-9a73fcdd4968
Key Slot 0: ENABLED
Iterations: 772146
Salt: 9b 44 9f 2f ba 61 c6 33 9e dd 44 59 8c dc b1 4d
1f 5a f3 d7 30 37 cd 7f 28 71 a1 8f 3e 09 f5 b3
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
After re-reading the section of the man-page about luksChangekey, we need to pass --key-slot to the command.
[root@servera ~]# cryptsetup luksChangeKey /dev/vdb1 --key-slot 0
Enter passphrase to be changed:
Enter new passphrase:
Verify passphrase:
[root@servera ~]# cryptsetup luksDump /dev/vdb1
LUKS header information for /dev/vdb1
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 256
MK digest: 9a e5 3b a4 b0 fa f9 62 df c0 71 db 39 60 47 9a d3 c1 7c 31
MK salt: 92 7b b7 d2 d8 c0 f1 4e 3d f5 18 72 9b 2a 44 46
c5 97 fe d7 a7 15 a5 73 8d b1 82 58 3b ab 16 cb
MK iterations: 47421
UUID: a3149833-3c52-4d06-8bdc-9a73fcdd4968
Key Slot 0: ENABLED
Iterations: 764268
Salt: b8 97 2c 33 ac 56 06 cf a2 a9 ed c2 96 85 38 96
f0 b0 df 3c cb 5e 5b 69 93 ac c8 92 26 26 e7 cc
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
We can also confirm that the new passphrase still works by opening this encrypted device.
[root@servera ~]# cryptsetup luksOpen /dev/vdb1 encryptedvdb1
Enter passphrase for /dev/vdb1:
To recap, to change an existing passphrase and have it saved on the same slot, run cryptsetup luksChangeKey [DEVICE] --key-slot [SLOT_NUMBER]. And if the command is too hard to remember, just remember one thing: man cryptsetup.
Reference:
man 8 cryptsetup