| With all the respect what they have done so far, I can't see any reason why this is securer than the other mobile phones.. With the latest NSA stuff, I came to conclusion that a true secure system can only be built under these conditions and just to put it out there, this is just my opinion; - A computer company that manufactures their own hardware such as hard drive, ram, cables, network cards. - An OS that is newly written and not based on any other existing operating systems. - Building the whole system with INDEPENDENT hardware and software mentioned above. - Keeping the mobile device's source code offline from Internet as much as possible These are just the first steps on developing a secure system, then comes the mobile network architecture and encryption etc. I admit, it is not an easy job but, trying to develop a secure system with "not secure" development tools is not the right way to go :) |
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 :)