Hello Horia, On 21.03.21 21:01, Horia Geantă wrote: >> - [RFC] drivers: crypto: caam: key: Add caam_tk key type >> Franck added[3] a new "caam_tk" key type based on Udit's work. The key >> material stays within the kernel only, but can optionally be user-set >> instead of coming from RNG. James voiced the opinion that there should >> be just one user-facing generic wrap/unwrap key type with multiple >> possible handlers. David suggested trusted keys. >> > The whole point was to use caam "black blobs", with the main advantage of > keys being kept encrypted in memory after "unsealing" the blobs. > (Keys in blobs are encrypted with a persistent BKEK - blob KEK, derived from > fuse-based OTPMK. OTOH black keys are keys encrypted with an ephemeral, random > KEK that is stored in an internal caam register. When a black blob is unsealed, > the key is practically rekeyed, the random key replacing the BKEK; key is never > exposed in plaintext, rekeying happens in caam). > > Current implementation uses "red blobs", which means keys are left unprotected > in memory after blobs are unsealed. Oh. I will reread the series when sending the v2 cover letter. Thanks for spotting. (Sorry for the noise, missed this question first time) >> - Introduce TEE based Trusted Keys support >> Sumit reworked[4] trusted keys to support multiple possible backends with >> one chosen at boot time and added a new TEE backend along with TPM. >> This now sits in Jarkko's master branch to be sent out for v5.13 >> >> This patch series builds on top of Sumit's rework to have the CAAM as yet another >> trusted key backend. >> > Shouldn't the description under TRUSTED_KEYS (in security/keys/Kconfig) > be updated to reflect the availability of multiple backends? > > Thanks, > Horia > -- 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 |
