SafeKeeper: protecting web passwords using trusted execution environments Krawiecka et al., WWW’18

(If you don’t have ACM Digital Library access, the paper can be accessed either by following the link above directly from The Morning Paper blog site, or from the WWW 2018 proceedings page).

Today’s paper is all about password management for password protected web sites / applications. Even if we assume that passwords are salted and hashed in accordance with best practice (NIST’s June 2017 digital identity guidelines now mandate the use of keyed one-way functions such as CMAC), an adversary that can obtain a copy of the back-end database containing the per-user salts and the hash values can still mount brute force guessing attacks against individual passwords.

SafeKeeper goes a lot further in its protection of passwords. What really stands out is the threat model. SafeKeeper keeps end user passwords safe even when we assume that an adversary has unrestricted access to the password database. Not only that, the adversary is able to modify the content sent to the user from the web site (including active content such as client-side scripts). And not only that! The adversary is also able to read all content sent to the backend servers, including any content encrypted by a TLS session key. The adversary can also execute any software they like on the backend server(s), and can launch state-of-the-art phishing attacks. Such as adversary for example, could be one that has taken over a backend server, or an operator of the service, or an operator of a service that a client has been hoodwinked into connecting to in lieu of the real thing.

Given an adversary like that, how is it possible to design a system that protects users’ passwords !? The adversary should not be able to obtain a user password though any means other than guessing. Offline guessing should be computationally infeasible irrespective of password strength, and online guessing must be throttled (rate limited) regardless of the adversary’s computational capabilities. The end user must also be able to tell whether they are communicating safely with a trustworthy backend service.

The answer is a clever use of trusted execution environments (Intel SGX in this case).

High-level design of SafeKeeper

On the server side, SafeKeeper’s password protection service computes cipher-based message authentication codes (CMAC) on salted passwords before storing them in the database. To perform a guessing attack against such passwords, an adversary also requires the CMAC key. SafeKeeper randomly generates this and protects it within an SGX enclave.

To prevent repeated guessing attacks using the online service, SafeKeeper enforces rate limiting within the trusted execution environment.

To prevent eavesdropping on passwords before they arrive at the password protection service, SafeKeeper establishing a secure end-to-end channel directly between the client and the enclave.

To ensure the client can trust the backend service it is interacting with, remote attestation is used to validate that the client is communicating with a genuine SafeKeeper Trusted Application.

To ensure that the user knows it is safe to their credentials, the SafeKeeper browser add-on displays trust information for the backend service, and highlights to the user the input fields that will be protected.

Server-side protection

The server-side is implementation as an SGX enclave.

• The init function is called whenever the enclave is started. If this is the first time the enclave has been started, Intel’s hardware random number generator is used to generate a new strong CMAC key.
• The shutdown function seals the enclave state (CMAC key, the map of salts, and password attempt counters) so that it can be securely stored outside of the enclave. This sealed data can be restored in the enclave on subsequent calls to init.
• The process function takes as input a password (encrypted on the client-side) and corresponding salt value, it calculates the CMAC and returns the result. This result can be stored by the database when the password is first set, and then tested against in future login attempts.

Rate-limiting is done on a per-salt basis (no user ids are passed to the enclave). Assuming a salt-per-user, this is equivalent to rate-limiting by user. SafeKeeper uses a quantized maximum rate limit for each salt, which allows a fixed number of attempts within a pre-defined time interval but doesn’t mandate a delay between the attempts. Once the number of attempts has been exceeded, the user must wait until the next time interval before they can try again.

Remote attestation

Via a process known as remote attestation, a client can verify it is communicating with an endpoint that is running a genuine copy of the SafeKeeper Trusted Application inside a genuine SGX enclave.

Remote attestation is the process through which one party, the verifier, can ascertain the precise hardware and software configuration of a remote party, the prover. The objective is to provide the verifier with sufficient information to make a trust decision about the prover. SGX supports remote attestation by providing verifiers with a signed quote from the enclave, which includes the enclave’s precise identity (MRENCLAVE value) and the enclave’s public key. The verifier can then validate this quote using the Intel Attestation Service (IAS), and can then establish an end-to-end encrypted channel directly to the enclave.

The configuration information in the quote is checked by the client against a whitelist of known SafeKeeper Trusted Applications (TAs). The same TA can be used as-is by many websites, so this list should be short. Since the key agreement step to establish a session key is cryptographically bound to the TA’s remote attestation, the adversary cannot perform a man-in-the-middle attack. The client encrypts the user-supplied password using the session key, and on the server it is this encrypted password that is passed as input to the process function of the enclave, which can decrypt using the shared key.

Client-side assurances

The client-side mechanism is implemented as a browser addon (e.g., a Chrome extension). The server specifies which input fields should be encrypted and sent to the SafeKeeper TA. The addon parses this information and encrypts any text entered into these fields.

A rogue server might specify the wrong field names though, leaving the actual password field unprotected. To prevent this, SafeKeeper visually highlights the fields to be encrypted, greying out the rest of the page.

To avoid an adversary spoofing the highlighting performed by SafeKeeper, the user is required to click on the extension icon to activate the highlighting.

This click cannot be detected or prevented by the adversary (as it is outside of the browser DOM). After the user has clicked, the SafeKeeper icon is again changed to indicate that it is in the highlighting mode… The user is thus assured that a password entered into such an input field will always be protected by SafeKeeper, regardless of the identity of the website or the behaviour of the server.

The addon is stateless and user-agnostic, which means it could also be directly integrated into web browsers.

What about…?

A malicious server operator can include javascript in the page that attempts to read the password as it is typed by the user. SafeKeeper provides a mode which will disable scripts for an individual website and then reload the page with all scripts but SafeKeeper’s blocked. It’s not perfect (there are race conditions), and on many modern sites disabling javascript interferes with the usability of the web page, so SafeKeeper allows client-side scripts by default. An alternative discussed in the extended technical report is to change the UI so that the password is directly entered into a SafeKeeper popup controlled by the extension. For this to work, users must be trained to only enter password data into SafeKeeper popups.

I also wondered about the enclave becoming a single point of failure, and how SafeKeeper would provide high availability. The answers can be found in sections 7.1 and 7.2 of the extended technical report. SafeKeeper supports backup and recovery across a set of key-holding enclaves, with unanimous approval of all current key holding enclaves required to add a new one. If a machine fails, an operator must provide a proof that the failed machine has been revoked in order to change the set of key holding enclaves. If desired, the backup and recovery protocol can be extended to support multiple concurrent primaries. In this case, the overall permissible password checking rate is divided amongst the primaries.

The SafeKeeper site including links to all technical papers and the source code can be found at https://ssg.aalto.fi/research/projects/passwords/.