3 ms·

I wonder whether it'd be better for a duress PIN to delete existing data and also create a semi plausible artificial profile to hide the deletion event.

dredmorbius 1mo ago
This discussion was raised last time this story was discussed. I was among its advocates: <https://news.ycombinator.com/item?id=49061890 https://news.ycombinator.com/item?id=49061890>. Briefly: no. Less briefly: <https://news.ycombinator.com/item?id=49060780 https://news.ycombinator.com/item?id=49060780> and <https://news.ycombinator.com/item?id=49060716 https://news.ycombinator.com/item?id=49060716> (from the grapheneos HN account directly).
- spacebanana7 1mo ago
  Thanks for sharing - I get the concerns people have raised in those threads, however I still feel something in this space could be useful. Even a duress PIN which triggers predefined deletion of certain folders, messages and apps could reduce law enforcement exposure significantly.
  - grapheneos 1mo ago
    Deleting arbitrary directories, messages and app data would be highly unreliable. There's a high likelihood of the data being recovered. It's not how computer filesystems and storage are designed to work. Reliable deletion of data requires setting it up to be reliably deleted later on by having it encrypted on storage with keys which can be reliably prevented from ever being obtained again. Wiping the overall data on the device via a factory reset, OS recovery mode or duress PIN/password prevents recovering any of the data because it reliably wipes material needed to derive key encryption keys and also reliably wipes the encrypted disk encryption keys. Wiping the encrypted disk encryption keys alone would not be good enough because they're stored on the SSD so imaging the SSD and restoring it could preserve the ability to recover the data. The way the key material needed to derive the key encryption keys is wiped prevents recovery via imaging the SSD mainly due to the secure element. There's already support for reliably wiping data at the granularity of Private Spaces and secondary users. Those have their own encryption keys and can be reliably deleted due to having their own Weaver slots in the secure element and other hardware-based security integration. Apps can also assorted generate encryption keys in the secure element and use those to encrypt data where it can be reliably deleted via wiping the hardware keystore keys. That requires apps built to have granular storage and encryption of their data. Despite it being possible to wipe a secondary user or Private Space reliably, the past existence of it and when it was wiped will be easily discoverable via the main Owner user and system data. Preventing discovery of those profiles having existed requires an overall wipe of the data. It isn't feasible to hide it without doing that and hiding it would involve a whole bunch of unreliable removal of data without a way to prevent recovery along with redoing a bunch of statistics and other metadata to hide that there was another profile until recently. For example, things like the battery and data usage stats directly refer to the profiles. Even hiding it from naive analysis not looking at the leftover data on storage would still require changing a bunch of things to hide it. Making data deletion of the data reliable for a whole profile or the whole data partition also requires a reboot or shutdown. Consider how much data gets loaded into the page cache and many other forms of data in the Linux kernel and other processes. Consider how much linger around in various kinds of registers, etc. including outside of the OS itself. Reboot or shutdown has code to get rid of this and the device sitting there turned off or booting again also gets rid of it. They were clearly going to hook his phone up to forensics software on a laptop and had done what they needed to do in order to justify it for their own policies. It would not make sense to set up everything they did simply to have someone non-technical manually sift through his apps. They have widespread access to forensic software and also more advanced software with exploits. They definitely have easy access to it at a major Atlanta airport. The adversary in this case is not a non-technical human but rather advanced software from Cellebrite who are fully aware of alternative operating systems and document information on it. Their documentation directly refers to GrapheneOS and has tables listing their (currently very limited) capabilities against it. This story got widespread news coverage and is widely known about. That should help make it clear how important it is for features to work against adversaries aware of these kinds of features. Our duress PIN/password works against adversaries aware of it. If they don't coerce a PIN/password from someone or don't enter a coerced PIN/password because they know it could be in use then the feature has worked. We want to improve the feature with secure element rate limiting integration in the future so that an OS exploit cannot be used to bypass it. The secure element already prevents an OS exploit from bypassing the limit of 20 total attempts for deriving encryption keys with massively increasing delays between those attempts. It used to solely be based on delays with throttling quickly reaching 1 attempt per day after 140 failed attempts but now there are only 20 total unique attempts. The past 5 failed unique attempts are temporarily remembered and discarded when entered again rather than trying to use them again for usability.
    - michaelt 1mo ago
      > Reliable deletion of data requires setting it up to be reliably deleted later on I mean - yes? If you design a subtle duress pin that only hides certain things, users would have to choose what. I myself want the bank apps, password manager and email to disappear without a trace, but I don’t care about the social media, photos or web browser history. Other people, though, will have different priorities.
      - dist-epoch 1mo ago
        You misunderstood the parent post, it's extremely difficult to delete the data without leaving a trace that something was deleted.
        grapheneos 1mo ago
        To reliably delete a specific file or directory, it needs to be encrypted with a dedicated key which can be reliably deleted. It can have dedicated key material in the secure element used to derive sub-keys from the main encryption keys or it could simply be encrypted with another layer of encryption. For the OS disk encryption, it uses separate randomly generated disk encryption keys for the main user, secondary users and Private Spaces which are different forms of profiles. Those keys are stored encrypted with key encryption keys derived from the per-profile lock method combined with various forms of key derivation material from elsewhere. The most important of the key derivation material for profiles is the per-profile Weaver token on the secure element which it uses to enforce rate limiting for decryption attempts (max 20 attempts per profile with rapidly increasing delays) and to provide extremely reliable deletion of the data. Wiping the weaver slot for a profile prevents deriving the key encryption keys which prevents ever decrypting the randomly generated disk encryption keys again. The randomly generated disk encryption keys are only stored once and get wiped via a special SSD secure erase command but that isn't nearly as good as the secure element integration. If the SSD is imaged before a wipe and then restored, the data still isn't recoverable because the secure element wiped what's needed to decrypt the disk encryption keys. Reliably deleting data is a much different thing from fully hiding that anything was deleted which is drastically more difficult and not compatible with how things are typically done. It's pretty much impossible to stealthily delete a secondary profile since there's too much system and Owner user data referencing them including the package manager's state, battery stats, data usage stats and far more. It's possible to attempt to go through all of that and hide it including forging the other stats to mask what was removed but data cannot be reliably deleted in a fine-grained way, especially on top of a modern copy-on-write or log structured filesystem combined with an SSD controller doing wear leveling. An SSD controller will redirect writes to less written NAND than what is now being written to level out usage. That relies on it being aware of free storage to choose from that instead which is the purpose of TRIM. A modern SSD will also very proactively move around data rather than only redirecting writes to free space with less wear. It will identify the data that's rarely or never written and move it to the most written areas of the SSD to free up the space it was on for the most written data. Having 2TB of used space that's rarely ever touched, 1TB of a heavily written database and 1TB free will not only use the 2TB of active space for wear leveling with a modern SSD controller design. It will use the whole 4TB for it. A modern copy-on-write or log structured filesystem doesn't write to the location where the data was originally but rather elsewhere. Android uses f2fs which is log structured which heavily helps with wear leveling at a higher level and also provides the ability to turn off data persistence temporarily and then roll back to the point it was turned back in an incredibly efficient way. Android uses that incredibly efficient rollback feature as part of A/B updates to preserve the ability to fully roll back an OS update which doesn't end up working properly until after it reaches the lockscreen successfully. An app regularly appending data to a file, overwriting data in it or replacing the whole file is leaving data around all over the place. A decision can't simply be retroactively made to reliably delete the data for that file or the overall app. It would have had to be set up in a way that it can be reliably deleted. Without that, the whole secondary profile it's in is going to need to be deleted to reliably delete the data. If it's not in a secondary profile, the whole device needs to be wiped for it.
- kelnos 1mo ago
  I think for the case we're talking about here, though, it would be doable. This doesn't need to thwart deep forensic analysis. It just needs to survive a border agent thumbing through the contents of your phone for a bit. If the fake profile data looks plausible, and doesn't raise any flags, the agent gives the phone back and you're on your way. Hell, I think a setup that doesn't wipe anything, but just drops you into a sanitized, isolated profile for the border agent to look at, would be fine for many users. Certainly you wouldn't want to use this in truly high-stakes situations where it's likely that your device will be confiscated no matter what, and analyzed to death, but for the simple "border agent wants to snoop on my data for a few seconds" case, it's likely sufficient. (As always, risk analysis can be hard, humans are often bad at it, and not everyone's threat model is the same.)
NDlurker 1mo ago
Or put a dead man's switch on there
Gabrys1 1mo ago
Maybe it could cause the phone to "randomly" bootloop or something? "Oh no, my phone is broken again, last time this happened I needed to do a factory reset"
- whycome 1mo ago
  Private 0-day exploits? Have a phone with crappy battery and have it trigger a high processor load to take the battery voltage drop and turn off the phone? (Eg what Apple tried to prevent with the batterygate thing).
- debugnik 1mo ago
  This case happened precisely because the officers noticed the phone flash and reboot when they entered the pin. IIRC they didn't make a fuss over it, but time later he got charged over the event. So whatever a duress pin does, it has to be subtle enough that anyone looking doesn't link it to the act of entering the pin.
grapheneos 1mo ago
> I wonder whether it'd be better for a duress PIN to delete existing data Reliably deleting data at the scale of the whole data partition, a secondary user or a Private Space is fully supported but requires a reboot or shutdown to truly complete it. After wiping key derivation material needed to obtain the key encryption keys in multiple ways and wiping the encrypted disk encryption keys, the OS can still access the data. It still has data in the page cache, in registers and elsewhere. There are still a bunch of system processes with data tied to what was removed. The OS is still fully functional after the nearly instant wipe of everything needed to recover the data again. It can still access all data other than what's encrypted with hardware keystore keys and not currently decrypted. The wiping process for the duress PIN/password is completed with a shutdown which tears down everything, zeroes memory and provides at least a small time window where the hardware is powered off too. A reboot would also work and the boot process has explicit zeroing of memory, registers, etc. We decided to use shutdown for the duress PIN/pasword but a reboot is a valid approach too. Our locked device auto-reboot timer feature we first shipped in 2021 relies on the zeroing done by GrapheneOS for both the process of the OS tearing down and then again during booting to return the device to Before First Unlock state. > also create a semi plausible artificial profile to hide the deletion event. It isn't feasible to fool forensic software so it largely wouldn't work against state actors. It nearly certainly wouldn't have helped in this situation in the news. They aren't reliant on a non-technical person sifting through a phone. They'll just hook it up to a laptop and follow the data extraction procedure which involves enabling ADB. The software is aware of GrapheneOS can guide people through dealing with anything different about it. They've had a lot of trouble with extraction via ADB for GrapheneOS since the vulnerabilities they exploit via ADB keep getting patched or blocked it exploit protections but it isn't realistic to block extraction with them having the PIN/password. They could just enable the encrypted backup service in the OS instead and then use CLI tools to extract the data from there with the seed phrase. They don't do that because they want everything rather than only nearly all app data. They also have special code to deal with apps such as Signal with their own layer of data encryption since the data taken from their app data directory is nearly all useless by itself. There's also quite a difference between wiping and rebooting into a not very plausible environment with decoy data set up by the user in advance compared to not properly wiping and giving access to a decoy profile. Bear in mind the OS can still access nearly all data after the wipe until a reboot. It could make a best effort attempt at purging as much as possible from memory, but the OS is not designed to continue functioning with all of the data disappearing. It can't just wipe all loaded encryption keys without crashing and rebooting anyway. It also has a ton of data still around in caches and elsewhere. We don't want to just do a best effort job cleaning up as much as we can but rather reliably prevent recovering any of the deleted data. We could definitely add a duress PIN/password which wipes only specific secondary profiles, reboots and has the device still functional with whatever data was in the main user still there. That's a feature we can add, but it's important to note that it will not hide that there was deletion of data. It's easy to detect, and it's not feasible to hide that it happened. Many steps can be taken to make it less obvious, but it will still be easy for software aware of it to detect. Even a massive overhaul designed to perfect it would not address the SSD itself giving away what happened for more advanced analysis. We aren't going to add a decoy profile compromising the security of the device and providing a way to recover data in a state where it isn't at all unrecoverable yet. We did already plan to consider a 2nd duress PIN/password which only wipes specific secondary profiles, but we need to make it clear that it cannot stealthily wipe them to users.

dredmorbius 1mo ago

This discussion was raised last time this story was discussed. I was among its advocates: <https://news.ycombinator.com/item?id=49061890 https://news.ycombinator.com/item?id=49061890>. Briefly: no. Less briefly: <https://news.ycombinator.com/item?id=49060780 https://news.ycombinator.com/item?id=49060780> and <https://news.ycombinator.com/item?id=49060716 https://news.ycombinator.com/item?id=49060716> (from the grapheneos HN account directly).

spacebanana7 1mo ago
Thanks for sharing - I get the concerns people have raised in those threads, however I still feel something in this space could be useful. Even a duress PIN which triggers predefined deletion of certain folders, messages and apps could reduce law enforcement exposure significantly.
- grapheneos 1mo ago
  Deleting arbitrary directories, messages and app data would be highly unreliable. There's a high likelihood of the data being recovered. It's not how computer filesystems and storage are designed to work. Reliable deletion of data requires setting it up to be reliably deleted later on by having it encrypted on storage with keys which can be reliably prevented from ever being obtained again. Wiping the overall data on the device via a factory reset, OS recovery mode or duress PIN/password prevents recovering any of the data because it reliably wipes material needed to derive key encryption keys and also reliably wipes the encrypted disk encryption keys. Wiping the encrypted disk encryption keys alone would not be good enough because they're stored on the SSD so imaging the SSD and restoring it could preserve the ability to recover the data. The way the key material needed to derive the key encryption keys is wiped prevents recovery via imaging the SSD mainly due to the secure element. There's already support for reliably wiping data at the granularity of Private Spaces and secondary users. Those have their own encryption keys and can be reliably deleted due to having their own Weaver slots in the secure element and other hardware-based security integration. Apps can also assorted generate encryption keys in the secure element and use those to encrypt data where it can be reliably deleted via wiping the hardware keystore keys. That requires apps built to have granular storage and encryption of their data. Despite it being possible to wipe a secondary user or Private Space reliably, the past existence of it and when it was wiped will be easily discoverable via the main Owner user and system data. Preventing discovery of those profiles having existed requires an overall wipe of the data. It isn't feasible to hide it without doing that and hiding it would involve a whole bunch of unreliable removal of data without a way to prevent recovery along with redoing a bunch of statistics and other metadata to hide that there was another profile until recently. For example, things like the battery and data usage stats directly refer to the profiles. Even hiding it from naive analysis not looking at the leftover data on storage would still require changing a bunch of things to hide it. Making data deletion of the data reliable for a whole profile or the whole data partition also requires a reboot or shutdown. Consider how much data gets loaded into the page cache and many other forms of data in the Linux kernel and other processes. Consider how much linger around in various kinds of registers, etc. including outside of the OS itself. Reboot or shutdown has code to get rid of this and the device sitting there turned off or booting again also gets rid of it. They were clearly going to hook his phone up to forensics software on a laptop and had done what they needed to do in order to justify it for their own policies. It would not make sense to set up everything they did simply to have someone non-technical manually sift through his apps. They have widespread access to forensic software and also more advanced software with exploits. They definitely have easy access to it at a major Atlanta airport. The adversary in this case is not a non-technical human but rather advanced software from Cellebrite who are fully aware of alternative operating systems and document information on it. Their documentation directly refers to GrapheneOS and has tables listing their (currently very limited) capabilities against it. This story got widespread news coverage and is widely known about. That should help make it clear how important it is for features to work against adversaries aware of these kinds of features. Our duress PIN/password works against adversaries aware of it. If they don't coerce a PIN/password from someone or don't enter a coerced PIN/password because they know it could be in use then the feature has worked. We want to improve the feature with secure element rate limiting integration in the future so that an OS exploit cannot be used to bypass it. The secure element already prevents an OS exploit from bypassing the limit of 20 total attempts for deriving encryption keys with massively increasing delays between those attempts. It used to solely be based on delays with throttling quickly reaching 1 attempt per day after 140 failed attempts but now there are only 20 total unique attempts. The past 5 failed unique attempts are temporarily remembered and discarded when entered again rather than trying to use them again for usability.
  - michaelt 1mo ago
    > Reliable deletion of data requires setting it up to be reliably deleted later on I mean - yes? If you design a subtle duress pin that only hides certain things, users would have to choose what. I myself want the bank apps, password manager and email to disappear without a trace, but I don’t care about the social media, photos or web browser history. Other people, though, will have different priorities.
    - dist-epoch 1mo ago
      You misunderstood the parent post, it's extremely difficult to delete the data without leaving a trace that something was deleted.
      - grapheneos 1mo ago
        To reliably delete a specific file or directory, it needs to be encrypted with a dedicated key which can be reliably deleted. It can have dedicated key material in the secure element used to derive sub-keys from the main encryption keys or it could simply be encrypted with another layer of encryption. For the OS disk encryption, it uses separate randomly generated disk encryption keys for the main user, secondary users and Private Spaces which are different forms of profiles. Those keys are stored encrypted with key encryption keys derived from the per-profile lock method combined with various forms of key derivation material from elsewhere. The most important of the key derivation material for profiles is the per-profile Weaver token on the secure element which it uses to enforce rate limiting for decryption attempts (max 20 attempts per profile with rapidly increasing delays) and to provide extremely reliable deletion of the data. Wiping the weaver slot for a profile prevents deriving the key encryption keys which prevents ever decrypting the randomly generated disk encryption keys again. The randomly generated disk encryption keys are only stored once and get wiped via a special SSD secure erase command but that isn't nearly as good as the secure element integration. If the SSD is imaged before a wipe and then restored, the data still isn't recoverable because the secure element wiped what's needed to decrypt the disk encryption keys. Reliably deleting data is a much different thing from fully hiding that anything was deleted which is drastically more difficult and not compatible with how things are typically done. It's pretty much impossible to stealthily delete a secondary profile since there's too much system and Owner user data referencing them including the package manager's state, battery stats, data usage stats and far more. It's possible to attempt to go through all of that and hide it including forging the other stats to mask what was removed but data cannot be reliably deleted in a fine-grained way, especially on top of a modern copy-on-write or log structured filesystem combined with an SSD controller doing wear leveling. An SSD controller will redirect writes to less written NAND than what is now being written to level out usage. That relies on it being aware of free storage to choose from that instead which is the purpose of TRIM. A modern SSD will also very proactively move around data rather than only redirecting writes to free space with less wear. It will identify the data that's rarely or never written and move it to the most written areas of the SSD to free up the space it was on for the most written data. Having 2TB of used space that's rarely ever touched, 1TB of a heavily written database and 1TB free will not only use the 2TB of active space for wear leveling with a modern SSD controller design. It will use the whole 4TB for it. A modern copy-on-write or log structured filesystem doesn't write to the location where the data was originally but rather elsewhere. Android uses f2fs which is log structured which heavily helps with wear leveling at a higher level and also provides the ability to turn off data persistence temporarily and then roll back to the point it was turned back in an incredibly efficient way. Android uses that incredibly efficient rollback feature as part of A/B updates to preserve the ability to fully roll back an OS update which doesn't end up working properly until after it reaches the lockscreen successfully. An app regularly appending data to a file, overwriting data in it or replacing the whole file is leaving data around all over the place. A decision can't simply be retroactively made to reliably delete the data for that file or the overall app. It would have had to be set up in a way that it can be reliably deleted. Without that, the whole secondary profile it's in is going to need to be deleted to reliably delete the data. If it's not in a secondary profile, the whole device needs to be wiped for it.
kelnos 1mo ago
I think for the case we're talking about here, though, it would be doable. This doesn't need to thwart deep forensic analysis. It just needs to survive a border agent thumbing through the contents of your phone for a bit. If the fake profile data looks plausible, and doesn't raise any flags, the agent gives the phone back and you're on your way. Hell, I think a setup that doesn't wipe anything, but just drops you into a sanitized, isolated profile for the border agent to look at, would be fine for many users. Certainly you wouldn't want to use this in truly high-stakes situations where it's likely that your device will be confiscated no matter what, and analyzed to death, but for the simple "border agent wants to snoop on my data for a few seconds" case, it's likely sufficient. (As always, risk analysis can be hard, humans are often bad at it, and not everyone's threat model is the same.)

NDlurker 1mo ago

Or put a dead man's switch on there

Gabrys1 1mo ago

Maybe it could cause the phone to "randomly" bootloop or something? "Oh no, my phone is broken again, last time this happened I needed to do a factory reset"

whycome 1mo ago
Private 0-day exploits? Have a phone with crappy battery and have it trigger a high processor load to take the battery voltage drop and turn off the phone? (Eg what Apple tried to prevent with the batterygate thing).
debugnik 1mo ago
This case happened precisely because the officers noticed the phone flash and reboot when they entered the pin. IIRC they didn't make a fuss over it, but time later he got charged over the event. So whatever a duress pin does, it has to be subtle enough that anyone looking doesn't link it to the act of entering the pin.

grapheneos 1mo ago

> I wonder whether it'd be better for a duress PIN to delete existing data Reliably deleting data at the scale of the whole data partition, a secondary user or a Private Space is fully supported but requires a reboot or shutdown to truly complete it. After wiping key derivation material needed to obtain the key encryption keys in multiple ways and wiping the encrypted disk encryption keys, the OS can still access the data. It still has data in the page cache, in registers and elsewhere. There are still a bunch of system processes with data tied to what was removed. The OS is still fully functional after the nearly instant wipe of everything needed to recover the data again. It can still access all data other than what's encrypted with hardware keystore keys and not currently decrypted. The wiping process for the duress PIN/password is completed with a shutdown which tears down everything, zeroes memory and provides at least a small time window where the hardware is powered off too. A reboot would also work and the boot process has explicit zeroing of memory, registers, etc. We decided to use shutdown for the duress PIN/pasword but a reboot is a valid approach too. Our locked device auto-reboot timer feature we first shipped in 2021 relies on the zeroing done by GrapheneOS for both the process of the OS tearing down and then again during booting to return the device to Before First Unlock state. > also create a semi plausible artificial profile to hide the deletion event. It isn't feasible to fool forensic software so it largely wouldn't work against state actors. It nearly certainly wouldn't have helped in this situation in the news. They aren't reliant on a non-technical person sifting through a phone. They'll just hook it up to a laptop and follow the data extraction procedure which involves enabling ADB. The software is aware of GrapheneOS can guide people through dealing with anything different about it. They've had a lot of trouble with extraction via ADB for GrapheneOS since the vulnerabilities they exploit via ADB keep getting patched or blocked it exploit protections but it isn't realistic to block extraction with them having the PIN/password. They could just enable the encrypted backup service in the OS instead and then use CLI tools to extract the data from there with the seed phrase. They don't do that because they want everything rather than only nearly all app data. They also have special code to deal with apps such as Signal with their own layer of data encryption since the data taken from their app data directory is nearly all useless by itself. There's also quite a difference between wiping and rebooting into a not very plausible environment with decoy data set up by the user in advance compared to not properly wiping and giving access to a decoy profile. Bear in mind the OS can still access nearly all data after the wipe until a reboot. It could make a best effort attempt at purging as much as possible from memory, but the OS is not designed to continue functioning with all of the data disappearing. It can't just wipe all loaded encryption keys without crashing and rebooting anyway. It also has a ton of data still around in caches and elsewhere. We don't want to just do a best effort job cleaning up as much as we can but rather reliably prevent recovering any of the deleted data. We could definitely add a duress PIN/password which wipes only specific secondary profiles, reboots and has the device still functional with whatever data was in the main user still there. That's a feature we can add, but it's important to note that it will not hide that there was deletion of data. It's easy to detect, and it's not feasible to hide that it happened. Many steps can be taken to make it less obvious, but it will still be easy for software aware of it to detect. Even a massive overhaul designed to perfect it would not address the SSD itself giving away what happened for more advanced analysis. We aren't going to add a decoy profile compromising the security of the device and providing a way to recover data in a state where it isn't at all unrecoverable yet. We did already plan to consider a 2nd duress PIN/password which only wipes specific secondary profiles, but we need to make it clear that it cannot stealthily wipe them to users.