Blackphone

The first connotation is the one my mother warned me about. It's Facebook photos of that tequila weekend in Tijuana and those two PM Tuesday tweets from the beach bar when I called in sick to work. These are things that require personal judgement in regard to what I say. Self-control addresses this type of privacy.

The second connotation of privacy is newer, but still nearly twenty years old. It entails concerns regarding information collected about my actions beyond what I explicitly choose to broadcast. It's cookies in the browser [and their more sophisticated descendants]. It's my browser linking my Google+ account to my browsing history at lesbiandwarffurries.com.

Privacy issues of this second type are assumed to be normal when they are considered at all - why doesn't my browser sandbox cookies for each website? Or rather why isn't there a browser that does so? The same logic underpins the Blackphone - sand boxing unrelated parts of the system so that privacy is a matter of personal judgement rather a battle against a technically sophisticated adversary.

(The first shipped Kitkat builds supported a form of this, but it was quickly removed, amidst complaints from privacy advocates:

https://www.eff.org/deeplinks/2013/12/google-removes-vital-p...

So, there are a few shipped phones which can have this functionality made accessible via third party app --- but update your phone and they cease to work.)

It's an interesting thought experiment, but I wonder if we can satisfy many use cases without having to build a truly secure smartphone.

For example, if I just want to have voice calls to a handful of people with the content of the calls encrypted, then perhaps I can just plug in a "scrambler box" between my untrusted off-the-shelf phone and my audio headset?

So rather than designing a secure phone where we trust the wifi stack, the baseband stack, the bluetooth stack, the graphics stack, the USB stack, the flash storage stack because we've designed them from scratch, all we have to design is a little scrambler box that just has audio in, audio out, some mechanism for key generation and exchange, and only needs a laughably modest CPU to do the encryption.

Don't really need an OS at all - single process and static memory allocation should suffice.

The audio encoding/decoding and encryption/decryption don't sound too hard to implement from scratch. It's the interoperability with the rest of the world and the UI that makes implementing a whole smartphone so hard.

[I do wonder though how well our scrambled audio will make it through the phone network which is applying lots of clever compression designed for speech.]

If we assume we can mostly trust hardware designs that are at least 30 years old then we can probably avoid designing all the hardware from scratch - e.g. there's probably some sort of Z80 clone CPU we can copy.

The mechanism for key generation and management sounds a bit tricky though. The user would need some way to add his contacts' keys to his scrambler box.

A keyboard and LCD display to type keys in by hand would be secure but impractical for long keys.

The level of tech needed to read a key file from a FAT filing system on a USB stick might be too high to be easily implemented securely. Any ideas?

I'm aware of the famous "trusting trust" paper, but I'm not sure we need to worry too much about the compiler used to build the software running on our scrambler box. All we need to do is choose a compiler released before we started out project and never upgrade it. It is hard to imagine a compiler backdoor that would automatically recognize that the intent of our code is to encrypt data and undetectably comprise it (though it would be wise I guess to avoid any existing implementations of cryptographic primitives).

Sounds like a hardware kickstarter project :)