Message-ID: <CACRpkdaDtG4Xf0nYnT66C5d8GOwOoqd3=bZ1E3_=osveWo_C5A@mail.gmail.com>
Date:   Wed, 10 Mar 2021 10:33:35 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     David Howells <dhowells@...hat.com>
Cc:     Arnd Bergmann <arnd@...aro.org>, keyrings@...r.kernel.org,
        Jarkko Sakkinen <jarkko@...nel.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>,
        Hector Martin <marcan@...can.st>
Subject: Re: [RFC PATCH 1/5] rpmb: add Replay Protected Memory Block (RPMB) subsystem

On Tue, Mar 9, 2021 at 6:12 PM David Howells <dhowells@...hat.com> wrote:
> Linus Walleij <linus.walleij@...aro.org> wrote:
>
> > As it seems neither Microsoft nor Apple is paying it much attention
> > (+/- new facts) it will be up to the community to define use cases
> > for RPMB. I don't know what would make most sense, but the
> > kernel keyring seems to make a bit of sense as it is a well maintained
> > keyring project.
>
> I'm afraid I don't know a whole lot about the RPMB.  I've just been and read
> https://lwn.net/Articles/682276/ about it.

Sorry, here is a primer on RPMB.

The proper source is the eMMC specification from JEDEC
which has semi-open access:
https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc

The spec is not super helpful because it does not describe what the
intention or use case for RPMB is, just what commands it can be
given.

Western Digital describes the use cases in this whitepaper page 5 ff:
https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/collateral/white-paper/white-paper-emmc-security.pdf

Quote:
"Some well-known use cases include software version
authentication, fingerprint verification, secure key storage,
network vendor information, digital rights management (DRM)
and secure payments."

The replay protected memory block comes from mobile phone
vendors, and it is described as designed for a usecase known
as "anti-rollback": make it impossible to flash an older firmware.
This is achieved by monotonic counters: a hardware counter
that always increases so that if we have software version 13
flashed we can flash version 14 or 15 but not version 10 or 12.
Attackers of mobile phones used the possibility to revert to
old firmware with vulnerabilities as an attack vector.

Messages to the RPMB are protected by a symmetric key
which is 32 bytes long. The hash used in messaging is
HMAC SHA-256.

The symmetric key is written once to initialize the RPMB.
With the current mmc-utils "mmc" command it looks like this:

echo -n AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH | mmc rpmb write-key /dev/mmcblk0rpmb -

The entity writing stuff to RPMB needs to keep track of this
secret. This is why a secure world such as TEE is often using
RPMB, as these usually have access to a protected secret
key, but any trusted environment can use the mechanism.
Compared to TPM, we are on the inside of the chip here,
so the agent dealing with this secret key will be vulnerable.

After this secret has been initialized, protected data blocks of 256
bytes can be written to RPMB while providing the key likt this:

(awk 'BEGIN {while (c++<256) printf "a"}' | echo -n
AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH) | mmc rpmb write-block
/dev/mmcblk0rpmb 0x02 - -

0x02 is the *counter*, so if you after this try to send the message
with 0x01 it will fail, whereas 0x03 will work. That is how the
monotonic counter is specified in the write interactions.

This can be imagined as writing keys 1, 2, 3 ... while you cannot
overwrite an older key you can write the next one in sequence.
Typically this would be the version number of a firmware.
The 256 bytes of data sent along with the key number is
typically the hash of a firmware. But it can be any 256 bytes
of data, RPMB leaves this up to whoever implements it.

You can also read chunks of 256 bytes from the device:
echo -n AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH | mmc rpmb read-block
/dev/mmcblk0rpmb 0x02 1 /tmp/block -

(0x02 again is the key index, 1 is the number of blocks/keys
we want to read)

This protocol is challenge-response so a random session key
will be used along with the MAC for authentication.

It is possible to read a key without authentication. I don't know
what the use case of this would be:

mmc rpmb read-block /dev/mmcblk0rpmb 0x02 1 /tmp/block

RPMB is a multiple of 128KB of key storage. Most typically
it is that size, so 128KB/256 = 512 unique keys can be
written in most standard parts.

> What is it you envision the keyring API doing with regard to this?
> Being used to represent the key needed to access the RPMB or
> being used to represent an RPMB entry (does it have entries?)?

The idea is to have an API toward RPMB that keyring can
use to store replay protection or other monotonic sequence
information. Only one party can hold the authentication key
so I guess both.

The most intuitive use case is protecting against exhaustive
password/pin/fingerprint/other authentication token search.

On mobile phones it is used to establish that 3 attempts is really
3 attempts, then your device is locked, for example. Doesn't
have to be 3. Can be 500. But to put a cap on it.

Also a time stamp from a monotonic clock can be stored in
RPMB so that the increasing time between unlock attempts
is enforced and cannot be manipulated. This requires
secure, monotonic time (which can be achieved in various
ways).

Is this something keyring does today, or would be doing
in the future? (Sorry for my ignorance...)

The original use case of being unable to install older
software can also be done, but since Linux distributions
generally support installing older packages I don't think
this is going to be requested much, maybe Chromebooks
and Androids would appreciate to do that through this
mechanism though?

Yours,
Linus Walleij

Powered by blists - more mailing lists