Live data from Hacker News

MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

mikrophone.net

31–40 of 90 posts

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#31
post #22
post #18

Earlier quoted context omitted.

> ...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, ye…

This. And no 2G/3G to protect against SS7 threats. 4G/5G only can be quite limiting but in this threat model you want SS7 attacks out.

Lockdown mode also does disable 2G[1], although personally it'd have been great to have a 2G/3G toggle per SIM the way they do the other per SIM options.

[1] https://support.apple.com/en-us/105120

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#33
I 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

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#34

I 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

Nothing stops you from buying one of those "granny phones" with big buttons and basic functionality. No traces of Google and Apple on them either.

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#35
post #18
post #11

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 offere…

> ...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, ye…

> You know, they're Secure(TM)! Against Threats(TM)!

This is thought provoking because I get your sentiment against half-baked ideas of "secure" and "threat", but then you start talking about cameras, fingerprint readers and boot processes...

These have nothing to do with phones as I see them. For me a secure phone is the minimum viable device to make a voice communication (and perhaps short text messages at a stretch).

So what's going on here is woolly ideas about function. If we define a "phone" as a multi-purpose personal computer, address book, secure storage device, video player, film camera etc, then it's going to have very different security parameters than a simple "telephone".

So we can't talk about threats and security until we have talked about function. As we define (or rather fail to define) a 'phone' today it has almost no functional boundaries, and so there's no model around which to define security.

The minimal RISC-V device outlined in the article looks like the kind of thing that could be customised to constrain functionality in such a way as to add security. It obtains that possibility by giving control to the end user around what not to include.

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#36
> 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.

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#37
post #20

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 i…

I 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.

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#38
post #22
post #18

Earlier quoted context omitted.

> ...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, ye…

This. And no 2G/3G to protect against SS7 threats. 4G/5G only can be quite limiting but in this threat model you want SS7 attacks out.

nitpick: SS7 is used at the core network between telecom companies. Whatever happens at the RAN/RAT layer (ie. 5G vs 2G) has nothing to do with it.

There's still security gains to be had from using LTE, but if mossad wants to hijack your 2fa codes by using a SS7 exploit, thats not going to protect you.

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#39
post #18
post #11

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 offere…

> ...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, ye…

>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).

It's worth pointing out that even the latest iPhones are vulnerable after first unlock (AFU), which means if your phone gets seized and you don't have time to turn it off, they can get a full dump of your phone.

https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#40
post #12
post #9

Earlier quoted context omitted.

> 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 en…

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.

As 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.

Post reply on HN