So the part of this that feels like it triggers the government issue here is that in effect you have a locally stored encryption key which gates access to the device, which was removed from the device due to duress password.

What if we flipped this to instead be something that's explicitly not on the device?

The border search stuff only applies to information on the device. It cannot compel you to provide access to e.g. emails stored in a cloud provider.

If instead of making the process of stopping searches like this be a destructive one, we instead pre-purge the key but store it offsite with the ability to get it from an online location, then this feels like it's probably reasonable here. In the sense that the 4th amendment explicitly allows "The right of the people to be secure in their persons, houses, papers, and effects, ..."

There's probably some sort of technical problem I'm missing here (or maybe this functionality is available already).

▲

fedpost an hour ago | parent | next [-]

Yeah, so caveat emptor: the legal system isn't something you can hack like a computer...

But...

The issue at hand is the "locality" of the encryption header. He merely facilitated its deletion, not the data.

If he had a backup at home, is that still a felony?

What about if he had a backup on a flash drive with him?

What if he never had the header on the phone to begin with and used a detached header on a flash drive?

Are detached headers (a thing you can easily do with LUKS) now de-facto illegal?

This whole thing is making me feel rather uneasy about the bigger picture.

▲

joshka 38 minutes ago | parent [-]

See https://www.cbp.gov/document/directives/cbp-directive-no-334...

> The border search will include an examination of only the information that is resident upon the device and accessible through the device's operating system or through other software, tools, or applications. Officers may not intentionally use the device to access information that is solely stored remotely. To avoid retrieving or accessing information stored remotely and not otherwise present on the device, officers will either request that the traveler disable connectivity to any network ( e.g., by placing the device in airplane mode and disabling Bluetooth and Wi-Fi connections) or where warranted by national security, law enforcement, officer safety, or other operational considerations, officers will themselves disable network connectivity. Officers should also take care to ensure, throughout the course of a border search, that they do not take actions that would make any changes to the contents of the device.

and

> Passcodes or other means of access obtained during a border inspection will only be utilized to facilitate the inspection of devices and information subject to border search. Passcodes or other means of access may not be utilized to access information that is only stored remotely. Passcodes or other means of access should only be recorded by the officer in a temporary format and should not be uploaded into CBP systems. Passcodes or other means of access recorded by the officer will be deleted or destroyed when no longer needed to facilitate the search of a given device.

	▲	fedpost 31 minutes ago \| parent [-]
		I'm not sure what you're trying to say

▲

vineyardmike an hour ago | parent | prev [-]

> or maybe this functionality is available already

Basically already exists depending on specific trade offs and risk profile.

You already can encrypt your data and store the encryption key offsite. But then you couldn’t use your phone during travel, if you toss the key locally.

You can encrypt the data at rest and leave the decryption key in RAM and just turn off your phone. But they can still take the phone and copy the encrypted data, if they think they’ll get the key later.

My understanding is that this individual would t want the government to access the encrypted data either.

	▲	joshka an hour ago \| parent [-]
		I'm talking specifically about the graphene OS ability for that approach, not the ability to add an external key to some generalized encryption. The threat model here is that the traveler was required to provide a passcode unlocking a key they had with them on their phone. If that threat is not there, then this bypasses problem.