While Apple may encrypt the contents of your communication, their statement doesn’t exactly rule out the possibility they store who you’re talking to. Armed with that knowledge they can make up their minds how much they want to trust Apple. But people should at least understand the strengths and weaknesses of the particular design that Apple has chosen. Now to some people this is obvious, and to other’s it’s no big deal. All of which is fine. If they cease to be honest (or if somebody compromises the iMessage servers) it may be possible to run a man-in-the-middle attack and silently intercept iMessage data. The practical upshot is that the integrity of iMessage depends on Apple honestly handing out keys. From what I can tell, the iMessage app gives the sender no indication of how many keys have been associated with a given iMessage recipient, nor does it warn them if the recipient suddenly develops new keys. Moreover, iMessage lets you associate multiple public keys with the same account - for example, you can you add a device (such as a Mac) to receive copies of messages sent to your phone. Since you won’t know the difference, you’ll be encrypting to that person rather than to your friend.** The concern here is that Apple – or a hacker who compromises Apple’s directory server – might instead deliver their own key. “message identity key” associated with an This is great, but represents yet another tradeoff: you’re now fundamentally dependent on Apple giving you the right key. Apple has a simple solution to this: they operate a directory lookup service that iMessage can use to look up the public key associated with any email address or phone number. And that means before I can talk to you I need to get hold of it. The problem here is that encryption only works if I have your encryption key. The question you should be asking now is: encrypted to whom? In this case the above won’t apply to you, and Apple clearly says that their messages are end-to-end encrypted. All they need are your iForgot security questions, something that Apple almost certainly does keep.* Apple distributes iMessage encryption keysīut maybe you don’t use backups. Possibly at the request of law enforcement. The simple and obvious point is this: if I could do this experiment, then someone at Apple could have done it too. The sad thing is there’s really no crypto to understand here.
#USE YOUR OWN NUMBER FOR MAC IMESSAGES UPDATE#
( Update 6/27: Ashkan Soltani also has some much nicer screenshots from a similar test.)
#USE YOUR OWN NUMBER FOR MAC IMESSAGES PASSWORD#
If you can recover your recent iMessages onto a new iPhone - as I was able to do in an Apple store this afternoon - then Apple isn’t protecting your iMessages with your password or with a device key. Now go to an Apple store and shell out a fortune buying a new phone. Now change your password using Apple’s iForgot service (this requires you to answer some simple security questions or provide a recovery email).
All you need to do is run the following simple experiment: First, lose your iPhone. Unfortunately neither of these choices really works - and it’s easy to prove it. From here on out it’ll be ciphers and zero knowledge proofs all the way. A post which I swear will be the last post I ever write on iMessage. The details of this tradeoff are what I’m going to talk about in this post.
By witholding these details, Apple is preventing its users from taking steps to protect themselves. And while there’s nothing wrong with tradeoffs, the particulars of their choices make a big difference when it comes to your privacy. The service is almost magically easy to use, which means Apple has made tradeoffs - or more accurately, they’ve chosen a particular balance between usability and security.
My view is inspired by something I like to call “Green’s law of applied cryptography”, which holds that applied cryptography mostly sucks. Crypto never offers the unconditional guarantees you want it to, and when it does your users suffer terribly.Īnd that’s the problem with iMessage: users don’t suffer enough.
This seems almost too good to be true, which in my experience means it probably is.
0 kommentar(er)
