| You're probably right about what's involved in building a truly secure smartphone from scratch that we can trust. 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 :) |
We may as well try it out! The concern will be the goal of the project...
What will be the output ?
Will it be just an experiment or business based project?
Never the less, it is exciting to see that a unique device can be made actually!
I would love to see how secure it would be at the end!