Secure elements are a nice way to supplement baseline privacy/security. The design should work without it. Changing your design due to having a secure element is problematic. Encouraging a weak PIN when you would have otherwise wanted a strong passphrase is a problem.
Conversation
SGX is not even a proper secure element. Also, same thing applies to attestation which can be a nice supplemental security check. Trying to use it to securely run code on adversary controlled hardware, even with a real secure element, just seems incredibly foolish and misguided.
Replying to
Attestation is also not all created equal. A pairing-based system for attestation is not comparable to verification based on a root of trust. An attacker can choose the oldest least secure hardware with no firmware updates applied and use that to bypass root-of-trust attestation.
1
1
If you're verifying attestations based on a root of trust, you're relying on the security of all hardware doing attestation with keys chaining to that root of trust. Attacker doesn't need to exploit the specific hardware you chose. Great for anti-cheat, etc. not strong security.
1
3
I think attestation is a useful security feature, but designed around a pairing-based model. A root of trust isn't useful once a pairing is established. This might not work well for this kind of server code verification since the app would need to whitelist a key for each server.
2