Hi there,
I am pretty sold on some of the use cases of the Librem 5, for example source code open, hardware switches for radios, etc.
I am curious if there is any advice for those entering airports and other contexts where they may be asked to give pin #s, allow phone search behind closed doors, etc.
What is the recommended procedure for privacy assuming physical access by 3rd parties? Is there any TPM/Evil Maid attack mitigation?
the librem 5 by purism will be like no other smartphone around. the question isn’t weather you are protected by this or that it is : “can i find something better for my needs at this point in time?”
For sure.
And some of this is more a of problem of software than of hardware. I wonder if a personal server or cloud vm or something is the answer, where files are stored there and decrypted/displayed locally.
I wonder if there is a way to tell the kernel not to swap certain apps’ memory to local storage? I hope to see something that will do this. Or maybe it is easier to make a small buffer of decrypted contents, which moves like a window over a larger encrypted buffer, only decrypting the current block in the window?
Anyway, I hope to support the project, perhaps by buying the phone soon. I am a little loath to purchase from the first run.
Regardless of any future goals, I would say I am behind the project, no matter what flaws may be apparent; a phone for the user is a truly great achievement. (I hate to see comments from the Objectors who would criticize the Wright Brothers for failing to get to Mars.)
You’re actually hitting on something that could enable the Librem 5 to become an enterprise-class device as well. Data encryption, key management, and secure enclaves for sensitive bits are all things that mature MDM solutions, e.g. VMware Workspace ONE, enable for iOS (and Android to a lesser but still great degree).
Both cases deal with data privacy; The latter’s goal is protecting company data within a BYOD consumer device, whereas the former seeks to protect data from the prying eyes of government. Different motivations, similar result. It would be a case of convergent evolution.
(New here, first post).
Two possibilities come to mind:
One, a “terminal only” mode where the device remembers exactly nothing. You would have to log into a secure server or plug in an external local storage device to do anything beyond phone calls and perhaps text messages (and of course there would be no memory of incoming or outgoing phone numbers). (Optionally, a bare-bones browser that remembered nothing when windows were closed.) Servers could be set up by the Purism organization or, perhaps more effectively since less impact on Purism resources, by vetted & approved third parties. (OTOH, monthly fees for server accounts could become a revenue source for Purism.)
If you select “terminal only,” you would be directed to a list of approved secure servers or external local storage options for backing up whatever data were on the Librem5 device. Then with another prompt, the device would erase its data caches and convert to terminal mode.
Two, “duress accounts.” You set up a “duress account” for future use: userID and password. When logged into the duress account, all you can access is what you’ve done in that account. Ideal case, users will use these accounts frequently enough for things they don’t object to hostile third-parties seeing, that they compile “reasonable” user data for hostiles to view.
The first-level duress userID & password would merely open into the duress account. But a second duress userID & password would also simultaneously erase all the data stored in the device under the primary “real” user account.
Now you have three userID/PW combinations to remember: your primary “real” one, your “casual duress” one, and your “duress/nuke” one. But using semantic passphrases makes PWs easy to remember (and harder to crack), so this is manageable.
One other thing I’d suggest re. terminal-only accounts and duress accounts, is to enable users to set a different background screen color or image for each account (primary, terminal-only, casual duress, and duress/nuke) and different audible tones for notifications, so users have additional feedback against erroneous logins.
Thoughts?
For your terminal-only mode, are you envisioning this only be enabled by the user prior to a risky situation (e.g. airport travel)? Or all the time? If the latter, I think that would lean too far inconvenient on the security vs. convenience spectrum. If the former, isn’t that similar to wiping my Android device followed later by signing in with my Google credentials to Google servers (aka a secure, vendor-managed server which syncs my personal data)? Not a bad idea. It’s also possible I’m not tracking your idea correctly.
I like the duress account idea better. I just fear what you note at the end about erroneous logins. It would be a shame to casually nuke my device because I used the wrong (yet valid) set of credentials. 
Hi Jon -
Someone could enable terminal-only before going into risky situations such as where the device could be stolen, or they could leave it in terminal mode all the time as their default login option. Everyone has their own preferred point on the security/convenience spectrum, so the ideal case is that users could configure their primary account as they choose, and then toggle in and out of terminal mode when needed.
For corporate clients, add the ability for Admin to lock down settings per company policy, to prevent users accidentally or deliberately doing things that increase risk or screw up the device configuration.
For duress accounts: the risk of accidentally wiping the device could be limited as follows, for all accounts on the device:
Turn on device; opens with gray screen with “userID” & “password” and keyboard. Enter credentials. Screen changes to color, image, or pattern associated with those credentials, message appears: “click Continue or Go Back” This, regardless of whether any duress accounts exist or not, to prevent hostiles noticing an extra prompt as a sign of duress account login. Now you’ve got one more chance to choose whether to abort or nuke it.
Understood that people tend to use muscle memory to click through screens, but we have to assume a minimum threshold of acceptable mindfulness for doing anything more than sleeping. There will be sad stories, but fewer and less-sad than if people are susceptible to getting hijacked.
Now while we’re at it, one of the configurable options in the duress accounts should be a “call for help” option that signals a server to trigger any or all of the following:
Call one or more telephone numbers and play a message the user has recorded in advance, e.g. “This is an emergency. This is Alice calling. I’m in a duress situation. Please follow company procedures to locate me.” Message repeats for 2 minutes (in case it reaches voicemail) and then hangs up. (The dialing protocol would need to allow for pauses such as if it reaches a voicemail menu and has to dial an extension.)
Send a pre-written text message to one or more designated destinations.
Send a pre-written email message to one or more designated destinations.
The user’s main account would have options for testing the “call for help” functions, so they could be set up in advance and tested ahead of need.
The signal to the server would be the minimum quantity of bytes needed to authenticate and trigger the action, which should be possible to accomplish within a ping payload. The server would ack by returning a ping to the device, with a payload that authenticated the server: this would cause the device to stop sending the “call for help” signal.
And of course, similar but non-duress routines could be used in the non-duress account modes, to prevent hostiles recognizing duress mode by the presence of the help transmissions.
Wouldn’t it be nice to live in a world where all of this isn’t necessary? Between now and then, the thing to do is make it so regular, routine, and easy, for people to protect themselves, as to deter at least some types of attack and make some others substantially more difficult.
For the TPM/Evil Maid part of your question, we intend on porting PureBoot over to the Librem 5 so you will get similar tamper detection of the boot firmware and /boot files.
With respect to travel, the best advice I can give for protecting against exposing sensitive data either from lawful seizure or from theft when traveling is to travel without the sensitive data to begin with, if you can, such that you can 100% comply with any customs or border agents in whatever country you are visiting.
A lot of geeks have fun putting on their “international spy/smuggler” hat and come up with a lot of elaborate measures whether it’s hidden partitions, steganography, or panic codes that wipe their storage. The problem is that they aren’t international spies, but customs agents in every country are professional human lie detectors. People try to lie to customs agents every day so they can traffic drugs and other contraband across borders. Your average geek is kidding themselves if they think they could somehow smuggle data hidden on a phone across a border without showing the kind of non-verbal cues these agents are trained to pick up on. Not complying with a lawful search risks your being detained and most likely means the electronics themselves will be confiscated. The best plan is one where you can fully comply and lose nothing.
Beyond the movie spy threats, the more common threat is that you lose your phone while traveling, either accidentally or because of theft. You are at a much higher risk of any of these things happening when traveling so ideally your phone would only contain the information/applications/etc. that you need while traveling and wouldn’t contain information you don’t need.
For what it’s worth, I’m personally working on an approach to address concerns about losing sensitive data while traveling. While I’m not quite ready to announce our approach, I figured it was worth letting you know that first, it’s something that we are thinking about and working on, and second, my general philosophy about the best ways (and worst ways) to tackle these problems.
Keep an eye out on our blog. I should be ready to announce something in the coming months.