Message-ID: <32bdceb1-e70d-7481-96e3-a064a7108eb9@marcan.st>
Date:   Thu, 11 Mar 2021 18:22:41 +0900
From:   Hector Martin <marcan@...can.st>
To:     Linus Walleij <linus.walleij@...aro.org>
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 11/03/2021 09.36, Linus Walleij wrote:
>> 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.

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

Basically what I'm saying is that for security *guarantee* purposes, 
AFAICT the storage part of RPMB makes no difference. It is useful in 
practical implementations for various reasons, but if you think you can 
use that secure storage to provide security properties which you 
couldn't do otherwise, you are probably being misled. If you're trying 
to understand what having RPMB gets you over not having it, it helps if 
you ignore all the storage stuff and just view it as a single secure, 
increment-only counter.

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

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.

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

This is hot how security systems are designed though; you do not "plug 
holes", what you do is cover more attack scenarios, and you do that in 
the order from simplest to hardest.

If we are trying to crack the PIN on a device we have physical access 
to, the simplest and most effective attack is to just run your own 
software on the machine, extract whatever hash or material you need to 
validate PINs, and do it offline.

To protect against that, you first need to move the PIN checking into a 
trust domain where an attacker with physical access can't easily break 
in, which means secure boot.

*Then* the next simplest attack is a secure storage rollback attack, 
which is what I described in that blog post about iOS. And *now* it 
makes sense to start thinking about the RPMB.

But RPMB alone doesn't make any sense on a system without secure boot. 
It doesn't change anything; in both cases the simplest attack is to just 
run your own software.

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

If you're trying to protect against a "dumb" attack with a keyboard 
emulator that doesn't consider access to physical storage, then you 
don't need RPMB either; you can just put the PIN unlock counter in a 
random file.

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

Powered by blists - more mailing lists