End-to-End Encrypting Android Phone Calls
I. Burns, K. Gabert, and J. Zheng
Department of Computer Science and Engineering, New Mexico Institute of
Mining and Technology, Socorro, NM, USA
iburns@cs.nmt.edu, kasimir@cs.nmt.edu, zheng@nmt.edu
Abstract Cellular phones are regularly used to discuss
sensitive personal and business information. However, little
attention is given to the security of these conversations, which
can be particularly important for international businessmen.
Current encrypted phone call solutions for this problem
require either an Internet connection for VOIP or a spe-
cialized handset. In this paper, we propose an architecture to
encrypt phone calls as an addition to the Android smartphone
operating system. The proposed architecture utilizes TLSPGP
to provide strong encryption with a peer-to-peer web of trust.
Keywords: Android operating system, mobile computing, com-
puter security, encrypted communications.
1. Introduction
As cell phones are becoming more common, they are
being used to communicate numerous types of sensitive
information: personal banking details, business secrets, and
personal health information are a few examples. Keeping
this information private is extremely important. In the past,
encrypted communications have only been accessible to those
with vast resources. As technology has moved forward, the
ability to communicate with high-level encryption has be-
come a reality for more and more people. Currently, there are
no means of having encrypted communications in consumer
cell phones which cannot be monitored by the telephone
service provider.
To compound this issue, numerous flaws have been pre-
sented in the current encryption used by the cellular telephone
providers. These flaws allow any individual with a computer
to quickly and easily monitor all cell-phone communications
near them [1].
This paper presents a method for adding an encrypted com-
munications stack to Android. Android-based smartphones
are becoming more and more common [2] and present a
unique opportunity to allow individuals and organizations
without vast resources to communicate using encrypted com-
munication.
Adding encryption into Android is not a new idea. Red-
Phone, from Whispersys [3], is a great example of re-
cent Android-based products which provide encrypted phone
calls. However, the current solutions, including RedPhone,
rely on identity-based encryption. Identity-based encryption
is not peer-to-peer and requires a trusted central server to
manage the security of the communications. If this trusted
server is the cell phone provider, then the communications
will still not be private in our model.
These solutions also are not implemented in Android
itself [4]. Instead, all of the current projects start from user
space, as an application available for Android, and add
encryption there. Starting from user space means that if
Android is in control of another entity, such as the phone
network provider, then these solutions will not provide any
protection [5]. Having Android in control of another entity
is a reasonable assumption since most phone providers will
install a custom Android on each phone sold. Also, these
solutions are vulnerable to user space malicious software
(malware) [4].
The rest of this paper is organized as follows. In next
section, we introduce some background information on se-
curity problems during an Andriod phone call, limitations of
existing solutions and related security and privacy protocols.
The Andriod radio subsystem is described in Section III. In
Section IV, we present our solution for end-to-end encrypting
Andriod phone calls and discuss some difficulties faced in
implementation. Finally conclusions are drawn in Section V.
2. Background
2.1 Security Problems during an Andriod
Phone Call
2.1.1 Security Problems in the Android Operating System
The Android operating system takes a pervasive and multi-
faceted approach to security, incorporating mechanisms from
Linux as well as introducing its own security features and
environment. These features include POSIX security mecha-
nisms, sandboxing through the Dalvik JVM, and restricted
tasks that require user consent at application install-time.
Finally, Android devices are distributed with the user (and
any installed applications) limited to a non-administrative
account (the user doesnt have root). Ideally, this prevents
users from allowing software to make deep changes to the
operating system and therefore limits the abilities of malware.
Even with this extensive security architecture, Android has
a very large number of security-related exploits, including
exploits granting root permissions [6]. The problem is exac-
erbated by nature of Androids distribution. Although Google
is in charge of Androids creation, it is distributed by a
multitude of phone manufacturers and wireless carriers, who
each must provide users with a patch after Google creates it.
This means the lead time between the discovery of an exploit
and users receiving a fix can be very long, even if Google
responds rapidly. Additionally, the vendors often abandon
the patching of phones relatively quickly, leaving some users
very vulnerable [6].
2.1.2 Security Problems in Cellular Networks
A secure phone does little to preserve privacy if it uses
an insecure network. In an effort to preserve privacy, cellular
radio standards such as GSM include encryption. Unfortu-
nately, these encryption schemes have a long history of being
inadequate for dependable privacy protection [7].
The most modern ciphers available for GSM networks are
Kasumi-based encryption schemes (A5/3 for GSM, UEA1
for UMTS, GEA3 for GPRS [8]) are currently unbroken, but
appear somewhat vulnerable. A practical time attack against
Kasumi exists [9], but does not appear to be workable on
the overall encryption schemes employed by GSM-based
networks [8].
2.1.3 Security Problems in Telephone Networks
Outside of the handset-to-tower link, cellular networks
revert to unencrypted traditional phone networks. If the
infrastructure provider is trusted, this can be a minor problem.
However, when the infrastructure provider is not trusted (such
as during international business travel), this lack of security
through the phone network can be a problem. Even when the
nation controlling the phone network is trusted, the network
may not be trustworthy.
In 2005, Vodafone Greece disclosed an attack that com-
promised two central office switches. The compromised
switches were used to unlawfully wiretap 100 high-level
officials in the Greek public and private sectors, including
the Prime Minister and his wife. The attacking rootkit was
not discovered until a software malfunction caused a deep
investigation into the switch software [10].
In Italy, both official and unofficial phone intercepts have
created numerous media scandals and resulted in arrests of
high-profile officials. These scandals have spurred demand
for end-to-end encryption for phones used to discuss sensitive
matters there [11].
The market research firm ABI states that 79% of com-
panies use mobile phones for communications that would be
damaging if intercepted, and other studies have indicated that
the average cost of significant data loss is up to $1.3 million
per incident [12]. End-to-end encryption is the only way to
fully address interception concerns [12].
2.2 Limitations of Existing Solutions
Encryption has been added to Android phone calls in the
past. The most notable project to add encryption is a phone
system denoted RedPhone, by Whispersys [3]. RedPhone is
a product which provides identity based encryption in a user-
land application using Voice over Internet Protocol (VoIP).
While it does support protection against eavesdropping and
provides authentication for the communicating party, it is
limited. First, it requires a trusted third party which will
handle the encryption keys. This becomes a large problem if
there is no third party which should be trusted. The second
reason that RedPhone does not satisfy the conditions is
because it is a user-space application. This means it is unable
to provide any security assurances about the underlying OS,
and it is limited to VOIP as opposed to phone network-based
calls.
2.3 Related Security and Privacy Protocols
2.3.1 Pretty Good Privacy (PGP)
PGP is a form of public key cryptography originally de-
veloped for use in email [13]. The OpenPGP standard allows
the implementation of various asymmetric and symmetric
algorithms, including RSA and AES. PGP is structured
around a message-packet format, with encryption for privacy
and digital signatures for integrity [13].
Where PGP is special among modern encryption schemes
is its trust model, called the Web of Trust. At its core, PGP
relies of the user to determine whether they trust the identity
of a key. The Web of Trust model is design to aid this
process, without introducing a central authority that can be
compromised. The concept of trust" is deliberately vague so
a user can determine what it means for them. An untrusted
key still provides privacy, but is unable to provide identity
verification [14].
2.3.2 Transport Layer Security (TLS)
TLS is a very popular cryptographic protocol in
widespread use for numerous Internet applications. The most
widely known of which is HTTPS. It provides symmetric
key exchange and an integrity check using a keyed Message
Authentication Code [15].
In traditional TLS, a trusted Certificate Authority verifies
the identities of key holders. However, there have been sev-
eral recent high profile attacks against the certificate authority
system [16]. Once a certificate authority is compromised the
entire system breaks down.
It is possible to use PGP instead of a certificate authority
structure in the TLS Handshake Protocol. RFC 6091 imple-
ments such a standard [17]. It allows a Web of Trust au-
thentication model to be used while providing the commonly
available and well studied TLS protocols.
3. Android System Architecture
In this section we will discuss the Android radio sub-
system and how it interacts with Android as a whole. The
information in this section was gathered using the Ice Cream
Sandwich source code.
 Android is composed of five major components: Applica-
tions, Application Framework, Libraries, Android Runtime,
and the Linux Kernel [18]. The cellular call system is imple-
mented in Android as the Telephony Manager component, a
subcomponent of the Application Framework.
3.1 Android Telephony
The Telephony Manager component is a platform-
dependent component, meaning that for each platform (or
different mobile phone / tablet) parts of it will have to be
adjusted to work with the potentially proprietary Vendor
Radio Interface Layer (RIL). Figure 1 contains a graphical
representation of the various blocks that compose the tele-
phony component.
The RIL interactions start right above the
baseband, which is the firmware specific to the
platform. The file android/hardware/ril/
reference-ril/reference-ril.c contains
functions which are the closest Android gets to interacting
with the GSM network. This file interfaces with the baseband
to perform various GSM actions such as dialing numbers,
hanging up calls, accepting calls, and so on. The RIL library
performs callbacks into this file. Those callbacks take the
form
onRequest ( i n t request , void * data ,
s i z e _ t d a t a l e n , RIL_Token t )
where request contains the action of the request,
and RIL_Token allows for stateful operations. On
the other end of the spectrum, the Android package
com.android.internal.telephony contains vari-
ous classes dealing with controlling the phone. Similar to
the RIL commands, the commands exposed through these
objects control the phone state, such as acceptCall(),
rejectCall(), clearDisconnected(), etc.
3.2 Android Media
The Media components of the Application Framework as
responsible for Androids multimedia support. The audio
portion of this framework is of interest for phone calls.
The basic unit of Android audio is the stream.
Streams can be input or output to/from any audio
device and application. The routing of these streams
to various available microphones and speakers is han-
dled by AudioFlinger android/frameworks/base/
services/audioflinger. Presumably to increase plat-
form independence, AudioFlinger does little direct rout-
ing by default (although it retains the capability to route
arbitrarily). Instead, it sets a system-wide routing mode
such as MODE_IN_CALL, or MODE_RINGTONE. This
routing mode is then passed down into vendor-specific
code supporting the media system through the inter-
face defined in android/hardware/libhardware/
include/hardware/audio.h. The vendor code is then
ultimately responsible for determining where the audio from
a stream (such as the call audio stream) ends up being played.
AudioFlinger does not provide a user-friendly
interface at the level Android applications are
expected to function at. This interface is provided
by android.media.AudioSystem, which
bridges from the Java-based Application Framework
to the native-code-based media system using
android/frameworks/base/media/libmedia.
The AudioSystem class provides constants for generic
devices and streams, such as DEVICE_OUT_EARPIECE
and STREAM_VOICE_CALL It also provides methods
meaningful to applications that control the media system,
such as muteMicrophone or setRingerMode.
Applications
Phone
Phone Util
Audio System
RIL Audio Flinger
Vendor RIL Lib Hardware
Fig. 1: The various blocks of the telephony component used
in placing and communicating during a phone call. The blue
outlined components are found in the Application Framework
layer of Android, the green outlined components are found
in the Library layer, and the black outlined components are
found in the Vender layer.
3.3 Phone Calls in Android
Phone calls in Android are the end result of a collaboration
between the telephony and media frameworks. They begin
when the user interacts with the phone application. When the
user has entered the number to dial and has placed the phone
call, the phone application will issue a request for a phone
call with the specified number. This request will propagate
down into the vendor RIL. The vendor RIL will then send the
request directly to the baseband on the phone. If the phone
call request was issued correctly then an acknowledgment of
the phone call will immediately be issued.
The baseband will then make the appropriate cell network
request. Upon success, it will begin transmitting from the
phone speaker and outputting the received voice transmis-
sion directly to the speaker. Finally, once a connection is
established, the RIL in Android will receive an onRequest
callback and will update the phone application interface
appropriately. This interaction can be seen in Figure 2.
Phone App
(1) (4)
(2) (3)
Telephony Audio System
RIL Audio Flinger
Vendor RIL Lib Hardware
baseband speaker / mic
Fig. 2: The structure of placing a phone call in Android.
Even though the call is placed in Android, the actual digital
voice stream is set up by the low-level code provided by
the vendor. (1): Placing a call. (2): Call in progress. (3): Set
mode MODE_IN_CALL. (4): Returning back, displaying call
in progress.
Once the call is established, the telephony system puts the
phones media system into MODE_IN_CALL. By default, this
causes the vendors media code to do something reasonable,
like routing the call audio stream STREAM_VOICE_CALL.
If a bluetooth or wired headset is connected, the vendors
code handles the change in audio routing.
Essentially, there is a dumb phone (as compared to a
smart phone) running alongside Android in an Android
smart phone. Android does not actually perform a phone
call itself. Instead, it effectively dials the number through
the baseband (dumb phone) and then the baseband will
alert Android whenever it is in a phone call. This leaves all
of the implementation of the phone components itself up to
baseband and outside of the reach of Android.
Such an architecture for sending and receiving calls
complicates the matter of adding encryption. Most of the
decision-making components lie in vendor code instead of the
Android system. Any encryption scheme must work within
the context of current decisions, routing around and through
existing, proprietary code.
4. End-to-End Encrypting Phone Calls in
Android
This section contains our proposed solution to this prob-
lem. First, we present the recommended encryption scheme
for this project. Second, we will discuss where this encryption
should be placed in the existing Android telephony stack
to provide encrypted phone calls to users while preserving
the integrity of current Android systems and applications.
Finally, some difficulties in implementation the solution are
discussed.
4.1 Encryption Scheme
To ensure privacy in the event of a malicious cellular
network provider, we propose using a combination of PGP
and an AES stream cipher. PGP provides a widely-used Web
of Trust which will help authenticate users.
This implementation will follow RFC 6091 [17] which
describes how to adjust the TLS Handshake Protocol to
use PGP keys. The TLS protocol is a widely-implemented
and well trusted protocol providing perfect forward secrecy.
The GNU TLS implementation of the TLS protocol contains
extensions to enabled the use of PGP keys. However, it does
not implement any trust model for these PGP keys [19].
We performed some benchmarking to determine if a target
Android phone could support AES at a speed fast enough for
the purpose of encrypting phone calls. For these benchmarks,
we used a Samsung Nexus S running the Android Open
Source Project version of Ice Cream Sandwich (Android 4.0).
This phone uses a 1 GHz ARM Cortex A8 based processor,
and we believe it represents a fairly typical current Android
device.
We measured performance of AES using 128-bit keys, no
padding, and the cipher in ECB mode. We compare perfor-
mance of the Java-based AES implementation (managed")
using the default provider for javax.crypto in Android and
the C implementation of AES in the nettle library (native").
The nettle library implements a variety of cryptography
algorithms which is also used by GNU TLS. We measured the
time required (as reported by the system clock) to encrypt 10
megabytes of random data. The results were then reported in
megabytes encrypted per second. Each test was repeated 10
times. The first execution was discarded in which managed
code was slower than subsequent executions.
We found the managed implementation of AES produced
an average encryption rate of about 3.66 MB/s with a
standard deviation of 0.02 and the native implementation
produced an average rate of 8.24 MB/s with a standard
deviation of 0.35. Either of these rates is completely sufficient
for our purposes, where we anticipate the requirement of
encrypting Andriod phone calls to be less than 100 kilobytes
per second.
4.2 Details of Implementation
Implementation of the proposed solution in Android re-
quires a few changes to the operating system. These changes
form 3 new subsystems: the Cryptographic Control Module
(CCM), the Cryptographic Module (CM), and the Crypto-
graphic Interface (CI). These modules create a tweaked media
stack for encrypted calls, and add a few additional libraries to
support their functionality. Figure 3 contains an overview of
the modules interactions during a phone call process. This
section will detail the changes required to Android in order
to realize these modules.
The Cryptographic Module will actually perform the en-
cryption on the audio stream. It will be added at the system
Library level. This encryption module will act as a virtual
audio input/output while performing the encryption of the
phone call. Then the module will route the decrypted plain-
text audio to the systems original call audio destination
which could be the phones ear piece or a peripheral hands-
free device. The incoming plaintext from the microphone will
similarly be encrypted before being passed through to the
baseband system.
The Cryptographic Module requires a library supporting
TLSPGP protocol functionality must be added at the system
Library level. We propose the use of GNU TLS for this
purpose. To support the implementation of the web of trust,
PGP will also be added to the system libraries. Java Native
Interface (JNI) bindings will then be added for the relevant
portions of each of these libraries to allow application-level
code to interact with the call cryptography system.
The Cryptographic Control Module will consist primarily
of adjustments to the AudioSystem and other Application
Framework components of the media and telephony systems.
These adjustments will allow the redirection of the call audio
stream to the Cryptographic Module. The setParameters
method of the AudioSystem class enables the CCM to
redirect the call audio stream using high-level constructs
understood at the application layer. That is, using constructs
such as the CALL_AUDIO_STREAM constant instead of
direct references to audio stream data.
The Cryptographic Interface exposes encrypted call and
key management functionality to the user. It consists of
modified Phone and Contacts apps. The Phone apps will
expose enable/disable encryption functionality when a public
key is available, provide indications that a secure or insecure
call is in progress, and allow the user to place secure and
insecure phone calls. The Contacts app will expose the web
of trust functionality and key management, by providing keys
associated with the users contacts.
4.3 Implementation Difficulties
The implementation of this architecture faces a variety
of challenges. The first is porting the required libraries.
When they are fully implemented in C, this process is
typically straightforward. However, it is difficult to predict
if or where assembly code will be encountered for improved
performance. This code is typically targeted at x86 machines,
so switching to ARM-based Android devices can be challeng-
ing.
The implementation also depends on data being sent
through the phone network in a manner that reproduces
the original bit-for-bit. If lossy compression is employed
below the encryption, the data will be irrecoverable. Any
compression performed by the phone network needs to be
evaluated. If it is performed in the RIL on the device,
access to the RILs code will be required for successful
implementation.
In general, the architecture of the Android system has
the potential to get in the way. In addition to compression
concerns, odd behavior of vendor code may derail implemen-
tation. Correct permissions for all actions need to be located
and assigned, and there is potential for unforeseen difficulties
in implementation from the structure of the Android system.
The latency of the phone network provides another un-
known. With cellular, wired, and international phone net-
works involved, there is the potential for significant latency
in the transmission system. We expect that TLS will be able
to tolerate whatever latency is present because of its common
use with HTTP. A phone call, however, can be viewed as a
real-time application where the encryption and transmission
of data must be mroe timely than web browsing. The length
of the handshake is also a concern, especially when the end-
to-end latency of the phone network is high. In the worst
case, we would expect that the proposed solution will suffer
from latency less than satellite phones, which is tolerable for
most users.
Finally, the battery life of the phone making the encrypted
phone calls is a concern. The encryption process will result
in higher CPU utilization and power consumption during a
call. The exact effect of this increased power consumption
on battery life needs to be investigated in future. In general,
somewhat reduced battery life is a necessary trade-off for
secure calls.
Phone App CI
(1) (4)
(2) (3)
Telephony Audio System
CCM
RIL Audio Flinger
Vendor RIL Lib Hardware
baseband speaker / mic
CM
Fig. 3: The structure of placing an encrypted phone call in
Android. In this structure, the phone call will have its voice
routed through the encryption module in the Library layer.
5. Conclusion
This implementation will satisfy the conditions required
to prevent the described adversary model. The encryption
will be triggered when a GSM phone call is placed and a
public key is known for the corresponding contact. Since
the encryption will be implemented in Android, it will be
resistant to user-land malware present on the phone. Since
the encryption is a modification to Android itself, users
will be motivated to place a custom OS on their phone
which will help prevent attacks from the cell phone service
provider. Finally, using a combination of PGP and AES will
be sufficient to ensure privacy of phone calls without relying
on a trusted central authority. Using TLS and PGP will help
prevent an implementation lock-in for the cryptography and
will allow multiple developers to independently implement
similar systems interacting on the same network.
Adding this encrypted radio module and modifying the
radio stack in Android will help provide privacy where
it is desperately needed. By implementing such a system,
attacks on core cellular or telephone infrastructure as well as
specific attacks against individuals will be mitigated. With
truly ubiquitous cell phone use, such a system becomes
exceedingly important.
[11] P. Kiefer, Phone taps in Italy spark a rush for cellular
encryption, 2007. [Online]. Available: https://www.nytimes.com/
2007/04/29/technology/29iht-encrypt30.1.5487929.html
[12] S. Bransfield-Garth, Mobile phone calls as a business risk, Network
Security, vol. 2010, no. 9, pp. 411, Sep. 2010. [Online]. Available:
http://linkinghub.elsevier.com/retrieve/pii/S1353485810701148
[13] J. Callas, L. Donnerhacke, H. Finney, D. Shaw, and R. Thayer,
OpenPGP Message Format, RFC, vol. 4880, 2007. [Online].
Available: https://tools.ietf.org/html/rfc4880
[14] M. Lucas, PGP and GPG. No Starch Press, Incorporated, 2006.
[15] T. Dierks and E. Rescorla, The Transport Layer Security
(TLS) Protocol, RFC, vol. 5246, 2011. [Online]. Available:
https://tools.ietf.org/html/rfc5246
[16] GlobalSign stops secure certificates after hack claim, 2011. [Online].
Available: http://www.bbc.co.uk/news/technology-14819257
[17] N. Mavrogiannopoulos and D. Gillmor, Using OpenPGP Keys for
Transport Layer Security (TLS) Authentication, RFC, vol. 6091,
2011. [Online]. Available: https://tools.ietf.org/html/rfc6091
[18] Google, Inc., Android Documentation,
http://developer.android.com/guide/.
[19] Free Software Foundation, Inc., Gnu TLS,
http://www.gnu.org/software/gnutls/.

References
[1] S. Gold, Cracking GSM, Network Security, vol. 2011, no. 4, pp.
1215, Apr. 2011. [Online]. Available: http://linkinghub.elsevier.com/
retrieve/pii/S1353485811700393
[2] Taylor Wimberly, Android growth outpaces iPhone,
http://androidandme.com/2009/08/news/android-growth-outpaces-
iphone/.
[3] Whisper Systems, Mobile Security for Android,
http://www.whispersys.com/.
[4] A. Shabtai, Y. Fledel, U. Kanonov, Y. Elovici, S. Dolev, and C. Glezer,
Google Android: A comprehensive security assessment, Security &
Privacy, IEEE, vol. 8, no. 2, pp. 3544, 2010. [Online]. Available:
http://ieeexplore.ieee.org/xpls/abs\_all.jsp?arnumber=5396322
[5] S. Trapp, M. Whlisch, and J. Schiller, Short Paper: Can Your
Phone Trust Your Friend Selection? in CCS 11: Proceedings
of the 18th ACM conference on Computer and communications
security, 2011. [Online]. Available: http://page.mi.fu-berlin.de/waehl/
papers/tws-spypt-11.pdf
[6] T. Vidas, D. Votipka, and N. Christin, All Your Droid Are
Belong To Us : A Survey of Current Android Attacks,
in USENIX Workshop on Offensive Technologies August 2011,
2011, pp. 110. [Online]. Available: http://mendeley.citizenlab.org/
VidasVotipkaChristin2011.pdf
[7] E. Barkan, E. Biham, and N. Keller, Instant Ciphertext-Only
Cryptanalysis of GSM Encrypted Communication, Journal of
Cryptology, vol. 21, no. 3, pp. 392429, 2008. [Online]. Available:
http://www.springerlink.com/index/ythkwv4gfq0fr5j4.pdf
[8] S. Bellec, The attack against Kasumi cannot
practically be used against the GSM, 2010.
[Online]. Available: http://pro.01net.com/editorial/511353/
the-attack-against-kasumi-cannot-practically-be-used-against-the-gsm/
[9] O. Dunkelman, N. Keller, and A. Shamir, A practical-time
attack on the A5/3 cryptosystem used in third generation GSM
telephony, in Proceedings of the 30th Annual Cryptology Conference
(CRYPTO 2010), no. December 2009, 2010. [Online]. Available:
http://cryptome.org/a5-3-attack.pdf
[10] V. Prevelakis and D. Spinellis, The Athens Affair, Ieee Spectrum,
vol. 44, no. 7, pp. 2633, 2007. [Online]. Available: http:
//ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4263124