[dm-crypt] Re: Transactional updates for LUKS2 metadata?

[Ondrej Kozina <okozina@redhat.com>]

On 4/11/21 2:09 PM, Schneider, Robert wrote:
> Thank you very much for your response!
> 
> I am implementing a form of key rotation for a "backup" key (a secondary key). The backup key has associated data which I wanted to store in a token. This associated data is required to get the passphrase. To rotate this backup key, I have to adjust the keyslot json object, the token, and the keyslot binary data.
> 
> Currently, I am using two keyslots to implement a safe update. I'm relying on the atomicity of API calls such as crypt_keyslot_add_by_* to a certain degree. To maintain the pair of keyslots, I write a sequence number into the token object. The key is rotated as follows:
> 1. crypt_keyslot_add_* - add new keyslot
> 2. crypt_token_set - add metadata for new keyslot, with incremented sequence number
> 3. crypt_keyslot_wipe - remove old keyslot and tokens

I have a suggestion based on the atomic writes of LUKS2 metadata. (LUKS2 
metadata only because as you've correctly noticed keyslots binary area 
writes does not provide any such guaranties at the moment).

Also it's based on assumption your application understands the token 
content and therefore can do something like this:

1) Write token with following metadata (let's say in token id 6)
{
   "type" : "my_token",
   "keyslots" : [],

   "new_keyslot" : 21,  <-- does not exist yet
   "current_keyslot" : 5, <-- it's the old keyslot, stil valid
}

2) crypt_keyslot_add_* (with keyslot id 21)

3) wipe_keyslot 5

4) replace token 6 with new metadata (this will be atomic):
{
   "type" : "my_token",
   "keyslots" : [],

   "current_keyslot" : 21
}

If anytime in between 1) and 4) crash occurs you can double check:

Does 'new_keyslot' exist and is it ok (just check passphrase by unlock 
API function with name set to NULL). Yes? go on. No? we crashed during 
step 2)

Provided both "current_keyslot" and "new_keyslot" fields are in token 
metadata: Does keyslot referenced in "current_keyslot" still exist? Yes? 
we crashed during step 3) No? we crashed in before step 4) finished 
correctly.

If "current_keyslot" field is missing the transaction was successfully 
completed.

Internal LUKS2 format validation code only enforces content in fields 
"type" and "keyslots". The later can be left empty.

Did I understand your use case correctly?

Kind regards
O.

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de