Tim Cook Says Apple Can't Read Users' Emails, That iCloud Wasn't Hacked 191
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 this technically impossible - no. (Score:5, Interesting)
Is it legally possible... Not everywhere certainly.
http://www.cnet.com/uk/news/in... [cnet.com]
Is he required to lie about this?
Re:Is this technically impossible - no. (Score:5, Insightful)
He makes a fair point. The data stored at Apple does not generate revenue for Apple, at the contrary of Google - where your emails are scanned for content to target ads at your eyeballs.
Now, jumping from that to "We cannot do it even if we wanted to" is quite a leap forward. I'm not sure I trust that part of the statement.
Re: (Score:2)
Data stored by Apple certainly does generate revenue them. It's a service that requires or at least strongly encourages you to buy expensive Apple hardware. They don't provide it out of generosity.
Re: (Score:3)
Semantics, but... the data "itself" does not generate revenue; it is an auxiliary to the expensive device. Contrast that to Google, the data is the central bit about the targeted adverting. That is the distinction done here.
Re:Is this technically impossible - no. (Score:5, Insightful)
Is he required to lie about this?
Very likely, if I can read my mail, so can he. It's only logical.
Re:Is this technically impossible - no. (Score:5, Informative)
Very likely, if I can read my mail, so can he. It's only logical.
The fact that an organization acts as a conduit for delivering messages does not necessitate that they have the ability to read the contents of those messages. The one does not follow from the other. It may be likely that the two go hand-in-hand, but by no means is it logical that they would do so.
The various white papers [apple.com] and other security documents Apple has released over the last year or two make it clear that they claim they do not hold the private keys necessary to decrypt their users' data. Those private keys reside on the devices of the users, with unique keys being generated for each device and unique copies of the data being maintained separately for each device. For instance, in the case of iMessages, here's how Apple claims they work:
1) I type up an iMessage to send to another Apple user and press Send.
2) My device queries Apple's servers for the public key(s) of the recipient, which could be numerous if they've configured iMessages to arrive on multiple devices.
3) My device creates and encrypts one copy of the message for each device, using the public key that is specific to each device for the copy going to it.
4) My device signs the copies using its private key.
5) The iMessage is sent to Apple, who then forwards it and immediately deletes it, unless they can't deliver it, in which case it'll stay queued for up to 7 days.
6) The recipient's device verifies the signature against my public key and then decrypts the message using its own private key.
Assuming the system works as described, Apple shouldn't have access to the content of the messages. Whether or not you believe that it works as described is a matter of how much faith you put in corporations and/or the governments that might be compelling them to insert backdoors. For instance, there are trivial ways that they can circumvent their own systems to gain access to messages, without having to compromise the private keys at all. The easiest way I can imagine would be to simply provide the public key of a wiretapping device in addition to the other keys in step #2 above. Unless you're sniffing your own traffic to ensure that you're sending EXACTLY what you're expecting to send, you'd never notice that you've sent out an extra copy of the message, and would be entirely unaware that it had landed on a government agent's device as well.
But again, it isn't logical that they would have that sort of access. "Likely", given the state of things? Sure. But logical? By no means. Again, the one does not follow from the other. Particularly so in the case of Apple, since their money comes from hardware sales, not from monetizing the user's information, so it's in their best interests to make those devices as secure to use as possible.
Re: (Score:2)
I'm not sure whether to follow your logic, or the guy who said Tim Cook is a big fat liar.
Re:Is this technically impossible - no. (Score:5, Insightful)
People are conflating the "iMessage & Facetime" part of the quote with the "email" part. He says that they cannot (that is to say "do not have the ability") to read iMessage & Facetime. He then states that they do not read your email. People are pulling the "cannot" along with them when they read that sentence, but it doesn't say that they cannot read email, only that they choose to not read your email.
Your description of the iMessage encryption is good, but what the original poster said was true given a few constraints. So let me restate it in a logically consistent manner: if I can read my icloud email on any browser then apple also has the ability to read it.
But, but, maybe they encrypt it using your password on their server! If they did, "change password" would always require the old password and if you forgot your password your email would be lost forever. So, no, they're not doing that.
The bottom line is that if they can show me my email in any browser (which they can) then they can also read it trivially.
This isn't inconsistent with Cook's statement - he merely says that they choose to not do that.
Re: (Score:2)
Apple say that the data is encrypted with a key derived from your password. Okay, that says they could be telling the truth, in so far as they don't store the key.
However, in practice it's meaningless. They could easily make the client send the password to them in plaintext for target accounts (weren't Hushmail suspected of doing that years ago?) For most users they could just brute force the password. We have to take their word for it that the password storage is properly secured, e.g. hashed with a unique
Re: (Score:3)
Re:Is this technically impossible - no. (Score:5, Insightful)
Wrong! They have the ability to reset your password without losing your data so they would need to have either have access to the password itself or the keys to decrypt stored data.
Re:Is this technically impossible - no. (Score:4, Interesting)
Assuming the messages are encrypted on Apples servers at all, they would likely be encrypted with a random key, and a copy of that key would then get encrypted with your password, and another copy encrypted with something support can use (ie. apple owned), so that changing your primary password does not change the underlying key, but just changes the encryption on the copy. There may be multiple layers in there, and public key/private key stuff, etc, but that's one simple description of how, for example, you can send an S/MIME encrypted email to multiple recipients (primary message is encrypted once; its key is encrypted by the public key of each recipient and attached to the email; their private key can decrypt the key and read the message).
That said, my gut doubts there's much encryption going on. This quote:
such messages and calls are not held in an "identifiable form."
... I've heard similar from many C-line (ceo/cto/etc) calls and RFC's (ex. discussing PCI-DSS or SSN security). It generally means there's just an extra hop between foreign keys. I mean, it's obvious that the messages are identifiable from some perspective (your phone), so the breadcrumbs are there somewhere. Things that get downloaded or are real time (SMS and calls)... maybe they remove the lookup and leave the original data? There's still some ID on them.
Re: (Score:2)
I agree with you, and I thought i was saying the same thing :-)
Re: (Score:3, Insightful)
That is the best proof I've seen in this discussion.
Summary for the unwashed masses: Tim Cook is a big fat liar!
Re: (Score:2)
That is the best proof I've seen in this discussion.
Summary for the unwashed masses: Tim Cook is a big fat liar!
The first statement is valid. However, it is possible that Tim Cook isn't lying and instead just relaying what he believes to be the truth based on what he was told. Ignorance is not the same as lying, which requires intent to deceive.
Re: (Score:3)
He also may be using weasel words, he may be stating there is no application that currently exists that allows a staff member read your emails. Not that one cannot be written, rather simply.
This maybe true, but the intent of the statement is still to deceive.
Re: (Score:3)
This works because iMessages are stored on your device, and not the server. So when you change your password, and update your devices password's the iMessages will re-transmit their history to other devices. So no, not wrong.
If you pull all of your devices offline and reset them, and then take them back online, the history won't be available to sync so all your messages will be gone. Apple does manage delivery, but the initial handshake is done by a peer to peer key exchange, so while Apple is caching and f
Re: (Score:2)
So if you loose your phone, or it getsbroken you loose all your iMessages? I am not sure you might be right but doesn't that kind of defeat the purpose of the cloud.
Tim Cook Says:
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."
saying they are not held in "identifiable form." means they are held. therefore they are idenfiable since the apple user can identify them, since apple has the knowledge to identify them.
Re: (Score:2, Flamebait)
...but they can change the password for you.
so they can read the mail.
http://support.apple.com/kb/HT... [apple.com]
so how is it not total bullshit that is is spewing from his filthy mouth?
Re: (Score:2)
The questions are this:
1. If you get a new phone can you access your emails with that phone?
2. Can you reset your password?
If 1 is true clearly there is nothing on your phone that is needed access your emails.
If 2 is true and they use your password to encrypt your data:
They clearly can decrypt it without you providing the old password, and re-encrypt it.
else they decrypt it with some key stored on their sever so they can clearly decrypt it.
else don't encrypt it at all.
So either Tim Cook's technical knowledg
Re:Is this technically impossible - no. (Score:5, Informative)
For these people, with their resources, your "encryption", unless it's a one time pad, is no better than ROT13.
From the Snowdon leaks it looks like even the NSA cannot crack properly used strong encryption. That's why they try to harvest or weaken keys, try to get in before or after encryption, or use traffic (metadata) analysis.
Re:Is this technically impossible - no. (Score:5, Interesting)
I personally don't believe that the NSA can't crack strong encryption.
I'm not quite sure what you are saying. It sounds to me as if you think that there is no encryption strong enough that the NSA cannot crack it. This is completely false.
A simple example is using one time pad encryption. Without the pad, you you cannot even theoretically crack it. Try every possible pad, and you will get every possible message of the proper length - some of them will make perfect sense, so you will not be able to find the right one.
Taking it a bit further, there are encryptions that would take too long to crack, if they are properly executed, and the NSA does not have a backdoor. And by too long, I mean that there is not enough time before the heat death of the Universe.
Hell, I am perfectly sure that I could establish communication with some of my friends from college that could not be cracked, even theoretically. I would have to exchange some information with them in a secure manner before hand, of course. But I would never take the risk of doing something like this. It would attract the wrong kind of attention.
Re: (Score:2)
Re: (Score:2)
Anyone with a solid Computer Science background, extensive programming experience, and access to google can make something that is secure enough that it cannot be cracked in resonable time. It may be sluggish, it may be extremely inefficient, it will require a secure exchange of data at some point (before it is secure itself) and will draw a lot of attention when used. But it is perfectly possible. I certainly could do it.
Oh, of course, I would be infringing on a bunch of patents, but I bet it would be t
Re: (Score:2)
I think Bruce Schneier put it quite blunt "trust the math". There is a relative high degree of certainty that the math is solid. You may need to use different "magic numbers" then the specs, but apart from that the math should be solid.
The problem actually comes in the implementation and security protocol. Implementation of the crypto may be faulty. The key may could be intercepted when you are sharing it with the other party. The system the key is stored on is vulnerable to attack. Systems processing the d
Re: (Score:2)
Let's put it more simply. Aside from the one time pad, there is no publicly available encryption the NSA can't crack.
Although that might be the safest assumption to make, it is not at all clear that that is true. The standard algorithms and key sizes that are currently considered safe are certainly far too strong for brute-force attacks, even using massive and dedicated hardware, and they will remain so in the foreseeable future. It is always possible that there is a weakness in an algorithm, but there are no indications that there are, despite a lot of public scrutiny.
More directly: Edward Snowdon says that he trusts the
Re: (Score:2)
Obviously this is only going to work for very, very important and infrequent messages, as one could run out of keys quickly or have to worry about too many keys being found by the opposition and compromised, but for those applications it works just fine.
Re:Is this technically impossible - no. (Score:4, Interesting)
One time pads are not worthless in practice, at all.
Whether you are a criminal, or a government agent, at some point you will be in a secure location, and you will be able to exchange the pads. The USB stick in my pocket can hold more data than I expect to exchange with any of my friends in the course my lifetime. How long to you think encrypted messages need to be?
But even that is less secure than what you could do.
Hell, if I was writing a novel about smart criminals, and wanted them to be capable of secure communication, this is what I have them do:
They would meet in the big boss's hacienda, and they would agree to use one of the 50000 books available on project Gutenberg. The page to use as an one time pad would be selected via a function of the day the message is sent. The function would be simple enough to memorize.
When one of the party wants to send a message, they would take a picture they have a plausible reason to send, and would use a hex editor, on a PC physically disconnected from the Internet, to manually change a subset of low-significance color bits. Again, the subset will be determined by a rule that is easily memorized.
Yes, the process is laborious, and I would have them do it twice, and then compare the two resulting pictures. If they do not match, they will have to do it again. Once the pictures match, wipe (properly) the originals (from everywhere: camera, usb, secure computer) and send the modified picture, accompanied with an innocuous and appropriate message.
Obviously, the encrypted messages would need to be short, but this process will not attract any attention, and will rely on memorized rules, publicly available data, and programs that would not draw anyone's attention.
What is the NSA doing to do? Suspect anyone sending pictures to his friends? Try, as a one time pad, every page on every book available on Gutenberg, or the myriads of pirated book libraries in China, Russia, Ukraine, etc?
I cannot think of any weakness of this system. Can you? And even if it is completely stupid, I bet you two things: there are plenty of people who can come up with a better one, and plenty of people who are getting away with using a worse one.
Re: (Score:3)
You didn't say so, but I'm assuming you're encrypting your message using the book page as a one time pad, then obscuring it using steganography. If someone sufficiently motivated were after your criminals, they could break that. Steganography isn't much protection when someone knows there might be hidden messages. And your one time pad, while one time, isn't random. Book pages have quite a bit of structure.
Any structure in a one time pad makes it vulnerable. To the point where people have gone to great
Re: (Score:2)
Your system has too many vulnerabilities. The worst is its reliance on criminals to be loyal and diligent, any one of whom could compromise your entire organization's communication. Almost as bad is using a 2 byte encryption key (the index to a book). And then you want them doing steganography, and by hand? They'll be raising every red flag there is.
On the other hand, you could simply use private/public keys. Each person has their own set of keys, and the key itself is encrypted with a decent password.
Re: (Score:2)
You didn't say so, but I'm assuming you're encrypting your message using the book page as a one time pad,
Yes, I missed describing part of the mechanism. You use the page to generate the one time pad, once again via simple rules that you only keep in your head. You certainly do not use the ASCII code of each letter/space/punctuation sign as one byte in the pad. This will not make it anywhere close to random - it will be way worse than counting decay particles, but I think that it will be good enough. I a
Re: (Score:2)
What you're describing is a random number generator with a key to initialize it. Some of the good ones might be good enough (or might not). Anything you can keep in your head is going to be crap and fairly easily breakable. Either way, you're still better off to just exchange regular secret keys at your meeting, which can be concealed in a variety of ways. Even real one time pads can be fairly easily concealed - a "blank" USB key, for example.
Re: (Score:2)
What you're describing is a random number generator with a key to initialize it. Some of the good ones might be good enough (or might not). Anything you can keep in your head is going to be crap and fairly easily breakable.
Hell no. Using a not-all-that random-book page, and obfuscating its structure by applying a simple algorithm on will still give you an one time pad that is suboptimal, but nowhere all that breakable, especially if you do not know the simple algorithm, and that it is being applied on boo
Re: (Score:2)
the worst is its reliance on criminals to be loyal and diligent, any one of whom could compromise your entire organization's communication.
No argument there.
And then you want them doing steganography, and by hand? They'll be raising every red flag there is
How exactly is the e-mail with a picture going to raise any red flags? Sure, it they are already tailed everywhere they go, and someone is monitoring how long they spend composing their e-mails, they will be in trouble. But just from the sent e-mail, whe
Re: (Score:2)
One time pads have been, and probably are, used extensively. You send a bunch of random data to someone via some secure method, which is usually very slow (like hopping on an airplane with a DVD full of random numbers on your person). You can then exchange messages securely using a convenient and fast channel, such as e-mail. See the utility there?
Re: (Score:3)
Re: (Score:2)
Is he required to lie about this?
Yes, a National Security Letter may do so. We have no way of knowing, so have to assume the worst.
This will continue until there is independent oversight of the security apparatus. And by apparatus I mean all three branches of government.
Re: (Score:2)
A National Security Letter means the recipient must hand over information without notifying anybody else about it. It can probably force somebody to lie if they're using a "canary" approach (such as a message on accessing mail that it's definitely not going to the authorities). I don't see that it can force lying under any other circumstances.
Re: (Score:2)
Yes, a National Security Letter may do so. We have no way of knowing, so have to assume the worst.
You are wrong. There is no way to legally force Tim Cook to lie. There are ways to legally force him to be quiet about a subject, and not to give us information, but there is nothing that can force him to lie.
Re: (Score:2)
Of course they can read it. They may not make a habit of it, but they do have the capability. If they didn't they would be worthless.
Re: (Score:3)
Lie. (Score:2, Insightful)
Since when is anyone's SMTP email secure in transit, when is anyone running a mailserver unable to read the mail?
Since when is any company immune from subpoena or contempt of court?
Re:Lie. (Score:5, Informative)
...because that's not what he actually said. He has previously stated that iMessage and Facetime, by design, can't be intercepted (it's all encrypted client-side); in this new interview he stated that they don't read your email, and that as a general principle they try to design systems so that they can't capture data, or at the very least aren't capturing anything they don't need to do what they're supposed to be doing.
Re:Lie. (Score:4, Insightful)
Look, where would ./ be if posters read TFA?
Looks to me like the ./ summary is claiming something that the ZDNet article does not. So yeah, not a lie on Cook's part, or not one the ZDNet article demonstrates anyway.
I still wouldn't trust any company not to hand over my information to the government. Lavabit was one hell of an exception, and one geeks the world over should be proud of.
Neither would I trust that email content I didn't personally encrypt with my own keys couldn't be seen by others.
Apple doesn't have to be relaying email for others in order for Apple to be able to see the contents of all SMTP traffic that transits or terminates at their mail servers. SSL for SMTP means nothing if the mail server is pwned or intentionally logging stuff due to a business mandate or government subpoena or pressure.
So Tim Cook didn't tell that particular lie. Good. But "We don't read your email" is an assertion, and one generally impossible to prove true (though more easily possible to prove false, given a certain amount of evidence).
Re: (Score:3, Insightful)
I still wouldn't trust any company not to hand over my information to the government. Lavabit was one hell of an exception, and one geeks the world over should be proud of.
But then Lavabit made the big mistake of being _capable_ of decrypting your data. Once they were _capable_ of decrypting it, that was it, and they started a fight with the government that they couldn't win.
With Apple's iMessage system, they _can't_ read your data. And since they _can't_ read your data, Tim Cook can refuse to give them your data (actually, he can't give them your data anyway because he just can't) without fear of having to go to jail for this refusal. So no heroics needed for Apple. Much
Re: (Score:2)
Re: (Score:3)
If Apple can reset your password and your imessages can still be recovered, they can read them.
Re: (Score:2)
It is this. EMAIL IS NOT SECURE. No matter who starts it or finishes it.
If you are using email to do anything but send words of affection to your legally bound, opposite sex, partner (or recipes to anyone), you're doing it wrong.
Remember the bit about email being a postcard?
Re: (Score:2)
It is this. EMAIL IS NOT SECURE. No matter who starts it or finishes it.
Well, exactly. If you send me an unencrypted email, and it is stored on Apple's servers somehow, and my computer asks Apple's email server for the mail, then Apple has to send the unencrypted email to my computer. In other words, Apple _must_ be able to produce the unencrypted email.
(Hmmh. I wonder if this is right. I wonder if there would be a way with https to store an encrypted mail, which would be decrypted when my computer decrypts the https? But then the NSA could just request my email through http
Re: (Score:2)
I wonder if there would be a way with https to store an encrypted mail
Short answer: No.
Long answer: SSL makes use of a temporary session key that is calculated between the client and the server at the time of the connection. Once the connection is over that key is (ideally) destroyed. If the email was encrypted with my session key when I sent it to the server (and somehow not decrypted by the server at this point) your session key that you create when you connect to the server won't do the job.
This is wha
Re: (Score:2)
Re: (Score:2)
better than that the system allows for password reset by using email(among other methods). so with the data they posses, they can generate access to all the data. that means that any encryption or access blocks or whatever there are, are meaningless from the logical point of "can they read it?"
so they can reset the password without having anything from you - that means they can read everything is in there and can be coerced to do so by legal means.
on some other site it might be worth mentioning that they do
Re: (Score:2)
You can secure SMTP with TLS, can't you?
Re: (Score:2)
I have not tracked the value over time to see if it is going up/down. And our site is not particularly large, so we don't have a good sample to pull from.
Re: (Score:3)
Apple doesn't run public email servers. At least, I don't think so. Nothing like gmail, anyway. So they aren't transporting your email. Unless they back up your mailbox to iCloud
Yeah, they do run public email servers if you've opted in. Was user@mac.com, then user@me.com, and now user@icloud.com. Just using a device, no, your mail doesn't go to an Apple server unless it's one of their accounts.
Re:Not really a lie (Score:4, Informative)
iCloud.com addresses are required for most of iCloud's services. Without iCloud loses a lot of functionality.
Guess what I don't have
Not true, you can register with iCloud with another email address, however it will then automatically allocate an iCloud.com address for you, but you don't have to use it nor does it limit the functionality. (This is what I do...)
Re:Lie. (Score:5, Informative)
Whoops (Score:2, Insightful)
The partial quote distorts what he said. The "Apple cannot read" part is specifically about iMessage, not email.
Not Hacked? (Score:2, Informative)
Re: (Score:3)
Right, it's not iCloud that was hacked, it was individual user accounts. It's the distinction between "the rotary club has been murdered" and "the members of the rotary club have been murdered".
Re:Not Hacked? (Score:5, Insightful)
Actually, it's more the distinction between "they broke into the bank vault and went through your safety deposit box" and "they pickpocketed you, and used your key and a fake ID to get into your safety deposit box."
Re: (Score:2)
Right, it's not iCloud that was hacked, it was individual user accounts. It's the distinction between "the rotary club has been murdered" and "the members of the rotary club have been murdered".
No, some members of the rotary club have been murdered. (And also some members of the local droid knitting club.)
There is no indication that every iCloud account was hacked, or even that a disproportional number of iCloud accounts were hacked.
Re: (Score:3, Insightful)
It's why you can't sentence a corporation to death...
Ah, but you can. Its charter can be revoked, should we ever vote for people who would do such a thing, but that's not very likely.
Re: (Score:2)
In reality, the next step up on Internet services is moving to 2FA everywhere. Passwords are easily gotten, but 2FA, though doable, raises the barrier immensely. It means that someone would have to know the user's password and have control of one of their devices. This is far harder than just sifting through a pile of passwords found on a bittorrent dump and trying them on various accounts, or guessing a user's grandma's last name.
I'm sure that if the users that had the pictured compromised had their pho
Poor Apple (Score:5, Interesting)
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.
Re: (Score:2)
Call me gullible if you wish (given the PRISM leak it'd be fair) but I do actually relatively trust them, and believe that they were probably just as horrified to discover that the NSA had manipulated whoever they managed to manipulate (some engineers most likely) and tightened things up accordingly.
There's always this idea that the more successful a company is, the more Pure Evil they are and basically out to be as scummy as they possibly can. But short of the PRISM thing (which again I personally suspect
Re: (Score:2)
Sigh. This has to go down as one of the most commonly manipulated misquotes in history.
Schmidt was saying something along the lines of "privacy is dead" in response to a question about the PATRIOT Act. He was telling it like it is, giving as much of a warning of what was going on as he could without actually doing a Snowden. He wasn't expressing happyness about that state of affairs, just pointi
Re: (Score:2)
I'll use what I want to, thank you.
Similarly, whether you choose sides (or choose a tinfoil hat and avoid cloud services altogether) is up to you. That's how the world works you see, people make personal decisions, they don't usually take orders off people on the internet.
3 years ago I liked what Google were doing and disliked what Apple were doing so I switched to Google
Now, vice versa.
There's no brand loyalty here, but these happen to be the two biggest mobile OS manufacturers (sorry but Blackberry and M
Re: (Score:2)
The part that gets me is that Apple thinks that it's a Google or Apple choice. That by tearing down Google they can raise themselves up.
I choose neither.
But Apple has historically promoted the idea of a competitor to their fandom. They utilize an 'Immanual Goldstein is the enemy' model, with regular five minute hate sessions.
I don't think they can maintain their marketing culture without something out there for their fans to feel superior to.
But we can stop caring. We don't have to pick a flag to wave in
Comment removed (Score:4, Interesting)
Re: (Score:3)
The fact You refer to "4chan" as a "notorious hacker" shows Your interpretation should be presumed erroneous.
And your reading of his message is erroneous, because it was reported in the media that the notorious hacker was indeed "4chan."
--
BMO
I do not believe him. (Score:2, Troll)
iAD http://advertising.apple.com/ since iOS4 (Score:5, Informative)
"With iAD you can get your message out to millions of people worldwide who use Apple products every day. Connect with users as they listen to music on iTunes Radio or while they use their favourite App Network. Find your audience using targeted tools built upon a foundation of registration and media consumption datahttp://www.youtube.com/watch?v... start at 44 Min The idea is you spy on people in Apps not in search, because people spens 97% of their time in apps
I realize Tim Cook is now the face of Apple (Score:2)
And Charlie Rose isn't a techie. But if you want to really convince the Slashdot audience, it'd be better to have a high-level engineer answering these questions than a guy who's skill is managing the inventory supply chain.
Re: (Score:2)
The old Jackie Mason routine (Score:4, Insightful)
Reagan was happy, he was always smiling
They asked him, "what about the defiicit?"
He said, "there is no deficit!"
They told him, "but there is!"
So he said, "so there is."
...
30 years later
There is is no emal theft! But there is!.... waaaait for it.
Apple Angels (Score:2)
False Headline (Score:5, Insightful)
Tim Cook Says Apple Can't Read Users' Emails,
No he didn't.
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."
He said they cannot read iMessage and FaceTime, and they are not reading your email. That is a very important distinction. It might be one he was hoping you would miss, and you did miss it, but he did not say they can't access your email.
And I'm not blowing sunshine up his skirt. I came here intending to kick him in the balls (metaphorically, of course) for lying, but he didn't.
Pro-tip: If any system includes a password recovery mechanism that allows you to get back messages, then the administrator of the password recovery system can read your back messages.
Re: (Score:3)
It makes sense really because he'd be lying if he said he can't access your email.
Because using me.com or icloud.com email? Well damn, that's standard email and I'm fairly certain even if Apple uses SSL, it's standard IMAP or POP protocols, and it's delivered to Apple in pl
Re: (Score:3)
iMessage and FaceTime are technologies Apple designed and implemented, and they chose to do it in a different way than e-mail. E-mail uses a plain text protocol and is stored in plain text. While the transport can be encrypted, if one were to encrypt the data on the server it was stored on, one would use a symmetric key, and one would have access to that key. iMessage and FaceTime can be implemented using asymmetric keys and one would not need access to those keys. It makes sense if you as a company want to
Subject & summary disagree (Score:4, Interesting)
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... [quarkslab.com]
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.
Re: (Score:2)
You’re thinking Web of Trust type public key architecture like PGP/GPG tend to use. That’s a good model among people who know each other well and trust each other (as well as trust each other’s ability to verify keys properly), but it doesn’t scale all that well. It also requires users to do much more work to distribute and verify keys.
iMessage uses a certificate authority model. You delegate all trust to the third party authority (Apple in this case) who you trust to do the work
Possible to store encrypted email? (Score:2)
Let's say my email address is gnasher@icloud.com and my password is "Password" You are sending me an unencrypted email (no S/MIME) and it is received by Apple's email server. No matter how encrypted Apple stores the data, when I request my email, Apple has to send me the unencrypted
Re: (Score:2)
Even better would be a system such as:
You generate a key pair, give Apple the public key. You manage your own private key.
Then, for each email:
Apple receives the email as plain text from another server (likely via SSL), encrypts it with your public key and stores it on their servers. When you connect to retrieve your mail they send you the encrypted blob that you decrypt via your private key.
Problems are this: first, Apple has a plain text copy of each email you receive and could be asked (nicely or forcefu
Re: (Score:2)
The sender could ask Apple for your public key. If Apple has your public key, it gives the public key to the sender, the sender encrypts the message with your public key, sends it to Apple who cannot read it, which sends it to you. Oh well, that's called S/Mime
Re: (Score:2)
Yes, but it's between your MUA and your server. S/MIME, as far as I know, does not do server-to-sender public key exchange. If I send a signed message to you, then you have my public key and can encrypt messages to me, yes, but you can't get my public key from the server.
Frankly, S/MIME is really the best solution available today. It works with gmail (not web-mail but using a MUA). Most MUAs support it. It's easy to get a free personal S/MIME keypair from a CA. Google, Apple or whoever you use for mail neve
Re: (Score:2)
This is essentially what Lavabit implemented. The NSA’s response was to compel Lavabit to hand over their SSL private keys so that all traffic to & from their web server could be intercepted. The key material that protects the private key must at some point pass over the wire, and if you can decrypt all traffic in & out, you can compromise the system.
Lavabit chose to go out of business rather than comply.
Land of the Free indeed...
Laugh... (Score:2)
http://www.wired.com/2014/09/e... [wired.com]
What's not said... (Score:2)
Oh boy (Score:2)
Think just for a second about how web email works, especially web e-mail that provides fast full content search. Or SMTP from outside systems. Can't read user's e-mail. Riiiight! Maybe with all open source client stack using public keys exchanged out of band.
Re:If true thats great (Score:5, Funny)
Yeah I can't wait until he starts saying:
"Bono and the Edge totally pulled a fast one on us. Apple has no way of automatically installing horrible music on your devices with your permission."
Re: (Score:2)
Apple has no way of automatically installing music on your devices with your permission.
That is a 100% correct statement. If you haven't turned on automatically download music purchases (i.e. permission), nothing installed on anyone device.
Apparently there were a vocal group of folks having a hissy fit at suddenly finding a U2 album on their iPods after the last keynote.
Re: (Score:2)
Free music is the worst thing EVAR!
Re:If true thats great (Score:4, Funny)
Re: (Score:3, Insightful)
If it were true, the U.S. government would have already come after them full force. No one tells the U.S. government "No" without serious consequences. Just ask Yahoo [npr.org].
Re: (Score:2)
If Apple, Microsoft, Google, Yahoo, Facebook, Twitter, Cisco, Intel and AT&T stood together and told the US government to fuck off (as they are obliged to to), I think the shoe would be on the other foot.
Re: (Score:2)
Sure of it, believe I am.
Re:What infamous PPT? (Score:4, Informative)
The PRISM PowerPoint slides [washingtonpost.com] leaked by Snowden.
Re: (Score:2)
Tim Cook says they "don't" read your email and "can't" read your iMessages. So presumably, they CAN read emails but choose not to do so.
Which makes sense as most email clients out in the wild don't encrypt messages, so even if Apple were to encrypt messages stored on the server, they'd be doing it with *their* key, not the users (unless the user used S/MIME or PGP or GPG or what have you). If they want to interoperate with other email providers, they need access to the emails as that's how email works.
Re: (Score:2)
Whilst you do sound like a channer (no offence - Anonymous is what they call themselves, and your writing style reminds me of one I know, but they do sometimes pretend to "know things") I wish I could mod you up as this is exactly what I'm suspecting as well. I really don't think the corporations are necessarily all Evil Devils out to collude with the NSA and do all sorts of nasty things with the data of individuals.
They're successful financially but surely this doesn't automatically mean they have no cons