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
