Apple’s claim of unbreakable iMessage encryption ‘basically lies,’ researchers say

By
With
Comments Off on Apple’s claim of unbreakable iMessage encryption ‘basically lies,’ researchers say

A famed iPhone jailbreak software developer says Apple could easily decrypt iMessages despite the company’s claims

A close look at Apple’s iMessage system shows the company could easily intercept communications on the service despite its assurances to the contrary, researchers claimed Thursday at a security conference.

Apple asserted in June, following disclosures about the NSA’s data collection programs, that iMessage, which lets users send texts over Wi-Fi for free, is protected by end-to-end encryption that makes it impossible for Apple or anyone else to descramble the messages.

But researchers at the Hack in the Box conference in Kuala Lumpur showed it would be possible for someone inside Apple, of their own volition or because they were forced to by a government, to intercept messages.

The company’s claim that iMessage is protected by unbreakable encryption is “just basically lies,” said Cyril Cattiaux, who has developed iOS jailbreak software and works for Quarkslab, a penetration testing and reverse engineering company in Paris.

The researchers emphasized they have no indication that Apple or the government is reading iMessages, only that it would be possible to do so.

Asked to comment, Apple didn’t directly address the claims about iMessage and pointed instead to a statement it issued in June after the disclosures about the NSA’s Prism data collection program.

The statement says in part that Apple first heard about Prism only when it was asked about it by news organizations. “We do not provide any government agency with direct access to our servers, and any government agency requesting customer content must get a court order,” the statement says.

One document revealed by former NSA contractor Edward Snowden indicated Apple became part of Prism in October 2012.

Apple uses public key cryptography to encrypt iMessages between the sender and the recipient. But its system for managing public keys is opaque, the researchers said, making it impossible to know if iMessages are being sent to a third party such as the NSA.

When someone sends an iMessage, the iOS device pulls the recipient’s public key from Apple’s non-public key server to create the ciphertext, or encrypted message. The iMessage is decrypted by the recipient using their private key.

The problem is “Apple has full control over this public key directory,” Cattiaux said.

Trust has always been an issue with public keys. To send an encrypted message, the sender frequently has to trust that the key listed on the key server used to relay the message actually belongs to the recipient.

With a public server, such as MIT’s PGP Public Key Server, the sender can at least see more information, such as whether a key has changed. At that point, the sender can decide whether they want to trust it or not if they suspect a man in the middle attack. Apple’s key server is not public, the researchers say.

“The biggest problem here is you just cannot control that the public key you are using when you are ciphering the message is really the key of your recipient and not, for example, the public key of some guy in Apple,” Cattiaux said.

Cattiaux’s fellow researcher, who goes by the name GG, added that: “In Apple’s case, it’s that they give the key and nobody can really know if it’s a substitute or anything like that. In fact, it’s a matter of trust. It’s a real problem for users.”

People generally can’t assess or control of the risks of cloud-based services since the data is maintained on systems that can’t be audited, said Paul Kocher, president and chief scientist of Cryptography Research.

“In practice, iMessage is only as secure as Apple chooses to make it, but it isn’t fair to criticize Apple too heavily since other services aren’t better (and most are worse),” Kocher said via email.

iMessage’s cryptograpy itself is solid, but it’s been clear that Apple controlled the distribution of public keys, wrote Matthew D. Green, an assistant research professor in the Department of Computer Science at Johns Hopkins University, in an email.

“They’ve insisted to their customers that messages were encrypted ‘end to end’ and that they couldn’t read the messages,” Green wrote. “This is all technically true, but at the same time they know perfectly well that this could change easily if they wanted to misbehave. They just chose to be misleading.”

Cattiaux said there’s also no way to detect man-in-the-middle attacks by analyzing an iOS device. iOS does not store the public keys it uses for iMessage, so it’s impossible to see if a key has suddenly been switched and, ultimately, where the iMessage is routed.

Cryptography expert Moxie Marlinspike, who was not involved in the research, said another attack scenario is possible. More than one Apple device can be linked to an iMessage account. So a device that is sending a message grabs several public keys in order to copy the message across the user’s iPhone and iPad, for example.

“This makes interception on Apple’s behalf even easier, since they don’t technically need to perform a strict ‘man in the middle’ attack,” Marlinspike said via email. “They can just add their own key to the list, and the sender will encrypt a copy directly to Apple in addition to the copy that gets sent normally.”

A solution for Apple would be to store public keys locally in a protected database within iOS, as then the keys could be compared, Cattiaux said. As part of their presentation, the researchers released an application, “MITM Protect,” for jailbroken devices that allows for such a comparison.

Trusting someone to manage keys on your behalf is no more secure than trusting them with plain, unencrypted text, Marlinspike said. “iMessage isn’t really ‘end-to-end’ encryption in the sense that phrase intends to convey.”


MCTS Training, MCITP Trainnig
Best comptia A+ Training, Comptia A+ Certification at Certkingdom.com

 

 

Click to rate this post!
[Total: 0 Average: 0]