On Wed, 10 Mar 2021 at 02:47, Hector Martin <marcan@xxxxxxxxx> wrote: > > On 09/03/2021 01.20, Linus Walleij wrote: > > I suppose it would be a bit brutal if the kernel would just go in and > > appropriate any empty RPMB it finds, but I suspect it is the right way > > to make use of this facility given that so many of them are just sitting > > there unused. Noone will run $CUSTOM_UTILITY any more than they > > run the current RPMB tools in mmc-tools. > > AIUI the entire thing relies on a shared key that is programmed once > into the RPMB device, which is a permanent operation. This key has to be > secure, usually stored on CPU fuses or derived based on such a root of > trust. To me it would seem ill-advised to attempt to automate this > process and have the kernel do a permanent take-over of any RPMBs it > finds (with what key, for one?) :) > Wouldn't it be a good idea to use DT here to represent whether a particular RPMB is used as a TEE backup or is available for normal kernel usage? In case of normal kernel usage, I think the RPMB key can come from trusted and encrypted keys subsystem. -Sumit > For what it's worth, these days I think Apple uses a separate, dedicated > secure element for replay protected storage, not RPMB. That seems like a > sane approach, given that obviously Flash storage vendors cannot be > trusted to write security-critical firmware. But if all you have is > RPMB, using it is better than nothing. > > The main purpose of the RPMB is, as the name implies, replay protection. > You can do secure storage on any random flash with encryption, and even > do full authentication with hash trees, but the problem is no matter how > fancy your scheme is, attackers can always dump all memory and roll your > device back to the past. This defeats stuff like PIN code attempt > limits. So it isn't so much for storing crypto keys or such, but rather > a way to prevent these attacks. > > -- > Hector Martin (marcan@xxxxxxxxx) > Public Key: https://mrcn.st/pub
