iMessage Encryption Flaw Found and Fixed

Matthew Green and team found and reported a significant iMessage encryption flaw last year.

Green suspected there might be a flaw in iMessage last year after he read an Apple security guide describing the encryption process and it struck him as weak. He said he alerted the firm's engineers to his concern. When a few months passed and the flaw remained, he and his graduate students decided to mount an attack to show that they could pierce the encryption on photos or videos sent through iMessage.

It took a few months, but they succeeded, targeting phones that were not using the latest operating system on iMessage, which launched in 2011.

To intercept a file, the researchers wrote software to mimic an Apple server. The encrypted transmission they targeted contained a link to the photo stored in Apple's iCloud server as well as a 64-digit key to decrypt the photo.

Although the students could not see the key's digits, they guessed at them by a repetitive process of changing a digit or a letter in the key and sending it back to the target phone. Each time they guessed a digit correctly, the phone accepted it. They probed the phone in this way thousands of times.

"And we kept doing that," Green said, "until we had the key."

A modified version of the attack would also work on later operating systems, Green said, adding that it would likely have taken the hacking skills of a nation-state.

This flaw is fixed in iOS 9.3. (You should download and install it now.)

I wrote about this flaw in IEEE Security and Privacy earlier this year:

Going back to the new vulnerability that you'll learn about in mid-February, the lead researcher wrote to me: "If anyone tells you that [the vendor] can just 'tweak' the system a little bit to add key escrow or to man-in-the-middle specific users, they need to spend a few days watching the authentication dance between [the client device/software] and the umpteen servers it talks to just to log into the network. I'm frankly amazed that any of it works at all, and you couldn't pay me enough to tamper with any of it." This is an important piece of wisdom.

The designers of this system aren't novices. They're an experienced team with some of the best security engineers in the field. If these guys can't get the security right, just imagine how much worse it is for smaller companies without this team's level of expertise and resources. Now imagine how much worse it would be if you add a government-mandated back door. There are more opportunities to get security wrong, and more engineering teams without the time and expertise necessary to get

Related: A different iOS flaw was reported last week. Called AceDeceiver, it is a Trojan that allows an attacker to install malicious software onto an iOS device, bypassing Apple's DRM protections. I don't believe that Apple has fixed this yet, although it seems as if Apple just has to add a certificate revocation list, or make the certs nonreplayable by having some mandatory interaction with the iTunes store.

EDITED (4/14): The paper describing the iMessage flaw.

Posted on March 21, 2016 at 1:45 PM • 28 Comments


K15March 21, 2016 2:09 PM

And we function as a society with protection of privacy and private property how, exactly?

AnuraMarch 21, 2016 2:11 PM

Although the students could not see the key's digits, they guessed at them by a repetitive process of changing a digit or a letter in the key and sending it back to the target phone. Each time they guessed a digit correctly, the phone accepted it. They probed the phone in this way thousands of times.

I'm not sure whether this description is dumbed down to the point of being incorrect, or if this flaw was really that unbelievably bad.

AnonMarch 21, 2016 2:39 PM

Let's say the 64-digit key was "the" key to decrypt the file, how did sending individual digits to the phone for checking work? I haven't read the article or other reports yet, but that alone seems very strange.

VictorMarch 21, 2016 2:59 PM

There have been talks of Apple moving towards zero-knowledge encryption of iCloud. For people who use Apple's cloud (which uses Amazon AWS and Google) this is a great move to protect privacy but I'd like users to be given the option. Some people may feel comfortable allowing Apple to reset their password - they don't want to lose priceless photos - but others will be happy to undertake key management themselves. Providing it doesn't result in people using weaker passwords then I'm all for it.

My concern with iMessage is that no matter how good (or bad) the encryption is it'll make no difference if the sender or receiver backup their messages to iCloud because as we know the data on there can be accessed with a warrant. It'd be good if Apple introduced an ephemeral message (self destruct after X seconds/minutes/days) as it'd allow a sender to be confident that their message will be destroyed after that amount of time has lapsed (unless the recipient consciously took a screenshot).

On a side note the new Night Shift facility in iOS 9.3 is amazing. Now you can get true night-time reading with very low brightness and very high 'warmth' of colour. It really makes for a dim but readable screen. As a user of f.lux on the desktop I'm glad Apple have incorporated it into iOS without the need to dangerously jailbreak your device.

JacobMarch 21, 2016 3:04 PM

The level of distrust in LEA and NSA is so great, that one must consider the possibility that the NSA picked up the comm by Prof. Green at the active reasearch state late last year noting that its the iPhone line, the FBI served NSL to get the details and then have used the discoveries to its purpose until patch time.

VictorMarch 21, 2016 3:05 PM

The 1970 bug has been fixed in this release too.

With this update your iPhone, iPad and iPod touch gain improvements to Notes, News, Health, Apple Music and a new feature called Night Shift that may even help you get a better night’s sleep by shifting the colours in your display to the warmer end of the spectrum at night. New features, improvements and bug fixes include:

Night Shift

When enabled, Night Shift uses your iOS device’s clock and geolocation to determine when it’s sunset in your location, then it automatically shifts the colours in your display to the warmer end of the spectrum and may even help you get a better night’s sleep.

Notes improvements

Protect notes that contain your most personal data with Touch ID or a passcode
Sort notes alphabetically, by date created or by date edited
When sketching, quickly bring up a fresh canvas with a two finger swipe or by tapping the New Sketch button
A new checklist button at the bottom of every note makes it easier to create lists
Show thumbnails instead of large images and attachments by long-pressing on any image or attachment in a note
Choose whether photos and videos taken within Notes are stored only in Notes or also added to Photos
Long-press on an Evernote Export file to import its contents into Notes

News improvements

New Top Stories section in For You highlights the most important stories of the day
Discover something great to read in Editors' Picks, a selection of channels and topics handpicked by our Apple News editors
Swipe left on stories in For You on iPhone to quickly share or save or swipe right for more options
Play video stories right from For You — without opening the article
Read stories and watch videos in landscape orientation on iPhone
Change the text size in articles to make reading easier

Health improvements

Related third-party apps for select data types such as weight, workouts and sleep are displayed in the Health app
Health dashboard adds support for move, exercise and stand Activity data and goals from Apple Watch
Easy access to Dashboard and Medical ID using 3D Touch Quick Actions from the Home screen
Third-party apps now have access to Activity rings and summaries from Apple Watch through HealthKit

Apple Music improvements

Add songs from the Apple Music catalogue to playlists without having to add them to your library
Watch music videos on iPad in full screen
See what’s playing on Beats 1 directly from the Radio tab — without having to tune in
Tap the name of the currently playing song in Now Playing to go to the album
See which songs are most popular on albums in the Apple Music catalogue

Photos improvements

Extract the still image from a Live Photo by tapping Duplicate which will give you the option to duplicate the Live Photo or just the still image
Improved download performance of full size original photos or videos stored in iCloud Photo Library
Share Live Photos between iOS and OS X through AirDrop and Messages

iBooks improvements

Adds the ability for iBooks to store your PDFs in iCloud, making them available across all of your devices
Adds support for downloading previously purchased audiobooks from the iBooks Store
Adds the ability to share your audiobook purchases with any of your family members using Family Sharing
New controls for reading Manga more comfortably with faster page turns and simple controls for enlarging text
Adds Apple Pencil support to highlight and save your favourite passages for later

Education improvements

Introduces a preview of Shared iPad that enables multiple students to use the same iPad at different times throughout the day
Adds support for signing into iCloud with Managed Apple IDs
Adds compatibility for the new Classroom app
New configuration options to control the organisation of apps on the Home Screen
New controls to determine which apps to show or hide on the Home Screen
Adds support for new restrictions for iCloud Photo Library and Apple Music

CarPlay improvements

Apple Music members now have access to their For You and New content in CarPlay
New Nearby screen in Maps to quickly find petrol, Parking, Restaurants, Coffee and other driving essentials
Siri speaks more concisely when reading back and composing messages in CarPlay
Equalised sound levels between different audio sources in CarPlay
Dolby Digital Plus
Adds support for playing video encoded with Dolby Digital Plus audio streams with support for multichannel output using the Apple Lightning Digital AV Adapter

Hardware keyboard improvements and fixes

Enables the use of arrow keys to navigate through lists in Spotlight, Mail and Safari
Enables the use of space bar to scroll in Mail
Improves performance when using the space bar to scroll in Safari
Adds the ability to bring up the software keyboard from the Shortcut Bar when a hardware keyboard is connected
Fixes an issue that could prevent unlocking an iPad using the hardware keyboard
Fixes an issue that caused hardware keyboards to become unresponsive in captive login pages
Fixes an issue that could cause the Messages input field to disappear behind the Shortcut Bar when connected to a hardware keyboard

Other improvements

Maps adds support for getting a highlighted view of destinations and stops for a specific public transport line by tapping on it
Maps now displays whether there are multiple public transport line options for each route suggestion
Wallet app adds the ability to view the app related to a card or pass in the Wallet app by tapping an icon on the card or pass
Apple Pay adds support for signing up for store rewards programs with Apple Pay at point of sale terminal
Podcasts adds support for fullscreen video playback
Activity app adds a new Workout tab with monthly summaries of key metrics and the ability to filter by workout type
Move to iOS now offers app suggestions from the App Store based on apps installed on your Android device
iCloud Storage adds proactive status information and in-app notifications to let you know before you run out of space
Two-factor authentication is now available for all iCloud accounts
Support for Spanish (Latin America) system language
Siri support for Finnish (Finland), Hebrew (Israel) and Malay (Malaysia)
Enterprise bug fixes
Resolves an issue that could prevent some VPP purchased apps from launching after being updated
Adds iCloud backup support for device-assigned VPP apps
Addresses an issue that could prevent certificates from installing correctly when updating configuration profiles
Fixes an issue for some IPSec VPN configurations that could cause the Internet connection to be interrupted after a VPN session was ended
Fixes an issue to prevent iBooks from emailing enterprise managed PDFs from unmanaged accounts
Resolves an issue for some Exchange users that caused Calendar to send multiple responses to the same invitation
Improves reliability for devices connecting to OS X Caching Server

Accessibility bug fixes

Improves 3D Touch reliability with Switch Control Accessibility option
Fixes an issue where VoiceOver interferes with speech after dictation
Fixes an issue where VoiceOver users could not write a review on the App Store
Resolves an issue where VoiceOver becomes unresponsive when receiving a phone call with a Bluetooth headset
Fixes an issue where large text was unreadable in Reminders
Other bug fixes, performance and stability improvements
Fixes an issue where manually changing the date to May 1970 or earlier could prevent your iOS device from turning on after a restart
Fixes issues that could prevent some iCloud Backups from completing
Fixes an issue for some users where Health data was incomplete after restoring from iCloud Backup
Fixes an issue where an inaccurate battery percentage could be displayed
Addresses an issue that prevented iMessage or FaceTime activation for some users
Addresses an issue that could prevent displaying the Phone interface while receiving a call
Fixes an issue that enabled overriding restrictions applied to mobile data toggle
Fixes an issue that caused notification settings to appear in the Watch app for apps that were not installed on Apple Watch
Improves reliability when using 3D Touch on the keyboard
Improves stability of the Phone app when setting up voicemail
Improves stability of the Mail app when your device is low on storage
Improves stability in Mail while using Mail Drop to send large attachments

Some features may not be available for all countries or all areas, for more information visit: and

For information on the security content of this update, please visit this website:

VictorMarch 21, 2016 3:30 PM


Available for: iPhone 4s and later, iPod touch (5th generation) and later, iPad 2 and later

Impact: Visiting a maliciously crafted website may auto-fill text into other Message threads

Description: An issue existed in the parsing of SMS URLs. This issue was addressed through improved URL validation.

CVE-2016-1763 : CityTog


Available for: iPhone 4s and later, iPod touch (5th generation) and later, iPad 2 and later

Impact: An attacker who is able to bypass Apple's certificate pinning, intercept TLS connections, inject messages, and record encrypted attachment-type messages may be able to read attachments

Description: A cryptographic issue was addressed by rejecting duplicate messages on the client.

CVE-2016-1788 : Christina Garman, Matthew Green, Gabriel Kaptchuk, Ian Miers, and Michael Rushanan of Johns Hopkins University

Anura March 21, 2016 5:32 PM

The paper on the flaw is a available here. A quick skim through, and I have to say the Washington Post description is just plain wrong. According to the paper, the attack exploits the use of GZIP compression, which has CRC32 checksums they can use as an oracle. On top of that, it exploits the fact that you can replace the signature with the signature of another sender whose account you control, and it will see the message as valid.

AnuraMarch 21, 2016 6:18 PM

This attack would be impossible if it wasn't for the fact that you can replace the signatures. Let this be a lesson: whenever you derive a key, the identity of the sender should be passed as part of the data included in the Key Derivation Function, so that if someone else tries to pass off ciphertext as their own, it will decrypt to gibberish.

Nick PMarch 21, 2016 7:19 PM

@ Jacob

Or they could just spy on communications of all vulnerability researchers or disclosure sites/addresses. Free vulnerabilities. It's what I'd do if I were them.

Clive RobinsonMarch 21, 2016 8:38 PM

@ Anura,

The real underlying problem was Apple using a stream cipher (AES-CTR) without a crypto MAC to prevent "bit flipping" attacks.

I'm guessing Apple incorrectly assumed that using the compression algorithm would do as a substitute.

Apple would have got away with this if it were not for a side channel of Apple's own making, that could be used as an "oracle".

The side channel is "out of band signaling" for attachments. For various reasons attachments to messages are not sent within the message system, only a URL and decryption key. The URL is not "locked" to Apples servers. This means that it is possible to give a URL that you control and use that as the "oracle". If you flip a bit in the compressed message and the correct bits in it's CRC then the phone does not see an error and goes and fetches the URL. If you get the CRC bits wrong then the phone sees an error and does not fetch the URL.

The compression CRC is a linear code which is why you can do this (there are papers that describe how to do it). If the compression function had used a crypto MAC instead then the attack would not have be able to use this known bit flip attack.

Asside from the non use of crypto MACs with stream ciphers, and out of band signaling as a side channel, it highlights the fact that what appears nonsensical as an attack--the resigning of an old valid message-- can be used in combination with other issues as an attack.

With hindsight it's easy to see where it went wrong, but I'll be honest and say it would have probably got past me, even though I know about the other two "no no's". So Mat Green's students deserve quite a bit of credit, for spotting it in the first place.

The other thing it highlights is the difference between general "engineering" and "security engineering". From an engineering aproach Apple's protocol was quite robust in terms of communications error detection, that is the chance of getting a false positive by chance was vanishingly small. But from a security engineering perspective a vanishingly small chance is "whole cloth" to work up into a nice little number...

Mat Green's comments about not being able to get encryption right thus no chance on "backdoors" is a message that should be tattooed on peoples foreheads lest people don't get the message.

Dirk PraetMarch 21, 2016 9:18 PM

@ Clive, @ Anura

The real underlying problem was Apple using a stream cipher (AES-CTR) without a crypto MAC to prevent "bit flipping" attacks.

There is (or was) a similar problem with Telegram in that they are trying to do “Mac and Encrypt” instead of “Encrypt then Mac” with HMAC-SHA512. Interesting analysis by Crypto Fails here.

Mat Green's comments about not being able to get encryption right thus no chance on "backdoors" is a message that should be tattooed on peoples foreheads lest people don't get the message.

I bet he and Ken Livingstone would make great drinking buddies.

@ Mike, @ Curious, @ CallMeLateForSupper, @ Jack Jones

Re. Telegram

Please be very careful with Telegram. Although not obviously broken, neither @thegrugq or Matthew Green think very highly of it. Green even compared their crypto to "being stabbed in the eye with a fork".

AnuraMarch 21, 2016 9:30 PM

@Clive Robinson

Apple assumed that since the message was signed, they didn't need the MAC. It's a reasonable assumption, but flawed in a not obvious way. It prevents forgery, but not other attacks. Simply doing what I suggested, including the sender as part of the data passed to the KDF (something that is provided for in NIST KDF specs, but not necessarily considered a must) would have stopped the attack. Others recommend sign-then-encrypt as it will cause a hard error that something is wrong, rather than just gibberish - I think that's fair. ECDH using two static and one ephemeral key, with a MAC is my preference, as the key exchange results in implicit authentication. However, there are reasonable concerns about the security of ECDH, and due to recent precomputation attacks traditional diffie-hellman should probably be avoided as every user would need to use the same parameters to use it for authentication.

AnuraMarch 21, 2016 10:09 PM

That should say "implicit authorship verification" not "implicit authentication".

AnuraMarch 22, 2016 1:30 AM

Thinking about it, even signature + MAC you need to be careful. Generic scenario:

You are sending your paper to a teacher, you generate key material, encrypt the key material with your teacher's RSA key, and from the keymat you derive an encryption key and MAC key. You encrypt the paper, append a mac, and then sign the whole shebang before emailing it to the teacher.

Another student has access to the mail server. They intercept your paper, strip your signature and append their own. The MAC is still valid, and everything looks good. The teacher gives the malicious student an A, while the innocent student gets an F for not turning in their paper.

No forgery is involved, but the problem is that it still wasn't enough to verify authorship. This is a situation where sign then encrypt could have been used to avoid the problem, but that has the same problems as mac-then-encrypt in which an attacker can exploit the possible implementation flaws that occur since you need to decrypt the message before verifying the MAC/signature. Alternatively, you need to sign the message, append the signature, and then compute the MAC over the entire message with the signature. Using ECDH as mentioned above works as well.

ThothMarch 22, 2016 5:01 AM

A session message should be tied to it's session keys (encryption and MAC). If you tie it to a long term key that can be chopped up and replaced like Matt Green et. al. did to chopping up the encrypted message from the signature, you can claim them your own.

What a MAC does is to tie the message to the short term session symmetric key which only both side know whereas a long term asymmetric key allows you retrospective analysis opportunities. This is where MAC-ing with a symmetric short term session key comes in by ensuring only two parties know the secrets. You can't simply chop up a session message and then invent some session key and MAC the data as that will be an obvious error.

Another thing to this that is not commonly noted is the thousands of erroneous tries they have to use. What if a tolerance limit to how many seemingly wrong messages that do not yield the correct authentication code is put in place before resetting the session and requiring a session negotiation all over again. This can open up to DOS-like attacks but it is better than allowing so many wrong messages to go through without being stopped. Sending the thousand over wrong messages by itself is already a form of DOS anyway so might as well force a session disconnection and forcing a renegotiation.

Adding some proof-of-work games like hashing message games into the protocol to make communication spamming more expensive to attackers would also make the protocol less likely of a low hanging fruit.

Traditional DH is still secure if you use a big enough key size (>= 2048 bits) over an RFC standardized parameter set. If paranoid, just use 4096 bit keys since very rarely would anyone support anything bigger than 4096 bits on hardware and on software it's even slower. Pre-computation over a secure key size is still not very feasible (although plausible). Another alternative of generating own primes is actually more problematic due to people getting it wrong by mistaking non-primes as primes for the code cutters that don't know how to do it right (too many of them just don't get it right :)).

ECC based curves are now in a state of limbo due to NSA dropping the bombshell on ECC crypto. It is not a killing blow to ECC but it's enough to cause doubt. Is DJB's Curve25519 and Ed25519 still safe ? No idea..... no comments nor research into any impact from NSA's bombshell on ECC implicating Curve25519 and Ed25519.

In fact, both traditional DH and ECC are bound to fail once a competent quantum computer emerge some long years (or may short years) later with ECC predicted to fall first.

I only offer RSA and DH for implementations I do (unless ECC is enforced by standards for a particular protocol or format) with >= 2048 bits key sizes just to be on the safe side that NSA's bombshell has any grain of truth which they attempt to hide routinely. Plus, implementing your own Curve25519 or Ed25519 on an embedded hardware (e.g. smartcard) with just 2KB RAM and 5KB EEPROM/Flash is a difficult attempt (probably even suicidal with so much side-channels for attack) whereas the hardware offered RSA and NIST ECC are usually covered with DPA/SPA protection mechanisms to a certain degree which can be leveraged.

ThothMarch 22, 2016 5:22 AM

re: Student's stolen paper
This is a problem with asynchronous messaging where you don't have a concept of session negotiation with shared secrets. Shared secrets between two parties makes it the case where no one learns the secret and thus cannot simply cut and paste what they like. This makes the message bind to the session.

I doubt there is any way to prevent such an attack unless it is bound by some sort of shared secret used to establish some form of two-way trust for that session.

zMarch 22, 2016 5:40 AM

Isn't iMessage using 1280 bit RSA keys? I understand that there are probably other weaknesses in the system, but that always struck me as uninspiring given the wide range of governments that are probably trying to attack iMessages.

zMarch 22, 2016 5:45 AM


Regarding ECC, I also tend to trust RSA more in light of those revelations, but I still happily use Curve25519 in my own code because Libsodium makes it easy to implement and hard to shoot yourself in the foot. I take the view that an implementation error on my part is far more likely than a break of Curve25519, so I'd rather go with a library that minimizes that risk.

Vesselin BontchevMarch 22, 2016 6:07 AM

The "hole" in the iMessage encryption is the usage of non-authenticated encryption (i.e., no MAC). This allows for message malleability - the attacker can change a single bit in the message, re-sign it, and check whether it can be decrypted by the recipient. In order for the attack to be practical, the attacker needs to be able to re-sign the message (i.e., prevent the recipient from receiving the original message). This doesn't work on the modern versions of iOS (even before the patch), because they use certificate pinning. Second, the attacker has to be able to determine if the recipient is able to decrypt the modified message. This is why the attack works only against messages that contain photos or videos (they aren't in the message; instead the recipient gets an URL for accessing them after decrypting the messages; by monitoring this URL the attacker can determine if the message was decrypted successfully). Even then, the attacker has to be able to isolate the victim from Apple's servers. Doable for a nation-state and for Apple (if served a National Security Letter), but not for a random hacker. Still, it's good that Apple has figured out a workaround. In the long run, iMessage ought to be replaced by a better crypto protocol.

The AceDeceiver thing is pretty serious, too. The actual malware is crap and doesn't pose significant threat (if you aren't trying to pirate apps in China) but the method it uses is quite dangerous and can be exploited much more efficiently in the future. Basically, if your PC is infected with malware using this attack, when you pair your iPhone with it, the PC can start pushing malware to your iPhone without your notice or consent. The only requirement is that the malware has been at some point of time in the AppStore. It doesn't have to be still there at the time of the attack - i.e., removing it from there doesn't stop the attack.

ThothMarch 22, 2016 6:47 AM

I lean more to discrete log (RSA and DH) since they are easier to understand thus easier to verify than ECC. There are so many curve variants and who knows what they might contain (backdoors). DJB wrote about Safecurves which he identified many "unsafe" curves deployed and approved by NIST !!! With so many different curves ot takes time to validate them as secure from anything sneaky and also secure and correctness of implementation. We can even get discrete log crypto right (mistaking non-primes as primes), moving to more complex crypto schemes like ECC is going to yield more problems.

AnuraMarch 22, 2016 11:32 AM


iMessage is an offline system, and doesn't have a session key. Each message is encrypted independently, and without two-way key negotiation. If it did, the attack would be thwarted by key confirmation.

MarkHMarch 28, 2016 12:34 PM

@Thoth, who wrote:

"I lean more to discrete log (RSA and DH) since they are easier to understand thus easier to verify than ECC."

I think there is a problem of classification here. As far as I know, ECC schemes are based on the elliptic curve version of the discrete log problem (DLP).

Perhaps you meant "integer multiplication" rather than "discrete log" as the category including RSA and (non-EC) DH.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.