zlacker

[return to "Remote Attestation is coming back"]
1. fleven+Lb[view] [source] 2022-07-29 23:59:09
>>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.

◧◩
2. gerdes+2d[view] [source] 2022-07-30 00:13:42
>>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.

◧◩◪
3. nouser+Bf[view] [source] 2022-07-30 00:45:02
>>gerdes+2d
"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...

◧◩◪◨
4. Wowfun+yg[view] [source] 2022-07-30 00:57:42
>>nouser+Bf
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.

◧◩◪◨⬒
5. taco99+nh[view] [source] 2022-07-30 01:05:51
>>Wowfun+yg
The emulated TPM will not contain the TPM manufacturer's private key that is used to sign responses.
◧◩◪◨⬒⬓
6. mindsl+3k1[view] [source] 2022-07-30 15:11:26
>>taco99+nh
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.

[go to top]