Are there any open source alternatives to the iPhone that might take off because of these happenings?
Then it's going to need a hardware key separation something like what apple is doing with the enclave approach.
Are there any projects like this?
There is some spectrum in the 600MHz range the government have been talking about re-purposing, but frustratingly they seem more interested in giving that to corporations than letting the public use it.
Then you can engineer the over the air protocol to be anonymous. Tower operators could be paid by bitcoin.
A truly secure cell phone network is possible. The problem is that certain people don't want us to have secure systems, and we're somewhat reliant on the government to afford us that opportunity.
I would imagine that if you focused on how it would help out poor Americans by offering them something cheaper, you'd get more traction than if you focused on privacy.
1. Once you buy the phone you (via itunes) create a RSA key pair. Put one of those in the phone. That key is set and bootloader uses it to verify loaded updates.
2. ios updates come to you signed by apple, you must resign them with your itunes and then they could be loaded.
So you obtain the ability to sign your own software on your own device.
In that case no amount of Apple assistance can help FBI until they obtain your private key.
[1] - https://developer.apple.com/library/mac/documentation/Securi...
Perhaps the ability to completely restore shouldn't require your own signature.
Given that nothing like that is out there as far as I know, you'd need a more specified model to prove it's even possible. It's not obvious from the proposal above.
- loader A stores a (PubKey,NextLoader) and has the ability to blank (via actual blanking or deletion of an encryption key) the entire device.
- loader A provides a new-key(PubKey,NextLoader) method which blanks the remainder of the device.
- Loader A also provides a update-loader(NextLoader) method that doesn't, but also doesn't update the PubKey. Before accepting the new NextLoader, it verifies it against the stored pub key.
Could also allow things like updating the PubKey if the update is signed by the previous PubKey
Spec presumes only access is via the loader A api, PubKey would really need to be stored somewhere safe (HSM, TPM, etc) to discourage direct hardware access.
Probably also could use the PubKey to encrypt the NextLoader.
New phones ship either:
- without a pubkey or next-loader, and require initial provisioning to do anything (fairly inconvenient)
- ship with a flag set that prevents updating the loader, ie: requires updating the key (less secure, probably need to specify further how this occurs to avoid the security hazard from un-updated phones from being too great).
Assuming this updates the loader, that means anyone with physical access for five minutes can permanently brick the phone, without opening it.
Are we sure we want that?
Also, how can loader A modify itself?
It doesn't. The model I presented presumes that it is unchangeable.
> anyone with physical access for five minutes can permanently brick the phone, without opening it
Pick one:
- you can always get your phone working, even if you forget your key & only you can apply updates to any software on the phone. Anyone can replace the loader (but this wipes all other data).
- you can always get your phone working, even if you forget your key & only a third party can provide new versions of the loader.
- if you forget your key, your phone is permanently bricked.
> Also, how can loader A modify itself?
It can't.
In general though, it's fairly straight forward to have code copy itself into ram & run from there while overwriting it's source. The problem is that opens the potential to brick the phone (just like any method that allows updating the loader).
To avoid bricking in all cases, one _must_ assume that there is some un-replaceable software (or hardware mechanism to start software).
Now I'm wondering whether you can place malicious RAM in the phone that changes instructions on the fly. Is that feasible?
I'd expect security consious parts (ie: all of the theoretical "loader A") would need to run in SRAM (ie: ram that is in the same IC and thus harder to get at than external DRAM chips) or some other mechanism.
At that point, it becomes a question of physical hardening within the ICs. Some manufacturers have done things like put metal layers over fuses (to prevent them from being changed), I'd imagine the same could be done (at some cost) for a larger area of the chip. I'd imagine HSMs (hardware security modules) and TPMs (though these aren't as good) probably implement some of that. There also exist some chips targeted towards security purposes (not aware of any processors off hand) that could be used .
There are IMHO two reasons for Apple's platform fascism. The more self-interested one is that they want app store profits. The second more user-focused one is that they really want to keep iOS from turning into the shitware and malware disaster that Windows has become. On one hand Apple's walled garden keeps out certain forms of innovation and lets them dictate the terms, but on the other hand it lets them exclude trash like Superfish or Comodo's "security" junk.
At most it should be a thin client.
Really? Every kind of server? I'm sorry, but that's some ridiculous statement.
A device running proprietary software that governments have physical access to (after it was confiscated) is less vulnerable than (possibly) your own device running open source software that nobody except you has physical access?
I've edited previous comment.
And if we are being completely paranoid, then you can have some form of Dead man's switch or "self-destruct" option. You have a right to make a phone call, right?
> Currently working on a server in Chrome that you can connect to using node.js to make a web page do stuff (and no, that isn't back to front).
?!?!
I have no words.
It'd be stupid, but there's no reason why you couldn't use a system like that, running in Chrome, listening on an IP address, to do pretty much anything a "real" server does. The user wouldn't know. It's just a server, or "the cloud".
You are naive if you think any device is secure against a determined and well funded actor.
Let me remind you, than if I'm not mistaken in US law enforcement can search your phone without any sort of warrant. Let's assume that you keep your stuff just on your own PC at home, then that at least would require a warrant.
not if it has a password
I think it certainly could be and probably is. Apple seems to be taking phone security pretty darn seriously with combined hardware/software approaches.
Furthermore, my servers sit in a datacenter or my apartment that I rely on somebody else to look after. Really though, you could probably bribe/threaten/warrant your way into those places easily enough and just pull RAM/HDDs to your heart's content. On the flip side, my phone stays in my pocket or next to my bed. If you want my phone, you have to arrest me/steal it from me/whatever.
> US law enforcement can search your phone without any sort of warrant
During a lawful arrest, and the search has to be documented and relevant to the arrest. Furthermore, that assumes that they know my password (Which I'm not currently obligated to give to them).
There's no guarantee it still going to be secure in the future and there's no guarantee that it was secure in the past.
But I'd say to look at how people hiding their money from their governments are doing it. Or look at Snowden. Let the law help you, even if it is the law of another country.
In any case you can create an encrypted container locally and then upload it to a remote server, doesn't really matter that it was intercepted.
https://en.wikipedia.org/wiki/Security_through_obscurity?wpr...