iCloud backups can be secured so not even Apple can get in them, but it is fundamentally much harder to secure (can't be hareware-entangled and still restore to a new device), and it would significantly complicate iCloud password changes. I'm sure they are working on it, but it is nontrivial.
That (software) problem is the real reason 99% of users are still exposed, as you say the hardware and secure enclave holes are basically closed.
There is no way they are working on this. It is an intentional design decision that Apple offers an alternative way to recover your data if you lose your password.
Or if you die without telling your next-of-kin your password. Most people do not actually want all of their family photos to self-destruct when they die because they didn't plan for their death "correctly". That would be a further tragedy for the family. (Most people don't even write wills and a court has to figure things out.)
Making data self-destruct upon forgetting a password (or dying) is not a good default. It's definitely something people should be able to opt-in to in particular situations, but only when they understand the consequences. So it's great news that in iOS 9.3 the Notes app will let you encrypt specific notes with a key that only you know. But it's opt-in, not the default.
"Hey, we're really sorry about fluxquanta's passing. Here is his private data which he may or may not have wanted you to see (but we'll just assume that he did). Aren't we such a caring company? Since we can no longer count on him to give us more money when our next product comes out, keep us and our incredibly kind gesture of digging through the skeleton closets of the dead in mind when shopping for your next device."
In absence of a will it would be terrible to assume that a person meant to have all their assets destroyed instead of handed down. It should be an explicit opt-in. The default should be, your stuff is recoverable and inheritable.
That seems like a weird assumption, that there'd be a single person with access to an account containing the only copies of decades of family photos. If someone else has account access or if there are copies of the photos elsewhere, then "destroy-when-I-die" isn't a big problem.
On the other hand, it also violates the way that I think things would usually work in the physical world. That is, if there's a safe that only the deceased had the combination to, I can still drill it to access the contents.
It would be a pretty big bummer for most families if when a family member passed away so did all those memories. That's probably not what they would have wanted. Or even if they just forgot their password.. that when they reset it all their photos go poof.
You are I might understand the consequences, but for most people it should really be a clear opt-in to "you can turn on totally unhackable encryption, but if you lose your pw you are totally screwed".
Do you have non-anecdotal evidence for that? Among my own friends and family, there are some images that only exist on one device or account, but most of the stuff likely to draw interest ends up somewhere else (a shared Dropbox account, e-mail attachments, on Facebook, copied onto some form of external storage).
There are likely some demographic groups that are more likely to behave one way than the other, and that could perhaps account for our differing experiences.
On second though, it is the easiest way to use the account (each person having an account on each device). I wonder what percentage of people that would benefit from it actually use the Family Sharing option?
If I were to die today I wouldn't want my personal photos, online history, or private writing to fall into the hands of my family. Hell, I don't really even want my physical assets to go to them (something I really should address in a will one of these days to donate it all to charity).
There has been a lot of fighting and backstabbing over who gets what when relatives have died in the past, and the more emotional items (like photographs) have been used to selfishly garner sympathy online through "likes" and "favorites" and it makes me sick. My position is that if you didn't make the effort to get to know a person while they were alive, you should lose the privilege of using their private thoughts for your own emotional gain after they're gone. And I do realize how selfish that sounds on my part, but in my current position I feel like it's justified. If I got a long term partner I would probably change my mind on that.
So yes, an opt-in would be ideal for me, but I don't think many online companies provide that right now.
In the case of sudden death, there would not have been any way to securely dispose of any private "data". So your private information, diaries, works you purposefully didn't publish, unfinished manuscripts you abandoned - everything was handed down to your estate, and more often than not used against your intent.
I'm not entirely clear whether your will could specify such disposal to be done, or could prohibit people from at least publishing these private notes and letters if not reading them, in any kind of binding and permanent way.
Shared photo streams are only a solution if they are used. Most people don't even write wills.
If you fail to write a will should the state just burn all your assets, assuming that's what you meant? No, that's the wrong default. Burn-when-I-die should be opt-in for specific assets, not the default.
And the good news is Apple is providing opt-in options like secure notes. Perhaps even backups too (3rd parties already do). But only after presenting the user with a big disclaimer informing them of the severe consequences of losing the password.
http://6abc.com/news/senior-official-stresses-feds-need-to-u...
[0] http://daringfireball.net/2016/02/san_bernardino_password_re...
"One of the strongest suggestions we [Apple] offered was that they pair the phone to a previously joined network, which would allow them to back up the phone and get the data they are now asking for. Unfortunately, we learned that while the attacker’s iPhone was in FBI custody the Apple ID password associated with the phone was changed. Changing this password meant the phone could no longer access iCloud services."
As above, not a good idea for a default, but don't see why it wouldn't be technically viable for opt-in protection.
To spell it out (1) request new encryption key from device (let's call it key4cloud); (2) encryption key generated, displayed for physical logging by the user, & stored in the secure enclave; (3) all normal backups to iCloud are now encrypted via key4cloud; (4) user loses phone; (5) user purchases new phone; (6) new phone downloads data; (7) user enters key4cloud from physical notes & decrypts backup
Yes, it requires paper and a pencil and user education (hence the opt-in). But it's also incredibly resistant to "Give us all iCloud data on User Y."
Look at the controversy over the phone not booting with third-party fingerprint reader repairs as an example. People were upset when they found out that having their device worked on could make it unbootable, but Apple was able to easily fix it with a software update. If it had been designed more securely, it might have wiped data when it detected unauthorized modifications, which would have meant even more upset people. Now that this has become a public debate, there will be a very different response to making it more secure.
Making the DFU update path more complex increases the risk of bugs and thus the risk of permanently bricking phones.
You could imagine an alternative where on boot the Secure Enclave runs some code from ROM which checks that a hash of the SE firmware matches a previously signed hash, which is only updated by the Secure Enclave if the user entered their pin during the update. If it doesn't match, either wipe the device or don't boot until the previous firmware is restored.
This way Secure Enclave firmware updates and updates via DFU are still possible, but not together without wiping the device.
Honestly, this is really the shit..
That basically happened (at a smaller scale) just last week. When Apple apologized and fixed the "can't use iPhone if it's been repaired by a 3rd party" thing, the fix required updating phones which were otherwise bricked. It's not an unreasonable scenario.
That probably also means removing most debugging connections from the physical chip, and making extra sure you can't modify secure enclave memory even if you desolder the phone.
You decap the chip to expose the die with HF, and then use Focused Ion Beams and a million dollar microscope setup, you can rearrange the circuits. So, if the NSA absolutely had to have the data on the chip they could modify it to make it sing. So, if say they know an iPhone had the location of Bin Laden on it, they could get the goods without Apple.
Locking themselves out of the Secure Enclave isn't anywhere near sufficient. As long as the device software and trust mechanisms are totally opaque and centrally controlled by Apple, the whole thing is just a facade. There's almost nothing Apple can't push to the phone, and the audibility of the device is steadily trending towards "none at all".
If the NSA pulls a Room 641A, we'd never know. If Apple management turns evil, again, we'll never know. If a foreign state use some crazy tempest attack to acquire Apple's signing keys ... again, we'll never know.
I don't think acting like an open ecosystem is the be-all and end-all of security is productive. Most organizations (let alone individuals) don't have the resources to vet every line in every piece of software they run. Software follows economies of scale, and for hard problems (IE, TLS, font rendering, etc) will only have one or two major offerings. How hard would it be to introduce another heartbleed into one of those?
As someone who has done quite a bit of reverse engineering work, I have no idea how I'd identify and isolate a vulnerability found by fuzzing without the ability to even look at the machine code.
For the same reason I do not independently vet every line of source code I run, but still reasonably trust my system magnitudes more than anyone could - and I argue, nobody can - trust proprietary systems. And that is because while I personally may not take initiative to inspect my sources, I know many other people will, and that if I were suspicious of anything I could investigate.
Bugs like Heartbleed just demonstrated... well, several things:
1. Software written in C is often incredibly unsafe and dangerous, even when you think you know what you are doing. 2. Implementing hard problems is not the whole story, because you also need people who comprehend said problems, the sources implementing them, and have reason to do so in the first place.
Which I guess relates back to C in many ways.
I look forward to Crypto implemented in Rust and other memory / concurrency / resource safe languages. There is always a surface vector of a mistake being made that can compromise any level of security - if you move the complexity into the programming language the burden falls on your compiler. But in the same way you can only trust auditable in production heavily used sources, nothing is going to be more heavily used and scrutinized, at least by those interested, than languages themselves.
The important thing about the secure enclave thing is that it pushes security over the line so that the attacker has to comprimise you befor you do whatever it is that will get you on somebodys shitlist.
Is this true even if you use Touch ID?
The only point I'm making is that Apple already designed a cryptosystem that resists court-ordered coercion: as long as your passcode is strong (and Apple has allowed it to be strong for a long time), the phone is prohibitively difficult to unlock even if Apple cuts a special release of the phone software.
Some corps require or strongly encourage it. My employer does.
And most parents I know use alphanumeric to keep their kids from wiping their phones and iPads just by tapping the numbers. (A four digit number code auto-submits on the 4th tap, so all it takes is 40 toddler taps. An alphanumeric code can be any length and won't submit unless the actual submit button is tapped.)
If you have a stronger passcode, you see a full keyboard instead.
Copying a good fingerprint from a dead finger or a randomly placed print is not easy [2]. It's hard, doable but you get 5 tries so if you screw up, you have thrown away all the hard work of the print transfer.
All bets are off if the iPhone is power-cycled. Best bet if you're pulled over by authorities or at a security checkpoint is to turn off your iPhone (and have a strong alphanumeric passcode).
[1] https://xkcd.com/538/ [2] https://blog.lookout.com/blog/2013/09/23/why-i-hacked-apples...
Excellent advice. Even better, if you're about to pass through US customs and border patrol, backup the phone first, wipe, and restore on the other side. Of course, this depends on your level of paranoia. I am paranoid.
I recommend you make a backup to your laptop, which you then encrypt manually. That way the trust model is: you trust yourself. Then you can do whatever you want with the encrypted file. Apple's iCloud is perfectly fine at this point.
The real challenge is to find a way to restore that backup, because you have to be on a computer you trust. If you decrypt the backup on a "loaner" laptop, your security is broken.
If you decrypt the backup on your personal laptop but the laptop has a hidden keylogger installed by the TSA or TAO, your security is broken.
It would be necessary to backup the phone on the _phone_ _itself_. Then manually encrypt the file (easy to do). Then upload to iCloud. At this time, no such app exists for iOS.
Since you plan to restore the backup to the phone anyway, it's no problem to decrypt a file on the phone before using it for the restore.
You mean your laptop that was manufactured by a 3rd party, with a network card that was manufactured by a 3rd party? And you're using encryption software that, even if it's open source, you probably aren't qualified to code review. I'm not downplaying the benefit of being careful, but unfortunately you can keep doing that pretty much forever.
its not trivial, but its sure easy to do in this day and age.
And it's paranoia if there's a legitimate threat, that's just called due diligence. ;)
Do the docs confirm that there is no way around this? I'd guess generating the encryption key requires the passcode, which is discarded immediately, and Touch ID can only "unlock" a temporarily re-encrypted version which never leaves ephemeral storage?
If Touch ID is turned off, when a device locks, the keys for Data Protection class
Complete, which are held in the Secure Enclave, are discarded. The files and keychain
items in that class are inaccessible until the user unlocks the device by entering his
or her passcode.
With Touch ID turned on, the keys are not discarded when the device locks; instead,
they’re wrapped with a key that is given to the Touch ID subsystem inside the Secure
Enclave. When a user attempts to unlock the device, if Touch ID recognizes the user’s
fingerprint, it provides the key for unwrapping the Data Protection keys, and the
device is unlocked. This process provides additional protection by requiring the
Data Protection and Touch ID subsystems to cooperate in order to unlock the device.
The keys needed for Touch ID to unlock the device are lost if the device reboots
and are discarded by the Secure Enclave after 48 hours or five failed Touch ID
recognition attempts.Now Cydia and 3rd party stuff? I have no clue.
If I absolutely had to I just wouldn't take a phone/laptop with me.
I wonder if there is any negative effects associated with being refused entry by a CBP? Could it be the case that if you are refused entry once, that in the future they will be more likely to refuse you entry? If so, that's a fairly significant penalty/power that the CBP person has.
Yes, some categories of non-citizen visitors (I don't remember which) are asked on the form if they have ever been refused entry to the U.S. (and are required to answer yes or no). If they're using the same passport number as before, CBP likely also has access to a computerized record of the previous interaction.
(They might also be able to search their database by biographical details such as date of birth, so getting a different passport may not prevent them from guessing that you're the same person.)
You get plenty of tries to perfect the technique, before using it on the actual device.
You acquire identical hardware and "dead finger countermeasures" (does the iphone employ any? Some readers look for pulses and whatnot, I don't know if the iphone does). You then practice reading the fingerprint on that hardware until you are able to reliably get a clean print and bypass any countermeasures. Only then do you try using the finger on the target phone.
You might still fuck it up, and you only get 5 chances on the target hardware. But with practice on the right hardware, I see no reason why you couldn't get it.
https://support.apple.com/en-us/HT204587
Great design.
All bets are off if the iPhone is power-cycled.
Also remember that rubber-hose cryptanalysis is always an option.
Edit: Looks like the answer is it depends and not a resounding no
http://www.nolo.com/legal-encyclopedia/evidence-obtained-thr...
Examples:
* prolonged solitary confinement: not legally torture
* fellow prisoner violence: not legally torture, no nexus
* prolonged pre-trial confinement: not really torture, but we may as well include it
* waterboarding/drowning: not legally torture? (Supreme Court declined to rule)
* stress positions: cannot show it took place
* parallel construction: cannot show / not aware
If they can find a judge who believes the iron maiden isn't torture while the anal pear is, then guess what... the government will use the iron maiden.
Even if they can't find such a pliable jurist, they'll have no problem getting a John Yoo to write an executive memo that justifies whatever they want to do to you, and let the courts sort it out later. There's no downside from their point of view.
The memos didn't provide de iure indemnity. There is no constitutional basis, in fact the proposition that a memo can supersede the Constitution is idiotic on its face.
The failure is the de facto doctrine of absolute executive immunity. It has two prongs: 1. "When the president does it, that means that it is not illegal." 2. When the perpetrator follows president's orders, also not illegal.
Nevertheless, since there is no legal basis, there is nothing preventing the next government from prosecuting them.
Yes, and that's what I meant by "let the courts sort it out later." The Constitution's not much help either way, being full of imprecise, hand-waving language and vague terms like "cruel and unusual." It was anticipated by the Constitution's authors that it would be of use only to a moral government.
Nevertheless, since there is no legal basis, there is nothing preventing the next government from prosecuting them.
I wonder if that's ever happened in the US? Does anyone know?
It usually only happens when the rule of law is suspended and then resumed. You're a young country, so maybe it hasn't happened before. Robert H. Jackson was an American, though ;-)
Enter parallel-constructed information as court-sanitized evidence.
The pulse and skin conductivity might change, but are either of those reliable enough metrics for such an application?
There is a VERY limited amount of time in which you can take the watch off and switch to another wrist (like milliseconds, you have to practically be a magician to switch wrists (which I do throughout the day)).
Apple has the watch, they could use it to beef up security for those that want it.
It was near-impenetrable, but it could have been inevitable if it weren't for the fact that Apple could push OS updates without user consent. They could have made it impossible for anyone to get in even if your pin was 1234, but didn't.
Kind of disappointing given their whole thing about the Secure Enclave. Bunch of big walls in the castle, but they left the servant's door unlocked.
The main difference would be that everyone knows trust zone through Qualcom's implementation and software - as it's been broken many times. At the end of the day "its just software" though, which runs on a CPU-managed hypervisor with strong separation ("hardware" but really, the line is quite a blur at this level).
What that means is that you need to be unable to update the secure enclave without user's code (so the enclave itself needs to check that) which is probably EXACTLY what apple is going to do.
Of course, Apple can still update the OS to trick the user into inserting the code elsewhere, then FBI to use that to update the enclave and decrypt - though that means the user needs to be alive obviously.
Past that, you'd need to extract the data from memory (actually opening the phone) and attempt to brute force the encryption. FBI does not know how to do this part, the NSA certainly does, arguably, Apple might since they're designing the chipset itself.
- Apple is required to have backdoors, at least on iPhones sold in foreign countries, isn't it?
- Even if the SE were completely secure, a rogue update of iOS could intercept the fingerprint or passcode whenever it is typed, and replay it to unlock the SE when spies ask for it. As far as I know, the on-screen keyboard is controlled by software which isn't in the SE.
- Even if iCloud is supposed to be encrypted, they didn't open up that part to public scutinity.
- Therefore a perfect security around the SE only solves the problem of accessing a phone that wasn't backdoored yet. There are all reasons for, say, Europe and CIA, to require phones to be backdoored by default for LE and economic intelligence purposes.
But in both those situations the weakness is in the person, not the device. Apple devices still potentially have security weaknesses which the FBI is asking Apple to exploit for them. Apple wants to fix these weaknesses, to stop Apple being forced to exploit them.
I don't believe this is the case.
Even if the SE were completely secure, a rogue update of iOS could intercept the fingerprint or passcode whenever it is typed, and replay it to unlock the SE when spies ask for it. As far as I know, the on-screen keyboard is controlled by software which isn't in the SE.
What you say about an on-screen passcode is likely true but the architecture of the secure enclave is such that the touch ID sensor is communicating over an encrypted serial bus directly with the SE and not iOS itself. It assumes that the iOS image is not trustworthy.
From the white paper [1]:
It provides all cryptographic operations for Data Protection key management and maintains the integrity of Data Protection even if the kernel has been compromised.
...
The Secure Enclave is responsible for processing fingerprint data from the Touch ID sensor, determining if there is a match against registered fingerprints, and then enabling access or purchases on behalf of the user. Communication between the processor and the Touch ID sensor takes place over a serial peripheral interface bus. The processor forwards the data to the Secure Enclave but cannot read it. It’s encrypted and authenticated with a session key that is negotiated using the device’s shared key that is provisioned for the Touch ID sensor and the Secure Enclave. The session key exchange uses AES key wrapping with both sides providing a random key that establishes the session key and uses AES-CCM transport encryption.
[1]: https://www.apple.com/business/docs/iOS_Security_Guide.pdf
"@AriX I have no clue where they got the idea that changing SPE firmware will destroy keys. SPE FW is just a signed blob on iOS System Part"
https://twitter.com/johnhedge/status/699882614212075520
Then Apple seems to confirm it:
"The executives — speaking on background — also explicitly stated that what the FBI is asking for — for it to create a piece of software that allows a brute force password crack to be performed — would also work on newer iPhones with its Secure Enclave chip"
http://techcrunch.com/2016/02/19/apple-executives-say-new-ip...
I hate to be that guy, but if you have an op and you have any opsec, you aren't even carrying a phone.
Right ?
To me, the more profound consideration is this: if you use a strong alphanumeric password to unlock your phone, there is nothing Apple has been able to do for many years to unlock your phone. The AES-XTS key that protects data on the device is derived from your passcode, via PBKDF2. These devices were already fenced off from the DOJ, as long as their operators were savvy about opsec.