On Wed, 2021-02-03 at 17:20 +0530, Sumit Garg wrote: > On Tue, 2 Feb 2021 at 18:04, Jan Lübbe <jlu@xxxxxxxxxxxxxx> wrote: > > > > On Tue, 2021-02-02 at 17:45 +0530, Sumit Garg wrote: > > > Hi Jan, > > > > > > On Sun, 31 Jan 2021 at 23:40, James Bottomley <jejb@xxxxxxxxxxxxx> wrote: > > > > > > > > On Sun, 2021-01-31 at 15:14 +0100, Jan Lübbe wrote: > > > > > On Sun, 2021-01-31 at 07:09 -0500, Mimi Zohar wrote: > > > > > > On Sat, 2021-01-30 at 19:53 +0200, Jarkko Sakkinen wrote: > > > > > > > On Thu, 2021-01-28 at 18:31 +0100, Ahmad Fatoum wrote: > > > > > > > > Hello, > > > > > > > > > > > > > > > > I've been looking into how a migration to using > > > > > > > > trusted/encrypted keys would look like (particularly with dm- > > > > > > > > crypt). > > > > > > > > > > > > > > > > Currently, it seems the the only way is to re-encrypt the > > > > > > > > partitions because trusted/encrypted keys always generate their > > > > > > > > payloads from RNG. > > > > > > > > > > > > > > > > If instead there was a key command to initialize a new > > > > > > > > trusted/encrypted key with a user provided value, users could > > > > > > > > use whatever mechanism they used beforehand to get a plaintext > > > > > > > > key and use that to initialize a new trusted/encrypted key. > > > > > > > > From there on, the key will be like any other trusted/encrypted > > > > > > > > key and not be disclosed again to userspace. > > > > > > > > > > > > > > > > What are your thoughts on this? Would an API like > > > > > > > > > > > > > > > > keyctl add trusted dmcrypt-key 'set <content>' # user- > > > > > > > > supplied content > > > > > > > > > > > > > > > > be acceptable? > > > > > > > > > > > > > > Maybe it's the lack of knowledge with dm-crypt, but why this > > > > > > > would be useful? Just want to understand the bottleneck, that's > > > > > > > all. > > > > > > > > > > Our goal in this case is to move away from having the dm-crypt key > > > > > material accessible to user-space on embedded devices. For an > > > > > existing dm-crypt volume, this key is fixed. A key can be loaded into > > > > > user key type and used by dm-crypt (cryptsetup can already do it this > > > > > way). But at this point, you can still do 'keyctl read' on that key, > > > > > exposing the key material to user space. > > > > > > > > > > Currently, with both encrypted and trusted keys, you can only > > > > > generate new random keys, not import existing key material. > > > > > > > > > > James Bottomley mentioned in the other reply that the key format will > > > > > become compatible with the openssl_tpm2_engine, which would provide a > > > > > workaround. This wouldn't work with OP-TEE-based trusted keys (see > > > > > Sumit Garg's series), though. > > > > > > > > Assuming OP-TEE has the same use model as the TPM, someone will > > > > eventually realise the need for interoperable key formats between key > > > > consumers and then it will work in the same way once the kernel gets > > > > updated to speak whatever format they come up with. > > > > > > IIUC, James re-work for TPM trusted keys is to allow loading of sealed > > > trusted keys directly via user-space (with proper authorization) into > > > the kernel keyring. > > > > > > I think similar should be achievable with OP-TEE (via extending pseudo > > > TA [1]) as well to allow restricted user-space access (with proper > > > authorization) to generate sealed trusted key blob that should be > > > interoperable with the kernel. Currently OP-TEE exposes trusted key > > > interfaces for kernel users only. > > > > What is the security benefit of having the key blob creation in user-space > > instead of in the kernel? Key import is a standard operation in HSMs or PKCS#11 > > tokens. > > User authentication, AFAIK most of the HSMs or PKCS#11 require that > for key import. But IIUC, your suggested approach to load plain key > into kernel keyring and say it's *trusted* without any user > authentication, would it really be a trusted key? What prevents a > rogue user from making his key as the dm-crypt trusted key? There is user authentication at the level of key rings. So an untrusted user cannot load or link keys they have no write permission for. As we already have user type keys, which don't have these restrictions and are accepted by most subsystems, any use of kernel keyrings must already make sure that the proper keys are used. With asymmetric keys we have trusted key *rings*: # keyctl show %:.secondary_trusted_keys Keyring 638775388 ---lswrv 0 0 keyring: .secondary_trusted_keys 1071890135 ---lswrv 0 0 \_ keyring: .builtin_trusted_keys 816294887 ---lswrv 0 0 \_ asymmetric: Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1 630436721 ---lswrv 0 0 \_ asymmetric: Debian Secure Boot Signer 2020: 00b55eb3b9 Here, a key is trusted because of it's presence in a keyring, not because it has a specific type. For example, fs-verity uses this mechanism as well. For the trusted key *type*, my understanding is that trusted refers to only being able to load and access them in specific "trusted" system states (via TPM PRC, TEE initialization via secure boot or SoC specific hardware status checks). So for example protecting against loading a data-encryption key into an unsigned kernel. > > I mainly see the downside of having to add another API to access the underlying > > functionality (be it trusted key TA or the NXP CAAM HW *) and requiring > > platform-specific userspace code. > > I am not sure why you would call the standardized TEE interface [1] to > be platform-specific, it is meant to be platform agnostic. And I think > we can have openssl_tee_engine on similar lines as the > openssl_tpm2_engine. Sorry, I meant platform-specific in the sense that some platforms use TPMs, while others use TEEs. The trusted key type was also suggested several times as the correct abstraction for SoC-specific key encapsulation hardware (instead of custom interfaces), so there will likely be platforms which don't have a TPM or TEE, but still trusted keys. Regards Jan > [1] https://globalplatform.org/specs-library/tee-client-api-specification/ > -- 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 |
