Re: [RFC PATCH 1/5] rpmb: add Replay Protected Memory Block (RPMB) subsystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux