On Fri, Dec 15, 2023 at 6:07 AM David Gstir <david@xxxxxxxxxxxxx> wrote: > > This is a revival of the previous patch set submitted by Richard Weinberger: > https://lore.kernel.org/linux-integrity/20210614201620.30451-1-richard@xxxxxx/ > > v4 is here: > https://lore.kernel.org/keyrings/20231024162024.51260-1-david@xxxxxxxxxxxxx/ > > 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@xxxxxxxxxxxxxx/ > > 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 - if this patchset isn't already in your review queue, can you take a look at it from a security/keys perspective? Thanks. -- paul-moore.com
