| 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
| ||
|
Message-Id: <20221006130837.17587-1-pankaj.gupta@nxp.com>
Date: Thu, 6 Oct 2022 18:38:29 +0530
From: Pankaj Gupta <pankaj.gupta@....com>
To: jarkko@...nel.org, a.fatoum@...gutronix.de, gilad@...yossef.com,
Jason@...c4.com, jejb@...ux.ibm.com, zohar@...ux.ibm.com,
dhowells@...hat.com, sumit.garg@...aro.org, david@...ma-star.at,
michael@...le.cc, john.ernberg@...ia.se, jmorris@...ei.org,
serge@...lyn.com, herbert@...dor.apana.org.au, davem@...emloft.net,
j.luebbe@...gutronix.de, ebiggers@...nel.org, richard@....at,
keyrings@...r.kernel.org, linux-crypto@...r.kernel.org,
linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, sahil.malhotra@....com,
kshitiz.varshney@....com, horia.geanta@....com, V.Sethi@....com
Cc: Pankaj Gupta <pankaj.gupta@....com>
Subject: [PATCH v0 0/8] Hardware Bound key added to Trusted Key-Ring
Hardware Bound key(HBK), is never available as a plain key buffer outside of the hardware boundary.
Thus, it is un-usable, even if somehow fetched from kernel memory.
It ensures run-time security.
This patchset establishes a generic bridge between HBK & the kernel's trusted-keyring.
This patchset adds generic support for identifying if the key is HBK.
Note: Copy-paste this text-based block diagram to notepad, for better
clarity.
+---------------+
| |
| keyctl |
| |
+-------+-------+
|
|
+-----------------------+-------------------------+
| trusted keyring |
| +---------------+ |
| +-----------------+ |trusted-key | |
| | |-------->|payload (plain)| |
| | | +---------------+ |
|-->| trusted key | +---------------+ |
| | source as CAAM |-------->| trusted-key | |
| +-----------------+ | payload (HBK)| |
| +-------^-------+ |
+---------------------------------------|---------+
|
|
|
+----------------+ crypt_alloc_tfms +-------|------------------+
| Kernel |<------------------| DM-Crypt |
| Crypto-API | | +---------------------+ |
| |------------------>| |struct crypto_tfm: | |
+----------------+ crypto_tfm(HBK) | |- flag-is_hbk | |
| |- struct-hbk_info, | |
| |is copied from the | |
| |tkp structure | |
| +---------------------+ |
+------------|-------------+
|
|
|crypto_tfm(HBK)
|
+---------------|--------------+
| Hardware crypto driver |
| |
| Processing the incoming |
| key based on the flag |
| - as plain key, if is_hbk = 0|
| - as HBK, if is_hbk = 1 |
+------------------------------+
Major additions done: (in brief)
- Newly added:
-- flag-'is_hbk', and
-- struct hw_bound_key_info hbk_info,
added to the structures - tfm & trusted key payload.
- Enhanced the 'keyctl' command to generate the hardware bound key
as trusted key.
-- at the time of generating the HBK, the values: 'flag - is_hbk'
& structure 'hbk_info', in the trusted key payload, is set by
the hw driver, generating or loading the key in the trusted
key-ring.
- Applications like dm-crypt,
-- first fetch the key from trusted key-ring. As part of doing this,
application retains the values of: 'flag - is_hbk' & structure 'hbk_info'.
-- to use kernel crypto api, after allocating the transformation,
application sets the 'flag - is_hbk' & structure 'hbk_info',
to the tfm allocated from crypto_alloc_tfm().
- Newly added information to tfm, helps to influence the core processing logic
for the encapsulated algorithm.
First implementation is based on CAAM.
NXP built CAAM IP is the Cryptographic Acceleration and Assurance Module.
This is contain by the i.MX and QorIQ SoCs by NXP.
CAAM is a suitable backend (source) for kernel trusted keys.
This backend source can be used for run-time security as well by generating the hardware bound key.
Along with plain key, the CAAM generates black key. A black key is an encrypted key, which can only be decrypted inside CAAM.
Hence, CAAM's black key can only be used by CAAM. Thus it is declared as a hardware bound key.
Pankaj Gupta (8):
hw-bound-key: introducing the generic structure
keys-trusted: new cmd line option added
crypto: hbk flags & info added to the tfm
sk_cipher: checking for hw bound operation
keys-trusted: re-factored caam based trusted key
KEYS: trusted: caam based black key
caam alg: symmetric key ciphers are updated
dm-crypt: consumer-app setting the flag-is_hbk
crypto/skcipher.c | 3 +-
drivers/crypto/caam/blob_gen.c | 221 ++++++++++++++++++++--
drivers/crypto/caam/caamalg.c | 43 ++++-
drivers/crypto/caam/caamalg_desc.c | 8 +-
drivers/crypto/caam/desc.h | 8 +-
drivers/crypto/caam/desc_constr.h | 6 +-
drivers/md/dm-crypt.c | 12 +-
include/keys/trusted-type.h | 4 +
include/linux/crypto.h | 5 +
include/linux/hw_bound_key.h | 27 +++
include/soc/fsl/caam-blob.h | 38 ++--
security/keys/trusted-keys/trusted_caam.c | 8 +
security/keys/trusted-keys/trusted_core.c | 16 ++
13 files changed, 356 insertions(+), 43 deletions(-)
create mode 100644 include/linux/hw_bound_key.h
--
2.17.1
Powered by blists - more mailing lists