Weaver-Enhanced Password Unlock Architecture and Security Analysis on Android

Background

On Android, the traditional password‑unlock solution combines GateKeeper and KeyMint to protect user data with a password known only to the user. Weaver leverages a Secure Element (or other tamper‑resistant hardware) to strengthen this protection, offering two key features: a device‑off security threat model and a brute‑force password‑guessing mitigation.

Device‑off security threat model

When the device is powered off, the secret used for authentication and disk encryption resides in a secure chip. Access to this secret requires the user’s LSKF (PIN/pattern/password).

Brute‑force password guessing mitigation

A secure timer inside the chip throttles repeated attempts, preventing attackers from brute‑forcing the password.

Weaver overall architecture

The process consists of password entry, verification, and unlocking. SystemUI captures the user’s password (PIN/pattern), generates a credential, and passes it to LockSettings for verification.

Key interface: doVerifyCredential (LockSettingsService.java)

SystemUI → LockSettingsService.doVerifyCredential(credential) → GateKeeper/Weaver verification → synthetic password generation → further unlock actions.

Traditional GateKeeper + KeyMint scheme

1. byte[] stretchedLskf = stretchLskf(credential, pwd);

2. byte[] gkPassword = stretchedLskfToGkPassword(stretchedLskf);

3. GateKeeper verifies the challenge using a fakeUserId and the derived gkPassword:

response = gatekeeper.verifyChallenge(fakeUserId(userId), 0L, pwd.passwordHandle, gkPassword);

4. After successful fakeUserId verification, LockSettings decrypts the protectorSecret:

protectorSecret = transformUnderSecdiscardable(stretchedLskf, secdiscardable);

This flow relies on software‑only throttling implemented in the GateKeeper TA, which can be bypassed by external brute‑force attacks.

Weaver + GateKeeper + KeyMint enhanced scheme

1. byte[] stretchedLskf = stretchLskf(credential, pwd);

2. The credential is sent to Weaver, which returns a response after verifying the derived Weaver key:

result.gkResponse = weaverVerify(weaverSlot, stretchedLskfToWeaverKey(stretchedLskf));

3. After obtaining the synthetic password, GateKeeper performs the usual authentication.

4. The final protectorSecret is derived using the Weaver‑protected secret:

protectorSecret = transformUnderWeaverSecret(stretchedLskf, result.gkResponse.getGatekeeperHAT());

This integration moves the throttling mechanism into the Secure Element, making offline brute‑force attacks far more difficult.

Advantages of the Weaver solution

The traditional scheme’s throttling resides in software (GateKeeper TA), which can be circumvented by extracting intermediate ciphertexts and performing high‑speed offline cracking. Weaver’s throttling is enforced by hardware timers inside the Secure Element; repeated incorrect keys cause exponentially increasing delays, effectively limiting brute‑force attempts.

Limitations

Weaver requires communication with the secure chip via OMAPI. Opening a logical channel (openLogicalChannel) checks Access Control Rules and incurs significant latency.

Optimization ideas

Bind a fixed logical channel to the Weaver applet during device startup, keeping it open to avoid repeated channel‑opening overhead, provided the chip vendor can manage power consumption.

Summary

The traditional password‑unlock approach implements throttling in software, exposing a potential vector for offline brute‑force attacks. Weaver relocates throttling to secure hardware, making it considerably harder for attackers to obtain intermediate secrets or bypass rate‑limiting, thereby enhancing overall device security.