1. By design, the cellular radio controller (called the baseband) accepts important/privileged commands from the cell tower. (For example, "update firmware". Sometimes, there's even "read range of bytes from phone's internal storage".)
2. Portable fake cell towers exist (called Stringrays).
Therefore, unfortunately, it seems unreasonable to claim that private keys generated by this eZing app never leave the phone.
* Probably previously here on HN. Couldn't find the link today.
UPDATE: This pgp-centric secure email is not open source? giggle Where do these people come from?
* You need to audit the blueprints for all hardware.
* You need to verify, physically, the products of manufacturing - the physical hardware you will use - often requiring you to know the design and likewise guarantee the implementation of the fab process.
* You need to audit and verify all firmware and software running on the system - from your flash controller to your chipset to your CPU to your GPU. This is on top of already having trust in the hardware.
* You need to then use software that is secure. Perfect security - mathematically proven security - is probably the most expensive thing you could try in software.
It is already impossible for any one individual to have audited all the hardware parts and the underlying OS and firmware, but then they need to also personally verify or write themselves the software implementations of security they will use.
We all, by using computers, are yielding an immense amount of security in the form of trust. One of the cornerstones of the free software and open hardware movements are how untrustworthy a singular set of eyes upon hardware or software truly are - that having the ability to independently have someone else inspect the code, or most importantly your own ability to do so, is what gives us reasonable expectations of security.
So nothing you ever use you can truly claim to be perfectly secure - you are always trusting that someone else is telling the truth when they say it is secure. In the best case scenario, a lot of unaffiliated people claim it is secure (ie, free software / free hardware). But we are well beyond the point anyone using an Internet based messaging app can presume perfect security, ever. The question is always who you are willing to trust when they claim to offer security - and to recognize when vendors are not promising (legitimate) security at all, as is the case with cell phones.
The local police department has ISMI catchers.
I estimate they won't have the ability to extract a file via the baseband until something like eZing becomes ubiquitous.
At that point, automated private key extraction will just become another feature of the ISMI catchers.
All of this is tangential to the real problem: basebands. Both in cell phones and cable modems. Time to take 'em back. You wouldn't allow OTA updates of your router or PC... Now would you?
I'll anticipate one response: "But, giving consumers control of their PHYs would be hell for the cellular/cable operators!" Well, after a few years, their/our networks (and devices) will be more secure.
Have you booted an internet-connected Windows 7/8 machine recently? "Here, have Windows 10, with all the privacy features built in to it switched off! (In fact we're already downloading ot for ypu even before you agree to install it, so it'll be ready as soon as you agree, isn't that _convenient?_)"
> Have you booted an internet-connected Windows 7/8 machine recently?
No, because I use GNU/Linux.
You're still relying on the wifi stack not having any holes that a compromised hotspot baseband could get through, and for that matter, relying on the whole OS not having any other holes they could attack. Either way, it's a smaller attack surface.
Under what circumstances would a "phone" manufacturer produce a headset that didn't have the baseband problem?
Which might just mean: a phone that consumers would regularly RTM if it did contain the problem?
Funny. With my email+PGP setup, my private key never even enters the device - https://grepular.com/An_NFC_PGP_SmartCard_For_Android
I don't know what this means? A snapshot (i.e. not an updated repository) available to anyone who asks for it?
I don't understand how it could meaningfully be "available in full" without it being equivalent and easier to just open source it.
And besides, I wasn't agreeing that it's a justifiable position, I was trying to highlight the confusion that arises when you use a term like "open source" (which doesn't have any moral backing, so "opening" the code may or may not make the software "open source").
We're a "15 year old startup" and we're very active with serveral open source projects. Our decision to not open source the project at the early stages is a decision that serves certain goals for us and the project.
First of all, we see some interest in the technical foundation of eZing. We admit it, we don't want to see a lot of forks and other people making profits based on our work while our initial investments are not covered. Yes, we're selfish like that.
The second goal is that we want eZing to stay. Forever if possible. When we look at successful open source projects, we noticed that quite some of them have had a proprietary or at least a protected "childhood". If open sourced at the right moment, a development community can take the momentum and relevance of the software and lead it to heights a single company is not able to.
There are two things that can go wrong: Open source it too early, before the technology is relevant or open source it too late, when the horse is already dead. The approach we choose is of course not a guarantee, but we believe in this approach.
Regarding the review and transparency: We are not willing to limit disclosure of the source code only to security companies or entities like that. We know that trust is not easily earned. If you allow us to dream, then we would - under NDA, see our first goal - disclose the code on a permanent basis to a group of developers that have earned the trust of the community until we finally release it as open source.
We're thankful for your thoughts on this and we would be glad to further discuss solutions so we get eZing off the ground.
This doesn't mean you can't work on a prototype before releasing it. Most projects do that. But asking free software developers to sign an NDA isn't going to work. They'll just go off and make a competing free software product.
- OpenOffice / LibreOffice (StarOffice)
- Firefox (with roots at Netscape)
- Joomla (Miro)
So, there are samples for both approaches.
Open source superiority discussions from your local "uber enthusiast echo chamber" should stay exactly there. Here's real world calling.
When it comes to your predictions about no developers signing NDAs... With the perspective for an early influence on a product that WILL go open source, I think it is a bold statement to deny the possibility of a group of people taking such a chance.
I am not claiming this is an especially interesting opportunity for hobbyists.
Open source, easier to use, much better UI.
I love the idea, but I'd never trust this, and I'd never recommend someone use it.
(I work at Nylas.)
Any hosted service is inacceptable by default for security-conscious users (metadata...), and your product is barely acceptable for selfhosting. Which requires to fork.
> The app should be open-source
> It will not be open-source