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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 5396BC433E0 for ; Wed, 3 Feb 2021 11:51:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 08B6464E29 for ; Wed, 3 Feb 2021 11:51:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234125AbhBCLvc (ORCPT ); Wed, 3 Feb 2021 06:51:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234116AbhBCLva (ORCPT ); Wed, 3 Feb 2021 06:51:30 -0500 Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83703C061573 for ; Wed, 3 Feb 2021 03:50:49 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id i187so32856318lfd.4 for ; Wed, 03 Feb 2021 03:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cOD/DHQlOSZ7fugmG47GUh/NK1JYxHNBoQ9+0qs9dMQ=; b=v9jPIxlvxSCQ/bTLzDIx/1JIXSpRw2NXw1XiUkWX7APLSFRqxIQClpxUtc9z1MMUCw ZPdKx1FlIAcSI0NAJLnFrdJNH1xtuZEpF87S0+r/9SupVdk+D7//GDtlhwarTOweA8GY qrcHfVgEhRR3oYBOXwWiv9ABFKzhqOuJAmH1FGs+nO7M4H4nGp3Un4dls3Si5EMtxn/i osB1UvQNexSBq94z3rDkm+U/FKxgBue55d6tY2OK04Ho2HigAG7w4dWebxfkGqLGkOQL okUWHIC+BG5AvkqvylxTWJsrBGUwpb4i6VxsMDgAdxSZBnwGPHIkjcFMQpvlyakitdp1 Bj/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cOD/DHQlOSZ7fugmG47GUh/NK1JYxHNBoQ9+0qs9dMQ=; b=EL1swdSh+erBIh2WHOufYm9qMfBj8a1rv41DPztk0iwQ0MdfS+4FARlipKUDZtwTFM Dxtr/iwahtu1VBkViE2XfUiMVyUlZNMiwW7L4dZMpeLLoPBOjQsXZdgDYaHQ/GizWSUc TYcfEyFwEA3UogmL2dIIyx3UaeCowIblnh1QOHJ+RLwYuUVBD4i8wA3PX8RNzgqcALTO o/attdZ4CUErF8/H2f2gYeEqAzQV49dCuoVzEILwh2UY4o1FdVuBbCewY0k4h0fKFoZw VVgtXY7UluaPXgLIp7cvBfK0y8aH1Ju5SkS7ecNAhPbGqpuZj9Yfp1CwcVaPDwpm0B8P txxA== X-Gm-Message-State: AOAM532GRjmuhP2s6y4GYq0p7/paLMO+AtfNJRRviCFxFEnIXsdMgGSc HvBQ+E5m22EDDgDMT0rxfZJJz+wER4g0L3V5RgEvCw== X-Google-Smtp-Source: ABdhPJxm93cdTAPl6mJX4bj/5/52s16IRBAo/arqepqGXR8NM99fuOAxt4ZL1ZDDkNBtyJN3Z/9KJIYLtiamgkgxWDs= X-Received: by 2002:ac2:47f8:: with SMTP id b24mr1520091lfp.108.1612353047926; Wed, 03 Feb 2021 03:50:47 -0800 (PST) MIME-Version: 1.0 References: <74830d4f-5a76-8ba8-aad0-0d79f7c01af9@pengutronix.de> <6dc99fd9ffbc5f405c5f64d0802d1399fc6428e4.camel@kernel.org> <8b9477e150d7c939dc0def3ebb4443efcc83cd85.camel@pengutronix.de> <18529562ed71becf21401ec9fd9d95c4ac44fdc0.camel@linux.ibm.com> <2012751fd653c284679aa2c6ac9a56a5edbf1410.camel@pengutronix.de> In-Reply-To: <2012751fd653c284679aa2c6ac9a56a5edbf1410.camel@pengutronix.de> From: Sumit Garg Date: Wed, 3 Feb 2021 17:20:36 +0530 Message-ID: Subject: Re: Migration to trusted keys: sealing user-provided key? To: =?UTF-8?Q?Jan_L=C3=BCbbe?= Cc: James Bottomley , Mimi Zohar , Jarkko Sakkinen , Ahmad Fatoum , David Howells , "open list:ASYMMETRIC KEYS" , linux-integrity@vger.kernel.org, Linux Kernel Mailing List , "open list:SECURITY SUBSYSTEM" , kernel@pengutronix.de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: keyrings@vger.kernel.org On Tue, 2 Feb 2021 at 18:04, Jan L=C3=BCbbe wrote: > > On Tue, 2021-02-02 at 17:45 +0530, Sumit Garg wrote: > > Hi Jan, > > > > On Sun, 31 Jan 2021 at 23:40, James Bottomley wrot= e: > > > > > > On Sun, 2021-01-31 at 15:14 +0100, Jan L=C3=BCbbe wrote: > > > > On Sun, 2021-01-31 at 07:09 -0500, Mimi Zohar wrote: > > > > > On Sat, 2021-01-30 at 19:53 +0200, Jarkko Sakkinen wrote: > > > > > > On Thu, 2021-01-28 at 18:31 +0100, Ahmad Fatoum wrote: > > > > > > > Hello, > > > > > > > > > > > > > > I've been looking into how a migration to using > > > > > > > trusted/encrypted keys would look like (particularly with dm- > > > > > > > crypt). > > > > > > > > > > > > > > Currently, it seems the the only way is to re-encrypt the > > > > > > > partitions because trusted/encrypted keys always generate the= ir > > > > > > > payloads from RNG. > > > > > > > > > > > > > > If instead there was a key command to initialize a new > > > > > > > trusted/encrypted key with a user provided value, users could > > > > > > > use whatever mechanism they used beforehand to get a plaintex= t > > > > > > > key and use that to initialize a new trusted/encrypted key. > > > > > > > From there on, the key will be like any other trusted/encrypt= ed > > > > > > > key and not be disclosed again to userspace. > > > > > > > > > > > > > > What are your thoughts on this? Would an API like > > > > > > > > > > > > > > keyctl add trusted dmcrypt-key 'set ' # user- > > > > > > > supplied content > > > > > > > > > > > > > > be acceptable? > > > > > > > > > > > > Maybe it's the lack of knowledge with dm-crypt, but why this > > > > > > would be useful? Just want to understand the bottleneck, that's > > > > > > all. > > > > > > > > Our goal in this case is to move away from having the dm-crypt key > > > > material accessible to user-space on embedded devices. For an > > > > existing dm-crypt volume, this key is fixed. A key can be loaded in= to > > > > user key type and used by dm-crypt (cryptsetup can already do it th= is > > > > way). But at this point, you can still do 'keyctl read' on that key= , > > > > exposing the key material to user space. > > > > > > > > Currently, with both encrypted and trusted keys, you can only > > > > generate new random keys, not import existing key material. > > > > > > > > James Bottomley mentioned in the other reply that the key format wi= ll > > > > become compatible with the openssl_tpm2_engine, which would provide= a > > > > workaround. This wouldn't work with OP-TEE-based trusted keys (see > > > > Sumit Garg's series), though. > > > > > > Assuming OP-TEE has the same use model as the TPM, someone will > > > eventually realise the need for interoperable key formats between key > > > consumers and then it will work in the same way once the kernel gets > > > updated to speak whatever format they come up with. > > > > IIUC, James re-work for TPM trusted keys is to allow loading of sealed > > trusted keys directly via user-space (with proper authorization) into > > the kernel keyring. > > > > I think similar should be achievable with OP-TEE (via extending pseudo > > TA [1]) as well to allow restricted user-space access (with proper > > authorization) to generate sealed trusted key blob that should be > > interoperable with the kernel. Currently OP-TEE exposes trusted key > > interfaces for kernel users only. > > What is the security benefit of having the key blob creation in user-spac= e > instead of in the kernel? Key import is a standard operation in HSMs or P= KCS#11 > tokens. User authentication, AFAIK most of the HSMs or PKCS#11 require that for key import. But IIUC, your suggested approach to load plain key into kernel keyring and say it's *trusted* without any user authentication, would it really be a trusted key? What prevents a rogue user from making his key as the dm-crypt trusted key? > > I mainly see the downside of having to add another API to access the unde= rlying > functionality (be it trusted key TA or the NXP CAAM HW *) and requiring > platform-specific userspace code. I am not sure why you would call the standardized TEE interface [1] to be platform-specific, it is meant to be platform agnostic. And I think we can have openssl_tee_engine on similar lines as the openssl_tpm2_engine. [1] https://globalplatform.org/specs-library/tee-client-api-specification/ -Sumit > > This CAAM specific API (in out-of-tree patches) was exactly the part I wa= s > trying to get rid of. ;) > > Regards, > Jan > > -- > Pengutronix e.K. | = | > Steuerwalder Str. 21 | http://www.pengutronix.de/ = | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 = | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 = | >