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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx)
Public Key: https://mrcn.st/pub



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux