From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 24B01C11F6B for ; Fri, 2 Jul 2021 10:53:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F163D61374 for ; Fri, 2 Jul 2021 10:53:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231574AbhGBK4S convert rfc822-to-8bit (ORCPT ); Fri, 2 Jul 2021 06:56:18 -0400 Received: from lithops.sigma-star.at ([195.201.40.130]:39292 "EHLO lithops.sigma-star.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231320AbhGBK4S (ORCPT ); Fri, 2 Jul 2021 06:56:18 -0400 Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id CF14D606BA30; Fri, 2 Jul 2021 12:53:43 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id hG49krIohN_g; Fri, 2 Jul 2021 12:53:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 52AA1606BA4F; Fri, 2 Jul 2021 12:53:43 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yiX2RLkjjlHe; Fri, 2 Jul 2021 12:53:43 +0200 (CEST) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lithops.sigma-star.at (Postfix) with ESMTP id 121A7606BA30; Fri, 2 Jul 2021 12:53:43 +0200 (CEST) Date: Fri, 2 Jul 2021 12:53:42 +0200 (CEST) From: Richard Weinberger To: Ahmad Fatoum Cc: Jonathan Corbet , David Howells , Jarkko Sakkinen , James Bottomley , Mimi Zohar , kernel , James Morris , "Serge E. Hallyn" , horia geanta , aymen sghaier , Herbert Xu , davem , Udit Agarwal , Eric Biggers , Jan Luebbe , david , Franck Lenormand , Sumit Garg , "open list, ASYMMETRIC KEYS" , Linux Crypto Mailing List , Linux Doc Mailing List , linux-integrity , linux-kernel , LSM Message-ID: <783613027.15909.1625223222889.JavaMail.zimbra@nod.at> In-Reply-To: <2f608e5a-5a12-6db1-b9bd-a2cd9e3e3671@pengutronix.de> References: <39e6d65ca5d2a0a35fb71d6c1f85add8ee489a19.1624364386.git-series.a.fatoum@pengutronix.de> <1850833581.13438.1625172175436.JavaMail.zimbra@nod.at> <2f608e5a-5a12-6db1-b9bd-a2cd9e3e3671@pengutronix.de> Subject: Re: [PATCH v2 6/6] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [195.201.40.130] X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF78 (Linux)/8.8.12_GA_3809) Thread-Topic: KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Thread-Index: YNq+u/AVc12Aad/zgRj+Xah98DqV1g== Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org Ahmad, ----- Ursprüngliche Mail ----- > Von: "Ahmad Fatoum" >> I'm still think that hard coding the key modifier is not wise. >> As I said[0], there are folks out there that want to provide their own modifier, >> so it is not only about being binary compatible with other CAAM blob patches in >> the wild. > > I don't think the characterization as a salt is accurate. AFAIU it's more > of a namespace, so blobs being loaded are "type-checked" against the modifier. Well, the CAAM programmer's reference manual states that the blob key is a 128 bit modifier and has two purposes: 1. It can be used as tag to provide separation between blobs to detect accidental replacement of blobs. 2. But it can also be treated as secret to provide additional protection. Because the blob encryption key derivation includes the key modifier. While you have case 1 in mind, I care about case 2. :-) >> I'll happily implement that feature after your patches got merged but IMHO we >> should first agree on an interface. >> How about allowing another optional parameter to Opt_new and Opt_load > > Sound good to me. pcrlock for TPM trusted keys has the same interface. > > I'd prefer the new option to accept strings, not hex though. Both is possible. If the string starts with "0x" it needs to be decoded to a 128 bit key. Otherwise it has to be a up to 16 byte string. Thanks, //richard