lkml.org 
[lkml]   [2021]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH 1/5] rpmb: add Replay Protected Memory Block (RPMB) subsystem
Date
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@marcan.st)
Public Key: https://mrcn.st/pub

\
 
 \ /
  Last update: 2021-03-09 22:11    [W:0.075 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site