Hello Jarkko, On 28.03.21 22:37, Jarkko Sakkinen wrote: > On Sat, Mar 27, 2021 at 01:41:24PM +0100, David Gstir wrote: >> Generally speaking, I’d say trusting the CAAM RNG and trusting in it’s >> other features are two separate things. However, reading through the CAAM >> key blob spec I’ve got here, CAAM key blob keys (the keys that secure a blob’s >> content) are generated using its internal RNG. So I’d save if the CAAM RNG >> is insecure, so are generated key blobs. Maybe somebody with more insight >> into the CAAM internals can verify that, but I don’t see any point in using >> the kernel’s RNG as long as we let CAAM generate the key blob keys for us. > > Here's my long'ish analysis. Please read it to the end if by ever means > possible, and apologies, I usually try to keep usually my comms short, but > this requires some more meat than the usual. Thanks for the write-up! > The Bad News > ============ > > Now that we add multiple hardware trust sources for trusted keys, will > there ever be a scenario where a trusted key is originally sealed with a > backing hardware A, unsealed, and resealed with hardware B? > > The hardware and vendor neutral way to generate the key material would be > unconditionally always just the kernel RNG. > > CAAM is actually worse than TCG because it's not even a standards body, if > I got it right. Not a lot but at least a tiny fraction. CAAM is how NXP calls the crypto accelerator built into some of its SoCs. > This brings an open item in TEE patches: trusted_tee_get_random() is an > issue in generating kernel material. I would rather replace that with > kernel RNG *for now*, because the same open question applies also to ARM > TEE. It's also a single company controlled backing technology. > > By all practical means, I do trust ARM TEE in my personal life but this is > not important. > > CAAM *and* TEE backends break the golden rule of putting as little trust as > possible to anything, even not anything weird is clear at sight, as > security is essentially a game of known unknowns and unknown unknowns. Agreed. > The GOOD News > ============= > > So there's actually option (C) that also fixes the TPM trustd keys issue: > > Add a new kernel patch, which: > > 1. Adds the use of kernel RNG as a boot option. > 2. If this boot option is not active, the subsystem will print a warning > to klog denoting this. > 3. Default is of course vendor RNG given the bad design issue in the TPM > trusted keys, but the warning in klog will help to address it at least > a bit. Why should the TPM backend's choice influence later backends? We could add a new option for key creation time, e.g.: keyctl add trusted kmk "new keylen rng=kernel" @s The default would be rng=vendor if available with a fallback to rng=kernel, which should always be available. > 4. Document all this to Documentation/security/keys/trusted-encrypted.rst. Yes, backends would then document whether they support a rng=vendor or not. > I'd prefer the choice between A, B and C be concluded rather sooner than > later. FWIW, my vote is for option C, with the change described above. Cheers, Ahmad > > /Jarkko > -- 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 |
