Introduction

The GNU Telephony Secure Calling initiative is intended to make passive
voice communication intercept a thing of the past, and thereby help both
national governments, and private corporations, which at present seem unable to
comply with their obligations to the public that they serve and with the law of
the land. While it is true that technological means for mass communication
intercept has grown with incremental improvements in communication technology,
the means to apply and use techniques to counter these abuses on a large scale
have also grown. By making “secure by design”, security
capabilities simple to embed, and by enabling the largest possible
participation in developing such solutions through free software, we hope to
break down those remaining barriers that prevent secure voice telephony from
being widely deployed.

Goals

To empower people, individually and collectively, to communicate and
collaborate privately and securely in real-time worldwide.

To establish secure communications as the default communication
infrastructure.

To provide secure communication services universally on all computing
platforms.

Elements of Secure Calling

There are I perceive three elements to secure calling. The first and most
obvious is securing the voice (bearer channel) itself. To achieve this, we
initially offer GNU ccRTP 1.5.0. GNU ccRTP now offers basic voice encryption
capability using the GNU gcrypt library and implements the Secure RTP profile
as per RFC 3711.

In addition to SRTP capabilities starting in GNU ccRTP 1.5, we have an
expansion library, libzrtpcpp. This is a library that extends ccRTP with direct
support for the ZRTP protocol.
The following
document gives some background information about ZRTP. Have a look at Phil Zimmermann's
Zfone project to get
first-hand information from the originator of ZRTP. While Zfone operates as an
external service (bump-in-the-wire) that needs to listen and intercept the
signalling protocol (SIP) of the clients in order to apply ZRTP and SRTP, GNU
ZRTP (libzrtpcpp) can be used to create softphone clients and VOIP servers that
natively speak ZRTP without needing an external service. Programs that use GNU
ZRTP are not required to use a signalling protocol to use ZRTP and to set up a
secure RTP session. The first example is the Twinkle softphone client, starting with
release 0.9.0.

One of the reason's for using ZRTP in particular is its management and use
of self-generated keys, rather than requiring certificate authorities. This
also means that the user is not required to obtain or manage secret keys or
certificates nor has any knowledge of the underlying communications protocols.
Hence, neither the user, nor an issuing authority, offers any ability to obtain
backdoors into or the means to compromise ZRTP sessions.

While securing the voice channel is fundamental to privacy, it is not in
itself sufficient to assure true privacy from passive observance. As we have
learned, given the hunger for data-mining that some national governments and
private corporations have, it is equally important to secure the signalling and
call detail information from external observation.

With GNU oSIP 2 and libeXosip 2, we have some capability to apply
SIP over TCP with TLS. This is sufficient to secure session information from
casual observance. However, it does not obscure the IP addresses of the
physical endpoints which are communicating. To achieve this, we are working on
forward publishing SIP contact information into anonymous proxies. However,
there is no requirement that SIP must be used as the signalling protocol in
conjunction with GNU ccRTP or GNU ZRTP, so we may also look at or introduce
other signalling/session protocols as well in the future for this purpose.

Our intent is to apply standard-compliant protocols and methods where they
exist and are usable to offer secure calling. Where existing protocols need to
be extended, we will offer and document such extensions. Where new and emerging
protocols exist for secure calling, such as ZRTP, we will make use of those as
well. Our goal is to have a broad GPL-licensed free software framework for
development of secure calling services that cover the full range of
possibilities (hence, for example, both SRTP and ZRTP), rather than narrowly
implementing a single variation.

Issues and Limitations

When we speak of securing VOIP from passive intercept through encryption, we
are of course presuming that, while there is the possibility that there exists
undiscovered and undisclosed shortcuts in some of the core algorithms, even if
true, the computational cost and time to decode a communication session would
remain so great that it would remain only of value to attempt against very
select targets.

Nor does encrypted voice in any way interfere with legitimate law
enforcement tasks where specific individuals are targeted for lawful
investigation, presumably with judicially sought warrants. However, the means
to do intercept would require on-premise bugging rather than external passive
intercept. The cost to use such methods for the very small number of lawful
investigations is indeed very small compared both to the cost of deploying
passive intercept capabilities everywhere, and especially compared to the
potential loss of everyone's right to free expression and free association
experienced by the deceptive deployment of police-state-inspired mass
intercept.

However, while encrypting voice has generally been understood for a long
time, securing connection information is a different problem. We can apply TLS
to existing session protocols so that they do not reveal secondary information,
and this helps reduce the visible communication profile even further. However,
the final task of obscuring who communicated with whom by IP endpoint address
is much harder to achieve.

One answer is the use of anonymous proxies. This helps in that neither party
directly communicates, and each session is through a different proxy. Anonymous
proxies have been used successfully in projects like Tor because they have
multiple stages. This cannot be done, at least in the same way, in voice
communication because of latency. Hence we are reduced to single step
proxies.

In the worst case in a single step anonymous proxy, an external party with
sufficient resources to observe broadly may well successfully observe that
person at IP address A communicated with proxy at IP address X starting at a
fixed and known time, and that proxy X formed a connection to someone at IP
address B at roughly the same time. Having very many users on each proxy will
obscure this, especially in conjunction with doing things with false sessions,
randomly delayed startup, and separate shutdown with false traffic. However,
again this requires proxies each capable of hosting a very large number of
users, and there being sufficient usage to assure many of these proxies are
filled to near capacity.

Project Status

Phase 1 - The Stack

Securing voice channels with Secure RTP profile and ZRTP support. Introduced
with GNU ccRTP 1.5 and improved since then. Complete, initially released
October 1, 2006, along with the release by Michel de Boer of a
Secure-Call-capable Twinkle softphone client. Current releases are maintained
compatible with the latest release of Zfone and the latest IETF “Media Path Key
Agreement for Secure RTP” drafts. Recently, a new Java implementation
of the ZRTP stack has been created, and successfully integrated into the
Java-based SIP Communicator client.
Recent downloads of SIP Communicator come with ZRTP4J support.

Phase 2 - The Switch

Many IP-PBX systems (such as Asterisk) establish media sessions with the
endpoints (operating as a B2BUA),
and thereby require both media to pass through the server itself, and to do so
in decrypted form. This is essentially a “forced”
man-in-the-middle, as well as adding latency and in my opinion disadvantaging
the existing peer media/network scalable capabilities of SIP/RTP softphone
devices.

GNU SIP Witch, initially released in 2008, is offered as a model for a
secure VOIP telephone switch that supports TLS over SIP and that can
interconnect secure endpoints without intercepting media, thereby assuring
privacy without compromising security. Furthermore, GNU SIP Witch offers a
“forward plugin” and calling model, whereby one can support secure
media interconnection directly between ZRTP-capable endpoints while also
operating in conjunction with, and access to, an insecure calling domain
managed by a conventional B2BUA-based IP-PBX. This is accomplished by
cross-registering secure user agents with the insecure IP-PBX and routing
insecure destinations to it.

Phase 3 - Domain Calling

Moving GNU SIP Witch to the desktop, and consolidating integration with a
local SIP User Agent, it has become possible to offer a bottom-up participatory
network that uses published protocols and allows people to directly communicate
anywhere using only DNS lookup of SIP URI's. This offers a free software
alternative to Skype, which depends both on source secret binary protocol
libraries and a central service provider, either of which can be compromised.
This is called “Domain Calling”, and is being introduced as a
feature in Ubuntu Lucid and Fedora F13 GNU/Linux.

Phase 4 - Worldwide Anonymous Calling

Anonymous calling proxy; Bayonne Voice Relay, with forward publishing of SIP
contact information, and the ability to search and cache contact points. The
goal is to allow truly anonymous and untraceable calling without revealing even
basic signalling meta-data. In Design.

Todo and User Comments

Maybe more GUI elements for SAS key management, fingerprints for social key
exchange?

Twinkle already supports GUI elements and actions to display and verify
the Short Authentication String (SAS). ZRTP uses SAS to to enable users to
detect and thus avoid Man-in-the-Middle (MitM) attacks. SAS is not a key but
an authentication string that users read aloud and compare over the SRTP
audio session.

Twinkle support for TLS-secured SIP (TCP SIP with TLS), and certificates for
traditional SRTP-related operations?