Adopting Device Communities for Modern Android Systems

(1)

Adopting Device Communities for Modern Android Systems

Simen Persch Andersen

Thesis submitted for the degree of

Master in Informatics: Programming and System Architecture

60 credits

Department of Informatics

Faculty of mathematics and natural sciences

UNIVERSITY OF OSLO

(2)

(3)

Adopting Device

Communities for Modern Android Systems

Simen Persch Andersen

(4)

Adopting Device Communities for Modern Android Systems http://www.duo.uio.no/

Printed: Reprosentralen, University of Oslo

(5)

Abstract

The ever-increasing abundance of Internet communication in various forms brings a similarly increasing need for security and privacy.

This usually introduces inconvenience to the end users and requires trust in third party service providers.

A viable solution to some of these concerns is DevCom, a network system that provides secure, trust-worthy, persistent and independent communication within communities of devices.

This thesis presents DevComJavaMobile, an Android port of the DevCom network concept from the Linux operating system.

DevComJavaMobile brings DevCom to modern Android devices via a user- friendly application.

We detail the background and motivation behind the port, the development process that led to its success, a deeper dive into its functionality and architecture, conduct an evaluation of the app as it is before presenting further work that can be done.

(6)

Acknowledgements

First and foremost, I would like to thank my supervisor, Thomas Peter Plage- mann, who consistently provided helpful advice on short notice.

His supervision has been excellent and our meetings and e-mail transactions have always pushed me in the right direction.

I would also like to thank Hans Vatne Hansen for his eagerness to provide thoughtful answers to my questions about his network concept, despite being busy with work.

Furthermore, I would also like to thank Pavel Shramau for letting me access his previous work on the domain and the research and help his 2019 thesis gave me.

I would also like to thank my brother, Bendik, for taking time off to help me troubleshoot the application when I was completely stuck and for providing helpful tips and words of encouragement.

I also reckon that a thanks to HTTP Toolkit creator Tim Perry is in place, given the tremendous work he has done in collaboration with volunteering developers to create this open source project and for allowing me to use a screen shot of the HTTP Toolkit desktop application in my thesis.

Last, but not least, I would like to thank my friends and family for the support, inspiration and words of encouragement.

Their support gave me the energy and motivation necessary to carry on with the thesis when I encountered various road blocks.

(7)

Terms and Abbreviations

AES Advanced Encryption Standard AGPL Affero General Public License

API Application Programming Interface AVD Android Virtual Device

CA Certificate Authority

Cyber Term affectionately used as a pre-fix to Internet related activi- ties

DNS Domain Name System

Flashing Overwriting existing device firmware GUI Graphical User Interface

HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure

ID Identity

IDE Integrated Development Environment IP Internet Protocol

IPv4 Internet Protocol Version 4

(11)

IPv6 Internet Protocol Version 6 IT Information Technology

mDNS Multicast Domain Name System

MP Megapixel

NAT Network Address Translation NDK (Android) Native Development Kit NFC Near-Field Communication

P2P Peer-to-Peer

PKCS1 Public Key Cryptography Standards 1 PKCS8 Public Key Cryptography Standards 8 PhD Philosophical Doctorate

QR Quick Response

RAM Random Access Memory

RSA Rivest–Shamir–Adleman public-key cryptosystem Root Super user with full access privileges

TAP Virtual Network Device capturing ethernet frames TCP Transmission Control Protocol

TUN Virtual Network Device capturing internet frames UDP User Datagram Protocol

VPN Virtual Private Network

(12)

Chapter 1

Introduction

We begin this thesis with a chapter that first explains the background and motivation behind the work we present, followed by a section discussing the problems we have solved, before we conclude the chapter with an outline of the thesis.

1.1 Background and Motivation

We live in a day and age when we are surrounded by digital computing devices that are central to our day-to-day lives.

The rise of what has later been come to be known as the Digital Revolution, beginning at the latter half of the 20th century [1], has brought many new revo- lutionizing technologies, which has given birth to a vast array of new industries, revolutionized existing ones and overall made a big, lasting impact on our lives and the world as know it.

Arguably the most impactful of these technologies is the advent of the Internet, which first appeared as an early iteration known as an Arpanet in 1969 [2].

Not only does the Internet give most of the world nearly limitless access to information, it also lets us communicate, socialize, share and access resources unlike ever before in human history.

The Internet grants us access to tools earlier generations could merely dream of, but it does however also come with its set of challenges.

One of those is that of security, and belated to that, privacy.

The more of our personal and work life resides on the Internet in one way or another, the more vulnerable we become to malicious parties accessing and using this information in ways that can be harmful.

(13)

Security and privacy protection is though unfortunately synonymous to many with inconvenience.

DevCom, a network concept envisioned and developed by Hans Vatne Hansen in 2013 [3] aimed to bring a solution to some of these issues.

It would grant users access to so-called ”Device communities” in which members are able to communicate, share and collaborate securely and in a user-friendly manner.

The concept he developed does however have two major problems regarding accessibility and usability.

By being developed on and only for the Linux [4] operating system, an operating system with a low adoption rate in the consumer space [5], the accessibility to consumers is limited.

With no graphical user interface to speak of, relying solely on console commands for its operation, the user-friendliness, while arguably still being better than equivalent solutions, has room for improvements.

Pavel Shramau aimed to address some of these concerns by porting the Linux implementation to Android [6][7].

Being the basis of his master thesis in 2019, it was to be an application that would adopt the DevCom network concept to the Android system and provide users with a graphical user interface to operate its features.

Due to issues with access privileges restricting regular Android users from important kernel drivers vital to DevCom functionality, the application could not be ported as planned.

For this reason, Shramaus work shifted towards solutions to the problem.

One of the possible solutions presented in his final thesis is to re-develop most, or all of the DevCom code base in Java or Kotlin.

This serves as the basis and motivation behind our work.

We present an application that manages to adopt the device community concept to modern Android devices.

This thesis discusses the development process behind the application ’DevCom- JavaMobile’, how it works, what it managed to achieve from what we sought out to, what it did not and how these areas can be improved through future work.

(14)

1.2 Problem Statement

We argue that DevCom has a lot of potential as a platform that enables a unique approach to solve some of the issues related to security and privacy within network communication.

The availability and accessibility of this platform is however restricted due to its nature of being a console application only available on the Linux operating system.

By developing an Android application that adopts the core concepts of DevCom to the Android platform, we are able to alleviate these problems by granting the availability of the network concept to a wider range of users.

We aim to achieve this with a user-friendly application that requires little prior preparation or technical knowledge by the end user.

Furthermore, we believe the evolution of technology, the nature of a mobile device platform vs a desktop environment and by learning from previous mistakes, that we can make improvements in other areas as well.

If they make sense in the context of the application, we aim to include such improvements in addition to adopting the core concepts of DevCom.

1.3 Outline

This thesis contains six chapters, followed by an appendix that contains link to the GitHub page containing the code for the application we present.

The first chapter introduces the thesis with a background and the motivation behind the work, followed by a description of the problem.

Chapter 2 provides a more in-depth description of the DevCom network concept, what it aimed to solve, how it works and what we consider the main areas it needed to be improved in.

Following this section, we give a brief overview of Shramaus DevComApp, the goal behind this app, how it failed and the possible solutions suggested, before we finish of with a related application vital to our projects success, i.e. HTML Toolkit [8].

Chapter 3 discusses the domain in which the application we present can be used, related technologies and unique benefits to DevCom and DevComJavaMobile.

Chapter 4 covers the main contribution of this thesis, the Android application DevComJavaMobile. In this chapter, we describe development requirements, processes and decisions made, the functionality and architecture of the application as well as core concepts of the application, how these are implemented and

(15)

how they can be improved upon.

Chapter 5 presents the experiments that were done, before we evaluate how well the requirements discussed in Chapter 4 were met.

Finally, we conclude the thesis with Chapter 6 by summarizing our contributions, assessing these contributions and the thesis as a whole before we present suggestions and ideas for future work related to this thesis.

(16)

Chapter 2

Background

This chapter describes the background of the work presented in this, from the original network concept developed by Hans Vatne Hansen as part of his PhD, to the attempted Android port of the same concept by Pavel Shramau in 2019.

We cover DevCom, the motivation behind developing it, followed by a description of the solution along with its design and architecture.

We discuss some of the areas of improvement this application had, which led to the development of DevComApp by Shramau.

Then we explain what this application aimed to do, where it failed to meet its goals and where it set the foundation for our contribution.

Lastly, this chapter describes the open source HTTP debugging, testing and building tool called ”HTTP Toolkit”, a source of inspiration that proved vital to our projects success.

(17)

2.1 Preceding work

The basis of our works lies in the network solution called ’DevCom’.

DevCom is a Linux-based network concept, developed in the C programming language, that allows users to easily organize devices in multiple trustworthy communities, dubbed device communities, and communicate, share and collaborate securely within these.

Shortcomings in terms of user-friendliness, usability and accessibility led the ground work for future improvements, some of which Shramau aimed to address with the work for his masters thesis on the Android application ’DevComApp’.

DevComApp aimed to adopt all the principles of DevCom by implementing as much of the existing C code as possible to an Android application, addressing some of the shortcomings in the process.

This work failed due to unforeseen challenges regarding root privileges, which was uncovered too late in the development process to be properly addressed in a working solution.

As a consequence of this, his work shifted at this point to researching theoretical solutions on how these device privileges could be circumvented, by presenting six possible solutions.

Five of the solutions presented still required root access, eliminating a large user base which have no desire or willingness to ”root” their Android devices, which led to the final, most challenging, but potentially possible solution, re- developing the application in Java [9] or Kotlin [10].

Ultimately, the clue which led to this conclusion, was the discovery of the Android API package ”VpnService” [11].

This API grants developers endpoints to access some of the features of the TUN/TAP [12] virtual network device driver, a driver that without these endpoints, accessed directly via C, requires the aforementioned root privileges.

(18)

2.2 DevCom

This section covers DevCom, the network concept developed by Hans Vatne Hansen in 2013 for his PhD at the University of Oslo, in collaboration with his supervisor Thomas Peter Plagemann.

We briefly describe the solution and what it aims to achieve that no other similar solution could at the time, how it works and the architecture that makes up the functionality and lastly, some of the areas that were left open for improvement.

2.2.1 Description of DevCom

DevCom is, in the words of Hansen, a”network system that provides users with a trustworthy and user-friendly way to communicate, share and collaborate among distinct groups of devices simultaneously” [13].

This is done by developing a new concept of ’Device communities’ where users within their respective communities trust each member to share information regarding who to trust, how to connect to each member, relay data on behalf of, and more.

To achieve this concept, three main contributions were achieved in developing this novel concept:

• a unique device community approach,

• a novel self-configuration mechanism, and

• a completely decentralized, self-organizing, user-friendly and trustworthy system that is achieved without developing new security and privacy solutions.

Hansen argues that Mark Weisers vision of ubiquitous computing [14] is achieved quantitatively through our modern world’s nearly unlimited access to data networks such as Wi-fi and cellular, through a variety of computing devices such as mobile phones, tables, laptop computers and more.

Qualitatively however, Hansen argues that Weisers vision of ubiquity still re- mains.

This aspect of his vision is covered when unconscious human-computer interaction via seamless communication, sharing and collaboration between devices is achieved.

Files, peripherals and services are some of the things that according to Hansen are not always accessible on the devices available and proper security and pri-

(19)

vacy protection makes the availability of such resources even more difficult.

This problem contributed to Hansens motivation for developing DevCom.

DevCom is a solution that aims to provide users with privacy and security in what can be seen as ageneric trustworthy platform for all types of network applications through devices communities [13].

His goal was to achieve this functionality with seamless integration with other applications and minimal user interaction.

2.2.2 Design

DevCom works in many ways similar to how Virtual Private Networks (VPN) work in that member admission is controlled, communication is encrypted and data is only transmitted to whom it concerns.

The core differences between DevCom and a traditional VPN are decentraliza- tion, meaning no third party entities are involved, as well as being able to be part of several network simultaneously, an essential part of ubiquitous computing.

To achieve this, a network stack was developed where applications use either existing transport layer services, or opt in to transmit their data within Dev- Coms device communities by providing the necessary destination addresses in the IP headers.

These destination addresses are unique to DevCom and are one of the key aspects that arrive from DevComs self-configuration mechanism.

In order to provide user mobility and maintain application sessions despite ever- changing physical location addresses, a virtual IP layer that exists above the current, unmodified Layer 3, i.e. the IP layer, was created.

This allowed the use of the aforementioned static addresses that are consistent no matter what the physical location address changes to.

Considering the complete exhaustion of the IPv4 address space, however, these addresses could not be used.

To combat this exhaustion, virtual IPv6 addresses are used as identifiers and provided as the destination address in DevCom-specific network packets.

These static virtual addresses are created automatically and without user interaction via DevComs self-configuration mechanism and consist of three parts:

A pre-fix, community name and device fingerprint.

In order to minimize the probability of an IPv6 address conflict on a global

(20)

scale, the first 16 bits of the 128 bit address consist of a link-local pre-fix,fe80.

This is a pre-fix reserved for local network communication and point-to-point communication, making these addresses only ”compete” with the local network or other devices known directly to the device in mind.

The next 48 bits are used to represent one of the device communities the receiving device may be part of, describing the first six characters of the community name, represented by the hexadecimal values of said characters in the ASCII table.

The last 64 of the 128 bit address represent the unique device fingerprint, accu- mulated from the modulus value of the device’ public cryptography key.

Figure 2.1: DevCom Addresses Example (Hansen et al 2014)

(21)

2.2.3 Device communities

The fundamental feature that DevCom consists of and the feature that inspired the name of the system is that of device communities.

This feature attempts to provide user-friendly and trustworthy communication, sharing and collaboration among any devices the community members desire to include.

Network systems like VPN only allow devices to be part of one network at a time, prohibiting the concurrent use of services at multiple locations, e.g., con- trolling a remote desktop at work from their home while sharing files and folders with friends and using the printer they have installed at their home network.

These services can at the very least not be accessed simultaneously unless one wishes to expose endpoints to them over the world wide web, a difficult task for most users and a possible security risk.

DevCom presents a solution to this problem with its device community concept.

It achieves this functionality via a few key concepts.

In order to send information to the correct recipient and within the correct community, it uses the self-configurated IPv6 addresses mentioned in the previous section and demonstrated in Figure 2.1.

Within these communities, a set of defined control packet types are supported in order to ensure control, what devices are to trust, member devices to be evicted, the last known physical location address of a peer and more.

Lastly, a requirement for this concept to be considered safe to adopt is that of privacy and security.

This is ensured by using state-of-the-art cryptography along with the mentioned device control mechanisms.

(22)

2.2.4 Architecture

The overall architecture of DevCom can be divided into four separate modules, the Virtual Interface Manager, Key Manager, Overlay Manager and Data Man- ager.

The overarching roles they play in the system can be seen in Figure 2.2.

This section details what tasks these modules are designed to perform in Dev- Com.

Figure 2.2: DevCom Architecture (Hansen et al 2014)

(23)

Virtual Interface Manager

The Virtual Interface Manager is responsible for establishing the virtual network interface where all network traffic, DevCom-specific or not, gets routed through, as well as for assigning the virtual device community addresses.

Key Manager

The key manager is responsible for creating symmetric and asymmetric keys used for authentication, encryption, decryption and ensuring packet integrity.

Packets used to establish connections as well as the rest of the control messages are encrypted using asymmetric RSA encryption, while the more lightweight and efficient symmetric AES 256 encryption standard is used for data transmission.

Overlay Manager

The Overlay Manager is responsible for membership management and to maintain the control channels to the devices’ known peers.

These control channels manage the decentralized virtual overlay be sending and receiving control messages.

These control messages consist of the following six types:

• T(rust)is sent to members of the respective communities with the public key of the device members are instructed trust.

• D(istrust) is sent to members of the respective communities with the fingerprint of the device members are instructed to delete the public key of, which accomplishes the task of no longer trusting this community member.

• J(oin)is sent when establishing a control channel to another device and includes a session exclusive symmetric encryption key.

• L(ocations) is sent to inform about the last known physical location addresses of a device in the community.

• S(ync) is sent to initiate synchronization within a device community which means exchanging L(ocations) and T(rust) messages.

• P(acket)is used as an alternative to sending data when data channels are unavailable, e.g. due to UDP port blocking.

(24)

Figure 2.3: DevCom Control Message Structure (Hansen et al 2014)

Data Manager

The Data Manager is responsible for the data channels.

These channels encrypt data from the tunnel upstream and sends them to its correct recipient, and decrypt incoming data.

This data is, after decryption, passed on to the tunnel in the downstream for the intended application to receive.

(25)

2.2.5 Joining a device community

In order for users to join a device community, two pre-requisites are needed for this process to be accomplished.

1. Knowledge of the current physical address of a device within the community they wish to join.

2. A public key exchange needs to take place between the users device and the device it wishes to connect with, prior to connecting.

When these pre-requisites are met, the new member can join the community by sending a J(oin) message, establishing a control channel between it and the device receiving the J(oin) packet.

Upon joining a device community, a synchronization process may be initiated, which begins and exchange of physical location addresses and public keys.

This process is demonstrated with an example in Figure 2.5.

Figure 2.4: DevCom Connection Process Example (Hansen et al 2013)

(26)

In this example, device A wishes to join the ”work” community by sending a J(oin) message to device community member B.

The connection is established and device A and B can safely communicate with each other.

Device A then wishes to be able to part of the entire community and therefore needs the public key information and physical location address of the rest of the community.

To acquire these, device A begins a synchronization process by sending a S(ync) message to device B.

This synchronization is done by sending T(rust) and L(ocations) messages, containing public keys and physical location addresses respectively, from devices C and B to A, as well as the other way around.

This concludes the synchronization process and device A is now able to send J(oin) messages to the remaining members, establishing control channels with them.

In this example, device A is not able reach device D due to a blocking firewall.

However, device D recognizes that it has received the public key and physical address of device A from B, but no control channel has been established.

As a consequence, device D sends a J(oin) message to A, establishing a success- fulreverse connection.

2.2.6 Firewalls and NAT

An important topic particularly difficult when developing Peer-to-peer communication is that of bypassing Firewall restrictions as well as challenges introduced by NAT.

In order to penetrate NATs, techniques such as reverse connections and relaying is used.

DevCom is also able to bypass four filtering techniques that Firewalls may implement.

These four filtering techniques are deep packet inspection, port blocking, UDP blocking and host blocking.

Attempting to block traffic based on data content via deep packet inspection is made next to impossible due to the entirety of the data packets in DevCom, including its protocol headers, being encrypted.

In many cases, port blocking can also be circumvented because data is not being sent to the actual service port it is intended for, but rather tunneled to the DevCom port first, before DevCom delivers the packets to the final intended

(27)

port after it has reached the device.

In the case of UDP blocking, TCP is used as a fallback transport protocol through the use of P(acket) control messages sent via control channels, offering an alternative protocol when UDP is unavailable.

Lastly, host blocking can be circumvented by relaying P(ackets) through other hosts in the community.

Firewalls are however also used for DevComs benefit.

By allowing for service and application restrictions within certain device communities, DevCom can e.g. allow features such as a video streaming service for devices in the ”home” community, but deny the same feature in the ”work”

community, either inbound, outbound or in both directions.

2.2.7 Areas of improvement

DevCom brings some innovative and unique solutions to problems that secure and private network communication introduces, but there are certainly are areas with potential for improvements.

For one, some of the features Hansen mentions as part of the concept like NAT traversal through relaying and most of the key sharing solutions were not implemented due to time constraints.

Arguably the biggest problem with DevCom though, is that of usability and availability to consumers.

DevCom was developed as a Linux-based network concept controlled through a console application.

This alone limits the availability of the platform to only a handful of the global population due to the small adoption of Linux as an operative system [5], outside of server hosting [15] and some other professional use cases.

The vast majority of computer users use Windows or Mac as their main operating system and in this day and age, many seldom use their computers or even have one at all, rather opting to mobile devices and tablets for the vast majority of their computational usage.

Furthermore, there is the problem of a console based application.

While one could argue that most Linux users are familiar with console applications due to how much of the different Linux distributions is based around console usage as is, it still creates a hurdle for anyone and is not an argument that can be used in one wishes to expand beyond the scope of the more techni- cally novice.

(28)

Furthermore, how this console application is used even when familiar with console commands can be argued to also not be straight-forward.

These problems combined led to the idea of developing a mobile application that can make the concept available to a much wider variety of end users and grant these users a more user-friendly and easily understandable graphical user interface. This premise is the basis of Pavel Shramau’s work on DevComApp.

(29)

2.3 DevComApp

DevComApp is the name of the Android application envisioned by Shramel Pavau for his masters thesis that he began his work on in the autumn semester of 2018 [6].

It was to be an adoption of the DevCom concept to the Android operating system that would present the users with a user-friendly graphical user interface.

This interface was meant to grant easy access to the functionality of DevCom to Android users, with an additional shifted focus towards the health sector.

Shramau aimed to provide doctors, patients and close relatives to the patient with a secure way to share sensitive information within device communities, e.g.

from health sensor IoT-devices connected to the patients’ smart phones.

This development unfortunately failed due to the discovery of a problem related to access privileges that could not be circumvented.

Establishing the virtual network interface from the TUN/TAP-driver [12], necessary for the tunneling aspect of the application, required root access to the phone in order to be established when programming in the C language, as was done in the original application.

Shramau initially thought this problem could be overcome, but it proved difficult at the late stage he was in the development process and so he shifted his focus to researching possible solutions to this problem.

This led to the discovery of six possible solutions:

• Converting the application to a system app with NET ADMIN permission.

• Patching the Android kernel to a fork which allows the C code not per- mitted in the native DevCom code base to be ran.

• Installation of a custom ROM(firmware) on the devices that are to run DevCom, where the user is able to grant root access and permit the blocked C code.

• Binding a socket to the virtual network interface.

• Running DevCom as a binary executable file which DevComApp interacts with through APIs exposed by this executable.

• Re-implementing DevCom in Java or Kotlin in order to take use of the VpnService API [11] used by a variety of Android VPN apps that uses it to get access to a TUN virtual network interface.

(30)

The first five suggested possible solutions did however have the same fundamental problem Shramau encountered in his development, namely requiring root access to the phone or being workarounds that grants users root access through custom firmware installations.

All of these five solutions would require an amount of effort and other down sides one could not expect end users to take on themselves.

The sixth and last alternative, on the other hand, was deemed as a more realis- tic solution as this would not require any extra steps for the end users to install and use compared to any other Android application.

This is what led to idea of the application presented in this thesis.

(31)

2.4 HTTP Toolkit

We conclude this chapter by introducing the open-source HTTP debugging, testing and building application vital to our projects success called ’HTTP Toolkit’

[8].

Most articles, forum discussions and other belated Internet material would lead one to believe that the VpnService API can only be used to build a VPN client used to access a VPN server.

Our research could also not find any mention of tunneling from one Android device to another, which made us question whether the functionality was at all possible with the solution suggested by Shramau, or any other end points available on Android.

This belief changed upon the discovery of HTTP Toolkit, an open source project led by Tim Perry.

In short, HTTP Toolkit uses a TUN virtual network interface established via the VpnService API to intercept and re-direct all inbound and outbound network traffic to a proxy established on a desktop computer on the same local network the Android device resides.

This desktop runs the proxy via a corresponding HTTP Toolkit application, which grants the users the ability to modify the packets as they please.

This means either re-writing packets in certain ways before being passed back to the Android client, stopping them from ever being sent or received by the Android client or re-direct them entirely.

The possibilities are varied and is entirely up to the user.

HTTP Toolkit is developed for a variety of different use cases, like mocking endpoints or entire servers, simulating traffic delays, testing how certain applications react to certain data and more.

Our interest, however, relies entirely in how HTTP Toolkit intercepts this data.

Rather than re-direct packets to a proxy, DevCom modifies DevCom-specific packets locally, by encrypting and directing the data to its correct physical address.

HTTP Toolkit demonstrates how this interception and re-direction can be done via its publicly available source code [16].

Another vital contribution the HTTP Toolkit source code granted us is classes and functions that both split packets into bytes and nibbles, as well as re- building them to packets that can be read and understood by Javas network functionality.

(32)

Considering tunnel traffic read and written to and from the virtual network is done so on a byte-by-byte basis, class structures that are able to parse and re-build UDP, TCP, IPv4 and most other standard internet protocols saves a tremendous amount of overhead one otherwise would have to take on one self.

Figure 2.5: HTTP Toolkit desktop dpplication screenshot taken from http- toolkit.com

All code used from HTTP Toolkit was taken from its open GitHub page [16]

and is used under the AGPL v3 Open-Source license [17].

(33)

Chapter 3

Application Domain

In this chapter we explain the domain in which DevCom and, by extension, DevComJavaMobile aims to bring solutions to existing problems.

We begin with a section on Security and Privacy, some existing solutions that tackles the issues DevComJavaMobile addresses, yet how they in the process either introduce other problems the concept does not, or fail to address issues the latter solution does.

Finally, we cover some of the wide ranges of use cases the concept can be used for.

3.1 Security and privacy

Security and privacy are two topics of ongoing discussion that is unlikely to ever become irrelevant.

Our society is becoming more dependent on IT solutions every year and thus, more of our data is being stored, shared and otherwise transmitted over the Internet.

This is all contributing to making each and every one of us increasingly suscep- tible to ”cyber” attacks, from both a personal and economical perspective.

The advent of the Covid-19 pandemic [18] that officially went global in March of 2020 made this trend skyrocket at an even greater pace than usual.

All jobs that were practically feasible to be done from home were done so, which gave an unprecedented rise to a need for Internet communication, particularly in the video and text communication space.

Riding on this demand, a relatively new at the time video communication software, Zoom [19], became widely adopted, almost overnight.

While Microsoft [20] was struggling to keep up with the sudden increase in de-

(34)

mand for their Teams [21] platform [22], both businesses and private individuals sought alternatives and found the ease of us, stability and free nature of Zoom desirable.

However, it did not take long for controversies surrounding this software to emerge in regards to both security and privacy.

In turned out that Zoom’s end-to-end encryption was not quite that, that Zoom attendees could see a lot more about you than many were comfortable with and that unwanted parties could attend meetings they were not invited to [23].

The latter issue in fact became so prevalent that it gave rise to a new expression through ”Zoom bombing”.

While privacy on the Internet is still a topic that many remain to be con- vinced of the importance of, e.g. citing that ”they have nothing to hide”, most of us are aware of the importance of security, to a certain degree.

A problem with security, however, is that it often means problems and annoy- ances for users.

This annoyance comes in many shapes and forms, from having to remember tens of dozens of passwords and bringing along objects required for two-factor authentication, to restricting personal freedom and work efficiency through lack of access rights.

In the case of Zoom, even though the security and privacy controversies surrounding the platform was common knowledge at the time, people still stuck with the platform for a lack of viable alternatives and we have more or less accepted that security is synonymous with annoyance.

DevComJavaMobile cannot solve all of these issues, but it does aim to provide an alternative to secure Internet communication, all while being entirely self- reliant and easy to use.

(35)

3.1.1 VPN

A technology that also has become much more relevant since the start of the 2020 pandemic and that in many ways works similar to DevCom is Virtual Pri- vate Networks or VPNs.

Like DevCom, it creates tunnels that sends end-to-end encrypted data from one point to another.

It does however have its issues that DevComJavaMobile addresses.

One of those issues is that of multiple connections. With VPNs, you are only able to connect to one network at a time. Files, folders, appliances etc. in other networks remain unavailable, unless reachable via end points exposed to the Internet.

This becomes an issue when you want to connect to e.g. your work space to access files stored here, your home space where you have a printer installed and a remote desktop connection to a server in another location.

Furthermore, unless you configure the VPN connections on your own, VPN services require third party providers.

These can be costly and brings its own set of both privacy and security concerns in that you have to trust the provider, that they are able to handle your data securely and does not use it with malicious intents, e.g. by selling it to other parties.

VPN servers can be self-configured, but this usually requires a lot of advanced configuration most users are either not able or willing to engage in.

DevCom addresses these issues by allowing for connections to a multiple of device communities that works as separate networks, by being entirely self- reliant, self-configuring and easy to set up.

(36)

3.2 Application scenarios

This section discusses how the application we present and DevComs community concept can be used in general, first covering the approach of Shramaus Dev- ComApp [6], before discussing DevComs original intent, which aligns closely with the approach we have with DevComJavaMobile.

Shramau envisioned in his idea for DevComApp for it to be a communi- cations app primarily aimed at the interaction between doctors, patients and relatives to the patient [24].

Health data is always of a very sensitive nature. There is a lot of confidentiality when dealing with such information and to keep this confidentiality when communicating such data over the Internet, it is vital that proper security is in place.

For this reason, Shramau thought of DevComApp as an app that could connect all interested parties in a patient’s case to each other within DevComs device communities.

One of the scenarios this can be used is that of when a patient wears a health monitoring device that connects to their phone.

Rather than have either the patient monitor and alert the doctor, who might not be able to control their phones properly in an emergency scenario, or the doctor who has a multitude of patients do it, close relatives would be able to be a part of these communities and be alerted when something happens, keep a close check on any anomalies detected and check up on the patient, communicate with doctors, emergency numbers etc.

This approach to device communities is certainly a novel idea we believe has great potential, but rather than focus on a specific domain and limit the use case for this, the focus for the application we present is rather to build a frame work in which any sort of communication can be transmitted safely within set communities.

This can include anything from sending texts, pictures and files, to accessing printers, desktops and other devices or services and even streaming movies, making video calls etc.

We developed DevComJavaMobile to make all of this possible, easy to use, end- to-end encrypted, entirely self-reliant and while one is able interact with other communities simultaneously.

(37)

Chapter 4

DevComJavaMobile

The solution presented in this thesis is an Android Application with the working name of ’DevComJavaMobile’.

This chapter first explains our general approach to develop this application and some of the more core design choices.

Then we discuss the core functionality that was made possible from this development, the core parts, both from a graphical user face perspective, how the programming logic works, as well as cover what can be considered the most essential parts of the code that makes the application we present able to perform its tasks.

Lastly in this chapter, we go through some of the more broad concepts that make up this application, how these are covered in the solution and some brief suggestions on how we envision these aspects of the application can be improved.

4.1 Development

This section covers the development of DevComJavaMobile.

First we discuss the requirements we set before the beginning of the development and then we discuss some of the core development discussions that were reached, both before and during the development.

(38)

4.1.1 Requirements

Before we began the development of DevComJavaMobile, we set ourselves some key design requirements that we aimed to achieve.

Given the nature of the applications origins, the requirements are quite similar to the ones Hansen set during his development, with a few key exceptions.

Our approach to user-friendliness and how this is achieved differ from Hansens approach [3], mostly given that we are developing for a different platforms that have entirely different design requirements and user bases.

We have also introduced two key requirements, namely that of compatibility and heterogeneity, and shifted the focus in the other areas slightly given the different contexts the two applications are developed within.

• Compatibility

DevComJavaMobile is based on the Linux application DevCom developed by Hans Vatne in 2013 and is a tried and tested concept that provides unique functionality that provides users with secure and reliable connections to multiple users within communities. For this reason, we want the application we develop to be compatible with this application, to a reasonable extent. By reasonable extent, we mean that DevCom more than likely has room for improvement in terms of technology and design and if flaws are found, improvement suggestions should be proposed and implemented. Furthermore, we argue that it is only natural that a mobile application in a controlled environment like that of the Android operating system has its limitations relative to the open-source operating system that are Linux distributions, and certain limitations are to be expected as a result.

These limitations should be accepted, as long as they do not interfere with what can be considered the core aspects of DevCom.

• User-friendliness

We argue that a big hurdle within the original DevCom Linux application is its user-friendliness. First and foremost, it is all controlled within a terminal window with user-written commands, which in and of itself presents a challenge for most users. Secondly, lack of documentation and instructions also provides a challenge to set up communities and establish connections between these communities. We want to remedy this hurdle by providing an easy-to-use application, with unambiguous GUI elements that users only need the most basic technical knowledge to operate.

(39)

• Heterogeneity

We want the application to be usable by most Android devices by developing an application that requires little in terms of computing power, back- wards compatibility to versions of Android that most users have installed on their devices. We also do not want to require any prior preparation, like ”flashing” the system to an Android version that grants the user with

”root” privileges.

• Security

The traffic in the connections provided by DevCom needs to be fully end- to-end encrypted with the latest widely accepted encryption protocols that have stood the test of the public’s breaching attempts.

• Mobility

DevComJavaMobile needs to provide mobility by allowing users to use the application on mobile devices with changing physical location addresses, e.g. when switching between WLAN and mobile internet, without requiring any additional setup and minimal, to no noticeable delay in network traffic.

• Persistent connections

By providing alternate means of transmission protocols, state-of-the-art Firewall and Network Area Translation (NAT) penetration techniques, as well as self-configuring connections, we want to provide robustness in terms of persistent connections despite numerous common challenges introduced by Firewalls, NAT, poor connections etc.

• Expandability

By operating between the application layer and the network layer on the Internet protocol stack, we aim to make DevComJavaMobile application independent and practically make applications unaware of DevComs existence, only requiring knowledge of device community addresses to use the concept.

(40)

4.1.2 Development decisions

In order to achieve the design requirements outlined above, certain crucial design decisions had to be made that may, depending on the severity, drastically change the direction of the development process.

Here we list some of the more important design decisions that were met both early on in the project and as it evolved.

Android Studio

The Android Studio [25] integrated development environment (IDE) developed by JetBrains [26] in collaboration with Google [27] was used as developing platform due to its integrated support for Android emulation, robust and easy to use Graphical User Interface (GUI) designer and Android Gradle [28] support, the build system for Android based on Gradle [29] and supported by Google.

Programming language

The research provided by Pavel Shramau [6] on DevCom and his attempt to port the application to Android devices made him discover that the native C code in the original DevCom application required root access and that there were no alternatives in the Android ecosystem that let him circumvent this issue, while still keeping the core of the application written in the C programming language.

Upon further research, it was discovered that by using either Java [9] or Kotlin [10], one could have access to a vital API added by Google to Android through API level 14, which came bundled with Android 4.0, called VpnService [11].

VpnService allows developers to access the TUN-device on the system with several supporting API calls, mainly intended to be used for VPN connections like those provided through OpenVPN [30] and similar solutions.

Given that establishing a TUN-device through native C code requires root access to the device and that this was the roadblock Pavel faced in his work, this indicated that there might be a solution through this API call. For this reason, Shramau suggested that an application that uses the same design principles as DevCom may be possible to re-build from the ground up using either Java or Kotlin.

Developing such an application is a tremendous task in and of itself, and time restraints led Shramau to conclude that this would have to be left as potential future work.

All official Android API documentation suggests that either of these two lan- guages can be used for the same task, given that all Android APIs in one language is available in the other as well.

(41)

A key difference, however, is the availability of both online documentation by other sources, such as forum discussions, code guides and published open source codes, as well as the prevalence of external libraries.

In these respects, given the longevity and familiarity of Java to developers, in contrast to Kotlin, a lot more resources are available in support of Java . For these reasons, Java was chosen as the programming languuage for DevCom- JavaMobile.

Importing C code using Android NDK

Given that the entirety of DevCom developed by Hans Vatne was written in C, and therefore, all the work there had already been done, we argue that it makes sense to adopt as much as possible to DevComJavaMobile, both for the sake of time savings and for compatibility reasons.

Android supports the import of code written in C to a Java or Kotlin applications through the Android Native Development Kit [31], more widely known with the abbreviation NDK.

Some of the code of DevComJavaMobile was initially imported by utilizing this functionality.

However, the use of a TUN virtual network interface requires the use of Java or Kotlin, and to keep things compatible we implemented all other network related logic, such as sockets, data transfer logic, network packet inspection, creation and manipulation and more using Java.

This logic, however, proved difficult to merge with the encryption logic we suc- cessfully imported from DevCom.

Converting Java data to C-compatible data and back again for encryption, decryption, packet signing in particular was the road block we encountered that led us to reconsider the use of C altogether.

Research led to the discovery that the encryption standards used in DevCom are available through the use of native and external Java libraries.

As a result of this and the belief that further use of C was likely to bring similar set of challenges, importing C through Android NDK was dropped and we focused on porting the entire concept to Java.

Development devices

Android Studio allows quick and easy compilation of Android apps for either physical devices connected to the development computer, or virtual Android devices.

For the virtual devices, a Google Pixel 4 and Pixel 2 XL running Android API

(42)

level 30, introduced with Android version 11, was chosen as emulation devices, while a Samsung [32] Galaxy S8+ running Android 8.0 was used as a physical Android test device.

A 2020 MacBook Pro [33] was used for both testing and development purposes and a virtual machine, hosted by the development machine via VMWare Fusion [34] and running Ubuntu 21.04 [35], was used to test DevCom and other Linux- specific C code.

(43)

4.2 Functionality

The Android application we present in this thesis adopts the core principles of Hansens DevCom framework which allows for entirely self-reliant, VPN-like and end-to-end encrypted communication across several devices.

DevComJavaMobile provides this functionality, adopted from a Linux application written in C and operated by console commands, to a simple-to-use Android mobile application.

This section explains the basis of the functionality achieved with DevComJava- Mobile.

4.2.1 Tunneling

The basis of DevComJavaMobiles functionality revolves around the virtual network tunneling interface.

TUN virtual network devices, short for TUNnel, is mainly used to intercept traffic from and write to use space programs, which enables the use of VPN functionality.

For this reason, Android has decided to name the service that is established to access said tunnel device ”VpnService” Google describes this service as follows:

”In general, it creates a virtual network interface, configures addresses and routing rules, and returns a file descriptor to the application. Each read from the descriptor retrieves an outgoing packet which was routed to the interface. Each write to the descriptor injects an incoming packet just like it was received from the interface. The interface is running on Internet Protocol (IP), so packets are always started with IP headers. The application then completes a VPN connection by processing and exchanging packets with the remote server over a tunnel.”

Despite this description and even though the service is called VpnService, it is not limited to Android device - VPN server communication.

By configuring the VpnService to intercept all traffic, one can filter out or read all application traffic and manipulate said traffic, e.g. to specify the destination address to any address of choice.

In the case of DevComJavaMobile, this means filtering out IPv6 traffic that has the link-local pre-fix of fe80 and that contains known community and device fingerprints. The content of these packets are then wrapped as fully encrypted IPv4 packets with their respective physical destination addresses.

All other traffic is sent back to the tunnel device in the upstream, meaning it gets sent as normal traffic, completely unaware of the existence of DevCom.

(44)

4.2.2 Device Community Communication

The ability to intercept and manipulate user space network traffic creates the foundation for the device community communication in both DevCom and De- vComJavaMobile.

This section covers how communication within these communities are handled, from establishing connections,to sending and receiving data between devices in their respective communities.

Considering the core logic is more or less equal to that of DevCom in terms of network protocols used, data packet transmission and control channel logic, we do not mention the overarching functionality of these components here to avoid redundancy.

A more detailed explanation of the different components and how they interact is discussed in Section 4.3.

Connecting to a device

The connection process begins with Device A acquiring the RSA public encryption key, which is stored in the¡fingerprint¿.pem.trampformat, meaning it also contains the fingerprint in the name, as well as the physical address of a device in the community it wishes to join.

Once this has been accomplished, a unique symmetric session key is generated and stored in the payload of a J(oin) control packet.

This packet then gets encrypted using the recipients public encryption key and signed with the senders private key before being transmitted over the internet.

Figure 4.1: Connection flow

(45)

Device B listens to any incoming connections a TCP server. When device A connects to device B, a new control channel is established to handle all incoming traffic.

All new DevCom control connections lead with a J(oin) packet, which is first being verified with the public key of device A before being decrypted by device Bs private key.

The session key that is found in the payload of this packet to be used for symmetric data encryption, along with the physical source address found in the IP header, is then being stored locally.

Should any of these steps fail, whether that might be that device B does not recognize the identity of device A, the verification fails or the decryption leads to corrupt or false data, the connections gets terminated.

Otherwise, we have an ongoing control channel and the rest of the community can be involved, as demonstrated in Section 2.2 of Chapter 2.

Not shown in figure 4.1 is the two-way UDP handshake that takes place when a control channel has been established to check whether both parties are able to receive UDP packets.

(46)

4.2.3 Sending data

The Virtual Network Interface is configured to accept all IPv4 and IPv6 traffic in its stream, but DevComJavaMobile only cares about IPv6 traffic read from this interface.

Should IPv6 packets be caught, the first check that needs to be verified is whether the packet is link-local with the fe80 pre-fix.

The next part of the address that gets verified is the 48 bit community part of the address.

If the device is part of such a community, the last section of the address, the 64 bit fingerprint, is checked against all known peers within this community.

Should any of these steps fail, the packet gets sent back to the virtual network interface and the operating system takes care of the rest.

Figure 4.2: Sending data flow

If the address in the IPv6 address represents a peer in a known device community, the packet gets sent as either UDP or TCP, depending on what protocols

(47)

the peer is known to support.

Should the peer support UDP, the entire packet read from the virtual network interface, including its data transmission protocol headers, but excluding the internet protocol headers, is then encrypted using the current symmetric session key.

The resulting payload is encapsulated in a new IPv4 packet that gets sent to the receiving device over the Internet.

If the peer does not support UDP, the same packet is then encrypted using the current symmetric session key before it gets signed with the senders private key.

The resulting payload is then encapsulated into a TCP Control (P)acket and is then sent as an IPv4 packet to the receiving device over the Internet, through the active control channel connection.

(48)

4.2.4 Receiving data

All UDP data traffic is received via a data traffic server that accepts all UDP traffic on port 1337.

The address in the IP header of these packets are being checked against all known peers to verify that there is an active control channel with this peer.

If this cannot be verified, the packet is dismissed, otherwise it gets decrypted using AES symmetric decryption with the current session key.

This results in a packet as it was originally perceived from the sending device before encryption, a packet that gets written to the virtual network interface and subsequently its intended application.

Figure 4.3: Receiving data flow

(49)

TCP packets are received through the active control channel as control (P)ackets and first gets its integrity checked by verifying the signature cou- pled along with the payload.

The rest of the payload then gets decrypted using the same symmetric key as is being used for UDP data packets, which like in the case of UDP data packets, is written to the virtual network interface and then its intended application.

(50)

4.3 System architecture

At the start of the development of DevComJavaMobile, we aimed for the System Architecture to be equal or similar to that of DevCom, shown and explain in Section 2.2 of Chapter 2. The traces of this philosophy can be found at various places, even when it does not make sense in the context of the application we present.

As the development of the application progressed, however, we came to the re- alization that DevComJavaMobile can not be structured the same way DevCom is.

There are a variety of reasons for this, one of the main ones being how the tunnel virtual network interface works in the Java ecosystem and the amount of extra programming overhead required to achieve the tunneling functionality in Java for Android, compared to C for Linux.

Arguably the biggest difference, however, is how heavily object-oriented Java is in comparison to C.

While C and the DevCom code mostly revolves around functions being called whenever needed and the locations of these mostly coming down to personal preference, or where it makes logical sense to include them, Java needs instan- tiated objects to perform any functionality unless declared abstract.

A clear example or where this requires different logic is in the control traffic channel maintenance.

In DevCom, this is done in a function that runs on its own thread that that loops over every active control channel sockets file descriptor, looks for any incoming control messages for peer and handles them accordingly.

This method of overseeing control traffic would not be possible in Java.

Rather, DevComJavaMobile runs a TCP server that listens for any new TCP connections on the port dedicated to control traffic.

Whenever new connections are established, the file descriptors of these newly established sockets are being passed as a parameter to an object instance of the ControlTraffic class, an object that is being run on its own thread and that handles any new packets separate from the rest of the program.

Rather than simply closing down the file descriptor and removing it from memory as is done in DevCom, DevComJavaMobile removes the entire object handling the socket and its traffic from memory, whenever a control channel closes.

(51)

Figure 4.4: Control traffic handling DevCom vs DevComJavaMobile.

All file descriptors are handled on the same thread in C vs their own threads in Java.

The system architecture in DevComJavaMobile is detailed in figure 4.5.

This section explains the key parts of this architecture and what functions they perform, starting with the graphical user interface.

Figure 4.5: DevComJavaMobile System Architecture diagram

(52)

4.3.1 Graphical User Interface

The graphical user interface (GUI) is structured into three different fragments, the Home, Communication and Overview fragments.

These fragments serve as the link between the user and the back-end code of the application and is one of the main contributions we present with DevCom- JavaMobile.

Figure 4.6: The ”Home” Frag- ment

Home Fragment

The Home fragment is the first screen the user is met with when opening the application.

In this fragment, one is able to start the core functionality of DevCom, i.e. the virtual tunnel network interface, and join a community.

To join a community, one needs to specify the fingerprint of a device that ex- ist in the community one wishes to join, by typing it in the ”Fingerprint” text field.

The name of the community also needs to be typed in the ”Community” text field and the current physical location address in the ”IPv4 address” field.

Upon joining a community, users are able to interchange end-to-end encrypted packets between online devices in said community, through secure and robust tunnels.

(53)

Figure 4.7: The ”Communica- tion” Fragment

Communication fragment

A pre-requisite to joining communities is to know the public encryption key of the device one wishes to join a community via.

This can be done through the Communication fragment.

By typing in the IP address of the device the user would like to know the public key of, they are able to exchange keys with this device by clicking ”Exhange keys”, after having written its IP address in the corresponding field.

”Send message” allows users to send simple text messages, written in the ”Message” field, to a device specified in the ”IP address” field.

When writing the physical address of the device a user wish to send a message to, the application will bypass the DevCom tunnel functionality and send a simple, unencrypted UDP packet containing the message.

If one instead writes the unique IPv6 Dev- Com address in the corresponding IP address field, the packet will be caught by the TUN

virtual interface, encrypted with the current symmetric session key they share with that device and decrypted on the other end.

This process assumes the receiving device have a corresponding UDP server running to receive the message, are running the DevCom TUN virtual interface and have an active control channel shared with each other.

The last buttons relates to starting and stopping either the UDP server or TCP server respectively.

(54)

The UDP server acts as a separate testing entity intended to be used to verify the functionality of DevComJavaMobile, as well as to serve as a primitive key exchange platform on UDP port 2500.

This platform is not to be confused with the ”Data traffic server” included in the application.

The Data Traffic Server handles all UDP-related traffic directly part of the core functionality of DevCom, while the UDP server mentioned in this context is a separate entity that exists outside of the scope of the DevCom concept, and exists purely as a testing and key transaction tool.

The TCP server is the server that listens for new TCP control channel connections.

(55)

Figure 4.8: The ”Overview”

Fragment Overview Fragment

The third and last fragment accessible within the GUI of DevComJavaMobile, is the Overview fragment.

With this fragment, the user is able to view the most important information related to DevCom about the current device.

Through the simple click of a button, users are able to copy either the physical address, unique fingerprint or public key information related to the running device.

At the bottom of the Overview fragment, a dynamic list displays the currently known device peers, their fingerprints, device communities, as well as the status of the connection of the control channel between the user device and a peer.

By clicking at any of the devices in this list, one is brought back to the Communication fragment and the IPv6 virtual device address of the device corresponding to the click is printed is written out in its entirety in the

”IP address” field.

This allows for an easy way to send an end-to-end encrypted messages to the desired community member.

(56)

4.3.2 Back-end components

The GUI discussed in the previous section uses the following components of the architecture to perform the functionality it presents to the user.

TunnelService

The central component of the entire DevCom relies around the tunneling component.

Through the VpnService Android API, programmers are able to access many of the features of the TUN/TAP device driver [12] that are otherwise only directly accessible via C code and root access privileges.

Upon clicking the ”Start Tunnel” button on the Home fragment, the application will ask the system for permission to run a tunnel device and thus monitor all network traffic on said device.

If this access has not been granted previously, Android will prompt the user, asking if they wish to allow DevComJavaMobile to intercept all network traffic on the device.

If granted, an instance of the VpnService will be run through the ”TunnelSer- vice” class and will catch all IPv4 and Ipv6 traffic via the TUN Virtual Network Interface.

The file descriptor of this interface is then passed on to a separate dedicated Runnable [36] thread, maintained via an instance of ”TunnelRunnable” class.

The TunnelRunnable continues to live in its own, dedicated thread and monitor all traffic on the tunnel stream.

Whenever anything gets sent upstream or downstream, these packets are caught as raw bytes and forwarded to an instance of the SessionHandler class.

While DevCom is not interested in reading IPv4 packets from the stream in any direction, it still needs to catch all IPv4 packets in order to be able tosend IPv4 packets in the downstream, such as the ones that have been decrypted from DevCom-specific IPv6 packets in the tunnel upstream.

These IPv4 packets are, however, not modified with any way, but are maintained through the ”SessionHandler” class.

IPv6 packets, on the contrary, are all being sent to ”handleIPv6Packet” in the aforementioned Java class. Here, all packets are checked to make sure that they are DevCom-specific, and handled accordingly if so.

All other packets are being sent back to the stream in their original forms.

Adopting Device Communities for Modern Android Systems