I've been pondering some potential cybersecurity applications for enclaves. One of them being the problem of password hashing.
Some clients have enclave support, meaning part of their CPU can securely execute code in an encrypted and authenticated channel, where the session keys are kept by the enclave. One must only trust the manufacturer of the processor, not the owner of the computer it runs on.
This leads to some useful implications:
- We have practically unlimited CPU cycles at our disposal, since each client has a processor.
- Memory is becoming cheaper and cheaper, clients can dedicate a portion of memory for calculating a password hash for a single session. For each CPU we get, we get an equivalent amount of memory.
- We can limit the attack surface by configuring our password hash to be single-laned (as in the case of argon2). Every attacker worker thread would increase the memory requirement linearly in order to be computationally feasible.
- This is surprisingly the exact opposite of how a server would configure password hashing, since multithreading would improve performance. Since performance is no longer a factor due to massive parallelism, we are making an effective security tradeoff.
- Due to the attestation, clients can also compute password hashes for account registration or password changes without a single password ever touching server memory. The server is free to tell the enclave what salt to use.
- Although not impossible, creating a session is much harder to do without an enclave due to the attestation, which is difficult without breaking the cryptosystem itself (universal forgery or recovering the private keys by cryptanalysis), so the only feasible way of bypassing this measure is by attacking the server itself.
- Owing to the point above, the enclave runs inside of a CPU, not a GPU, meaning a scheme like argon2 can be hardened to side-channel attacks rather than GPU resistance, letting the memory hardness and highly serial computation reduce GPU effectiveness.
- Server-side authentication has been simplified to interactive signature authentication, no complex hashing involved.
Other than lack of practical implementations and market penetration for enclaves*, what are the glaring issues with this kind of approach, especially from a security standpoint?
Assume the following threat model:
- Attacker has compromised the server and exfiltrated the entire password database (no plaintext passwords were in memory).
- Attacker has the enclave authentication code and can run their own enclave to create a valid session.
- An offline brute force attack is to be attempted.
*Example: WebAssembly runtimes shipped with browsers do not have TEE support.