This work is a collaboration of Dominik Schürmann, Fabian Kabus, Gregor Hildermeier, and Lars Wolf.

VoIP Security with ZRTP

Voice calls are still one of the most common use cases for smartphones. Often, sensitive personal information but also confidential business information is shared. End-to-end security is required to protect against wiretapping of voice calls. For such real-time communication, the ZRTP key-agreement protocol has been proposed. By verbally comparing a small number of on-screen characters or words, called Short Authentication Strings, the participants can be sure that no one is wiretapping the call. Since 2011, ZRTP is an IETF standard implemented in several VoIP clients.

We analyzed attacks on real-world VoIP systems, in particular those implementing the ZRTP standard. We evaluate the protocol compliance, error handling, and user interfaces of the most common ZRTP-capable VoIP clients. Our extensive analysis uncovered a critical vulnerability that allows wiretapping even though Short Authentication Strings are compared correctly. We discuss shortcomings in the clients’ error handling and design of security indicators potentially leading to insecure connections.

Test Cases

We designed a set of test cases to test ZRTP clients. These either follow the protocol specification to test basic implementation requirements or explicitly violate parts of the ZRTP standard defined in RFC 6189. An app passes a test if it behaves according to the expected results defined per test. For a brief overview, our test cases are summarized in the following table. A full description of each test case can be found in the publication.


For our evaluation, we selected common ZRTP-capable VoIP clients. An overview of our results can be found in the following table:

In the following I give a short summary of our findings. For more information, please read our publication:

  • We found a security vulnerability in Linphone (CVE-2016-6271) that has been responsibly disclosed on 07/05/2016 to Belledonne Communications and fixed in Linphone 3.2.0.
  • In Jitsi, a MitM warning was shown even for normal calls due to erroneously reading the last entry from the ZID cache. We fixed this issue directly.
  • CSipSimple and Linphone did not implement a warning dialog when an invalid shared secret is read from the cache [invSS]. While RFC 6189 requires this, it is not a fatal protocol error and its usefulness is limited.
  • No tested client except Acrobits Softphone and Signal is protected against the shared MitM attack [sharedMitM]. In this attack, a third person Eve conducts a normal ZRTP-protected call with Alice and one with Bob at different times. All participants verify the SASs. Now, Alice as well as Bob have shared secrets associated to Eve’s ZID in their cache. Eve can now act as an active MitM by announcing her own ZID instead of forwarding that of Alice and Bob. Because ZIDs are not associated to a participant’s SIP address, this attack stays undetected. RFC 6189 proposes ZID labeling to provide users a way to detect this attack. We suspect that the adoption of ZID labeling is hindered by its UI complexity. Here, we want to encourage a broader discussion how to prevent this attack automatically, e.g., by SIP-ZID binding.
  • We encountered different status indicators, which were not optimal and easily dismissed. Developers should follow our best practices and use indicators proposed in our publication. To prevent accidental insecure usage, clients should terminate on errors and provide secure defaults for SIP accounts. We hope that our proposed best practices encourages a discussion about usability and UI elements in the ZRTP developer community.

Aftermath (2017-03-21)

  • Signal no longer uses ZRTP in its recent versions. It now uses WebRTC and “the “signaling” messages used to set up the voice/video beta calls (offer/answer SDPs, ICE candidates, etc) are transmitted over the normal Signal Protocol messaging channel, which binds the security of the call to that existing secure channel.”.
  • It has been asked why we have included Linphone on Android, but not on iOS. Honestly, it somehow escaped our attention. We should have included it as an individual app. Because it is also based on the bzrtp library and has a UI that is nearly identical to the Android implementation, the evaluation would probably be very similar to Linphone on Android, especially the issues we have with the security indicators are true for both implementations.
  • In our evaluation we were not able to initiate PBX enrollment with any SIP client. However, after email contact with Acrobits, we learned that it should be possible to initiate a PBX enrollment with their client Acrobits Softphone. They claim to support this feature with the default Freeswitch configuration by calling 9787 which is the enrollment number. Thus, we consider testing PBX enrollment against Acrobits Softphone using a different setup. For open source clients, we were able to verify that PBX enrollment is not supported by studying the source code.

Takeaways for Protocol Designers (2017-03-21)

I think there are several important takeaways from our paper. While it is a laudable effort that ZRTP has been designed to work with any session protocol, handling cryptographic identities independent of the outer protocol fails in practice (see [sharedMitM] attack). While Acrobits Softphone allows labeling of ZIDs, I doubt that this is really done by end-users. Looking into the encountered security indicators and handling of handshake failures, I would encourage a more precise definition of how to handle error cases. This could be done by state machines or a listing of possible error cases similar to Table 3 in our paper. Finally, while we propose the usage of sentences for SAS, this only prolongs ZRTP’s lifetime until speech synthesis catches up. In the next years, we will see new synthesis methods that are near to impossible to distinguish from real human voices (see our related work).


All gory details of our test cases and a proposed best practices can be found in the preprint of our publication accepted for PETS 2017:


If you have more question, please contact Dominik Schürmann.