zlacker

"Hardware-based attestation of the running software is an important security feature"

I understand the mechanics in a "lies to children" way but who exactly is attesting what? Let's face it: MS isn't going to compensate me for a perceived flaw in ... why am I even finishing this sentence?

I recently bought some TPM 2.0 boards for my work VMware hosts so I could switch on secure boot and "attestation" for the OS. They are R630s which have a TPM 1.2 built in but a 2.0 jobbie costs about £16.

I've ticked a box or three on a sheet but I'm not too sure I have significantly enhanced the security of my VMware cluster.

>>gerdes+(OP)
"Attestation" of a VM is such a fraught concept... Isn't whole idea of virtualization, to outright lie to the "guest" operating system?

Yes, dear Windows, you're running on a dual-core Xeon Gold 6326 with i440BX chipset. Don't ask how this is possible, just trust me...

>>gerdes+(OP)
Implemented properly, the idea is that you have a chain of certificates (rooted by the CPU vendor's public key) that can identify all the different bits of software that have executed on the machine, along with a ephemeral public key. The hardware guarantees that the associated private key can only be wielded by the software versions that the chain attested to. So when you initiate your TLS connection with this machine, you can validate the cert chain and understand exactly what software the machine is running, assuming that you trust the CPU vendor and all the versions of the software that were attested to.

>>nouser+z2
And so isn't this basically the flaw in the whole idea? You can always emulate a TPM. You can always boot with a stock kernel and have the host patch the memory afterwards. Software can try to detect whether it's running in a VM, but the VM can lie. Last I heard, blocking VMs didn't go so well when nVidia tried it.

Am I wrong about the effectiveness of this? I'll readily admit I don't understand most of the underlying tech here.

>>fleven+93
> … assuming that you trust the CPU vendor and all the versions of the software that were attested to.

That’s a huge caveat.

You also cannot verify your trust is deserved, and that it will continue to be deserved, because such a system by its very nature must be opaque to untrusted parties (which means you).

>>nouser+z2
The hardware attests the hypervisor, the hypervisor attests the OS, the OS attests the app, etc. It all works as long as you chain down to the unique key in hardware.

>>Wowfun+w3
>Am I wrong about the effectiveness of this?

Partially. For online attestation you'd be missing the most important part. The vendor signed keypair that is insanely hard to extract from the device.

>>Wowfun+w3
The emulated TPM will not contain the TPM manufacturer's private key that is used to sign responses.

>>teaket+R3
such a system by its very nature must be opaque to untrusted parties

No, you can attest to a completely open source system. Nobody's actually doing that, but it's possible. The private keys have to be secret and non-extractable, but that's it.

>>wmf+p4
The fundamental security mechanism upon which the entire system hinges is opaque.

>>wmf+p4
Plenty of people do it. I use tpm2-totp for it. There is a key sealed in my TPM, that will only unseal for known boot stacks (firmware/bootloader/kernel). I have the same key stored in my Yubikey's TOTP application. After boot I can verify my stack by comparing a TOTP code generated by my Yubikey with one generated by the TPM.

Caveat is that security only extends into the kernel image, so for my use case I embed the initrd in the kernel image and have all the filesystems and swap on a dm-crypt volume.

I also have to unseal and reseal when performing upgrades of the initramfs and above, but I'm fine with that.

>>no_tim+f4
I'll extract them for 40k a pop all day long. I've got the hardware in storage from an old contract. Side channel power analysis is fun.

>>traver+x5
lol If I had USA money I'd go for it for 40k.

I've read once about the hardware tricks DRM dongles use in the silicon itself. Doesn't sound like a 40 job :^)

>>taco99+l4
Which is why the comment which started this sub-thread mentioned buying extra physical TPM 2.0 chips. They contain the correct keys, and since they're external devices, it's trivial to lie to them, pretending to be the physical CPU doing a normal boot.

Of course, that only works until they start rejecting external TPM chips, and accepting only the built-in "firmware" TPMs found in more recent CPUs.

>>cesarb+xd
Yeah, Pluton "fixes" this because it's inside the CPU.

>>blkfnw+i5
> After boot I can verify my stack by comparing a TOTP code generated by my Yubikey with one generated by the TPM.

But if you're not sure whether the system booted cleanly, then it might be compromised. If it's compromised couldn't your tools simply lie about the codes generated by both the TPM and the Yubikey so that they always match?

>>wmf+p4
Yes. Intel is willing to lend me all the equipment and logic analyzers I need to analyze their products, access to their internal design docs, access to their engineering team to answer my questions, etc, etc...

Do you realize how daft and unrealistic your assertion is?

Tell ya what. You get Broadcom, Intel, AMD, Nvidia, etc... to go full transparent, and we'll talk.

>>taco99+l4
nit: the TPM contains its own internally-generated private key. That private key never leaves the TPM, and has nothing intrinsic to the manufacturer.

The manufacturer then signs the public portion of that TPM key, creating the ability for everyone to assert that said key was generated internal to their hardware (and thus couldn't be used by an emulator).

You yourself could also sign the public portion of the TPM key, or even generate a new one and sign it, but that wouldn't affect the perverse incentive generated by the manufacturer's assertion. It would just enable you to assert that you trust the TPM key is internal to the TPM without trusting the manufacturer's records.

We're dealing with something like the dual of software signing here.