lkml.org 
[lkml]   [2021]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC PATCH 1/5] rpmb: add Replay Protected Memory Block (RPMB) subsystem
    Date
    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@marcan.st)
    Public Key: https://mrcn.st/pub

    \
     
     \ /
      Last update: 2021-03-11 21:04    [W:2.490 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site