A Tour Through Zfone

This review of Zfone is intended for readers who would like to take a look at Zfone but are too busy to test it at the moment. The visual aids used in this article may also help readers to grasp some of the concepts (such as key continuity) behind Zfone. The complete specification of ZRTP, the key exchange protocol used by Zfone, can be found in this Internet draft. Zfone is available for Windows XP, Mac OS X and Linux, and can be downloaded for free from its official homepage.


Installing Zfone should take only a couple of minutes. You may encounter a number of warning messages presented by Windows XP along the way, but they can be ignored. Despite its name, Zfone is not a stand-alone softphone, but rather, a “bump in the cord” (as described in its homepage) that encrypts RTP packets generated by a softphone. There is not much you need to do to get Zfone up and running, assuming that your softphone works properly prior to the Zfone installation and that Zfone is launched before the softphone.

After installation, Zfone would automatically launch itself and sit in the system tray. Zfone also installs a ZRTP driver that can be verified by opening the property menu of any LAN card installed in the system. Zfone also automatically checks with a designated server to see if there is any new update available. Since I used an isolated network as my test bed, Zfone complained “Can’t connect to libzrtp server” at the bottom of the GUI.


Figure 1: Zfone control panel

The Zfone GUI looks very clean (Figure 1). In fact, what’s conspicuous about the GUI is its lack of any configuration menu. Basically there are only three things you can do when the system is idle: check for new version, read help and exit.

Experiment Setup

In order to experiment Zfone all by myself, I set up a very simple test bed as shown in Figure 2. I used a SIP server implemented by Brekeke, and X-Lite to work with Zfone on hosts dubbed Alice and Bob. I also set up a host dubbed Eve to sniff packets using Ethereal. All four machines are connected using a non-switching hub.


Figure 2: Test bed

Zfone in Action

One revolutionary feature of Zfone is that its key exchange is performed over RTP packet streams without any reliance on signaling and PKI. This approach allows users to encrypt their phone conversation in a pure peer-to-peer manner without any support from their VoIP service providers. It also allows Zfone to easily work with existing softphones and solves interoperability issues one may encounter with cross-carrier authentication.

When Alice calls Bob, the control panel of Zfone would pop up automatically on both ends. It seems that Zfone detects SIP signaling packets used to set up a call. Initially, all RTP packets are exchanged in plaintext and the Zfone GUI would display “not secure” in red color. Zfone uses ephemeral Diffie-Hellman as its key exchange algorithm. The time it takes to complete a ZRTP handshake in which DH values are exchanged seems to vary (ranging from 1 to 20 seconds when I tested it with different softphones). After a successful handshake, all RTP packets are encrypted as SRTP and the GUI would display “secure” in green color. Figure 3 provides an overview.


Figure 3: ZRTP Overview

Figure 4 shows packets captured by Eve with Ethereal. To extract ZRTP packets within the RTP stream, I looked for packets with “Payload type = comfort noise”. The packets are exchanged as described in the Internet draft.


Figure 4: Packet capture (click to enlarge)

Once Zfone is activated, there are a few more things you can do with the GUI. You can turn off encryption by pressing “Go Clear” and turn it on again by pressing “Go Secure”. You can also edit the name of the other party. There is also a little check box labeled “verified”, which will be explained later. From an RTP steam captured by the host Eve, I tried to decode it into an audio file using Ethereal and confirmed that the conversation between Alice and Bob was encrypted (nothing but loud static noise).

Man-in-the-middle Attack

Another important feature of Zfone is its ability to detect man-in-the-middle (MITM) attacks, even though it does not use a PKI. First, let’s have a brief review of the Diffie-Hellman algorithm in Figure 5.


Figure 5: Diffie-Hellman

In short, Alice and Bob have to generate A and B respectively and exchange them in order to come up with a shared secret SAB to be used to create a session key for encryption. A MITM attack is possible (Figure 6) if Eve can somehow intercept packet that carries the value of B from Bob, replace it with E that she generated by herself and send it to Alice. If Alice is not aware that the packet from Bob has been tampered with, she would accept E and create a secret value SAE, believing that the value is shared with Bob while in fact is shared with Eve. If Eve is successful in deceiving Bob in the same manner, she can relay all packets exchanged between Alice and Bob and wiretap the conversation. The conversation appears encrypted to both Alice and Bob, but is in fact decrypted (and encrypted again) by Eve in the middle.


Figure 6: A MITM Attack

To prevent this from happening, Alice has to confirm with Bob that the value she received is in fact generated by Bob, and vice versa. Fortunately, the nature of VoIP provides an easy way to do it. Since they are already on the phone, Alice can simply read aloud a hash (short authentication string or SAS) of the value that she think she got from Bob and verify it with him. Bob then would do just the same. If there is a mismatch, Alice and Bob can be pretty sure that someone else is listening. Verification in such verbal and analog manner is very effective since it is extremely difficult for Eve to replace Alice’s and Bob’s voices in real time.

To make the GUI even cleaner, Zfone hashes both A and B together and presents only one SAS to the user (instead of hashing them individually and presents two SAS, as in the early version). This is somewhat simplified in Figure 7.


Figure 7: Short authentication string

Key Continuity

Although comparing SAS verbally at the beginning of each call can be fun at first, users may start to find it troublesome after a few calls. To combat with laziness, Zfone adds a convenient feature called key continuity. Preferably, users should verify SAS when they call someone for the first time. The shared session key used in that first call is then cached on both hosts. Next time when Alice calls Bob again (or the other way), the new session key would be a combination of the newly calculated shared secret and the session key used in the previous call. This neat trick frees both users the trouble to verify SAS in every call. The concept is simplified in Figure 8.


Figure 8: Key continuity

The following scenario illustrates an attempted MITM attack on this scheme (Figure 9). Eve steps in after Alice has called Bob twice without being intercepted. Eve is able to create a new shared secret with Alice. However, in order to encrypt RTP, Eve has to combine this shared secret with the session key used by Alice and Bob in the previous call. Since Eve does not have it, Zfone would warn Alice that something is wrong as shown in Figure 10.


Figure 9: Another MITM attack


Figure 10: Warning Message

Despite the warning message, Zfone still allows both parties to speak over an encrypted channel. This is because Bob may someday actually lose his cache of session key (due to an OS problem etc) and make him look suspicious. If both parties verify the SAS on the spot and check the box labeled “verified”, they are able to establish key continuity from scratch again.

What happens if Alice and Bob forget to verify SAS in the first call? Let’s say that all of a sudden they remember to do so in the 11th call. If both SAS match, they can rest assured that all previous 10 calls were safe. However, if there is a mismatch (and they had never seen any warning message as in Figure 11), it implies that someone has been wiretapping their conversation since the first call and has cached all previous secrets shared with Alice and with Bob separately. In other words, SAS displayed to Alice and Bob had never matched and the anomaly had gone unnoticed in all previous calls.

In order to manage cached secrets shared with various parties, each Zfone is randomly assigned a ZID at installation. Every time Alice finishes a call session with Bob, the shared secret associated with Bob’s ZID is cached in Alice’s machine, and vice versa. Just for the fun of it, I installed Zfone into a VMware virtual machine, created a clone of it and had one call the other. In other words, I tried to let two Zfones with identical ZIDs communicate with each other. As expected, both Zfones generated error dialogs as shown in Figure 11. In the real world, I think such collision is not likely to happen since each ZID has 96 bits and is randomly generated. However, there seems to be no mechanism to guarantee that each ZID is in indeed globally unique.


Figure 11: ZID Error

Final Remarks

Zfone is very user-friendly since it hides most of the encryption mechanism from its users. Its independence from PKI and signaling makes the technology very accessible to individuals. Zfone, being a “bump in the cord”, also allows its users to keep their favorite SIP softphones without switching to an unfamiliar one. Moreover, because only the end users are involved in the key management, the service provider does not have access to any of the keys. Eavesdropping on Zfone users seems extremely difficult as the attacker would have to be present since the first call, able to forge verbal SAS verification in real time, and preferably, able to imitate voices.

I hope this article has been helpful to you. If you have any question, any insight, or any correction to make to this article, please feel free to leave your comments.

My homepage is here.

13 thoughts on “A Tour Through Zfone

  1. Dustin D. Trammell

    Did you happen to test to see if re-installing Zfone on your second VMware system preserved the original installation’s ZID, or would that be an effective way of creating a new ZID for the endpoint, in the (as you mention) very inprobable chance that you end up with a duplicate ZID?

  2. Eric Y. Chen Post author

    I did, after reading your comment. I uninstalled and reinstalled Zfone on the second VMware system, but I still got the same error messages. And if I call from an entirely different system A to the first system B and then to the second system (clone) C , I would get a warning message saying that the shared secret has not been cached. In other words, from A’s point of view, B and C are identical. It seems that we cannot generate a new ZID by simply reinstalling Zfone.

  3. Wence Van der Meersch

    I wonder what it will do when you install zfone on a windows machine running internet connection sharing (or any other kind of NAT gateway software for that matter) and use a SIP phone through it’s NAT… Would it attempt (and succeed?) in encrypting the RTP packets? Since technically the RTP packets will originate from the outside interface using the interface’s IP.

  4. Eric Y. Chen Post author

    I haven’t really tried it yet, but I think if the SIP phone is able to overcome its NAT barrier prior to the Zfone installation, Zfone should work in most cases. However, if the SIP phone does unusual things such as sending RTP/TCP instead of RTP/UDP to solve the NAT traversal problem, Zfone would not work since it currently looks at only UDP packets, as stated in its official homepage http://www.philzimmermann.com/EN/zfone/bugs.html.

  5. Mark Trifiro

    Great tour of Zfone!

    Is the upshot of the ZID issue that each user must retrieve their original copy of Zfone from Zfone’s download site (that is, I can’t share my copy of the installation software with colleagues)? Or have I misunderstood the issue? I recall that retrieving the installation software originally required waiting on an email from Zfone (don’t remember the details now).


  6. Eric Y. Chen Post author

    ZID is randomly generated when you install Zfone, not when you download it. So even if you share your copy of installation file with your colleagues, they should all get different ZIDs.

    However, I did something unusual (really just for the fun of it) by installing Zfone to a VMware virtual machine (Windows XP) and creating a clone of that virtual machine. This way, I got two virtual machines with an identical ZID and got error messages in Figure 11 when I let one call the other.

    Although I think this scenario is unlikely to occur in the real world, Dustin (the first commentator) asked me if I can reset the ZID by reinstalling Zfone. I tried but it seems that once a ZID is generated, it is stored somewhere even after Zfone is uninstalled. When I reinstalled Zfone, the old ZID somehow resurrected (you can verify your ZID in “zfone.log” in the Zfone directory). I don’t know how we can reset the ZID if we do end up with a duplicate ZID.

  7. Pingback: VOIP IP Telephony

  8. Pingback: Voice of VOIPSA » Blog Archive » Talk to the Hand

  9. Zoran

    Its time to explain for people who are not computer experts.
    Thank you Phill, and thank you because wrote PGP.

  10. Michel de Geofroy

    Hi I have uninstalled zfone from osx but my firewall still detects zfone trying to connect with internet … where are the zfone files located ?

Comments are closed.