It's a bit of an annoyance when products talk a lot about "privacy" and "security", but never once mention what sort of threat model they are private/secure against.
Then add in something like a bespoke (unvetted?) communication protocol on top and my eyes really start to roll.
The people who really want privacy & security enough to be willing to buy something like this will want a lot more detail than what is offered here.
> ...but never once mention what sort of threat model they are private/secure against.
You know, they're Secure(TM)! Against Threats(TM)! Buy me if you're scared of Threats(TM)!
Threat modeling ("Secure from who? Under what conditions?") sort of stuff just doesn't seem to be a thing that's taught these days outside certain weird circles. And certainly something this project hasn't touched on in the slightest. But, yes, I was having to keep my eyeballs constrained too.
As much as it pains me, I think the most "generally secure phone" out there, for at least the sort of threat models this phone handwaves at (journalists, human rights activists) is a recent (last generation or two) iPhone with Lockdown enabled - and then shut down nightly, and carried shut down through any sort of sensitive environments. I would be inclined to go with an iPhone SE3, moreso than one of the mainline devices, simply for fingerprint scanning versus the FaceID stuff. You can't "point a phone at me" and unlock it with my fingerprint, but you can with FaceID in a wide enough range of situations to be concerning. Set a longer than usual PIN/passphrase, and be careful where you enter it.
As far as I understand the boot process, Apple has largely fixed a lot of the "before first unlock" type attacks with their secure enclave. They fixed that rather well after the battle with the FBI, and seem to have continued hardening and improving that process (hence my recommendation for the latest generation or two of device - there are changes in the boot security flows every now and then, and I assume they matter, at some point).
Then Lockdown, as near as I can tell, does a very fine job of simply closing the common attack points used. Most of the "good" attacks on iPhone users (at least the ones I know of...) are through the various "texting-esque" endpoints with weird image formats, or a browser based Javascript/JIT exploit, and Lockdown does a fine job of simply refusing most of the paths these use. Weird image formats simply aren't rendered. URLs in text messages aren't accessed and previewed. The Javascript engine removes all JIT capabilities, WebRTC, WebGL, and other "suitably complex that it's probably exploitable" sort of features.
It's not perfect, but were I an individual who believed I was under actual threat for this sort of stuff, I'd 100% use a secured iPhone (possibly with some of the Mobile Device Management features configured by a trusted person to disable the USB port and such things) over a random device like this. Sorry, open JTAG ports means it's "comically insecure" against anyone with local access and the time to bother doing anything with it.
And of course, don't keep location services on, don't install a ton of apps, etc. The usual if you're concerned about any of this.
I don't like that this is the state of the world of secure computing, but it certainly seems to be it, to me.
This is like, barely risc-v. As far as I can tell, there's a risc-v management micro, an esp32 that I'm not easily finding a part number for so may as well be Tenscilica, and an app processor that's ARM based. I don't understand the GPU chip if you have the app processor, and I don't understand the management micro if you have custom ESP32 firmware. And a lot of SoMs have WiFi + Bluetooth on board. So I also don't understand the ESP32. This really feels like it could be a card-edge SOM, battery, HMI, and modem. As per usual I find this project needlessly complicated and buzzwordy.
> an esp32 that I'm not easily finding a part number for so may as well be Tenscilica
On their dev board it's the usual esp32-wroom. They also say their esp32 firmware needs esp-idf 4.2, which doesn't support any of the risc-v esp32. So it is xtensa.
I agree that everything could be done with the esp32 alone (well, an wrover with extra RAM) but this project seems to be just a guy experimenting and having fun! Although I can see how someone might be cynical regarding this project being deliberately complicated/overengineered just to extract more money from the nlnet fund.
My pet peeve on open-source, *-focused hardware: it should start with an artistic sketch and a mockup, not the final board and a shell wrapped around as an afterthought.
Valve[1] reportedly made over 100 mockups before settling on the final shape, most of them representing shapes only. Apple[2] had at least five iterations of nearly indistinguishable mockups for one of iPhone models that were discovered by fans.
It is certainly possible to build a radio equipment by starting from a block diagram and installation into enclosure, but that's development process for low volume technical instruments which measure of utility is electronic performance. A consumer product should look and feel good in hand, even when it's dead.
1: https://www.rockpapershotgun.com/valves-steam-deck-prototype...
Hm. I'm not sure what to make of this, really.
The concept of a RISC-V based "assemble it yourself" phone is solid enough - there have been the PiPhone concepts based around a Pi Zero for long enough, and while I don't think they're terribly usable, they're also a fun looking little project.
But then they throw the ElipticCP concept on top, and sort of handwave it being "secure" if you're talking to someone else who is using a similar device, or similar capabilities, or such. And, unfortunately, there's not a lot of information about that I'm seeing (or, that which there is seems rather vague and handwaving).
https://mikrophone.net/about.html
> The security of the whole system is not compromised even though none of these modules is trusted, because all sensitive data is encrypted by the central MCU before sending it to a communication module. Secure communication uses a protocol EllipticCP originally designed for this project. It provides end-to-end encryption and an additional anonymizing layer based on the principle of onion routing. In order for a security protocol to function to its full extent, the end recipient in the communication channel also needs to use mikroPhone or some other phone with comparable security performances (in other words, both communication parties must be secure enough).
There's a lot of words in here that sound good, but there's a serious lack of details, and then when you go to build the phone, you have open JTAG ports to the device.
So I'm not really sure what threat model they're dealing with exactly. "People who can build their own hardware and firmware, who work in investigative journalism or human rights activists, who have iron clad control over their hardware, who want to talk to other people with identical hardware," maybe? It seems designed to counter remote threats only, and without a lot more details as to what it's doing, it's hard to say if it is or isn't doing that competently. I don't have the time right now to go dig through their firmware to see, unfortunately.
If it weren't a build it yourself sort of thing ("Here's the schematics, go get boards fabricated!") it would trip my honeypot sensors ("Secure Phones!" being more government ops than anything actually useful, IMO), but... it's not that, fairly obviously?
Dunno. I doubt it would work on any US carriers, they're all VoLTE only now. :/
Tbh I would accept anything usable without being bound neither to Google nor Apple. Like a Linux phone but with usable apps which is quite important.
For example Samsung gets free MP3 player and more important, background-running voice recorder, which is extremely important for me, but was impossible to find on OnePlus One.
You should try GrapheneOS
It is basically Android with all the crap from Google removed.
Better yet, GrapheneOS allows you you sandbox Google's crap if you need or want it. Very useful when needing to use a proprietary app that requires it.
+1 Graphene works great
Ah, another privacy-oriented phone project. As if the Pine-, Libre-, Jolla-, Neo900- etc. etc. endeavours weren't successful enough.
I was wondering - what is the status of those projects?
And because they are (mostly?) open source, why not start with one of them?
This looks really cool! I don’t know if this more of a feature phone or a smart phone though. Would like to see pictures of completed builds and what they can do.
Looking at the hardware, it's likely to be a "mostly usable interface to a cell modem." So, SMS, audio. No idea if it can handle MMS or not. And anything beyond that is iffy.
They've got some interesting concepts for a separate application processor that can route to the screen, but... right now, consider it the sort of project to build if you don't actually need to talk to anyone with any reliability.
The main processor is a very low-performance microcontroller, so even "featurephone" might be ambitious.
What is the cost for the hardware BoM?
Also curious why someone is motivated? Pretty great, would love a 3rd alternative option to Apple and Android.
Mostly I care about phone calls, texting, and web browsing.
> Mostly I care about phone calls, texting, and web browsing.
"Easy, Easy, Brutally Difficult."
If all you want is phone and text, there's no shortage of cheaper flip phone/candybar phones out there that handle it, though I will caution you that older versions of KaiOS, at least, struggle badly with handling any sort of modern text quantities (a few hundred messages on a phone on a KaiOS 2.x device lagged it badly enough that it stopped alerting me to new messages or phone calls, and I had to trim it down regularly, though even then it struggled).
I'm a fan of the Sonim stuff, it runs Android Go, and is properly stout.
Web browsing, though. That's hard. If you want a simple phone, your best bet is to carry a tablet or laptop for that sort of thing, and just hotspot off the phone if/when needed. Most current featurephones have a thing called a web browser, and it ranges from "almost useless" to "literally can't render the modern web." That's before you sort out using it on what is typically a 320x240 pixel display. You're way better off just carrying something different for that need.
Isn't that the other way around? I thought voice is usually the most complicated to implement, especially in 4G/5G which uses modified SIP/RTP. Mic and speaker has to work too. Web browsing OTOH at bare minimum require just simulated PPP over AT command interface, touchscreen, and Chromium.
If you're building your own cell modem, then, probably.
In terms of "finding hardware that can do the following things," pretty much any cell phone sold will support voice and text - though some don't do a great job with MMS. The web browser requires orders of magnitude more resources than voice/text, though. A Nokia from 20 years ago, with... I actually can't find how much RAM or storage, had no problems with voice or text. Wouldn't run a browser at all, though.
I was admittedly of the impression that most of the voice work was handled by the baseband, though. I've not built my own phones, unfortunately. I just use some basic flip phones for mobile use.