On 02.07.21 12:53, Richard Weinberger wrote:

Ahmad,

----- Ursprüngliche Mail -----

quoted

Von: "Ahmad Fatoum" [off-list ref]

quoted

I'm still think that hard coding the key modifier is not wise.
As I said[0], there are folks out there that want to provide their own modifier,
so it is not only about being binary compatible with other CAAM blob patches in
the wild.

I don't think the characterization as a salt is accurate. AFAIU it's more
of a namespace, so blobs being loaded are "type-checked" against the modifier.

Well, the CAAM programmer's reference manual states that the blob key is a 128 bit modifier
and has two purposes:
1. It can be used as tag to provide separation between blobs to detect accidental replacement of blobs.
2. But it can also be treated as secret to provide additional protection. Because the blob encryption
key derivation includes the key modifier.

While you have case 1 in mind, I care about case 2. :-)

Ah, using the key modifier as a passphrase didn't occur to me.

quoted

quoted

I'll happily implement that feature after your patches got merged but IMHO we
should first agree on an interface.
How about allowing another optional parameter to Opt_new and Opt_load

Sound good to me. pcrlock for TPM trusted keys has the same interface.

I'd prefer the new option to accept strings, not hex though.

Both is possible. If the string starts with "0x" it needs to be decoded to a
128 bit key. Otherwise it has to be a up to 16 byte string.

Fine by me. Looking forward to your patches. :-)


Cheers,
Ahmad

Thanks,
//richard

-- 
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 |