Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I couldn't find anything that describes whether Apple can access your iCloud data in response to a law enforcement request. (I.e., whether it's encrypted in situ.) Does anyone know?


Apple will provide iCloud data in response to search warrants. Horse's mouth: https://www.apple.com/legal/more-resources/law-enforcement/


All your iCloud content is encrypted in transit and, in most cases, when stored (see below). If we use third-party vendors to store your data, we encrypt it and never give them the keys. Apple retains the encryption keys in our own data centers, so you can back up, sync, and share your iCloud data.

If I'm reading this correctly, it looks like most things are encrypted while on iCloud. Namely:

  - Photost
  - Documents
  - Calendars
  - Contacts
  - iCloud Keychain
  - Backup
  - Bookmarks
  - Reminders
  - Find My iPhone
  - Find My Friends
But these aren't encrypted on iCloud:

  - Mail and Notes (Though they are encrypted in transit)
I would think this means that Apple is able to hand over Mail and Notes data sans encryption?

On another page it reads: On devices running iOS 8, your personal data such as photos, messages (including attachments), email, contacts, call history, iTunes content, notes, and reminders is placed under the protection of your passcode. Unlike our competitors, Apple cannot bypass your passcode and therefore cannot access this data.

I read this to apply only to items stored on the device itself. Not on iCloud.

But I hope I'm reading this wrong, and Mail storage is indeed encrypted on iCloud.


It doesn't matter what is encrypted, Apple has the keys, as the paragraph you quoted notes.


I thought that the data would be encrypted with your device's key, not Apple's key.

Here's a quote of his from the Charlie Rose interview: We’re not reading your email, we’re not reading your iMessages. If the government laid a subpoena on us to get your iMessages, we can’t provide it. It’s encrypted and we don’t have the key.

Perhaps that's not the case? Or rather, perhaps that's literally only the case with iMessage? I don't think iMessages are ever stored on iCloud, and instead only ever propagate from device to device...


I am pretty sure you can retrieve data on multiple devices and also restore without the phone.

All of which is moot since Apple can simply be ordered to write software to leak or capture passwords and decryption keys.


Actually within US law and case law, even the horrible Patriot act, that is not true. The government cannot require you to design your photo service (for example) to allow eavesdropping. They almost made that a law back in the 90s but enough tech companies freaked that it got shitcanned.

Similarly, you cannot be ordered to lie and say the NSA has not been given access to your servers, you can only be ordered not to discuss it if it has happened.


They do for certain technologies (see CALEA) but even for others they would be required to take reasonable effort to comply with court orders. Intercepting passwords isn't particularly difficult, assuming they don't have them already. Lavabit was required to do something like this.


That is not true. Remember Lavabit.


Hmm, yes. That makes sense. Being able to retrieve from a different device would blow the 'by device' idea apart. And you're also able to reset your password and have access to all of your stored information, which I think just further enforces the concept that nothing you're storing is unreadable by Apple(Or any requesting agency...).

I'm not sure how anything could be safely stored on their cloud(or any cloud), given these features.


And Apple can say "Nope" and make it all very public and take it all to the SCOTUS.


Besides the fact that they can't (as we have seen with NSLs) admitting that the outcome is contingent on policy means the (technical) security is broken.


Yeah, just like Lavabit and Yahoo, oh wait...


The paragraph he quoted notes that Apple does not have the keys.


From Apple's site:

> Even if you choose to use a third-party application to access your iCloud data, your username and password are sent over an encrypted SSL connection.

So user/pass is sufficient to access cleartext of your data, and Apple definitely has that.

This should be obvious: If there is any way to recover your data when you lose your phone (without using a secret key that is never shared with Apple) then the security is broken.


How do you propose to solve the problem of a user's house burning down with their phone, laptop, and iPad? Tell them sorry, your iCloud backups are encrypted and now all the keys are gone?

So encrypt the iCloud backup with a password you say... Except you need a password to get in to iCloud already so how is that any different?

And for the record, Apple stores password hashes, so they don't have your password. Unless you think they are just lying repeatedly for no good reason.

When was the last time you verified the chip layouts for your CPUS to ensure there were no back doors? Didn't think so.


I think you're being a bit overly defensive here. (S)he was just pointing out some facts about the system that I didn't grasp in my initial post. It's important that we remain critical of any system. And it's equally important that we remain conscious of their potential flaws and design trade-offs.


I didn't propose to solve any problem, I pointed out the obvious flaws in claims about Apple's security and resistance to gov requests.

Private keys are different than passwords.

Password hashes are computed server side where the password can be trivially intercepted.

CPU backdoors are a security problem, that doesn't negate the existence of other security flaws. Moreover CPU backdoors are far more costly to implement and effort should be directed first at cheaper/easier weaknesses, like ineffective encryption of data.


> If I'm reading this correctly, it looks like most things are encrypted while on iCloud. [...]

If that list is accurate, that's great.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: