lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <7AED262F-9387-446D-B11A-C549C02542F9@sigma-star.at>
Date: Mon, 5 Feb 2024 09:39:07 +0100
From: David Gstir <david@...ma-star.at>
To: Mimi Zohar <zohar@...ux.ibm.com>,
 James Bottomley <jejb@...ux.ibm.com>,
 Jarkko Sakkinen <jarkko@...nel.org>,
 Herbert Xu <herbert@...dor.apana.org.au>,
 "David S. Miller" <davem@...emloft.net>
Cc: Shawn Guo <shawnguo@...nel.org>,
 Jonathan Corbet <corbet@....net>,
 Sascha Hauer <s.hauer@...gutronix.de>,
 "kernel@...gutronix.de" <kernel@...gutronix.de>,
 Fabio Estevam <festevam@...il.com>,
 NXP Linux Team <linux-imx@....com>,
 Ahmad Fatoum <a.fatoum@...gutronix.de>,
 sigma star Kernel Team <upstream+dcp@...ma-star.at>,
 David Howells <dhowells@...hat.com>,
 Li Yang <leoyang.li@....com>,
 Paul Moore <paul@...l-moore.com>,
 James Morris <jmorris@...ei.org>,
 "Serge E. Hallyn" <serge@...lyn.com>,
 "Paul E. McKenney" <paulmck@...nel.org>,
 Randy Dunlap <rdunlap@...radead.org>,
 Catalin Marinas <catalin.marinas@....com>,
 "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
 Tejun Heo <tj@...nel.org>,
 "Steven Rostedt (Google)" <rostedt@...dmis.org>,
 linux-doc@...r.kernel.org,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
 "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
 "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
 linux-arm-kernel@...ts.infradead.org,
 linuxppc-dev@...ts.ozlabs.org,
 "linux-security-module@...r.kernel.org" <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v5 0/6] DCP as trusted keys backend

Hi,

> On 15.12.2023, at 12:06, David Gstir <david@...ma-star.at> wrote:
> 
> This is a revival of the previous patch set submitted by Richard Weinberger:
> https://lore.kernel.org/linux-integrity/20210614201620.30451-1-richard@nodat/
> 
> v4 is here:
> https://lore.kernel.org/keyrings/20231024162024.51260-1-david@sigma-star.at/
> 
> v4 -> v5:
> - Make Kconfig for trust source check scalable as suggested by Jarkko Sakkinen
> - Add Acked-By from Herbert Xu to patch #1 - thanks!
> v3 -> v4:
> - Split changes on MAINTAINERS and documentation into dedicated patches
> - Use more concise wording in commit messages as suggested by Jarkko Sakkinen
> v2 -> v3:
> - Addressed review comments from Jarkko Sakkinen
> v1 -> v2:
> - Revive and rebase to latest version
> - Include review comments from Ahmad Fatoum
> 
> The Data CoProcessor (DCP) is an IP core built into many NXP SoCs such
> as i.mx6ull.
> 
> Similar to the CAAM engine used in more powerful SoCs, DCP can AES-
> encrypt/decrypt user data using a unique, never-disclosed,
> device-specific key. Unlike CAAM though, it cannot directly wrap and
> unwrap blobs in hardware. As DCP offers only the bare minimum feature
> set and a blob mechanism needs aid from software. A blob in this case
> is a piece of sensitive data (e.g. a key) that is encrypted and
> authenticated using the device-specific key so that unwrapping can only
> be done on the hardware where the blob was wrapped.
> 
> This patch series adds a DCP based, trusted-key backend and is similar
> in spirit to the one by Ahmad Fatoum [0] that does the same for CAAM.
> It is of interest for similar use cases as the CAAM patch set, but for
> lower end devices, where CAAM is not available.
> 
> Because constructing and parsing the blob has to happen in software,
> we needed to decide on a blob format and chose the following:
> 
> struct dcp_blob_fmt {
> __u8 fmt_version;
> __u8 blob_key[AES_KEYSIZE_128];
> __u8 nonce[AES_KEYSIZE_128];
> __le32 payload_len;
> __u8 payload[];
> } __packed;
> 
> The `fmt_version` is currently 1.
> 
> The encrypted key is stored in the payload area. It is AES-128-GCM
> encrypted using `blob_key` and `nonce`, GCM auth tag is attached at
> the end of the payload (`payload_len` does not include the size of
> the auth tag).
> 
> The `blob_key` itself is encrypted in AES-128-ECB mode by DCP using
> the OTP or UNIQUE device key. A new `blob_key` and `nonce` are generated
> randomly, when sealing/exporting the DCP blob.
> 
> This patchset was tested with dm-crypt on an i.MX6ULL board.
> 
> [0] https://lore.kernel.org/keyrings/20220513145705.2080323-1-a.fatoum@pengutronix.de/
> 
> David Gstir (6):
>  crypto: mxs-dcp: Add support for hardware-bound keys
>  KEYS: trusted: improve scalability of trust source config
>  KEYS: trusted: Introduce NXP DCP-backed trusted keys
>  MAINTAINERS: add entry for DCP-based trusted keys
>  docs: document DCP-backed trusted keys kernel params
>  docs: trusted-encrypted: add DCP as new trust source
> 
> .../admin-guide/kernel-parameters.txt         |  13 +
> .../security/keys/trusted-encrypted.rst       |  85 +++++
> MAINTAINERS                                   |   9 +
> drivers/crypto/mxs-dcp.c                      | 104 +++++-
> include/keys/trusted_dcp.h                    |  11 +
> include/soc/fsl/dcp.h                         |  17 +
> security/keys/trusted-keys/Kconfig            |  18 +-
> security/keys/trusted-keys/Makefile           |   2 +
> security/keys/trusted-keys/trusted_core.c     |   6 +-
> security/keys/trusted-keys/trusted_dcp.c      | 311 ++++++++++++++++++
> 10 files changed, 562 insertions(+), 14 deletions(-)
> create mode 100644 include/keys/trusted_dcp.h
> create mode 100644 include/soc/fsl/dcp.h
> create mode 100644 security/keys/trusted-keys/trusted_dcp.c

Jarkko, Mimi, David do you need anything from my side for these patches to get them merged?

Thanks,
- David


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ