4

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.

Expectator
  • 171
  • 4
  • 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 Sep 15 '22 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 Sep 15 '22 at 23:31
  • That doesn't seem to be an answer to the question I asked. – JimmyJames Sep 16 '22 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 Sep 16 '22 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 Sep 16 '22 at 17:25
  • OK, so if the enclave isn't required for an offline attack, then the attacker can use a GPU, no? – JimmyJames Sep 16 '22 at 17:28
  • Yes, but again, the entire point of this is to maximize memory usage to the point that running this sort of an attack on a GPU would be slower than running it on a CPU. GPU memory must be extremely high bandwidth and is always smaller than main memory, and each GPU core can only run a single attack. GPU cores are slower than CPU cores, and there are usually hundreds. Allocating 2 GB per thread means you're only using ~6 cores out of hundreds, at a higher cpb than a CISC CPU core. You'd then have to run with a detrimental memory-time tradeoff to work on a GPU semi-effectively. – Expectator Sep 17 '22 at 21:38
  • Thanks, that helped. You might want to the details from that last comment that to the explanation of the approach in the question. – JimmyJames Sep 19 '22 at 14:49

1 Answers1

8

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.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 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 was recently given to the enclave, and includes the nonce in the signed response. – Shelvacu Sep 15 '22 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. – Steffen Ullrich Sep 15 '22 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. – Gavin S. Yancey Sep 15 '22 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. – Steffen Ullrich Sep 15 '22 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 Sep 16 '22 at 17:15