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