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