GrapheneOS protections against data extraction from locked devices

de0u

Onlyfun Google leaves some ways to recover data after the 20 attempts were made, so data is still there waiting for the right key.

I don't think we know that Google "left a way"! Is there a basis for knowing or suspecting that?

Onlyfun Graphene OS site mentions no recovery options. Should following quote

Only a total of 20 attempts is permitted. Weaver also provides reliable wiping of data since the secure element can reliably wipe a Weaver slot.

mean that the data is wiped after 20 attempts?

Wiping the Weaver slots (etc.) after 20 attempts would make the data inaccessible, so the claim of inaccessibility certainly could be true. I'm unaware of anybody having reverse-engineered the firmware to check. On the other hand, I'm unaware of anybody having reverse-engineered the firmware to check the other claims about how the secure element works.

de0u

Onlyfun I think I am not exactly following the encryption scheme, not sure what is the hardware key that could be extracted from the SoC.

At a very high level, imagine that your PIN/passphrase is "half" of a passphrase that is necessary to decrypt the storage, with the other "half" being chosen randomly when the PIN/passphrase was set and stored only inside the secure element. If you present your "half" and it combines with the other "half" correctly, the storage encryption key is made available to the flash controller. If the secure element's "half" is lost, recovering the storage encryption key is expected to be infeasible. The actual details are more complicated.

de0u

de0u On the other hand, I'm unaware of anybody having reverse-engineered the firmware to check the other claims about how the secure element works.

I believe the original Titan firmware was reversed, and it may well be that somebody has examined the M2 firmware as well. That may not mean that every part was equally carefully examined (people tend to report exploitable bugs rather than code that does what it should).

FunkTastic

Onlyfun why couldn't a secure chip wipe after a set amount of wrong unlocking attempts happen?

As stated by a user grapheneos on https://news.ycombinator.com/item?id=49394050

Android does have standard support for enabling wiping after N attempts and an open source app can be used to set a configurable limit rather than specifically after 10.

GrapheneOS

Onlyfun

No, 20 is good enough. The point I meant is to make data not accessible after those attempts. Google leaves some ways to recover data after the 20 attempts were made, so data is still there waiting for the right key.

There are no recovery mechanisms. People need to make backups if they want a recovery option which applies to both the stock OS and to GrapheneOS.

There are only 20 attempts to obtain the Weaver token from the secure element and then the data cannot ever be recovered. It would take over 13 years to exhaust all 20 attempts so it's not particularly relevant.

Onlyfun

de0u My bad, I confused the device access options provided by Google after 20 attempts(like FRP), with a complete device recovery with data.

Android 17 introduces a dedicated recovery shortcut directly on the lock screen.

If users are unable to unlock their device, they can quickly access recovery resources from another trusted device.

This simplifies the recovery process by directing users toward Google’s official account recovery tools rather than forcing them to search for assistance manually.

If you somehow enter 20 incorrect PINs all by yourself, the Android 17 lock screen will feature a recovery shortcut that lets you access different recovery options on a new device. Details on this haven't been specified, but that presumably means you won't be locked out of your phone forever simply because your annoying cousin deliberately entered the wrong passcode several times.

Google actually stated the device has to be reset after 20 attempts. Question remains, why the reset doesn't happen automatically after 20 attempts, if it is inevitable? Possibly has something to do with FRP, but not sure.
Graphene does not have FRP, it would just feel safer when device reset.

Thanks for the tip on hardware key.

GrapheneOS So device is bricked after 20 attempts? How are these limits implemented, throttling and attempt number limit? Are they logged in Titan?Why not wipe the encryption and reset it after 20 attempts? I was under impression that Titan does the throttling, so if the keys are to be bruteforced bypassing Titan throttling is out of equation, how about the attempt limits? Are they still enforced?

GrapheneOS

Onlyfun There are no recovery options in the stock OS bypassing the rate limiting.

Details on this haven't been specified, but that presumably means you won't be locked out of your phone forever simply because your annoying cousin deliberately entered the wrong passcode several times.

You will be locked out of the profile forever if you used all 20 attempts over more than 13 years. There's no alternative to providing the correct PIN/password.

The device can be wiped via recovery to avoid it being bricked. Dealing with the factory reset protection account login is a separate thing.

Onlyfun

GrapheneOS All is clear now thank you!

MoldedArgon

Notme I'd like to be able to select one or more fingerprints that return to BFU.too.

silverfox1875

DeletedUser1041 Not at an airport.

DeletedUser1191

silverfox1875 What evidence do you have that the 5th amendment is weakened or doesn't apply at airports. To my knowledge the 4th amendment is what's weakened.

mar2112

DeletedUser1191 And that's only when going through customs and immigration.

00disi00

The duress PIN is great and covers coercion well when the phone is in hand and you can reach a prompt. Problematic are the cases where you cannot type it: the device is already grabbed, you are restrained, or it is in a bag while you could potentially reach a concealed physical control.

Would a narrow, local companion trigger for the existing duress actions be desirable?

The shape I have in mind would stay inside the current model:

A special-access permission, off by default, granted to one app and revocable.
A guarded local call that runs the same audited duress path (lock, or wipe). No new wipe logic.
The OS listens on no network. The authorized app has its own remote trigger paired over BLE.
Wipe only fires while the user has armed a duress mode, so a lost or spoofed companion is inert until the owner chooses otherwise.

Context: this comes from my work on a personal-safety wearable that pairs a button with the phone (primarily to send a private alert), but the capability would be generic to any companion. Is this worth a full proposal, or has it already been considered and rejected?

de0u

00disi00 I think the existing Android "device administration" API (source) supports wiping a device.

Jeffsimp

GrapheneOS is it possible to block and stop stop a device being booted into safe mode or being able to turn safe mode off

00disi00

de0u supposedly that worked until Android 14. Not anymore, at least not for an app you just install.

[removed AI generated content]

If you've actually seen a non-Device-Owner app wipe a phone on a current build, let me know please. Couldn't find one.

de0u

00disi00 If the Android developer documentation is stale, it might be productive to point that out to Google.

The post contains text that appears to be a quotation, but without an indication of the source. If requesting that Google update their documentation, it might be useful to include support that is attributed.

I have no personal experience with device-admin apps.

00disi00

de0u thanks a lot, will do!
that quote was from a summary over agentic research, didn't want to phrase it wrongly..

Is there someone on the team who could address my question about the companion trigger? imagine a button in your pocket that could wipe the phone when you're under duress.

de0u

00disi00 that quote was from a summary over agentic research

There is a policy against that: #11951

Rephrasing factual claims made by LLMs can be OK if they are carefully checked first. But posting factual claims that are incorrect can mislead people, and provides future LLM training runs with incorrect "facts" for them to mislead other people with (this is called "model collapse").

People come to this forum hoping for accurate information. Anybody who wants to receive LLM speculation knows where to find it.

de0u

00disi00 Is there someone on the team who could address my question about the companion trigger? imagine a button in your pocket that could wipe the phone when you're under duress.

Which question, exactly?

I have a faint sense that there has been discussion about locking a device if it falls out of communication with a Bluetooth device, and I don't think the response was enthusiastic. Also there has been various traffic about wiping devices when unexpected USB devices are connected, which I believe has not been enthusiastically received.

I don't speak for the GrapheneOS project, but my hunch is that the team would not build this any time soon, and I am skeptical that they would merge donated code to do this even if it were high-quality. This seems likely to be a "try it on a private fork" situation.

« Previous Page Next Page »