Message-ID: <d7f8a732-7a44-f609-52dc-3ba824a3d192@marcan.st>
Date:   Fri, 12 Mar 2021 05:02:22 +0900
From:   Hector Martin <marcan@...can.st>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     David Howells <dhowells@...hat.com>,
        "open list:ASYMMETRIC KEYS" <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 11/03/2021 23.06, Linus Walleij wrote:
> Yes. And this is what mobile phone vendors typically did.
> 
> But the nature of different electrical attacks made them worried
> about different schemes involving cutting power and disturbing
> signals with different probes, so they wanted this counter
> implemented in hardware and that is why RPMB exists at all
> (IIUC).

No, prior to RPMB there was no such secure counter at all. The problem 
is that non-volatile erasable storage (i.e. EEPROM/Flash) is 
incompatible with modern SoC manufacturing processes, so there is no way 
to embed a secure counter into the main SoC. And once your counter needs 
to be external, there needs to be a secure communications protocol to 
access it. This is what RPMB implements.

For preventing software downgrades, especially of bootloader code, this 
can be implemented with one-time fuses embedded in the SoC, but there is 
a limited supply of those. So this doesn't work for things like PIN 
attempt counters. For that you need a secure external counter.

> It is fine to be of the opinion that this entire piece of hardware
> is pointless because the same can be achieved using
> well written software.

You've misunderstood me. RPMB isn't pointless; what I am saying is that 
if you strip away everything but the counter functionality, you can 
still build equivalent security guarantees. You still need the counter. 
There is no way to get that counter without RPMB or something like it 
(another option is e.g. to use a smartcard IC as a secure element; AIUI 
modern Apple devices do this). Software alone doesn't work. This is why 
I wrote that article about how the FBI cracks iPhones; that works 
because they weren't using a secure rollback-protected storage/counter 
chip of any kind.

> The position that the kernel community shall just ignore this
> hardware is a possible outcome of this discussion, but we need
> to have the discussion anyway, because now a RPMB framework
> is being promoted. The people who want it will need to sell it to
> us.

Again, you're kind of misunderstanding me here. I'm not saying the 
feature is useless. What I'm saying is that, to understand *how* it is 
useful, it helps if you forget about the read/write commands and treat 
it as a simple counter.

Once you do that, you'll realize that e.g. putting keys in RPMB doesn't 
really make sense as a kernel primitive. The usefulness of RPMB is 
purely in the integration of that counter (which is equivalent to 
rollback-protected storage) with a policy system. Everything else is 
icing on the cake; it doesn't create new use cases.

Consider this:

* You have RPMB, but you will use it as a counter only.
* To use RPMB, you need to have a secure shared key.
* You use the RPMB key (or a hash, or whatever) to encrypt a GPG key in 
your filesystem
* You have a Git repo. This is your secure rollback-protected storage.
* We assume the filesystem can be potentially read, written, and 
intercepted.

To read from your rollback-protected storage, you:

* Read the RPMB counter securely
* Fetch the Git tag named "v%d" with the counter value
* Ensure the Git tag is correctly signed with your secure GPG key
* Ensure the commit description of the signed commit is also "v%d"

To write to your rollback protected storage, you:

* Commit your changes to the repository (as a child of the current known 
good commit, which you know is secure via the prevous read process) with 
the commit message "v%d" with the counter value + 1
* Tag it "v%d" with the current counter value + 1, signing the tag with 
your GPG private key
* Ensure all changes are flushed to disk
* Perform an increment operation on the RPMB counter

You have now built a secure, rollback-protected Git repository, with 
similar security properties to RPMB storage, without using RPMB storage; 
just a counter.

Just like RPMB storage, the repo is readable without a key.
Just like RPMB storage, you need to have a secured master key stored 
somewhere; if the attacker gets your key it is game over.
Just like RPMB storage, the repo can only be updated (in a way that 
would be accepted) with the key available
Just like RPMB storage, the repo cannot be rolled back to a prior 
version (because it would not match the counter value)

Thus, we can conclude that the storage features of RPMB do not provide 
additional security properties that cannot be derived from a simple counter.

* Disclaimer: please don't actually deploy this; I'm trying to make a 
point here, it's 5AM and I'm not claiming this is a perfectly secure 
design and I haven't missed anything. Please don't design 
rollback-protected Git repositories without expert review. I am assuming 
filesystem mutations only happen between operations and handwaving away 
active attacks, which I doubt Git is designed to be robust against. A 
scheme like this can be implemented securely with care, but not naively.

>>> 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.
>>
>> But this is only enforced by software. If you do not have secure boot,
>> you can just patch software to allow infinite tries without touching the
>> RPMB. The RPMB doesn't check PINs for you, it doesn't even gate read
>> access to data in any way. All it does is promise you cannot make the
>> counter count down, or make the data stored within go back in time.
> 
> This is true, I guess the argument is something along the
> line that if one link in the chain is weaker, why harden
> any other link, the chain will break anyway?

This is how security works, yes :-)

I'm not saying hardening a link in the chain is pointless in every case, 
but in this case it's like heat treating one link in the chain, then 
joining it to the next one with a ziptie. Only once you at least have 
the entire chain of steel does it make sense to start thinking about 
heat treatment.

> I am more of the position let's harden this link if we can
> and then deal with the others when they come up, i.e.
> my concern is this piece of the puzzle, even if it is not
> the centerpiece (maybe the centerpiece is secure boot
> what do I know).

Well, that's what I'm saying, you do need secureboot for this to make 
sense :-)

RPMB isn't useless and some systems should implement it; but there's no 
real way for the kernel to transparently use it to improve security in 
general (for anyone) without the user being aware. Since any security 
benefit from RPMB must come from integration with user policy, it 
doesn't make sense to "well, just do something else with RPMB because 
it's better than nothing"; just doing "something" doesn't make systems 
more secure. There needs to be a specific, practical use case that we'd 
be trying to solve with RPMB here.

-- 
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub

Powered by blists - more mailing lists