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 09.49, Linus Walleij wrote:
> The use case for TPM on laptops is similar: it can be used by a
> provider to lock down a machine, but it can also be used by the
> random user to store keys. Very few users beside James
> Bottomley are capable of doing that (I am not) but they exist.
> https://blog.hansenpartnership.com/using-your-tpm-as-a-secure-key-store/

I've used a TPM as an SSH key keystore in the past (these days I use
YubiKeys, but same idea). TPMs are useful because they *do* implement
policy and cryptographic operations. So you can, in fact, get security
guarantees out of a TPM without secureboot.

For example, assuming the TPM is secure, it is impossible to clone an
SSH key private key managed by a TPM. This means that any usage has to
be on-device, which provides inherent rate-limiting. Then, the TPM can
gate access to the key based on a passphrase, which again provides
inherent rate-limits on cracking attempts. TPM 2.0 devices also provide
explicit count limits and time-based throttling for unlocking attempts.

We have much the same story with the Secure Enclave Processor on Apple
Silicon machines (which I'm working on porting Linux to) - it provides
policy, and can even authenticate with fingerprints (there is a hardware
secure channel between the reader and the SEP) as well as passphrases.
For all intents and purposes it is an Apple-managed TPM (with its own
secureboot). So it is similarly useful for us to support the SEP for key
storage, and perhaps even integrate it with kernel subsystems at some
point. It's useful for our regular users, even though they are unlikely
to be running with full secureboot on the main CPU (though Apple's
implementation does allow for a user-controlled secureboot subset, and
it should be possible to provide hard guarantees there as well, but I
digress).

All of these things make putting keys into TPMs, YubiKeys, the SEP, etc
a useful thing for anyone, regardless of whether their machine is locked
down or not.

This is not the case for RPMB. RPMB *relies* on the software running on
the other side being trusted. RPMB, alone, provides zero new security
guarantees, without trusted software communicating with it.

The key initialization story is also a lot thornier in RPMB. TPMs, the
SEP, and YubiKeys are all designed so that they can be factory-reset
(losing all key material in the process) by a user with physical access,
which means that provisioning operations and experiments are risk-free,
and the only danger is data loss, not making the hardware less useful.
With the MAC key provisioning for RPMB being a one-time process, it is
inherently a very risky operation that a user must commit to with great
care, as they only get one chance, ever. Better have that key backed up
somewhere (but not somewhere an attacker can get to... see the
problem?). This is like fusing secureboot keys on SoCs (I remember being
*very* nervous about hitting <enter> on the command to fuse a Tegra X1
board with a secureboot key for some experiments... these kinds of
irreversible things are no joke).

Basically, TPMs, SEP, YubiKeys, etc were designed to be generally useful
and flexible devices for various crypto and authentication use cases.
RPMB was designed for the sole purpose of plugging the secure storage
replay exploit for Android phones running TrustZone secure monitors. It
doesn't really do anything else; it's just a single low-level primitive
and you need to already have an equivalent design that is only missing
that piece to get anything from it. And its provisioning model assumes a
typical OEM device production pipeline and integration with CPU fusing;
it isn't friendly to Linux hackers messing around with securing LUKS
unlock attempt counters.

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

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