Fail to extract volume key for capi:authenc(hmac(sha256),xts(aes))-plain64

[pPanda-beta]

The volume key of luks2 with integrity is slightly different from regular luks2 volume key.

It is normally 96bytes. The first 64 bytes are the two parts of aes-xts key. The next 32bytes are the integrity key which is used for validation.

There are primarily two problems I've identified:

1. Reading the anti-forensic key
   Here this code is reading equivalent size of keyslot.KeySize but it should read the anti forensic area size (keyslot.Area.KeySize) only.
   

   luks.go/luks2.go

   Line 219 in d8c59ab

   afKey, err := deriveLuks2AfKey(keyslot.Kdf, keyslotIdx, passphrase, keyslot.KeySize)

   
   When using aes-xts-plain64 without integrity, both the values are 64bytes.

2. Separation of aes-xts key and integrity key. As I've mentioned above, the 96 bytes need to be split into 64bytes and 32bytes. This should be done near

   luks.go/luks2.go

   Line 225 in d8c59ab

   finalKey, err := d.decryptLuks2VolumeKey(keyslotIdx, keyslot, afKey)

Command to prepare the test data:

dd if=/dev/random of=/tmp/partitionKey.txt  bs=1 count=32
cryptsetup luksFormat -q --type luks2 /tmp/exp1/test_disk.img --cipher aes-xts-plain64 --key-file /tmp/partitionKey.txt \
    --integrity hmac-sha256 --integrity-no-wipe --sector-size 4096

# Extract volume key and verify with our code's output
cryptsetup luksDump /tmp/exp1/test_disk.img -q -v  --key-file /tmp/partitionKey.txt --dump-volume-key --volume-key-file /tmp/exp1/vk.key

[anatol]

Adding support for keys with integrity sounds reasonable. There are a few places in luks.go that assume keyslot.KeySize and keyslot.Area.KeySize are the same. And this needs to be fixed.

Would you be able to provide a patch for the changes you mentioned? And I can add an integration test for this change.

[pPanda-beta]

I've identified only two places which are harmful.

luks.go/luks2.go

Line 219 in d8c59ab

afKey, err := deriveLuks2AfKey(keyslot.Kdf, keyslotIdx, passphrase, keyslot.KeySize)

and

luks.go/luks2.go

Line 379 in d8c59ab

return afMerge(keyData, int(keyslot.KeySize), int(af.Stripes), h())

For the patch I tried modifying these, but it was giving checksum error. The 2nd part is also crucial. I tried taking only first 64bytes of the volume key. It didnt work. Tried looking over internet to see if any algorithm or pseudocode is present for this. Unfortunately I couldn’t find any good resource.
This doc is too much theoretical and actual algorithm / steps are not clear from it.

I'm planning to go through the latest cryptsetup luksOpen codebase. (Too challenging, since its a c code with low readability)

If you know any good documentation please let me know.

[anatol]

There is no good documentation about the implementation algorithm, unfortunately.

I've been using luks2_keyslot_get_key() code from cryptsetup project to understand the logic.

I think I was able to figure out what was wrong with the function. Please try luks.go from master branch and let me know if you still see the problem.

[pPanda-beta]

@anatol
Thanks for that PR. I think this part is solved for now. But I'm still struggling to read encrypted data at certain offset. I believe the problem lies in the devmapper.go codebase and not here.
To discuss that I have opened anatol/devmapper.go#1

Anyway, it would be nice if we can somehow pass on the information to the CryptTable struct that this key contains both cipher key and integrity key.

Somewhere near here:

luks.go/volume.go

Line 57 in ada2562

Key: v.key,