security in delay tolerant networks for the android platform · aalto university abstract of the...

Royal Institute of Technology (KTH)

Aalto University - School of Science and Technology (TKK)

Faculty of Information and Natural Sciences

Sebastian Domancich

Security in Delay Tolerant Networks forthe Android Platform

Master's Thesis

Stockholm, June 30, 2010

Supervisors: Professor Bjorn Pehrson, The Royal Institute of Technology

Professor Antti Ylä-Jääski, Aalto University

Instructors: Professor Avri Doria and Hervé Ntareme

Aalto University ABSTRACT OF THESchool of Science and Technology MASTER'S THESISFaculty of Information and Natural SciencesDegree Programme of Security and Mobile Computing

Author: Sebastian DomancichTitle of thesis:Security in Delay Tolerant Networks for the Android Platform

Date: June 30, 2010 Pages: 7 + 73Professorship: Data Communications Software Code: T-110Supervisors: Professor Bjorn Pehrson

Professor Antti Ylä-JääskiInstructor: Professor Avri Doria and Hervé Ntareme

In the recent years, access to ICT has become not only an economic imper-ative for nations seeking progress, but also an essential asset to improvethe development of societies as a whole. However, still in 2010, more than90% of the population of Africa has no access to Internet.

The Bytewalla project was started with the objective of narrowing theglobal digital divide in Africa, by implementing DTN in Android phones.This technology is aimed at providing connectivity to places where tradi-tional end-to-end infrastructure is prohibitively expensive or not scalable.

The thesis work consists on the deployment of a security solution for DTNin the Android platform. Our solution comprises the implementation ofthe Bundle Security Protocol, which will be used in the Bytewalla pro-gram. We have carried out performance tests to measure size and batteryoverhead, and we made a thorough security assessment of the Bytewallasystem.

The fact that our DTN security implementation is compliant with theBundle Security Protocol speci�cation has two clear implications. Firstly,the Bytewalla system will be ready to be deployed in a real world testbed as soon as security in the DTNRG reference implementation is fullyimplemented. Secondly, our compliant implementation can be utilized todeploy security in any DTN application based on the Android platform.

Keywords: DTN, Delay Tolerant Networking, Bundle SecurityAndroid, Bytewalla

Language: English

ii

Acknowledgements

I would like to thank Professor Bjorn Pehrson and Professor Antti Ylä-Jääskifor being my supervisors. I also would like to thank Marco Zennaro forstarting up the Bytewalla project. Without his vision, the thesis work wouldhave not been possible.

In addition, I would like to thank Professor Avri Doria and Hervé Ntareme,my instructors, for their constant guidance and feedbacks throughout thisthesis work. I also sincerely thank Peter Lovell and Rerngvit Yanggratokefor their valuable help in the implementation tasks.

Finally, I would like to thank my family, girlfriend and friends for theirsupport during the thesis writing time.

Stockholm, June 15, 2010

Sebastian Domancich

iii

Abbreviations and Acronyms

IP Internet Protocol

TCP Transmission Control Protocol

IETF Internet Engineering Task Force

IRTF Internet Research Task Force

DTN Delay- and Disruption-Tolerant Networking

DTNRG Delay Tolerant Networking Research Group

GPRS General Packet Radio Service

3G Third Generation of mobile phone standards

IEEE 802.11 b/g Standard for carrying out wireless communication

GSM Global System for Mobile communications

EU European Union

DNS Domain Name Service

SMTP Simple Mail Transfer Protocol

IMAP Internet Message Access Protocol

RSA Algorithm for public-key cryptography

AES Advanced Encryption Standard

DNS Domain Name System

iv

Contents

Abbreviations and Acronyms iv

1 Introduction 1

1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Background and Related Work 6

2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Evolution of the Concept of DTN . . . . . . . . . . . . . . . . 7

2.2.1 Early research . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.2 NASA and its Interplanetary Network (IPN) . . . . . . 7

2.2.3 IRTF DTN-Research Group (DTNRG) . . . . . . . . . 8

2.3 Causes for Delay and Disruption in Networks . . . . . . . . . . 9

2.4 DTN Applications . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.1 Deep Space Communication . . . . . . . . . . . . . . . 11

2.4.2 Providing (DTN alike) Internet Connectivity in ex-treme environments . . . . . . . . . . . . . . . . . . . . 11

2.4.3 Lake pollution Monitoring . . . . . . . . . . . . . . . . 12

2.4.4 Noise Pollution Measurement . . . . . . . . . . . . . . 13

2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 DTNRG Protocols 14

v

3.1 The Bundle Protocol . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 DTN Architecture . . . . . . . . . . . . . . . . . . . . 14

3.1.2 Application Data Units, Bundles and Blocks . . . . . . 16

3.1.3 Binding and Persistence . . . . . . . . . . . . . . . . . 17

3.1.4 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Bundle Security Protocol Speci�cation . . . . . . . . . . . . . 18

3.2.1 DTN Threats . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.2 Security Design Considerations . . . . . . . . . . . . . 19

3.2.3 Security Blocks . . . . . . . . . . . . . . . . . . . . . . 20

3.2.4 Key Transport . . . . . . . . . . . . . . . . . . . . . . 23

3.2.5 Mandatory Ciphersuites . . . . . . . . . . . . . . . . . 23

3.2.6 Default Security Policy . . . . . . . . . . . . . . . . . . 24

3.2.7 Key management . . . . . . . . . . . . . . . . . . . . . 24

3.3 DTN Implementations . . . . . . . . . . . . . . . . . . . . . . 25

3.3.1 Reference Implementation . . . . . . . . . . . . . . . . 25

3.3.2 Bytewalla DTN . . . . . . . . . . . . . . . . . . . . . . 25

3.3.3 Other Implementations . . . . . . . . . . . . . . . . . . 25

3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Implementation 27

4.1 Previous Work . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Design and Implementation . . . . . . . . . . . . . . . . . . . 30

4.2.1 Path Leading to the Solution . . . . . . . . . . . . . . 30

4.2.2 Election of Security Block for the Implementation . . . 31

4.2.3 Software Development Approach . . . . . . . . . . . . 31

4.3 Implementation Technical Description . . . . . . . . . . . . . . 33

4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5 Performance Analysis 40

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . 41

vi

5.2.1 Equipment Used . . . . . . . . . . . . . . . . . . . . . 41

5.3 Size and transmission overhead . . . . . . . . . . . . . . . . . 42

5.3.1 DTN Bundle characteristics . . . . . . . . . . . . . . . 42

5.3.2 Measurement . . . . . . . . . . . . . . . . . . . . . . . 43

5.4 Energy Consumption . . . . . . . . . . . . . . . . . . . . . . . 45

5.4.1 Measurement . . . . . . . . . . . . . . . . . . . . . . . 45

5.4.2 Bundle Upload . . . . . . . . . . . . . . . . . . . . . . 46

5.4.3 Bundle Download . . . . . . . . . . . . . . . . . . . . . 48

5.4.4 Upload / Download Comparison . . . . . . . . . . . . . 49

5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6 Security Assessment for Bytewalla Application 51

6.1 Threat Modeling . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.1.1 Assets Identi�cation . . . . . . . . . . . . . . . . . . . 52

6.1.2 Architecture Overview . . . . . . . . . . . . . . . . . . 52

6.1.3 Application decomposition . . . . . . . . . . . . . . . . 54

6.1.4 Threats Identi�cation and Documentation . . . . . . . 56

6.1.5 Threats Rating . . . . . . . . . . . . . . . . . . . . . . 58

6.1.6 Threat Modeling Output . . . . . . . . . . . . . . . . . 58

6.2 Integration of Security Functionality . . . . . . . . . . . . . . 59

6.3 Evaluation of Protection Provided by Bundle Protocol Security 61

6.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7 Conclusion 63

7.1 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

A Threat Modeling Output for Bytewalla 71

vii

List of Tables

5.1 Size and transmission overhead . . . . . . . . . . . . . . . . . 44

6.1 Used technologies . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.2 Entry Points in the Bytewalla system . . . . . . . . . . . . . . 55

6.3 DREAD rating for the threats in Bytewalla . . . . . . . . . . 58

A.1 Threat 1: Identity spoo�ng . . . . . . . . . . . . . . . . . . . 71

A.2 Threat 2: Man-in-the-Middle attack . . . . . . . . . . . . . . . 71

A.3 Threat 3: SD card data tampering . . . . . . . . . . . . . . . 72

A.4 Threat 4: Eavesdropping in wireless communication . . . . . 72

A.5 Threat 5: Eavesdropping in Android data . . . . . . . . . . . 72

A.6 Threat 6: Denial of service attack . . . . . . . . . . . . . . . . 72

A.7 Threat 7: Unauthorized DTN usage . . . . . . . . . . . . . . . 72

A.8 Threat 8: SQLite data tampering . . . . . . . . . . . . . . . . 73

A.9 Threat 9: Information gathering attack . . . . . . . . . . . . . 73

viii

List of Figures

1.1 Bytewalla System Overview . . . . . . . . . . . . . . . . . . . 3

3.1 DTN Overlay Architecture . . . . . . . . . . . . . . . . . . . . 16

3.2 Abstract Security Block (ASB) . . . . . . . . . . . . . . . . . 22

3.3 AES-GCM Encryption Scheme . . . . . . . . . . . . . . . . . . 24

4.1 CMS enveloped-data structure generation . . . . . . . . . . . . 29

4.2 Iterative and Incremental development model . . . . . . . . . 32

4.3 Bundle Daemon initialization event . . . . . . . . . . . . . . . 36

4.4 Bundle Send event . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5 Bundle Receive event (1/2) . . . . . . . . . . . . . . . . . . . 38

4.6 Bundle Receive event (2/2) . . . . . . . . . . . . . . . . . . . 39

5.1 Bytewalla security connection scenario . . . . . . . . . . . . . 41

5.2 Structure of the analyzed bundle instance . . . . . . . . . . . 43

5.3 Structure of the analyzed security block instance . . . . . . . . 43

5.4 DTN security: Relative size overhead . . . . . . . . . . . . . . 45

5.5 DTN Bundle cumulative upload . . . . . . . . . . . . . . . . . 47

5.6 DTN Bundle cumulative download . . . . . . . . . . . . . . . 48

5.7 Comparison between download and upload battery consumption 49

6.1 Bytewalla Village Architecture Overview . . . . . . . . . . . . 53

6.2 Bytewalla City Architecture Overview . . . . . . . . . . . . . 54

ix

Chapter 1

Introduction

1.1 Overview

The widespread adoption of Information Technology (IT) plays a leadingrole in interconnecting communities from geographically distant locations.However, not all people have access to the same technical facilities. Someareas of the world, especially in underdeveloped countries or rural areas,are disconnected from technology, resulting in a signi�cant gap in progressopportunities between both types of countries.

In order to address this problem, the ByteWalla project was started up inKTH University [50]. The key idea of the developed technology is to allowpeople commuting between a city and a village to carry data in their mobilephones, working as a mule. After they arrive to the city or the village, thedata is transmitted to the destination's link.

Although the basic functionality has been achieved, there are still importantaspects that need to be addressed in order to allow the project to be deployedin a real world scenario. The area of security and privacy has to be studied.A user with a mobile phone is carrying sensitive information, which needs tobe encrypted. Encryption and decryption require CPU time and use batteryresources. The energy consumption and system performance implicationswill be analyzed. The security and privacy aspects of the system will bestudied, by using the Android platform for deployment and testing.

1

CHAPTER 1. INTRODUCTION 2

1.2 Problem Statement

Since the invention of Internet around 30 years ago, there is no doubt thatit has radically changed the way we work, play, and most importantly, com-municate with each other [42]. This technology has had a high adoptionrate among the industrialized countries since its birth, increasing e�ciencyand productivity in their economies, as well as allowing fast, inexpensive realtime communications. However, developing and least-developed countries1

have had a considerably slow Internet adoption rate.

According to recent surveys, only 25% of the World population has accessto Internet [34]. While highly industrialized countries like United States,Japan and United Kingdom show an Internet penetration of more than 70%in 2009, least-developed countries like Cambodia, Burundi and Bangladeshhave less than 1% of Internet users among their population. The continentwith least Internet adoption is Africa, with a level of only 6.8% up to date.

During the �rst decade of Internet existence, the term "global digital divide"was de�ned to refer to the inequalities regarding Information and Commu-nications Technology (ICT) adoption between the aforementioned types ofcountries. While developed countries were dramatically bene�ted by theadoption of Internet, the countries without IT infrastructure could not getany pro�t from this progress, increasing the digital divide and making thegap even bigger. To address this issue, an area of IT started to study howtechnology can be positively used in least-developed and developing countriesto reduce poverty, called ICT for Development.

In terms of the urgent need to shorten the digital divide, many projects havebeen carried out to increase access to Internet, mainly in rural areas. Thecommon approach is to consider the rural areas as the last mile, i.e. the lastsegment of communication from the provider (in an urban area) to the ruralregion [45]. However, these options are generally expensive because of theinfrastructure costs that are involved and as a consequence, people in ruralareas cannot take advantage of ICT in their community.

In order to provide connectivity to rural areas that lack of Internet access orany other networking infrastructure, a recently developed technology, namedDelay and Disruption Tolerant Networking (DTN) can be used. DTN is anetworking approach that provides connectivity in environments where tra-ditional transport protocols cannot work, due to disruptions or considerabledelays in the communication.

1Least-developed countries de�ned by United Nations in [8].


The Bytewalla Project implements the DTN concept for the Android Plat-form [7]. The scenario is explained in �g. 1.12 . Firstly, a user from anInternet kiosk in a village without Internet access (bottom left of the �gure)composes and sends an email, which is stored in the Village server. Afterthat, the person acting as a data mule receives the data packets (called bun-dles in the DTN jargon) from the village server, and transfers to the city,that has Internet access. When he arrives, he sends the bundles from hiscell phone to the city server, that acts as a gateway, delivering the messagevia the Internet connection. Another choice for the message delivery is touse the GPRS or 3G connectivity, which was not originally considered in theoriginal project and would require further testing. Finally, it is worth notingthat an analog procedure is carried out in the opposite direction, when anemail is sent from Internet to a mail address from a village inhabitant.

Figure 1.1: Bytewalla System Overview

The project previously developed up to date includes di�erent applications:

1. The port of the DTN Bundle protocol from C++ to the Android plat-form.

2. The implementation of an Android application, working on top of theDTN Bundle Protocol,to send and receive bundles.

3. An email integration script, to translate the received emails into bun-dles, ready to be sent via DTN to the mule, and transported to desti-nation.

2From [50], with permission.


The Bytewalla project also considered that once the project is deployed ina real scenario, a possible business model can be introduced. A telecomoperator can set up Internet kiosks in di�erent villages and in a city with thenecessary equipment to send and receive emails, and recruit employees withAndroid phones, that would act as data mules going back and forth betweenthe city and the village.

The current solution does not implement any security mechanisms to protectthe delivered messages. Security in DTNs is a critical aspect, as discussed insec. 3.2, and is the main topic of the present thesis work.

1.3 Criteria

This thesis work is carried out in TSLab (KTH University) in spring 2010.

A set of requirements are de�ned for the present work. Firstly, a literaturestudy has to be carried out on the �eld, considering DTNs and security inDTNs.

Based on the previous work, the main objective of the thesis is to deploy astandardized security solution for DTN networks in Android, which could beimplemented in the ByteWalla project, as well as other DTN related futureprojects. According to this, we can identify the following requirements:

1. Implementation of Security mechanisms in the Bundle Proto-col

The implementation will be fully compliant with the Bundle SecurityProtocol Speci�cation from DTN Research group [48]. In addition, itneeds to be inter-operable with the current C++ DTN2 implementa-tion in order to allow testing. It is worth considering that the securitymechanisms for DTNs are still Internet-Drafts, so the work needs to bedone in a modular way: while the focus is placed on the interoperabil-ity with the DTN2 implementation, attempts should be made to testit also against the latest released work by the Delay Tolerant Network-ing Research Group (DTNRG). This task also includes documentingthe implementation design approach to facilitate future expansion andenhancement of the developed program.

2. Performance analysis of the implementation

The implemented solution needs to be analyzed considering CPU andenergy consumption measured in the Android system when the security


services are enabled.

3. Integration into Bytewalla Application and Security Assess-ment

The possibility of integrating the security solution into the Bytewallaapplication needs to be analyzed. In addition, a security analysis ofthe solution has to be carried out. An analysis of the threats that aresolved in the implemented approach and of the ones that are still openshould be included.

1.4 Thesis Organization

This thesis report is organized in seven chapters. Chapter 1 provides theIntroduction, which includes the problem description, the criteria and out-lines the organization of the rest of the work. Chapter 2 provides backgroundabout Delay Tolerant Networks and references relevant research in this topic.Chapter 3 reviews the Bundle Protocol, which was already implemented inthe Android platform, and the Security Protocol, which is implemented asan outcome of the present work. Chapter 4 describes the implementationprocess carried out to port the security protocol to Android, while in chap-ter 5 we analyze the performance of the developed security mechanisms. Inchapter 6 we assess the security in the original Bytewalla program, and weconsider how the addition of security services improves the application. We�nalize the present work by discussing related matters, depicting possiblefuture work and summarizing the work done in chapter 7.

Chapter 2

Background and Related Work

In this chapter, we �rstly discuss the need of a new kind of protocol to dealwith extreme networking situations, de�ned as delay- and disruption-tolerantnetworking. Later on, we identify the di�erent research groups involved inthe �eld, and we mention how they have contributed with each other to endup with the current DTN standards. After that, we explain in more detailthe characteristics of DTN networks. Finally, we provide an overview of thepractical applications that can be implemented under the idea of delay- anddisruption-tolerant networks.

2.1 Motivation

The majority of the inter-networking communication that takes place at thepresent time makes use of the TCP/IP model, as de�ned in [11]. However,this networking model implies a set of assumptions needed for the commu-nication to succeed [16]:

• There is an end-to-end link between both communicating parties thatnever gets interrupted.

• The communicating parties are close enough such that the propagationdelay, and hence the round trip time, are acceptable. For example, theTCP speci�cation states a default user timeout of 5 minutes [44], butthis option can be changed by means of a TCP User Timeout Optionspeci�ed by the application [26].

• The percentage of dropped packets is small, in order to make the re-transmission mechanisms viable.

6

CHAPTER 2. BACKGROUND AND RELATED WORK 7

The aforementioned assumptions are not always held, and the term of chal-lenged networks [27] is applied to such networks that do not comply withthe principles needed for TCP/IP to work correctly. As explained in thefollowing section, research in this area started focusing on the developmentof an interplanetary Network (IPN), and later on evolved to the generalizedconcept of Delay and Disruption Tolerant Networks.

2.2 Evolution of the Concept of DTN

This section outlines the role of the di�erent standardization bodies in thedevelopment of Delay Tolerant Networking.

2.2.1 Early research

The �rst research attempts in the �eld of Delay Tolerant Networks date backto 1982, with the creation of the Consultative Committee for Space DataSystems (CCSDS) [14]. This committee is composed by a number of spaceagencies around the world, and its main objective is to create standards forcommunication in deep space. These standards are published with the nameof Blue Books.

During its existence the group developed many protocols to deal with situ-ations where delay or disruption can occur in multiple network layers. Themost relevant for this context is the CCSDS File Delivery Protocol (CFDP)[15], published as part of its recommended standards. This reliable link layerprotocol assures the transmission of protocol data units (called bundles) be-tween DTN nodes in distant networks.

2.2.2 NASA and its Interplanetary Network (IPN)

In 1998, the Defense Advanced Research Projects Agency (DARPA) , whichbelongs to the USA Department of Defense, provided funding to the NASA'sJet Propulsion Laboratory [41] to start up a program for the InterplanetaryInternet. Basically the objective was to provide a means for applications inEarth to communicate seamlessly with applications in spacecrafts and other�ying objects [30]. Leaded by Vint Cerf, the group published its proposedarchitectural de�nition in 2001 [17]. The main idea behind it (explainedin more detail later on in this work), is that each application should usethe protocols stack that �ts its needs in each scenario, but there should be


an extra intermediate overlay network protocol between the optimized lowerlayers and the application layer [12].

Later on, NASA's IPN project evolved into a public Internet Society IPNspecial interest group, called Interplanetary Internet Project (IPNSIG) [35].The objective of the group remained constrained to deep space communica-tions.

2.2.3 IRTF DTN-Research Group (DTNRG)

In 2002, the Internet Research Task Force created a Research Group for DelayTolerant Networks, with the objective of extending the concept of IPN toconsider also terrestrial wireless networks. In this way, the experimentationwould be easier to carry out.

Clearly, there are similarities between deep space and terrestrial DTNs. Forexample, both types of networks need to deal with disruption and delay inthe communication path. However, the main design di�erence is that in theIPN case the connectivity is in general scheduled (i.e., the delay and disrup-tion are predictable), while in the terrestrial case, the connectivity model isbroader, including mobile ad-hoc networks (MANETs) that communicate inan opportunistic manner, as many of the application examples depicted insec. 2.4.

The DTNRG working group has been designing DTN solutions since its cre-ation back in 2002. After de�ning the principles for its architecture [27] thetopic has gradually evolved into a recognized research area, with a richercommunity contributing to it. In the recent past, the group has learned alsofrom a number of real-world deployments. As an outcome, it has been ableto convey a number of publications, including Internet RFCs and ongoingdrafts. The most relevant documents published by the group are:

• Delay Tolerant Networking Architecture (RFC 4838) [16].

• Bundle Protocol Speci�cation (RFC 5050) [46].

• Bundle Security Protocol Speci�cation (Internet-draft) [48].

• Delay Tolerant Networking TCP Convergence Layer Protocol (Internet-Draft) [19].

• UDP Convergence Layers for the DTN Bundle and LTP Protocols(Internet-Draft) [39].


2.3 Causes for Delay and Disruption in Net-

works

In sec. 2.1 we pointed out the assumptions that traditional inter-networkingprotocols like TCP and UDP are based on. In this section, we analyzedi�erent situations in which those premises are not complied with, unveilinga need for networking protocols that can handle delays and disruptions.

We de�ne network delay as the time it takes for a packet to travel from thesource to the destination within the IP network [49]. The total network delayis the sum of the delays caused by the transmission medium and the inter-mediate nodes that the packet traverses (like routers, switches and others).

We de�ne disruption as a situation in which the packets cannot be transmit-ted as expected because the link is not available (e.g., when changes in thecommunication scenario occur).

The most prominent sources of delay and disruption, either in spatial orterrestrial networks are [29]:

• Speed of light in interplanetary distances

The �rst issue that arises is that interplanetary communication (and infact, any communication) is subordinated to the speed of light, whichis around 300,000 kilometers per second. For example, from an Earthstation to the Sun, a one way trip would require around 8 minutes.Secondly, it is worth considering that the planets are constantly mov-ing and rotating, so the propagation delay is dynamic, relative to theposition of both communicating bodies. Also, because of the rotation,visibility between the planets can be disrupted for a certain amountof time. Finally, another issue in interplanetary communication is thefact that other bodies (for example, planets) can interfere in the pathbetween the communicating parties, provoking a disruption in the net-working attempt.

• Power consumption issues

One of the main application �elds for DTN is the area of WirelessSensor Networks. In this kind of devices, the power consumption has tobe strictly controlled because batteries tend to have a very low capacity.Because of that, in the general case the controller turns on the radiotransceiver only when it needs to transmit or receive data to/fromanother node [38]. In some scenarios, the nodes will be able to predictthe time when the connection is feasible (in a similar way that we


can predict when the planets will be aligned). In some other cases,the movement of the nodes may not be completely controlled, makingcommunication much more challenging.

By powering o� the radio, the device can face voluntary disruptionthat a�ects connectivity, and it may also cause delays to other nodescommunicating, if the intermittent node is part of a multihop pathbetween two communicating parties.

• Security considerations

In general terms, any network is exposed to a number of securitythreats, and DTNs are not an exception. As the resources are gen-erally scarce, one of the main concerns is the prevention of Denial ofService (DoS) attacks, where an attacker prevents a node from beingavailable to the intended users, provoking a disruption in the service.For example, an attacker can send continuous communication attemptsto a victim node, in order to exhaust its battery and make it unableto handle any more communication attempts. In addition to a protec-tion mechanism to minimize DoS attacks, a DTN deployment shouldprovide basic security features, such as data authentication, integrityand privacy in communications. Their main objective is to avoid mali-cious or non-authorized nodes from making use of the resources of thenetwork, that may be considerably costly. Finally, it is worth notingthat DTN nodes may be placed in locations where they could be vic-tims of the environment. For example, in the case of DTNs in an openscenario like a forest, they could be compromised by extreme weatheror animals, and this would possibly lead to a disruption in the com-munication. The security in DTNs is discussed in further detail in sec.3.2.

2.4 DTN Applications

In this section we discuss some of the areas in which DTNs can provide anadequate solution to communication needs. Most of the scenarios depictextreme situations, where traditional end-to-end connectivity is not possible,or cost-prohibitive. It is in these cases where the DTN approach shows itsmain bene�ts. DTNRG maintains a list of the most relevant projects basedon the DTN architecture in [23], while [6] contains a detailed survey of allDTN related projects and studies up to 2009. In addition, we provide anoverview of the Bytewalla project, whose security is analyzed in chapter 6.


2.4.1 Deep Space Communication

As previously mentioned, NASA JPL started developing a DTN protocolfor its interplanetary missions back in 1998. It was named InterplanetaryOverlay Network (ION), and it was the basis of the DTNRG Bundle protocol,discussed in chapter 3. After continuous e�orts, in 2008 it performed the �rst�le transfer using a Delay Tolerant Protocol, by transmitting a set of imagestaken from a satellite named UK-DMC [54]. In the same work, the authorspoint out a series of issues that should be further addressed in the BundleProtocol, like fragmentation, custody transfer and reliability. These topicsare discussed in sec. 3.1.

2.4.2 Providing (DTN alike) Internet Connectivity inextreme environments

One of the main application scenarios for DTN is the extension of Inter-net connectivity in environments were traditional networking is not possible.This lack of connectivity can be due to many factors. In this section weanalyze projects that tackle connectivity in extreme weather conditions, andin developing regions.

Bytewalla

The Bytewalla project [50] belongs to KTH University in Sweden, and hasthe objective of providing connectivity to rural villages by means of Androidphones carrying an implementation of the DTN Bundle protocol.

In general terms, the lack of a link between a village without Internet accessand a city with Internet connectivity is replaced by a data mule, i.e. aperson carrying the Android phone between both ends. When the mule is inthe village, it receives a set of bundles from the Server via an 802.11 accesspoint (AP), and when it arrives to the city, it will connect to the gatewayAP to upload the received data.

The currently implemented functionality includes only email for the timebeing, but there are plans to add more DTN applications on top of thealready deployed DTN implementation. The project is further described inchapter 6, and its Android DTN implementation is the basis for the securityimplementation carried out in the present work.


Sámi Network Connectivity (SNC)

The SNC project [22] aims at providing Internet connectivity for the Saamicommunity of reindeer herders, located in the north part of Sweden. It wasa pioneer in the adoption of the DTN practices, although the DTN Bundleprotocol was not implemented by the time the project was deployed. Ingeneral terms, the network is composed by semi-�xed nodes, located in thetemporary places where the Saami herders stay, and mobile nodes (snowmobiles or helicopters) that act as data mules. the success of this project ledto the launch of an EU funded project to study connectivity in remote areas,called Networking for Communications Challenged Communities (N4C) [6].

DakNet

DakNet [43] is another project that addresses the lack of networking in-frastructure in developing regions, for example, in places where traditionalnetworking approaches are prohibitively expensive. It was one of the �rstprojects in implementing the concept of data mules to transport tra�c. Inthe case of DakNet, it makes use of public transport (mainly buses) to travelamong the di�erent villages and the Internet-enabled spot.

2.4.3 Lake pollution Monitoring

We have previously mentioned that Wireless Sensor Networks can be ben-e�ted by the use of DTN solutions. Farrel et al. carried out a project tomonitor the quality of the lake water in Ireland, and thoroughly documentedthe process in [29]. Some design considerations are considered in the follow-ing paragraphs, and they provide a valuable idea of the steps involved whendeploying DTN applications.

The sensors had to be deployed in a way such that their life time should belong enough to work for more than a year, and without requiring frequentservice. The density of the network (the number of needed nodes) had to beanalyzed, considering the cost of each node, the radio coverage of the di�erentalternatives, and the needed power supply. The �nal decision for the lakequality pilot was to deploy a small number of capable nodes, provided witha solar power battery, and the option to switch to a power-conserving modein case of a detected critical level.

The communication requirements were also analyzed, and protocols for eachlayer were selected. For the physical and link layer, they chose IEEE 802.11b/g,


over other options like GSM based technologies, that would require a higheroperational cost. For the network layer they selected IP, and for the trans-port layer, they picked out UDP, considering the smaller number of requiredround-trip times compared with TCP. Finally, for the DTN and applicationlayer, they chose to avoid end-to-end connectivity, favoring the store-and-forward paradigm from DTN, making use of nodes that would cross the lakeattached to �shing boats, that would act as "data mules". In this way, thecontact between nodes would be opportunistic.

To sum up, it is worth considering that many options for communicationwere considered (for example point-to-point communication via GPRS and3G mobile), but DTN proved to be the most cost-e�ective one, consideringthe amount of data that needs to be collected and sent. In this respect,the authors accepted the fact that cost is a very important argument whenchoosing technologies, and it can be considered as a bene�t when comparingthe DTN approach with other possible solutions.

2.4.4 Noise Pollution Measurement

Noise pollution is a serious issue in many urban areas, and the EuropeanUnion has stated a common approach related to the way to act againstenvironmental noise situations [20]. In general terms, it is carried out bymeans of a monitoring station, that periodically checks the noise level, andeventually triggers an alarm or records the result in a logging module. Theseapproach is composed of a high �delity and pricey microphone. In order tolower costs and add functionality, an array of low-price microphones and dataprocessing functionality connected in a DTN fashion can be implemented.In order to avoid infrastructure costs, the nodes can communicate with eachother using a mule approach, similar to the lake monitoring case.

2.5 Summary

This chapter introduced the topic of Delay Tolerant Networking. First, weprovided an overview of the DTN concept coinage. Later on, we mentionedthe most common causes for delay and disruption in networks. Finally, weprovided a short list of example applications where the concept of DTN canbe employed.

Next chapter will focus on the DTNRG protocols implemented in the Byte-walla system.

Chapter 3

DTNRG Protocols

This chapter discusses the main DTN protocols developed by DTNRG. Firstly,we review the Bundle Protocol that is already implemented in the BytewallaProject. After that, we discuss the Bundle Security Protocol, which is im-plemented in the current thesis work. Finally, we provide an overview of theavailable DTN Implementations, focusing on the Reference Implementationdeveloped by DTNRG.

3.1 The Bundle Protocol

DTNRG has authored RFC 5050, describing the Bundle Protocol for DTNs.In this section we present an overview of its most relevant aspects and designchallenges.

3.1.1 DTN Architecture

The Bundle Protocol design follows the architecture speci�cation previouslydetailed in RFC 4838. As we mentioned in sec, 2.1, the Internet architecturefollows a number of implicit assumptions for the communication to succeed,like the existence of an end-to-end link between the communication parties,a short round trip time and a low level of disruption in the network. On thecontrary, the DTN architecture was designed to loosen all these requirements,to provide a solution to disruption and delay in a variety of scenarios. Itdepicts a store-and-forward mechanism with persistent storage, providing thenodes with the ability to save bundles even between long network disruptions.In addition, it can take advantage of end-to-end connectivity, but it does not

14

CHAPTER 3. DTNRG PROTOCOLS 15

require it for the protocol to work.

The Bundle protocol provides two mechanisms for enhancing reliability. The�rst one is custody-based transmission [16], in which the nodes can be re-quested to use reliable transfer procedures when available, and they be-came responsible for assuring retransmission whenever necessary. The secondmechanism involves end-to-end acknowledgments.

Finally, and as will be further discussed in sec. 3.2, it provides policy basedsecurity mechanisms to prevent unauthorized nodes from using up the re-sources of the network.

As speci�ed in the DTN Architecture, the Bundle Protocol is situated inthe Application layer. It was conceived to manage di�erent devices withpotentially distinct underlaying networking protocols. It allows the inter-connection of dissimilar nodes, independently of the underlaying transportlayers, by de�ning a set of Convergence Layer Adapters (CLA), one for eachunderlaying transport protocol, that are placed on top of the Transport layer.These CLAs supply a minimum set of functionality common to all the nodes,to successfully transmit the bundles that are the protocol data units of theBundle Protocol.

Fig. 3.1 shows a possible overlay scenario for a DTN application. In this case,we have 3 DTN entities: 2 hosts and a gateway, that is a host with a dualprotocol stack, allowing entities with di�erent underlaying protocols to com-municate with each other. There are some aspects to analyze from this �gure.Each node can have a di�erent transport layer, and the Bundle protocol isplaced on top of them. The bundle protocol is the same in all the entities.In addition, each node is associated to an endpoint identi�er (EID), that isde�ned following the URI syntax [10], for example, dtn://city.bytewalla.org.As can be seen, the �rst and last node are running a DTN application on topof the bundle protocol, and they communicate with each other, exchangingDTN bundles.

In the present example the DTN hosts have di�erent network layer protocols.While the host on the left uses the traditional TCP/IP networking model, thehost on the right uses a speci�c or proprietary protocol stack (this practiceis relatively common in WSNs). The only requirement in this case is thata Convergence layer should be implemented for the required protocol stack.The DTN gateway receives bundles from the host on the left and sends themto the host on the right. An analog procedure is carried out to send bundlesback in the opposite direction.

The previously mentioned overlay approach allows the bundle protocol to be


Figure 3.1: DTN Overlay Architecture

used in a wide range of di�erent DTN networks interacting together. It isworth mentioning that this behavior has been object of criticism by someresearch groups. For example, [53] argues that DTN is an heterogeneousworld, and the approach of layering over all networks (in a similar way to theInternet approach) may not be appropriate, because di�erent DTN networksrarely interact with each other.

3.1.2 Application Data Units, Bundles and Blocks

The DTN application layer communicates with the Bundle layer (where theBundle Protocol is implemented) to send and receive data packets calledApplication data Units (ADUs). When a DTN application wants to send anADU to an speci�c Endpoint Identi�er, it generates an ADU and sends it tothe Bundle Protocol layer; this layer receives the ADU, and produces one ormore Bundle Protocol data units (bundles).

Each bundle is composed by a number of blocks. There are three types ofblocks:

1. Primary Block: It contains the source and destination EIDs, amongother �elds. It is the equivalent of a header in other protocol de�nitions.There is only one primary block per bundle.

2. Payload Block: It contains the application data. There can be zero ormore payload blocks per bundle.


3. Extension Block: It is a powerful mechanism to extend the functional-ity of the Bundle Protocol, for example, to add security functionality.These optional blocks are generally situated between the primary andthe payload blocks, except when authentication is used. In this case,the block containing the digest signature is placed at the end of thebundle.

After the blocks are created, they are sent to the convergence layer andforwarded according to the lower level layers in the protocol stack.

3.1.3 Binding and Persistence

In the context of DTN, we can de�ne binding as the mapping function usedto convert DTN Endpoint IDs into transport layer addresses [28], in a similarway that DNS works in Internet. The binding process can be executed atthe source (called early binding), in transit or at the destination (called latebinding).

3.1.4 Routing

In traditional networks, routing generally involves selecting the shortest pathin a connected path that complies with a prede�ned policy, without consid-ering bu�ering availability or bandwidth [36]. However, DTNs are de�nedunder the assumption that they will experience frequent disruptions, andthere may never be a constant end-to-end path between two EIDs. becauseof its complexity, this topic was not addressed in the speci�cation of BundleProtocol, allowing the proposition of several routing algorithms, includingperformance simulation studies.

In general terms, routing in DTN considers that the routing graph is dis-connected (as opposed to traditional routing where it is assumed to be fullyconnected). In addition, routing can involve other variables, like knowledgeabout the network topology over time, fragmentation, resource reservation,etc. One of the �rst research works about this topic was [36], published in2004, less than a year after the �rst draft of the Bundle Protocol. It mainlyaddresses routing taking the approach of shortest path algorithms, and it con-siders the knowledge of the network to make routing decisions. A detailedoverview of several routing schemes for DTN, including the aforementionedone can be found in [56].


3.2 Bundle Security Protocol Speci�cation

Security is a signi�cant aspect in DTNs, mainly because this technology wasdevised to operate on top of resource-constrained networks that need to beprotected from unauthorized use. In addition, sections of the network can becompromised, and protection measures like con�dentiality and integrity areessential in this context.

The DTNRG had started working in the documentation regarding DTN Se-curity as early as 2005, while the Bundle Protocol Speci�cation was still anInternet-draft. By that time, the group released the �rst drafts of two docu-ments named DTN Security Overview [31], which comprises a general surveyof security requirements and design considerations, and the Bundle SecurityProtocol Speci�cation [48] or BPSEC which de�nes the provision of securityservices like integrity and con�dentiality. The DTN Security Overview doc-ument has already expired in 2009, and has allegedly reached its goal. Onthe other hand, BPSEC is still an Internet-draft, and it is mature enough asfor it to be expected to become an RFC in the upcoming months.

This section contains a compact overview of the speci�cation, including theessential information needed to understand the forthcoming implementationand analysis chapters. We consider that the o�cial speci�cation is clear andto the point, and its understanding is highly recommended to obtain a clearerpicture of the present work.

3.2.1 DTN Threats

In this section we identify the key security issues that need to be addressedin a DTN security implementation.

General Networking Attacks

As previously discussed in chapter 3, DTN conforms an overlay network. Be-cause of that, it needs to cope with traditional networking attacks [25] whichcan be passive (eavesdropping, tra�c analysis) or active (tra�c modi�cation,masquerading). As a palliative for the aforementioned situation, DTN ap-plications could make use of the security mechanisms provided by the lowernetworking layers. However, this solution needs to be e�ectively organizedin order to be relied as consistent protection.


Resource Leakage

The resource constrained scenario that characterizes DTNs poses a highercost to the misuse of the network capabilities. Some examples of such resourcemisuse are:

• A malicious or defective node can inject spurious packets into the net-work.

• Applications can send nodes at a rate that they are not allowed bytheir policy.

• Amalicious or defective node can generate additional management mes-sages for each bundle sent.

Denial of Service Attacks

Denial of Service (DoS) attacks should also be addressed in the DTN scenario.Regarding this matter, DTNs are vulnerable to similar attacks as MobileAd-Hoc Networks. [13] presents an overview of this topic, and presents acomprehensive list of the DoS attacks that target the di�erent networkinglayers.

Privacy and Integrity

DTNs are subject to ordinary threats related to con�dentiality and integrity.More speci�cally, the DTN Security protocol needs to address the followingtopics.

• Altering bundle headers. This includes modifying source and/or desti-nation, and the control �elds present in each bundle.

• Altering the payload of the bundles.

• Eavesdropping bundle content.

3.2.2 Security Design Considerations

In this section we present the main design considerations that were consentedupon before designing the Bundle Security Protocol [29].


End to End or Hop by Hop

Security protocols are generally de�ned either in an end-to-end, or in a hop-by-hop fashion. However, in the DTN scenario we need to also consider thepossibility that a subsection of the network might be already protected, e.g.by lower layer security, and only the remaining segment may need securityfunctionality.

In order to provide security functionality in cases as the previously referred,we need to distinguish the sender of a bundle from the security sender, whichis the one that applies the cryptographic operation, protecting the bundle.Likewise, the security destination is the DTN node whose the protected bun-dle is destined to. It is worth mentioning that in a pure end-to-end securityoperation, the security source and security destination will be the same asthe source and destination of the DTN bundle.

As a consequence, when it is speci�ed that a DTN security operation is end-to-end, it means that it is sent from a speci�c security source to a securitydestination, which might not be the originator and destination of the bundlerespectively.

Privacy and Integrity

The DTN security protocol needs to provide a con�dentiality service to allowprivacy of the bundle contents as they are moved from one node to another.In addition, it needs to provide an integrity service to detect changes in theoriginal message.

Security Policy

The DTN protocol has to provide a mechanism to enforce routing policieswith the objective of specifying bundle forwarding decisions. Simple policiesare valid, like e.g. forward all received bundles.

3.2.3 Security Blocks

This section introduces the di�erent security blocks that can be present ina bundle. As will be noticed, each one provides a di�erent security service.All of them share a number of �elds, hence an abstraction called AbstractSecurity Block (ASB) was created, which groups all these characteristics. Aswill be seen in the implementation chapter, this abstraction is followed also


in the C++ and Android programs, where all security blocks inherit fromthe ASB.

The latest DTN security standard de�nes four di�erent types of securityblocks that extend the ASB to provide a speci�c functionality. These blocksare: Payload Con�dentiality Block (PCB), Bundle Authentication Block (BAB),Payload Integrity Block (PIB) and Extension Security Block (ESB). The �rstone, PCB, has special relevance because it corresponds to the security serviceimplemented in the present thesis work.

As we have already pointed out, each security block is associated with aunique security service. In addition, each security service can make use of oneof a number of ciphersuites which de�ne the implementation speci�cations,such as bulk encryption method, data integrity algorithm and authenticationprotocol.

Abstract Security Block (ASB)

The structure of an ASB is presented in �g. 3.2, and contains the following�elds.

• Block type code: Speci�es the type of the block and is included inall DTN blocks. As of security, it speci�es whether the block is BAB(0x02), PIB (0x03), PCB (0x04) or ESB (0x09).

• Block processing control �ags: It is de�ned in the Bundle Protocol andis common to all DTN blocks.

• EID references: Is an optional �eld that contains the security-sourceand security-destination of the present bundle.

• Block data length: Contains the length (bytes) of the remainder of theblock.

• Ciphersuite ID: Speci�es the ciphersuite that is being used among theregistered ones.

• Ciphersuite �ags: Control �ags that mandate the security functionality.

• Correlator: This optional �eld is used to associate several related in-stances of a security block when this functionality is needed

• Ciphersuite parameters and Security result: These two �elds are com-posed of tuples represented as type-length-value, and are used by the


di�erent ciphersuites to store security results. Some of the types thatcan be included are: Initialization Vector, encoded key information,salt, PCB Integrity Check value (ICV).

Figure 3.2: Abstract Security Block (ASB)

Payload Con�dentiality Block (PCB)

PCB is used to indicate that the bundle payload has been encrypted at thePCB security-source, and it will be decrypted at the security-destination.

A ciphersuite that operates with a PCB should �rstly generate a securerandom key, called bundle encryption key (BEK) and use this key to encryptthe payload of the bundle. After that, it should encrypt the BEK with a longterm encryption key (e.g., a public key) and send this encrypted key insidethe PCB.

In addition, a data integrity mechanism should be implemented to detecttampering into the bundle payload content.

Bundle Authentication Block (BAB)

BAB provides integrity and authenticity of the whole bundle on a hop-by-hop basis, i.e., from a security-capable node to the next security-capable node(which might be actually more than one node distance).

Payload Integrity Block (PIB)

The PIB provides integrity and authenticity for the payload in an end-to-end basis, starting from a security-source, which generates a signature of theblock, and ending in the security-destination, which veri�es the integrity ofthe received payload. Intermediate nodes could eventually check the integrityin case that they are in possession of the needed credentials.


Extension Security Block (ESB)

The ESB is a later addition to the Bundle Security Protocol, which allowsthe protection of blocks not considered by the previous services. The BundleProtocol allow the creation of speci�c-purpose blocks to provide a particularfunctionality. The previously de�ned security blocks aim only at encryptingthe bundle payload and integrity protecting the whole bundle. In case that aspeci�c-purpose extension block needs security, the ESB is the right securityblock to provide it.

3.2.4 Key Transport

After the security-source generates the random symmetric key to encrypt thepayload, it encrypts this key with the long term secret and sends it to thesecurity-destination. The speci�cation recommends that implementationsshould use the Cryptographic Message Syntax (CMS) to encode the keys, inorder to support interoperability.

3.2.5 Mandatory Ciphersuites

The Bundle Security Protocol speci�cation describes four mandatory cipher-suites, one for each type of security block. Each one speci�es a set of al-gorithms and modes of operation, as well as the structure that the securityblocks need to have. It is worth mentioning that other ciphersuites can becreated with di�erent algorithms, to work with the same security blocks.In the following section we provide an overview of the ciphersuite used inthe PCB, which is the one implemented in the current thesis work. Otherciphersuites can be found in [48].

PCB-RSA-EAS128-PAYLOAD

This ciphersuite encrypts the payload with a key size of 128 bits, by meansof AES algorithm in Galois - Counter Mode (GCM) [33].

AES-GCM does not expand the payload, and works as shown in �g. 3.3. Theinput to the algorithm are a randomly generated symmetric key (128 bits),the payload to be encrypted (plaintext) and a randomly generated nonce. Asa result, we obtain the encrypted payload (ciphertext) and an authenticationtag (ICV) of 16 bits.


Figure 3.3: AES-GCM Encryption Scheme

The security block is �lled in with the result in the following way. Thesecurity-parameter �eld will contain the symmetric key, encrypted with therecipient's public key and encoded with CMS. In addition, it will contain theparameters that conform the nonce. The security �eld will contain the ICVto check the integrity of the bundle once decrypted in destination.

In this way, the ciphersuite provides encryption, integrity protection andauthentication. Encryption is provided by the AES algorithm. Integrityprotection is provided by the GCM mode, which calculates the ICV. Receiverauthentication is provided by the use of public key cryptography: the randomkey is encrypted with the public key of the recipient. As a consequence, thereceiver is authenticated by proving that he knows his long term secret.

3.2.6 Default Security Policy

Each node has a speci�c policy that manages the forwarding and deliveryof bundles. This policy can be default or explicit, and it speci�es, e.g., theconditions under which the received bundles will be forwarded, or requiredto include a speci�c security block.

3.2.7 Key management

Key management was not considered in the development of the speci�ca-tion, mainly because it is a complex matter that has not came to consensusin the research community yet. Existing key management schemes rely onan online status checking service or a key-distribution service, and none ofthem is practical in a DTN scenario, where high delay and disruption arecharacteristic. In addition, the decision was to allow di�erent types of keymanagement schemes when they become available, hence no speci�c schemewas made explicit in the speci�cation.


3.3 DTN Implementations

The DTNRG maintains a Reference Implementation (RI) which is a programwritten in C++ that follows the Bundle Protocol speci�cation, and there areother independent projects as well.

3.3.1 Reference Implementation

The �rst version of the RI was released around 2005, and the current ver-sion is DTN 2.7. It includes the Bundle security Protocol and the LickliderTransmission Protocol (LTP), among others. It is currently maintained bythe Trinity College Dublin.

3.3.2 Bytewalla DTN

This implementation was developed in the Android platform in KTH Uni-versity in Sweden, and is used as a base platform to implement the securityservices in the current thesis work.

3.3.3 Other Implementations

There is a number of additional implementations that follow the RI to agreater or lesser extent. The Interplanetary Overlay Network (ION) imple-mentation referenced in previous chapters is currently maintained by OhioUniversity[1] and has been released as Open Source. IBR-DTN [21] is a C++version focused on embedded systems with limited memory. Finally, the Uni-versity of Wisconsin has ported the Bytewalla DTN implementation to pureJava, and works in Windows and Linux platforms [3].

3.4 Summary

This chapter discussed two protocols developed by DTNRG, namely BundleProtocol and Bundle Security protocol. For both of them we provided onlythe information of immediate relevance to the subject of the thesis. In addi-tion, we provided an overview of the available DTN implementations, whichfollow the reference implementation from the DTNRG.


Next chapter will focus on the implementation tasks performed. We willidentify the problems associated with our design and the path that led to thesolution.

Chapter 4

Implementation

This chapter presents the implementation that was carried out during thethesis work. Firstly, we discuss previous work that has been made in thissubject. After that, we de�ne the challenges associated with the design.Then, we describe the path leading to the solution of the problem. Finally, weprovide an instructive overview of the developed system. This chapter intendsto be both a descriptive and educating story of our thesis experience, and atthe same time a technical report useful for future DTN security practitioners.

4.1 Previous Work

This section describes earlier research e�orts at implementing security mech-anisms for DTN. We recall that the main objective in the thesis work is toprovide a security solution that is interoperable with the reference implemen-tation. Because of that, we consider the di�erent degrees of interoperabilityprovided by each reviewed solution. In order to better understand the con-text of the cited works, we concurrently make a reference to the evolution ofthe DTN security speci�cations throughout the last years.

Early DTN Security Speci�cation E�orts

The �rst e�orts to provide seamless security to the DTN Bundle Protocolspeci�cation date back to the IETF-62 meeting in March 2005, where MitreCorporation presented the outcome of relevant discussions made within thepale of the DTN community [47]. Basically, they agreed that the securityfunctionality would be optional for DTN, and relevant speci�cations would

27

CHAPTER 4. IMPLEMENTATION 28

be generated to deal with this topic. In addition, they discussed the needfor security and the requirements for this functionality. They concluded thatall future DTN-compliant implementations would need to comply with theupcoming speci�cation. During the same DTNRG meeting, the DTN Refer-ence Implementation (RI) was presented [18], and the DTNRG encouragedfuture DTN implementations to interoperate with the RI.

Later on the same year, the �rst draft versions of the security speci�cationswere published by DTNRG: Bundle Security Protocol Speci�cation [48] andDTN Security Overview [31].

First Implementation Attempts

Although the security speci�cations were clearly a work in progress, the al-ready set rules allowed an implementation of the basic security features ofDTN commissioned by DARPA [52]. This version had been added to theCVS revision in September 2005, and made certain design decisions aboutmatters that were not stated in the speci�cation yet. For example, for en-cryption it used a simple shared key scheme, without any public key support,which would be incompatible with the current speci�cation.

Security in the Reference Implementation

In October 2007, security mechanisms were partially added to the DTN2 ref-erence implementation, increasing the software version to 2.5. By that time,discussion in the DTN community was still being carried out regarding thekey transport mechanism to be used. In the case of PCB, after the payloadis encrypted with symmetric key encryption, the randomly generated key isencrypted with public key encryption, and this key should be transported tothe receiver in some standardized way. As there was no agreement on theway to transport the key, the implementors left this section to be speci�edin a later revision.

Private Key Management Implementation

In 2008, Lehigh University implemented a key management scheme to pro-vide the missing functionality to the DTN2 C++ program . It extended theDTN2.5 source, and was implemented for a private company. The imple-mented code is expected to be open-sourced during June 2010.


Key Management in the Reference Implementation

In March 2009, the Key Management text of the Bundle Security Proto-col speci�cation was �nally arranged, and the use of CMS to encode theencrypted symmetric key was decided as necessary for any compliant DTNimplementation.

The �rst major change was the adoption of Cryptographic Message Syntax(CMS), as de�ned in RFC 5652, for the key transport. CMS is based onthe syntax of PKCS #7, and provides encapsulation syntax for data that isencrypted or digitally signed.

This secure messaging standard is necessary because a simple security op-eration, like signing a message and verifying a signature needs a numberof attributes like: signature algorithm, signer's certi�cate (eventually) andsignature bytes. CMS packages all this in a standard format, to allow inter-operability in independent implementations.

Fig. 4.1 shows how the keys should be encrypted. After encrypting the datawith shared key cryptography, the generated symmetric random key needsto be encrypted with the recipient's public key.

Figure 4.1: CMS enveloped-data structure generation

In addition, the speci�cation went through its last modi�cations, and hasbeen recently proposed as an RFC. Because of that, the main implemen-tors of security in DTN2 have now a stable ground to implement the KeyTransport functionality, and are currently working to release a fully workingimplementation for the upcoming DTN2 release, which will comply with theDTN2 security speci�cations.


Shortcomings in the Current DTN2 Implementation

The security services of DTN2 are not fully functional in the current version.Several areas will be updated in the upcoming iteration.

The CMS support has not been implemented yet, and the symmetric datakey is not encrypted in the current revision. Instead, it is sent as a plaintext.

Other major tasks that will be changed in the upcoming implementation ofDTN2 are:

• Refactoring the BAB ciphersuite class to provide hop-by-hop authen-ticity and integrity protection by using public key cryptography (viathe KeySteward class).

• Implementation of a mechanism to cause PIB and PCB to be appliedat a particular node.

4.2 Design and Implementation

In this section we discuss about the process that we went through to complywith the thesis criteria of sec. 1.3. We refer to the path leading to thesolution, including main design tasks and software development approach.

4.2.1 Path Leading to the Solution

As previously mentioned, the overall thesis task involved implementing aspeci�cation compliant security solution for DTNs to be implemented in theBytewalla project, as well as in other future DTN projects. This wouldimply implementing security in a compatible way with the reference imple-mentation. However, after analyzing the current state of the DTN referenceimplementation, we realized that the key management module was not yetimplemented in the C++ code.

As a consequence, we decided to extend the thesis work to not only makethe DTN security implementation compatible with the available DTN2 code,but also to implement the missing key transport module into our Androidimplementation, tightly following the DTN Security speci�cation.


4.2.2 Election of Security Block for the Implementation

Sec. 3.2.3 provided an overview of the four available solutions for applyingsecurity services in DTN. In order to provide the required services to bothBytewalla and other general DTN applications developed in the Androidplatform, we have chosen to implement the Payload Con�dentiality Block(PCB) over the other 3 possible choices. We have selected this option forseveral reasons. Firstly, PCB is the only security service in the DTN speci-�cation that provides con�dentiality, integrity and authenticity. Hence, theusefulness and complexity of this block is higher than the others.

In addition, there is a number of minor reasons that would prevent us fromchoosing other security blocks. In the case of BAB, the current DTN2 imple-mentation does not follow the DTN standards, and could be considered anad-hoc attempt. It provides hop-by-hop integrity of the whole bundle, butby using a symmetric key, when the speci�cation mandates the use of publickey based signatures. PIB could be a suitable option, but as already men-tioned, it does only provide integrity, without the encryption functionalityneeded for the Bytewalla project, among other usages. Finally, ESB appliessecurity services to blocks other than payload. Thus, it would not provideany protection for the payload blocks (containing emails) in the Bytewallaapplication.

In consequence, we have implemented the Payload Con�dentiality Block(PCB), and as we followed the class structure from DTN2, the additionof new ciphersuites to provide other security functionality by extending thein-place classes requires a smaller amount of e�ort. As we have followed theavailable DTN security speci�cations, it is expected that it will interoperatewith the upcoming security functionality of the reference implementation,with eventual minor changes.

4.2.3 Software Development Approach

The software follows the object-oriented paradigm and an iterative and in-cremental development approach [51]. This development model was chosenbecause we believe that it suits the project goals. It allows modules of thesystem to be developed at di�erent times, e.g. via the addition of cipher-suites. Also, it schedules time to revise and improve the developed software.

Fig. 4.2 depicts the stages that we went through, and are explained in thefollowing sections.


Figure 4.2: Iterative and Incremental development model

Problem De�nition

Firstly, we de�ned the problem to solve, and we obtained enough informationfrom several sources. Mainly, we based our work on the RFC 5050 and thesecurity speci�cations from the DTNRG.

Analysis and Design

With regards to the implementation platform, we decided to continue theimplementation in Android 1.6, in order to allow the program to work withold OS versions.

Regarding the developed key management module, we made use of BouncyCastle cryptographic libraries [5] to provide the required encoding for theencrypted key transport.

Implementation

In order to obtain a working implementation, we followed the next steps.

• Stub Classes generation: We created the skeleton of the software, in-cluding stub classes and the needed methods.

• Unit Testing: Following the guidelines of test-driven development, wegenerated JUnit [4] test cases to test our software.

• Actual implementation: We developed the methods that were previ-ously de�ned. While in this implementation step, we followed Javaprogramming style guidelines [2] to allow other programmers to ana-lyze and extend the code without big di�culties. We also followed the


layers of abstraction mandated by the RI, and made use of the latestavailable Java techniques, e.g. enums from Java 5.0, which providea type safe and more informative way of implementing object modelconcepts. Finally, method comments were properly added to supportunderstanding the whole system.

After researching about Bouncy Castle (BC) libraries, we realized that inboth, the target Android SDK (1.6) and in the latest SDK (2.1), the includedversion of BC cryptography is considerably outdated (the included version,1.38 is more than 2 years old). However, as there is a version of BC alreadyin place, we would have duplicate code issues while integrating if we simplyadded the BC libraries. The solution that we adopted was to use the installed"basic" version of BC, and manually add the missing classes to support theneeded cryptographic functionality. Speci�cally, the implemented ciphersuitemakes use of AES in GCM mode to provide encryption, integrity protectionand authenticity. AES is included in the SDK, but the GCM mode wasadded manually.

Testing

This phase comprised testing the implemented code via both the JUnit testsand via our testbed between two Android phones (HTC Tattoo in Android1.6 and HTC Nexus One in Android 2.1).

4.3 Implementation Technical Description

This section provides an in-dept view into the security implementation inDTNs. It is worth mentioning that as our implementation follows the ref-erence implementation, the class structure and concepts discussed in thecurrent section are applicable to any DTN2 compliant implementation, in-dependently of the platform. Considering that the available documentationabout DTN2 in general and DTN2 security in particular is very limited atthe present time, this section will hopefully result in useful help for DTNsecurity practitioners, as it has been requested in some academic forums.

We �rstly provide an overview of the implemented security classes, and afterthat we provide the basic method calls when a bundle event occurs (such asbundle received or bundle being sent). The code snippets show a top downapproach of the actions related to the security processing.


DTN2 Security Class Overview

The following general security classes are invoked by all the security cipher-suites that might be implemented.

• BP_Local_CS: Represents an Abstract Security Block (ASB), as de-�ned by the Bundle Security Protocol. It contains all the data requiredfor the security functionality, like security source, security destination,security parameters and security result. In addition, it contains the en-coded binary data that refers to all the aforementioned security �elds.

• Ciphersuite: Represents a generic ciphersuite. This superclass declaresall the methods that a speci�c ciphersuite must implement. It is ageneric class that handles suite registration and other general tasks. Italso provides the parse method, which is invoked every time a securityprotected bundle is received, to make some basic processing. Afterthat, the block is processed by the associated security block processor.

• KeySteward: This class is in charge of the key stewardship. It pro-vides support for public key cryptography. The ciphersuites make useof symmetric key cryptography, which is fast for encryption but makesdistributing symmetric keys a di�cult task. Public key cryptographyis convenient for key distribution, but slow at encryption. As a con-sequence, the chosen solution uses public key cryptography as a se-cure means of distributing the keys for symmetric encryption. Thisclass contains the key transport functionality implemented based onthe DTN Security speci�cations.

• SPD: This class represents the Security Policy Database (SPD), whichcontains a collection of rules instructing what policy should be appliedto packets received and sent by the device. In the current DTN2.6implementation, it only supports global SPD for incoming and outgoingsecured bundles. It contains:

� Global PCB on/o� setting.

� Public keys for PSB and PCB.

In addition, the following classes are related speci�cally to the con�dentialityservice provided in the implemented ciphersuite.

• C_BlockProcessor: Block processor implementation for the PayloadCon�dentiality Block (PCB). This class extends from BlockProcessor


and implements a generic PCB processor. In the current implementa-tion, it calls the methods of Ciphersuite_C3, which is an implemen-tation of the ciphersuite PCB-RSA-AES128-PAYLOAD-PIB-PCB, asde�ned in the Bundle Security Protocol Speci�cation.

• Ciphersuite_C3: Block Processor implementation of the ciphersuitePCB-RSA-AES128-PAYLOAD-PIB-PCB, as de�ned in the Bundle Se-curity Protocol Speci�cation. It contains the code that does the "real"encryption work. For outgoing encrypted bundles, it implements therequired methods:

� Generate: creates an empty security block to be �lled in by pre-pare and �nalize.

� Prepare: generates the �rst round of security information, mainlyindependent data.

� Finalize: generates the last security information, which dependson already created �elds.

For incoming bundles, it implements the validate method.

Event: Bundle daemon is initialized

Fig. 4.3 presents a sketch of the actions that take place when the DTN sys-tem is started. When the program starts, the bundle daemon is initialized,as well as the di�erent components of the DTN system. Regarding the se-curity functionality, the do_init function starts up the implemented blockprocessors, the ciphersuites and the policy manager methods.


void BundleDaemon . do_init ( ){

BundleProtocol . i n i t_de f au l t_proc e s s o r s ( ) ;C iphe r su i t e . i n i t_de f au l t_c i ph e r s u i t e s ( ) ;SPD : : i n i t ( ) ;KeyDB : : i n i t ( ) ;

}

void BundleProtocol . i n i t_de f au l t_proc e s s o r s ( ){for ( every implemented b l o ckp ro c e s s o r block_proc_i )

r e g i s t e r_p ro c e s s o r (new s p e c i f i cB l o c kP r o c e s s o r ( block_proc_i ) ) ;}

void Ciphe r su i t e . i n i t_de f au l t_c i ph e r s u i t e s ( ){for ( every implemented b l o ckp ro c e s s o r block_proc_i ){new s p e c i f i cB l o c kP r o c e s s o r ( ) ;for ( every implemented c i p h e r s u i t e c ipher_i )new c ipher_i ( ) ;

}}

Figure 4.3: Bundle Daemon initialization event

Event: A bundle is being sent

Fig. 4.4 reviews the actions that occur when a bundle is sent. The classBundleProtocol invokes the prepare_blocks and generate_blocks meth-ods. These methods invoke the respective security block processor classesthat ultimately call the ciphersuite methods, which are the �nal workers.


void BundleDaemon . handle_bundle_send ( ){

BundleProtocol . prepare_blocks ( ) ;BundleProtocol . generate_blocks ( ) ;

}

void BundleProtocol . prepare_blocks ( ){SPD. prepare_out_blocks ( ) ;

}

void SPD. prepare_out_blocks ( ){

pol icy_out = obtain_current_pol icy_out ( ) ;for ( every c i p h e r s u i t e c ipher_i ){

i f ( pol icy_out == cipher_i . code ( ) )c ipher_i . prepare ( ) ;

}}

void BundleProtocol . generate_blocks ( ){for ( every block block_proc in the outgoing bundle )

block_proc . generate ( ) ;for ( every block block_proc in the outgoing bundle )

block_proc . f i n a l i z e ( ) ;}

void Spe c i f i cB l o ckPro c e s s o r . generate ( ){

c i p h e r s u i t e S p e c i f i c . generate ( ) ;}

void Spe c i f i cB l o ckPro c e s s o r . f i n a l i z e ( ){

c i p h e r s u i t e S p e c i f i c . f i n a l i z e ( ) ;}

Figure 4.4: Bundle Send event


Event: A bundle is received

Fig. 4.5 and 4.6 sketch the actions made when a bundle is received. In thiscase, there are two code sections that are sequentially executed. Firstly, aconvergence layer connection is detected and the method BundleProtocol.

consume is called. This method will examine the received bundle, and foreach block it will invoke the appropriate block processor to run the consumemethod. In the case of the security block processors, this method will in-voke Ciphersuite.parse, independently of which security block has beenreceived. Secondly, the bundle daemon invokes BundleProtocol.validate,which in turn will query which block processor should validate this block, andinvoke it. As in the previous case, the raw work is done by the speci�c cipher-suite, in the method validate. Once the received security block has been val-idated, the security policy is checked by the method SPD.verify_in_policy.

void Connection . handle_data_todo ( ){

BundleProtocol . consume ( ) ;}

void BundleProtocol . consume ( ){for ( every block in the bundle ){

i f ( b lock i s s e c u r i t y block ){

C iphe r su i t e . parse ( ) ;}

}}

void BundleDaemon . handle_bundle_receive ( ){

BundleProtocol . v a l i d a t e ( ) ;}

Figure 4.5: Bundle Receive event (1/2)


void BundleProtocol . v a l i d a t e ( ){

s p e c i f i cB l o c kP r o c e s s o r . v a l i d a t e ( ) ;SPD. ver i fy_in_po l i cy ( ) ;

}

void s p e c i f i cB l o c kP r o c e s s o r . v a l i d a t e ( ){

s p e c i f i cC i p h e r s u i t e . v a l i d a t e ( ) ;}

Figure 4.6: Bundle Receive event (2/2)

4.4 Summary

This chapter discussed the implementation process carried out in the thesiswork. We started by summarizing previous work performed in the DTNcommunity. After that we identi�ed the steps that we followed to implementthe required software. Finally, we provided a technical overview, which isuseful not only to understand the structure of our implementation, but alsothe reference implementation sketched by DTNRG.

Next chapter will depict an analysis of the performance in the implementedprogram.

Chapter 5

Performance Analysis

In the present chapter, we evaluate the implemented software according tothe criteria speci�ed in sec. 1.3 . The addition of security functionality to theAndroid project provides clear advantages such as data con�dentiality andintegrity protection that comply with the DTN speci�cations. However, asthe software will run in resource-constrained devices, it is relevant to analyzethe performance penalty that these security services have in the response ofthe system.

This chapter is structured as follows. Firstly, we detail the testing envi-ronment used in the performance analysis. Secondly, we examine the sizeoverhead of the security-protected bundles, which has direct consequencesin the program's throughput. Finally, we consider the energy consumptionpenalty of our implemented solution.

5.1 Introduction

Resource consumption is an everlasting concern in the scenario of mobiledevices. The technical speci�cations of smart-phones continue growing fol-lowing Moore's law postulate, but the complexity of the whole system growsat the same pace, continuously requiring extra resources to provide seamlessfunctionality.

Taking into account that our main objective is to recognize the performancecost of the security functionality, the tests need to be compared with theperformance of the program when the security services are not enabled. Thus,in the following analysis we compare and contrast our results with the onesobtained in a performance analysis made by a preceding Bytewalla team [55].

40

CHAPTER 5. PERFORMANCE ANALYSIS 41

5.2 Experimental Setup

We carried out all measurements in our DTN Lab. The bundles' payloadconsisted of random data generated in the DTN servers, and their size variedaccording to the needs of each test. The trials were executed during May2010 in KTH University campus, in Stockholm, Sweden.

5.2.1 Equipment Used

Our test environment consisted of two servers running DTN2.6 and two An-droid enabled phones running Bytewalla. The servers consist of Intel Celeron1.8 Ghz workstations with 512 MB of RAM, running Ubuntu 8.04 OS, con-nected to the network through a 100 Mbps Ethernet card. The involvedAndroid phones are HTC Tattoo, which runs Android 1.6 OS, a 528 MHzCPU and 256 MB of RAM, and HTC Nexus One, which runs Android 2.1-Update1, a 1 GHz CPU and 512 MB of RAM.

Fig 5.1 presents the connection scenario. Each server is associated with aunique network, and the Android phones can change from one network to theother to deliver the bundles. The test bundles are generated in the Villageserver, and sent to one of the Android clients. This client generates thecryptographic bundle and forwards it to the next Android client, which inturn decrypts it and forwards it to the City server.

Figure 5.1: Bytewalla security connection scenario

The following set of tools was employed.

• Perl: This language was utilized to run the scripts that send the bun-dles from the DTN servers to the Android phones in a controlled andrepeatable manner. The script (adapted from [55]) supports a numberof parameters, including number of bundles to generate, initial bundlesize, incremental value and the involved EIDs.


• Recording module in the Android phone: The existing recording mod-ule in the Android program was adapted to ful�ll the needed function-ality. It records the battery status change by calling the battery APIin Android.

• R language: This programming language was used to display the mea-sured data. It was chosen because it is a widely used Open Sourcelanguage, which can be operated both interactively and in batch modeusing scripts. In our case, we created scripts to generate the neededgraphs.

5.3 Size and transmission overhead

In this section we analyze the amount of additional data that is transmittedwhen the security services are enabled. We start by analyzing the size of aspeci�c DTN bundle with and without PCB enabled. Later on, we calculatethe size overhead and transmission time overhead.

5.3.1 DTN Bundle characteristics

We start considering a speci�c bundle with a payload of 10 bytes. Aftergenerating and sending the same message twice (with and without security),we analyze the transmitted bundle size in both situations. Fig 5.2 showsthe obtained bundles structure. Some considerations can be made about thesize and content change in the blocks. The primary block neither changes itssize nor its content: it is not altered at all by the security functionality. Thishappens because the information stored there, mainly source and destinationaddresses are not encrypted. There is no ciphersuite that can encrypt theprimary block, because the destination EID, which is included there, needs tobe known by intermediate routers to forward to bundles to destination. Thesize of the payload block does not change either, because the encryption algo-rithm used, AES in GCM mode, prevents expansion of the payload when theencrypted content is swapped [24]. This avoids fragmentation and reasemblyinconsistencies in the Bundle Protocol functioning [48]. As a consequence,we can see that the whole size overhead is constrained to the con�dentialityblock, which adds 372 bytes.


(a) Block structure of a non-protected bundle

(b) Block structure of a protected bundle

Figure 5.2: Structure of the analyzed bundle instance

Fig 5.3 provides a closer look inside the security block for the example bundle.Each of the �elds referenced here is explained in more detail in sec. 3.2, whereBundle Security Protocol is reviewed. In out test case, the block preamble(which includes type, block processing �ags, EIDs and block length) has asize of 4 bytes. The ciphersuite number and ciphersuite �ags follow, with2 bytes. Then, the ciphersuite parameters �eld (17 bytes) follows, whichcontains the salt and IV used in the encryption process. Finally, the securityresult data �eld (341 bytes) contains the integrity check value (18 bytes)and the key, encrypted and encoded in a CMS message (318 bytes). It isworth considering that the sizes can vary between bundles, and the presentedexample intends only to provide an idea of a security block. For example,the CMS encoded data can eventually contain a Certi�cate Revocation List(CRL), which might make the whole block size increase dramatically. All theaforementioned �eld sizes are independent of the payload to be encrypted.This fact is relevant to understand the following analysis.

Figure 5.3: Structure of the analyzed security block instance

5.3.2 Measurement

In order to measure the overhead incurred when sending encrypted and in-tegrity protected bundles, a test was arranged to compare the total bundlesize when the PCB functionality is enabled and disabled. We generated aset of 13 bundles with sizes ranging from 10 bytes to 100,000 bytes, to berouted in the sequence: village server - Android phone 1 - Android phone 2 -


Generated bundle ID 1 3 8 11 13Payload Size [bytes] 10 100 1,000 10,000 100,000

Primary block size [bytes] 123 123 123 123 123Payload block size [bytes] 13 103 1,004 10,004 100,005PCB block size [bytes] 372 372 372 372 372

Total size without security [bytes] 136 226 1127 10127 100128Total size with security [bytes] 508 598 1499 10499 100500

Size overhead [%] 273.5 164.6 33.0 3.7 0.4Calculated time overhead [sec] 0.007 0.007 0.007 0.007 0.007

Table 5.1: Size and transmission overhead

city Server. Table 5.1 presents an extract of the measurement of the size andtransmission time with security enabled and disabled. The primary blocksize resulted always 123 bytes, and the Payload con�dentiality block (PCB)was always 372 bytes. Those values were expected to remain constant, asexplained in the previous section.

Firstly, we analytically calculate the size overhead, based on the observedsize of the bundles. Fig. 5.4 shows how the overhead relative to the originalbundle size changes when we increase the bundle size. While the initial sizeoverhead for a small payload is high (273.5%), the overhead diminishes dras-tically when the payload size increases, following the mathematical functiony=1/x. This shows that the relative size in encrypted bundles is smallerwhen sending big bundles. Secondly, we analyze the bandwidth overheadincurred in the transmission. The program, according to previous studies[55] has an average measured transmission bandwidth of 50 KB/sec, whichmeans that in order to transmit the size of the security block (372 bytes inthis example), we spend an extra average time of 0.007 seconds. In prac-tice, it was not possible to distinguish any di�erence in the time spent whensending protected or non-protected bundles.

To summarize the size and transmission overhead analysis, we conclude thatthe relative size overhead when security is enabled is inversely proportionalto the payload size. On the face of it, this appears to imply that biggerbundle sizes are preferred. However, after measuring the absolute overheadtime in transmitting secured bundles, we proved that even in bundles withsmall payload size, the extra transmission cost (measured in time) incurredwhile sending and receiving security protected bundles is negligible.


Figure 5.4: DTN security: Relative size overhead

5.4 Energy Consumption

Energy consumption in handheld devices is a primary concern for mobiledevelopment. Some hardware-based measurement methods require physi-cal access to the battery and simple circuitry [32], while methods based onsoftware may call a provided API to query the battery status. Android OSprovides a mechanism to detect battery changes, by broadcasting the intentACTION_BATTERY_CHANGED, which contains charging state and battery levelthat can be queried from any Android application. We follow this latterapproach to measure the consumed battery when sending the protected bun-dles. This approach was chosen because it provides a non-intrusive way ofmeasuring battery changes that �t our purpose. In addition, it allows us tocompare our result with the previous analysis made for this implementationwhen security was not implemented.

5.4.1 Measurement

In order to measure the battery consumption incurred by our program, wegenerated a total of 75 DTN bundles being routed in the sequence: village


server - Android phone 1 - Android phone 2 - city server. The encryption wasapplied between the android phones, taking into account that the encryptionfunctionality has not been implemented in the C++ DTN2 version yet. Inour generation script we set the bundle repetition parameter to 3, the initialbundle size is 100 KB, each of the remaining bundles is incremented by 100KB and the number of repetitions is 25. Thus, the size of the last 3 bundlesis 2.5 MB. The total amount of data generated in this measurement is 95.21MB.

We chose to make the measurement in the HTC Android Tattoo phone, whichcan be considered a low end Android phone. In this way, we can predict thatother more advanced Android devices will outperform our test, thus ourmeasurement can be considered as a worst case scenario. In addition, thechoice of the HTC Tattoo device allows us to compare with the previousperformance analysis made by Bytewalla team.

The tests were executed starting with a fully charged HTC Tattoo phone.All other applications were closed to minimize external in�uence in the mea-surement.

5.4.2 Bundle Upload

Fig. 5.5 contrasts the cumulative battery consumption when uploading bun-dles with security enabled (the red curve), and disabled1(the blue curve).Several considerations can be made.

Firstly, we can notice that the program spent 40% of the battery to uploadthe total amount of 95.21 MB. From [55], the battery consumption afteruploading the same amount of data when the bundles are not protectedis 20%. This means that the addition of encryption doubles the batteryconsumption in the Android device.

1The statistics of the non-protected bundles are included with permission from [55]


Figure 5.5: DTN Bundle cumulative upload

Another analysis related to the battery consumption rate can be made. Ifwe consider the �rst 13 percentiles to predict a straight line, we obtain aline with a considerable slope of the way y=mx+b (green line). Likewise,we could generate a line with a lower slope if we consider the percentiles[24,40] (orange line). We can see that the �rst 15 MB of transmitted dataconsume battery at a high rate, while from 35 MB onward, the rate decreasesconsiderably. We can adduce this behavior to the nature of the encryptionapplied. As explained in sec. 3.2, two encryption mechanisms are used in theprogram for every transmitted bundle. First, we apply public key encryptionto decrypt/encrypt the symmetric key (which has always the same size), andafter that, we encrypt the whole payload with symmetric key encryption(which has an execution time that is proportional to the payload size). The�rst section of data consists of small bundles, which means that the expensivepublic key computations need to be made more frequently. On the otherhand, the last section of data consists of bigger bundles, which require lesspublic key encryption and more symmetric encryption computation per dataunit.


5.4.3 Bundle Download

Fig. 5.6 presents the cumulative battery consumption when downloading en-crypted bundles (red curve), and non-encrypted bundles (blue curve). In thiscase, an analog analysis to the upload case can be made. After having down-loaded 95.21 MB of bundles, the cumulative battery consumption is 44%. Onthe other hand, [55] calculated that the cumulative battery consumed afterdownloading the same amount of bundles is 25%. From these measurements,we can conclude that the security services add a battery overhead of 76%when downloading encrypted bundles.

Similarly to the upload case, if we consider the �rst 15 percentiles to predict astraight line, we obtain a line with a considerable slope (green line). Likewise,we generate a line with a lower slope if we consider the percentiles [27,44](orange line). The �rst 6 MB of transmitted data consume battery at a highrate possibly due to a high rate of public key encryptions performed, whilefrom 18 MB onward, the rate decreases steadily as the packet size increases.

Figure 5.6: DTN Bundle cumulative download


5.4.4 Upload / Download Comparison

Fig. 5.7 shows a comparative graph between the cumulative upload anddownload battery consumption for secured DTN bundles. We can observethat the download operation consumes more battery that they upload one.This follows the trend of the original program without encryption, wheredownload operations were slightly more battery-consuming.

There can be an additional reason for the battery consumption di�erence be-tween the download and upload time. We have already mentioned that RSAoperations are considerably more expensive that symmetric key encryption.There is also a speed di�erence between encrypting and decrypting, whichis related to the public key exponent (known as e). When the exponent issmall, the encryption operations become more e�cient [37]. In our program,encryption is carried out when a bundle is uploaded (by using the recipi-ent's public key) and decryption is made when a bundle is downloaded (bymeans of the private key). In the generation of the key pairs, we use BouncyCastle [5] provider for RSA, and the generated public exponent is by default0x010001, which means that the encryption operations (upload in our case)could be comparatively faster than decryption operations (download).

Figure 5.7: Comparison between download and upload battery consumption


5.5 Summary

In this chapter we have analyzed the performance penalty induced by theaddition of security functionality. We can conclude that the size and trans-mission overhead when security is enabled are negligible. However, the cryp-tographic operations require extra CPU resources, which spend considerablebattery resources and increase the processing time needed between the bun-dles are received and they are available to be processed by the DTN API. Onaverage, the battery consumption when uploading encrypted bundles dou-bles the battery spent when uploading non protected bundles. In addition,when downloading protected bundles, the average extra battery spent is 76%compared with the non-protected transmission.

As a �nal note, it is worth mentioning that heavy CPU consuming opera-tions such as encryption are expected to require a certain amount of extraresources. On top of that, the comparison was made against the originalBytewalla operation, which does not make any intensive processing (it onlysends or receives bundles, saving them into memory). Hence, the di�erencein relative consumption is more noticeable.

Next chapter will focus on the security aspects of the original Bytewallaapplication. We will identify, rate and intend to mitigate the discoveredthreats.

Chapter 6

Security Assessment for

Bytewalla Application

In this chapter we perform a security analysis for the Bytewalla Applicationintroduced in chapter 1, by means of the Threat Modeling procedure, asde�ned in [40].

We start by decomposing the application architecture to discover the vul-nerabilities that it may have and by identifying the threats that are relevantto the application. After that, we analyze how the addition of DTN secu-rity functionality helps in addressing these threats and vulnerabilities, byevaluating the strength of the proposed solution.

6.1 Threat Modeling

The use of threat modeling allows us to identify and rate the threats thata�ect the Bytewalla application. In this way we can privilege the addressingof problems that pose a higher risk.

The threat modeling process involves di�erent steps, namely:

• Identify the assets to be protected.

• Create an architecture overview of the system.

• Decompose the application.

• Identify and document the threats.

51

CHAPTER 6. SECURITY ASSESSMENT FOR BYTEWALLA APPLICATION 52

• Rate the Threats.

The following sections describe each of the process steps.

6.1.1 Assets Identi�cation

In this section we identify the assets that the system has to protect.

As already mentioned in Sec. 1.2, the Bytewalla application allows sendingand receiving emails between city and village servers by implementing theDTN Bundle Protocol. The main asset that we need to protect is the datatransported as emails. It needs to be protected the whole path, since theemails are sent from a host in one network until they are received by anotherhost in the receiving network, considering all the transport means that thedata passes through.

6.1.2 Architecture Overview

In this section we document the function of Bytewalla application by speci-fying its use cases, its architecture and the technologies that constitute thesolution.

Use Cases

We can identify the following use cases:

• A user sends an email from a host attached to the village wirelessnetwork into the Bytewalla village server.

• A mule (person carrying an Android phone with the Bytewalla applica-tion) wirelessly connects to the Bytewalla server and receives a streamof bundles containing the emails to be transported to the other end.He moves to the city, carrying the phone with the application. Finallyhe connects via wireless to the Bytewalla city server, and transfers thebundles.

• The Bytewalla city server receives the outgoing bundles from the mule,unwraps them to obtain the plaintext emails and forwards them toInternet.


• The Bytewalla city server receives an email destined to a host insidethe Village. It wraps it into a DTN bundle and sends it to the mule.The whole process is carried out in an analog way.

• A user connects to the Bytewalla village server via wireless connectionand receives an email destined for him from the server.

Architecture

Fig. 6.11 and �g. 6.22 show the components of the Bytewalla system for thevillage and city scenarios respectively. The Bytewalla village architecturecomprises:

• A sender/receiver that implements a Mail User Agent (MUA)

• The Bytewalla server which contains a DTN implementation, a mailtransfer agent (MTA), a mail delivery agent (MDA) and an IMAPserver.

• The Android mule, which implements DTN.

The Bytewalla city architecture is analog to the village scenario, but theserver works as a gateway to route messages to Internet.

Figure 6.1: Bytewalla Village Architecture Overview

1From [50], with permission2Based on [50], with permission


Figure 6.2: Bytewalla City Architecture Overview

Employed Technologies

The most relevant technologies that comprise the Bytewalla program aredepicted in table 6.1

Technology/Platform Implementation DetailsAndroid SDK 1.6 The Bytewalla DTN implementation and mail pro-

grams were implemented in this platform.C++ The DTN implementation in the servers was de-

veloped in C++.SQLite for Android 1.6 The database used in the Bytewalla DTN imple-

mentation relies in this technology.Post�x This mail system runs in the Bytewalla servers.Python Python Scripts are used for integrating PostFix

with DTN2.Email clients Are involved in sending and receiving emails from

the servers.IEEE 802.11 (Wi-Fi) This technology is used to connect hosts with

servers.

Table 6.1: Used technologies

6.1.3 Application decomposition

In this section, we break down the Bytewalla application into its components.We identify trust boundaries, entry points and privileged code.


Trust Boundaries

A trust boundary de�nes a limit in the system, where on one side data istrusted, and on the other side, it is potentially untrusted and needs to beprotected.

In the Bytewalla application we can de�ne the following trust boundaries:

• Bytewalla servers.

• Android client running Bytewalla.

• Hosts (e.g., workstations with mail clients in the village).

When data is passed between trust boundaries (e.g. between a server anda Bytewalla Android client) we assume that the data can be malicious andshould be validated.

Entry Points

Entry points in the Bytewalla application can also be entry points for at-tackers. By analyzing the communication paths between entities in �g. 6.1and �g. 6.2, we can identify the entry points speci�ed in table 6.2.

Entity Entry PointBytewalla servers TCP port 25 (SMTP): Port used for outgoing mail trans-

port from a village host to the village mail server.Bytewalla servers TCP port 143 (IMAP): Port used for retrieving mail

messages by the village hosts in the village and by otherInternet users in the city.

Bytewalla servers TCP port 4556 (DTN): Standard port used by the DTNservice to receive DTN connections.

Android mule TCP port 4556 (DTN): Standard port used by the DTNservice to receive DTN connections.

Table 6.2: Entry Points in the Bytewalla system

Privileged Code

Privileged code has access to speci�c secure resources (such as �le system,registry and event logs) and must be validated when it is executed. In the


case of Bytewalla, the developed Android application performs privilegedoperation like accessing sockets for network communication with the servers,serializing objects to be saved into the database and accessing the SD card�le system to save the bundles payload. All these operations need to beprotected against code modi�cation. With this objective, Android providesa signature mechanism, to assure that the executed code has not been altered.

6.1.4 Threats Identi�cation and Documentation

In this section we identify the threats that can a�ect our Bytewalla appli-cation. We base our analysis in the STRIDE method [40], and the analysismade in the previous sections. We identify two kinds of threats, namelynetwork and application threats.

Network Threats

We can recognize the following network related threats in the Bytewallaapplication:

• Information gathering attack

The DTN servers do not use Firewall, so there are unnecessarily reach-able ports. This situation could lead to potential threats in the servers,in case any of the redundant ports opens a door for a vulnerability. Pas-sive attackers can execute information gathering attacks, where theygain information about the servers through the open ports and canattack known vulnerabilities.

• Unauthorized DTN network usage

The Bytewalla program does not protect the resource usage of theDTN network. In case that a business model is introduced, a fee wouldbe involved in each email sent through DTN. Currently, any Androidphone with an installed instance of Bytewalla can send messages to thecity server, which would be routed to Internet without accounting.

Application Threats

In order to analyze the threats in the Bytewalla application, we make use ofthe STRIDE method, which proposes categories of threats to be consideredin any application. The threats are listed as follows.


• Identity spoo�ng

Both the Android and C++ DTN implementations rely solely on the IPaddress to authenticate the other party. The source of an IP packet canbe easily forged by means of IP spoo�ng. This could allow an attackerrunning an instance of Bytewalla in the Android phone to pretend tobe a valid mule and receive data from the DTN server not intended forhim. A countermeasure is to authenticate the involved parties at theDTN layer by applying DTN security services.

• Man-in-the-Middle attack in the wireless communication

An attacker can modify data in transit from a host to the mail server,and from the mail server to the Android client, because none of thesecommunications is protected.

• Tampering attack in the SQLite database and �le system inAndroid

Another tampering threat can succeed in the SQLite database and inthe location of bundles payload in the SD card. In both cases thedata is not protected in any way and a tampering attempt cannot bedetected.

• Eavesdropping in the wireless communication and in the bun-dles stored in the Android system

Neither the wireless communication nor the DTN bundles are protectedagainst information disclosure, allowing a passive attacker to monitorthe tra�c and sni� the emails that are sent from a host to the server,and from the server to the Android client. A possible countermeasureis to use WPA2 encryption in the WiFi connection or DTN encryptionin the DTN transport layer. In addition, the Android client carriesbundles with email content in the clear, allowing the carrier to accessthe content and eventually modify it.

• Denial of Service attack

An attacker with an installed instance of Bytewalla could issue a DoSattack against the DTN server, e.g. by sending a sequence of bundleswith a big size, which would prevent the server from processing otherrequests and provoking a disruption in the service.


6.1.5 Threats Rating

In this section we rate the aforementioned threats by means of the DREADmethod, which is a risk assessment model proposed by Microsoft. We choosea rating (between 1 for low risk and 3 for high risk) for di�erent categories:damage potential, reproducibility, exploitability, a�ected users and discov-erability. After the individual values are set, the total speci�es the kind ofthreat: between 5 and 7 the threat importance is low; between 8 and 11 thethreat importance is medium; between 12 and 15 the importance is high.Table 6.3 presents the result of the rating process.

Threat D R E A D Total RatingInformation gathering attack 3 1 1 1 1 7 LowUnauthorized DTN network usage 1 2 2 3 3 11 MediumIdentity spoo�ng 2 3 2 3 3 13 HighMan-in-the-Middle attack in the wire-less communications

3 2 2 3 3 13 High

Attacker tampering with the SQLitedatabase in Android

2 1 1 3 2 9 Medium

Attacker tampering with bundlesstored in the SD card in Android

3 2 2 3 2 12 High

Eavesdropping in the Wireless com-munication

2 2 2 3 3 12 High

Eavesdropping in the bundles storedin Android

2 2 2 3 3 12 High

Denial of Service in the DTN servers 2 3 2 3 1 11 Medium

Table 6.3: DREAD rating for the threats in Bytewalla

6.1.6 Threat Modeling Output

The threat modeling output document allows to understand the threats thathave to be addressed, and the preference order in which they should beaddressed. This document, available in Appendix A, summarizes the analysisthat we have already made in this chapter into a compact components list.It consists in a list of threats for the application including the threat target,risk involved and proposed countermeasures.


6.2 Integration of Security Functionality

In the previous section we obtained a list of threats that should be mitigatedand we categorized them among high, medium and low importance. In thissection we consider how the addition of DTN security functionality into theBytewalla system addresses these threats and vulnerabilities.

As already explained in sec. 4.1, the current C++ reference implementationof DTN2, which is also used in the Bytewalla application, has not fully im-plemented the security mechanisms de�ned in the standards yet. However,as the reference implementation will follow the DTN Security speci�cation, itis expectable that its behavior will be similar to our speci�cation-compliantAndroid implementation. As a consequence, we can analyze how security inthe Bytewalla system can be enhanced when we integrate our Android DTNsecurity mechanisms, in addition to the upcoming C++ security functional-ity.

In this section we analyze how to mitigate the aforementioned risks, by mak-ing use of the DTN security mechanisms in both the C++ and Android im-plementations, as well as other security practices that could help in securingthe Bytewalla system.

High Risk Threats Mitigation

We analyze possible solutions for the high risk threats. These risks must beaddressed before any real world deployment of Bytewalla.

• Identity spoo�ng

Although we cannot avoid an attacker from spoo�ng an IP address, wecan mitigate the consequences of this threat by applying DTN security.If we encrypt the bundle payload with the recipient server's publickey, the attacker will have no access to the bundle plaintext, and thereceived payload will be of no use.

• Man-in-the-Middle attack in the wireless communications

This threat can be mitigated by applying a wireless security scheme,like IEEE 802.11i (WPA2) in the wireless links, because it this way, onlyauthenticated parties can communicate. Hence, an attacker would notbe able to carry out the attack, e.g., by spoo�ng the identity of one ofthe Bytewalla servers.


• Attacker tampering with bundles stored in the SD card inAndroid

This threat can be mitigated by applying DTN encryption to the pay-load.

• Eavesdropping in the Wireless communication

This threat can be mitigated by applying a Wireless security scheme,like IEEE 802.11i (WPA2) in the wireless links.

• Eavesdropping in the bundles stored in Android

This threat can be mitigated by applying DTN encryption to the pay-load.

As a summary, we can specify that all the high risks threats can be mitigatedif the system implements DTN security and at the same time, it protects theWI-FI communication by applying an encryption scheme like WPA2.

Medium risk threats Mitigation

In this section we analyze the mitigation of medium risk threats. It is highlyadvisable to address them, unless the cost for the solution is prohibitivelyexpensive.

• Unauthorized DTN network usage

This threat can be addressed by authenticating DTN nodes, by meansof hop-by-hop DTN security integrity, which uses certi�cates.

• Attacker tampering with the SQLite database in Android

This threat can be mitigated by using full database encryption. An-droid does not provide this mechanism in the current release, but itcan be implemented by using open source solutions, or by encryptingthe data before being inserted into the database.

• Denial of Service (DoS) in the DTN servers

DoS attacks can be partially addressed by authenticating DTN users.However, DoS attacks are still an open issue in DTNs and research isbeing carried out in this area.


Low risk threats Mitigation

In this section we consider the mitigation of low risk threats. Addressingthem is not mandatory, and might be subordinated to the costs and resourcesinvolved.

• Information gathering attack

This kind of attacks can be mitigated by enabling a Firewall in thea�ected Bytewalla servers.

6.3 Evaluation of Protection Provided by Bun-

dle Protocol Security

In this section we analyze the strength of the security scheme de�ned inthe Bundle Security Protocol for the implemented ciphersuite: PCB-RSA-AES128-PAYLOAD.

Sec. 4.1 discussed the encryption scheme used in DTN security. For sym-metric key encryption the ciphersuite uses AES in GCM mode, with a keysize of 128 bits. NIST states that the use of the block cipher AES-128 isbelieved to provide security beyond 2030 [9].

In addition, the randomly generated symmetric key has to be a secure ran-dom number. RSA is used for key transport. In order to have a period ofsecurity valid beyond 2030, NIST recommends that the RSA algorithm usedshould have a key size (i.e., the size of the modulus n) of at least 3072 bits.However, our Android implementation uses certi�cates generated with a keyof 1024 bits. This fact downgrades the overall level of security provided tothe equivalent of 80 bits of strength, which according to NIST should belimited to the year 2010. In order to maintain the original level of security,certi�cates with a key size of 3072 bits should be used.

6.4 Summary

In this chapter we performed a security assessment of the Bytewalla applica-tion. We started by building a threat model to identify and rate the possiblethreats to the system. Later on, as the application evolves to support securityfunctionality, we have evaluated the strength of this solution.


By means of this documentation, we have identi�ed not only what the knownthreats are, but also how they have been addressed, with the objective ofputting us in control of the security of the Bytewalla system.

However, it is worth noting that the threat modeling process is not a onetime only process. It is an iterative process that needs to continue during allthe application life cycle. In case that the application adds new functionalityin the future, e.g. GPRS support, the threat modeling process should berepeated to follow the Bytewalla application evolution.

Next chapter will conclude the thesis, by analyzing how the objectives havebeen accomplished and describing future work to be carried out.

Chapter 7

Conclusion

The Bytewalla project was created with the objective of providing Inter-net connectivity to rural villages by means of Android phones carrying animplementation of the DTN Bundle protocol. In order to provide a seam-less security functionality for Bytewalla as well as for other Android DTNdeployments, this thesis work was arranged.

More speci�cally, the main goal of the thesis work was the implementation ofsecurity mechanisms in the Bundle Protocol for the Android platform, andan analysis of the quality of the developed solution.

7.1 Evaluation

We have implemented a security solution for DTNs which is fully compliantwith the Bundle Protocol Security speci�cation. During this process, wefollowed recommended coding-style guidelines to allow future developers touse and extend our solution, as well as the abstraction layers proposed bythe DTNRG reference implementation.

We pursued a performance analysis in the deployed solution, and we concludethat the use of security does not increment the size of the protected datanoticeably, but it clearly increments the energy consumption required in themobile devices, nearly doubling the battery usage, due to the high processingpower involved in the cryptographic operations and the extra time needed tocomplete these operations.

We performed a security assessment of the application by following formalthreat modeling techniques, considering also the threats that would arise

63

CHAPTER 7. CONCLUSION 64

when the application is deployed in a commercial scenario. We concludedthat after applying DTN security services to the application layer and WIFIsecurity (WPA2) to the link layer, all the high and medium risk threats areaddressed for this application.

As a consequence of the aforementioned results, we believe that after applyingthe developed security services, the application is ready for testing in a realworld testbed.

7.2 Limitations

Although our implementation is compliant with the DTN Security speci�ca-tions, we could not test its interoperability because the reference implemen-tation has not fully implemented the security mechanisms for DTN yet, andthis is a limitation of our program at the present time.

Another limitation in our solution is the high performance loss when encryp-tion is enabled. However, it is worth noting that the performance comparisonwas made against the original Bytewalla application, which only sends andreceives DTN bundles, without making any processing. Because of that, thedi�erence in consumption relative to each of the versions is more noticeable.

7.3 Future Work

The DTN community encourages all DTN implementations to inter-operatewith the reference implementations. When the security mechanisms are re-leased in the reference implementation, a useful future work would be to testthis implementation against it.

In the present thesis work we implemented a ciphersuite that provides allthree security services altogether: encryption, integrity protection and au-thenticity. An interesting future work would be to implement the otherremaining ciphersuites that provide only hop-by-hop authentication (BAB)and end-to-end authentication (PIB).

Finally, the performance of our application could be improved, e.g. by choos-ing another set of security libraries, or when Bouncy Castle support is imple-mented natively in the Android SDK. It is worth mentioning that the newAndroid OS version 2.2 includes a native Just In Time (JIT) compiler, whichallegedly increases performance in a noticeably way, mainly in mathemati-cal computations. This feature is likely to improve the computational time

CHAPTER 7. CONCLUSION 65

required for the security services to work.

Bibliography

[1] Interplanetary Overlay Network (ION), Project web site at Ohio Univer-sity. Available at: https://ion.ocp.ohiou.edu/index.php (AccessedMay 2010).

[2] Java Programming Style Guidelines. Available at:http://geosoft.no/development/javastyle.html (Accessed May2010).

[3] JavaDTN: A Java Port for Bytewalla DTN. Available at:https://wiki.umiacs.umd.edu/VirtualMeshTest/index.php/JavaDTN

(Accessed May 2010).

[4] JUnit.org. Resources for Test Driven Development. Available at:http://www.junit.org/ (Accessed May 2010).

[5] Legion of the Bouncy Castle Java cryptography APIs. Available at:http://www.bouncycastle.org/java.html (Accessed May 2010).

[6] Networking for Communications Challenged Communities: Ar-chitecture, Test Beds and Innovative Alliances. Available at:http://www.n4c.eu/ (Accessed March 2010).

[7] TSLab. Bytewalla - Final Report. Available at:http://www.tslab.ssvl.kth.se/csd/projects/092106/sites/

default/files/ Bytewalla_Final_Report_v1.0.pdf (AccessedMarch 2010).

[8] United Nations. Criteria for identi�cation of Least Developed Coun-tries. Available at: http://www.unohrlls.org/en/ldc/related/59/

(Accessed March 2010).

[9] Barker, E., Barker, W., Burr, W., Polk, W., and Smid, M.

NIST Special Publication 800-57. NIST Special Publication 800 (2007),57.

66

BIBLIOGRAPHY 67

[10] Berners-Lee, T., Fielding, R., and Masinter, L. Uniform Re-source Identi�er (URI): Generic Syntax. RFC 3986 (Standard), Jan.2005.

[11] Braden, R. Requirements for Internet Hosts - Communication Layers.RFC 1122 (Standard), Oct. 1989. Updated by RFCs 1349, 4379.

[12] Burleigh, S., Hooke, A., Torgerson, L., Fall, K., Cerf, V.,Durst, B., Scott, K., and Weiss, H. Delay-tolerant networking:An Approach to Interplanetary Internet, 2003.

[13] Çayirci, E., and Rong, C. Security in Wireless Ad Hoc and SensorNetworks. John Wiley & Sons Inc, 2009.

[14] CCSDS. Consultative Committee for Space Data Systems (CCSDS).Available at: http://public.ccsds.org/about/default.aspx (Ac-cessed March 2010).

[15] CCSDS. CCSDS File Delivery Protocol (CFDP). Rec-ommended Standard, January 2007. Available at:http://public.ccsds.org/publications/archive/727x0b4.pdf.

[16] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R.,Scott, K., Fall, K., and Weiss, H. Delay-Tolerant NetworkingArchitecture. RFC 4838 (Informational), Apr. 2007.

[17] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L.,

Durst, R., Scott, K., Travis, E., and Weiss, H. In-terplanetary Internet (IPN): Architectural De�nition, 2001. Avail-able at: http://ipnsig.org/reports/memo-ipnrg-arch-00.pdf (Ac-cessed March 2010).

[18] Demmer, M. The DTN Reference Implementation. Presen-tation - IETF DTNRG Meeting, March 2005. Available at:http://www.ietf.org/proceedings/62/slides/DTNRG-3/dtnrg-3.ppt


[19] Demmer, M., and Ott, J. Delay Tolerant Networking TCP Conver-gence Layer Protocol. Internet-Draft (Experimental), 2008.

[20] Directive, E. Directive 2002/49/EC of the European parliament andthe Council of 25 June 2002 relating to the assessment and managementof environmental noise. O�cial Journal of the European CommunitiesL 189, 12 (2002), 18�7.

BIBLIOGRAPHY 68

[21] Doering, M., Lahde, S., Morgenroth, J., and Wolf, L. IBR-DTN: An E�cient Implementation for Embedded Systems. In Proceed-ings of the Third ACM Workshop on Challenged Networks (2008), ACM,pp. 117�120.

[22] Doria, A., Uden, M., and Pandey, D. Providing Connectivity tothe Saami Nomadic Community. generations 1, 2 (2002), 3.

[23] DTNRG. Delay Tolerant Networking Research Group. Available at:http://www.dtnrg.org/ (Accessed March 2010).

[24] Dworkin, M. NIST Special Publication 800-38D: Recommendation forBlock Cipher Modes of Operation: Galois/Counter Mode (GCM) andGMAC. US National Institute of Standards and Technology (2007).

[25] Edney, J., and Arbaugh, W. Real 802.11 security: Wi-Fi ProtectedAccess and 802.11 i. Addison Wesley Publishing Company, 2004.

[26] Eggert, L., and Gont, F. TCP User Timeout Option. RFC 5482(Proposed Standard), Mar. 2009.

[27] Fall, K. A delay-tolerant network architecture for challenged internets.In Proceedings of the 2003 conference on Applications, technologies, ar-chitectures, and protocols for computer communications (2003), ACMNew York, NY, USA, pp. 27�34.

[28] Fall, K., and Farrell, S. DTN: An Architectural Retrospective.Language 733 (2008), 8716.

[29] Farrell, S., and Cahill, V. Delay- and Disruption-Tolerant Net-working. Artech House, Inc., Norwood, MA, USA, 2006.

[30] Farrell, S., Cahill, V., Geraghty, D., Humphreys, I., andMcDonald, P. When TCP Breaks: Delay-and Disruption-TolerantNetworking. IEEE Internet Computing 10, 4 (2006), 72�78.

[31] Farrell, S., Symington, S., Weiss, H., and Lovell, P. Delay-Tolerant Networking Security Overview. IRTF, DTN Research Group(2008).

[32] Fitzek, F. External Energy Consumption Measurements on MobilePhones. Mobile Phone Programming , 441�447.

BIBLIOGRAPHY 69

[33] Housley, R. Using AES-CCM and AES-GCM Authenticated Encryp-tion in the Cryptographic Message Syntax (CMS). RFC 5084 (ProposedStandard), Nov. 2007.

[34] Internet World Stats. World Internet Users and Population Stats.Available at: http://www.internetworldstats.com/stats.htm (Ac-cessed March 2010).

[35] IPNSIG. Internet Society. Interplanetary Internet Project. Availableat: http://www.ipnsig.org/ (Accessed March 2010).

[36] Jain, S., Fall, K., and Patra, R. Routing in a Delay TolerantNetwork. In Proceedings of the 2004 Conference on Applications, Tech-nologies, Architectures, and Protocols for Computer Communications(2004), ACM New York, NY, USA, pp. 145�158.

[37] Kaliski, B., and Staddon, J. PKCS# 1: RSA cryptography speci-�cations version 2.0. Tech. rep., RFC 2437, October 1998.

[38] Karl, H., and Willig, A. Protocols and architectures for wirelesssensor networks. John Wiley & Sons Inc, 2005.

[39] Kruse, H., and Ostermann, S. UDP Convergence Layers for theDTN Bundle and LTP Protocols. Internet-Draft (Experimental), 2009.

[40] Meier, J., Mackman, A., Dunner, M., Vasireddy, S., Es-

camilla, R., and Murukan, A. Improving Web application security:threats and countermeasurers. Microsoft, 2003.

[41] NASA. Jet Propulsion Laboratory. Available at:http://www.jpl.nasa.gov/.

[42] Norris, P. Digital divide: Civic engagement, information poverty, andthe Internet worldwide. Cambridge Univ Pr, 2001.

[43] Pentland, A., Fletcher, R., and Hasson, A. Daknet: Rethinkingconnectivity in developing nations. Computer (2004), 78�83.

[44] Postel, J. Transmission Control Protocol. RFC 793 (Standard), Sept.1981. Updated by RFCs 1122, 3168.

[45] Richardson, D. The Internet and rural development. Washington DC:Food and Agriculture Organisation. IBA+ SATRA= SACRA. SouthernAfrican Wireless Communications Journal 5 (2000), 16�17.

BIBLIOGRAPHY 70

[46] Scott, K., and Burleigh, S. Bundle Protocol Speci�cation. RFC5050 (Experimental), Nov. 2007.

[47] Symington, S. DTN Security. Presentation -IETF DTNRG Meeting, March 2005. Available at:www.ietf.org/proceedings/62/slides/DTNRG-4/dtnrg-4.ppt


[48] Symington, S., and Farrell, S. Bundle Security Protocol Speci�-cation. Draft (Experimental), 2010.

[49] Telchemy, I. Impact of Delay in Voice over IP Services. TelchemyApplication Notes, Series VoIP Performance Management (2006), 1�7.

[50] TSLab. Bytewalla: Delay Tolerant Network on Android phones. Avail-able at: http://www.tslab.ssvl.kth.se/csd/projects/092106/

(Accessed March 2010).

[51] Victor, R. Iterative and Incremental Development: A Brief History.IEEE Computer Society (2003).

[52] W. Scheirer, M. C. Dtn security features technical report. Tech. rep.,Lehigh University for DARPA, 2006.

[53] Wood, L., Holliday, P., Floreani, D., and Eddy, W. Sharingthe dream. Workshop on the Emergence of Delay-/Disruption-TolerantNetworks (E-DTN), part of the International Conference on Ultra Mod-ern Telecommunication (ICUMT), St. Petersburg, Russia (2009).

[54] Wood, L., Ivancic, W., Eddy, W., Stewart, D., Northam, J.,

Jackson, C., and da Silva Curiel, A. Use of the delay-tolerantnetworking bundle protocol from space. In Proceedings of the 59th As-tronautical Congress, Glasgow. IAC (2008).

[55] Yanggratoke, R. Bytewalla: Delay Tolerant Networks on Androidphones: Performance Analysis Report.

[56] Zhang, Z. Routing in intermittently connected mobile ad hoc networksand delay tolerant networks: Overview and challenges. IEEE Commu-nications Surveys & Tutorials 8, 1 (2006), 24�37.

Appendix A

Threat Modeling Output for

Bytewalla

This document presents the threats in the Bytewalla application, includingrisk level and possible countermeasure.

Threat Description Identity spoo�ng: An attacker with Bytewalla re-ceives bundles from server via spoo�ng

Threat target Bytewalla serverRisk HighCountermeasures Authenticate involved parties at the DTN layer using

DTN security services

Table A.1: Threat 1: Identity spoo�ng

Threat Description Man-in-the-Middle attack in the wireless communi-cations

Threat target Android client and serversRisk HighCountermeasures Secure the wireless links

Table A.2: Threat 2: Man-in-the-Middle attack

71

APPENDIX A. THREAT MODELING OUTPUT FOR BYTEWALLA 72

Threat Description Attacker tampering with bundles stored in the SDcard in Android

Threat target Android ClientRisk HighCountermeasures Encrypt bundles payload at DTN layer.

Table A.3: Threat 3: SD card data tampering

Threat Description Eavesdropping in the Wireless communicationThreat target Android client and serversRisk HighCountermeasures Encrypt wireless link

Table A.4: Threat 4: Eavesdropping in wireless communication

Threat Description Eavesdropping in the bundles stored in AndroidThreat target Android ClientRisk HighCountermeasures Encrypt bundles payload at DTN layer.

Table A.5: Threat 5: Eavesdropping in Android data

Threat Description Denial of Service in the DTN serversThreat target DTN serversRisk MediumCountermeasures Apply security services

Table A.6: Threat 6: Denial of service attack

Threat Description Unauthorized DTN network usageThreat target Accounting system in serversRisk MediumCountermeasures Protect DTN resource by authenticating users

Table A.7: Threat 7: Unauthorized DTN usage

APPENDIX A. THREAT MODELING OUTPUT FOR BYTEWALLA 73

Threat Description Attacker tampering with the SQLLite database inAndroid

Threat target Android clientRisk MediumCountermeasures Encryption of the SQL Lite database

Table A.8: Threat 8: SQLite data tampering

Threat Description Information gathering attackThreat target DTN serversRisk LowCountermeasures Enable �rewall in servers, e.g., iptables

Table A.9: Threat 9: Information gathering attack

security in delay tolerant networks for the android platform · aalto university abstract of the...

Documents