Message-ID: <CACRpkda9f-BNmu-CaNsghnDoOcSXvvvji=tag2Xos+tg_nNZ0w@mail.gmail.com>
Date:   Thu, 11 Mar 2021 01:36:39 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Hector Martin <marcan@...can.st>
Cc:     David Howells <dhowells@...hat.com>, keyrings@...r.kernel.org,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Sumit Garg <sumit.garg@...aro.org>,
        Arnd Bergmann <arnd@...aro.org>,
        Joakim Bech <joakim.bech@...aro.org>,
        Alex Bennée <alex.bennee@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Maxim Uvarov <maxim.uvarov@...aro.org>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Ruchika Gupta <ruchika.gupta@...aro.org>,
        "Winkler, Tomas" <tomas.winkler@...el.com>, yang.huang@...el.com,
        bing.zhu@...el.com, Matti.Moell@...nsynergy.com,
        hmo@...nsynergy.com, linux-mmc <linux-mmc@...r.kernel.org>,
        linux-scsi <linux-scsi@...r.kernel.org>,
        linux-nvme@...r.kernel.org, Ulf Hansson <ulf.hansson@...aro.org>,
        Arnd Bergmann <arnd.bergmann@...aro.org>
Subject: Re: [RFC PATCH 1/5] rpmb: add Replay Protected Memory Block (RPMB) subsystem

On Wed, Mar 10, 2021 at 2:52 PM Hector Martin <marcan@...can.st> 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

Powered by blists - more mailing lists