Hacker News new | past | comments | ask | show | jobs | submit login

It's interesting how easy Apple's iMessage model would lend itself to being a mass-deployed, heavily-used, CA-based asymmetric encryption network.

As I understand iMessage, when you attempt to text a number a background thread fires and checks with Apple's iMessage servers to see whether or not the number is associated with an iMessage account, then returns the end-user account details to your device so it may send a digital message addressed to that user to Apple's iMessage servers.

Replace that digital ID with a public key. Private keys are generated and kept only on your iDevice. iMessage servers are your CA. Each iDevice has a unique public key.

At this point you have a very secure, end-to-end encryption scheme. No warrantless snooping is possible, and even Apple is unaware of your message contents.

Now depending on whether you want your design to be CALEA-compatible or not, Apple can issue a new private key to the government and add it to "your" list of public keys on their CA to allow the government to intercept future messages after they have obtained a warrant. If you think you can go toe-to-toe with the FBI and exempt yourself from CALEA by claiming the design of your infrastructure does not permit for message interception, you can tweak the CA around a bit. Only one public key per user, pass private key symmetrically encrypted with a password only the user knows from one device to the other via a "secure" side channel when adding new iDevice to user's iMessage account or other workaround.

I'm absolutely not a security person, and none of what I say should be taken except as some ramblings that might have some hint of an idea beneath them. I already can think of a dozen weaknesses in this system, this kinda works only if you assume you can trust Apple to play within the rules of the framework they're making, i.e. not to try to intercept your private key, log your keystrokes, automatically add a second public key recipient to your messages, etc. Fact of the matter is, you are at their mercy. tptacek, please be gentle in gutting me.

Edit: Thanks for that link, daniel. It is comforting to know that there is indeed some base level of security. If CALEA-compliance is achieved by adding the fed's public key to a list of destination public keys for a message, that implies you should actually be able to find out whether or not you're being monitored by simply checking for new/unknown/unexpected additions to your list of public keys. Of course, there are other methods of doing this that wouldn't be as easy to detect, e.g. maybe there is an out-of-band request for additional public keys to send to, maybe the fed's public key is already embedded in the device and is being used invisibly every time, etc. etc. etc.

Edit2: For people wondering if syncing of old iMessages between devices means iMessage doesn't work like this, I don't think that's the case. I believe that's done via iCloud (i.e. backup of previously decrypted messages), as when you add a new Apple ID to iMessages on OS X, you don't get the old messages for that account, only new ones. So it's another attack vector, but not inherent weakness in the iMessage design.




This is actually how the protocol works, it uses the certificate burnt into the CPU; Apple claims that the private keys are known by no party including themselves, probably generated by the chip fab with some some of SCEP exchange. I've been meaning to update the IMWiki page with my research, but here's the bit where you see that exchange: http://imfreedom.org/wiki/IMessage#Unknown2 ["Apple iPhone Device CA" / "Mac OS Device Identity (Production)"]


> Apple claims that the private keys are known by no party including themselves

Source? How can I add a new device (e.g. Messages on OSX) and get all the messages between my phone and friends?


Private keys, not public; the messages are decryptable by anyone who's been added to the keybag, you've probably seen the pop up notifying you that another device (private keys burnt onto the chipset) is joining the keybag. Once you hit OK Apple pings you with encrypted communications from the other devices (them being the pipe and presumably not in the trust chain, this explains why sometimes it's a little iffy showing cross device messages.)

The protocol hasn't been completely reverse engineered but enough to know it's likely decentralized like this, just MITM it (quite a bit is documented on the wiki I linked), Apple is the CA and the piping but it appears to be rather strong and decentralized in terms of chain-of-trust. Apple has put itself, probably without coincidence, in a position where they may not even be able to execute a court order to spy on a user.

The Apple security white-papers detail their hardware level certificates, I've dealt with this a lot as a Apple MDM developer.


Not sure I'm reading this correctly, so a quick check:

When I have A, and want to add B, A ships its private key to B so it can decrypt the messages too? (and vise versa, obviously)

Or does A get B's public key, and A then re-encrypts and re-sends messages it receives to B?

Or is it something completely different?


The messages don't always arrive in the same order between the devices, so it's definitely not passed from one to the other. I imagine the senders encrypt the message with every public key in your keybag.

Someone who actually knows should weigh in, though. GP's understanding seems a bit murky to me.


If that's the case though, where would this popup be appearing from? (I haven't seen it, not quite sure where it would be) I would guess they wouldn't be asking the sender to approve adding my multiple computers whenever I add one, since that would be a fairly crummy user experience. Seems like it should be something that I, the owner of the receiving devices, would approve or deny.


The popup (and e-mail) only notify you that a device has been added to your account. The approval is done by logging in with your Apple ID.


I've seen the message notifying me that I've added a new device to the account, yes, but what does that have anything to do with the encryption?

When someone sends me an iMessage, their client sends as many copies as I have devices?


>When someone sends me an iMessage, their client sends as many copies as I have devices?

Generally how this works is that the sender encrypts the message with a symmetric encryption algorithm (like AES) and then encrypts the randomly-generated AES key with RSA with each of the receivers' private keys. So you only send out a single message, but it can be decrypted by any of the intended recipients.


If I understand this correctly, you're saying that they actually encrypt the message with a single key. Then they encrypt the messages key with the public key of all recipients and send it with the message, so each user can decrypt the message key with the private physically attached to the device and use it to decrypt the message?


That makes a lot of sense. In that case, it seems the easiest way to wiretap an iMessage account would be to compromise one of the devices. Not surprising that the DEA doesn't have that kind of expertise/authority, though.


Nope - all they have to do is get Apple to add another surveillance key to the list of device keys associated with your Apple ID. Then all future iMessages get encrypted to that one, too.


Whenever any iDevice downloads a new keybag with an extra key, it gives the user like 15 notifications that a new device has been added to the iMessage account. I don't think there's a way to suppress this (without releasing a new OS).


I think you are assuming too much about the coupling of the UI. Do people iMessaging me get an alert every time I buy a new iPad?

WINDMILLS DO NOT WORK THAT WAY.


No, but the person being snooped gets a notification.


Why do you assume that?


And apple would only have to make sure, that you get no warning, that another device was added to your keybag.


They manufacture the hardware, design and produce the software, and are the intermediary between all device communication with all other devices.

I have a feeling they could manage.


I didn't mean to imply, that they could not, written it missed my ironic voice-modulation ;-)

I really had thought, that this would have happened long ago, for everybody, and so on. Would not have thought, that this was a problem for law enforcement, as it was with i.e. skype.


The user could detect that, though, so it's a no-go.


Not without jailbreaking or proxying the push connection...


No, by default your device notifies the shit out of you whenever your keybag is modified.


You are confusing the iMessage device activation UI with the underlying crypto operations.

Nobody iMessaging me gets any indication when I get a new iPad and add it to my account, despite all their messages to me now encrypting (on their device) to n+1 of my devices now.


I'm trying to find more info about the certificate burnt into the CPU. Thus far, all I can find is the UID, which is an AES key burnt into the CPU and protected from cryptanalysis. However, I can't find anything about an asymmetric crypto key burnt into the CPU. Do you have any more info on that?


http://images.apple.com/ipad/business/docs/iOS_Security_May1...

You can find more info here. Encryption and Data Protection section should be a good place to start.


I've already read that document. There's nothing about burned-in asymmetric crypto keys, only the burned-in symmetric AES key (the UID).


That begs the question: how does my private key securely get shared between my mac, iPhone, and iPad so that all of my devices can securely read messages delivered to me.


The protocol appears to toss around the keybag, which causes the devices to re-sign payloads and toss them back up to Apple to pipe around—I've responded in more detail on a sibling.


From Wikipedia, the point of the CALEA is to require telephone companies to add in back channels, not software companies [1].

[1]http://en.wikipedia.org/wiki/Communications_Assistance_for_L...


The Justice Department successfully convinced the FCC to expand CALEA to ISPs by having the FCC treat ISPs as common carriers. (CALEA is a long story, but basically the internet freedom fighters agreed to not oppose CALEA so long as the internet was left alone. That backfired and the EFF hightailed it out of DC to SF.)

The choice is odd because the FCC deregulated the internet to make ISPs "information services" not "common carriers". So there is precedent for expansion that makes no logical sense.


Which is exactly the same issue we have everywhere else where laws that were made before the age of the internet use very narrow language that exclude computer systems in general and the internet in particular. It's just that this time, it's convenient for us.


No, think about the logical consequence of such an expansion. It would effectively make all encryption such as SSL/TLS illegal.


You'd have to remove iMessage features for that. Currently iMessage syncs between devices which is extremely useful. If each device generated it's own key that syncing wouldn't be possible.


Each device does have it's own key. When you add a new device that key is shipped to all the other devices that can receive the messages. Basically you have a ring of keys, and each time you add a new key every single device on that ring gets an updated copy of the key ring.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: