Re: [gentoo-user] New Intel vulnerability?

[Rich Freeman]

On Fri, Mar 6, 2020 at 3:55 PM Wols Lists <antlists@××××××××××××.uk> wrote:
>
> On 06/03/20 19:39, Rich Freeman wrote:
> >
> > They don't detail the effort required.  If the firmware is patched it
> > sounds like it still requires tinkering with hardware.
>
> By then it's TOO LATE. The firmware is signed for security, AND LOADED
> AT BOOT. But if the boot process is compromised, the attacker simply
> doesn't load the patched firmware.

The patched firmware executes before any software you boot, assuming
your device was patched before the hacker got his hands on it.

Obviously if you lost your laptop last week and the hacker has it in
their closet, then they're going to be able to attack the unpatched
firmware with a software hack.

From the descriptions I'm seeing it sounds like the attack against the
hardware itself requires physical access to some of the busses.  A
proper TPM should resist this sort of attack, and that is why this is
a vulnerability.  However, you can't just stick a USB drive into a
computer to hack it if the firmware is patched.

> >
> > Yes, but keep in mind the signing keys have nothing to do with disk
> > encryption.  It is for remote attestation.  Hence my Netflix comment.
> >
> Signing keys have EVERYTHING to do with whether you can trust the CPU.
> If you can't trust the CPU, then it can simply read the disk encryption
> credentials without any reference to whether it SHOULD read them.

So, I think you're conflating a few different things here.

First, trust is a choice you make.  Whether you trust the CPU or not
makes no difference in whether somebody else can defeat the embedded
TPM.

Second, the signing keys we're talking about are keys embedded in the
CPU used by the CPU to sign stuff.  These keys aren't used for
encrypting anything, and they aren't used for decrypting anything.
They're also not used to verify firmware/etc.  It would make no sense
to put the firmware signing key in the CPU - that key would be locked
up at the firmware vendor's HQ with the corresponding public key
embedded in the CPUs.

Don't get me wrong - encryption keys stored in the CPU are compromised
by this vulnerability.  However, this has nothing to do with the
signing keys.

I suspect that modifying the firmware might also be possible due to
this vulnerability, by replacing the public key in the CPU with a new
one that you generated.  Again, that has nothing to do with the
signing keys on the CPU.

The signing keys should just be associated with remote attestation.

> And it only takes ONE person to crack that master key ONCE, and
> EVERYBODY is up shit creek.

No - there isn't any master key stored inside an Intel CPU that can be
used to compromise the encryption on other hosts.  We're talking about
the signing keys used for remote attestation.

Again, Netflix and Intel and similar companies are going to be ticked
if that master key is leaked, but it won't have any impact on disk
encryption.

Of course, disk encryption is still compromised by the vulnerability.
It just has nothing to do with the master signing keys (which are also
model-specific and not completely universal), and hacking any
individual device, if patched, will probably still require a
hardware-level attack against that specific device.

> At the end of the day, it's a "tree of trust". And once the root key is
> compromised, you can NOT trust ANY key that was secured by said root
> key.

Yup.  Fortunately the disk encryption keys are unique to each device,
and stored in the compromised TPM hardware.  They aren't really
secured by a root key in any meaningful way.

-- 
Rich