[HN Gopher] MikroPhone: A privacy enhanced, simple and featured ...
___________________________________________________________________
MikroPhone: A privacy enhanced, simple and featured RISC-V mobile
phone
Author : voxadam
Score : 78 points
Date : 2024-10-03 15:41 UTC (7 hours ago)
(HTM) web link (mikrophone.net)
(TXT) w3m dump (mikrophone.net)
| p0w3n3d wrote:
| 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.
| phasnox wrote:
| You should try GrapheneOS
|
| It is basically Android with all the crap from Google removed.
| nvllsvm wrote:
| 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.
| skeptrune wrote:
| +1 Graphene works great
| metadat wrote:
| 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.
| Syonyk wrote:
| > _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.
| numpad0 wrote:
| 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.
| Syonyk wrote:
| 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.
| kebokyo wrote:
| 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.
| jdietrich wrote:
| The main processor is a very low-performance microcontroller,
| so even "featurephone" might be ambitious.
| Syonyk wrote:
| 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.
| 10xalphadev wrote:
| Ah, another privacy-oriented phone project. As if the Pine-,
| Libre-, Jolla-, Neo900- etc. etc. endeavours weren't successful
| enough.
| mmooss wrote:
| I was wondering - what is the status of those projects?
|
| And because they are (mostly?) open source, why not start with
| one of them?
| Syonyk wrote:
| 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. :/
| ziddoap wrote:
| 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.
| Syonyk wrote:
| > _...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.
| Neywiny wrote:
| 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.
| tredre3 wrote:
| > 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 just
| be just a guy experimenting and having fun! But I could see why
| someone might be cynical regarding this project being
| deliberately overly complicated just to extract more money from
| nlnet.
___________________________________________________________________
(page generated 2024-10-03 23:00 UTC)