From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=nBIX=JR=saout.de=dm-crypt-bounces@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-5.0 required=3.0 tests=BAYES_00,DKIM_INVALID,
	DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 880BBC433ED
	for <dm-crypt@archiver.kernel.org>; Tue, 20 Apr 2021 08:53:59 +0000 (UTC)
Received: from mail.server123.net (mail.server123.net [78.46.64.186])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.kernel.org (Postfix) with ESMTPS id F15C2611C9
	for <dm-crypt@archiver.kernel.org>; Tue, 20 Apr 2021 08:53:58 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F15C2611C9
Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com
Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dm-crypt-bounces@saout.de
X-Virus-Scanned: amavisd-new at saout.de
Authentication-Results: mail.server123.net (amavisd-new);
	dkim=pass (1024-bit key) header.d=redhat.com
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=216.205.24.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=okozina@redhat.com; receiver=<UNKNOWN> 
X-Greylist: delayed 417 seconds by postgrey-1.37 at siona; Tue, 20 Apr 2021 10:51:03 CEST
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.server123.net (Postfix) with ESMTPS
	for <dm-crypt@saout.de>; Tue, 20 Apr 2021 10:51:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1618908662;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=LUyF2nhOMibSCRcDXwOlZzZQf8LzOUBYoALWXEvYkaw=;
	b=URsXFZ4u53AjepUZV6ezUOOhyHssyYmkYx3AH4ro8kKqdJ9uVNSnurhE4ZBIEjq1Hr3cb6
	heR95dK5Spaz/6WJ/dOp6iaHWFQElZ7tPKfaIfHtjRH6sqJmF9SYQaodDTfFGh7fJZeHxI
	gEHtl/XG27UbMBWMB3/DxHyIRBcivvo=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-597-ONSE_ia6OGGxWHE6Ja826Q-1; Tue, 20 Apr 2021 04:44:00 -0400
X-MC-Unique: ONSE_ia6OGGxWHE6Ja826Q-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 47FD319357A1;
	Tue, 20 Apr 2021 08:43:59 +0000 (UTC)
Received: from mrjust.localdomain (unknown [10.40.193.214])
	by smtp.corp.redhat.com (Postfix) with ESMTP id 3CF7139A5F;
	Tue, 20 Apr 2021 08:43:58 +0000 (UTC)
To: "dm-crypt@saout.de" <dm-crypt@saout.de>
References: <AM0PR02MB5585DDB379587BDCADB87F628F739@AM0PR02MB5585.eurprd02.prod.outlook.com>
 <96066d25-7e45-17a9-6799-e6dd39b3bffb@gmail.com>
 <AM0PR02MB55853E23D3570BAA4E21FB358F719@AM0PR02MB5585.eurprd02.prod.outlook.com>
From: Ondrej Kozina <okozina@redhat.com>
Message-ID: <8b72fbe2-1197-149e-b59d-7f10e2b6b8e3@redhat.com>
Date: Tue, 20 Apr 2021 10:43:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <AM0PR02MB55853E23D3570BAA4E21FB358F719@AM0PR02MB5585.eurprd02.prod.outlook.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
Authentication-Results: relay.mimecast.com;
	auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=okozina@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Message-ID-Hash: SAC5OMUODQ7GVRXWH5RDVP3JZWGJB77B
X-Message-ID-Hash: SAC5OMUODQ7GVRXWH5RDVP3JZWGJB77B
X-MailFrom: okozina@redhat.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dm-crypt.saout.de-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header
CC: "Schneider, Robert" <robert.schneider03@sap.com>, Milan Broz <gmazyland@gmail.com>
X-Mailman-Version: 3.3.2
Precedence: list
Subject: [dm-crypt] Re: Transactional updates for LUKS2 metadata?
List-Id: <dm-crypt.saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Post: <mailto:dm-crypt@saout.de>
List-Subscribe: <mailto:dm-crypt-join@saout.de>
List-Unsubscribe: <mailto:dm-crypt-leave@saout.de>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit

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