| I may not be fully understanding your scenario but it sounds like A needs to prove to B that it knows a secret but doesn't want to actually reveal/send the secret to B? And the idea, therefore, is that A sends the secret to an enclave, which inspects the secret and, if correct, signs a message to say "I, the enclave, have verified that A does indeed know the secret". (Apologies if I've oversimplified or got this wrong). But assuming the above is roughly correct then, without remote attestation, you have a problem, and it comes down to the question of who's running the verification code, I think. If A is running the checker, why should B believe what it says? If A is running the code, they can just change it so that it signs the statement irrespective of whether it's true. But If B is running the checker, then A will have just sent their secret to a service run by B, violating the requirement that A doesn't send the secret to B! You could ask a third party to run it of course. But if you don't want to introduce that third party then this is where remote attestation comes in: If A is running the checker in an enclave then RA allows B to verify that the "A knows the secret" message really did come from a codepath that has actually done the right thing. In this scenario, B is the "user" of the enclave from the perspective of reliance on Remote Attestation. (Aside: I know it's weird to think of an actor that doesn't interact with a system to be a user of it, so I'm probably using poor terminology when I say 'user'... it's more that, in this scenario, B is _relying_ on properties of the enclave such as its attestation) And if B is running the checker then RA allows A to verify that it won't just turn around and reveal the secret to B. |
The secret never leaves the enclave.
The goal here is that if an attacker can execute code within A's operating system that they can not exfiltrate the password. They might be able to get the enclave to sign on their behalf, but that's significantly better than an exposed secret - simply removing the attacker from the box would be sufficient to remediate, vs having to rotate the secret.
To mitigate impersonation, I suppose one could do a number of things involving a second key, but I think that this simple version demonstrates the value of having a signing oracle. This is actually not an atypical approach, just not using sgx - I know companies that keep their signing keys in separate processes, which are mutually seccomp'd such that they can only pipe messages to each other for signing purposes of apps before publishing. But in the sgx case you have a much stronger guarantee than just seccomp.
So to me the only problem that attestation solves here is if the attacker is somehow in the SGX enclave, but actually the much more likely scenario is that they aren't, and that they just ask the oracle to sign on their behalf - because B can't verify that A is the one asking to sign. Given that there is a single entity deploying both the software in the enclave and the service that interacts with it at least, that seems to be the case to me - like, in this scenario A, B, and the software in the enclave are all deployed by me, barring malicious action to interfere with that - but again, the most likely scenario is the attacker just owned the box and has a regular user on there.
But... also also, A can prevent impersonation via tricking the oracle by having another keypair shared between it and the enclave, and then it becomes a matter of protecting that memory from an attacker who can almost certainly scrape your memory - a hard thing to do.
So you end up with:
System 0, A: Key 0 System 0, Enclave: Key 1, Key 0 System 1, B: Key 1
Key 0 is used to 'auth' A to Enclave. Key 1 is used to auth A to B (via enclave oracle).
This is just my perspective on it.