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.

  • 1
    RE "Owing to the point above, the enclave runs inside of a CPU, not a GPU": I'm probably missing something but what would force the attacker to use the enclave in an offline attack?
    – JimmyJames
    Commented Sep 15, 2022 at 15:05
  • Only if the attacker is unable to reverse engineer the enclave. Even if they did, video memory would be a significant bottleneck, and a GPU wouldn't be that useful in a completely serial context.
    – Expectator
    Commented Sep 15, 2022 at 23:31
  • That doesn't seem to be an answer to the question I asked.
    – JimmyJames
    Commented Sep 16, 2022 at 16:55
  • Errata: I read "what would" as "does that". An attacker would not have to use an enclave in an offline attack, but the whole point of the enclave is to allow for a non-standard password hash configuration that would make running an attack, enclave or not, infeasible.
    – Expectator
    Commented Sep 16, 2022 at 17:18
  • I'm just trying to understand fully the scheme. I understand that the hash is created on the client and the attestation confirms the hash was created in the enclave. The server doesn't know the password, but it knows the hash was computed from the input given by the user creating the credentials. So far so good?
    – JimmyJames
    Commented Sep 16, 2022 at 17:25

1 Answer 1


While trusted execution environments are useful, I don't think that outsourcing password hashing from server to the client is the right approach.

Either the server only has the hashed password for comparison in which case due to the fixed salt a replay would be possible, i.e. without computing it again in the enclave. Or the server knows the password (or some suitable derived value) in which case both client and server must compute the resulting hash with a for each authentication newly chosen salt for comparison. This is basically the problem faced by digest authentication.

If a trusted execution environment is available it would make more sense to create a key pair instead, keep the private key in the TEE and have the public key on the server side. Authentication is then done by the client proving to the server that it has the private key matching the public key stored in the server by signing a server generated random challenge. This is an already widely established method, for example used for authentication with smartcards, with client certificates in TLS etc.

Using a key pair has the added advantage that the server does not actually need to fully trust the TEE in the client, i.e. no remote attestation etc is needed. Instead the role of the TEE is only to protect the private key on the client side.

  • 1
    Couldn't the replay be prevented if the server sends a unique nonce to the enclave before it computes the hash? Then the secure enclave does the hashing, and then attests that a password that hashes to <computed hash> was recently given to the enclave, and includes the nonce in the signed response.
    – Shelvacu
    Commented Sep 15, 2022 at 19:16
  • @Shelvacu: I'm not fully convinced that this might work but I don't see a specific problem to this at the moment. The main problem I see is that it is attempting to transfer a concept which originally was based on the user remembering something (i.e. the password) is moved into a different context where the user does not need to remember something and then one is trying to perfect it in this context - instead of using an established approach which hasn't the problems of passwords from start and is more suitable for this new context - i.e. authentication based on asymmetric cryptography. Commented Sep 15, 2022 at 19:32
  • @SteffenUllrich a password authenticates the user, whereas a key in the enclave authenticates the device. With the password-based scheme, a user can log in from a different new device just by knowing their password. Commented Sep 15, 2022 at 19:44
  • @GavinS.Yancey: Good point. I'm still not comfortable though with extending the live of a weak authentication concept (memorizable password) by directly using it in an enclave - it does not get any stronger this way. I'm more comfortable with using it as an rarely used authentication factor (and maybe not the only on) in enrolling a new device - which then again uses asymmetric cryptography in the enclave. Commented Sep 15, 2022 at 20:08
  • @GavinS.Yancey I'm trying to verify that I understand the proposed scheme: that implies that the hash for a given password is independent of the enclave, correct?
    – JimmyJames
    Commented Sep 16, 2022 at 17:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .