4 ms·

Nah. If it can be fixed with a microcode update it's not the end of the world.

lxgr 6y ago
Definitely not the end of the world, but the utility of a trusted computing implementation depends a lot on the track record of actually being one, and SGX's isn't exactly great.
- uluyol 6y ago
  To be honest, you could say the same about SSL/TLS, browsers, and (probably) virtualization. Secure enclaves are new. It takes time to develop new technologies and work out all the issues. I probably wouldn't trust my data to SGX today, but I'm not opposed to it as an idea. In 5-10 years it may be in a reasonable state.
  - yjftsjthsd-h 6y ago
    If we had a heartbleed every month, then I'd be rethinking whether I want to trust anything to TLS, yes. Browsers are awful, and tolerable only because they provide so much value (and even then, I overwhelmingly only run a browser with extra mitigations in place). And no, virtualization probably shouldn't be trusted against hostile code.
    - pjmlp 6y ago
      As long as we rely on languages like C for our foundations, we will have them, just not always on TLS, that is why it is so relevant to push for better foundations, even when most of us aren't doing systems programming.
rcxdude 6y ago
If you're relying on it for remote attestation (which is what signal is doing) it's not any use for that, because you have no real verification that the microcode has been updated.
- ENOTTY 6y ago
  In SGX, you do have verification that the microcode has been updated. This is known as the CPUSVN value, it is part of the SGX report that gets issued, and mixed into the keys used to sign reports.
  - pstrateman 6y ago
    Except this attack extracted the attestation keys, so I can attest to any version of the microcode that I want. (Even ones that don't exist).
    - ENOTTY 6y ago
      This attack did not extract the root attestation secret or sealing secret, both stored in CPU fuses. Instead, this attack extracted the sealing and attestation keys stored by the current version of Intel's Quoting Enclave under the current microcode revision (and presumably all previous microcode revisions). Assuming Intel fixes the vulnerability in the next revision of microcode (lets call it Rev H), the Quoting Enclave will need to generate and/or store new attestation keys. Because the root secrets were not leaked AND the microcode revision has revved forward, these cannot be derived under previous microcode revisions. Thus, they are assumed not to be available to the attacker under the SGXAxe/Cacheout vulnerabiilty. Intel generates or provides access to new public keys that correspond to the attestation keys. You use these to verify the Quoting Enclave's attestations. Intel additionally asserts that these new public keys will only verify attestations created by the Quoting Enclave running under Rev H of the microcode. You must determine whether to trust this assertion.
- anonymousDan 6y ago
  Nope. Microcode updates bump the CPU security version number I believe and incorporate that into the attestation, i.e. you can only accept attestations from machines with a certain SVN.

lxgr 6y ago

Definitely not the end of the world, but the utility of a trusted computing implementation depends a lot on the track record of actually being one, and SGX's isn't exactly great.

uluyol 6y ago
To be honest, you could say the same about SSL/TLS, browsers, and (probably) virtualization. Secure enclaves are new. It takes time to develop new technologies and work out all the issues. I probably wouldn't trust my data to SGX today, but I'm not opposed to it as an idea. In 5-10 years it may be in a reasonable state.
- yjftsjthsd-h 6y ago
  If we had a heartbleed every month, then I'd be rethinking whether I want to trust anything to TLS, yes. Browsers are awful, and tolerable only because they provide so much value (and even then, I overwhelmingly only run a browser with extra mitigations in place). And no, virtualization probably shouldn't be trusted against hostile code.
  - pjmlp 6y ago
    As long as we rely on languages like C for our foundations, we will have them, just not always on TLS, that is why it is so relevant to push for better foundations, even when most of us aren't doing systems programming.

rcxdude 6y ago

If you're relying on it for remote attestation (which is what signal is doing) it's not any use for that, because you have no real verification that the microcode has been updated.

ENOTTY 6y ago
In SGX, you do have verification that the microcode has been updated. This is known as the CPUSVN value, it is part of the SGX report that gets issued, and mixed into the keys used to sign reports.
- pstrateman 6y ago
  Except this attack extracted the attestation keys, so I can attest to any version of the microcode that I want. (Even ones that don't exist).
  - ENOTTY 6y ago
    This attack did not extract the root attestation secret or sealing secret, both stored in CPU fuses. Instead, this attack extracted the sealing and attestation keys stored by the current version of Intel's Quoting Enclave under the current microcode revision (and presumably all previous microcode revisions). Assuming Intel fixes the vulnerability in the next revision of microcode (lets call it Rev H), the Quoting Enclave will need to generate and/or store new attestation keys. Because the root secrets were not leaked AND the microcode revision has revved forward, these cannot be derived under previous microcode revisions. Thus, they are assumed not to be available to the attacker under the SGXAxe/Cacheout vulnerabiilty. Intel generates or provides access to new public keys that correspond to the attestation keys. You use these to verify the Quoting Enclave's attestations. Intel additionally asserts that these new public keys will only verify attestations created by the Quoting Enclave running under Rev H of the microcode. You must determine whether to trust this assertion.
anonymousDan 6y ago
Nope. Microcode updates bump the CPU security version number I believe and incorporate that into the attestation, i.e. you can only accept attestations from machines with a certain SVN.