Closed dnoliver closed 4 years ago
@dnoliver: I submitted #140 to fix this. I'd appreciate if you could test it.
root@fedora-server-1 clevis]# cryptsetup luksFormat /dev/sda
WARNING: Device /dev/sda already contains a 'crypto_LUKS' superblock signature.
WARNING!
========
This will overwrite data on /dev/sda irrevocably.
Are you sure? (Type uppercase yes): YES
Enter passphrase for /dev/sda:
Verify passphrase:
[root@fedora-server-1 clevis]# clevis luks bind -d /dev/sda tpm2 '{"pcr_bank":"sha1","pcr_ids":["16"]}'
Enter existing LUKS password:
[root@fedora-server-1 clevis]# echo $?
0
[root@fedora-server-1 clevis]# cryptsetup luksDump /dev/sda
LUKS header information
Version: 2
Epoch: 5
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: 7c873cf4-240c-411d-8096-db7928eb10c3
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)
Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 512 [bytes]
Keyslots:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2i
Time cost: 7
Memory: 1048576
Threads: 4
Salt: eb c4 e3 65 25 45 f4 e1 77 b5 bc bc 63 62 ac 90
83 e8 bd 97 76 aa 92 80 45 42 a9 49 50 e7 f4 37
AF stripes: 4000
AF hash: sha256
Area offset:32768 [bytes]
Area length:258048 [bytes]
Digest ID: 0
1: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2i
Time cost: 7
Memory: 1048576
Threads: 4
Salt: 5f 4f 42 74 90 ae 99 60 54 1d 34 7c db 9b 1a a7
b0 61 e4 1c 29 6c cd 9f 73 42 20 f3 05 a3 b7 76
AF stripes: 4000
AF hash: sha256
Area offset:290816 [bytes]
Area length:258048 [bytes]
Digest ID: 0
Tokens:
0: clevis
Keyslot: 1
Digests:
0: pbkdf2
Hash: sha256
Iterations: 121588
Salt: f8 eb bd 4e 12 5c f7 f3 1c 26 3f 3d c6 bf ca 8b
e7 ad 31 97 a2 a8 99 fc 23 bf 72 8f 4f a9 5b 1e
Digest: 33 4a 8d b4 15 aa be 52 62 e2 61 83 19 8c aa a6
f3 91 06 3e 0e 67 42 f1 e2 51 6c 85 d8 d8 36 d0
[root@fedora-server-1 clevis]# clevis luks unlock -d /dev/sda
[root@fedora-server-1 clevis]# ls /dev/mapper/
control fedora_fedora--server--1-root fedora_fedora--server--1-swap luks-7c873cf4-240c-411d-8096-db7928eb10c3
[root@fedora-server-1 clevis]# cryptsetup luksClose luks-7c873cf4-240c-411d-8096-db7928eb10c3
[root@fedora-server-1 clevis]# tpm2_pcrextend 16:sha1=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15
[root@fedora-server-1 clevis]# clevis luks unlock -d /dev/sda
WARNING:esys:src/tss2-esys/api/Esys_Unseal.c:291:Esys_Unseal_Finish() Received TPM Error
ERROR:esys:src/tss2-esys/api/Esys_Unseal.c:98:Esys_Unseal() Esys Finish ErrorCode (0x0000099d)
ERROR: Esys_Unseal(0x99D) - tpm:session(1):a policy check failed
ERROR: Unable to run tpm2_unseal
Unsealing jwk from TPM failed!
Works great!
I think there should be some more validation of the json passed in. I managed to pass in a malformed json and was confused why the pcr registers weren't being checked. Somehow I managed to repeat this several times and not notice the additional closing bracket.
Example:
{"pcr_bank":"sha256"},"pcr_ids":"7"}
Hello @alexyao2015 : May I ask you to open an issue regarding this to track it appropriately?
Related Issue https://github.com/latchset/clevis/issues/102
As explained on this comment https://github.com/latchset/clevis/issues/102#issuecomment-499008845, using incorrect settings generates parsing errors in Jose.
Those parsing errors are now ignored, and the encryption process continues without warning the user about the invalid configuration. This can generate unexpected behavior from a user point of view, where the encryption process will be successful, but will not be configured with the intention of the settings.
i.e.
This setting defines a PCR policy on PCR 16. On background, it will generate a parsing error at Jose level, that will be ignored (explained in https://github.com/latchset/jose/issues/68). The result is that the LUKS container get a key slot tied to the TPM without any PCR policy attached, and no errors are reported to the user.