In a previous post, I summarized some academic papers in which prominent cryptographers and other security experts took a very skeptical look at current cryptography, both research and practical systems.
It’s not just e-mail plugins and other desktop computer applications that can disappoint us. One of the papers showed that the APCO Project 25 two-way radio system, used by law enforcement up to the federal level, embedded potentially strong cryptography within systems with gaping security holes.
An analysis from last year showed problems with another exotic sounding security system that we would certainly expect to be secure. In that case the problem once again wasn’t in the cryptography, but the user interface.
We look at risk analysis in Learning Tree’s System and Network Security Introduction course. As we discuss there, we must move beyond what might occur if everything happens to work as we hope, and consider what is likely to happen in real situations.
A number of crypto phone systems are now available to consumers. There are very real reasons to be concerned about communication interception by government intelligence agencies and private organizations including criminal gangs with adequate funding, capabilities, and motivation. These crypto phone systems include Zfone, Silent Circle, and TextSecure and RedPhone from Open Whisper Systems.
Some crypto phones are hardware, several are apps to be run on a smart phone. They promise end-to-end VoIP security guarantees for their strictly peer-to-peer and user-centric mechanisms. Let’s look into that.
The two end points agree on encryption keys using the open-source ZRTP protocol. A Diffie-Hellman ephemeral key is agreed upon when the session is established. That shared secret generates keys and salt for a Secure RTP session. The cryptography is strong, but there is no PKI or public-key infrastructure, and no trusted certification authority. Without further steps the system is vulnerable to a Man in the Middle (or MITM) attack.
Good news: ZRTP has further steps.
The Short Authenticated String or SAS is calculated and displayed at both ends. The SAS is essentially a cryptographic hash of the Diffie-Hellman values, albeit an unusually short one with just 16 bits of output. It is converted to two words and displayed on the phones at each end.
Each user reads the displayed SAS word pair over the newly established link. If the MITM attacker is running an active attack, the two SAS values seen at the end points will not agree.
With the SAS being a 16-bit hash, there is only a 2–16 or 0.0015% probability that a MITM attacker could guess which 16-bit hash and thus two-word authenticator to use.
On top of that, we can expect that in most situations the two users know each other already, and thus each should recognize the other’s voice. More importantly, they should recognize that any MITM attacker is not the person who should be at the other end.
Maliheh Shirvanian and Nitesh Saxena of the University of Alabama at Birmingham asked and answered that questions in their paper On the Security and Usability of Crypto Phones.
As it turns out, things go wrong disturbingly often.
SAS strings are mis-read. When read correctly, they are mis-heard. Even when read and heard correctly, it’s surprisingly often that the person doesn’t realize that what they just heard doesn’t agree with what they’re looking at.
Then there are the cases where the situation really is good, but one or both of the people at the endpoints conclude that it isn’t. Self-inflicted denial of service, plus unneeded worry that they are under attack.
Then there is the problem of recognizing voices. Humans will think that another human is really their friend. Or that a computer or an electronically modified human voice is their friend. Play their friend’s actual voice to them, and some of the time they will think that an imposter is speaking.
As Agent Smith said in The Matrix, “Never send a human to do a machine’s job.”
The math said that an attacker should have no better than a 0.0015% chance of success. The testing indicated that with sloppy humans at both ends, the attacker had a 30% chance of success!
Increasing the SAS hash length to 32 bits should, in theory, have made the system 216 or 65,536 times stronger. The reality was that the attacker’s success rate increased from about 30% to about 40%.
Between struggling to match the SAS and recognize the voices, a legitimate session had only a 75% chance of being accepted as valid.
The only good news is that the users felt that the systems were reasonably easy to use.