On 09-02-21 12:48:38, Jan Wasilewski wrote:
Hi All,
I have a question about the possible decryption of LUKS volume. I'm testing currently barbican+cinder, but I'm just wondering if there is a way, to somehow decrypt my LUKS volume with payload generated by a barbican. Is there any procedure for that? I was doing it by myself, but somehow it doesn't work and I got an error:
[TEST]root@barbican-01:/usr/lib/python3/dist-packages# barbican secret get --payload --payload_content_type application/octet-stream http://controller.test:9311/v1/secrets/76631940-9ab6-4b8c-9481-e54c3ffdbbfe +---------+--------------------------------------------------------------------------------------------------------+ | Field | Value | +---------+--------------------------------------------------------------------------------------------------------+ | Payload | b'\xbf!i\x97\xf4\x0c\x12\xa4\xfe4\xf3\x16C\xe8@\xdc\x0f\x9d+:\x0c7\xa9\xab[\x8d\xf2\xf1\xae\r\x89\xdc' | +---------+--------------------------------------------------------------------------------------------------------+
cryptsetup luksOpen /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f my-volume Enter passphrase for /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f: *<passphrase from payload>* No key available with this passphrase.
I thought that above issue can be related to encoding, so I took payload value directly from vault and use it as a key-file, but problem is exactly the same(my encrypted volume is the last volume list by domblklist option):
vault kv get secret/data/e5baa518207e4f9db4810988d22087ce | grep value | awk -F'value:' '{print $2}' 4d4d35676c336567714850663477336d2b415475746b74774c56376b77324b4e73773879724c46704678513d]
[TEST]root@comp-02:~# cat bbb 4d4d35676c336567714850663477336d2b415475746b74774c56376b77324b4e73773879724c46704678513d [TEST]root@comp-02:~# cat bbb | base64 -d > pass2 [TEST]root@comp-02:~# cat pass2 ▒▒▒▒▒▒▒^<▒N▒▒▒▒~پ5▒▒▒▒▒▒▒z߾▒▒▒▒~▒▒▒▒▒n▒▒▒▒▒]▒[TEST]root@comp-02:~# [TEST]root@comp-02:~# virsh domblklist instance-00000da8 Target Source ------------------------------------------------ vda /dev/dm-17 vdb /dev/disk/by-id/wwn-0x6e00084100ee7e7e74623bd3000036bc vdc /dev/dm-16 vde /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f vdf /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 [TEST]root@comp-02:~# udisksctl unlock -b /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 --key-file pass2 Error unlocking /dev/dm-21: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/dm-21: Failed to activate device: Operation not permitted [TEST]root@comp-02:~# cryptsetup luksOpen /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 my-volume --master-key-file=pass2 Volume key does not match the volume.
I see that nova/cinder and barbican are doing this stuff somehow so I strongly believe there is a way to decrypt this manually. Maybe I’m doing something wrong in my testing-steps. Thanks in advance for any help here! Unfortunately, I haven’t found any materials on how to do this.
Yeah this is thanks to a long standing peice of technical debt that I've wanted to remove for years but I've never had to the change to. The tl;dr is that os-brick and n-cpu both turn the associated symmetric key secret into a passphrase using the following logic, ultimately calling binascii.hexlify: https://github.com/openstack/nova/blob/944443a7b053957f0b17a5edaa1d0ef14ae48... https://github.com/openstack/os-brick/blob/ec70b4092f649d933322820e300326956... I'm sure I've written up the steps to manually decrypt a cinder volume using these steps before but I can't seem to find them at the moment. I'll try to find some time to write these up again later in the week. Obviously it goes without saying that c-vol/c-api should be creating a passphrase secret for LUKS encrypted volumes to avoid this madness. Cinder creating and associating symmetric keys with encrypted volumes when used with Barbican https://bugs.launchpad.net/cinder/+bug/1693840 -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76