On Mon, Mar 29, 2021 at 12:11:24PM +0200, Ahmad Fatoum wrote: > 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. It matters a lot because it is existing ABI - for better or worse. I think a new option is a bad idea, because it cannot easily enforced. Kernel command-line on the other hand can be even signed. /Jarkko
