
Contrary to public claims, Apple can read your iMessages - shawndumas
http://arstechnica.com/security/2013/10/contrary-to-public-claims-apple-can-read-your-imessages/
======
mcherm
This seems a bit disingenuous to me. If I understand it correctly, they are
saying that the messages are encrypted using an RSA key unique to the sender,
and that this is not secure because Apple could, if they wanted to or were
ordered to, replace the certificates with ones that were not secret:

> Since Apple controls the entire infrastructure, there's nothing preventing
> company employees from swapping out the proper keys with ones controlled by
> Apple or other parties.

What is misleading here is that (if I understand it correctly) the
cryptography is solid, it is the implementation being owned by Apple that
raises the doubt. But this is NOT a statement about the cryptography used on
the iMessages, it is a statement about the fact that Apple effectively has
"root access" to their phones.

Imagine that you had a PERFECT and UNBREAKABLE code system. Perhaps it
interfaces with angles who alter the laws of the universe to prevent anyone
but the intended recipient from reading the messages. Such a system would
still have the same vulnerability. All Apple needs to do is to alter the phone
so that when you click on the icon to launch this perfectly secure messaging
app it instead launches one that has the same UI but which actually sends a
duplicate to the NSA (or whoever it is you don't want listening in).

ANY system where code can be deployed at will and the owner of the device is
not in full control of the device will have this same level of vulnerability.
Saying that a system is insecure because you could change the system doesn't
tell you anything interesting about the system.

~~~
mapgrep
>(if I understand it correctly) the cryptography is solid

The issue is that iMessage outright ignores a long understood challenge in the
APPLICATION of cryptography, namely knowing when to trust that someone is
REALLY giving you their public key rather than being man-in-the-middled.

While this is a thorny challenge there are well understood, if imperfect, ways
of addressing it that have been around for decades. At minimum it works like
ssh, where you get a warning when an unfamiliar new key is presented and
decide whether to trust it or not. More sophisticated is the certificate
infrastructure around TLS/SSL where some effort is made to bring semi-trusted
third parties into play.

These are all flawed solutions, the problem remains essentially unsolved. But
any truly secure system based around public keys has some mechanism that
addresses this challenge.

The issue with iMessage is that 1. Apple did not attempt to address the key
exchange problem, which would maybe be fair enough on an "easy" consumer
product with weak security claims but then 2. Apple made strong security
claims very publicly and 3. even said a counterfactual, that it had no
capability to intercept messages.

THAT is what is disingenuous: Apple implements public key cryptography, which
since its inception and at its very heart raises difficult challenges around
key exchange; Apple chooses to ignore these challenges; Apple then claims
strong public key security. Either attempt to address the challenges like
everyone else, or don't make the security claim, you can't do both.

~~~
Spooky23
I disagree.

The flawed systems are SMS and predecessor systems like alphanumeric pagers,
where your messages are archived indefinitely in a database by the carrier.
Remember the Wikileaks release of all of the pager traffic in lower Manhattan
on 9/11?

In my mind, the NSA/PRISM stuff is a meta-problem that is just something that
is hanging out in the background. I work in enterprise IT, I'm not a
dissident, drug dealer or whistleblower, so I'm more worried about incompetent
carriers and other hostile parties than the NSA.

So iMessage gives me encrypted message content that may be readable
retrospectively by the NSA, and is almost certainly "tappable" by normal law
enforcement.

The reality is, that's about as good as you are going to get outside of a
defined community of interest. My employer has highly secure voice and text
solutions available for key personnel, for instance. Perfectly secure
communications won't be available to the masses, because the operators of
those systems face liability.

~~~
bloopletech
Whats the liability difference between the systems at work and the systems for
the general public?

Strong crypto is, and should be, available to everyone.

~~~
Spooky23
The law.

Common carriers are required to to have "tappable" systems if the system is
deemed to replace phone conversations.

------
StavrosK
This says that, yes, Apple can read your iMessages, but it seems to me that
the protocol is pretty much designed to be as secure as one can make it while
still being usable. Would you really expect people who used iMessage to call
their friends and have them read hex fingerprints over the phone?

As anti-Apple as I am, I think we have to give them this one, especially when
the alternative (i.e. making iMessage _completely unencrypted_ ) would have
been much, much easier.

~~~
GrinningFool
Well - to be fair, BBM over BES is as secure as it gets. The only people who
can read those messages are sender and recipient, and the owner of the org
keys. Neither cell provider nor blackberry can decrypt them.

~~~
privong
I think it's established that there are backdoors in BBM. E.g.,
[http://www.zdnet.com/in/indias-blackberry-monitoring-
system-...](http://www.zdnet.com/in/indias-blackberry-monitoring-system-ready-
for-use-7000017937/)

------
kemayo
This reads more like "Apple can't read your messages as-is, but controls all
the iMessage key-exchange infrastructure, and thus could sabotage it if it
chose to".

------
stellar678
So if I get this right, the vulnerability is that Apple could sit in between
you and your friend, impersonating each to the other while relaying and
reading your messages.

This seems about as vulnerable as the certificate authority/public key
infrastructure system used for SSL, code signing, etc... We're always
delegating to another party the responsibility of authenticating the person on
the other side of our messages/web browser/signed software that we run. In the
case of iMessage, Apple is responsible for authenticating your friend. In the
SSL or signed code case, the certificate authorities are responsible. Seems
that both Apple and CA companies might be subject to the same legal pressures
to eavesdrop on people.

~~~
fsckin
Not quite. A CA signs your _public_ key. You never give anyone the private
key, because... well, it's private.

~~~
agwa
You're not giving anyone your private key here, either.

stellar678 is basically correct - Apple, like a CA, is vouching for the
authenticity of users' public keys. The only difference is superficial: a SSL
CA signs a certificate and the validation is done without needing to contact
the CA, whereas with iChat the public key is validated by virtue of coming
from Apple. Just as a CA can sign a malicious certificate, Apple can send you
a malicious public key.

~~~
fsckin
Except in the iMessage scenario, Apple generates (and keeps) a copy of the
private key so you can recover a lost device by signing into iCloud on a new
phone.

~~~
agwa
That's not what these researchers found. They found that each device has a
distinct private key, and that the sender of an IM actually sends a separate
message to each device, encrypted with the appropriate key. Do you have a
source for your claim?

~~~
mikehotel
_While Apple boasts of "end-to-end encryption" it's pretty clear that Apple
itself holds the key -- because if you boot up a brand new iOS device, you
automatically get access to your old messages. That means that (a) Apple is
storing those messages in the cloud and (b) it can decrypt them if it needs
to._ From [http://www.techdirt.com/articles/20130405/01485922590/dea-
ac...](http://www.techdirt.com/articles/20130405/01485922590/dea-accused-
leaking-misleading-info-falsely-implying-that-it-cant-read-apple-
imessages.shtml)

------
Steko
_Since Apple controls the entire infrastructure, there 's nothing preventing
company employees from swapping out the proper keys with ones controlled by
Apple or other parties._

Well internal controls could prevent that but since we don't know we'll assume
they don't exist, print the headline:

 _Tim Cook is reading your iMessages right now!_

~~~
mcherm
Well, being prevented by internal controls is outside the scope of the
question. Apple had claimed that they were incapable of intercepting the
messages, not that they had policies against it. And Apple is known to be
subject to secret US government demands that come with a gag order.

~~~
mattdmrs
What we know is that it seems possible, when looking at the system externally,
for them to perform MITM attacks. What we don't know is if their system
_internally_ makes it possible for anyone inside apple to intercept and read
those messages, with or without an order from the NSA. They could very well
have told us the truth!

~~~
mcherm
No, what we know is that it seems impossible for them to perform MITM attacks
at the moment, but they appear to have the ability to rewrite the app later if
they wanted to perform MITM attacks. At least that's how I understood it.

------
anfedorov
_[The researchers] went on to say there 's no technical measure stopping Apple
employees, working under a secret court order or otherwise, from performing
the same kind of attack and making it completely transparent to the parties
exchanging iMessages._

 _Since Apple controls the entire infrastructure, there 's nothing preventing
company employees from swapping out the proper keys with ones controlled by
Apple or other parties._

We have evidence of a secret court order for Verizon to hand over the meta-
data associated with phone calls. IANAL, but this seems quite different from
ordering Apple to perform a MITM attack against a user.

Under what kind of court order would Apple have to remove or compromise end-
to-end encryption from a target's device?

~~~
ChuckMcM
The same kind of court order that told Lavabit to hand over their SSL key, one
where the person of interest was communicating over iMessage. It would
probably be accompanied by an NSL which would then prevent Apple from talking
about it.

~~~
anfedorov
AFAIK, the Lavabit case is not legally decided yet:

    
    
      http://www.volokh.com/2013/10/11/lavabit-challenges-contempt-order/
    

I imagine Apple would put up quite a strong legal fight if they were issued
the same order, especially considering their public stance.

A NSL can force Apple to not disclose it, but they can't force them to
publically lie about it. And lying about that would be ridiculously stupid.

~~~
privong
> A NSL can force Apple to not disclose it, but they can't force them to
> publically lie about it. And lying about that would be ridiculously stupid.

I'm not sure they'd be put in a position to lie. It would have to be a very
direct, specific question to _require_ a lie. Otherwise, dodgy language would
suffice.

~~~
anfedorov
They didn't use dodgy language: "conversations which take place over iMessage
and FaceTime are protected by end-to-end encryption so no one but the sender
and receiver can see or read them. Apple cannot decrypt that data." [1].

1\. [https://www.apple.com/apples-commitment-to-customer-
privacy/](https://www.apple.com/apples-commitment-to-customer-privacy/)

~~~
ChuckMcM
And per the article, that statement can be true at the same time this
statement can be true:

"Apple can intercept the creation of _new_ conversations between users on
iMessage or FaceTime if compelled to do so by a valid court order."

English being as fungible as it is, leads to this sort of mess.

------
pa5tabear
Does that mean they can view private pictures sent via iMessage?

I've wondered the same thing about Dropbox. If I were to open my dropbox at
work, could my employer view private things in the dropbox? Even if I don't
open the file, an icon will still load in the browser view.

~~~
roywiggins
Your employer could MITM all your SSL connections just by installing their own
cert installed on the machine, so yeah.

~~~
fpgeek
Indeed. This is why Apple sending your AppleID and password in the clear
inside the SSL connection to Apple is troubling. That makes it relatively easy
for the right IT people to steal those credentials. Hopefully this will be
fixed soon.

------
_Simon
Article's author is Dan Goodin. I'd take _everything_ he says with a quarry
full of salt. This guy is symptomatic of all that is wrong with Ars these
days.

------
coldcode
Is there any commercially viable messaging protocol that is 100% defensible
against any and all attacks?

~~~
leeoniya
i dont see how something like this could conceivably work for 2 parties that
do not yet know each other. the problem of establishing identity/trust between
strangers can't be solved in any 100% manner over any medium that can be
tampered with.

if both of you rely on some intermediate authority for authentication (as
HTTPS works), it's by definition not 100% because the intermediary can, in
theory, be compromised.

if the two parties know each other and can authenticate via some basic
questions, that may work. or you can just exchange symmetric AES keys in
person or public certs through another channel.

~~~
eknkc
How about physical trust creation protocol? Something like bumping phones to
create key pairs and exchanging them via bluetooth. That might work fine in
theory.

------
WaterSponge
Did anyone ever figure out how the iMessage for Android developer got his
implementation to work?...

~~~
tuananh
saurik said this on Twitter[1]

> A 3rd-party iMessage app was just released on Android; I believe all data
> sent from/to Apple is resent to/from China for processing: beware.

[1][https://twitter.com/saurik/status/382387551144652800](https://twitter.com/saurik/status/382387551144652800)

------
nick32m
I don't mind apple is able to it... as long as not the chinese government ..

~~~
tonyplee
Most likely, the chinese government can/does tell Apple to decrypt certain msg
or don't do biz in China, similar to what India government told RIM.

