3 ms·
Yes. If you extract keys, you win the game. I think their best answer is a sort of blacklist system where if Intel becomes aware one of their key has leaked, t
by tux3 5y ago
Yes. If you extract keys, you win the game.
I think their best answer is a sort of blacklist system where if Intel becomes aware one of their key has leaked, their servers could stop telling people it is genuine (this gets into the details of EPID and DCAP that I really don't want to clutter my memory with, so my retelling may be less accurate there)
To prevent the idea with fake certificates, I think you "simply" pin some Intel root certs in your enclave. Do TLS with those, verify the "TCB" cert chain with them too. Then the VM either lets you run on a real CPU and cannot poke your encrypted memory, or it emulates you and this is back to the previous scenario (it owns you locally, but remote attestation fails)
The whole thing that makes SGX interesting and not a boring traditional HSM is remote attestation for secret provisioning, sealing of secrets, etc. This means you in theory run workloads on someone else's computer without having to trust it.
If your secrets are already on the attacker-controlled VM and you only verify things locally, this is useless. Nothing can save you, the VM already owns your entire environment.
- betterunix2 5y agoThere is already a blacklisting/revocation system for leaked SGX keys -- which failed completely when it was put to the test, after researchers tried publishing some keys they extracted on Twitter. However, it depends on Intel becoming aware of a leaked key, which makes perfect sense for the original DRM use-case and makes no sense in the cloud/server/hosting/etc. use-case.