8 ms·
MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone
- notorandit 2y ago> 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. No way. You need to decrypt that stuff before sending it to the communication modules (BT, WiFi, cellular, display) and you get them unencrypted from the same. If the communication modules can decrypt the stream themselves, then eavesdropping will happen there inside.
- teddyh 2y ago> Software licensed under the GPLv2 Good for you, you get a cookie. Get back to me when you have a RYF certification and we’ll talk sales.
- teddyh 2y agoYou traded the Bluesmobile for this?
- theamk 2y agoNote that esp32 (and esp8266) use proprietary, closed-source network stacks[0] It's not a important in this project as there is a separate "main" MCU, but having radio module with closed-source software, active radios, and which you pass unencrypted data through (like bluetooth audio) might concern some people. (The SIM module is likely closed-source too, but hopefully it's impact is much more limited - if you care about privacy, you would not send any data over cell phone networks unencrypted) [0] https://github.com/espressif/esp32-wifi-lib/issues/1 https://github.com/espressif/esp32-wifi-lib/issues/1
- motohagiography 2y agoless a criticism (as this is a fantastic project) and more a general comment about security protocols. The protocol (https://mikrophone.net/ecp.html https://mikrophone.net/ecp.html) for privacy appears to require another MikroPhone device on the other side to communicate with. the cryptographic backdoors I have encountered in my work were in closed loop systems where having a standards based interface to facilitate separate or independent implementations would have foiled the schemes, as replicating the sabotage in another project would have been far more complex. the first student project is building this, the next really interesting one is reasoning about that security protocol. the ideal protocol described provides good forward secrecy, and speculatively if I were looking for implementation sabotage I would look for where the padding nulls were used instead of bytes of the nonce to reduce its entropy to something brute-forcible, and off hand as far as threads to pull, whether the parity bit on the key could reduce the search space by %50 as either even or odd. from a design perspective, if it only talks to copies of itself, why add the complexity of a new protocol? from a mass interception perspective, the "don't roll your own crypto" cliché is probably one of the most successful psyops of all time and I don't think it's a useful admonition in this case, but imo the question of "why" for a new protocol is the most interesting one.
- 6SixTy 2y agoWhy is this being pitched as a complete solution? There's no concrete explanation why it's more secure, just open source software = secure while rolling it's own stuff; and there's baffling component choices that completely conflict with each other. A color 400x840 screen is not needed for a "simple" phone, and having any possibility of redundant BT/WiFi radios is a baffling oversight. There's 2 different ideas here, and instead of splitting them up into their own discrete projects that can excel at both ideas, they are turned into 1 mediocre project. Also, exposing JTAG in your final product and forgetting about physical security aren't good looks either.
- p0w3n3d 2y agoTbh 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.
- nextos 2y agoJolla's Sailfish is another alternative. Linux, quite a few native apps and an Android emulation layer that makes it easy to use most F-Droid and Play Store applications.
- phasnox 2y agoYou should try GrapheneOS It is basically Android with all the crap from Google removed.
- canadiantim 2y agoIs Librem 5 not such a device?
- fsflover 2y agoAnd it can run Android apps with Waydroid.
- My2Cents276366 2y agoAs an owner and occasionally serious user of the above device, I can say that, no, it is not usable as a phone by any definition that includes portability. This is due to extreme bulk and still terrible battery life, even before we get to the experience of using PureOS and Gnome for your phone OS. However, the kill switches are super cool and would be practical if the device were.
- metadat 2y agoWhat 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 2y ago> 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 2y agoIsn'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.
- tonyg 2y agoAs recently as the Samsung Galaxy S7, Pinephone, etc., voice calls are done with high-level commands too. All you have to do is get the soundcard mixer settings right. Figuring out the correct settings is tricky but once you have them it's plain sailing. Web browsers have a very broad interface with the underlying system. Speaking from experience: getting calls and text working is much easier than getting a browser going in a new environment.
- kebokyo 2y agoThis 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 2y agoThe main processor is a very low-performance microcontroller, so even "featurephone" might be ambitious.
- Syonyk 2y agoLooking 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.
- numpad0 2y agoCurrent status section mentions "3d printable phone case designed in FreeCAD", but there don't seem to be corresponding file. I think the project is practically in breadboard stage.
- 10xalphadev 2y agoAh, another privacy-oriented phone project. As if the Pine-, Libre-, Jolla-, Neo900- etc. etc. endeavours weren't successful enough.
- mmooss 2y agoI was wondering - what is the status of those projects? And because they are (mostly?) open source, why not start with one of them?
- finaard 2y agoThe problem is the hardware, not the software. Also, what you want as a paranoid person is your baseband not part of the SoC running your computer - this project hear does that, Jolla and others are using standard Android SoCs. Jolla added libhybris to make it easy to use Android hardware adaptations - which at that time was needed to get a phone out (ste, which the first Jolla phone was supposed to be based on, decided to get out of the phone chip business during the prototyping phase, and that was the last vendor offering proper Linux drivers). I never was much of a fan of that as you just pull in way too much uncontrollable crap - unfortunately it works good enough that a lot of other projects then also jumped on that, instead of reviving a focus of doing proper Linux drivers (something I was worried might happen when the libhybris development started).
- hedora 2y agoI'd argue software is the main problem. If you want to make a new smartphone OS, just target a pixel or something. The driver + kernel stack as pretty close to as open as you'll find anywhere. The hardware is flagship-grade, updated every year, and shipping now. I've had zero luck putting a non-Android daily driver OS on it though. I'll define daily driver as "all of this works tolerably well": Phone, SMS/MMS, web browser, podcasts, navigation, music player and camera. Heck, drop the camera requirement for version one, and then you're down to "video, audio, GPS and phone stuff works".
- 2y ago
- Syonyk 2y agoHm. 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 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 2y agoIt'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.
- wepple 2y agoOr _who_ is leading this project. There’s a gigantic difference between someone who has experience designing and building complex systems to be secure and private… and someone who thinks “how hard can this be? There’s gotta be a market for it!” I can’t tell which one this is
- lizknope 2y agoHow the FBI's fake cell phone company put criminals into real jail cells https://www.npr.org/2024/05/31/1197959218/fbi-phone-company-anom https://www.npr.org/2024/05/31/1197959218/fbi-phone-company-... https://www.theverge.com/2024/5/23/24163389/joseph-cox-dark-wire-fbi-phone-startup-anom-criminals-secure-messaging-decoder-interview https://www.theverge.com/2024/5/23/24163389/joseph-cox-dark-... I remember this story. The FBI created cell phone business targeting criminals. They got criminals to believe it was a secure network all while listening in.
- joemazerino 2y agoThere is a distinct difference between a publicly offered MikroPhone and a phone swapped between criminals. Not every phone is some honeypot.
- lazyeye 2y agoDark Wire by Joseph Cox covers the whole story https://www.amazon.com/Dark-Wire-Incredible-Largest-Operation/dp/B0CKNP2Z8B/ https://www.amazon.com/Dark-Wire-Incredible-Largest-Operatio... It was a real conundrum for law enforcement agencies because at some point they had to stop facilitating crime and start exposing it.
- Neywiny 2y agoThis 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.
- mshockwave 2y agoI was just wrapping my head around on how do they even run linux on the RISC-V microcontroller they use. Turns out there is a separate ARM for application processor.
- Neywiny 2y agoYeah. As I'm sure you're aware, you can get Linux capable RV. I mean you can build mmu-less as well but there's plenty of I think it's M extension cores out there. This isn't that. This is a design that happens to use at least one RV core and happens to be capable of hosting a modem card. It's not a RISC-V mobile phone.
- entropicdrifter 2y agoFrom what I can tell, the RISC-V processor handles all of the phone functionality in a way that's almost entirely decoupled from the app-module/smartphone features. The phone part has its own firmware and drives the screen separately from the app-module. They added a green indicator light to show when the RISC-V "core" is using the screen vs when the app-module is. The graphics processor is probably just for when the RISC-V core takes over the screen, as well.
- Neywiny 2y agoWhat's the purpose though? You can put your own code on the app processor too. I don't know Android kernel dev but presumably with aosp you can do whatever the RV core does either in the A class core or using one of the many SoMs with built-in M class cores.
- numpad0 2y agoMy 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-prototypes-the-best-the-worst-and-the-utterly-cursed https://www.rockpapershotgun.com/valves-steam-deck-prototype... 2: https://www.youtube.com/watch?v=GXAsLCAbNGY https://www.youtube.com/watch?v=GXAsLCAbNGY
- explodingwaffle 2y agoI wouldn’t call it a pet peeve but I understand where you’re coming from with this: but I think the main reason for it is electronic engineers, with little-to-no product design or even mechanical design/CAD background. IMO it’s a shame: it’s sort of like the open source hardware version of the “Blender before it got good UX” problem.
- Joel_Mckay 2y agoAs someone that builds hardware all the time, your opinion is actually quite a common bias. The Idea that physical design (and aesthetics were important to Steve Jobs) can somehow reliably define the final technical form-factor is naive, and often leads to impractical products or vaporware. Usually it is the common mistake that creates every camera that overheats, usb-c port that snaps off, or power adapter the size of a brick. Apple could have made the new iPad battery last another 2 hours, or make it 1.7mm thinner... They made it thinner, and provided less value to consumers in newer products. In general, one MUST transition through every stage of the TRL or are bound to repeat the process from the start again at some point. Part of design revisions is figuring out whats possible (including physical volume constraints) with current technology, and whats appropriate in the projected market. https://en.wikipedia.org/wiki/Technology_readiness_level https://en.wikipedia.org/wiki/Technology_readiness_level Notably, the physical volume of a battery is a physics constraint, and most of the mass of your iPhone is the battery (Steves team miniaturized everything else to reach the form it ultimately became.) The battery type is a requirement set by the desired function of the hardware, and chips slowly optimize for a given role (hence the trend of things getting slightly smaller/more-efficient, but compared to the battery volume it is negligible.) Almost every business I've seen that prioritized the injection molded box first, has not survived to product launch. One could disagree with physics, but then again most engineers will simply abandon that project. =3
- spencerflem 2y agoOnly kinda related, but I've been excited to try Genode OS on the PinePhone https://genode.org/documentation/release-notes/22.08 https://genode.org/documentation/release-notes/22.08 for a very different take on a secure mobile os
- justinclift 2y agoIt can be runs in a VM on at least x86_64 too, which is useful for people wanting to experiment but who don't have a pinephone handy. :)
- notorandit 2y agoAre all the needed software drivers open source? Or will this phone end up by using blobs, just like all other devices?
- pkphilip 2y agoI am glad that these sorts of projects exist. Even if the implementation may not be the greatest it at least provides an option which is not under the thumb of Google, Apple and others.. and it can always be improved over time. However, I do wish there were some videos and photos of the completed products