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?) :)
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
