(of course if the phone is not in use anymore it doesn't apply)
If the software (Android) had the same type of protection (if the wrong PIN is entered 10 times it destroys the key), would this device be at par with the iOS approach?
If Apple can't launch new iOS versions, can they still launch new iPhones?
What if the feds decide that an O/S update closes a zeroday that the NSA was using (note they've been really quiet here) and interferes with an FBI investigation in process?
And yeah, DOJ keeps saying it's just the one device, just this one time. What happens if they suddenly change course just to prevent iOS from getting more secure?
There are however those pesky share holders to keep happy.
Had he lost to the DOJ, here is what would (might) have happened:
- he would gladly unlocked this phone and bill DOJ for the time spent on redesigning IOS
- going forward, he would label each phone's box in red letters: CONTAINS GOVERNMENT-REQUIRED BACKDOOR (I doubt Gov can forbid him from doing that)
- he would then stop selling devices in Apple stores directly and only allow to order them in stores with direct home delivery from Apple website hosted and operated outside USA.
- all the shipping would be done directly from China by-passing US-tax system all together.
- shortly after he would remove the backdoor IOs for devices that are not directly sold on US soil
That would be a big fat middle finger to the DOJ.
They won't try to pass this law until after this election year. It's too sensitive an issue and will fracture the voter base along unexpected lines, thus giving Trump a chance at winning.
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.
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.
http://6abc.com/news/senior-official-stresses-feds-need-to-u...
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.
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?
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.
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...
Also remember that rubber-hose cryptanalysis is always an option.
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
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 ?
I mean, we're talking about threat models where chip-level doping has been shown as an attack. This just seems to be a variation on the same claims of copy protection tamper resistant dongles we've had forever. That someone builds a secure system that is premised on a secret being held in a tiny tamper-resistant piece, only the tamper resistance is eventually cracked.
It might even be the case that you don't even need to exfiltrate the UID from the Enclave, what the FBI needs to do is test a large number of PIN codes without triggering the backoff timer or wipe. But the wipe mechanism and backoff timer runs in the application processor, not on the enclave, and so it is succeptable to cracking attacks the same way much copy protection techniques are.
You may not need to crack the OS, or even upload a new firmware. You just need to disable the mechanism that wipes the device and delays how many wrong tries you get. So for example, if you can manage to corrupt, or patch the part of the system that does that, then you can try thousands of PINs without worrying about triggering the timer or wipe, and without needing to upload a whole new firmware.
I used to crack disk protection on the Commodore 64 and no matter how sophisticated the mechanism all I really needed to do was figure out one memory location to insert a NOP into, or change a BNE/BEQ branch destination, and I was done. Cracking often came down to mutating 1 or 2 bytes in the whole system.
(BTW, why the downvote? If you think I'm wrong, post a rebuttal)
The cynical side of me says that Apple's marketing tactics have worked. But I've got a feeling, heck, I want to believe, that this is actually driven by company values and not a short-term marketing benefit.
The reason iCloud data will always be accessible by Apple, and thus governments, is not because Apple wants to make it accessible to governments. It's so that Apple can offer customers the very important feature of accessing their own data if they forget or otherwise don't have the password. That is an essential feature, and why this aspect will never change.
When someone passes away, for example, it would be a terrible compounding tragedy if all their photos from their whole life passed away along with them, because they didn't tell anyone their password or where they kept the backup key. So Apple wants and needs to provide an alternative way to recover the account. (For example, they will provide access to a deceased person's account if their spouse can obtain a court order proving the death and relationship.)
Harvard recent published a paper (called "Don't Panic") that essentially states the same.[1] Governments shouldn't "panic" because in most cases, consumers will not be exclusively using unbreakable encryption, because it has tradeoffs that aren't always desirable.
And the reason why most consumer should be backing up to iCloud is similar: that's how you prevent the tragedy of losing your data if you lose your phone.
Just something to keep in mind when discussing the "going dark" and "unhackable" news items.
It is worth noting however that people who do "have something to hide" from governments probably won't be using iCloud, if they know what they're doing. Then again if they know what they're doing, they wouldn't use anything that is backdoored anyway. So the naive criminals will still probably be hackable, and that's about all we can hope for.
[1] https://cyber.law.harvard.edu/pubrelease/dont-panic/Dont_Pan...
Since 197X, people had home computers (and institutional computers for two decades before that) on which the FBI could install anything they want, if that equipment fell into their hands. This fact never made news headlines; it was taken for granted that the computer is basically the digital equivalent of a piece of stationery, written in pencil.
There is nothing wrong with that situation, and on such equipment, you can secure your data just fine.
No machine can be trusted if it fell under someone's physical access. Here is a proof: if I get my hands on your device, I can replace it with a physically identical device which looks exactly like yours, but is actually a man-in-the-middle (MITM). (I can put the fake device's board into your original plastic and glass, so it will have the same scratches, wear, grime pattern and whatever other markings that distinguish the device as yours.) My fake device will collect the credentials which you enter. Those are immediately sent to me and I play them against the real device to get in.
Apple are trying to portray themselves as a champion of security, making clueless users believe that the security of a device rests in the manufacturer's hands. This could all be in collaboration with the FBI, for all we know. Two versions of Big Brother are playing the "good guy/bad guy" routine, so you would trust the good guy, who is basically just one of the faces of the same thing.
I'm not well versed in security so excuse me for my ignorance but what if there were a way to solder chip onto the board that allows access to the secure enclave. Every time an iphone is made a companion chip is produced that contains some kind of access key which only works for that device and someone is required to foot the bill for storing them.
- George Orwell, 1984
- Apple, 2016Today, we celebrate the first glorious anniversary of the Information Purification Directives. We have created, for the first time in all history, a garden of pure ideology—where each worker may bloom, secure from the pests purveying contradictory truths. Our Unification of Thoughts is more powerful a weapon than any fleet or army on earth. We are one people, with one will, one resolve, one cause. Our enemies shall talk themselves to death, and we will bury them with their own confusion. We shall prevail!
https://www.youtube.com/watch?v=R706isyDrqI
They should re-run this commercial for iPhone 7. "On September 24th, Apple Computer will introduce iPhone 7. And you'll see why 2017 won't be like 1984."
@Udik: I could just keep my tax documents in printed plaintext on top of my dresser but I opt to keep them locked up. Privacy and security are important. If people who utilize privacy/security tools are up to no good then why does the U.S. Gov't have a clause for not revealing information due to State Secrets? Why do we set our Facebook profiles to private? Why have passwords at all on anything? Are you beginning to see the point?
For many customers of hardware and software trust is what is being sold.
As trust is eroded 'good enough' is no longer good enough. The only way to continue to be trusted is to be more secure, and as the grandparent points out the endgame there is that the encryption puts the software and hardware beyond the reach of the company that produced it.
You don't compromise there, it's against your customer base and your product positioning, and furthermore it dilutes your brand.
https://news.ycombinator.com/item?id=10906999
Apple is far from having a secure phone right now. NSA certainly has ways to bypass this based on my attack framework and their prior work. They just don't want them to be known. They pulled the same stuff in the past where FBI talked about how they couldn't beat iPhones but NSA had them in the leaks & was parallel constructing to FBI. So, the current crop are probably compromised but reserved for targets worth the risk.
That said, modifying CPU to enable memory + I/O safety, restricting baseband, an isolation flow for hardware, and some software changes could make a system where 0-days were rare enough to be worth much more. Oh yeah, they'll have to remove the debugging crap out of their chips and add TEMPEST shielding. Good luck getting either of those two done. ;)
Do you have a link to a leak that shows this? I couldn't find anything with a simple google search.
I want it all to go when I do. Hell, I want some of it to go now.
After I'm gone, I want to leave no part of my existence on the internet.
I realize that's not possible. But I want to minimize my footprint.
It is totally possible for a local device. I have a deadswitch on all my computers. If I don't log in and set an alive flag via the command line in any of my computers for more than a week, that computer securely wipes itself.
Let it be known, I have nothing to hide. I just think this is the best way to do things.
Edit: My reason for this is the frequency with which I encounter people who are no longer alive. It's a harsh thing to look at a link to someone who said something, and you used to know and then suddenly realize, "Oh shit. He's dead. And I used to be his best friend."
I know facebook has memorial pages, but those are difficult to get.
Private information is another matter, but when people presume they have rights to choose how others think, it really makes my blood boil.
http://www.b-list.org/weblog/2013/jan/29/persistence/
Since then I've started noticing services rolling out the ability to specify someone to take over your account after you die, and I suspect the legal framework around wills and estates is robust enough that you could leave instructions (and have them enforced) to delete things.
What encryption and security really does is create scarcity of access to information and data in order to force a market solution where government groups have to prioritize their efforts and apply them deliberately.
The only reason previous wiretapping laws were passed is because they weren't in the limelight and the public never had a chance to weigh in. Let's make this an election issue
Unless it breaks DRM!
USA FREEDOM was passed fairly specifically because the issue was in the limelight.
Nothing is 100% proof, crypto certainly isn't. It's going from child's play to "you actually need to knowledge" to "this is actually hard now" (but.. not impossible).
It's such a grey area and I will probably get down voted for commenting this way. I 100% agree that the power, in the wrong hands, is horrible, but can't we talk about this in a way where there's some kind of middle ground? All I've been reading are either extremes.
They give you the choice.
I'm not sure it's a perfect solution but might be better than counting on someone to reverse engineer or hack into your phone.
If you're serious about encryption you should always have a backup key somewhere... unless you want a single point of failure (you). Both should be an option.
I was a bit surprised by the clickbait-y nature of the HN title, but we can see in the nytimes URL that this "Apple Is Said to Be Working on an iPhone Even It Can’t Hack" was the original title, eh.
1. http://www.pcgamer.com/john-mcafee-on-his-fbi-iphone-hack-of...
2. http://arstechnica.com/staff/2016/02/mcafee-will-break-iphon...
edit: added source #2; see Google for additional sources...
"Balanced" compared to what? To the 80% insecurity we have now? And "balance" for what protocol? For all existing protocols? For all future protocols? What if hackers learn how to exploit that "balance" in a massive way? Will companies be allowed to fix it by improving the security or will they be "impeding law enforcement"?
It's unbelievable to me how hard the government is fighting against basic security.
It's not an attainable goal in practice. Today they generate a per device customized update that can be installed without user intervention. Even if they tomorrow enforce user intervention they still retain the capability to push a targeted update for a specific device on law enforcement/court order. The user has no way of telling what the update did.
(although there's a whole separate set of legal attacks unexplored)
Again, it is objectively very strange to not even hint at what the source of your information is. But it's also standard practice.
Full disclosure I understand this was a persons work phone. This is a statement which is solely being posted to stimulate theoretical discussion.
(Somehow, I feel iMessage and related apps are MITMable because there is no mandatory, mutual, out-of-band validation of a recipient's identity.)
* Decapping and feature extraction even from simpler devices is error prone; you can destroy the device in the process. You only get one bite at the apple; you can't "image" the hardware and restore it later. Since the government is always targeting one specific phone, this is a real problem.
* There's no one byte you can write to bypass all the security on an iPhone, because (barring some unknown remanence effect) the protections come from crypto keys that are derived from user input.
* The phone is already using a serious KDF to derive keys, so given a strong passphrase, even if you extract the hardware key that's mixed in with passphrase, recovering the data protection key might still be difficult.
Any mechanism that prevents the application processor from either a) remembering it incremented the count b) corrupts the count or c) patches the logic that handles a retry count of 10, is sufficient to attack the phone.
Somewhere in the application processor, code like this is running:
if (numTries >= MAX_RETRY_ATTEMPTS) { wipe(); }
or
if (numTries >= MAX_RETRY_ATTEMPTS) { retryTime = retryTime * 2; }
Now there are two possibilities. Either there are redundant checks, or there aren't. If there aren't redundant checks, all you need to do is corrupt this code path or memory in a way that prevents it's execution, even if it is to crash the phone and trigger a reboot. Even with 5 minutes between crash reboot cycles, they could try all 10,000 pins in 34 days.
But you could also use more sophisticated attacks if you know where in RAM this state is stored. You couldn't need to de-capp the chip, you could just use local methods to flip the bits. The iPhone doesn't use ECC RAM, so there are a number of techniques you could use.
I disagree. The pin validation is done within the secure enclave. You can't do it outside the secure enclave because the pin is combined with a secret that is burned into the silicon of it. The secure enclave can and will enforce timeouts for repeated failures, as well as refuse to process any pin entries after too many attempts. Disabling the wipes or bypassing the timer won't do you any good when you only have a few attempts.
https://blog.trailofbits.com/2016/02/17/apple-can-comply-wit...
Look, there's a big difference between trusting known ciphers that have been well studied by the world's top cryptographers, and a proprietary TPM chip that relies on security-through-obscurity.
The history of embedding secrets into black boxes is a history of them being broken. This isn't a theoretical concern, it's a very practical one.
Don't discuss your (or others') votes.
Don't interrupt the discussion to meta-discuss the scoring system.
Sure, to resist microscopic attacks, an IC must assert logical integrity to itself i.e. that the gates & wires are not compromised by a microscopic attack.
But just because you and I haven't imagined it, doesn't mean some kind of internal canary can't exist. Your naive code (below) of a counter might instead be based on quantum cryptography, or on intrinsic properties of a function or algorithm which if compromised the SE cannot function at all.
The existence of one-time password schemes like S/KEY gives me hope, since it is a sequence generator that simply doesn't function without input of the correct next value (technically the previous value from the hash function). S/KEY itself is not the answer (wrong UX and no intrinsically escalating timer), but I wanted to illustrate that you can generate a self-validating sequence without tracking integer position.
Apple apparently has a motive and the warchest for the R&D. If they're hiring cryptographers (has anyone checked?), they're acting on it.
Of Palladium, Bruce Scheier said:
> "There's a lot of good stuff in Pd, and a lot I like about it. There's also a lot I don't like, and am scared of. My fear is that Pd will lead us down a road where our computers are no longer our computers, but are instead owned by a variety of factions and companies all looking for a piece of our wallet. To the extent that Pd facilitates that reality, it's bad for society. I don't mind companies selling, renting, or licensing things to me, but the loss of the power, reach, and flexibility of the computer is too great a price to pay."
I think his fears have come true to some extent in iOS, but knowing what we know now about government surveillance of everybody, it may no longer seem like too great a price to pay. That is, if you trust the vendor. Apple seems to be worthy of that trust. But Microsoft...?
Edit: formatting
We're already paying that price, essentially. An iPhone won't run arbitrary code, a replacement OS, or accept code from arbitrary sources. It's already an exclusively vendor-curated platform. If you're already going to buy into that model, I don't see the point in not going for the greatest amount of protection that you can get. (OK, yes, a dev can compile their own code and push it to their own device. I'm actually not sure why I don't hear about this happening more often as a way to run "unacceptable" programs on iOS devices).
Oh no... it's working...
Edit: a Nexus device bought directly from Google with the right hw may address both points.
I'll repost a snippet from a post by merhdada that hints at the root of one of the problems with android security:
"This can happen only because of a design flaw in the security architecture of Android (L). Unlike iOS and like traditional PCs, the disk encryption key is always in memory when the device is booted and nothing is really protected if you get a device in that state. It's an all-or-nothing proposition."
Please read the entire thread, and check the links referenced in that thread, for information on how issues like these are mitigated.
That's only one issue though. There are a few more.
But none of that even matters a lot of times ... you really won't need to hack an android phone... because the data is also on corporate servers. So the FBI could get at it in any case most of the time.
Is anyone aware of anything that makes this more than a leap of faith?
Do i really need a quad core smartphone with a dedicated GPU 3GB of ram a higher pixel density than i can possibly distinguish, etc etc?
Why would i settle for shitty crypto just because the information isnt a state secret?
In both cases, when was the last time you drove it at its maximum speed all the time? Or ensured that you were using maximum torque at all times and always sitting in the maximum power band for the engine?
If you find that you haven't done these things, you probably should ask yourself why you have a car, right? After all, you're never going to drive the full speed of the car, so why have the car in the first place?
Anyway, a rational politician would have a tremendous uphill battle against both Pride and Ignorance. He or she would have to have tremendous skill as a teacher and a leader, not to mention the emotional fortitude of a Buddha to endure the onslaught of hatred.
Sanders has expressly argued that climate change is a bigger national security threat than terrorism (or anything else) -- and did so in one the Democratic debates, in response to a question on national security threats. While that may not be directly minimizing terrorism, it certainly is explicitly placing it behind other problems in terms of need for focus.
> (And in another twist of irony I am positive that the American Revolutionaries were called terrorists by the British.)
They absolutely were not; the term "terrorists" was first applied to the leaders of the regime of the Reign of Terror in the French Revolution (shortly after the American Revolution), and it was quite a long time after that before the term was applied to actors other than state leaders applying terror as a weapon to control their subject population.
out of curiosity, what evidence is there that there isn't?
perhaps i should ask what you mean by "a terrorism problem" as well.
I have absolutely nothing to hide. I have simply always treated my privacy as something that was valuable in it of itself. Perhaps even more valuable than the photos I clearly opted to not share with others, to go off your example.
I also don't understand why it's so absurd for some people to conceptualize non-malicious things you wouldn't wasn't to share with anyone but yourself. Hell, I have tons of notes and things I write to myself that I definitely do not want to be seen by anyone. They simply weren't written with the intention to be read by others. So I don't sympathize with desire to make a deceased person's private things accessible, even to family. Let it burn. It might have been the owner's intention all along.
The problem here is that a lot of the stuff stored on phones falls somewhere between "dies with me" private and "should pass on to my family" private. Or "should be recoverable if I lose my key" private.
Strong encryption makes it impossible to recover in the event of a lost key or pass on to family in the event of your death. So that's not necessarily a great default for, say, decades of family photos. It would be a huge tragedy if that was lost.
The good news is that Apple does provide tools to opt-in to stronger security, rather easily. For example, the Notes app was recently upgraded with note-level strong encryption. That might be a good solution for your most private notes, without endangering the survivability of your digital memories and assets.
Would you really expect Apple to recover the data in this scenario for the next of kin? I certainly wouldn't, and I wouldn't want them to.
If there was something the deceased person truly wanted hidden from their next of kin, they could use stronger encryption for that. The Notes app, for example, allows for note-level strong encryption. But it's not an ideal fit for the more typical use case.
Anyway, they do it.[1]
[1] http://www.cnet.com/news/widow-says-apple-told-her-to-get-co...
I certainly don't know if Apple should, without a court order, share any of my data that I haven't explicitly shared with next of kin if I passed away.
I'm wondering though - what happens if I stop paying my $2.99/month for 200 GB - will any of my existing photos be wiped out of shared photostreams?
The problem with requiring explicit sharing is that a lot of people don't realize they need to do it to properly navigate these future events. Just look at how many people fail to write wills. You wouldn't want real-world assets to automatically get destroyed because you failed to write a will, even though there may be some things in there you didn't want to pass down. The "failsafe" mechanism there is, a court figures it out. So that's apparently what Apple is doing.
But keep in mind this is not just about next-of-kin. It's also about the ability for you to recover your life if you forget your password. That is why Apple will always have a "backdoor" into iCloud.
A pretty interesting point.
Photos are probably good to recover... unless they were photos of something horrible you did (beat up someone, sent photos of your anatomy, etc.).
What about text messages? Again, it could express what kind of person you are. Do all iOS users have unwitting diaries that will be unlocked at our death in the form of our iMessage and SMS history?
In 400 years, will our ancestors point out, "Wow, great-great-great-grandma was pretty awful, did you see this text they sent once?" in a way that removes context from the message written at the time. This is something we can't know about our ancestors... and probably for the best, since otherwise we might be disappointed in our ancestors.
Or maybe that's an okay thing?
But for bank account records, most photos, etc., you probably don't want those to disappear in the event of your death. You want those to pass on.
Given the choice between the two defaults, it makes a lot of sense for Apple to make "accessible to next of kin" the default, and "dies with you" the opt-in.
And may the era of homomorphic encryption schemes come and thus render moot the need for Apple and other companies to access unencrypted data as a plausible excuse when performing back-end processing/recovery on their client's data.
edit: well, to correct myself, as you said that wouldn't obviate the need for the feature of "recover data without password, after passing some other security tests"
Apple could make truly secure systems user friendly if they wanted to. It seems they may see some value in doing so.
It's just not an option that your average person would want for their family photos.
Q: Can't I already encrypt my iCloud data via a keychain?
Having said that, you can add another layer of your own encryption to certain data that is stored in iCloud, like for example the latest Notes app in iOS 9.3. Apple won't have that key.. but the app warns you the data will be lost if you lose it. You could also encrypt files you store in iCloud Drive using an encryption app. But you wouldn't be able to do this with other data that is managed by iOS like iCloud backups or photo libraries.
This is already the case. Right now, only firmware signed by Apple can be installed. The next logical step is to build a system where the unit that deals with PINs cannot be updated at all, or at least not without wiping all keys. This would prevent any non-invasive attempts of bypassing the rate-limiting of PIN attempts or auto-wipe.
> There is nothing wrong with that situation, and on such equipment, you can secure your data just fine.
Again, this is also true for an iPhone with a sufficiently complex passphrase, Because Crypto™. Secure Enclave is just an additional layer that protects against everyone not in a position to get custom firmware signed by Apple.
> No machine can be trusted if it fell under someone's physical access. Here is a proof: if I get my hands on your device, I can replace it with a physically identical device which looks exactly like yours, but is actually a man-in-the-middle (MITM). (I can put the fake device's board into your original plastic and glass, so it will have the same scratches, wear, grime pattern and whatever other markings that distinguish the device as yours.) My fake device will collect the credentials which you enter. Those are immediately sent to me and I play them against the real device to get in.
The scenario here isn't an Evil Maid Attack. It's about protecting locked devices while someone else has physical access to them. Right now, you're fairly safe from most attackers in this scenario. In the future, with a read-only Secure Enclave, you're also safe from Apple and anyone who could force Apple to sign firmware. The fact that Evil Maid Attacks are harder to pull off because of this is just a nice extra.
> Apple are trying to portray themselves as a champion of security, making clueless users believe that the security of a device rests in the manufacturer's hands. This could all be in collaboration with the FBI, for all we know. Two versions of Big Brother are playing the "good guy/bad guy" routine, so you would trust the good guy, who is basically just one of the faces of the same thing.
This doesn't make sense. There's no crypto backdoor. The worst case scenario for their current security architecture is that it falls back to how FDE works on a desktop system - i.e., it's completely dependent on your passphrase complexity.
How do you plan to flash all the HDD/USB/Network controllers? Not to mention the CPU/GPU microcode, and countless other random chips inside your computer that are executing firmware you have no access to.
We're already hosed. Its just a matter of whats considered a 'reasonable' barrier.
I don't care whether a given processor is microcoded via a tiny ROM, or whether it is all hard-wired gates; the difference is just in the instruction execution timings.
We are not "hosed" in any way by this.
As soon as the microcode is writable, then we have questions: can anyone write any arbitrary microcode and put it in place? Or is there some tamper-proof layer containing that only accepts signed microcode, and who has the keys?
This is something Apple practically guaranteed by using platform DRM to turn themselves into a critical single point of failure.
CALEA was extended to ISPs once ISPS consolidated enough; now that Apple has consolidated central control of mobile devices in a similar fashion, it seems quite likely that extending CALEA to cover smart phones will be on the table.
I'd be extremely surprised if Apple's management wasn't very aware of the CALEA precedent, but they chose to go down this road anyway. I find that rather unsettling.
But unless you can point at - This is Bill, we are targeting Bill, we have a warrant for Bill, we need 1 phone that we will make sure becomes Bill's - All Writs cannot help.
If Bill mails order a new iPhone they can compel apple store to give him compromised device. They could probably put FBI team presenting themselves as store employees in every store if Bill is high value enough target and expected to buy iphone today.
But they cannot say - compromise all of SF Bay Area iphones because we expect one of them to be bought by Bill.
Some of the lawyers here correct me if I am too wrong.
Passphrases suck enough whenever you have to log back in. Are people really gonna put up with that every time they want to use their phone?
On the other hand, if there were a convenient way to toggle between passphrases and 4-digit unlock, (especially if you had to use the passphrases to toggle back to 4-digit) then I would be all for it.
Low-friction UI has been Apple's differentiator for years. If you have to take the time to type out a secure passphrase every time you want to interact with your phone, people will stop interacting with their phones (or use phones that suck less).
Why do you think they built Touch ID? Because typing even a 4-digit PIN is too annoying!
Longer answer: There's a key that encrypts the actual data, and that key is stored on disk, but encrypted with your passcode along with a hardware key. The hardware key cannot be read, only used to decrypt. Changing your code just changes the key stored to disk, but not the encryption key, so it's quick, but preserves security.
Longest and most accurate answer: https://www.apple.com/business/docs/iOS_Security_Guide.pdf from page 10.
To bad flock does not exist any more, a droping replacement for google sync with end to end crypto. Very nice.
Physical defenses are not security through obscurity, and why you assuming they don't use known ciphers?
OTOH, the practical purpose of encryption is to remain unbroken for long enough, not to be completely unbreakable. As seen here, security-through-obscurity is practical enough in cases where user-obtained key material is too weak to provide enough protection using strong publicized crypto. In other words, it's a two-part key: one is in user's wetware, the other in phone's hardware (as per obXKCD, it's usually easier to attack the former).
Honestly, this is really the shit..
"@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...
That has never been the case, for practical manufacturing reasons.
>As soon as the microcode is writable, then we have questions:
It has been writable for more than a decade I think.
Any aspect of the machine which is data-driven is de facto hardware if that data is fixed in read-only memory.
Consider than an AND gate can just be memory. The two inputs can be treated as a two bit address: 00, 01, 10, or 11. If we stuff in the values 0, 0, 0, 1 into the 1-bit content cells at these addresses, we have an AND gate.
If this memory is ROM, then the overall circuit is not distinguishable from a conventional AND gate where a few transistors do the signaling directly.
The long passphrase is used to mount the encrypted file system upon startup, and the PIN code is used merely as a "screen lock", as a casual deterrent from your friends and casual thieves from swiping through your photos before you can catch them.
The file system can be automatically unmounted after a set period of inactivity, or if the user wants to unmount it on demand. After the file system is unmounted, the data is secure again and the long passphrase will once again be needed before anything can be done with the phone.
I currently use a generated long password on my Android phone and have adapted to the extra work, but having the option to enter a password once a day and a pin or shorter password throughout that day would be a welcome convenience option, and it's not really significantly more onerous than just a pin.
Pursuant to the All Writs Act, the Court has the power, "in aid of a valid warrant, to order a third party to provide nonburdensome technical assistance to law enforcement officers."
The most important limitation here is that nobody, including the FBI, is claiming the All Writs Act grants the court any power at all in the absence of a search warrant. Nobody really disputes the statement above, or the validity of the warrant in question.
Again: if the FBI wants Apple to preemptively insert a generalized backdoor into their products they'll need to lobby to have new legislation passed. They've tried that and it hasn't gone much of anywhere. In my opinion lets try and keep it that way.
[1] http://www.wired.com/wp-content/uploads/2016/02/SB-shooter-M...
To preemptively demand a back door is almost akin to guilty until proven innocent, youre assuming that there will be an investigation in the future where a governments ability to hack a device is required.
"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."
[0] http://daringfireball.net/2016/02/san_bernardino_password_re...
"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.
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.
As above, not a good idea for a default, but don't see why it wouldn't be technically viable for opt-in protection.
For reference I've googled every combination of "nsa apple mobile OS leak" I could think of and couldn't find a primary source.
http://www.spiegel.de/international/world/how-the-nsa-spies-...
Helps to type in just what you want and what will specifically have your answer. Mobile will give you garbage most of the time. Apple as well. A technical document will usually reference iOS. Also, you can use quotes to ensure something appears.
Interesting enough, me typing what you typed into Google still led to same leak and others showing potential backdoors. Hmmm.
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.
Enter parallel-constructed information as court-sanitized evidence.
So no, that's not DRM for your own data.
Apple does hold the keys for software updates, which can be pushed without user approval. Maybe that's what you were referring to.
Secure Enclave is a variant of TrustZone (http://www.iphoneincanada.ca/iphone-5s/apples-new-secure-enc...).
The major issue with android systems does not seem to be lacking software and hardware, but rather the unwillingnes of providers to push best practices as defaults to all users.
I somewhat agree and somewhat disagree with your analysis of the politics. Their are both advantages and disadvantages of both situations
Why? I'd expect just the opposite.
To many Americans, Apple is the example of American innovation and entrepreneurial spirit, and a proof that the American model works. Apple employs 10s of thousands of Americans directly, and probably provides jobs for 100s of thousands indirectly. Going too aggressive on Apple, e.g. at the level where executives could be charged in court, or products embargoed, would be a decidedly unpopular move with many voters and politicians. Samsung is a much easier target here.
Also as an American company, Apple can legitimately enter the democratic debate, see the calls it makes to congress. Samsung can't really do that. Imagine Samgsung putting out press release quoting the founding fathers or referring to the first amendment. That would not be credible.
Edit: grammar
Imagine if somebody is writing down there dreams, writing there intimate deep thoughts, tracking symptoms of a medicine, using drugs recreationally...etc. These things might be very very private and be totally abusable outside of context.
It would be better to opt-in to auto-destruct-when-i-die, not opt-out. It's more of a special case. E.g. create encrypted notes for super secret stuff you want to die with you, but let the default security for photos and documents be "private but recoverable in the event of death or forgotten key."
Not to mention, writing that password down in a will would be pretty bad from a security standpoint while you're alive.
Most people don't stick their wills to their monitors with post-its (there are other secrets in there after all, and many people would like to know those); the legal system has mature tools that are surprisingly good at keeping such secrets secret until the release conditions are met. A will is a Solved Problem, with highly reliable solutions - consider the ways to prove that it is indeed to be opened. Contrast with most computerized solutions and "solutions" thereof, mostly hinging on some form of dead man's switch.
"Room 641A is a telecommunication interception facility operated by AT&T for the U.S. National Security Agency"
As long as you have a backdoor, and Apple does, shady government agencies can and do come knocking. We've got plenty of shady government agencies, and can never guarantee that we won't have more in the future.
Our interpretation of already unconstitutional NSLs guarantees nothing.
And whats the difference to me between 452 ppi or 532 ppi? I'll never be able to enjoy the difference between the two, yet i would still go for the higher ppi all else being equal.
Of course there is always an appeal in the numbers. I'd go for a 40MP camera instead of a 20MP one - who cares if the quality of the lens is such that there is no difference beyond 10MP. It's marketing. It's curious how people so wary of being observed or exploited make themselves so prone to basic manipulation by entities who want to get their money.
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.
1. Get a dump of the encrypted data.
2. Try to probe the hardware, potentially destroying it.
3. If the probe works, we're done. If not, put the encrypted data dump onto a fresh iPhone and repeat from step 2.
This way, you effectively get unlimited shots at an otherwise risky hardware probe.
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.
I agree there may be other reasons the user switched, but maybe they switched to android because they believed it to be more secure? Or maybe the user wants to vote with their wallet for the company they see as most in support of security/privacy.
I do agree though, switching for a feature you are unlikely to use is silly, but i think there are definitely reasons enough to make a switch like that from a 'voting with your wallet' type standpoint
Until a few years ago you were perfectly content with keeping an agenda in your pocket and pictures in your living room's drawer. A minimum of privacy is of course needed and welcome; however, unless you're planning a major terror attack, or strategic war plans, or you have incredibly valuable industrial secrets (all cases in which you'll probably be using specialized SW to keep your information) you don't really need incredibly advanced security simply because nobody is going to spend vast amounts of time and resources to uncover your little secrets. The GP is talking about switching phone (spending money) to obtain a level of security that he won't need in a million years.
only because they weren't (thought to be) subject to casual perusal by unknown entities. this is a silly thing to even mention.
> unless you're planning a major terror attack
ah, the "if you don't have anything to hide" rhetoric. do you really buy that?
> a level of security that he won't need
unless there is some nontrivial cost or burden associated, it's a red herring to belabor whether it's "too strong" or "more than needed".
This morning I was having a conversation with my fiancee, who said "if the US government gets a warrant they can open your mail, they can tap your phone calls, they can come into your house and search -- why should your phone be some sort of zone they cannot search even with a warrant?"
I happen not to agree but this is not some wacko view.
As to why they disagree: HN's audience is not representative of the general citizenry. We're better informed about technical security matters (or we like to think we are, at least). I suspect that correlates with being less willing to trust security to the goodwill of third parties.
"If you aren't doing anything wrong, what do you have to fear."
"If you do want something private then you must be doing something wrong, ARE YOU A TERRORIST!?!?!?!"
"About the linked article: out of date (2013, mentions iOS 4.3.3). Very thin on actual information. "
It's what I got out of a quick Google. I was unwilling to spend more time on that angle as my list of risks plus Apple's development practices shows we should consider it untrustworthy by default. I just don't feel like putting too much time into finding the specific evidence NSA might hit a specific version of a product that wasn't secure in its entire history. Also, which came from a company whose products did things like require an admin login on certain services but not check if password matches records: just the existence of a password in submission was enough. Better to spend that time on researching actual security. ;)
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."
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.
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.)
On phones after the 5C, nothing you can do with the AP helps you here; the 10-strikes rule is enforced by the SE, which is a separate piece of hardware. It's true that if you can flip bits in the SE, you can influence its behavior. But whatever you do to extract or set bits in SE needs to not cause the SE to freak out and wipe keys.
The ultimate way to defeat physical or software attacks is to exploit intrinsic properties of the universe, which suggests finding a mathematical and/or quantum structure impervious to both.
So it falls to either 2-factor or biometric to avoid PINs. Biometric of course has it's own problems.
Perhaps people should really carry around a Secure Enclave on a ring or something, and with a button to self-destruct it in case of emergency. (e.g. pinhole reset)
The entire point of an secure enclave is to completely enclose all the hardware and software needed to generate encryption keys in a single lump of silicon.
This means that all of its processing requirements (it's a complete co-processor) are on chip, it's RAM is on chip (not shared with it the main CPU, and probably has ECC), and it uses secure boot to cryptographically verify that it's firmware has not been tampered with before it starts executing. Additionally it may even be possible to update it bootloader in the future to prevent further updates without a passcode.
The end result means that attacking a secure element is very difficult. There are few, if any, exposure points that would allow you to fiddle with its internal state, and any attempts too should result in the secure element wiping stored keys, making further attacks a moot point.
http://www.nasdaq.com/article/apple-standoff-escalates-local...
http://www.leadertelegram.com/News/Front-Page/2016/02/20/Off...
http://www.argusleader.com/story/news/2016/02/18/sf-police-c...
The NSA did infact try to build backdoors into important hardware and software standards. They did push companies into using worse crypto. The do massiv port scanning and build themself botnets from where thet attack other nation states. And thats just a tiny fraction of what they do.
So yes, I absolutly do need computer hardware and software that even the manufacturer cant break. Low level security for boot and authentification is only the first in many, many steps that we have to take all the way up to imroving usability in end user applications to make it hard to do the wrong thing.
The FBI are not the o ly player, all governments want such control, all governments have things like the NSA. Even private actors are getting better and better.
We do need better security to protect the integrety of all our data, this includes all our communication and even, if possible metadata that we produce.
The point is that state actors have vast resources to pull off these attacks. The NSA intercepted hardware in the supply chain to implant attacks as documented by Snowden. Stuxnet was a super-elaborate attack on the physical resources of the Iranian nuclear program, which was obviously carried out with supply chain vendors like Siemens. Apple uses Samsung as a supplier, and the US government has very high level security arrangements with the South Koreans, so how do we know the chips haven't been compromised even before they arrive at Foxconn for assembly?
Here's an example of a TPM module being decapped and hacked at Blackhat: https://redmondmag.com/articles/2010/02/03/black-hat-enginee...
Attacks have been shown using silicon doping, security fuse cutting, etc.
If the NSA really wanted to crack the Secure Enclave, I have very little doubt about their ability to carry it out.
Well they certainly really want to crack the Secure Enclave, so maybe this case is moot.
Seems to me when we are at a point were every time the NSA wants to get at some data, the have to start a heroic effort of attacking low level hardware, we are in a pretty good state in terms of device security.
Apple's security guide would indicate otherwise, look on page 7. The secure enclave encrypts its portion of memory, but it isn't built into the secure enclave itself.
If you have a stronger passcode, you see a full keyboard instead.
Far as parallel construction, let me see if I can quickly Google something. Here's you a few on it early on with FBI and DEA's stronger cooperation.
https://www.techdirt.com/articles/20150427/11042430811/nsas-...
http://www.reuters.com/article/us-dea-sod-idUSBRE97409R20130...
Further, they'll actually let a criminal go just to prevent either the public or courts learning the details of defense-related techniques. The Stingrays are a perfect example:
http://arstechnica.com/tech-policy/2015/04/fbi-would-rather-...
However, your original comment made it sound like we had direct confirmation of that fact. I hadn't heard that before, which is why I was interested.
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 ;-)
There is no reasonable argument to be made that people shouldn't have higher quality products when they _don't_ cost more^.
Apple only have to develop "unbreakable" encryption once and then it costs them no more to make it available in every iPhone than to only make it available in some of them. Indeed, it'd be cheaper than maintaining both breakable and "unbreakable" variants.
There are arguments to be made about the secure enclave hardware, since it presumably costs more to make it more tamperproof.
However, securing iPhones against this particular "attack" appears to be a software issue: iOS should never apply updates without an authenticated user approving them first.
^ For the avoidance of doubt, this includes externalized costs.
If you're using a breakable crypto , you're not protected at any given time.
If you're using a watch that's waterproof up to 100m, you're safe up to 100 meters.
To be pedantic, that's not exactly what is meant by 100m Water Resistant, but your point is valid.
Although no watch can be absolutely waterproof, not even at a given depth, there are levels of risk one can accept. A watch you can use at 100m for several hours a day is effectively waterproof if that's the harshest treatment the watch will receive.
Similarly, although no cryptographic system is absolutely unbreakable^, there are levels of risk one can accept. And, unlike with watches, we can design cryptographic systems which, except in the face of unforeseen mathematical breakthroughs, or bugs (or backdoors) in their implementation, cannot be broken in the next few hundred years even by a nation state-level attacker.
I think is it reasonable to describe a cryptographic system that can't be broken within the lifetime of anyone alive today as "unbreakable".
^ Except maybe one-time-pads, depending upon how "unbreakable" is defined.
It depends, how many meters does it have to claim before I can make sudden movements and god forbid press the buttons underwater?
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.
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?
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.
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.
Now, is a cryptography that can't be broken by anyone except maybe (that hasn't even happened yet) through a specific court order signed by a judge, reasonably secure? I think it qualifies as such. If you need even more security, I'm sure you can use specialized software to achieve it - I'm not saying you shouldn't be allowed to.
Assuming I agree that a security system that can be turned off remotely by its vendor is reasonably secure, it is only a specific court order now. If Apple are successfully compelled to produce a version of iOS that bypasses PIN security, it will be much easier for the FBI to request that it be deployed on phones in the future - after all, that version of iOS will already exist then.
If Apple do make it, I am certain there will quickly be a slew of court orders regarding other iDevices that the authorities have in their possession, all of which are likely to be harder to defeat than the court order they would just have failed to defeat.
However, I don't agree that a security system that can be turned off remotely by its vendor is reasonably secure, anyway. There is nothing technically requiring Apple to wait for a court order: the phone will accept their new software whether or not it comes with a court order. Apple could decide to make PIN cracking available to anyone who can prove they own a given iPhone. Given their attitude, they probably won't, but the actual security mechanism is reliant on their goodwill for it to remain unbroken. I don't consider that reasonable.
this would seem a rather scary precedent of forced, unwilling labor. i wonder if it could be construed as "involuntary servitude".
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.
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.(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.)