de0u
The OS stores a high entropy random value as the Weaver token on the secure element (Titan M on Pixels) and uses it as another input for key derivation. The Weaver token is stored alongside a Weaver key derived by the OS from the password token. In order to retrieve the Weaver token, the secure element requires the correct Weaver key. A secure internal timer is used to implement hardware-based delays for each attempt at key derivation. It quickly ramps up to 1 day delays before the next attempt. Weaver also provides reliable wiping of data since the secure element can reliably wipe a Weaver slot. Deleting a profile will wipe the corresponding Weaver slot and a factory reset of the device wipes all of the Weaver slots. The secure element also provides insider attack resistance preventing firmware updates before authenticating with the owner profile.
Standard delays for encryption key derivation enforced by the secure element:
0 to 4 failed attempts: no delay
5 failed attempts: 30 second delay
6 to 9 failed attempts: no delay
10 to 29 failed attempts: 30 second delay
30 to 139 failed attempts: 30 × 2⌊(n - 30) ÷ 10⌋ where n is the number of failed attempts. This means the delay doubles after every 10 attempts. There's a 30 second delay after 30 failed attempts, 60s after 40, 120s after 50, 240s after 60, 480s after 70, 960s after 80, 1920s after 90, 3840s after 100, 7680s after 110, 15360s after 120 and 30720s after 130
140 or more failed attempts: 86400 second delay (1 day)
Invalid input outside the minimum or maximum length limits of the UI won't trigger an attempt at authentication or key derivation.
GrapheneOS only officially supports devices with Weaver. The fallback implementation for devices without it is out-of-scope for this FAQ.
The password token, Weaver token and other values like the OS verified boot key are used by the TEE as inputs to a hardware-bound key derivation algorithm provided by the SoC. The general concept is having the SoC perform hardware accelerated key derivation using an algorithm like AES or HMAC keyed with a hard-wired hardware key inaccessible to software or firmware. This is meant to prevent offloading a brute force attack onto more powerful hardware without an expensive process of extracting the hardware key from the SoC.
Many apps use the hardware keystore, their own encryption implementation or a combination of those to provide an additional layer of encryption. As an example, an app can use the hardware keystore to encrypt their data with a key only available when the device is unlocked to keep their data at rest when the profile is locked but not logged out. This is beyond the scope of this FAQ section.
From my understanding on this, the Weaver token (like a second key or a keyhole?) will be destroyed so even if the actual key was obtained, user data cannot be retrieved. It means that the data exists, just that it can't be accessed. If getting the keys is the only way to enter (no figurative breaking of windows) than the guy passing through border patrol from the other thread would be safe if he was just willing to reset his phone.
Just one last question, assuming if a GrapheneOS phone has been restarted, not reset (before first unlock state), do all exploits aim solely to obtain the keys and there are absolutely no other ways to access user data? Is this the same for PixelOS as well?