We all knew stickers, payment options, and games would appear as the first wave of iMessage apps the moment iOS 10 shipped. Less obvious was the availability of encrypted-message apps that work within iMessage. Isn’t iMessage already secure enough?
Yessssssss—imagine me slowly drawing out that “s” for a while—and no. As I’ve written about in this space for years, researchers have found iMessage and FaceTime’s underlying cryptographic implementation remains unbroken, but have found and exploited weaknesses. Some of those were patched, while others remain fundamentally problematic.
On top of that, we know that the world’s spy agencies and criminals all over would love nothing better than be able to gather messaging information en masse or target individuals, and iMessage is thus a key target, along with Facebook’s WhatsApp and others.
Adding encryption you control inside an iMessage transmission can provide more assurances that your messages remain unreadable to others, but there a whole lot of provisos you need to consider before accepting this as a higher level of security.
New apps, who apps
I’m always excited to see new ways for people to take direct control of their own privacy and security enabled by tools that keep their hands off. The first three apps I’ve found have a couple of approaches, and none of them is quite it yet. Those apps are Cipher Pro (free, $2 in-app purchase), Password Message ($1), and Secret Message ($1). Cipher lets you decrypt received messages at no cost, but you need to purchase the IAP to send messages back.
Secret Message (left) and Password Message require you to tap in a password.
First, we don’t know enough about the developers or their companies. Even assuming each company is pure of heart, apps that purport to offer security and privacy require substantial, open disclosure about who is making them. With single-developer firms or companies in countries that have issues with government intrusion (Russia, China…America…), this requires a lot of openness, which can be paired with my second point.
Which is: the code needs to be open to inspection and audit. If you—meaning anyone, but more particularly people who specialize in beating on encryption implementations—can’t check the code of crypto software, you effectively shouldn’t trust it, even again assuming that the developers are brave and true and noble and wise. A flaw in code that its programmers missed, a malicious insertion by a cracker who gains silent access to a private repository, and other issues can break security. One of iMessage’s fundamental problems, in fact, is Apple’s lack of public disclosure of how it audits and its lack of interest in making at least relevant portions of the code available to anyone outside the firm.
Cipher uses a more sophisticated approach to protect an encrypted message, but it doesn’t explain or expose enough information to users yet.
Third, two of the apps use a symmetrical key solution—that is, you enter a password and the party on the other end has to use the same password to decrypt it. This allows any intermediate party who gets ahold of that password or can guess it to access the message. Cipher relies on encrypting using information locked via Touch ID or a passcode, but it doesn’t disclose how you validate the key to allow the other party to gain access.
The other two apps require tediously tapping in a password for a message, which is then converted into a strong encryption key. But the necessity of tapping it in makes it unlikely that it will be complex or long enough to defeat attempts to break it. We also don’t know how Password Message and Secret Message store the passwords entered: are they ever written to disk?
Because these initial apps don’t have interoperability with other encryption programs, both parties have to purchase (or download and unlock) the same iMessage app to communicate. Stickers and some other iMessage apps can send a version to iMessage users without iOS 10 and macOS users, but that can’t work with encrypted messages.
So enough of me dumping on these poor early entrants! I like the moxie, and nobody is trying to take your money without providing value. I just don’t think the first forays hit the mark beyond iMessage’s built-in encryption. They’ll mature and we’ll see many more options in days to come. I have an idea for one path forward.
How a system could work
Let’s look at the problem that iMessage apps with encryption can solve: they should let a user pick a password or other unique encryption seed to which only they have access, and allow a party on the other end to decrypt a message sent in some fashion without the password ever transmitting via iMessage. (They can’t solve anonymity, because both parties need an Apple ID and have to register devices with Apple, which provides a lot of ways to trace someone back through legal and other means.)
The obvious answer is public key encryption (PKE), which splits the encryption process into what works effectively like two separate keys. One is kept strictly private by the owner. The other can be shared publicly, and is used by other parties to encrypt messages that only someone with the private key can decrypt. The private key can also be used to sign a text or other message digitally, so that a recipient (checking with the corresponding public key) can be sure that its contents weren’t modified since they were sent by the owner of the private key. PKE is used for Web encryption, iMessage, Bitcoin and other cryptocurrency blockchains, and in many other ways.
PKE’s fundamental problem isn’t in secrecy, but in ensuring that you have the correct public key of the party to whom you’re sending messages. The PGP (originally “Pretty Good Privacy”) crypto-system developed over two decades ago solved key distribution for individuals and companies by pairing with keyservers, where people could post their keys for others to find. That proved to be a problem, because there was no good way to remove keys, update them, prove uniqueness, and so on.
There are lots of ways now to bypass using an old-fashioned keyserver. You can post the public key in its entirety in some places, and elsewhere a fingerprint, a sort of cryptographic shorthand, that can validate the public key is accurate. Keybase.io has formalized a way to post a key and validate it across social media accounts, websites, and other elements under your control to provide assurance, and bake the result into a Bitcoin transaction that others can verify independent of Keybase. (There’s a waiting list at Keybase.io, which is one of the most interesting overall projects to bring strong, personally controlled encryption to the masses in years.)
iMessage provides another path, and an app could automate this. You don’t want to send the key and its verification over the same method, because something that intercepts or sends the false key can also send a valid (but unwanted) fingerprint. Instead, an iMessage app can automate the public key exchange, and then display a human-readable fingerprint and a tap-to-dial option so you can go voice-to-voice.
It’s effectively impossible to mimic someone’s voice and behavior in real time in a phone call, so it’s a great way to handle the fingerprint validation. Something like this works within WhatsApp, where you can exchange a validation detail with someone in person using the app, with that physical component providing the not-same-method step.
iOS elements stored locally, such as crypto tied to Touch ID, can be used to protect the private key, or you could also use a passphrase.
Such a system can be (and has been) built into an app, but there’s a higher bar. The app can access contacts, but it doesn’t get direct access to a way of connecting with other people. It also doesn’t make it straightforward for a recipient to install and use the software required to get started. iMessage wraps that all up in one place: contacts, transit, and app information.
All these ideas are in common circulation and available in free and open-source software libraries, so someone should just go ahead and implement it in a way that also allows open inspection of their code. I mean, if they think it’s a good idea.
Such an idea might be entirely bypassed, too, if some of the existing end-to-end encryption ecosystems decide to plug into iMessage, even though that may seem counterintuitive, as those firms should want to drive traffic to their own software and services. But it may be a way to develop another revenue source and educate people about their more complete options for voice, mail, messaging, and video.
Leveraging without starting from scratch
I expect a lot more diversity to come to iMessage apps for another layer of secure messaging because the bar to create and distribute them is so low, and developers get a form of built-in word of mouth advertising when one person messages another who doesn’t have the iMesssage app installed.
Because Apple has a separate directory of iMessage apps available within the iMessage app interface, it’s a fresh area where developers can stand out, as opposed to the overcrowded full App Store. I look forward to seeing experiments—but even at a buck or two a pop, don’t buy in too early. More is surely coming.
Author: Glenn Fleishman, Senior Contributor
Glenn Fleishman’s most recent books include Take Control of iOS and iPadOS Privacy and Security, Take Control of Calendar and Reminders, and Take Control of Securing Your Mac. In his spare time, he writes about printing and type history. He’s a senior contributor to Macworld, where he writes Mac 911.