3 ms·

"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'

"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...

Wowfunhappy 4y ago
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.
- no_time 4y ago
  >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.
  - traverseda 4y ago
    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.
    - no_time 4y ago
      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 :^)
- taco9999 4y ago
  The emulated TPM will not contain the TPM manufacturer's private key that is used to sign responses.
  - cesarb 4y ago
    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.
    - wmf 4y ago
      Yeah, Pluton "fixes" this because it's inside the CPU.
  - mindslight 4y ago
    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.
wmf 4y ago
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.
- deleted 4y ago
  [deleted]

Wowfunhappy 4y ago

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.

no_time 4y ago
>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.
- traverseda 4y ago
  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.
  - no_time 4y ago
    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 :^)
taco9999 4y ago
The emulated TPM will not contain the TPM manufacturer's private key that is used to sign responses.
- cesarb 4y ago
  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.
  - wmf 4y ago
    Yeah, Pluton "fixes" this because it's inside the CPU.
- mindslight 4y ago
  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.

wmf 4y ago

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.

deleted 4y ago
[deleted]