<div dir="ltr">Thank you for a nice description of how everything is organized. It is much easier to understand the full workflow.<div><br></div><div>>> I'll try to find some time to write these up again later in the week.</div><div>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.</div><div><br></div><div>Anyway, I checked also related conversation at openstack-lists and I'm wondering about this part:</div><div><a href="http://lists.openstack.org/pipermail/openstack-dev/2017-May/117470.html">http://lists.openstack.org/pipermail/openstack-dev/2017-May/117470.html</a></div><div><br></div><div>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?)</div><div>Thanks in advance.</div><div><br></div><div>Best regards,</div><div>Jan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">wt., 9 lut 2021 o 23:12 Lee Yarwood <<a href="mailto:lyarwood@redhat.com">lyarwood@redhat.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 09-02-21 12:48:38, Jan Wasilewski wrote:<br>
> Hi All,<br>
> <br>
> I have a question about the possible decryption of LUKS volume. I'm testing<br>
> currently barbican+cinder, but I'm just wondering if there is a way, to<br>
> somehow decrypt my LUKS volume with payload generated by a barbican. Is<br>
> there any procedure for that? I was doing it by myself, but somehow it<br>
> doesn't work and I got an error:<br>
> <br>
> [TEST]root@barbican-01:/usr/lib/python3/dist-packages# barbican secret get<br>
> --payload --payload_content_type application/octet-stream<br>
> <a href="http://controller.test:9311/v1/secrets/76631940-9ab6-4b8c-9481-e54c3ffdbbfe" rel="noreferrer" target="_blank">http://controller.test:9311/v1/secrets/76631940-9ab6-4b8c-9481-e54c3ffdbbfe</a><br>
> +---------+--------------------------------------------------------------------------------------------------------+<br>
> | Field   | Value<br>
>                                         |<br>
> +---------+--------------------------------------------------------------------------------------------------------+<br>
> | 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'<br>
> |<br>
> +---------+--------------------------------------------------------------------------------------------------------+<br>
> <br>
> cryptsetup luksOpen /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f<br>
> my-volume<br>
> Enter passphrase for<br>
> /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f: *<passphrase from<br>
> payload>*<br>
> No key available with this passphrase.<br>
> <br>
> I thought that above issue can be related to encoding, so I took payload<br>
> value directly from vault and use it as a key-file, but problem is exactly<br>
> the same(my encrypted volume is the last volume list by domblklist option):<br>
> <br>
> vault kv get secret/data/e5baa518207e4f9db4810988d22087ce | grep value |<br>
> awk -F'value:' '{print $2}'<br>
> 4d4d35676c336567714850663477336d2b415475746b74774c56376b77324b4e73773879724c46704678513d]<br>
> <br>
> [TEST]root@comp-02:~# cat bbb<br>
> 4d4d35676c336567714850663477336d2b415475746b74774c56376b77324b4e73773879724c46704678513d<br>
> [TEST]root@comp-02:~# cat bbb | base64 -d > pass2<br>
> [TEST]root@comp-02:~# cat pass2<br>
> ▒▒߻▒▒▒▒▒^<▒N▒▒▒▒~پ5▒▒▒▒▒▒▒z߾▒▒▒▒~▒▒▒▒▒n▒▒▒▒▒]▒[TEST]root@comp-02:~#<br>
> [TEST]root@comp-02:~# virsh domblklist instance-00000da8<br>
> Target     Source<br>
> ------------------------------------------------<br>
> vda        /dev/dm-17<br>
> vdb        /dev/disk/by-id/wwn-0x6e00084100ee7e7e74623bd3000036bc<br>
> vdc        /dev/dm-16<br>
> vde        /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f<br>
> vdf        /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5<br>
> [TEST]root@comp-02:~# udisksctl unlock -b<br>
> /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 --key-file pass2<br>
> Error unlocking /dev/dm-21:<br>
> GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking<br>
> /dev/dm-21: Failed to activate device: Operation not permitted<br>
> [TEST]root@comp-02:~# cryptsetup luksOpen<br>
> /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 my-volume<br>
> --master-key-file=pass2<br>
> Volume key does not match the volume.<br>
> <br>
> <br>
> I see that nova/cinder and barbican are doing this stuff somehow so I<br>
> strongly believe there is a way to decrypt this manually. Maybe I’m doing<br>
> something wrong in my testing-steps.<br>
> Thanks in advance for any help here! Unfortunately, I haven’t found any<br>
> materials on how to do this.<br>
<br>
Yeah this is thanks to a long standing peice of technical debt that I've<br>
wanted to remove for years but I've never had to the change to.<br>
<br>
The tl;dr is that os-brick and n-cpu both turn the associated symmetric key<br>
secret into a passphrase using the following logic, ultimately calling<br>
binascii.hexlify:<br>
<br>
<a href="https://github.com/openstack/nova/blob/944443a7b053957f0b17a5edaa1d0ef14ae48f30/nova/virt/libvirt/driver.py#L1463-L1466" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/944443a7b053957f0b17a5edaa1d0ef14ae48f30/nova/virt/libvirt/driver.py#L1463-L1466</a><br>
<br>
<a href="https://github.com/openstack/os-brick/blob/ec70b4092f649d933322820e3003269560df7af9/os_brick/encryptors/cryptsetup.py#L101-L103" rel="noreferrer" target="_blank">https://github.com/openstack/os-brick/blob/ec70b4092f649d933322820e3003269560df7af9/os_brick/encryptors/cryptsetup.py#L101-L103</a><br>
<br>
I'm sure I've written up the steps to manually decrypt a cinder volume<br>
using these steps before but I can't seem to find them at the moment.<br>
I'll try to find some time to write these up again later in the week.<br>
<br>
Obviously it goes without saying that c-vol/c-api should be creating a<br>
passphrase secret for LUKS encrypted volumes to avoid this madness.<br>
<br>
Cinder creating and associating symmetric keys with encrypted volumes when used with Barbican<br>
<a href="https://bugs.launchpad.net/cinder/+bug/1693840" rel="noreferrer" target="_blank">https://bugs.launchpad.net/cinder/+bug/1693840</a><br>
<br>
-- <br>
Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76<br>
</blockquote></div>