Researchers Show Apple Can Read iMessages 124
Trailrunner7 writes "The Apple iMessage protocol has been shrouded in secrecy for years now, but a pair of security researchers have reverse-engineered the protocol [original analysis] and found that Apple controls the encryption key infrastructure for the system and therefore has the ability to read users' text messages–or decrypt them and hand them over at the order of a government agency. ... The researchers found that while that basic framework makes sense from a security point of view, there are a number of issues with the iMessage system. One major issue is that Apple itself controls the encryption key infrastructure use for iMessage, and has the keys for each individual user. The upshot of this is that Apple has the ability to read users' messages if it so chooses. The researchers who looked at iMessage, known as Pod2g and GG, said that there is no evidence that Apple is in fact reading users' iMessages, but it's possible that the company could. Users' AppleID passwords also are sent in clear text to the Apple servers."
Re:Terrible summary (Score:3, Informative)
The article only mentions the username going in clear.
Upshot? (Score:3, Informative)
"The upshot of this is that Apple has the ability to read users' messages if it so chooses."
I do not think upshot means what you think it means.
Re:Terrible summary (Score:5, Informative)
Also, the password isn't sent over the wire in cleartext; it's sent as cleartext *inside of the SSL stream*. As in: you need to defeat SSL to read it as a man in the middle. SSH does the same thing.
Re:Terrible summary (Score:5, Informative)
Second surprise was actually bigger: we saw our AppleID and password going through this SSL communication. Yes, the clear text password... There can be a lot of good reason to send the password as cleartext, ssh does it for instance. But here, we dont see any reason for Apple to get our password.
....
Firstly, it means that Apple can replay our password using for instance our email also on many websites. Ok, Apple has no reason to do so. But what of intelligence agencies? Secondly, it also means that anyone capable of adding a certificate and able to proxify the communications can get user's AppleID and password, thus get access to iCloud accounts, backups, buy apps,
Re:Terrible summary (Score:5, Informative)
The username and password are sent in clear text in the SSL tunnel. So no, people at Starbucks won't get your username and password.
What this suggests is that iMessage should only be sending a hash of the username and password to Apple Servers without ever sending those things even within a SSL tunnel.
Re:Terrible summary (Score:0, Informative)
NSA Collects Data Directly From Servers Of Google, Apple, Microsoft, Facebook And More [techcrunch.com]
Apple iOS 7 Update Gives Law Enforcement Unlimited Access To User’s Personal Data [nationalreport.net](NSA is specifically mention in the article.)
Apple admits, ‘iPhone 5s Fingerprint Database To Be Shared With NSA’ [hackersnewsbulletin.com]
Apparently Apple has officially admitted it after the NSA leaks.
Considering what has been revealed, shouldn't you think twice before calling someone paranoid or a tin-foil hat?
Seriously, either you have lived in a closet the last months or you are a government goon spreading FUD.
Re: Terrible summary (Score:1, Informative)
I have plenty of evidence. And this topic really isn't anything new. Apple have woeful security practices that broadcast their own customers private data while using no encryption whatsoever. You need to research a little more instead of being a tool.
Re:Terrible summary (Score:2, Informative)
Apple admits, ‘iPhone 5s Fingerprint Database To Be Shared With NSA [hackersnewsbulletin.com]
What kind of braindead moron actually believes an Apple exec said this? And then, wait, is that a little update notice way at the bottom of the page?
Uh huh. And the second link the parent gave is also from this parody site. Nobody, ACs especially, should be modded informative for posting lies or parody as fact.
Re:Terrible summary (Score:3, Informative)
Apple admits, âiPhone 5s Fingerprint Database To Be Shared With NSAâ(TM)
Um, no.
http://www.theguardian.com/technology/2013/sep/27/no-nsa-iphone-5s-fingerprint-apple [theguardian.com]
Important quote, in case you decide to not read the linked article:
Reality check: the article claiming this comes from a right-wing "satire" site. Why are people confused? Because the satire's badly executed.
And, before you don your tinfoil hat in an attempt to refute this information, please try to remember that my source is The Guardian - you know, the source of the Snowden information.
So, yeah - please do think twice before spouting off moronic stupidity.
To add some more information about the protocol (Score:5, Informative)
The system appears secure; hacking it requires injecting your own certificate into the trusted roots on the device.
Further, forging messages requires you compromise the private key which is only contained on the device (Apple doesn't know it). The public key is submitted to Apple's push CA which generates a certificate. The public part of your key is what other devices see when they get a copy of your certificate. So far, so good.
The issue is, of course, that Apple controls the CA so in theory if the government ordered them to issue a certificate in your name to the government, the gov could then monitor your communications or forge your identity.
Apple claims not to be able to read iMessages and that appears to be true, and as far as I'm aware not even the Patriot act requires them to issue forged certificates (aka allow the government to impersonate you digitally). So insofar as the law works and is followed, there is no legal authority to compel Apple to issue bunk certificates.
For the curious, when you send a message it contacts Apple and requests the list of public certs for a given URI (telephone number, email address, etc). Apple responds with a list of the public certs issued to each of your registered devices, which the client then uses to send messages encrypted with that public key to each, and also signed with your own private key. The receiver does a similar lookup and uses your public key to validate the signature (proving you sent the message and that it was sent from the correct device even), then uses its own private key to decrypt the message you encrypted with the public key.
I'm not sure how this could be improved. No matter what you do, someone has to be in charge of saying "The certificate for mobile number xxx-yyy-zzzz is ..." and that gives you a chain of trust problem. The alternative is requiring every iMessage user to meet face-to-face to exchange keys before sending any messages.