Slashdot Mirror
Tim Cook Says Apple Can't Read Users' Emails, That iCloud Wasn't Hacked
Apple CEO Tim Cook insists that Apple doesn't read -- in fact, says Cook, cannot read -- user's emails, and that the company's iCloud service wasn't hacked. ZDNet presents highlights from Cook's lengthy, two-part interview with Charlie Rose. One selection of particular interest:
Apple previously said that even it can't access iMessage and FaceTime communications, stating that such messages and calls are not held in an "identifiable form." [Cook] claimed if the government "laid a subpoena," then Apple "can't provide it." He said, bluntly: "We don't have a key... the door is closed." He reiterated previous comments, whereby Apple has said it is not in the business of collecting people's data. He said: "When we design a new service, we try not to collect data. We're not reading your email." Cook went on to talk about PRISM in more detail, following the lead from every other technology company implicated by those now-infamous PowerPoint slides.
Is it legally possible... Not everywhere certainly.
http://www.cnet.com/uk/news/in...
Is he required to lie about this?
It seems they've picked "privacy" as a fighting point vs Google. They don't seem to realize that people either
1- don't care anyway
or
2- care, and know Apple is bullshitting.
The Cloud - because you don't care if your apps and data are up in the air.
Tim cook, talking head who has only ever held managerial roles in various fortune 100 companies, expels platitudes about the sanctity of the iGalaxy for users who slept through FISA and NSA backdoors and only recently began giving a shit when selfies and nudes were leaked from the magical cloud by notorious hacker 4chan.
Good people go to bed earlier.
Article subject says, “email,” but TFS says, “iMessages.” Those are different things, and the security of them is handled very differently because the mechanism of access is very different.
Apple being unable to access emails is impossible since they must deliver them in plain text to plain-old IMAP clients that don’t support decryption or key storage.
Apple being unable to access iMessage contents is plausible. My understanding of the protocol is something like this:
Alice starts texting Bob’s phone number. Alice’s iDevice contacts Apple’s servers to see if Bob’s phone number is registered with iMessage. If not, Alice’s device sends a plain-old SMS. If it is, Alice’s device receives a list of public keys for each of Bob’s registered iDevices. Alice’s iDevice encrypts the message with a session key, then encrypts that session key to each of Bob’s public keys. Her device transmits the encrypted message to Apple’s servers which then transmit it to each of Bob’s devices as they become accessible. Each of Bob’s registered devices can use its private key to decrypt one of the encrypted session key blocks, then use that to decrypt the message.
The private key to decrypt session keys never leaves Bob’s device. The session key never travels in the clear outside Alice’s or Bob’s devices. Apple can retrieve sender/recipient info (ye olde metadata), but no message contents.
The one gotcha to all of that is that since Apple controls all SSL certs involved in the process, they could MitM attack the process if they so-choose (or were so-ordered). There’s no certificate pinning or checking implemented, so Alice’s iDevice has no way of knowing if the public keys it retrieved for Bob’s iDevices might also include an extra key held by Apple or LEO.
Assuming Apple is compelled to intercept messages from Alice starting at a particular date, messages sent before that date at rest on their server should remain secure (unless they’re lying and are currently MitM or escrowing keys). New messages sent while the MitM was active could be decrypted and provided to LEO. Whether or not they’re performing an MitM at present should be detectable by analyzing the traffic during new device registration or sending messages — IE if Alice checks the keys received and confirms them all with Bob manually (jailbreak most likely required). If they don’t match or there’s an extra key, something’s wrong.
There’s an in-depth protocol analysis of iMessage here: http://blog.quarkslab.com/imes...
Scroll to the bottom for the tl;dr on that analysis. That post also includes proof of concept software to check for an active MitM attack, at least on iMessage for Mac.
tl;dr: Apple is in a trusted position where they could intercept message on a per-user basis if compelled to do so, but the general case of iMessage working as intended leaves messages encrypted on their server with keys they don’t have. I’m not aware of any way that Apple could perform that attack in an undetectable fashion, though performing that detection is well beyond the ability of most users.