[Cryptography] Apple�s iMessage Defense Against Spying Has One Flaw

Allen Schaaf netsecurity at sound-by-design.com
Thu Sep 10 02:56:27 EDT 2015

On 9/9/2015 11:07 AM, Henry Baker wrote:
> <snip>
>   From here, the Apple server provides Alice with, say, Bob’s encryption keys.  Then armed with this information, Alice’s iPhone encrypts the message, sends the garbled text to Apple, which then forwards it over to Bob, who can decrypt it.
> At no point in this process does Apple see the actual content of the message, because it is encrypted before it leaves Alice’s device, aka end-point.  Hence, the label “end-to-end encryption.”
> This centralized approach to key management isn’t necessarily a problem, and is the same process that other encrypted messaging services use.  Signal, developed by Open Whisper Systems, also makes a user’s device connect to a central server of keys, Nicholas Weaver a senior researcher from the International Computer Science Institute, told WIRED in an email.
> However, as pointed out by Weaver in a recent post on the Lawfare Blog, it is impossible for an iMessage user to make sure that the Apple server has provided them with the right set of encryption keys.
> “Without such an interface, iMessage is “backdoor enabled” by design: the keyserver itself provides the backdoor,” Weaver writes.
> Weaver says that, if configured to do so, the Apple server could, instead of providing Alice with Bob’s correct keys, send an additional one that the FBI had access to.  Indeed, this was highlighted by researchers as far back as 2013, and Matthew Green, assistant professor at Johns Hopkins University also previously laid out a similar case.
> “[In that case] the FBI (but not Apple) can decrypt all iMessages sent to Alice in the future,” Weaver continues.  Likewise, by adding another FBI key to all messages that Alice sends herself, it would be possible for the agency to snoop all of her outgoing texts too.
> <snip>
Okay, verifying the public key can be automated, but why can't 
one verify that it is Bob's key and not the FBI's by sending a 
message and requesting an out of band reply. If the reply is a 
voice phone call from Bob that shows his phone number then Alice 
can call it and speak with Bob. It is possible (and probable) 
that the FBI could fake the proper phone number but it would be 
very difficult to find a identifier that was sent to Bob via 
snail mail or just handed directly to Bob prior to the start of 
the text message exchange. Just old fashioned WWII call and 
response, sign and countersign.

Another possibility might be some open source app using the 
approach that Steve Gibson is using in fingerprinting web pages 
to detect man in the browser attacks. The hash of Bob's real 
public key could be mailed/e-mailed to Alice. Bob could request 
his public key by asking to send a text message to himself and 
capturing it to then hash it and sending the hash to Alice. Then 
Alice can compute the hash of the file that the server provides 
to validate it. This could avoid a FBI MIM attack as the hash of 
Bob's key would be of his own key, not a fake provided to Alice 
by the attacker. Of course this assumes that Bob is the original 
source for the public key. If the server provides both the public 
and private key for Bob, all bets are off.

Does either of these make sense or have I missed some obvious flaw?



This e-mail may, and probably does, contain factual errors as 
well as errors of logic, organization, grammar, and spelling. 
They are included at no charge. However, you're invited to make a 

More information about the cryptography mailing list