September 28, 2018
We are finally getting to the deeper end a lot of people have been waiting for, the connectivity issues, solutions and our decisions.
If you haven’t already, go read our miniseries on securing the freedom of mobile. Read it here.
One could argue that WiFi-chips and Baseband modems are the most vulnerable parts of the mobile phone. They catch radio signals from the air and try to interpret them. In most phones these chips also have access to the device memory and CPU without any authentication or protection which can lead to pretty nasty exploits and vulnerabilities like the BroadPwn for example.
In practice this means that no matter how and which E2E encrypted messaging, or any application for that matter, is used, encryption keys can be accessed via these chips with their direct memory access. No matter which OS or application one uses if WiFi or Baseband modems have direct access to memory. Game over. This is the case for majority of mobile devices and was demonstrated by the Bluetooth based Blueborne exploit. Your connectivity has generally been ‘their’ side channel access to your RAM.
These things are always closed source and have had plenty of security holes in them. There are also well known and documented backdoors built in these devices utilizing the modem.
These chips having access to memory is one major security concern. Other is the ability to gain users real-time location data. More sinister techniques involve the notorious SS7 layer snooping and attacks. NSA’s involment has been publicly known for many years now.
The obvious solution would be create these components with Open Source firmware but that seems to be impossible since radio frequencies and devices using and sending them are heavily regulated for number of reasons.
The other solution is to isolate this closed component completely and not allow any access to the device CPU or memory. This can be very effective although it does not conform to the FOSS ideologies. Other solutions include using wired connections or having physical kill switches for these ‘grey’ components.
We have tackled these issues in a way which satisfies our enterprise customers and hopefully we will find a way (if we don’t already) to satisfy you, the mobile FOSS community.
Our device features 100 Mbit/s Ethernet for wired internet access. With Ethernet port, possible use cases for our device are far beyond normal ‘mobile phone’.
For obvious security reasons our first evolution devices wont have cellular module included. But we know how important this might be to you, so we are in active discussion with carrier partners to enable cellular (LTE) and other wireless IP connectivity. In our opinion ‘being mobile’ is not same as a mobile phone.
For FCC/CE certifications WiFi-chip in our device must include ‘regulative firmware’ but we are looking ways to overcome this, to reclaim our ‘0% closed firmware’ claim. Even if we had to include this ‘regulative firmware’ the WiFi-chip is behind SDIO to ensure there is no access to device memory.
Last wired connectivity option in our device is serial communication interface. This enables full console access for us via 3V3 solder pads. We are looking into an option to have a choice to order our device with screen detached (but glue applied for easy installation) so FOSS community can have direct serial access aswell.
Lastly we would like to hear your opinions for connectivity and component choices as we might have an option to produce devices with different configuration combinations. Please contact us at firstname.lastname@example.org if you have ideas or preferences for connectivity and component choices. Also we are open for all collaboration or any other suggestions for us. We are big fans of all of you!
Stay tuned for more