4 ms·

I think that every design that relies on trusted hardware needs to be much more up front about it (e.g., put it in the title) so the paper can be less disappoin

I think that every design that relies on trusted hardware needs to be much more up front about it (e.g., put it in the title) so the paper can be less disappointing. I don't understand academia's obsession with these security theater devices -- it would make sense to see it in industry as a hyped buzzword, but I think it makes for weak scholarship. edit: as some note below, it is a TEE not a TPM or a SE. I don't think the distinction should distract from the point, so I have amended above.

munchbunny 8y ago
What makes TPM's security theater? Also where does it say TPM? The paper references Intel SGX and ARM TrustZone, which to my knowledge are both on-CPU, whereas TPM's generally sit separately on the motherboard.
- jlrubin 8y ago
  I don't think the distinction matters that much in this context, so I amended above. I think they're theater because they do something complicated with ambiguous security benefits. And even if they are used correctly, flaws in the designs like spectre/meltdown/foreshadow/rowhammer/etc etc compromise these use cases.
  - deleted 8y ago
    [deleted]
  - Certhas 8y ago
    Because the secret is never in memory, wouldn't it exactly be safe against all the attacks you mention?
    - jlrubin 8y ago
      Not quite -- for example, the way that registers are implemented in modern processors is super complex. Here's a sketch of an attack against this: the registers don't actually get overwritten they get renamed in modern CPUs. That means the old data is still there, just not logically accessible by non-pipelined instructions. It's possible the data is still sitting in the registers, with an old epoch name. The predictors will be predicting branches and other things based on those registers. So by issuing the right instruction and measuring delay, you might be able to create an oracle to see if you guess a byte correctly from the stale data. I also don't think the secrets are actually out of memory, they are out of your memory, where your is the kernel and the user space but not necessarily the TEE Secure World memory. This is, of course, the same RAM but protected by a page table. """ To ensure code integrity the kernel page table is made read-only at boot time. The kernel is modified to send a request to GService whenever it needs to modify the page table, GService honours this request only when doing so would not result in mapping the code pages of a sensitive function. The kernel is also prevented from overwriting its page table base register so that it can’t swap the table with a compromised one. """ Of course, this sounds like the perfect kind of attack for rowhammer to break. Just overwrite the page table by doing reads and then overwrite a sensitive function after it's been invoked once and approved, and now you can leak secrets out that way. etc
    - munchbunny 8y ago
      You could accomplish that with the TPM but not TEE. But with the TPM you'd have to trust the OS when you generated the secret, so what's to say that the OS isn't already compromised?
subway 8y ago
This paper doesn't mention anything about TPM. It mentions TEE (TrustZone, really) and SGX. TPM is effectively a smart card hanging off a system bus, usually on a separate package. SGX and TrustZone are CPU features enabling a "secure" run time environment separate from the main run time env.

munchbunny 8y ago

What makes TPM's security theater? Also where does it say TPM? The paper references Intel SGX and ARM TrustZone, which to my knowledge are both on-CPU, whereas TPM's generally sit separately on the motherboard.

jlrubin 8y ago
I don't think the distinction matters that much in this context, so I amended above. I think they're theater because they do something complicated with ambiguous security benefits. And even if they are used correctly, flaws in the designs like spectre/meltdown/foreshadow/rowhammer/etc etc compromise these use cases.
- deleted 8y ago
  [deleted]
- Certhas 8y ago
  Because the secret is never in memory, wouldn't it exactly be safe against all the attacks you mention?
  - jlrubin 8y ago
    Not quite -- for example, the way that registers are implemented in modern processors is super complex. Here's a sketch of an attack against this: the registers don't actually get overwritten they get renamed in modern CPUs. That means the old data is still there, just not logically accessible by non-pipelined instructions. It's possible the data is still sitting in the registers, with an old epoch name. The predictors will be predicting branches and other things based on those registers. So by issuing the right instruction and measuring delay, you might be able to create an oracle to see if you guess a byte correctly from the stale data. I also don't think the secrets are actually out of memory, they are out of your memory, where your is the kernel and the user space but not necessarily the TEE Secure World memory. This is, of course, the same RAM but protected by a page table. """ To ensure code integrity the kernel page table is made read-only at boot time. The kernel is modified to send a request to GService whenever it needs to modify the page table, GService honours this request only when doing so would not result in mapping the code pages of a sensitive function. The kernel is also prevented from overwriting its page table base register so that it can’t swap the table with a compromised one. """ Of course, this sounds like the perfect kind of attack for rowhammer to break. Just overwrite the page table by doing reads and then overwrite a sensitive function after it's been invoked once and approved, and now you can leak secrets out that way. etc
  - munchbunny 8y ago
    You could accomplish that with the TPM but not TEE. But with the TPM you'd have to trust the OS when you generated the secret, so what's to say that the OS isn't already compromised?

subway 8y ago

This paper doesn't mention anything about TPM. It mentions TEE (TrustZone, really) and SGX. TPM is effectively a smart card hanging off a system bus, usually on a separate package. SGX and TrustZone are CPU features enabling a "secure" run time environment separate from the main run time env.