> Unless you made a backup before you forgot your passcode, there isn't a way to save your device's data. You'll need to erase your device, which deletes all of your data and settings.
Looks like the deceased had an iCloud backup of his iPhone, potentially unencrypted (i.e. without a password - Apple obviously encrypts this on their end). More in the iCloud security model: https://support.apple.com/en-us/HT202303
Edit 2: You can turn off iCloud backup altogether to avoid this (on an iPhone: Apple ID -> iCloud -> iCloud Backup -> Off).
If I recall you cannot, I think Apple has the keys to your iCloud account so its always available for unlock (iCloud not the phone itself) this is how they provide access to authorities when they have a warrant. This was the case a few years ago, it might have changed since.
I believe this is the case for unencrypted iCloud backups. If you put a password on your iCloud backup, I'm not sure they can do that (as then it becomes E_iCloud(E_yourPwd(backup)) - doesn't look like they could do much more here than recover the user-encrypted backup).
This is not true. Under no case can Apple unlock an iPhone's passcode protection with the iCloud account, unless Apple is hiding something major. More likely, the iPhone was backed up to iCloud, and Apple granted access to the iCloud backup, which would probably be essentially identical to the contents of the iPhone itself.
I think you might be conflating macOS and iOS. When you enable FileVault (macOS full-disk encryption), you are given the option to upload a recovery key to Apple tied to your iCloud account. To my knowledge this is not offered with iOS.
For context, this article is regarding a Fair Go story. They're like a "Stand up for the small guy" type show here in New Zealand so it's not surprise that they didn't really go into detail at all. Their target audience wouldn't know, nor likely care how Apple went about this process. The same could also be said likely about whether it was a phone unlock or an iCloud dump. Viewers just want to see a happy ending for the "small guy against the big corporate"
Incorrect here in New Zealand. The dead have less privacy rights but not zero. In particular, if the information relates to another person and may breach their privacy it should be kept private. Seems complicated.
EDIT: On a second reading it looks like there's a difference between the "on server" encrypted data and the "end to end" encrypted data. Backups are covered under the former but not the latter. Shame.
However, I am really curious about whether or not using iCloud Backup negates these protections. For iMessages, Apple specifically says that it does: "If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages." In other words, if you use iCloud Backup, Apple specifically holds a key allowing them to decrypt your messages in your iCloud backup.
it’s encrypted but they have the keys. you can access iCloud data via web, so they definitely have the capabilities to decrypt it before sending it to your browser.
"Good because I left secrets on the kitchen table"
"Oh, the landlord has a key. But it's locked"
"Um, ok. It's sort of locked. It's locked, but other people can get in. All I really care about is my secrets so I guess I'll just go back and get them and find someplace else to leave them that's more 'locked'"
This is ridiculous. A door is either locked or it isn't. The word makes no claim about how secure the lock is. No matter how you try to twist this topic to suit your views.
In the same way a file can be encrypted, yet be insecure because somebody untrustworthy has the key to decrypt it. Doesn't change the fact that on a technical level, it's encrypted.
What's ridiculous is having a semantic argument when you know people's intent. Yes, someone said "locked" and someone said "encrypted", but what they meant was "secure". I think we all get their meaning. They are saying, what good is this if it is not secure? I mean, what good is it? It'll keep your significant other out, but not Apple employees and not the police? Is that the technical-level benefit?
It's not a definition, it's pointing out that someone was being pedantic about the meaning of "locked" and "encrypted" when Apple employees can seemingly read your encrypted iCloud date. They wanted to be "technical", but nobody was talking about technicalities. They were talking about security. iCloud data seems to be locked, encrypted and insecure! One of those words is not like the other
Depends how willing the landlord is to open your front door upon request.
And how secure your landlord stores your front door key.
So if your landlord is careless and/or willing to open your door to people requesting them to do so, you can assume that your landlord IS indeed an adversary.
No? It just means they can access it. Encryption turns plaintext into ciphertext; it says nothing about the security thereof. I can ROT13 encrypt a message. Just because you can easily use cryptanalysis and read my message doesn’t make it any less encrypted.
I think they could pull it off in a way that would result in few inaccessible backups. The decryption keys could be stored on your iCloud Keychain, so if you lose one iOS device, the backup can be decrypted with another iOS device you own. And maybe the encryption key could itself be derived from your device's passcode in some asymmetric way.
They can’t because it’s obvious they have a secret FISA order preventing them to. The recent iMessages in the Cloud shows this: messages are end to end encrypted in iCloud using a separate, unique key that is only stored on your devices... and this key is uploaded to your iCloud account if you have backup enabled. No choice.
This is after the original version, got pulled from the beta suddenly with no reason and no widely reported bugs.
The design of this irrational system only makes sense when a 3 letter agency saw it, and got FISA to compel Apple to key escrow.
>The design of this irrational system only makes sense when a 3 letter agency saw it, and got FISA to compel Apple to key escrow.
Or the more common reasoning: Apple wanted to provide a method for you to restore your new iPhone from an iCloud backup without treating your Apple ID password as an encryption key.
This will become an increasingly untenable solution in the future. Apple has been pushing iOS towards independence from PCs in the past couple of years, removing things such as installing apps through iTunes. Additional iOS and macOS updates could create new bugs in the iTunes/iOS sync process that Apple may not want to bother fixing anymore. They might remove iTunes backup entirely. And there are increasing numbers of iPhone users without Macs or PCs at all.
Law enforcement officials could, until recent iOS updates, unlock iPhones by brute-forcing passcodes with a device attached to the Lightning port. The phone was likely not updated to the latest iOS builds. So wouldn't Apple be able to do the same?
The implication is that the police device uses a flaw unknown to Apple (lest they fix it). It is not normally supposed to be possible to brute force passcodes like that.
What measures are in place to prevent the FBI from imaging a phone, and then brute forcing every possible pin combination? Would these measures be able to stand up against a team of reverse engineers, with near unlimited resources, which I assume the FBI would be able to find for the task?
Other avenues of gaining potentially useful data will be utilized as well. Does the FBI have access to data stored on Apple's cloud servers? What about the fingerprints of the suspect, or other methods of bioidentification?
The pin code gets entagled with a unique per-device key Apple calls the UID, the combination is what encrypts the data on-device.
Only the Secure Enclave has access to the UID, but only through silicon, it can't read the key bytes.
The Cellebrite rigs do use the Secure Enclave to brute force, but they're acheiving roughly 1s/guess, and the theoretical fastest is 80ms because the Secure Enclave uses PBKDF2 iterations tuned for that time.
If you have a long numeric passcode or an alphanumeric passphrase you can be confident your iPhone is secure when it's off.
As thisacctforreal mentioned, both the PIN and the device UID are used to generate the actual encryption key. Even if someone were to get access to the UID, the amount of processing to generate an encryption key for each PIN possibility would be costly, so it may be the case that simply bruteforcing would take prohibitively long.
I know that on an iOS device itself, if passcode attempt limits didn't exist, it takes a whole 90 milliseconds to check each passcode. That's only 10 passcode attempts a second, and if the passcode is sufficiently long, it could take years.
It's trivially parallelized if you've got the data and the device uid extracted. Combined with more powerful cpus, it could easy end up 10k pins per second if you can try to decrypt it (or verify it) externally. Combine that with most people's lackluster pin selection and length you've probably got the ability to unlock a phone in a few minutes to hours.
Not as much as you might think, the iPhone is going to be doing a single decryption and checking action per attempt. If this takes 90 milliseconds because it's also going out to the secure chip to do the key derivation with the device uid so that the cpu and main ram never sees all the information to derive the full key on it's own then once you have both of those pieces of information (as was stated in this hypothetical) then you've eliminated the slow communication and slower processor involved. This could easily mean you can now do the derivation of the key in a much quicker fashion (I'd be surprised if it's not 10s to 100s of microseconds). But that's assuming that the bulk of the time isn't being spent on something like a modern key derivation function from the user's pin which is quite possibly a bad assumption (nobody knows these details outside Apple as far as I know). So let's say it's that, we've now got maybe 80ms of real cpu time on the iphone (not counting the communication to secure chip). This is still going to just be one core of the iphone's cpu doing this (no parallel KDFs that I'm aware of) and it's still trivially parallelizable. I don't know exact specs but lets say a modern intel cpu is going to be only 4x faster at this KDF because apple put in special cpu hardware to help accelerate it and other crypto operations. Now we multiply that by however many cores we can get (RAM isn't going to be an issue here even if it's a memory safe KDF, on a real computer or server we can always add more, terabytes if needed). So at this point we've got ~10-12 checks per second (80ms) times 4 for just the single core speedup, and then we can multiply that by the number of cores/threads we can throw at it, 256 wouldn't be too hard to get at (amd 2x epyc 64 core cpus). That gets us to 10240-12284 password checks per second. Even if that 4x is 2x or 1.5x it's still relatively easy to just throw some more servers at it since the actual check is so trivial to do in parallel. This would be very easy to be within a state actor or even a large corporation's budget if they had the need.
That's why Apple is so hard on making the secure chip they use for the encryption and holding the device uid. It's really the only thing that can keep that from being within a $10k-15k budget to break a bad passcode/pin. If they aren't using a modern KDF that has memory safety, branch safety, and other defenses in it then all the above goes out the window since you can now throw some really cheap GPUs and do it in parallel at a scale that's even more insane.
Have a look at some of the GPU benchmarks for John the Ripper
No inheritance doesn't compel Apple to unlock that inherited property. Imagine it like a safe. You might inherit a safe but there is no obligation on the manufacturer to help you unlock it.
To push the analogy, if you need a code to open your safe, but forgot to put the code in your will, is the manufacturer required to provide you a master key?
The deceased is expecting to make the necessary preparations before dying. Facebook has a system to let a user allow trusted user to takeover access, or let a user allow a group of friends to agree to takeover access; which both seem good methods of handling inheritance of account data.
I think a more appropriate analogy is that this is like a safe deposit box. You lost the key. The bank is obligated to help you out, even if for a fee to drill the lock.
Where the analogy breaks down is the level of difficulty --- even the strongest safe in the world is crackable given enough resources, and we know how to do it very well. Good encryption is impossible to break within the lifetime of the known universe.
I say this as someone who has sadly had to explain to others a few times, that recovering encrypted files is nothing as easy as "busting it open" in the physical world.
This is incidentally why governments are scared of encryption, but IMHO users should be too --- it is very, very strong technology. Encrypting data with a suitably secure algorithm and losing the key means it is truly gone forever. You have to weigh that risk against the risk of someone else getting access to the data.
I think the story here (for HN readers) is that Apple can unlock the iPhone; isn't it supposed to be encrypted? Does Apple having the capability to unlock it mean that the encryption is backdoored?
(Other commenters have speculated that it's sloppy reporting, and that Apple gave them the iCloud backup contents, not the contents of the phone itself.)
I hope someone informed her on recommended backup practices. Imagine going through all that trouble and then losing the data again because of hardware failure.
This entire thing is very eerie. Someone might rumor that you have had argument with some female non-employee yesterday in a bar and next day you could be unemployed. Employers are now frequently rolling out judgements if employees don't conform to their world view even outside of work. An employer unilaterally decides if unlocking a phone for person X fits in to their fency and whims. Sure, you can say that vote with your wallet but the bigger question is why we as citizens should accept such unabashed power bestowed to any entity to roll out decisions that should be made by court of laws with due process.
80 comments
[ 3.4 ms ] story [ 178 ms ] threadEdit: I think I'm wrong and misremembering.
Edit: https://support.apple.com/en-us/HT204306:
> Unless you made a backup before you forgot your passcode, there isn't a way to save your device's data. You'll need to erase your device, which deletes all of your data and settings.
Looks like the deceased had an iCloud backup of his iPhone, potentially unencrypted (i.e. without a password - Apple obviously encrypts this on their end). More in the iCloud security model: https://support.apple.com/en-us/HT202303
Edit 2: You can turn off iCloud backup altogether to avoid this (on an iPhone: Apple ID -> iCloud -> iCloud Backup -> Off).
In most cases though, a phone backup is an identical substitute for the phone itself.
Anyone care to confirm?
https://privacy.org.nz/further-resources/knowledge-base/view...
Then it is the living person's privacy rights which are in force, not the dead's.
https://support.apple.com/en-ca/HT202303
EDIT: On a second reading it looks like there's a difference between the "on server" encrypted data and the "end to end" encrypted data. Backups are covered under the former but not the latter. Shame.
The fact people don't appreciate what Snowden leaked and infosec in general is as much a result of that as it is negligence or humans being 'bad'.
However, I am really curious about whether or not using iCloud Backup negates these protections. For iMessages, Apple specifically says that it does: "If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages." In other words, if you use iCloud Backup, Apple specifically holds a key allowing them to decrypt your messages in your iCloud backup.
Yes, you can never be sure that your landlord has not let other people into your house. Your landlord could let the police into your house
"Did you lock the house?"
"Yes"
"Good because I left secrets on the kitchen table"
"Oh, the landlord has a key. But it's locked"
"Um, ok. It's sort of locked. It's locked, but other people can get in. All I really care about is my secrets so I guess I'll just go back and get them and find someplace else to leave them that's more 'locked'"
In the same way a file can be encrypted, yet be insecure because somebody untrustworthy has the key to decrypt it. Doesn't change the fact that on a technical level, it's encrypted.
And how secure your landlord stores your front door key.
So if your landlord is careless and/or willing to open your door to people requesting them to do so, you can assume that your landlord IS indeed an adversary.
This is after the original version, got pulled from the beta suddenly with no reason and no widely reported bugs.
The design of this irrational system only makes sense when a 3 letter agency saw it, and got FISA to compel Apple to key escrow.
How is that obvious? And how a court do this? What would be the legal basis?
Or the more common reasoning: Apple wanted to provide a method for you to restore your new iPhone from an iCloud backup without treating your Apple ID password as an encryption key.
Other avenues of gaining potentially useful data will be utilized as well. Does the FBI have access to data stored on Apple's cloud servers? What about the fingerprints of the suspect, or other methods of bioidentification?
Only the Secure Enclave has access to the UID, but only through silicon, it can't read the key bytes.
The Cellebrite rigs do use the Secure Enclave to brute force, but they're acheiving roughly 1s/guess, and the theoretical fastest is 80ms because the Secure Enclave uses PBKDF2 iterations tuned for that time.
If you have a long numeric passcode or an alphanumeric passphrase you can be confident your iPhone is secure when it's off.
I know that on an iOS device itself, if passcode attempt limits didn't exist, it takes a whole 90 milliseconds to check each passcode. That's only 10 passcode attempts a second, and if the passcode is sufficiently long, it could take years.
EDIT: removed bad math
That's why Apple is so hard on making the secure chip they use for the encryption and holding the device uid. It's really the only thing that can keep that from being within a $10k-15k budget to break a bad passcode/pin. If they aren't using a modern KDF that has memory safety, branch safety, and other defenses in it then all the above goes out the window since you can now throw some really cheap GPUs and do it in parallel at a scale that's even more insane.
Have a look at some of the GPU benchmarks for John the Ripper
https://openwall.info/wiki/john/GPU
In short, physics.
It's not the PIN they'd have to brute force, but the encryption key... and that's where physics comes in.
I say this as someone who has sadly had to explain to others a few times, that recovering encrypted files is nothing as easy as "busting it open" in the physical world.
This is incidentally why governments are scared of encryption, but IMHO users should be too --- it is very, very strong technology. Encrypting data with a suitably secure algorithm and losing the key means it is truly gone forever. You have to weigh that risk against the risk of someone else getting access to the data.
(Other commenters have speculated that it's sloppy reporting, and that Apple gave them the iCloud backup contents, not the contents of the phone itself.)