On 10-02-21 11:29:06, Jan Wasilewski wrote:
Thank you for a nice description of how everything is organized. It is much easier to understand the full workflow.
I'll try to find some time to write these up again later in the week. That would be great, I will try to do this by myself, but I'm wondering if it's possible to do "all magic" directly from a payload that is visible from barbican CLI.
Anyway, I checked also related conversation at openstack-lists and I'm wondering about this part: http://lists.openstack.org/pipermail/openstack-dev/2017-May/117470.html
Is there a way to replace the compromised LUKS passphrase with the current implementation of barbican? I was trying to do this by myself but without luck. I'm also wondering if there is a procedure that can help here(if you know?)
AFAIK the only way to do this at present is by retyping [1] the volume to a different encrypted volume type. That should result in a new volume using new secrets etc that for LUKSv1 volumes would mean a new passphrase. [1] https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=rety...
wt., 9 lut 2021 o 23:12 Lee Yarwood <lyarwood@redhat.com> napisał(a):
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
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
/dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f 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
-- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76