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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 5C50FC11F68 for ; Wed, 14 Jul 2021 09:32:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 471CE613B7 for ; Wed, 14 Jul 2021 09:32:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238821AbhGNJfS (ORCPT ); Wed, 14 Jul 2021 05:35:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238833AbhGNJfR (ORCPT ); Wed, 14 Jul 2021 05:35:17 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7FFA9C061760 for ; Wed, 14 Jul 2021 02:32:26 -0700 (PDT) Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1m3bFY-0008WH-W8; Wed, 14 Jul 2021 11:32:17 +0200 Subject: Re: [PATCH 3/3] doc: trusted-encrypted: add DCP as new trust source To: Richard Weinberger , keyrings@vger.kernel.org Cc: David Gstir , David Howells , "David S. Miller" , Fabio Estevam , Herbert Xu , James Bottomley , James Morris , Jarkko Sakkinen , Jonathan Corbet , linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org, linux-doc@vger.kernel.org, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, Mimi Zohar , NXP Linux Team , Pengutronix Kernel Team , Sascha Hauer , "Serge E. Hallyn" , Shawn Guo References: <20210614201620.30451-1-richard@nod.at> <20210614201620.30451-4-richard@nod.at> From: Ahmad Fatoum Message-ID: Date: Wed, 14 Jul 2021 11:32:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210614201620.30451-4-richard@nod.at> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: a.fatoum@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-crypto@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Hello Richard, Hello David, On 14.06.21 22:16, Richard Weinberger wrote: > From: David Gstir > > Update the documentation for trusted and encrypted KEYS with DCP as new > trust source: > > - Describe security properties of DCP trust source > - Describe key usage > - Document blob format > > Cc: Ahmad Fatoum > Cc: David Gstir > Cc: David Howells > Cc: "David S. Miller" > Cc: Fabio Estevam > Cc: Herbert Xu > Cc: James Bottomley > Cc: James Morris > Cc: Jarkko Sakkinen > Cc: Jonathan Corbet > Cc: keyrings@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-crypto@vger.kernel.org > Cc: linux-doc@vger.kernel.org > Cc: linux-integrity@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-security-module@vger.kernel.org > Cc: Mimi Zohar > Cc: NXP Linux Team > Cc: Pengutronix Kernel Team > Cc: Richard Weinberger > Cc: Sascha Hauer > Cc: "Serge E. Hallyn" > Cc: Shawn Guo > Co-developed-by: Richard Weinberger > Signed-off-by: David Gstir > --- > .../security/keys/trusted-encrypted.rst | 84 ++++++++++++++++++- > 1 file changed, 83 insertions(+), 1 deletion(-) > > diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst > index 80d5a5af62a1..e8413122e4bc 100644 > --- a/Documentation/security/keys/trusted-encrypted.rst > +++ b/Documentation/security/keys/trusted-encrypted.rst > @@ -35,6 +35,11 @@ safe. > Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip > fuses and is accessible to TEE only. > > + (3) DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs) > + > + Rooted to a one-time programmable key (OTP) that is generally burnt in > + the on-chip fuses and is accessbile to the DCP encryption engine only. s/accessbile/accessible/ . In the code you differentiate between UNIQUE and OTP. Here you use OTP to mean both. Perhaps explicitly mention this? > + > * Execution isolation > > (1) TPM > @@ -46,6 +51,12 @@ safe. > Customizable set of operations running in isolated execution > environment verified via Secure/Trusted boot process. > > + (3) DCP > + > + Fixed set of cryptographic operations running in isolated execution > + environment. Only basic blob key encryption is executed there. > + The actual key sealing/unsealing is done on main processor/kernel space. > + > * Optional binding to platform integrity state > > (1) TPM > @@ -63,6 +74,11 @@ safe. > Relies on Secure/Trusted boot process for platform integrity. It can > be extended with TEE based measured boot process. > > + (3) DCP > + > + Relies on Secure/Trusted boot process (called HAB by vendor) for > + platform integrity. > + > * Interfaces and APIs > > (1) TPM > @@ -74,10 +90,14 @@ safe. > TEEs have well-documented, standardized client interface and APIs. For > more details refer to ``Documentation/staging/tee.rst``. > > + (3) DCP > + > + Vendor-specific API that is implemented as part of the DCP crypto driver in > + ``drivers/crypto/mxs-dcp.c``. > > * Threat model > > - The strength and appropriateness of a particular TPM or TEE for a given > + The strength and appropriateness of a particular TPM, TEE or DCP for a given > purpose must be assessed when using them to protect security-relevant data. > > > @@ -103,6 +123,14 @@ access control policy within the trust source. > from platform specific hardware RNG or a software based Fortuna CSPRNG > which can be seeded via multiple entropy sources. > > + * DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs) > + > + The DCP hardware device itself does not provide a dedicated RNG interface, > + so the kernel default RNG is used. SoCs with DCP like the i.MX6ULL do have > + a dedicated hardware RNG that is independent from DCP which can be enabled > + to back the kernel RNG. > + > + > Encrypted Keys > -------------- > > @@ -188,6 +216,19 @@ Usage:: > specific to TEE device implementation. The key length for new keys is always > in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits). > > +Trusted Keys usage: DCP > +----------------------- > + > +Usage:: > + > + keyctl add trusted name "new keylen" ring > + keyctl add trusted name "load hex_blob" ring > + keyctl print keyid > + > +"keyctl print" returns an ASCII hex copy of the sealed key, which is in format > +specific to this DCP key-blob implementation. The key length for new keys is > +always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits). > + > Encrypted Keys usage > -------------------- > > @@ -370,3 +411,44 @@ string length. > privkey is the binary representation of TPM2B_PUBLIC excluding the > initial TPM2B header which can be reconstructed from the ASN.1 octed > string length. > + > +DCP Blob Format > +--------------- > + > +The Data Co-Processor (DCP) provides hardware-bound AES keys using its > +AES encryption engine only. It does not provide direct key sealing/unsealing. > +To make DCP hardware encryption keys usable as trust source, we define > +our own custom format that uses a hardware-bound key to secure the sealing > +key stored in the key blob. > + > +Whenever a new tusted key using DCP is generated, we generate a random 128-bit s/tusted/trusted/ > +blob encryption key (BEK) and 128-bit nonce. The BEK and nonce are used to > +encrypt the trusted key payload using AES-128-GCM. > + > +The BEK itself is encrypted using the hardware-bound key using the DCP's AES > +encryption engine with AES-128-ECB. The encrypted BEK, generated nonce, > +BEK-encrypted payload and authentication tag make up the blob format together > +with a version number, payload length and authentication tag:: > + > + /* > + * struct dcp_blob_fmt - DCP BLOB format. > + * > + * @fmt_version: Format version, currently being %1 > + * @blob_key: Random AES 128 key which is used to encrypt @payload, > + * @blob_key itself is encrypted with OTP or UNIQUE device key in > + * AES-128-ECB mode by DCP. > + * @nonce: Random nonce used for @payload encryption. > + * @payload_len: Length of the plain text @payload. > + * @payload: The payload itself, encrypted using AES-128-GCM and @blob_key, > + * GCM auth tag of size AES_BLOCK_SIZE is attached at the end of it. > + * > + * The total size of a DCP BLOB is sizeof(struct dcp_blob_fmt) + @payload_len + > + * AES_BLOCK_SIZE. > + */ > + struct dcp_blob_fmt { > + __u8 fmt_version; > + __u8 blob_key[AES_KEYSIZE_128]; > + __u8 nonce[AES_KEYSIZE_128]; > + __le32 payload_len; > + __u8 payload[0]; [] ? > + } __packed; > Cheers, Ahmad -- 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 | 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=-15.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 45FE6C07E9A for ; Wed, 14 Jul 2021 09:34:09 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 0FC576120A for ; Wed, 14 Jul 2021 09:34:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0FC576120A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=P/0+gf2EXXIKxGoOrQCjEZ4TUIJvs+A7KDDrTch1/J4=; b=At0MKZWr2KxCUWdZ/q9lQ83oXh Pan4UddqY5cUrQF96D4rwLrPiHHuXI892X30CRPF6SyO5eA7qYW3bpNlXzu8Osb+S7Svge5jB9Z4B KX1Ivs7VmYXiQXER0+lT4i1sB/1rT/AFLGnz+SVXqE84eJ9MQS0n5G6/8pG1fv5TtbgJax86zHzT+ ir+qheCDoBIqNZdkO0kuFDPdseuhlGf80bXmDaSqf1WW+ARiknX4GiA0XRs4cQoKpNcoTYruEnQL0 NHA4VjKf6Je7OmaEFeEX5RyvxfHzEKCZtWnn58tIGkf7mlXXgKcwOkYgB8Rc3dwAHt4DE2oWesGPk LQVvJ2/A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m3bFn-00CvXS-Pz; Wed, 14 Jul 2021 09:32:31 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m3bFi-00CvWU-JG for linux-arm-kernel@lists.infradead.org; Wed, 14 Jul 2021 09:32:28 +0000 Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1m3bFY-0008WH-W8; Wed, 14 Jul 2021 11:32:17 +0200 Subject: Re: [PATCH 3/3] doc: trusted-encrypted: add DCP as new trust source To: Richard Weinberger , keyrings@vger.kernel.org Cc: David Gstir , David Howells , "David S. Miller" , Fabio Estevam , Herbert Xu , James Bottomley , James Morris , Jarkko Sakkinen , Jonathan Corbet , linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org, linux-doc@vger.kernel.org, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, Mimi Zohar , NXP Linux Team , Pengutronix Kernel Team , Sascha Hauer , "Serge E. Hallyn" , Shawn Guo References: <20210614201620.30451-1-richard@nod.at> <20210614201620.30451-4-richard@nod.at> From: Ahmad Fatoum Message-ID: Date: Wed, 14 Jul 2021 11:32:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210614201620.30451-4-richard@nod.at> Content-Language: en-US X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: a.fatoum@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210714_023226_864029_9A05C8B4 X-CRM114-Status: GOOD ( 40.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello Richard, Hello David, On 14.06.21 22:16, Richard Weinberger wrote: > From: David Gstir > > Update the documentation for trusted and encrypted KEYS with DCP as new > trust source: > > - Describe security properties of DCP trust source > - Describe key usage > - Document blob format > > Cc: Ahmad Fatoum > Cc: David Gstir > Cc: David Howells > Cc: "David S. Miller" > Cc: Fabio Estevam > Cc: Herbert Xu > Cc: James Bottomley > Cc: James Morris > Cc: Jarkko Sakkinen > Cc: Jonathan Corbet > Cc: keyrings@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-crypto@vger.kernel.org > Cc: linux-doc@vger.kernel.org > Cc: linux-integrity@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-security-module@vger.kernel.org > Cc: Mimi Zohar > Cc: NXP Linux Team > Cc: Pengutronix Kernel Team > Cc: Richard Weinberger > Cc: Sascha Hauer > Cc: "Serge E. Hallyn" > Cc: Shawn Guo > Co-developed-by: Richard Weinberger > Signed-off-by: David Gstir > --- > .../security/keys/trusted-encrypted.rst | 84 ++++++++++++++++++- > 1 file changed, 83 insertions(+), 1 deletion(-) > > diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst > index 80d5a5af62a1..e8413122e4bc 100644 > --- a/Documentation/security/keys/trusted-encrypted.rst > +++ b/Documentation/security/keys/trusted-encrypted.rst > @@ -35,6 +35,11 @@ safe. > Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip > fuses and is accessible to TEE only. > > + (3) DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs) > + > + Rooted to a one-time programmable key (OTP) that is generally burnt in > + the on-chip fuses and is accessbile to the DCP encryption engine only. s/accessbile/accessible/ . In the code you differentiate between UNIQUE and OTP. Here you use OTP to mean both. Perhaps explicitly mention this? > + > * Execution isolation > > (1) TPM > @@ -46,6 +51,12 @@ safe. > Customizable set of operations running in isolated execution > environment verified via Secure/Trusted boot process. > > + (3) DCP > + > + Fixed set of cryptographic operations running in isolated execution > + environment. Only basic blob key encryption is executed there. > + The actual key sealing/unsealing is done on main processor/kernel space. > + > * Optional binding to platform integrity state > > (1) TPM > @@ -63,6 +74,11 @@ safe. > Relies on Secure/Trusted boot process for platform integrity. It can > be extended with TEE based measured boot process. > > + (3) DCP > + > + Relies on Secure/Trusted boot process (called HAB by vendor) for > + platform integrity. > + > * Interfaces and APIs > > (1) TPM > @@ -74,10 +90,14 @@ safe. > TEEs have well-documented, standardized client interface and APIs. For > more details refer to ``Documentation/staging/tee.rst``. > > + (3) DCP > + > + Vendor-specific API that is implemented as part of the DCP crypto driver in > + ``drivers/crypto/mxs-dcp.c``. > > * Threat model > > - The strength and appropriateness of a particular TPM or TEE for a given > + The strength and appropriateness of a particular TPM, TEE or DCP for a given > purpose must be assessed when using them to protect security-relevant data. > > > @@ -103,6 +123,14 @@ access control policy within the trust source. > from platform specific hardware RNG or a software based Fortuna CSPRNG > which can be seeded via multiple entropy sources. > > + * DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs) > + > + The DCP hardware device itself does not provide a dedicated RNG interface, > + so the kernel default RNG is used. SoCs with DCP like the i.MX6ULL do have > + a dedicated hardware RNG that is independent from DCP which can be enabled > + to back the kernel RNG. > + > + > Encrypted Keys > -------------- > > @@ -188,6 +216,19 @@ Usage:: > specific to TEE device implementation. The key length for new keys is always > in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits). > > +Trusted Keys usage: DCP > +----------------------- > + > +Usage:: > + > + keyctl add trusted name "new keylen" ring > + keyctl add trusted name "load hex_blob" ring > + keyctl print keyid > + > +"keyctl print" returns an ASCII hex copy of the sealed key, which is in format > +specific to this DCP key-blob implementation. The key length for new keys is > +always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits). > + > Encrypted Keys usage > -------------------- > > @@ -370,3 +411,44 @@ string length. > privkey is the binary representation of TPM2B_PUBLIC excluding the > initial TPM2B header which can be reconstructed from the ASN.1 octed > string length. > + > +DCP Blob Format > +--------------- > + > +The Data Co-Processor (DCP) provides hardware-bound AES keys using its > +AES encryption engine only. It does not provide direct key sealing/unsealing. > +To make DCP hardware encryption keys usable as trust source, we define > +our own custom format that uses a hardware-bound key to secure the sealing > +key stored in the key blob. > + > +Whenever a new tusted key using DCP is generated, we generate a random 128-bit s/tusted/trusted/ > +blob encryption key (BEK) and 128-bit nonce. The BEK and nonce are used to > +encrypt the trusted key payload using AES-128-GCM. > + > +The BEK itself is encrypted using the hardware-bound key using the DCP's AES > +encryption engine with AES-128-ECB. The encrypted BEK, generated nonce, > +BEK-encrypted payload and authentication tag make up the blob format together > +with a version number, payload length and authentication tag:: > + > + /* > + * struct dcp_blob_fmt - DCP BLOB format. > + * > + * @fmt_version: Format version, currently being %1 > + * @blob_key: Random AES 128 key which is used to encrypt @payload, > + * @blob_key itself is encrypted with OTP or UNIQUE device key in > + * AES-128-ECB mode by DCP. > + * @nonce: Random nonce used for @payload encryption. > + * @payload_len: Length of the plain text @payload. > + * @payload: The payload itself, encrypted using AES-128-GCM and @blob_key, > + * GCM auth tag of size AES_BLOCK_SIZE is attached at the end of it. > + * > + * The total size of a DCP BLOB is sizeof(struct dcp_blob_fmt) + @payload_len + > + * AES_BLOCK_SIZE. > + */ > + struct dcp_blob_fmt { > + __u8 fmt_version; > + __u8 blob_key[AES_KEYSIZE_128]; > + __u8 nonce[AES_KEYSIZE_128]; > + __le32 payload_len; > + __u8 payload[0]; [] ? > + } __packed; > Cheers, Ahmad -- 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 | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel