Is Apple Fully Complying With iMessage and FaceTime-Related Court Orders?
Apple’s recent acquiescence to the Chinese government, both by removing anti-censorship VPN applications and in Tim Cook’s recent speech in China, is not just disturbing because it shows Apple succumbing to Chinese pressure to remove counter-censorship applications and Skype from the Chinese App Store.
Published by The Lawfare Institute
in Cooperation With
Apple’s recent acquiescence to the Chinese government, both by removing anti-censorship VPN applications and in Tim Cook’s recent speech in China, is not just disturbing because it shows Apple succumbing to Chinese pressure to remove counter-censorship applications and Skype from the Chinese App Store. The move is also in sharp contrast to Apple’s uncooperative behavior in the U.S. I’m not speaking of device encryption but rather Apple’s behavior concerning providing the government with information about iMessage and FaceTime communications.
iMessage and FaceTime have a cryptographic architecture that enables prospective wiretapping, yet there is reason to believe that Apple not is fully complying with lawful court orders to exercise this capability. There is also evidence that, although Apple is supposedly complying with pen register orders, the company is actually providing something substantially less than what the law is able to compel them to provide in response to a pen-register or trap-and-trace (PR/TT) order.
Pen registers and Trap and Trace Devices
But first, I should explain pen registers and trap-and-trace “devices.” A pen register or trap and trace device records (or in the case of a pen register might also decode) information about electronic communications passing through a particular platform, be it a cellular network, an email system, or an IP-based messenger. In a criminal investigation, the government may apply for a court order authorized under the Electronic Communications Privacy Act, specifically 18 U.S.C. §3122—based upon a showing that the information obtained is relevant to the investigation—to compel a company to provide the PR/TT information relevant to the electronic communication in question or to install a PR/TT “device” to get this information. And companies, according to 18 U.S.C. §3124, are required to comply with orders to assist with installation.
For an internet-based system, the PR/TT response may include the IP addresses of the sender and recipient, the start time of communication, and the length of the communication in bytes (for asynchronous messengers) or time (for audio and video calls), since this represents the “signaling information” involved in the two party’s communication. For example, here is an excerpt from a 2015 PR/TT order to WhatsApp:
Accordingly, IT IS ORDERED that, pursuant to Title 18, United States Code, Section 3123, pen‐trap devices may be installed and used, without geographic limit, to record, decode, and/or capture dialing, routing, addressing, and signaling information associated with each communication, to or from the Subject Account, including but not limited to the following:
Source and destination account numbers or telephone numbers associated with the origination and termination of all wire and electronic communications to and from the Subject Account, including identifying all participants of multi-party communications (e.g., group chat, broadcast, etc.);
Date, duration, and timestamp for each communication and service event, to include specification of the time zone offset from Universal Coordinated Time (UTC);
The type of communication (e.g., text, image, video, location, audio, etc);
IP Addresses associated with the originating and terminating customer devices used to send and receive communications (both IPv4 and IPv6);
Port Numbers (e.g. TCP/UDP Ports) associated with the originating and terminating customer devices used to send and receive communications (both IPv4 and IPv6);
Transport Protocol the originating and terminating customer devices used to send and receive communications (both IPv4 and IPv6);
Byte size information for each WhatsApp communication or other information from which the size of the communication and media transfers can be ascertained;
WhatsApp account numbers and any unique identifiers associated with each accounts/devices used to make and receive communications to and from the Subject Accounts, including identifying all participants of multi‐party communications (e.g., group chat, broadcast, etc.), sent or received by the Subject Account, including the:
WhatsApp Account Numbers
Electronic Serial Number (“ESN”),
Mobile Electronic Identity Number (“MEID”),
Mobile Identification Number (“MIN”),
Subscriber Identity Module (“SIM”),
International Mobile Subscriber Identifier (“IMSI”),
Mobile Station Identification Number (“MSID”),
Mobile Service Node (“MSN”),
Mobile Subscriber Integrated Services Digital Network Number (“MSISDN”),
or International Mobile Station Equipment Identity (“IMEI”).
Addresses or other information that uniquely identify the Subject Accounts used to authenticate to WhatsApp or its network, including the Internet Protocol address and device identifiers of any smartphone or computer used to access the subject account; as well as the time, date and duration of such access.
Apple’s Responses to PR/TT Court Orders
So if the FBI requests a PR/TT report on a specific iMessage account, the PR/TT response should tell the FBI that, at time T, Alice sent a message to Bob and the message was X large. When asked, Apple doesn’t appear to provide these details.
The Florida Department of Law Enforcement’s Electronic Surveillance Support Team’s guide showing what it receives from Apple in response to a PR/TT order reveals that Apple falls short:
Source: The Intercept 9/28/2016
Instead of logging the actual communication activity, Apple is only logging that “at time T, Alice at a specified IP looked up the keys for Bob,” what cryptographers would call the “keyserver lookup” since this involves querying Apple’s server for Bob’s public keys. Yet this is only loosely associated with communication activity.
These searches only occur once every so often when Alice is communicating with Bob, so they convey significantly less information. Alice only needs to lookup Bob’s keys when Alice is starting to send a new set of messages (it would be inefficient otherwise since Bob’s keys rarely change), and when Alice starts composing a message, her phone automatically queries for Bob’s keys to see if Bob supports iMessage, whether or not Alice eventually sends a message to Bob. In other words, a response like this does not actually give law enforcement that much useful information.
Instead of being able to say that “Alice and Bob had a back and forth conversation, and Alice seems to have transmitted a large file, roughly the size of an image,” the investigator may only infer that Alice may have decided to talk to Bob at this time. Apple reasonably chooses not to log information—preventing any retrospective orders since there is no obligation for retaining this information—but that does not remove Apple’s obligation to provide this information for future messages upon receipt of a prospective PR/TT order targeting Alice or Bob. Once law enforcement asks for future monitoring, Apple has a legal obligation to provide the detailed information for every actual communication: who, when, from what IPs, and how much data.
It could be that Apple now provides information akin to what WhatsApp will provide in response to a PR/TT order but it is unclear that this has actually occurred because I would have expected a court case to compel Apple would have ended up in the public eye and there is no evidence about Apple changing their policy. But I have not found any recent court orders compelling Apple to comply with PR/TT orders after providing inadequate information.
In the United States v. Lavabit, the Fourth Circuit is clear that providers have an obligation to cooperate with these orders. After all, it was the refusal by Lavabit to provide this exact information (presumably concerning Edward Snowden’s account) that resulted in the government eventually demanding Lavabit’s transport encryption keys so it could effect the pen register order without Lavabit’s further cooperation.
Apple’s Ability to Wiretap
Of further concern, and perhaps responsible for Sen. Ron Wyden’s (D-OR) cryptic concerns on technical assistance and Foreign Intelligence Surveillance Court (FISC) orders (suggesting that there is a previous or ongoing attempt in the FISC to compel a provider to provide technical assistance in support of some form of interception), is Apple’s lack of support for government wiretaps targeting iMessage and FaceTime. In my first guest post on Lawfare, I flagged that iMessage uses a design that actually enables wiretapping without weakening the cryptography, thinking at the time there may have been some theater going on. Now, I simply think Apple is just refusing to wiretap iMessage customers, even though they are technically capable of doing so.
If we look back at the information recorded in the keyserver lookup (the time at which Alice looked up Bob’s keys or, more concretely, what Apple logged in the example above) we see that there are a “number of devices.” Unlike WhatsApp and Signal, iMessage is designed so that a single user can have multiple public keys, one for each Apple device. When Alice sends a message to Bob, it is encrypted so that any one of Bob’s keys can decrypt the message. To assist in wiretapping Alice’s iMessage communication, Apple would simply need to modify the keyserver so that whenever Alice looks up someone else’s keys, it also returns an additional FBI key.
In this proposal, every message that Alice sends can be decrypted by the FBI because, from Alice’s viewpoint, the receiving device is just another device belonging to Bob; her phone happily encrypts the message so the FBI can read it. Similarly, anybody else’s request for Alice’s keys should include the additional FBI key allowing the FBI to read messages to Alice.
A similar technique could be used to wiretap FaceTime. Apple keeps the same key distribution change and when Alice wishes to make a FaceTime call, it would simply route that call to the FBI—which then acts as a “Man-in-the-Middle”—decrypting the call and then re-encrypting and forwarding the call to Alice’s recipient. Both proposals only enable prospective monitoring but prospective monitoring is technically possible.
Such monitoring works because Apple, unlike Signal and other end-to-end encrypted platforms, does not provide transparency to its users when keys are added or changed. If Bob uses Signal or WhatsApp, he is notified whenever Alice’s key changes. This prevents Signal from silently replacing Alice’s key with the FBI’s. Likewise, when Alice makes a call with Signal, it shows two “random” words that aren’t actually random but a function of the key used to encrypt the message. If Alice and Bob agree that they see the same words, they will then know that their key is the same, preventing a man-in-the-middle. Apple could have implemented similar features, perhaps hidden behind options, years ago; they have not.
Since Apple now seems to pride itself that “[they] follow the law wherever [they] do business,” I think it is reasonable for the U.S. government to demand that Apple do so in the U.S. Because it seems to me they haven’t.
