linux-kernel - Re: [RFC PATCH 1/5] rpmb: add Replay Protected Memory Block (RPMB) subsystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdZ_-rqGBUOxUcBPeqVkLzX=Q9pjO9M+zY20-S9tNXAE0Q@mail.gmail.com>
Date:   Thu, 11 Mar 2021 15:06:57 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Hector Martin <marcan@...can.st>
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 Thu, Mar 11, 2021 at 10:22 AM Hector Martin <marcan@...can.st> wrote:
> On 11/03/2021 09.36, Linus Walleij wrote:

> > 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.
>
> Yes, but to implement that you don't need any secure storage *at all*.
> If all the RPMB did was authenticate an incrementing counter, you could
> just store the <last timestamp, attempts remaining> tuple inside a blob
> of secure (encrypted and MACed) storage on any random Flash device,
> along with the counter value, and thus prevent rollbacks that way (some
> finer design points are needed to deal with power loss protection and
> ordering, but the theory holds).

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).

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.

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.

> > 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?

(The rest of your message seems to underscore this
position.)

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).

Yours,
Linus Walleij