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 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@xxxxxxxxx)
Public Key: https://mrcn.st/pub



[Index of Archives]     [Linux Memonry Technology]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux