lkml.org 
[lkml]   [2021]   [Mar]   [10]   [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 10/03/2021 18.48, Linus Walleij wrote:
> Disk is encrypted, and RPMB is there to block any exhaustive
> password or other authentication token search.

This relies on having a secure boot chain to start with (otherwise you
can just bypass policy that way; the RPMB is merely storage to give you
anti-rollback properties, it can't enforce anything itself). So you
would have to have a laptop with a fully locked down secure boot, which
can only boot some version of Linux signed by you until, say, LUKS
decryption. And then the tooling around that needs to be integrated with
RPMB, to use it as an attempt counter.

But now this ends up having to involve userspace anyway; the kernel key
stuff doesn't support policy like this, does it? So having the kernel
automagically use RPMB wouldn't get us there.

I may be wrong on the details here, but as far as I know RPMB is
strictly equivalent to a simple secure increment-only counter in what it
buys you. The stuff about writing data to it securely is all a red
herring - you can implement secure storage elsewhere, and with secure
storage + a single secure counter, you can implement anti-rollback.

It is not intended to store keys in a way that is somehow safer than
other mechanisms. After all, you need to securely store the RPMB key to
begin with; you might as well use that to encrypt a keystore on any
random block device.

> Ideally: the only way to make use of the hardware again would
> be to solder off the eMMC, if eMMC is used for RPMB.
> If we have RPMB on an NVME or UFS drive, the idea is
> to lock that thing such that it becomes useless and need to
> be replaced with a new part in this scenario.
>
> In practice: make it hard, because we know no such jail is
> perfect. Make it not worth the effort, make it cheaper for thieves
> to just buy a new harddrive to use a stolen laptop, locking
> the data that was in it away forever by making the drive
> useless for any practical attacks.

But RPMB does not enforce any of this policy for you. RPMB only gives
you a primitive: the ability to have storage that cannot be externally
rolled back. So none of this works unless the entire system is set up to
securely boot all the way until the drive unlock happens, and there are
no other blatant code execution avenues.

There isn't even any encryption involved in the protocol, so all the
data stored in the RPMB is public and available to any attacker.

So unless the kernel grows a subsystem/feature to enforce complex key
policies (with things like use counts, retry times, etc), I don't think
there's a place to integrate RPMB kernel-side. You still need a trusted
userspace tool to glue it all together.

--
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

\
 
 \ /
  Last update: 2021-03-10 14:53    [W:0.228 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site