|
|
|
|
|
by achamayou
2254 days ago
|
|
I’m not sure why you think that SGX shows hardware enclaves “don’t work”. I also don’t see why you think enclaves “protect the malware from you”. Enclaves are created and started from host code, which can interrupt or terminate them at any time. The scheme you suggest, which isn’t typically how TrustZone is used, gives zero integrity and confidentiality guarantees for applications. I don’t know if it’s “the right way” for some threat model, but for the most typical TEE use cases which are trying to establish strong integrity and confidentiality guarantees in the presence of an untrusted host, it’s absolutely not right nor useful. |
|
Enclaves are started from host code, but host code can't see into them. In other words you have no way of telling whether the enclave you've started is what you wanted, or if it includes malware.
The scheme I've described does give integrity - after all, that's precisely how the actual trusted components work, SecureEnclave, TEE etc: you have a trusted hypervisor, and then run your secure components outside the untrusted OS, in a trusted environment in that trusted hypervisor. It gives you everything SGX could, without its fundamental design problems.