On Wed, Mar 10, 2021 at 2:52 PM Hector Martin <marcan@xxxxxxxxx> wrote: > 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. Yes and no. For secure boot yes. For other use cases it can still be useful. The way I understand it, there are people (not me) with secure boot ambitions but I wouldn't say that is the only use case, see below. > 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. Yes, you are right, I had the wrong idea. It needs to be something the user (or the users agent such as an organization) decides to make use of, and it is policy so it should be in userspace. We may standardize the key format on the device though. > 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. The typical use-case mentioned in one reference is to restrict the number of password/pin attempts and combine that with secure time to make sure that longer and longer intervals are required between password attempts. This seems pretty neat to me. > 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. This is true for firmware anti-rollback or say secure boot. But RPMB can also be used for example for restricting the number of PIN attempts. A typical attack vector on phones (I think candybar phones even) was a robot that was punching PIN codes to unlock the phone, combined with an electronic probe that would cut the WE (write enable) signal to the flash right after punching a code. The counter was stored in the flash. (A bit silly example as this can be countered by reading back the counter from flash and checking etc, but you get the idea, various versions of this attack is possible,) With RPMB this can be properly protected against because the next attempt can not be made until after the RPMB monotonic counter has been increased. Of course the system can be compromised in other ways, (like, maybe it doesn't even have secure boot or even no encrypted drive) but this is one of the protection mechanisms that can plug one hole. It is thus a countermeasure to keyboard emulators and other evil hardware trying to brute force their way past screen locks and passwords. Such devices exist, sadly. > 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. You need to pass the symmetric key to increase a counter and store a new "key" (data chunk, 256 bytes). But as you say one can read it without the symmetric key. AFAICT that is not a problem for any use case for RPMB. > 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. Yes, I understand such ambitions may exist and pretty much why I CC the keyring people. So the question is whether they think that is something they would go and use for e.g. passphrase retries. Yours, Linus Walleij
