zlacker

>>gjsman+(OP)
Unpopular opinion:

Hardware-based attestation of the running software is an important security feature, especially in a world where data leaks and identity theft are rampant. Let's say I'm a healthcare provider, and I'm about to send sensitive medical data to a third party vendor. Wouldn't you prefer that this data only be able to be decrypted by a computer that can prove to the world it booted a clean OS image with all the latest security patches installed?

If the vendor wants to install some self-built OS that they trust on their computer and not update it for 5 years, that's their business, but I may not want to trust their computer to have access to my personal data.

Remote attestation gives more control to the owners of data to dictate how that data is processed on third-party machines (or even their own machines that may have been compromised). This is useful for more than just DRM.

>>fleven+Lb
"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+2d
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.

>>fleven+bg
> … 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).

>>teaket+Tg
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+rh
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.