Threat modeling Duress code data wiping
The GrapheneOS data wiping function is in the news due to a customer now facing serious legal jeopardy for using it at a border crossing. I don’t know the details of the case not exactly how the duress feature works, but from public knowledge we certainly can talk about learning from this.
There must be better strategies and this is an excellent example of how threat modeling (typically applied to whole systems or components) is a great tool for evaluating design ideas to meet needs effectively. It’s also a great example of why it’s important to involve contributors beyond technical staff alone. Furthermore, it’s a great example of threats exceeding information security and privacy categories (e.g. STRIDE, LINDDUN), in this case the need to include legal threats.
Caveat: IANAL but I think this simplified analysis makes sense; IANAR but the suggested alternative following seems reasonable and at least worth considering as more choices for each individual to choose (I Am Not A Lawyer/Reporter). Immigration examiners have very broad discretion in general so the law does not strictly limit their actions as inspectors.
Here I’m only thinking of the immigration process as one common case. Here’s a simple threat model of the duress passcode initiated function:
- Information leak: data on the phone is destroyed.
- Legal considerations: exposure to evidence destruction and/or non-cooperation charges.
- Initiating the data wipe during the inspection does break the law.
- If carefully observed, any delay (quick sign in compared to data wipe including factor reset) is evidence of initiating the duress function.
While the technical aspects of the design, the residual legal consequences may be significant. Legal risk is very hard to mitigate by technical means, so what alternatives exist?
- Wipe the phone before entering the country (outside immigration jurisdiction).
- Data is safe and on examination no lying or elusive answers are needed.
- As a mitigation for elevated threats while traveling abroad it is quite reasonable.
- This does incur taking time to set up the phone (identical to out-of-box), however in typical use this should not be difficult or significantly time consuming. While this may feel like wasted effort when sailing through immigration, like all security methods it is a form of insurance against chances of a far greater problem occurring.
- Carrying no phone on the flight (leave your phone safely behind and rent a phone abroad) may be considered suspicious, but that seems weak
- Use multiple cloud accounts with one being “safe” (no sensitive data) and remove other accounts.
- Secret data is safe, looks normal, no problem having the phone contents inspected.
- This does require some effect quarantining data (data protection is always work).
Now that we know the duress function includes legal risk we can only hope that others learn quickly and stop using this at immigration. To be clear, the feature may be great for other scenarios such as criminal coercion.
It’s important to keep in mind that non-citizens crossing borders typically have fewer rights, including great discretion by authorities so they are much more exposed: I won’t attempt to detail that, but thorough legal mitigation is especially important for them. For example, carrying a reset phone or no phone at all may be deemed suspicious enough for a rigorous examination and questioning or even refusing entry.
One more idea to strengthen these non-technical alternative mitigations is worth mentioning. To mitigate to a degree the potential suspiciousness of no phone or factory reset state, industry organizations or employers of reporters can institute best practice policy suggesting or requiring some of these precautions to document it as standard operating procedure.
As this case shows, threat modeling is the best way I know of to evaluate software features, including other stakeholders, including real world threats in situations where the technology interacts with human factors. Just one more reason to threat model.