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
