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 10/03/2021 14.14, Sumit Garg wrote:
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.

Remember that if the key is ever lost, the RPMB is now completely useless forever.

This is why, as far as I know, most sane platforms will use hard fused values to derive this kind of thing, not any kind of key stored in erasable storage.

Also, newly provisioned keys are sent in plain text, which means that any kind of "if the RPMB is blank, take it over" automation equates to handing over your key who an attacker who removes the RPMB and replaces it with a blank one, and then they can go access anything they want on the old RPMB device (assuming the key hasn't changed; and if it has changed that's conversely a recipe for data loss if something goes wrong).

I really think trying to automate any kind of "default" usage of an RPMB is a terrible idea. It needs to be a conscious decision on a per-platform basis.

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