Self-Organizing High-Assurance Privacy

UPTEC IT 19015 Examensarbete 15 hp Augusti 2019

Joakim Ingnäs & Nicole Tutsch

Institutionen för informationsteknologi Department of Information Technology

Abstract Self-Organizing High-Assurance Privacy

Joakim Ingnäs & Nicole Tutsch

Teknisk- naturvetenskaplig fakultet UTH-enheten When using a network, devices might have to securely communicate with one another. Issues arise when the devices are unaware of others in the network, or Besöksadress: when the devices have to be manually updated with the information about the Ångströmlaboratoriet Lägerhyddsvägen 1 devices they wish to communicate with. This presents an issue with bootstrapping Hus 4, Plan 0 over networks. Therefore, the question of how to make these devices find the relevant peers becomes a pressing one. In addition, the devices have to securely Postadress: exchange keys. In this paper, a solution is presented using a rendezvous point that Box 536 751 21 Uppsala acts as a gateway between a key distribution server and the clients. The architecture of the system consists of one rendezvous point, one key distribution Telefon: server, and multiple clients. The clients have to go through the rendezvous point in 018 – 471 30 03 order to reach the key distribution server. Two different protocols, RSA and

Telefax: password-authenticated key exchange, are studied in order to understand which 018 – 471 30 00 one of them is superior in key exchange security. The result of the study is that the RSA protocol is faster than the password-authenticated key exchange protocol Hemsida: when applied to this solution. However, password-authenticated key exchange is http://www.teknat.uu.se/student seen as safer, as it applies security measures that RSA lacks. In this project, the system manages to have the clients routed from the rendezvous point to the key distribution center, and the key distribution server manages to send out information to the clients about their peers. In addition, the rendezvous manages to shield the key distribution center from some denial-of-service attack on the hardware. However, this solution is highly theoretical, and requires further research to be regarded as completely functional.

Handledare: Tobias Laross Ämnesgranskare: Joachim Parrow Examinator: Lars-Åke Nordén ISSN: 1401-5749, UPTEC IT 19015 Tryckt av: Reprocentralen ITC

Populärvetenskaplig sammanfattning

I dagens samhälle är en stor del av alla datorer uppkopplade i ett nätverk, t.ex. internet. Eftersom alla dessa datorer måste kommunicera med varandra krävs det att de kan hitta varandra, så kallat "bootstrapping". Kommunikationen måste även ske på ett säkert sätt, så att ingen obehörig kan avlyssna vad som skickas. Detta presenterar, bland annat, två problem som måste lösas: hur ska datorer hitta varandra, och hur ska de förhandla fram nycklar på ett säkert sätt? I detta examensarbete har två olika protokoll för utbyte av nycklar: PAKE, "Password Authenticated Key Exchange" (autentisering med hjälp av lösenord), samt RSA (två olika nycklar). Dessa två skiljer sig markant, då RSA har två olika nycklar (en publik och en privat), och PAKE har symmetriska nycklar. Den viktiga delen av detta examensarbete är inkluderingen av en KDC, "Key distribution center" (nyckeldistributionscenter), och en RP, "rendezvous point" (mötesplats). KDC har använts tidigare, i t.ex. implementationer av Kerberos, men RP är inte lika vanligt. Examensarbetet undersöker även de två tidigare nämnda protokol för att ta reda på vilket som var säkrare. Användandet av en RP, tillsammans med en KDC, undersöks för att ta reda på om den kunde bidra till att det blev enklare för klienter att hitta varandra. Två stationära datorer med Linux Ubuntu användes som KDC och RP, medan klienterna var Raspberry Pis. Attackerna var i deﬂesta fall två Macbook Pros. Klienterna hade förprogrammerat adressen och portarna till RP:n, för att försäkra sig om att de skulle hitta den. Efter att klienterna hade autentiserat sig skickade RP:n ett meddelande till klienterna. Detta meddelande innehöll IP och port till KDC:n. Klienterna kunde då koppla upp sig till KDC:n. Säkerheten i detta system undersöktes med hjälp av att attackera RP:n med en DoS och en DDoS-attack. Även en man-in-the-middle-attack testades, men gav bristfälliga resultat på grund av problem med verktyget som användes. Även en brute force attack skulle ha blivit utförd, men var endast teoretisk. Som slutresultat visade det sig att klienterna enkelt kan hitta RP:n, samt vidarekoppla sig till KDC:n. Därifrån får de meddelande om vilka klienter som var uppkopplade. Detta betyder att de två problemen som nämndes i början är lösta, inom en testmiljö. Dessu- tom skyddar RP:n KDC:n från DoS och DDoS-attackerna som attackerar hårdvaran. Det är endast när själva nätverket går ner som kommunikationen mellan KDC och klienterna upphör. Systemet är däremot inte redo för användning utanför en testmiljö. Resultatet somﬁnns i detta examensarbete ska endast användas som ett underlag för vidare forskning.

Contents

1 Introduction 1

2 The Problem 2

3 Background 2 3.1 Secure Networks ...... 3 3.2 Peer-to-Peer ...... 3 3.3 VPN ...... 3 3.3.1 Tunneling ...... 4 3.3.2 Dynamic Multipoint VPN ...... 5 3.3.3 Requirements of a decentralized bootstrapping of P2P systems ...... 5 3.3.4 Existing solutions - Peer-based ...... 6 3.3.5 Existing solutions - Mediator-based ...... 7 3.4 Token-based authentication ...... 7 3.5 IPSec ...... 8 3.6 Encrypted Key Exchange ...... 9 3.6.1 Diffie-Hellman Key Exchange ...... 9 3.6.2 RSA ...... 10 3.6.3 Password Authenticated Key Exchange ...... 13 3.6.4 Secure Packager and Encoder Key Exchange ...... 14 3.7 Lattice-Based Cryptography ...... 14 3.7.1 LAC.CPA ...... 16 3.7.2 LAC.CCA ...... 20 3.7.3 LAC.AKE ...... 21 3.8 Security of self-organizing networks ...... 22 3.9 Attacks ...... 24 3.9.1 Denial-of-Service and Distributed Denial-of-Service ...... 24 3.9.2 Eavesdropping ...... 25 3.9.3 Man in the Middle ...... 26 3.9.4 ARP spoofing and poisoning ...... 27 3.9.5 Brute force attack ...... 27 3.9.6 VPN hijacking ...... 28 3.9.7 Sniffing ...... 29 3.10 Tools ...... 29 3.10.1 Ettercap ...... 29 3.10.2 bettercap ...... 30 3.10.3 XerXeS ...... 30 3.11 Key Distribution Center ...... 30

4 Related work 32

ii 4.1 Group Encrypted Transport VPN ...... 33 4.1.1 Group Domain of Interpretation ...... 35 4.2 Internet Key Exchange Protocol Version 2 (IKEv2) ...... 36 4.3 Kerberos ...... 36 4.4 Decentralized Bootstrapping in Pervasive Application ...... 37 4.5 Bootstrapping in ad hoc networks ...... 37

5 Design 38 5.1 Requirements ...... 38 5.1.1 Key system attributes ...... 39 5.2 Design ...... 39 5.2.1 PAKE ...... 41 5.2.2 RSA ...... 42 5.2.3 Rendezvous point ...... 42

6 Method 42 6.1 Hardware ...... 43 6.1.1 Laptops ...... 43 6.1.2 Raspberry Pis 3B+ ...... 43 6.1.3 Desktops ...... 43 6.2 Implementation aspects common between PAKE and RSA ...... 44 6.2.1 The client ...... 44 6.2.2 The rendezvous point ...... 45 6.2.3 The key distribution server ...... 45 6.2.4 Application programming interface ...... 46 6.3 PAKE ...... 47 6.3.1 Client ...... 47 6.3.2 Rendezvous point ...... 47 6.3.3 KDC ...... 48 6.4 RSA ...... 48 6.4.1 Client ...... 49 6.4.2 Rendesvouz point ...... 49 6.4.3 KDC ...... 50 6.5 Setting up the server ...... 50 6.6 Attacks ...... 50 6.6.1 DoS and DDoS ...... 50

7 Results 51 7.1 General testing ...... 51 7.1.1 Robustness ...... 51 7.1.2 Theoretical scalability ...... 51 7.1.3 Eﬃciency ...... 52

iii 7.1.4 Authentication server ...... 53 7.2 DoS and DDoS-attack ...... 53

8 Discussion 55 8.1 Issues ...... 57 8.1.1 General issues ...... 57 8.1.2 University-related issues ...... 57 8.1.3 LAC.AKE ...... 58 8.1.4 Hardware ...... 58 8.2 Answers to questions in section 2 ...... 59 8.3 Choice of protocols ...... 61 8.4 Design ...... 62 8.4.1 Requirements ...... 62 8.4.2 General design ...... 64 8.4.3 PAKE ...... 65 8.4.4 RSA ...... 66 8.4.5 Robustness ...... 67 8.4.6 Eﬃciency ...... 67 8.4.7 Scalability ...... 68 8.4.8 Authentication server ...... 68 8.5 Method ...... 69 8.5.1 Common method for PAKE and RSA ...... 69 8.5.2 PAKE ...... 71 8.5.3 RSA ...... 71 8.6 Attacks ...... 71 8.6.1 MitM ...... 72 8.6.2 DoS and DDoS ...... 73 8.6.3 Brute force ...... 73 8.6.4 VPN hijacking ...... 74 8.7 Tools ...... 74 8.8 Related work ...... 75 8.8.1 GET VPN ...... 75 8.8.2 IKEv2 ...... 76 8.8.3 Kerberos ...... 76 8.8.4 Decentralized bootstrapping in Pervasive Application ...... 77 8.8.5 Bootstrapping in ad hoc networks ...... 77

9 Future work 78

10 Conclusion 79

11 My contribution 80

iv 11.1 Joakim Ingnäs ...... 80 11.2 Nicole Tutsch ...... 81

Appendices 92

A Dictionary 92

v 1 Introduction

In today’s society, everyone and everything is connected though large networks. In 2013 , 80 devices per second connected to the internet alone. [1] In order for devices to communicate with each other, they need to be able toﬁnd their peers. This does not only apply to those that are to connect to the world wide web, but also those on smaller networks, such as an oﬃce communicating with the local server.

The problem, known as bootstrapping, is that devices do notfind one another. Discovering a solution has kept people from severalfields, from computer scientists to engineers, occupied throughout the years. However, to this day no satisfactory solution has been found. [2, 3] In addition, there is a risk of single points of failure. This means that even one component can bring down the whole system. As the saying goes, a chain is only as strong as its weakest link. If a single point of failure exists, it may render the whole system unavailable for all users, or make the devices connected to the system unable tofind each other. This could have disastrous consequences, such as valuable information becoming compromised. Therefore, it is important to be able to prevent this potential communication issue in a way that is both user-friendly and still provides ample security protection.

This project focuses on one possible solution, and aims to answer several question that arise with such a solution. The questions that the project wishes to answer are described in section 2. In order to answer them, a system that consists of a key distribution centre and a rendezvous point was created. The key distribution center distributes keys between clients that are to communicate with one another. The importance of the rendezvous point is that it acts as a barrier between the key distribution centre and the clients. In addition, several key exchange protocols are used in this project, and those are evaluated to assess how well they perform in the solution. Because it would be a barrier, it would remove the risk of immediate single point of failure.

In addition, the solution is put under a stress test, in order to prove that it is not only user- friendly, but that it can survive strain put on it. The rendezvous point is tested in the form of speciﬁc attacks. This is done to make sure that the rendezvous point can withstand malicious devices and will not be the weak component in the system. The attacks are of two kinds: those that willﬂood the system and those that are malicious devices that attempt to impersonate an authorized device.

There are key concepts related to secure systems: confidentiality, authenticity, integrity, trust, and availability. Confidentiality is a set of rules that either limits or restricts access to certain types of vital information. Authenticity is the concept of applying processes that proves a user’s identity. Integrity is kept by using methods that ensures that data is correct, real, and not modified by unauthenticated users. Trust is used to determine user trust in cryptosystems. This concept can be used in order to generate trusted authorities in systems. Availability is the possibility for a certain user to access resources or information. This information is often

1 accessed from a speciﬁc location, and in some predetermined correct format. All of these key concepts have to be executed properly in the solution that this project proposes.

2 The Problem

Currently, the systems that facilitate networks based on cryptosystems have to be configured manually in order to allow for different devices to communicate with each other. This can be done either physically on each device or remotely. However, manual configuration is time- consuming, which makes this method an unsatisfactory one. Therefore, it would be preferable if the devices themselves were able to create Peer-to-Peer (P2P) connections automatically. This would allow them to communicate faster with each other. [4]

Two problems have already been presented in section 1: the issue of clientsfinding their peers, and the issue of exchanging keys. However, automatic configuration, in turn, raises some specific research questions that need to be answered:

• Would a predefined rendezvous point be beneficial in order for devices tofind one another? [4]

• Are there any particular risks using a rendezvous point? How can these be mitigated? [4]

• Is there a diﬀerence in performance between diﬀerent key exchange protocols in a solution employing a rendezvous point? [4]

The project aims primarily to answer the question whether using a rendezvous point is beneﬁcial, and if it presents any security beneﬁts.

The answers to these questions can be found in section 8.2, where they will be discussed in the scope of the project.

3 Background

In order to understand what is being researched in this report, a few speciﬁc topics have to be covered. In this section, the required topics are described and deﬁned in detail in order to provide an extensive understanding of the research performed.

This section goes through important topics such as virtual private networks, bootstrapping in regards to distributed networks, and different protocols that are important to this project. It also goes through different attacks that could possibly affect the system, and what they entail.

2 3.1 Secure Networks

A secure network is any type of network that has some security measures in place in order to protect it from any possible outside threats or attackers. [5] It should stop and track any occurrence of unauthorized access, exploitation, and modiﬁcation, as well as denial of the network and network sources. [6] Generally, a secure network has to contain multiple layers of combined defenses, where each layer implements policies and controls. This should, in most cases, let authenticated users in, and block attackers. Some examples of these defenses areﬁrewalls, data loss prevention, antivirus and anti-malware software, as well as virtual private networks (VPNs). [7]

3.2 Peer-to-Peer

Peer-to-Peer, commonly written as P2P, is a network architecture where every peer is a device connected to the Internet, and, through it, to other peers. This enables the sharing offiles without the need for a central server, meaning every peer becomes not only a client, but a temporaryfile server as well. In order to join a P2P network, only two requirements need to be fulfilled: the client must have an Internet connection, and have a type of P2P software installed, such as Limewire. [8]

3.3 VPN

A virtual private network (VPN) is a tunnel between devices, allowing them to securely connect to a different device through the Internet, without the risk of interference from outside sources. [9] The tunnel can be compared to how a concrete tunnelfilled with water will allow the water toflow from point A to point B, without any disturbance from outside forces, nor will anyone be able to see the water. It works the same way when it comes to tunneling in networks, but it is an encrypted tunnel that lets dataflow instead of water. It consists of both client side and server side applications, where the user most often simply starts their VPN software. This, in turn, encrypts the data sent from the client’s device before it is routed to the Internet. This ensures that any possible WiFi or Internet Service Provider will not see the data in its decrypted form. The VPN forwards the data, after having encrypted it, to the client’s desired destination. The destination will see that the data’s origin of the data is the VPN’s server and its location, rather than the client’s real location. [10] However, devices connected to the same VPN network can see the data, enabling communication over the network for the authorized parties. This is possible due to the VPN emulating a point-to-point link, through the process of tunneling. [11] Tunneling will be described in section 3.3.1.

Figure 1 shows a simpliﬁcation of how the communication between a device and the Internet functions when not using a VPN. As can be seen, the data is visible to whoever decides to intrude. In Figure 2, a proxy VPN is used. This means there is a step between the client’s

3 Figure 1: The connection between a client Figure 2: The connection between a client and the internet without a VPN and the internet with a VPN device and the Internet, and it encrypts the data from the client. Therefore, the data cannot be seen by unauthorized users as it has to be decrypted once it reaches the Internet.

A VPN is used for many different reasons, both for commercial and non-commercial users. A VPN can be used to bypass geographical limitations on websites, such as video and audio streaming websites, but it also protects the user from being spied on, as well as hides the user’s location and traffic. There is not as big of a digitalfingerprint once a VPN is used. [12] The previously mentioned reasons are mostly for private parties. A business would more likely use it for protection against any possible espionage attempts, as well as allowing the employees to communicate within the business with a secure connection. [13] Private users might want to use a VPN to protect against espionage as well, but businesses generally have access to sensitive information. For that reason, an assumption is made that businesses are more likely to use a VPN for protection against espionage.

However, VPNs are not invulnerable, and are at risk of attacks as well. Not only is the client side at risk because of malware or the human error, but an attacker can breach the secure network from outside as well. Two examples of such attacks are VPN hijacking, and Man-in-the-middle attacks, both of which will be described in section 3.9. [11]

3.3.1 Tunneling

What is commonly referred to when using the term VPN tunneling is the process of encapsulating data into an encrypted data packet. It is the actual encrypted connection between the devices connected to the network. A simpliﬁcation of the process can be seen in Figure 3. [14]

There are two types of tunneling, both of which are commonly used. Theﬁrst method is voluntary tunneling, where the VPN client manages the setup of the connection. In order to reach a network, for example the Internet, the user has to establish a connection to their Internet Service Provider (ISP), whereto the VPN will create a tunnel from the VPN server, which allows the user to reach the Internet through the VPN server. The second method is compulsory tunneling, where the carrier network provider is the one that manages the setup of the VPN connection. This happens as soon as the user at the client side connects to their

4 Figure 3: VPN Tunneling. ordinary carrier. The carrier then manages a VPN connection between the client and a VPN server, with which the client is associated. This means that the client will see the tunneling as simply one step, compared to the two-step connection in the voluntary tunneling. [15]

3.3.2 Dynamic Multipoint VPN

Dynamic Multipoint VPN (DMVPN) is a solution created by Cisco for their networking software in the IOS line. It is used to build scalable IPSec VPNs, and utilizes a centralized architecture, ensuring easier implementation and management. [16] DMVPN allows for communication between branch oﬃces in a business, without having to pass the traﬃc through a VPN server or router. [17] This is important for GET VPN, which is described in section 4.1.

3.3.3 Requirements of a decentralized bootstrapping of P2P systems

A large issue with bootstrapping in P2P networks is that there has not been, at the time of research, any viable solutions to the issue of letting a nodefind the network and its peers. A selection of such solutions can be found in section 4. There are some potential solutions that satisfy some of the needed criteria, mentioned below. However, none of them satisfy all of the criteria, and lack in other aspects that are needed to make them good or the ’perfect’ solution. The solutions are the only centralized part of a decentralized network, and therefore a single point of error. [2, 3] Because of this, a new protocol has to be created in order to ensure that the P2P network will be able to expand andflourishflawlessly.

5 The three diﬀerent requirements that are needed to be a good bootstrapping protocol are:

• Robustness, which includes protection against failure, external interference, and disturb- ing security appliances such as anti-virus. The protocol should still retain the decentralization of the P2P network, in order to eliminate the risk of a single point failure. In addition, it needs to avoid external interference, so that no authority can simply shut it down. Security appliances, such asﬁrewalls, should not provide any issue either, if the protocol is to be deemed good.

•Eﬃciency, as it should provide a fast and slim bootstrapping process.

• Scalability. Because of theﬂuctuation in the number of peers inside a network, it should not put a limit to the amount of nodes, nor fail to communicate in a large network. [2]

None of the existing protocols fulﬁll all of these requirements.

3.3.4 Existing solutions - Peer-based

There are two categories of previously created bootstrapping solutions: peer-based approaches, and mediator-based approaches. The peer-based approaches focus on detecting peers, and by connecting with a peer inside of the network, gain access to the network itself. There are several diﬀerent ways to solve this issue, but only three are discussed in this report. [2] The solutions are presented and explained, as well as the issues with them that cause them to be less than ideal solutions.

In one approach, a cache of previously active peers is kept, and a new node simply loads the cache in order to contact a node. This is known as peer caches, and while it is not only a simple solution, it is also robust, eﬃcient, and scalable. Theﬂaw that makes this solution less than perfect is the fact that if none of the nodes in the cache are active, all communication ceases to exist. Therefore, it is not a good solution. [2, 18]

Multicast is another solution, which focuses on the use of multicasting, as the name already suggests. When a node joins the network, it sends out a query to the multicast, which is a sort of group communication, in order to receive the IP of other nodes in the network. [2, 19] Then, it connects with them, allowing the node to become part of the network. This is also a reliable and convenient solution, as well as being simple and eﬃcient. The issue with this solution is that it does not work for larger, let alone world-spanning networks as the multicast communication does not get routed beyond the local network. [2]

Lastly, random probing is more of a brute-force approach, where a node searches for peers and probes specific ports in an attempt to establish communication. The peers are selected at random in the communication network. It might be feasible in smaller, denser networks. Unfortunately, it is not efficient in any remotely large network. In addition, it is not suitable for starting up networks. The major issues are that the approach suffers from a poor hit ratio, due to the amount of connection attempts and cannot always connect to the specified ports, due

6 to security appliances. [2, 3, 18] However, it does present a completely decentralized solution. [3]

Because of the failure to fulﬁll the requirements mentioned earlier, the peer-based approach is not seen as a viable solution.

3.3.5 Existing solutions - Mediator-based

The mediator-based approaches instead focus on, as the name suggests, using a mediator in order toﬁnd peers, either as a peer itself or as an external node. The main issue is that the mediators’ information needs to be constantly updated. Each mediator is registered as a well-known entry point (WKEP) from the start, as it is programmed into the bootstrapping protocol. It acts as a dictionary for the peers. It is this way that it ensures that a node that wishes to join a network is able toﬁnd one or more active peers, by providing the node with the IP addresses of the peers. [2]

Just like the peer-based approaches, there are multiple approaches using a mediator. Some of the well-known known mediators are Gnutella, eDonkey Server Lists, Bittorrent, and Napster Server. However, due to having to manually provide the information about the WKEP, or having to rely on the availability of the mediators, [2] the mediator-based solution is not seen as optimal. Another reason is the fact that mediators can become overwhelmed with the amount of requests, causing a DDoS-attack on its own, and not only becoming a bottleneck, but the single point of failure. [20]

3.4 Token-based authentication

Just as some buildings require an employee to have a speciﬁc key card to be let inside, so do some applications. These "key cards" are referred to as security tokens, or authentication tokens, and are often used instead of a password. They are also used in order to remember certain information about a user, and their actions on a speciﬁc web page. [21, 22] Some security tokens can be hardware solutions, such as the key card mentioned earlier [23].

Token-based authentication is desirable since it is stateless, and does not require any data to be stored on the server, making it scalable, in contrast to the session-based authentication. It is the client that stores the token, which is desirable when a lot of users are in contact with one server, and storing the token on the client side allows for a user to be moved between diﬀerent servers seamlessly. In addition, there are no cookies sent when a token is being used, as a token will be sent on every request to the server, which in turn prevents cross-site request forgery (CSRF) attacks, and the token is set to expire after a set amount of time. [22, 24]

7 3.5 IPSec

IPSec, short for Internet Protocol Security, is a deﬁnition of the architecture for security services for IP network traﬃc. [25] While the previously mentioned protocols have been singular protocols, IPSec is a collection of collaborating protocols which provide secure private communication over IP networks. It is often paired with Layer 2 Tunneling Protocol (L2TP) in order to provide the security the other protocol lacks. The two main protocols of IPSec are the authentication header, and encapsulating security payload. They are described in depth further on. [26] There are also other important parts of the IPSec collection, such as the Internet Key Exchange (IKE), and the Internet Security Association and Key Management Protocol (ISAKMP), where the latter is now included in IKE. [25]

IPSec is versatile, allowing for a lot of diﬀerent areas of use. A few such areas are protection of network data through encryption, encryption of application layer data, as a provider for security for routers, as well as authentication without encryption. The IPSec protocol is included in the IP header, and will in turn appear as a header extension on a system using this protocol. [25]

All of this has caused IPSec to become one of the preferred protocols to use for corporate networks. One of the reasons IPSec has gained so much attention is the transparency it has towards applications, as it works on Layer 3, the network layer, and therefore causes no interference with the higher network layers. In addition, because it works on the network level, it is not dependent on the application in itself. In other words, a computer connected to the corporate network might not have IPSec capabilities itself, but still use the network layer, and therefore still be protected. [27, 28]

However, while it presents advantages that make it attractive for business, it also suﬀers from its own share of disadvantages. While the previously mentioned advantage of letting computers in a network all use the same IPSec protocol without having any IPSec capabilities themselves, it can also cause issues. If a computer in the network gets a worm, it can spread over to the rest of the computers in the network. In addition, it is almost impossible to connect remotely to the network, due to restrictions. [27, 28]

The most alarmingflaw of the IPSec is how Edward Snowden revealed that the NSA had already cracked several VPNs, and how the NSA could sometimes bypass a specific implementation of that security to spy on users. It was later tested by a hacker group known as the Shadow Brokers, who leaked NSAfiles and confirmed that a specific implementation of IPSec had been compromised. [29, 30] It was believed that IPSec was bypassed, due to the necessary amount of different options it offered, and because the implementations were to be as complex as possible, there were often faulty implementations. [31] However, since the Snowden reports, the number of IPSec implementations had risen by 60% by 2017, and it was stated in an interview in “The Snowden Disclosures, Technical Standards, and the Making of Surveillance Infrastructures” by Michael Rogers and Grace Eden [32] that IPSec should have been implemented widely, and

8 preferably with similar options, in order to curb the breaking by the NSA. [32, 33]

3.6 Encrypted Key Exchange

When a user attempts to authenticate themselves on the Internet, the most common practice is to use a username and a password. However, while this is used to allow a user to access a computer that is enforcing access control, there is a risk in storing the passwords on the computer in plaintext. This puts the passwords at risk of getting exploited by an attacker. In order for the user to not have to store the password, and instead input it each time, the password has to be chosen so that it can be input repeatedly with a low probability of error. [34] In response to this, Steven Bellovin and Michael Merritt proposed the "Encrypted Key Exchange" (EKE) protocol in 1992, which consists of a combination of asymmetric and symmetric cryptography, "where a secret key is used to encrypt a randomly generated public key". [35]

The symmetric encryption is used to encrypt the initial asymmetric key exchange, to trade challenges and responses, and to protect the ensuing application session. The initial exchange has severe constraints placed on the plaintext encrypted, such as not using ASN or other types of tagged data representation on the messages. The EKE is relatively open to whichever cryptosystem the user decides to use, with a few seen as unusable due to practical grounds, such as systems with many large prime numbers. A vital detail of EKE is that the two cryptosystems should not be associative, as an attacker might be able to break the encryption in that case. [35] Associativity entails that the result from the algorithm will not change depending on the order of the arguments. [36]

When governments and businesses store information, it might have to be kept safe for several decades, depending on the classiﬁcation. This means that the cryptography used has to withstand the time and the evolution of cracking methods. Because of this, the governments and large companies have to be certain that the algorithm cannot be cracked in the coming decade.

3.6.1 Diﬃe-Hellman Key Exchange

The Diﬃe-Hellman Key Exchange (DHEKE) is a method of digital cryptography, or rather a public-key technology, used to produce secret keys through the use of numbers raised to speciﬁc powers, and works on the basis that the parts generating the key will not be transmitted. This should make it mathematically overpowering for a possible attacker to crack. The two users who wish to communicate will decide on two large positive integers, where one will be a prime number, and the other a generator. The prime and the generator are domain parameters, which are stable and public information. They are never transmitted because they both are hard coded into both clients. A generator is a number that never produces the same result when raised to whole-number powers less than the chosen prime number. [37] The generator is a primitive root modulo p, which generates all other numbers (modulo p). For example,g a =b (mod p) where

9 b will take any value from 1 to p – 1. However, while it does allow for a secret key to be shared between two parties, DHEKE does not provide any encryption itself. It is only a key exchange protocol. [38]

When using the DHEKE method, the two communicating parties do not need to be previously aware of one another in order to establish a shared, secret key. [39] Figure 4 illustrates how the DHEKE algorithm would work, albeit with much smaller numbers than used in reality. In this example, Alice and Bob have publicly agreed to use prime number 17, and the generator 3. Then, they choose their own private numbers, which remain secret. Alice has chosen 15, and Bob 13. In order to decide on a common key, they both calculate a number using the formula generatorprivate_number mod prime and sends the result to one another. Alice sends 6, and Bob sends 12. Then, using the formula sent_numberprivate_number mod prime, they get the same result, which will be their key.

Unfortunately, because this algorithm does not perform any authentication, it is susceptible to man-in-the-middle attacks. [40] Those attacks are described in section 3.9.3. One of DHEKE’s major advantages is that it generates keys fast, something that is not as necessary with today’s hardware. [41] Some papers, such as “Security Issues in the Diﬃe-Hellman Key Agreement Protocol” [42] by Jean-Francois Raymond and Anton Stiglic, present severalﬂaws within the protocol. However, as all protocols that are currently in use have security issues, [42] it does not deem DHEKE as useless.

In Figure 5, the pros and cons are summarized.

3.6.2 RSA

The RSA algorithm is an asymmetric cryptography algorithm, where the name is an acronym of the inventors of the algorithm. It utilizes both a public key and a private key. [43] In RSA, both keys are able to encrypt a message, and the opposite key is used in order to decrypt it. Because of this, coupled with the fact that the private key is always kept secret, it is a widely used asymmetric algorithm, which provides not only conﬁdentiality and integrity, but also a method for authenticity, and non-repudiation. [44, 37]

The security of RSA comes from the fact that it is diﬃcult to factorize a large integer that is the product of two large prime numbers, even for supercomputers. It is expected that it will remain secure for many years to come, unless quantum computing makes incredible strides in the near future. [44] The risk of quantum computing breakthroughs only applies to regular people, as large companies and governments work on the assumption that the protocol has already been cracked without public knowledge.

In Figure 6, an example of the RSA can be seen. The prime numbers, p and q in this case, are chosen through the use of the Rabin-Miller primality test algorithm. These numbers are later used to calculate a modulus n, by multiplying p and q, and is the link between the two keys. The public key uses the modulus, as well as a public exponent e. The exponent usually has a

10 Figure 4: Theﬁgure illustrates an example given on Venaﬁ’s website about the DHEKE algorithm. The clouds represent secrets known only to the corresponding actor, and the rest is known publicly. The symmetric key used for communication is 10. [37]

Figure 5: The pros and cons of the DHEKE algorithm. set value of 65537, a prime which is large but not considered too large, and it does not have to be secretly selected either, since it will be shared with everyone. As for the private key, it uses the modulus n as well, but also a private component, which is calculated with respect to the

11 Figure 6: The image illustrates an example of how RSA works, taken from Search Security’s website. All parts, except the public key, in only known to their corresponding partners. [44] The red color symbolizes Alice’s actions, and the blue color symbolizes Bob’s actions. totient of n. [44, 45] The totient is derived from Euler’s totient function, which "is deﬁned as the number of positive integers <=n that are relatively prime to (i.e., do not contain any factor in common with) n, where 1 is counted as being relatively prime to all numbers". [46]

While RSA allows for authentication, with the help offingerprinting or similar, giving it an edge compared to DHEKE, it still suffers fromflaws. Researchers have been successful in demon- strating that even RSA can become a victim to attacks. Two examples of attacks are partial key exposure attack and those based on Coppersmith’s Theorem. [47, 48, 49] In Figure 7, the pros and cons of the key exchange protocol can be seen.

12 Figure 7: The pros and cons of the RSA algorithm.

3.6.3 Password Authenticated Key Exchange

Password authenticated key exchange (PAKE) is a protocol that is used when two parties want to engage in a communication after which both of them hold a session key which only they know of. This can either be a shared key or a public key, with a private key remaining hidden. A PAKE protocol is established by using a common password for the key exchange. By using the PAKE protocol, one is protected against offline dictionary attacks, and, even with a low-entropy password, PAKE protects against offline user impersonation. [50] PAKE protects against offline dictionary attacks by limiting an attacker to only gain information about one password per protocol session. Therefore the attacker may not run through a dictionary offline and check each word with occurences in the data. [51] In a setting like this, the protocol is still vulnerable against online dictionary attacks. In such an attack, the attacker repeatedly performs guesses until itfinallyfinds the correct password. However this also requires that the attacker interacts with a legitimate user to be able to check if its guess is correct or not. [52] For further security, a password authenticated server can be used to provide security against online dictionary attacks. [50] A summary of the pros and cons of PAKE can be seen in Figure 8.

Figure 8: A summary of pros and cons of the PAKE protocol.

The speciﬁc PAKE protocol implemented is J-PAKE. The unique feature of this feature is that is uses short lasting values, such as a standard DHEKE protocol. Then, it combines the short lasting values with a password to provide an extra security measure.

The diﬀerence between the J-PAKE and the regular PAKE protocol is that the regular one uses passwords a single time to make the inputs obfuscated. J-PAKE, on the other hand performs this in multiple steps. In theﬁrst step, both participants exchange public keys and combine these with the passwords to get new public keys. After this, both parties can compute session keys securely if they share the same passwords. The added security eliminates some of the randomization factors due to the use of the correct password. This technique is called “juggling”

13 by its designers, therefore giving the protocol’s name a J-preﬁx to signal that. [51]

Most of the recently created PAKE protocols are based on DHEKE, but there are some that are based on RSA as well. The reason why a majority are based on DHEKE is that the approach used when designing RSA-based PAKE protocols is far from perfect and not mature enough to use in a high security environment. [53]

3.6.4 Secure Packager and Encoder Key Exchange

Amazon Web Services created the base of the secure packager and encoder key exchange (SPEKE) API in 2017, and have continuously worked on it, releasing new features ever since. This method has now become the standard for communication between encrypters and packagers, speciﬁcally regarding media content and digital rights management (DRM) key providers. The general architecture of SPEKE consists of three main parts, all of which play an important role in the architecture: an encrypter, which provides the encryption, a DRM platform key provider, which provides the encryption keys, and a player, which requests the keys from the DRM. [54]

Because the protocol is mostly used in order to provide secure communication for DRM key providers, it is not used in this report. It was evaluated, due to being such a standardized algorithm, but was dropped due to the intended use being incomparable with the focus of the project.

3.7 Lattice-Based Cryptography

A lattice is a set of points in an n-dimensional stage, having n-linearly independent vectors, which generates the lattice, as seen in Figure 9. Lattice-based cryptography has great potential for post-quantum cryptography, as it is believed to be secure against attacks performed on quantum computers. Many of the lattice-based constructions are eﬃcient and compete with some of the best alternatives for post-quantum cryptography. Lattice-based cryptography has security from worst case assumptions, due to the fact that there are currently no known quantum algorithms for solving lattice-based problems that perform noticeably better than classical algorithms. Attempts to solve lattice-based problems by quantum algorithms have been made since the mid-90s when Peter Shor devised a quantum factoring algorithm. [55] However, that has not met any great success. Therefore, lattice-based algorithms are secure as long as no oneﬁnds a poly-time algorithm for approximating the shortest vectors in every lattice and not just a few random lattices. Lattice-based cryptography is parallelizable, as the algorithms often include matrix multiplications or other parallelizable multiplications. The only currently known way to build fully homomorphic encryption is by using lattices or similar techniques, which is also a great advantage. [56]

Lattice-based cryptographic constructions can be divided into two types, where one includes practical proposals, which is often very eﬃcient but lacks proof of security. The second type can

14 Figure 9: A two-dimensional lattice and two possible bases. [56] prove security based on the worst-case hardness of lattice problems. The simplest worst-case has the shortest vector problem (SVP), in which the input is a lattice as an arbitrary basis, and the goal is to output the shortest nonzero vector in it. [56] The general pros and cons for Lattice-Based Cryptography can be seen in Figure 8.

Figure 10: An overview of the pros and cons of basic lattice-based cryptography.

15 3.7.1 LAC.CPA

There is a foundation on which both LAC.CCA and LAC.AKE are based, which is the secure public key encryption protocol LAC.CPA. It stands for The Indistinguishably under Chosen Plaintext Attack (IND-CPA), where Indistinguishably means that an attacker cannot indistingus plaintexts from ciphertexts. It is made up of three algorithms; a key generation algorithm (KG), as seen in algorithm 1, an encryption algorithm (Enc), as seen in algorithm 2 andﬁnally a decryption algorithm (Dec), as seen in algorithm 3. [57]

Several notations are used in algorithm 1, algorithm 2, and algorithm 3, these notations are Zq[x] explained in this paragraph. Modulus is defined as q, defining the polynomial ringRq= (xn+1) . In LAC, the modulus used is alwaysq = 251.Ψ σ is the centered binomial distribution withσ σ being the distribution parameter where the standard variance is 2 . For a positive integer n, n Ψσ notes the n independently identical distribution ofΨ σ. The message� space M is defined as 0,1 lm for a positive integerl . The space of random seeds S is 0,1 ls for a positive integer { } m { } ls. [57]

Algorithm 1 LAC.CPA.KG()

Ensure: A pair of public key and secret key(pk, sk) 1 : seed $ S a ←− 2 :a Samp(U(R )); seed ) R ← q a ∈ q 3 :s $ Ψ n ←− σ 4 :e $ Ψ n ←− σ 5 :b as+e R ← ∈ q 6 : return(pk := (seeda, b), sk :=s)

The key generation algorithm randomly generates a pair of public key and secret key (pk, sk) [57]

16 Algorithm 2 LAC.CP A.Enc(pk= seed , b), m ; seed S a ∈M ∈

LAC.CPA.Enc(pk=(seed , b), m ; seed S a ∈M ∈ Ensure: A ciphertextc 1 :a Samp(U(R ); seed ) R ← q a ∈ q 2 :c ECCEnc(m) 0,1 lv m ← ∈{ } 3 : (r, e , e ) Samp(Ψ n,Ψ n,Ψ lv ; seed) 1 2 → σ σ σ 4 :c ar+e R 1 ← 1 ∈ q lv 5 :c 2 (br) lv + ¯q cm Z ← × ∈ q lv 6 : returnc := (c1, c2) R q Z ∈ × q

The encryption algorithm, on input pk and message m, it encrypts m with the randomness seed. If the seed is not given, the process is randomized, otherwise it is deterministic for the same seed. [57]

17 Algorithm 3 LAC.CPA.Dec(sk= s, c=(c 1, c2))

Ensure: A plaintextm. 1 :u c s R ← 1 ∈ q lv 2 :c � c 2 (u) lv Z m ← − ∈ q 3 : fori=0 tol 1 do v − q 3q 4 : if c � < then 4 ≤ mi 4 5 :c 1 mi ← 6 : else 7 :c 0 mi ← 8 : end if 9 : end for 10 :m ECCDec(c ) ← m 11 : return m

The decryption algorithm, on input sk and a ciphertext c, decrypts and returns the plaintext message m. [57]

The protocol has two subroutines, ECCEnc and ECCDec which deal with encoding and decoding of the error correction codes respectively. In these, the conversion between a messagem ∈ 0,1 lm and its encoding cm 0,1 lv is provided. The encoding and decoding algorithms Bose- { } ∈{ } Chaudhuri-Hocquenghem Encryption (BCHE) and Bose-Chaudhuri-Hocquenghem Decryption (BCHD) are invoked in these subroutines as can bee seen in algorithm 4 and algorithm 5. [57]

18 Algorithm 4 ECCEnc(m ) ∈M

Ensure: An encodingc 0,1 lv m ∈{ } 1 : ˆc BCHE(m) 0,1 ne ← ∈{ } lv ne lv 2 :c ˆc 0 − 0,1 m ← � ∈{ } 3 : returnc m

The error correction code encryption algorithm converts the message m into a codeword ˆcand padding with 0’s to bec , which is in the space of 0,1 lv . [57] m { }

Algorithm 5 ECCDec(c 0,1 lv m ∈{ }

ECCDec(c 0,1 lv ) m ∈{ } Ensure: A bit string m.1 : ˆc (c ) ← m ne 2 :m BCHD(ˆc) 0,1 lv ← ∈{ } 3 : return m

The error correction code decryption algorithm takes a ciphertext messagec m, decoding c^, returning m. In case of a decoding error, an error symbol is returned. [57]

19 3.7.2 LAC.CCA

LAC.CCA is a Indistinguishably under Chosen Ciphertext Attack (IND-CCA), secure key encapsulation mechanism. The LAC.CCA is obtained by applying the Fujisaki-Okamoto transformation [58, 59] to the LAC.CPA protocol. LAC.CCA has three major algorithms;

• A key generation algorithm (KG) which is the same as in the LAC.CPA protocol, as seen in algorithm 1

• An encryption algorithm (Enc), as seen in algorithm 2

• A decryption algorithm (Dec), as seen in algorithm 3

Notations used are the same as for LAC.CPA, using some additional notations:ﬁrstly, a hash function G : 0,1 lm S 0,1 ls , and a hash function H : 0,1 0,1 lk for generating the { } → { } { } ∗ →{ } encapsulated key, wherel k denotes the length of the session key. In LAC,l k =l m is always set. [57]

Algorithm 6 LAC.CCA.Enc(pk; seedm)

Ensure: A ciphertext and encapsulated key pair(c, K). 1 :m Samp(U( ); seed ) ← M m ∈M 2 : seed G(m) S ← ∈ 3 :c LAC.CP A.Enc(pk, m; seed) ← 4 :K H(m, c) 0,1 lk ← ∈{ } 5 : return(c, K)

The CCA encryption algorithm, when given pk and a seed seedm, it generates a message m and encrypts it by using LAC.CPA.ENC as seen in algorithm 2 with pk, m, and the randomness seed. [57]

20 Algorithm 7 LAC.CCA.Dec(sk, c)

Ensure: An encapsulated keyK 1 :m LAC.CP A.Dec(sk, c) ← 2 :K H(m, c) ← 3 : seed G(m) S ← ∈ 4 :c LAC.CP A: enc(pk, m; seed) � ← 5 : ifc =c then � � 6 :K H(H(sk), c) ← 7 : end if 8 : return K

The CCA decryption algorithm, given sk and a ciphertext, gets a message by applying LAC.CPA.Dec as seen in algorithm 3. It then veriﬁes the correctness of the performed decryption by performing a re-encryption process. If it passes, it returns the encapsulated key, otherwise, a generated pseudo-random key from the sk and ciphertext. [57]

3.7.3 LAC.AKE

There exists an authenticated key exchange protocol based on lattice-based cryptography; this is called LAC.AKE, which is based on both LAC.CPA and LAC.CCA. The protocol is secure in Canetti-Krawczyk mode, assuring weak perfect forward secrecy. In addition, it is resistant to maximal exposure attacks and key compromise impersonation attacks. [57] An overview of the LAC.AKE can be seen in algorithm 8; an overview of its pros and cons can be seen in Figure 11.

21 Algorithm 8 LAC.AKE complete algorithm. Parameters: the speciﬁcation of LAC.CCA and LAC.CPA G: 0,1 0,1 ls ,H: 0,1 0,1 lk { } ∗ →{ } { } ∗ →{ }

Alice Bob

(pk , sk ) $ LAC.CCA.KG() (pk , sk ) $ LAC.CCA.KG() A A ←− B B ←− static public key: pkA static public key: pkB

static secret key: skA static secret key: skB (pk, sk) $ LAC.CP A.KG() ←− $ r 0,1 ls 1 ←−{ } seed G(r , sk ) 1 ← 1 A pk,c (c ,K ) LAC.CCA.Enc(pk ; seed ) 1 1 1 ← B 1 −−−→ $ r 0,1 ls 2 ←−{ } seed G(r , sk ) 2 ← 2 B (c ,K ) LAC.CCA.Enc(pk ; seed ) 2 2 ← A 2 $ K 0,1 lm 3 ←−{ } c ,c 2 3 c $ LAC.CP A.Enc(pk, K ;�) ←−−− 3 ←− 3 K LAC.CCA.Dec(sk , c ) 2 ← A 2 K LAC.CP A.Dec(sk, c )K LAC.CCA.Dec(sk , c ) 3 ← 3 1 ← B 1 K H(pk , pk , pk, c ,K ,K ,K )K H(pk , pk , pk, c ,K ,K ,K ) ← A B 3 1 2 3 ← A B 3 1 2 3

An overview of the LAC.AKE protocol. [57]

3.8 Security of self-organizing networks

Two very useful tools for security of self-organising networks are reputation and trust. In essence, reputation is one entity’s opinion about another, as in how trustworthy the other entity is. Trust is the expectation that an entity has about other entities’ actions. These concepts can often solve problems that are not solvable with traditional security and authentication methods. [60]

There are diﬀerent ways of deﬁning trust. In general, it is a one-way relationship between two entities. For example, entity A trusting entity B does not automatically mean that it is the other way around. "There are three general types of trusts: basic, general and situational"[60]. Basic

22 Figure 11: An overview of the LAC.AKE protocol’s pros and cons. trust is the initial trust a node has to other nodes, not tied to any specific other node. This type of trust is based on the node’s past experiences. General trust is how much one node trusts another, not taking the current situation into account. The situational trust is the amount of trust one node has for another in a specific situation. This is usually the most important in self-organising networks, as this affects the actual trust between nodes when interacting with each other. [60]

There are different methods of initializing trust- and reputation-based systems. Thefirst method is that all entities are initially assumed to be trustworthy. In this method of initializing, the trust decreases with every bad encounter and cannot be increased again. The second method is that all entities are untrustworthy. This entails that the trust increases with every good encounter and does not decrease again. Thefinal method is that the reputation of entities is neutral, that they are neither trustworthy or untrustworthy. In thefinal method, every good or bad encounter makes the reputation increase and decrease. There are two methods for the systems to observe bad and good encounters, thefirst method being using onlyfirst-hand information. This means that the trust and reputation are only based on information directly observed by the entities. The second method is using bothfirst-hand and second-hand information. This method also includes information provided by the peers in its neighboring parts of the system. [60]

23 3.9 Attacks

While VPNs oﬀer protection for the user against attackers and eavesdroppers, they are not invulnerable. There are still some attacks that can aﬀect a VPN, and some of the more common ones are described in this section, such as man in the middle attacks and brute-forcing.

The attacks described in this section were chosen because of how common they are [61], and because they are relatively easy to perform. In addition, these could cause immense damage if the attacker managed to perform the attacks. This would be especially true if the victim was a business.

3.9.1 Denial-of-Service and Distributed Denial-of-Service

When using a server, there is the risk of being the subject of a denial-of-service (DoS) attack, or a distributed denial-of-service (DDoS) attack. The goal of either attack is to disrupt the normal traffic as much as possible. This is done by overwhelming the target, and the attacks are most effective by using multiple compromised devices as the sources of the the traffic. [62] The compromised devices can send out messages, requests for connections, or fake packets, all with the goal to overwhelm the targeted server. This would render the server inoperable. [63] Sometimes, due to poor coding or missed patches, legitimate connection requests might trigger a DDoS. [64]

A DoS-attack is when a single computer attacks, with the intent to overload the network. This is done either throughﬂooding the system with traﬃc, or crashing the system by exploiting a vulnerability. The goal is to take down systems and render them impossible to reach for legitimate users. [65, 66, 67]

Unlike a DoS-attack, which only uses one device, a DDoS-attack usually starts with a large botnet. A botnet is a network of compromised devices, and a command-and-control server, which commands the botnet. There is no limit to the amount of devices in a botnet. Large botnets containing hundreds of thousands of devices are becoming common. These devices generate the traﬃc, which is then sent to the targeted server. [62, 64] A visualization of the controlﬂow of machines in a DDoS-attack can be seen in Figure 12.

While DDoS counts as one attack, it can fall within three diﬀerent categories. Network-centric, also called volumetric attacks, focus on overwhelming a target by consuming all available bandwidth. Protocol attacks focus on the network layer or transport layer protocols, targeting vulnerabilities in the protocols, ensuring overload of the target. Lastly, application layer attacks overload application services or databases by making an immense amount of application calls. [63, 64]

This is mostly a concern with the possible rendezvous point used in this project, and both a DoS and a DDoS-attack will be performed.

24 Figure 12: Visualization of a DDoS-attack. [65]

3.9.2 Eavesdropping

Some attackers seek to monitor communication. The intercepted messages should be close to the original message sent by the victim, with high informationfidelity. This is called eavesdropping, and if done correctly should not alert the sender or receiver of the eavesdropper’s presence. This is often done to intercept authentication credentials. [68] An example of eavesdropping is data sniffing, which is done in order to localize recorded packets of data communication. [69] Sniffing is described in section 3.9.7.

Eavesdropping can be divided into two different categories: passive and active. During passive eavesdropping, the eavesdropper does not interfere with the communication channel, and instead simply monitors it. This makes the attack more difficult to detect, due to not producing any observable effects. Instead, active eavesdropping not only allows the eavesdropper to observe but also modify the content. This means that this type of eavesdropper allows the attacker to insert, modify, or even remove messages before they arrive at the receiver’s end. [68]

It should be possible to prevent any potential eavesdropping through the use of cryptography, in order to obfuscate the communication content. Another way to hide is to send concealed messages, hidden within seemingly innocuous data. The latter is not secure, and rather employs security through secrecy. [68]

25 3.9.3 Man in the Middle

A Man-in-the-Middle (MitM) attack is an eavesdropping attack that can be performed on protocols where mutual authentication is not guaranteed. Two conditions must be satisﬁed for the attack to be run:

• All traﬃc information between two legitimate devices must be intercepted and relayed to the attacker.

• The attacker must be able to impersonate the legitimate devices of the network. These two methods are called traﬃc leading and identity spooﬁng. [70]

A simpliﬁcation of how an attack will be performed can be seen in Figure 13.

Figure 13: The client and the server have had their communication intercepted, and the MitM has inserted himself between them. The client and server are unaware of this, and believe their original connection is the one they are using. Instead, the MitM can see and alter their communication as they seeﬁt.

There are plenty of examples of MitM attacks in modern time, the most well known being the US National Security Agency (NSA) posing as Google, revealed by Edward Snowden. By intercepting internet traffic and spoofing SSL certificates, the NSA was able to keep track of everyone’s Google searches. [71]

There are different types of MitM attacks, thefirst being rogue access points. This type exploits the fact that some computers are set up to automatically connect to public, non-password protected wireless networks. This way, the attacker poses itself as a legitimate public network. By doing so, it aims to steal vital information from devices connecting to it. A second type of attack is address resolution spoofing. With this type, a malicious node on a local area network (LAN) poses as a legitimate machine, making the victim pass traffic through it before passing it on to the actual machine. Another type of attack is mDNS spoofing, which fools devices into connecting to fake addresses. It is used to match names to addresses on LANs, and gives malicious machines access to the vulnerable devices. Afinal attack type is DNS-spoofing, which

26 is used to trick internet users into thinking that a fake website that looks like the real one is the actual website. This one is most commonly known for being used in bank-related fraud. [71]

To prevent a MitM attack, users should make sure that their devices do not connect to public non-password protected networks automatically. They should also make sure that all access points are secure and encrypted, as well as make sure that websites use the latest protocols, HTTPS over HTTP. Adding extra authentication when it is possible and making sure that operating systems (OS) are up to date prevents exploitation of known weaknesses of older OS. [71]

To test the security of the system presented in this thesis, a MitM attack is performed, speciﬁcally an ARP-spooﬁng.

3.9.4 ARP spooﬁng and poisoning

In order to resolve IP addresses to MAC addresses, computers use a protocol called Address Resolution Protocol (ARP). This means that when a device A communicates with a device B, it has to look up the ARP table of device B. If device B’s MAC address is not found, an ARP_request is broadcasted over the whole network, and all the devices connected to it will compare their IP address to the MAC address. If an identiﬁcation is found, a response is sent back and the requesting device will save the IP address and MAC address in its ARP table before communication carries on. [72, 73, 74]

However, this method is not secure, as it is built as a trusting protocol, and can therefore not deal with any malicious hosts. Because of this, a malicious host can make changes to a victim’s ARP table, without being noticed. In addition, by making changes to the victim’s ARP table, it allows an attacker to perform several different attacks, such as a MitM attack. This is done by impersonating a different user by modifying the ARP table. Such a process is called an ARP cache poisoning attack, or ARP poisoning or ARP spoofing. In order to perform a MitM attack, two hosts need to be victims of ARP spoofing, in order for them to think they are communicating with one another, and not the man in the middle. [75, 73, 74]

3.9.5 Brute force attack

The goal of a brute force attack is to gain access to either an encrypted message, a hidden web page, or to crack any password or username. This is done through a trial-and-error method, where the attacker uses software in order to guess a large number of times on the value of the desired data. This can be compared to trying every key on a keyring in hope ofﬁnding the one thatﬁts the lock. If left to their own devices, the attacker will go through all possible combinations. However, it is not always viable for the attacker to perform a brute force attack, due to the fact that such an attack takes a considerable amount of time. Even when software can

27 try 1000 combinations per second, it can still take several years toﬁnd the right combination. [76, 77, 78, 79, 80]

Many attributes have an eﬀect on the speed of a brute force attack. Even if the brute force algorithm is optimized and one password is attempted for every instruction the machine handles, the hardware will aﬀect the performance considerably. If a computer has a commercial high- end CPU (Intel i9-9900K), it would provide a speed of4 10 10 instructions per second and ∗ CPU, assuming 1 instruction per clock-cycle in the CPU. [81, 82] IBM’s supercomputer Summit has a maximum computational power of2, 397, 824 3.07 10 9 = 7.36 10 15 instructions per ∗ ∗ ∗ seconds (IPS), assuming one instruction per clock cycle. [81, 83] If an attacker had access to that supercomputer, they could perform a brute force attack that is as fast as a completely optimized brute-force algorithm could possibly run with today’s hardware.

A speciﬁc type of brute force attack is dictionary attack. A dictionary attack is a systematic brute force attack which is used to breach the security of password-protected devices. The success of dictionary attacks comes from that many users use ordinary words or combinations of words as part of their password. This is often the case because such passwords are simpler for a human to remember, compared to a long pseudo-random password. However, by doing so, a device becomes more vulnerable to a dictionary attack. [84]

3.9.6 VPN hijacking

A VPN hijacking is, in short, when an attacker takes control over a VPN connection and proceeds to impersonate a client machine in the network. [11] However, hacking into a VPN requires the breaking of the encryption through the advantage of some vulnerabilities, or by obtaining the keys used, in any way possible. It is not as simple as it sounds, and it requires a lot of computational power - as well as time - to break the encryption. In addition, most attackers do notﬁnd VPNs to be a viable target, as they would need a large amount of time, funds, and resources to follow through with the attack. [85]

There have been occurrences of VPNs being hijacked, such as when the Heartbleed bug was revealed. Attackers took the opportunity to hijack web sessions over VPNs by exploiting the Heartbleed OpenSSL vulnerability. Researchers were able to emulate an attack by exploiting Heartbleed and extract private keys over an open source VPN software. [86]

This could be compared with session hijacking, which is when an attacker takes control of a session cookie. The cookie contains information about the user, such as their preferences and login details, and often lacks encryption. The cookie is collected by an attacker either through malware installed on the user’s device, or a script on the used website which forces the device to send the cookie data. However, using a VPN protects against this sort of attack, due to encrypting the data. This makes a session hijacking diﬀerent from a VPN hijacking.[87, 88, 89]

28 3.9.7 Sniﬃng

Sniffing is the act of monitoring and analyzing data packets going over computer networks, most often in real time, and is done through the use of sniffer tools. [90] However, it does not alter or redirect the traffic in any way, but merely observes it. [91] Even though it does not affect the packages, it is used by both network administrators, as well as attackers. Because of how it can eavesdrop on the network, attackers might use it to sniff a network of an unsuspecting victim, and can allow the attacker to capture sensitive information, such as passwords and PIN numbers. This is because when a sniffer tool is utilized, a copy of the packets is sent to a part of the kernel, called the packetfilter, and it is from there the sniffer toolsfind the information. [90, 91] There are several different methods of sniffing, and the one that is the most used in this project is ARP-sniffing, which allows the tool to sniff the ARP table. [92]

3.10 Tools

Several tools are used in this project in order to perform attacks. In this section, those tools will be described. Two out of these tools, Ettercap and bettercap, are used in order to test MitM attacks, while XerXeS was used to perform DoS and DDoS-attacks.

3.10.1 Ettercap

In order to perform a MitM attack, the software Ettercap is used. Ettercap is an open source program that is fairly popular, and allows for a user to perform a MitM attack. The program is able to sniff the network tofind the targets, and has additional functionalities, such as actually performing MitM attacks. It has four modules it uses to function, which are IP-based, MAC- based, ARP-based, and PublicARP-based. [93] In this case, the ARP-module is used. In order to perform attacks, it uses unified sniffing as the base for any of the attacks it performs. [94, 95] Sniffing is described in section 3.9.7, and ARP-poisoning in section 3.9.7.

When performing an ARP-poisoning with Ettercap, the program poisons the ARP-cache of the two hosts, in order to identify itself as the poisoned hosts. Then, it intercepts the packages the victims send to one another, records them and possibly alters them, before sending the packages to their correct host. Figure 14 shows how the connections would look like if a MitM attack was performed with Ettercap. [94, 95]

However, as it is not a completely stable release, it suﬀers from several issues. The issues will be described in section 8.7 The Ettercap used is version 0.8.2, and seems not to have been updated since 2015.

29 Figure 14: How a MitM attack is performed with Ettercap. [95]

3.10.2 bettercap

Another tool used for a MitM attack is bettercap. It is a tool that allows for several diﬀerent types of attacks, such as deauthentication attacks, and credential harvesting. It allows for both terminal-based usage, as well as a Web UI that makes it a bit more intuitive to use. It was created as the creators found Ettercap to be lacking, boasting that bettercap is a superior penetration testing tool. [96, 97]

3.10.3 XerXeS

XerXeS is a tool implemented in C that allows a user to perform a DoS-attack. [98] It was created by a user on Github [99] going by the name zanyajamal. It is believed it was created by the hacker The Jester (th3j35t3r), who claims to have used it to bring down the WikiLeaks website. XerXeS is a DoS tool that does not require a zombie net in order to be eﬃcient, and can be used by a low-spec computer [100, 101], which "allows an attacker to launch multiple independent attacks against several target sites" [100].

As mentioned earlier, XerXeS does not use a botnet in order to perform an attack. Instead, XerXeS exploits a vulnerability in Apache HTTP, [98] which is a "robust, commercial-grade, featureful, and freely-available source code implementation of an HTTP (Web) server". [102] By exploiting this vulnerability, XerXeS sends multiple malformed packets to the Apache server, all of which take seconds to process, but only a fraction of a second to send. This allows XerXes to send hundreds of these packets in a second. This results in XerXeS overwhelming the webserver instead of the network, rendering the amount of bandwidth the victim has irrelevant. [98]

3.11 Key Distribution Center

A key distribution center (KDC) is a device that receives and distributes keys to users and devices in a network, in order to share sensitive or private data. Whenever two devices are

30 to make a connection, they have to contact the KDC in order to generate a password unique to them, which is used for veriﬁcation by the end system users. [103] The reason a KDC is used is that if users had to keep all the keys of the other devices in the network, an immense amount of memory would be required. Instead, a separate server is dedicated to keeping the keys, minimizing the memory requirement for all the devices in the network. [104]

The KDC connects two or more devices in a network, and allows for symmetric encryption by generating a unique ticket-type key, used to establish a secure connection where data can be shared and transferred. However, there is a risk that a KDC can be overwhelmed by requests, and KDCs are commonly used in smaller networks for that reason. [103]

In Microsoft Windows, the KDC provides two diﬀerent services. Implementations of the Ker- beros protocol generally oﬀer those services. The Kerberos protocol will be described in section 4.3. The two services are the authentication service (AS) and the ticket-granting service (TGS). [105] Most security implementations of KDCs contain Kerberos. [106]

The AS is used before the TGS to issue ticket-granting tickets (TGT). This is done in order to allow the device to connect to the TGS, both in its own domain or any trusted domain. A device trying to connect to the TGS needs a TGTﬁrst, and the TGT can be reused until it expires. However, theﬁrst access to any TGS requires a connection with the AS, even if the TGT has not yet expired. [105]

The TGS is in charge of issuing tickets for establishing connections to other devices within the domain. A device that wishes to connect to another oneﬁrst presents a TGT to the TGS, and then requests a ticket for the desired device. [105]

A visualization of the process of the KDC can be seen in Figure 15. A description of each step accompanies the image, and gives a better understanding of how the KDC authentication process works.

31 Figure 15: An image depicting the process of a client authenticating itself to the KDC and requesting to communicate with a speciﬁc device. In step 1, the client contacts the AS, and gets a TGT in return in step 2. In step 3, the client contacts the TGS, and presents it with the TGT it received earlier, together with a request for the device the client wishes to communicate with. In step 4, the TGS issues a ticket for the client for the requested device.

4 Related work

Because of the nature of the problem this project is trying to solve, others have tried other solutions to several parts of this project. In this section, a selection of the most relevant solutions is presented. Three of the related work is about authentication andﬁnding other peers. Those include: "Group Encrypted Transport VPN", "Internet Key Exchange Protocol Version 2", and "Kerberos". The last related work, named "Decentralized Bootstrapping in pervasive Application" tries to solve the issue of bootstrapping in networks. All of these were chosen as they are solutions to problems similar to the problem presented in the thesis. In section 8.8, the diﬀerence between the presented solution and the related ones are discussed.

32 4.1 Group Encrypted Transport VPN

Group Encrypted Transport VPN (GET VPN) is an encryption solution from Cisco using a tunnel-less VPN approach. GET VPN oﬀers a secure solution for better scalability of large- scaled, meshed networks with any-to-any encrypted connectivity and increased network eﬃ- ciency. [107]

GET VPN is tunnel-less, and one of its main advantages over other similar protocols is that it retains the original IP header of the packet, and only encrypts the data that is sent. This is done be copying the original IP header and placing it in front of the IPsec header, which the IPsec protocol adds. This ensures that the solution does not rely on point-to-point mechanisms, giving it the capability to scale any-to-any inter-site VPN connectivity. GET VPN is an IPsec model, based on the concept of always having trusted groups. Routers in these trusted groups uses a security methodology that is not dependent on point-to-point IPsec tunnel relationship. [107] Figure 16 shows the basic components of this solution.

Figure 16: Shows basic components of GET VPN, Group Members are actively participating and sharing data, Key Server handles key distribution and negotiation. Encrypted data shared in the “middle”. [107]

A key feature that makes the GET VPN solution superior to other similar solutions includes

33 easy-to-manage, high-scale encrypted communications. Some examples of more of those key features include IP header preservation, easier distribution, and management of security policies, as well as reduced latency for real-time applications, and improved network performance. [107] An overall comparison between a traditional solution and GET VPN can be seen in Figure 17.

Figure 17: Comparision between traditional point-to-point IPsec tunnels and the GET VPN solution. [107]

Highly integrated large-scale meshed networks requires scalability solutions that provide instan- taneous connection without compromising quality or increasing complexity and overhead. One commonly used solution for this issue is Multiprotocol Label Switching (MPLS) VPN, which provides secure communication. However, MPLS VPN does not provide end-to-end encryption, which in many cases is a critically needed feature. Other solutions are DMVPN and Easy VPN, which do indeed provide end-to-end encryption. However, as both those solutions are overlay models, they can introduce delay and suboptimal routing for large-scale meshed networks, adding complexity and overhead to the network. Another alternative solution is VRF-aware IPsec (Virtual Routing and Forwarding) on Provider Edge (PE) routers. Again, this model does not provide end-to-end encryption. Traffic is only encrypted between Customer Edge (CE) and PE devices only. PE to PE traffic is not encrypted, eliminating end-to-end encryption, as well as causing additional overhead on PE routers. However, GET VPN is an efficient alternative to all of these models, providing end-to-end security without using tunnels, offering secure communication for both IP unicast and multicast applications for any-to-any security. GET VPN can also be deployed on any type of network, based on IP, MPLS, Frame Relay, or ATM. [107]

GET VPN and DMPVN are complementary solutions. DMVPN provides spoke-to-spoke and hub-to-spoke connectivity using multipoint Generic Routing Encapsulation (mGRE) and Next Hop Resolution Protocol (NHRP). It queries the NHRP server for addresses of other spokes so it can build tunnels. Until this tunnel is built, traﬃc continues to pass through the hub, possibly causing delays and more complexity for large-scale meshed networks. By using GET VPN together with DMVPN, this delay can be eliminated because connections are static. [107]

34 As mentioned, a key attribute and advantage of GET VPN is that it has header preservation. Packets in GET VPN retains their original source and destination information. This is added in an outer IP Header as shown in Figure 18. Hence, this solution is “tunnel-less”. [107]

Figure 18: Showing how the IP header is preserved when using the GET VPN solution. [107]

The key server is aware of which traffic to encrypt by using an access control list (ACL). The ACL determines which traffic to encrypt. The information regarding the traffic that requires encryption is also sent to each authenticated group member to make communications trusted. Policies that each group member gets from the key server is appended to each member locally configured ACL. The ACLs that are configured locally override downloaded information for the same traffic. [107] This override could be aflaw, and will be discussed further in section 8.

4.1.1 Group Domain of Interpretation

The Group Domain of Interpretation (GDOI) is a group key management protocol Internet Security Association and Key Management Protocol (ISAKMP) Domain of Interpretation (DOI) for groups [107, 108], and is used to ensure that all members in a group and multicast application share a common security policy and keying material. [108] While GDOI is run between between group members, it also utilizes a “group controller/key server” (GCKS), which it communicates with at the same time. This establishes the security associations that are needed. It is vital that the GDOI is protected by a Phase 1 security association. [109] Phase 1 is one of two phases deﬁned by the ISAMKP, and provides mutual authentication and authorization. [108]

The GCKS is a vital part of GDOI, and is a router responsible creating the keys, as well as maintaining them and the policy of the group. It registers new members, as well as rekeys any group members before their keys expire. [107] There are two types of keys the GCKS can issue: the traﬃc encryption key (TEK), and key encryption key (KEK). TEK is used to secure the data plane, meaning it becomes the IPSec SA, essentially rendering it the group key shared among all the group members to ensure secure communication. KEK is instead used to secure

35 the control plane, encrypting the rekey messages, as well as way for group members to decrypt incoming rekey messages from the key server. [107, 110]

In the GDOI model, the participants consist of a group member and the GCKS. The group member contacts the GCKS in order to properly join said group. This step is important, as when the group member is being registered at the GCKS, both mutual authentication and authorization are achieved. Following, the GCKS gives the group member the required group policy and keying material, all done during an authenticated and encrypted session. [109] In order to rekey group members, the GCKS sends out a GROUPKEY-PUSH message, which alerts the group member to update their policies for the group. These updates can contain new material, indications of deleted material, or replacements. It is not required by the GCKS to get an acknowledgment in return from the group members, but it might be beneﬁcial. [111]

4.2 Internet Key Exchange Protocol Version 2 (IKEv2)

In October 2014, a paper called “Internet Key Exchange Protocol Version 2 (IKEv2)” [112] was released, which described a way for IPSec to perform authentication, as well as establishing and maintaining security associations. It was created in order to allow for scalability, and focuses on request-and-response. The security associations contain the shared secret information used to establish the security associations for the encapsulating security payload, or the authentication server, as well as a set of cryptographic algorithms. These algorithms are used in order to protect the traffic. The main advantages of the IKEv2 protocol is that it offers high-security while still enabling both high speed as well as low latency. It offers a 256-bit encryption, the same level of encryption as the layer 2 tunneling protocol. [112, 113]

4.3 Kerberos

Kerberos is an authentication system, designed by Massachusetts Institution of Technology (MIT) as a part of its Athena project. The system was designed by Miller and Neuman, with the intention for it to work on open network computing environments. [114] It is based on Needham and Schroeder’s trusted third-party authentication protocol, together with some modiﬁcations proposed by Denning and Sacco. [115] As with the KDC, Kerberos requires a list of all the clients that are to use it, together with the clients’ private keys. Each client will trust Kerberos’ judgement on the other clients, rendering Kerberos a third-party authentication service. [114] It works under the assumption that all packages that travel over the unprotected network can and will be altered in any way. Because of this, it does not trust the operating system of the client, the host addresses, or any physical security of the host networks. Kerberos uses shared secret keys in order to ensure that the clients in the network are to be trusted. [116] The process of the authentication is the one described in section 3.11, as Kerberos has been integrated as the default authentication package in Microsoft operating systems as of Windows 2000. [117]

Kerberos consisted originally of two parts: the ticket and the authenticator, and both are based

36 on private key encryption. This are described in section 3.11. However, the two parts are encrypted using diﬀerent keys. The ticket is used to ensure that the identity of the client is passed securely between the authentication server and the end server. In addition, the ticket contains information that ensures that the owner of the ticket is the same client that it was issued to, in order to ensure that the ticket was not stolen. The authenticator compares that information with the information it has stored, thwarting any attempts to use a stolen ticket. As stated in the paper "Kerberos: An Authentication Service for Open Network Systems" by J. G. Steiner, C. Neuman, and J. I. Schiller, "an authenticator contains the name of the client, the workstation’s IP address, and the current workstation time" [114], and is encrypted with the session key, which is part of the ticket. However, unlike the ticket, an authenticator can only be used once, and thus must be generated anew each time a user wishes to use the authenticator’s services. [114] As of Kerberos V5, the system can be described as three parts, consisting of a user administration system, a KDC, and a principal database replication system. The latter is used to duplicate the KDC to a backup server. [118]

4.4 Decentralized Bootstrapping in Pervasive Application

The earlier mentioned works both deal with authentication. The paper "Decentralized Boot- strapping in Pervasive Application" [119] by Mirko Knoll, Arno Wacker, Gregor Schiele and Torben Weis instead deals with the issue of bootstrapping in a P2P network. Instead of using a server, such as a KDC, this paper focuses on having a decentralized network where any new node wanting to access the network has tofind at least one peer in the overlay network. The paper states a few requirements vital to a good solution to the bootstrapping issue, and applies those requirements to the already existing solutions. In the end, it is shown that none of the evaluated approaches fulfill all the requirements. Instead, the decision was made to attempt to design a new protocol, offering three different solutions. It was all theoretical, but it is not impossible that the Internet Relay Chat solution could become viable in the future. [119]

4.5 Bootstrapping in ad hoc networks

There are solutions that deal with the issue ofﬁnding the peers without previous knowledge of them, as well as the issue of trust. They also try to solve the issue of having a decentralized solution. Those solutions are very common with sensor networks. [120]

One such solution is presented in "Bootstrapping of Peer-to-Peer Networks" [120] by Gau- thierDickey and Grothoﬀ (2008), there is a solution for complete distributed bootstrapping among nodes. The paper suggest the use of the domain name system in order to acquire the "IP ranges of start-of-authorities" (SOA). This means that the heuristic presented in the paper is able to generate a stream consisting of IP addresses that would be promising entry points. This is done by employing statistical proﬁles, made from the IP ranges of SOAs in the domain name system. The aim is to increase the success rate of boostrapping in a completely decentralized

37 network. [120]

Another paper that deals with this is written by Hoeper and Gong (2006). [121] The paper is specialized on the use of mobile ad hoc networks, which usually consists of multiple sensors, but it is still applicable to regular desktops and similar devices. The paper explains that ad hoc networks lack the possibility to renew keys or revoke them. The authors present a solution where each node in the netowrk monitors the other nodes within communication range in order to distribute the its observations. In addition, the nodes themselves should be able to "verify whether a public key has been revoked". [121]

Similarly, the paper written by by Tseng, Jiang, and Lee (2003) also deals with the issue of bootstrapping in ad hoc networks. In the paper, it is stated that all ad hoc networks are trusted networks and is therefore vulnerable to malicious nodes. In order to solve this, the paper proposes the possibility of integrating the IPv6 protocol into ad hoc networks in order to increase the security of the network. [122]

These are only a selection of works that are relevant to theﬁeld of bootstrapping in ad hoc networks.

5 Design

This section will go through the designs in depth, and the requirements of the system. In this project, a proxy VPN will not be used. Instead, a VPN will be created through the use of key exchange protocols.

5.1 Requirements

The solution has to launch at startup of a client’s computer, and then run stably. The solution has some key features that must be fulﬁlled for it to always run properly. Theﬁrst of this is keeping nodes up to date. This entails updating the node’s information whenever devices enter or exit the network. Therefore, the network topology will change dynamically. If a node is unaware of the changes done to the topology of the network, the node will not function properly, because it would not be aware of its peers.

A second feature is authenticating users that are added to the topology of the network as to keep malicious and stranger devices away from any information, including an encrypted one. The authentication should preferably be performed as the keys are negotiated, since this is the stage in which a malicious device could perform a MitM attack and become a middle-hand for communication between a node and the KDC or other nodes. Theﬁnal step is encryption. Even if a device is authenticated, sending its key as plain-text to the KDC is hazardous, due to the risk of an eavesdropper listening, and therefore getting the key.

38 Another important feature is that the KDC is not directly open, in the sense that it is available to everyone. It should be hidden and only the rendezvous point (RP) and the connected clients should be aware of its IP address. The RP should always be theﬁrst contact for clients following the protocol. The clients should never be able to connect directly to the KDC, even if they have been previously connected. The RP should be easy toﬁnd for new clients, and the IP address to the KDC should not have to be entered manually.

An additional requirement for the PAKE version of the solution is that it implements an authentication server which is mentioned in 3.6.3, to prevent online dictionary attacks from malicious clients.

5.1.1 Key system attributes

Thefinal solution should retain some important properties. Those will be specified and explained in this section. The properties apply to the system when it is not experiencing any abnormal traffic.

• Reliability - The system should be reliable. Clients should be able to stay connected without the risk of being removed from the network unless the client demands to do so, or fails to inform the KDC that they are alive.

• Availability - The system should be available, as in that clients should easily be able to connect to the KDC through the RP without being denied access as long as it gives the correct password and has the correct IP address to the RP.

• Security - The system should be secure; it should not leak any vital information to unauthorized users. Only authenticated clients should be able to take part of such information.

• Scalability - The system should be scalable. Multiple clients should be able to connect and stay connected without aﬀecting the system’s ability to accept new clients, maintain current clients and negotiate keys.

•Eﬃciency - The system should be eﬃcient, it should not spend an abnormal amount of time in certain places of the system. It should run smoothly and be able to perform its key exchange and authentication in a decent amount of time. The solution should at very least be faster than setting networks up manually, any improvement in time is considered positive.

5.2 Design

An initial design of the solution can be seen in Figure 19, where no manual key handling or pairing is done. Instead the network utilizes rendezvous points, where the devices canﬁnd each other and automatically create connections. The main issue with this design would be the

39 security of the system, as it needs to be secure enough that no hostile device gets wrongfully authenticated.

Figure 19: Four devices connected through VPNS to the internet implementing a keyserver and a rendezvous point.

The solution consists of three main components, the KDC, the client(s), and the rendezvous point. For this project, PAKE and RSA were chosen as the key exchange protocols. The reasoning behind the protocols chosen is described in section 8. In the case of using the PAKE protocol, an authentication server would be included as well. A simple visualisation of the two diﬀerent systems can be seen in Figure 20.

Figure 20: Image showing a simpliﬁed version of the RSA design, colored in yellow, and the PAKE design, colored in blue.

The connected clients must have a key negotiation phase, together with an undeﬁned amount of session keys to those devices they wish to communicate with. In turn, the rendezvous point should act as a gatekeeper, protecting the KDC from any attacks, such as DDoS-attacks. This

40 would remove the risk of a single point failure. If the RP goes oﬄine due to an attack, the KDC should be safe and still online, ensuring the network is still alive. The only limit the system would experience would be the inability to introduce new clients. Already connected clients should be able to continue undisturbed, in the case of the DDoS-attack taking out the RP’s hardware. The KDC keeps a list of the connected clients, which needs to be regularly updated. It will update the list whenever:

1. A new client enters the network.

2. When a client leaves the network.

3. When a client wishes to communicate with another.

The second requirement requires the client to send a message to the KDC, informing the KDC that the client is leaving. After that, the KDC can update the list by removing the leaving client and updating connected clients with the new list. Should there be any reason that the message does not reach the KDC, the client will remain in the list until someone requests to speak to the oﬄine device. The KDC will send a request to the oﬄine device. When it fails to get a response back, it will update the list and remove that device from it. Should there be a power failure and the KDC server has to reboot, it should update the list as well.

5.2.1 PAKE

In the case of PAKE, an authentication server is to be implemented. It is situated between the rendezvous point and the KDC, and requires a password. The authentication server protects against dictionary attacks, and does that through a local password cool-down. If the password is saved on the device instead of entered manually, the client only gets one try to try to connect to the KDC. Should that fail, the authentication server locks that user out, and ask them contact administration to unlock. This eliminates the risk of the human error when typing in the password, and allows for passwords with higher entropy since a human does not have to remember the password. However, if a malicious attacker manages to get a physical hold over the device, they will have complete access to the KDC. The authentication server is implemented together with the RP, as to not add another hardware implementation to the system.

Should the authentication server notice thatN devices become locked within the timeframe t, it will issue a global lock, and stop any new clients from accessing the KDC.N andt can be modified depending on specific solution cases. Some affecting factors are if passwords are manually entered or not and how much traffic can be expected.

The speciﬁc PAKE type used in the PAKE solution is the J-PAKE protocol which is explained in section 3.6.3.

41 5.2.2 RSA

The key exchange part of the system in the RSA version of the solution uses the RSA protocol to negotiate keys with the RP and KDC, as well as a password to authenticate itself at the RP. If the password does not match, the client will not be sent to the KDC and will instead be rejected.

The system starts with exchanging the public keys between the RP and the client. Afterwards, the RP sends the IP and port of the KDC to the client, all encrypted with the client’s public key. This is the last contact with between the client and the RP, and the client is instead connected with the KDC. It repeats the same steps by exchanging keys, and then proceed to communicate.

The password is saved on the devices themselves, and therefore the client should not input the wrong password. An attacker should not be able to forge the password, as it is a pseudo-random password consisting of lowercase letters and digits. This password could certainly be changed. This was done in order to eliminate the potential human error with passwords chosen by users, as they often lack the entropy a pseudo-random password provides.

5.2.3 Rendezvous point

In this project, an RP is seen as a common server at which all devices connected to a network congregates in order to authenticate themselves. In addition, the devices are able to receive the required keys for whatever devices they wish to communicate with. This could be a KDC, described in section 3.11, or something else that funnels the communication towards the desired device. In this case, a KDC was seen as the easiest way to do both the authentication, as well as the distribution of the keys.

6 Method

When designing the system, the diﬀerent protocols and cryptosystems were evaluated in order to understand which ones were to be tested in this project. They were compared, their pros and cons carefully studied, and in the end it was PAKE and RSA that were selected to be used. The motivations for each protocol can be seen in section 8.

Initially, the work was done on laptops, using the local hosts in order to emulate the server, rendezvous point, and the client. All the diﬀerent ways of exchanging keys and communicating were created on the laptops, and moved onto a desktop when a suitable one was acquired.

However, this proved to be a hindrance once attacks were commenced, and a second desktop was used, to split the KDC and the RP. The attacks were then performed once more.

42 6.1 Hardware

In order to perform this project, several diﬀerent devices were used. In this section, all of the hardware will be described, as well as named for easier understanding in the rest of the report. The hardware included laptops, desktops, and raspberry pis.

6.1.1 Laptops

Laptops were used to test the structure of the system. Two Macbook Pros were used, both from Mid-2014. From hereon, they will be referred to as Attacker_1 and the other as Attacker_2, to separate the two laptops as they have slightly diﬀerent technical speciﬁcations.

Attacker_1 is a Mid-2014, 13” retina Macbook Pro laptop from Apple, and it has 16GB RAM, an 3 GHZ Intel Core i7 dual-core processor, and was running MacOS High Sierra 10.13.4. Attacker_2 is also a Mid-2014, 13” retina Macbook Pro laptop from Apple Inc. It has 8GM RAM, 2.6 GHz Intel Core i5 dual-core processor, and was running MacOS Mojave 10.14.4.

6.1.2 Raspberry Pis 3B+

Raspberry Pi:s are small computers the size of a credit-card. These computers are sold at a low cost, and allows a user to explore computing and programming. It is possible to connect a standard mouse and keyboard to them, and because of their HDMI outputs, it is possible to connect Raspberry Pi:s to computer monitors or TV:s. The small computers have gotten popular as they can do everything that a regular desktop can do, but in a smaller format. [123]

Two small Raspberry Pis of model 3B+ were used, most often as the clients and sometimes as additional attackers. This model of Raspberry Pi has a 1.4GHz 64-bit quad-core processor, 1GB LPDDR2 SDRAM, [124] and both the Pi:s used the raspbian OS, which came pre-installed on their memory cards.

6.1.3 Desktops

The desktops used for the rendezvous point and KDC server were of the model HP EliteOne 800 G.

The KDC_desktop had 16GB of RAM and an Intel i7-4790S 3.2GHz * 8 processor, running Ubuntu 18.04. This desktop always hosted the KDC:s for the chosen protocols. The RP_desktop was similar, with it’s 16GB RAM, but had an Intel Core i7-4770S 3.10GHz*8 processor. It also had Ubuntu 18.04. This desktop, in turn, always hosted the rendezvous points.

The network used when setting up the test system was a wireless hotspot created on the KDC_desktop using a Wiﬁ adapter.

43 6.2 Implementation aspects common between PAKE and RSA

As major parts of the systems have overlapping functions, many implementation steps are mirrored in both the PAKE and RSA implementation. These will be mentionedﬁrst. Any diﬀerences will be noted and elaborated in section 6.3 and section 6.4.

6.2.1 The client

Thefirst implementation of the client was a python script that connected to an RP without any authentication and then get forwarded to the KDC to receive a confirmation message. It would then close the connection. When this was functioning, the client kept the connection with the KDC alive, in the form of a simple chat program, allowing the client to send messages to the KDC. Thisfirst implementation was done using a guide found at Realpython. [125]

As a next step, authentication was added. This was done a differently for PAKE and RSA. As a first response to successful authentication, KDC information, such as the port and IP, was given to the authenticated client. While this was the same for both implementations, the encryption of this vital information was handled differently in the two protocols.

When authentication had been implemented, the client could connect to the KDC through the RP and keep the connection alive, but had no way to end the connection. Handling of a keyboard interrupt exception was added. When such an exception was found, the client automatically sent a standard quit message, namely ‘q’ to the KDC.

When all of this basic functionally had been implemented, both system’s key exchange algorithms were implemented. This was done diﬀerently for the diﬀerent solutions, and will be described in detail in their respective sections.

Once the key exchange was implemented in the client, handling standard messages was implemented. This included both sending to and from the KDC, as well as predeﬁned responses to the KDC’s messages in the clients. The KDC could send to the clients either an “ALIVE?” or a “CI” (Client Information) standard message. The handling of an “ALIVE?” message consisted of sending back a standard response message, an “ACK”. If the standard message received is a “CI”. The information sent together with the "CI" message had to be saved to a textﬁle containing all information of connected clients in the system. When this was done, a standard response message, a “GI” (Got Information) was sent to the KDC. On the client, the outgoing messages were all handled in one thread, while incoming messages from the KDC were handled in another thread. An additional standard message existed in the PAKE solution, an “ERR” which the RSA solution does not use. The "ERR" message signaled that the authentication server had issued a global lock.

Theﬁnal password used for authentication in both methods was a pseudo-random password. This was given by a generator that was created by simply using os.urandom(32).

44 6.2.2 The rendezvous point

As afirst simple implementation, the RP gave all clients the information of the KDC in the form of plaintext when they requested it. When thefirst setup of the system was working without any issues, authentication was then added for both solutions. The authentication differs some between PAKE and RSA.

After authentication had been implemented, encryption was added to the system information that was sent to authenticated clients. In this step, the RP also got threading implemented. Each connecting client was given its own thread to achieve parallelism to a certain degree.

The PAKE RP also got an authentication server implemented to protect it from online dictionary attacks. The RSA RP did not get that implemented.

6.2.3 The key distribution server

Atﬁrst, the KDC simply received requests from clients that had gone through the RP. As an initial response to this, the KDC simply let all such clients connect and sent them a welcoming message. The message informed the clients that they had been connected followed by closing the connection. As an additional step, keeping the connection alive was implemented, as well as receiving messages from the client. This was done to be able to manually check that connections did not crash.

The next step was to implement a way to keep track of clients. The KDC was given an integer, which was updated in order to keep track of how many clients were connected, and a list of all connected clients. Additionally, logging each client’s IP and port to a plain textﬁle was implemented. When this was completed, clients were given the opportunity to request to leave the network. This was done by whenever the KDC recognizes a quit message, namely ‘q’ from a client. Doing so, it closed the client’s connection, removed it from the list, and updated the textﬁle.

When the system to handle new and leaving clients was fully set up, the two key exchange protocols were implemented. This was done diﬀerently for PAKE and RSA.

When the key exchange was completely set up, the KDC was given the ability to recognize dead clients. This was done by adding standard messages. Theﬁrst two standard messages were “ALIVE?” and “CI”. Whenever the KDC wanted to check if a client was still alive, it send that client an “ALIVE?” and expected an “ACK” as a response. Whenever a client left or joined the network, the KDC sent all currently connected clients a “CI” followed by all connected clients’ information encrypted. The KDC expected a “GI” as a response for this to make sure clients received the information. Threads were set up so that one thread was always checking if clients were alive, looping through the list of clients. One thread would handle sending client information to clients on events when it was deemed necessary. In addition, each client got its own thread

45 for handling incoming message from this client. “ALIVE?” messages were sent continually in a serial manner while “CI” messages were sent once for every triggering event.

Thisfirst implementation of standard messages had some issues, namely data races. To solve this, a list offlags was implemented where each client had its ownflag. Theflag could be set to either FREE (0), ALIVE (1) or CI (2). Whenever theflag for a client was set to FREE, this client was deemed ready to receive standard messages. If theflag was either ALIVE or CI, the KDC had to wait for the clients standard response.

On receiving a standard response, the KDC sets the client it just communicated with to FREE. This allowed new standard messages to be sent to that client. To prevent dead clients from holding theflags forever, possibly stopping the "ALIVE?" message of the KDC as this was done serially for the clients, time limits were implemented for how long the KDC could wait on any clients standard response. If the time limit was exceeded, theflag was forcefully freed and the client was deemed dead in the case of freeing an ALIVEflag.

Whenever clients were handled any form in the solution’s iterations, either by sending messages, receiving messages, or removing clients, safety checks were added to make sure the client had not left the system during the iteration. This was done as a client could be removed both in the thread checking if clients were alive, but also if the thread handling messages for each client received a quit message.

As afinal step, a sleep offive seconds were added in between every “ALIVE?” message that the KDC sent out to its clients. It still sent them out serially, but with afive second wait not counting delay between the transmissions.

6.2.4 Application programming interface

A simple application programming interface (API) was implemented at a later stage. This was done in order to be able to dynamically keep track of the clients connected. A pythonflask API was created, which simply shows the information in the textfile that keeps track of the client information. The API works with both the RSA and PAKE implementation, and has its own specific URL suffix. The API was designed to be used for efficient experiments. It is not an important part of thefinal design, but rather a tool to get an overview of connected clients and if their keys were properly negotiated.

46 6.3 PAKE

The PAKE solution started out byﬁnding an already built version of the protocol in python. A github repository, on Github [126] contained predeﬁned functionality for implementing the PAKE protocol. The instructions were followed, and a simple prototype for exchanging keys using PAKE was built by using python sockets and already known connections. Once this was done, attention was given to building a prototype of the Client, (RP), and (KDC).

When prototyping the initial setup of the system, Realpython [125] was used as a guideline for making socket connections. The initial setup was simply connecting then KDC and the client ﬂawlessly through an RP. Once this was done, the three parts of the systems were constructed, namely the KDC, the RP and the Client.

6.3.1 Client

When authentication was added for the PAKE solution, it wasﬁrst done by sending a plaintext password over sockets. Following theﬁrst simple plaintext authentication, a one-way hash was added in order to ensure the safety of the password. It would make it impossible to crack the password. This was done by using the python3 passlib modules pbkdf2_sha256 hashing and salting. The password was hashed and salted with 200,000 rounds with a salt size of 16 and then sent to the RP for authentication.

Receiving responses from the RP after the client authenticated itself was initially done in plaintext. As a next step, the KDC information was also encrypted. This is done by generating a key based on the password which both the RP and client is aware of by using base64 encryption and pbkdf2_sha256 to get a key which is then used with fernet to encrypt and decrypt the information. As the key was generated with the password, it was identical for both client and RP. The key was generated by using a guide found at Nitratine. [127]

When connection between client and KDC had been properly established, a python version of the PAKE protocol was found and implemented at Github. [126] This codebase was used to generate a jpake key in the client based on a predetermined pseudo-random password that both the KDC and the client agrees on before making any connection. The codebase had to be altered due to some existing bugs and converting it to python 3 from python 2.

As aﬁnal step, the standard ERR message from the RP was added as a standard message. This message is followed by an informative message telling the client what went wrong when trying to connect to the RP.

6.3.2 Rendezvous point

After theﬁrst simple RP worked, hashing was added to the password. A one-way hash pbkdf2_sha256 was implemented. Since the RP was already aware of the correct password, it could simply verify

47 the password by using the .verify() function. The function utilizes the known password and the hashed message received as parameters.

When encrypting the KDC information, it was encrypted in the same way as mentioned in section 6.3.1.

As afinal step, an authentication server was added to the RP. This was done to make the system secure against online dictionary attacks. Whenever a new client gives the RP an incorrect password, it is added to a list of banned clients. A global counter is also incremented to make sure an attacking device could not spoof its IP and try over and over. The global counter has an initial limit set to one. When this global counter reaches the set limit, a global lock is applied, making it so no new clients can connect to the RP. It will remain locked until a system administrator has looked into the malicious behaviour, and resets the counter to zero. The authentication server also has a time limit. Once the limit is reached, the authentication server clears the global counter and sets it to zero. This was initially set to 600 seconds, but can be altered tofit different systems using either manually entered or hard coded passwords.

A standard message from the RP of the type "ERR" was also implemented. This was used to send messages to the clients attempting to connect when the RP was in a global lockdown, thus informing the clients that the RP is online but unavailable.

6.3.3 KDC

When an initial setup of the system and handling new clients was fully set up, the PAKE protocol was implemented on the KDC simultaneously as it was implemented on the client side. This was implemented to negotiate the keys between each client and the KDC. The protocol was implemented by using the same codebase as for the PAKE client.

6.4 RSA

The RSA solution consists of three parts: the client(s), the RP, and the KDC. They have a lot in common, and any shared parts will be described here. A more in depth description of each part is found in their respective subsection.

The RSA started out with a simple server and client, described in section 6.2. These were made to communicate, and to use RSA cryptography once communicating. Functions were created in order to ease the encryption and decryption, and sent between the client and server through the use of sockets. Once that was working without error, a rendezvous point was introduced, and the server became the KDC. Now, the client was to communicateﬁrst with the rendezvous point, which would in turn give the authenticated client the IP and port of the KDC. A random password was generated and saved, temporarily, in the client and rendezvous point, in order to enable authentication.

48 How the RSA cryptography works is described in section 3.6.2. Because the diﬀerent parts of the system all have the same cryptography functions, the functions will be described below.

In order to encrypt, a function called encrypt() was created, taking a message and the socket to send the message over as parameters. The message wasﬁrst encoded in order for it to become an object of the type byte, before it was encrypted with the destination’s public key. In order to ensure this would be safe and transferred properly, as well as be read properly by the destination, it was serialized. The serialization was made through the use of pickle, which is python’s library for serialization. In addition, a SHA-1 hash was added, with the hash-length of 20. After all this was done, the message wasﬁnally sent over the socket.

In turn, the decryption() function received the message, and checked the hash. If the hash did not match, it would throw an exception. The destination would have the same hash length, and ensures that what is written by the encryption function was the same as the decryption function received. Once the hash had been veriﬁed, the message wasﬁrst deserialized, before decrypted and decoded.

6.4.1 Client

When thefirst simple implementation of the system was runningflawlessly, RSA keys were generated. A private key and a public key were created, and were used in order to encrypt and decrypt messages. In addition, python’s own serialization called Pickle was used. In order to ensure that the hashing of the pickling was done right, code from Stackoverflow was used. [128]

When the client managed to establish a connection to the KDC, they began exchanging keys. The clientﬁrst sent their key, before receiving the KDC’s key. Before the RP and a password were implemented, the client and the KDC only exchanged keys used for cryptography, before they began sending information. Once that was working, the client began communicating with the RP instead, as the middle point between the KDC and the client. This time, the password was encrypted and sent after the key exchange, before it got the IP and port of the KDC back in return. This is the last part of communication between the RP and the client, before it moved on to the KDC, where it once again had to exchange the keys as before.

After the client had successfully exchanged keys with the KDC, it began communicating by sending messages that the user input, or answering requests for acknowledgement by the KDC. Every- thing that was sent between the parties was encrypted with the other party’s public key.

6.4.2 Rendesvouz point

The rendezvous point uses RSA cryptology, and had its own private and public key in order to use the RSA cryptography.

49 In addition, the rendezvous point had a password check implemented, where it compared the password sent by the client to a static password. When they matched, the rendezvous point sent a message back to the client containing the KDC’s IP and port, all encrypted with the client’s public key.

6.4.3 KDC

Once the initial implementation was deemed a success, the RSA protocol was implemented, allowing for cryptography with the generated keys.

6.5 Setting up the server

The code for the RP and KDC was moved onto a desktop, and the IP address was changed to remain static. That address, together with the chosen ports, would remain static and hard coded to ensure that the clients couldﬁnd it. The clients would still only connect to the RP, and not retain any knowledge of the address of the KDC.

6.6 Attacks

The attacks attempted on the RSA and PAKE solutions were a MitM attack, a DoS and DDoS- attack, and a theoretical brute force attack. A motivation as to why the attacks were chosen can be found in section 3.9.

The attacks were done the same way on both protocols, and therefore only the general way will be discussed here, along with the results of the Dos and DDoS-attacks for both key exchange protocols described in section 7.2. Because the MitM attack and the brute-force were not completed, they will be presented in section 8 instead. The DoS and DDoS-attacks were completed, and the method will be described here.

6.6.1 DoS and DDoS

XerXeS, a tool which is explained in section 3.10.3, was used to perform the DoS-attack on the KDC. XerXeS was run through the command ./xerxes . Initially, port 80 was tested, just to ensure that the software worked. In order to make sure that traﬃc was indeed sent over the network, Wireshark was run in the background of one of the laptops. The data rate of XerXeS was approximately 560Kbps, and the size of each packet was approximately 113 bytes.

In the attack on the RSA implementation, port 50000 was tested as it is the one used for RSA. Initially, the attack was run against the desktop containing both the KDC and the RP. Because the RP adn the KDC were hosted on the same desktop, issues and interference arose. Therefore,

50 it was tested once again, with the KDC and the rendezvous point hosted on diﬀerent desktops. This time, the test was done several times, using both Attacker_1 and Attacker_2, as well as the Raspberry Pis. A table of the diﬀerent attack setups can be seen in section 7.2.

7 Results

This section will present the results found, but does not discuss theﬁndings. Any discussion will be seen in section 8. This section contains the results from the general testing performed, as well as the results from the attacks performed.

The section starts by discussing the system, and the general testing performed, in order to present a baseline for the system. Then, the results from the attacks are presented, with the information gathered from the attacks performed.

7.1 General testing

General tests were conducted in order to get a baseline reading for how the system would behave, without any malicious intent or other interferences aﬀecting the system.

Some general tests were conducted to determine general properties of the implemented system. All these tests were done during normal runtime environment, when no abnormal amount of traﬃc from attacking devices took place.

7.1.1 Robustness

Robustness of the solutions was tested by starting an instance of the RP on one desktop, an instance of the KDC on one desktop, and connecting a client from a raspberry pi. These were left during a longer time period and made sure that the client was still connected after this time. The longest time they were left connected and running was 18 hours overnight. The solutions were tested during the days as well, but with shorter time connected, around three hours at a time.

Both solutions could keep an active connection with a single client connected during the tests conducted. Even during long time testing where test were conducted overnight during a timespan of 18 hours, both solutions kept its client alive and did not disconnect the clients.

7.1.2 Theoretical scalability

Scalability was tested by addingﬁve clients at once. Since a limited amount of client machines (raspberry pis) were available, multiple instances were launched on them. Once the clients had

51 started connecting to the system, the output of all terminals were monitored and any abnormal output was noted.

After theﬁrst set of tests, someﬁnal changes were done to the code as mentioned in 6.2.3 in the last paragraph. When these changes had been implemented, the systems were tested again.

Theﬁrst set of scalability tests for PAKE, gave an output of transmissioning client information in the wrong order. Other than this, all clients connected to the KDC and were kept alive. For RSA, theﬁrst set of scalability tests returned an error.

After the code changes as previously mentioned, a second set of scalability tests were performed. These tests displayed no errors, or any signs of the program executing out of order.

7.1.3 Eﬃciency

Effectivity was tested by timing the different parts of the solution. The tests were done by measuring the time it took for the KDC to receive standard responses and how long time it took for a client to connect on average. The times that were collected were noted. These tests were conducted both manually and by code. The manual calculations were performed on shorter time spans and transmissions, while the code was used to measure time on a larger amount of transmissions. For the automatic testing, one test instance for each protocol was run with afive second sleep on the KDC before sending a new alive message and another was run without this sleep.

For the manual testing, the average connection time for RSA was measured to be 0.19 seconds when performing 100 connections. The average time between sending an “ALIVE?” message and receiving an “ACK” from the clients was 0.56 seconds. For the PAKE solution, connection time averaged at 3 seconds and the time between sending and receiving alive messages was 0.76 seconds.

When doing the automatic testing without aﬁve second sleep by calculating average time between transmitting an “ALIVE?” and receiving an “ACK” yielded that the RSA average transmission time was 0.62 seconds, and the PAKE average transmission time was 1.24 seconds.

When doing the same testing with aﬁve second sleep time, RSA average transmission time was measured at 0,64 seconds, and the PAKE average transmission time was 1 second.

In all cases of eﬀectivity testing, the times measuredﬂuctuated. The slowest and fastest times measured for the protocols in terms of transmission time can be seen in the table below. Protocol Slowest Fastest RSA 3.03 0.047 PAKE 2,1 0.7

52 The slowest and fastest times measured for the protocols in terms of connection time can be seen in the table below. Protocol Slowest Fastest RSA 0.7 0.03 PAKE 3.13 2.7

7.1.4 Authentication server

For PAKE, a simple brute-force attack was tested to ensure correct functionality of the authentication server that had been implemented. This was done by simply trying to connect a single client using an incorrect password for authentication and note down how the authentication server reacted to clients connecting after thisﬁrst client had attempted.

When testing the PAKE authentication server, the outcome was that once a client had entered a bad password, no matter what the next clients entered as a password, they all were given a standard ERR message as response. Stating that a global lock had been applied to the RP and that the user should contact their system admin to solve the lock. This worked as intended.

7.2 DoS and DDoS-attack

The results from the DoS and DDoS-attacks will be presented in this section. The results were evaluated as "failed" or "survived", depending on if the clients could still connect to the RP and KDC, even while the attack(s) were running. If the run was evaluated as "failed", this would entail that the clients were unable to connect to the RP or KDC, while evaluating a result as "survived" would mean that the clients were still able to communicate with the RP or KDC. The "survived" criteria does not take into consideration if there was a delay. The "failed" criteria would entail that the RP crashed from the amount of traﬃc. The results were classiﬁed on whether they survived for 10 minutes.

PAKE was tested with XeXeS once the KDC and the RP had been separated. As can be seen in Figure 21, it did not deal well with a DDoS-attack. It could handle a simple DoS-attack, but anything above two devices made the RP crash within two minutes. Once it reached four devices, the RP went down in less than 20 seconds. While the PAKE solution could withstand a single DoS-attack and a DDoS-attack of two attackers, it still suﬀered delays. Clients that tried to connect would suﬀer delays in answers when they tried to reach the RP. No delays was observed when the client reached the KDC. The delays were no greater than one second.

Against the RSA implementation, the attacks were run twice, due to changes in the hardware used. Theﬁrst run’s results can be seen in Figure 22 and Figure 23. This was when the RP and the KDC were implemented on the same desktop, which was KDC_desktop. Figure 22 shows that the system could handle single DoS-attacks, and to some extent a DDoS-attack. However, as soon as it was four devices attacking, or two terminal windows on the two laptops, the RP

53 Figure 21: The result of attacking the PAKE implementation with DoS and DDoS-attacks. The check- marks symbolizes that the system remained functional, with or without delays. The X means that the system crashed within 10 minutes.

Figure 22: The result of attacking the RSA implementation with DoS and DDoS-attacks while the KDC and the RP were on the same desktop. The RP crashed after about 15 seconds. The Figure 23: The result of attacking the check-marks symbolizes that the system RSA implementation with a DoS-attack remained functional, with or without de- lasting over 12 hours. The RP went down lays. The X means that the system after about nine hours, which the cross crashed, in this case after 15 seconds. symbolizes. crashed. This rendered the KDC unable to be reached, most likely because of them being on the same device.

In the second run, the KDC and RP were separate, and Figure 24 shows the results from the tests

54 done with XerXeS. It could handle a DoS-attack, but started suﬀering when the DDoS-attack began. Four devices was more than it could handle. Delays were observed as soon as the attacks became DDoS-attacks. The delays were only observed when the clients were communicating with the RP. The delays were often below one second.

Figure 24: The result of attacking the RSA implementation with DoS and DDoS-attacks while the KDC and the RP were on the separate desktops. A checkmark symbolizes that the solution was able to stay online throughtout the attack. The X symbolizes that the RP crashed.

8 Discussion

In this section, several parts of the project are discussed, and arguments for decisions made during the project will be made clear as well.

Important design choices will be presented and discussed, in order to explain why those decisions were made. This is important, because RSA is usually compared to DHEKE instead of PAKE. It is a peculiar decision to compare those protocols, and it is therefore important to explain the reasoning behind the decision. This section will also discuss the hardware used, and any shortcomings found.

In addition, the design itself will be discussed, as this is a major part of the project. It is the foundation of the whole implementation, and if there are any issues in the design, they will be mirrored in the implementation. Therefore, the design will be scrutinized and any possible improvements or issues with it will be mentioned.

There is always a risk of the human error causing issues in the implementation stage, and it is therefore important to scrutinize the method in order to see whether there were any faulty

55 actions taken. In addition, this allows for commendations for good decisions.

The attacks and the tools used to perform them are also discussed, especially since they presented so many issues. This will be explained in section 8.6. Lastly, the related works presented in section 4 will be discussed, comparing the similarities and diﬀerences, as well as discussing if the solution presented in this thesis could be integrated with the related solutions.

The hypothesis of the project is that the RP will protect the KDC from any unauthorized devices, as well as protect the KDC from attacks such as a DDoS. This section discusses whether this hypothesis is conﬁrmed or rejected. This mostly relates to the discussion about the results presented in section 7. However, it will also present the correlation to the initial questions presented in section 2.

In the case of the PAKE solution, where trust is implemented in the authentication server, trust is based on a binary scale. The initial value of each connecting client is set to trustable. If a client then fails to properly authenticate itself, it is instead seen as completely untrustable, no matter if it has been able to authenticate itself before. If too many untrusted clients tries to connect to the PAKE solution, all clients’ trust will be set to untrusted, making it so no clients can connect.

It is important to notice that these protocols are only key exchange protocols, and do not provide any authentication. They are only a way to ensure that the messages sent will remain unreadable by any unauthorized devices.

Theﬁve key concepts of secure systems in section 1 are evalutated in terms of how well this project applied them.

• Conﬁdentiality is maintained by encryption of data that is openly transmitted between client, KDC and RP. This is done in both the PAKE and RSA implementation of the solution.

• Authenticity is implemented through password based authentication of new clients that are to receive any vital information. This, combined with the fact that the KDC and RP are predetermined, ensures that the solution applies authentication.

• Trust is used both between the KDC and the clients. It is mentioned thoroughly in section 8.4.3 and section 8.4.4 for the PAKE and RSA solution respectively. The KDC and the RP are seen as trusted authorities, as all clients connecting to the system has complete trust towards both the KDC and the RP. There is a chance for this aspect to be vulnerable when it comes to intercepting and altering data through MitM attacks.

• Availability is ensured since all connecting clients are aware that the RP should send client information in an encrypted format. In addition, all standard messages are formatted through a speciﬁc method, which is a demand of availability.

Therefore, it can be seen as theﬁve key concepts have all been applied correctly to the presented solutions.

56 8.1 Issues

Because of the amount of issues suﬀered during this project, this section is dedicated to present and explain several of the problems encountered. Some issues were related to the workplace at the university, while others were general problems with the project itself.

8.1.1 General issues

No network simulation tool was used, due to the fact that none of the found network simulation programs were adapted for this project. This is not optimal, and should there be a possibility to apply such a network tool, it should be done. This could possibly have been something that improves the workﬂow, or helps with the design of the system, as simulations could have been run, and it is a great waste to not have run such a tool in the beginning of the project.

When scalability was tested, due to resource constraints onlyﬁve clients connecting were tested as only two actual machines were available as client machines. Would there be more available, scalability would be tested more thoroughlyﬁnding a turnpoint where the KDC cannot handle any more clients. In addition, it was only theoretical scalability, since the clients were emulated.

8.1.2 University-related issues

A major setback in the project was that work got stalled due to outside forces, such as the university having issues with designated rooms, and therefore the project suﬀered a lot in terms of implementation and testing. This was something the authors were aware of, but unable to change. Thus, the project might not have been as extensive as it could’ve been, and more research is necessary.

Duringﬁrst setup, when eduroam was used as the network, connecting with sockets did not work, and neither did pinging. Resolving this issue took an excessive amount of time and in the end, a hotspot wireless network was used instead.

57 8.1.3 LAC.AKE

SwiftieTerrence, a user on GitHub, provided the code on Github [129] for the LAC.AKE method to the public, which was last updated on October 19, 2018. There were three diﬀerent versions to choose from, an optimized implementation, a reference implementation, and a supporting implementation. While an optimized implementation might have been most desireable, it was sadly optimized for Intel-architecture. The Raspberry Pis used are built on ARM architecture, and therefore the reference implementation was used.

However, the code was written completely in C, while everything written for this project was done in Python. In order for it to work with this project, Python had to be extended, as rewriting the oﬀered C-code into Python would take far too long. Thankfully, the Python used was of the CPython type, meaning it could be extended with C. While it was possible, it proved to be quite challenging to get it to work, while still ensuring that the LAC.AKE code was still functioning.

There were a lot of issues with C notfinding certain frameworks andfiles, resulting in a myriad of errors that were not easily solved. This was not only affecting the extension itself, but the Makefile as well. It took several days to solve the errors and to get it tofinally work together with the created solution. When all the issues with extending the code was dealt with, only the necessaryfiles for LAC.AKE were kept.

This, in turn, presented new issues withfiguring out whichfiles were safely discarded and which were vital for the code to work. However,finding the correctfiles to keep seemed to be impossible to achieve within the given timeframe. Instead, all the code that deemed necessary were merged into onefile. This proved to be much more time effective, even though it might not yield the most readable of codes. That was not an issue in this case, as functionality was all that was required, and the properly structured code is still available at the source.

8.1.4 Hardware

The hardware that was used would be enough for a simple setup, but proved to have issues once the testing began. Some of the hardware was not strong enough, and sometimes they desktops would not accept the Wiﬁ adapters. New adapters had to be bought, and it took time before they worked with the desktops, especially the RP_desktop.

In addition, the laptops ran graphical interfaces, which meant they were not completely focused on simply performing the attack. Other software, such as anti-virus, would run in the background, especially on Attacker_1, which could affect how the attacks performed. The laptops were running Mac OS X, and it is uncertain if some of the tools used would have worked differently on other operating systems. Unfortunately, the laptops were suffering from batteries that were in dire need of service, and therefore dual-booting with different operating systems was not a viable solution. Because the battery was in such need of service, there were concerns whether

58 the laptops were working on their full capacity. It is possible this issue with the batteries aﬀected the laptops’ performance.

If the system was to be employed outside of a test environment, proper servers would most likely be used to host the RP and the KDC, eliminating some of the restrictions placed on the test setup used in this project. Increased amounts of CPU:s as well as RAM would aid in the use of threads. The network capabilities would most likely be better as well, and because the network in the test setup was easilyﬂooded after multiple tests, it did not properly reﬂect on how the setup would do with the proper hardware or network.

8.2 Answers to questions in section 2

In section 2, some questions are presented that this project tries to solve, as well as the main challenge of the project. In this section, all of them will be discussed.

• How do devicesﬁnd one another?

Currently, the devices get a list consisting of [Client X: IP], where the X is a number, and the IP is the IP of that client. It is comma separated, and shows the connected clients, even themselves. This is a quick solution, and simply shows that the KDC at that moment gets the information of all the clients connected, and stores them. The clients do not do anything with the information as of now, as that functionality would depend on what the employer of the system would want the KDC to do. More about such issues will be mentioned further down.

• How will the clients exchange keys?

This question has been answered through the experimentation of two diﬀerent key exchange protocols. These two protocols diﬀer in how the exchange is performed, and therefore shows how such an exchange might take place.

• Would a predefined rendezvous point be beneficial in order for devices tofind one another?

In this solution, the clients are all aware of the RP, and can therefore easily locate it. Further- more, this allows the clients to connect to the KDC, if they are authorized, and thereforefind other devices. The RP in itself does not allow for the clients to locate one another, but instead acts as a barrier between the KDC and any malicious users. The KDC is instead the beneficial component when it comes tofinding other devices. This means that the RP is not beneficial for clients tofind one another. However, the KDC is vital for the issue of clients locating each other.

• Are there any particular risks using a rendezvous point? How can these be mitigated?

One issue that has been mentioned throughout the report is whether there is a single point of failure. This depends on how the system would be deﬁned in terms of working. Should the RP

59 go down by any reason, the KDC continues to run, with all the connected clients still able to communicate with the KDC and each other, but no new clients would be able to join the KDC, unless one of the already connected clients handed over the IP and port, which they shall not do because of the security risk. Should the KDC go down, the clients would no longer be able to communicate with clients they have yet to communicate with, nor would any new clients be able to join the KDC. The clients would still be able to communicate with the RP and get the IP and port of the KDC, which they would be able to communicate with once it went online again. Any clients that had already begun communication with other clients would still be able to communicate, even while the KDC is oﬄine.

The RP failure is by design, as it would mean that already connected clients would not be affected in case of a DDoS-attack. This issue could possibly befixed by having a backup KDC, which would go online once the original KDC went offline. However, if it was an electrical issue that caused thefirst KDC to go offline, the second KDC server would most likely be housed at the same location, and would be affected as well. The question is then how far the employer of the system would want to go in order to ensure the KDC never goes down. Having a backup KDC at a different location would be a possible solution to that issue.

In addition, if the network becomes overloaded, the system will fail and be unable to perform any sort of communication. Thus, the question about the single point of failure can be answered both yes and no. The system keeps running, as long as the network is up. However, it would suﬀer issues of performance. It could be argued that if the KDC goes down, the whole system fails, but new clients can still get the IP and port from the RP, so the entire solution is not unreachable. However, it could be argued that it indeed has a single point of failure, should the network go down, as nothing will work in such a case.

Then the question about how the clients and KDC and RPﬁnd one another is presented. In this solution, all the legitimate clients have the IP and port of the RP hard-coded into them, and thus will always try to connect to the RP theﬁrst thing they do. Once they have authenticated themselves, they will get the IP and port for the KDC, and establish connection that way. As mentioned before, the KDC will send out a list to all clients, containing the connected clients and their IP addresses.

The whole project circulates around the fact that an RP was used. It was deemed the best choice, as all methods mentioned in section 3.3.4 and section 3.3.5 are not viable solutions. None of them employ an RP, and therefore it was an interesting point to research. It would also eliminate the single point of failure to have a KDC. Because the solution utlizies an RP and a KDC, it is close to a mediator-based solution. It cannot be called a peer-based solution, as the clients do not contact one another in a try to connect to the network. That is done through the RP and KDC.

While the method of using an RP is seen as a good idea, due to the fact that it ensures that only authorized parties can reach the KDC, it requires the use of two servers that are dedicated to just these functionalities. In addition, because of the protocols used, the risk of a MitM is greater

60 than acceptable. This particular risk will be discussed more in depth below. Compared to other methods, the use of an RP was studied as it did not appear in any related work, and therefore is an interesting point of research. However, due to the amount of setbacks suﬀered during the project, the solution is not adequately tested, and therefore cannot be seen as a perfect solution. Because of that, there are possibly better methods to solving this bootstrapping issue, but that might change once the solution presented in this thesis gets adequately researched.

When it comes to the risks with this system, they are mentioned below in this section, and both the solution using the RP and KDC, as well as the choice of protocols are discussed. That also includes how authentication is performed.

Currently, only devices with a pre-determined password will be sent to the KDC. This should, in theory and a test environment, block any hostile devices. This method is not completely polished, and therefore has some performance issues that could beﬁxed. These will be discussed in detail below.

• Is there a diﬀerence in performance between diﬀerent key exchange protocols in a solution employing a rendezvous point?

In the presented solution, there are some minor differences between the two protocols used. Some time difference can be seen when measuring the protocols’ transmission time and connection time, as can be seen in section 7.1.3. It is minimal, but if the clients are to transmit larger packets, it might prove to be beneficial to use the faster protocol, in this case RSA. However, because RSA lacks the possibility to authenticate any client, it is vulnerable to MitM attacks, and does not have an authentication server. PAKE suffers in terms of efficiency, but can be seen as safer due to the authentication server it employs.

8.3 Choice of protocols

RSA and PAKE were the chosen protocols because of their simplicity, as well the rivalry between RSA and DHEKE. Because the project had a limited time, RSA was chosen because it was easily implemented with Python, as it already has libraries available. Since it was not the focus of the project to build an implementation from scratch, the libraries were used in order to save time and to focus on the more important parts of the project. RSA is also a widely used key exchange protocol, and therefore it would be wise to test it.

In turn, the PAKE that was chosen was based on DHEKE. While it might be argued that DHEKE would have been a more intuitive choice to compare to RSA, it was deemed that it was more interesting to see if the PAKE has any sort of advantages over RSA in this speciﬁc case, especially since it is a supposedly more reﬁned version of the DHEKE protocol.

Atﬁrst, network protocols such as L2TP and IPSec had been an option to incorporate into the project, as the protocols described in section 3.6 all have their advantages and disadvantages, and could beneﬁt from having network protocols evaluated. Because of lack of knowledge of what

61 Advenica is currently using, as well as uncertainty whether the time allotted for the project would be enough, it was dropped. This was rather unfortunate, as it would have presented an opportunity to compare the necessity of a security of a protocol such as IPSec to a faster protocol such as L2TP. It does not have a detrimental eﬀect on the project’sﬁnal implementation, but is rather a missed opportunity to further research this solution, and what combination of protocols that might be advantageous to the solution.

Pure token-based authentication was deemed unnecessary for the system. As authentication only happens once in the RP and once in the KDC, it was seen as unnecessary computational power to produce two tokens to use for authenticating a unit. Instead, a pseudo-random password was used for authentication as it was seen as faster since it is coded into every device, and it has a high entropy and require less encryption when sending the password itself. So the authentication method that was chosen can be seen as somewhat of a hybrid where it has been randomly generated at one point in a token-based fashion, but also has the need to be hashed to not be sent as plaintext and discovered by malicious devices.

The LAC.AKE protocol was seen as a candidate to be implemented, this was due to two reasons. The protocol diﬀered a lot from the others evaluated, it was the only protocol evaluated using lattice-based cryptography, and lattice based cryptography is deemed to be post quantum safe. This would have given such an implementation a very good value for future usage even when quantum computers becomes an ordinary thing. Unfortunately, the implementation of the LAC.AKE protocol could not beﬁnished, mainly because the existing code that was found was written in C, and all the other components written in Python3. Extending Python3 with C code was deemed to be more complex than what was initially realized. This combined with time constraints and that the code base for the protocol was roughly 3,000 rows of code, the protocol was not fully implemented. It still stands as a very good candidate for future implementation due to the fact that it is post quantum safe.

8.4 Design

In this section, the diﬀerent design choices will be discussed. Because of how the solution was solved, the RSA implementation is very close to the general design, and therefore has less to discuss that is speciﬁcally connected to RSA. PAKE has an additional part to it, outside of the general design, and therefore has a more extensive discussion section.

8.4.1 Requirements

There are several requirements on the system, mentioned in section 5.1, and it is important to question whether the current version of the system fulﬁlls all those requirements.

One of the requirements on the system is that the clients are updated whenever a change in the clients in the network takes place. This included whenever a new client enters the KDC,

62 and whenever a client leaves. Currently, the system has no issue with updating all clients on any existing clients in the system, and automatically sends out the information to the clients connect. When the system is used outside of a test environment, it might be better if the KDC does not automatically send out the information, but keeps the list updated nonetheless, so that if a client wishes to communicate with someone, it can request it, and the KDC will respond whether the requested client is still connected or not. This might be a better choice, as sometimes clients are not supposed to know about one another for security reasons, and there are a selected few that will communicate with one another. It would depend on what the user of the system desires. However, in terms of fulfilling the requirement, the implemented KDC does indeed fulfill thefirst requirement.

The second requirement is that the system shall authenticate any client that tries to connect. Since all clientsﬁrst has to contact the RP, that is where the authentication takes place. Using a password saved on all clients that are to be rerouted to the KDC, the RP compares that password to the one it has saved on itself. If they match, it will send the encrypted KDC information to the client. This way, no other clients are able to enter the KDC. Therefore, it does fulﬁll the requirement.

However, in order to make the system even safer, the client has to authenticate itself with the KDC as well. The client only presents its password to the RP, but it should do so to the KDC as well in order to increase the security of the system. The client should have two different pseudo-random passwords that are for the different communication parties. One for the RP, and one for the KDC. This would mean that even if some malicious party manages to obtain the first password, they would still be stopped. Such a breach would be noted, and an administrator could proceed to change both passwords.

Another possible change to the design of the system is to skip direct authentication. This means that when a new client connects to the RP, the RP sends an encrypted version KDC’s information to the client connecting. It is encrypted with the password. This is already done in current design and could be intercepted by a malicious device performing a MitM attack. A change like this would mean that new clients indirectly authenticate themselves since they need to be able to properly decrypt the KDC information in order to connect to it. An important thing to keep in mind when changing the system like this is to not send the KDC information with any wrapper such as “IP:” or “PORT:”, as this could help an attacker crack parts of the used password. Instead, the information should be sent comma-separated. A change like this would skip one of the bigger steps of hashing and verifying a password and probably increase eﬃciency of the solution noticeably but also decrease the security to some degree.

In addition, the RP should communicate with the KDC and send the information of the client that was authenticated, which the KDC then would compare to the client that tries to connect. This way, any party that managed to get the KDC IP and port would not be able to connect, because they would not have been authorized by the RP. It would be an added layer of security, and it could be applied to both the chosen protocols. All the information would be sent

63 encrypted.

The last general requirement was that the KDC should not be open to the general network, but should instead be hidden, and force the client to go through the RP. While the RP does reroute those that are authenticated, the KDC does not do any sort of authentication, and should someone manage to get the IP and port of the KDC, they will be able to access it. The IP of the KDC is not hidden, as some of the tools couldfind the IP of the KDC_desktop. Therefore, it is seen as this requirement was not fulfilled. Some of the changes mentioned in the previous paragraph wouldfix this to some extent, but the IP of the KDC would have to be completely hidden.

There is a separate requirement for the PAKE protocol. This is an authentication server which prevents users from performing online dictionary attacks. Such an authentication server was implemented and when tested, worked as expected. Because of how the system is set up today, with machine coded pseudo-random passwords, only one wrong attempt was deemed necessary before applying a global lock, since a legitimate client connecting to the system would never attempt to input the wrong password.

8.4.2 General design

The design of using an RP and KDC seems to be wise. While the KDC in this project does not have much in terms of functionality, it was proven that it can get information from diﬀerent clients, andﬁnds both new clients and those that had become disconnected. This way, it often updates its client list, and update the remaining clients about such changes. In addition, the KDC remained online even when the rendezvous point was attacked with a DDoS-attack.

However, if the network was attacked, the KDC would no longer be able to communicate with the clients, and would boot every client, believing them to be disconnected. This is certainly negative, as communication ceases. In order for this to not happen, some security regarding the network itself has to be implemented.

The KDC wipes everything in its memory at crash in this version, which can be seen as beneficial, should some malicious device have found its way into the KDC by bypassing all security. However, in most cases, it is only detrimental, as it requires every client that was connected to reconnect, possiblyflooding either the RP or the network. Therefore, it would benefit the solution if the KDC would rather retain some information of the clients that had been connected before it went offline. While the PAKE solution implements a strong one-way hash in order to ensure security, the RSA solution does not have such a strong one-way hash, but instead a weak SHA-1 hash is applied to all the encrypted objects. This was motivated as not being as necessary for the RSA, and it was deemed an interesting point to test if it caused any weakness in the protocol. The reasoning behind why RSA does not need such a strong hash for its RP password was that it is only used to authenticate the client for a key exchange, where it negotiates keys with the RP in order to receive and decrypt the KDC information. Meanwhile, the PAKE so-

64 lution instead uses its password to perform password based encryption and decryption on the KDC information. Therefore, the PAKE solutions password must retain a higher secrecy and not be leaked at any time compared to the RSA password.

While the password used in the project is a pseudo-random one, consisting of lowercase letters and digits. This would be difficult to crack, but not completely impossible, and in order to ensure that it would be as safe as possible, the password should include uppercase letters as well as special characters. Because this project is only a test environment, the lower entropy password was seen as an acceptableflaw, but one that should be rectified if such a system is employed in a live situation.

8.4.3 PAKE

The PAKE design uses a password stored in the authentication server. If the password instead was something the user knew themselves in memory, the cooldown would work diﬀerently. In- stead of only one try, the user would getﬁve tries before a lock with a timer of 15 minutes would become active. That timer would increase if the user kept inputting the wrong password, going from 15 to 30 to 60 minutes, before the authentication server locks the user out, and also asks to contact administration. This method enables two-way authentication, since it requires not only the device itself, but also a password the user knows. However, this presents a risk due to the human error, and the lack of pseudo-random passwords.

A binary model of trust is implemented in the PAKE solution for the system. This is integrated with the authentication server, where it keeps track of the address of clients that has had failed attempts on the input of the password. This includes binary trust since a bad client will not be allowed to attempt to connect again while a good, new client will have a chance to do so before being considered bad. The RSA protocol has no implemented trust, so a client would always be considered as good, no matter its previous actions. From a security perspective, this is seen as a risk, as users will have unlimited amount of attempts to brute force the password that is used for authentication. If a regular password was used and not a pseudo-random machine saved password, it would pose a greater risk than it currently does.

One of the major advantage of the implemented PAKE protocol is that even if a lower entropy password was used, the protocol itself gives security against oﬄine dictionary attacks by default, by allowing users to only get information about the password one data package at a time. By implementing an authentication server, it also protects against online dictionary attacks by limiting the number of attempts a brute force attacker is allowed. In this case, high entropy passwords are used as they were going to be on the devices in any case, and provided higher security.

As of right now, authentication in the PAKE solution is implemented in the RP to keep the KDC secure. As the KDC also has a form of authentication as it uses a certain password to exchange keys, it would be possible to remove theﬁrst authentication in the RP and only keep

65 authentication in the KDC, but this would also include moving the current authentication server from the RP to the KDC, to detect a lot of connection attempts and block the KDC from more attempts after this. If appropriate changes are not done to the authentication server, a design like this would be highly vulnerable to DoS and DDoS-attacks.

A change like this would mean a change in the behaviour of the system. Firstly, the KDC would not be hidden, and would therefore require some additional protection against DoS and DDoS-attacks. Secondly, if the authentication server locks the system to new users, this would be done in the KDC and not the RP, meaning that some alterations would have to be done to the authentication server so that it does not lock the entire KDC to both new clients and already connected clients. A change like this would be beneﬁcial since hashing and sending passwords twice during client setup is less eﬃcient than only doing this once. Since it can be assumed that the client also has the password for the PAKE protocol key exchange, this password could be used for password based encryption of the KDC information, still keeping this vital information somewhat safe.

8.4.4 RSA

The RSA, while a secure protocol, suffers from the lack of trust. Since it completely trusts the party it sends the exchanged keys with, the risk of MitM attacks increase. In order to ensure that the RSA system would be safe, a third party authenticator orfingerprinting would be beneficial. This would allow the RP and KDC to verify that it indeed is the correct client they are communicating with. This was not done in the project, because it is not the main issue of the project. This would mean that the design isflawed, as it would be more open to attacks.

Regarding the hashing in the RSA implementation mentioned in 8.4.2, it is deemed to be bad practice to not strongly hash the password. Should the RSA system be used outside of a test environment, a strong hash should be applied to the password, and have the hashed password veriﬁed. While the hash cannot be used on everything sent, the password should at least be properly and strongly hashed. If it is not, there is a risk that a MitM could get ahold of the password, and use it to reach the KDC. However, RSA is less dependant on keeping the password safe compared to PAKE, as PAKE uses the password for encryption, while RSA uses its keys.

In addition, in this particular implementation, the password is not hashed in itself. Instead, the hash is added onto the encrypted message, so that the device that receives the message can verify that the message has not been tampered with. This might be good practice, but it is not the same as hashing the password, and does not beneﬁt the users in the same way. It lacks the same amount of security.

66 8.4.5 Robustness

Robustness of the system was tested by running connectivity tests overnight on both the PAKE and RSA solution under normal runtime circumstances, with no attacks applying any abnormal load of internet traﬃc or data handling. Both the PAKE and RSA solutions encountered no issues while performing these tests. Both solutions were left overnight with the two desktops running both protocol’s RP and KDC. The two raspberry pies were running the client software. The result of this was that both clients were still connected to the KDC after running for 18 hours, both RPs were still up and had not crashed. The KDCs were still actively running.

This means that both implemented solutions fulﬁlls the requirements about system robustness. They have been proven to not kick active clients during normal runtime environment, and have showed no tendencies of either the KDC or RP crashing during longer uptime.

8.4.6 Eﬃciency

When it comes to the results of the efficiency testing, some major differences can be seen between the PAKE and RSA solution. The biggest difference is when new clients connected to the KDC, for RSA, the time it took for a client to enter the network and negotiate a key was 0.56 seconds. The same measurement for PAKE yielded three seconds.

There are some underlying reasons for this diﬀerence in time. First of all, the RSA solution starts by exchanging public keys between the client and RP, and then uses this for encrypting password and KDC information. The PAKE solution instead uses a heavy one-way hash to hash the password before the client sends it to the RP and let the RP verify it. Both of these are heavy from a computational perspective. The PAKE solution also uses password based encryption for encrypting the KDC information. The time it takes to perform that encryption should take the same amount of time as RSA takes to perform its encryption.

When measuring transmission times without afive second wait time in between the transmissions, the average time for the RSA solution was 0.62 seconds and 1.24 seconds for PAKE. These differences stem from the fact that when using the encryption method, the PAKE solutions keys has to be altered tofit python’s standard keys for encryption, while the RSA keys can immediately be used. These time differences could be smaller if another encryption standard was looked up for the PAKE solution, or an encryption function created which could immediately use the PAKE key.

When measuring transmission times with afive second wait in between transmissions, the RSA solution had an average of 0.64 seconds while the PAKE solution had an average of 1 second. While PAKE is still slower, PAKE itself had an improvement in its efficiency when adding a wait time. When comparing how RSA and PAKE encrypts, RSA has an encryption that takes less computational power than PAKE has. This makes it so that the PAKE solution has time tofinish calculations after the alive thread hasfinished but before it starts using computational

67 power again.

8.4.7 Scalability

During thefirst test of scalability for PAKE, the client information transmissions was received out of order; the client information transmission containing four clients was received after the one receivingfive clients. This happened because the client information function was initially started in its own thread at every instance of it, and this was done whenever a client joined the network. This meant thatfive threads were started almost at the same time and all of them had the mission to transmit the client information that they were aware of. This made it possible for a later initialized thread to pass an earlier thread in order and transmit its information before this. Even if this was only noted in PAKE, this could also happen in RSA theoretically. So appropriate changes were made in the code which will be mentioned in 8.5.

The results during theﬁrst scalability tests for RSA gave an error "plaintext too long”. After some research it was found that this error was caused when the plaintextﬁle that was attempted to be encrypted was longer than the RSA private key. To solve this, key length was increased as mentioned in section 8.4.7.

The results during the second scalability tests returned with no abnormal output, all clients could connect and all received transmissions came in the correct order.

With the PAKE solution, scalability can be said to be fulfilled. It lets all thefive clients connect, and then it transmits the correct client information to the clients. This makes all the clients aware of the topology of the network. In addition, it does not render any client unable to connect to the KDC, even when multiple clients simultaneously try to connect. For RSA, scalability is fulfilled only if one changes the key size as the expected number of clients are increased. It was found that for every 1024 bits of key size, four clients could be connected, but notfive. To further make RSA scalable in a more dynamic fashion, a future change to the solution could be to use the keys exchanged by the RSA protocol to exchange other keys that are generated in some other way. Transmitting these keys securely between the client and the KDC using RSA.

8.4.8 Authentication server

The authentication server responded as expected to a client giving it a bad password. Meanwhile, locking the entire system as soon as it currently does might not be the best way. The limits can be easily altered to suit the needs of the users. When locking the system proves eﬀective against malicious devices trying to guess the password, it could also lock the system if a small DoS-attack gets launched against it but the RP does not crash from the attack. However, DoS- attacks were tested and they do not give a hashed password by default. This is not the case in

68 the current system. So the limit of one failed password attempt might still be suitable as it will still stop a real brute force attack but not lock the RP if a DoS gets launched against it.

8.5 Method

A pseudo-random password generator was created, by simply using os.urandom(32), but it was momentarily removed due to other functionality being prioritized. For the moment, the generator was decided against, and instead the focus would be on hard-coded passwords, saved directly onto the client and rendezvous point. At that time, it was simply a possible further development to include a pseudo-random password generator that would generate a password that the rendezvous point would recognize.

8.5.1 Common method for PAKE and RSA

The reason why a simplefirst implementation was made was to make sure that the basics worked correctly. If this was not done, thefinal system could have issues concerning effectivity and robustness all based on the underlying socket code. As a logical next step, authentication was added to the system. This was done as the entire solution is based around being able to authenticate clients. While authentication was being implemented, encryption was also added to keep vital information safe.

Standard messages were added to the solutions. This was done in order to be able to keep track of any system progress, if clients were losing connection and if clients properly received information that the server sent them. The standard messages and responses were designed so that they would be easy to understand and remember and not be similar to each other, to keep the solution as easy to follow as possible.

Implementing threads was seen as a big part of the system. This was done in the RP to get a betterﬂow of handling new clients. Should a lot of clients connect at the same time and the RP only has a single thread running, the amount of traﬃc on the single thread would cause a build up of a great queue. However, if the threads are handled in parallel, and if the machine that the RP runs on has enough threads, it will process everything faster. Another reason behind this is also DoS and DDoS-attacks. If no parallelism was implemented and such an attack was launched, the queue would very quickly be full and the RP would almost never get to the authorized clients which tried to connect. When parallelism was implemented, even if a delay was noticed, clients could join while the RP was being attacked but had not crashed.

Implementing threads in the KDC was done in order to be able to send out standard messages while still being open for input from clients and receiving new clients which were redirected by the RP. When implementing the threads, some issues from the KDC was noticed. To start with, standard messages and responses had data races. Receiving these messages in parallel while still getting them in the concurrently correct order was not possible, as one thread was sending

69 standard alive messages and one was receiving them. To bypass this, theﬂags were implemented as mentioned in section 6.2. Theﬂags were implemented so that a standard message thread could lock the client for getting other standard messages sent to it until the KDC has received a standard response matching the message.

At the start, a client could be removed twice. This occurred when one thread is running where a client can be seen as a dead client if it lost internet or power, and another thread where clients can request to quit the network. This was solved by always checking that the client that was about to be removed was still in the network, as threads could loop through the list of clients and be at the same client simultaneously. This could also be an issue when accessing client ﬂags or similar client speciﬁc resources during loops. This was solved by adding checks before accessing such resource while in a thread looping through the list of clients, to make sure a client has not requested a quit or has been found dead from another thread.

In the end, the password generator was decided against, and instead the focus would be on hard-coded passwords, saved directly onto the client and rendezvous point. At that time, it was simply a possible further development to include a pseudo-random password generator that would generate a password that the rendezvous point would recognize. It is clearly not safe to have the same password on each and every device, even if they’re pseudo-random. However, since this project was only a test environment, the static password was deemed an acceptable ﬂaw.

Because the system sent out so many alive-messages, it seemed that the KDC was actually DoS-ing the network itself. Therefore, a sleep ofﬁve seconds had to be added. This was an oversight, and one that had to be rectiﬁed. The alive-messages sent out in this practice setup would not be used in a proper, live situation. They would be redundant, and were only used in order to test that the clients were indeed alive. This was because the clients lacked the ability to communicate with one another.

Theﬁnal KDC does not have full KDC functionalities mentioned in section 3.11, but instead the focus of the method is to be able to authenticate new clients, exchange keys, check if clients are alive and send client information to connected clients whenever the client list updates. This was done intentionally as a KDC is a complex component and no secure free code could be found online and the goal was to test how to properly connect new clients to the type of networks containing a KDC.

It was realized at the end of the project that current authentication methods are unnecessary. An attacker could simply resend the same message containing the hashed password, rendering this method useless. Instead, authentication happens by default when the user decrypts the encrypted server information message. Solutions to making the password authentication work as intended are proposed in section 9.

70 8.5.2 PAKE

An existing codebase was used for the PAKE solution, which implements J-PAKE in python2. The codebase was used because it was not within the scope of the project to create a new codebase for the solution. There already exist good codebases for this purpose, and therefore the codebase was used. The only issue was that the codebase had to be altered to python3 since the rest of the system was implemented in python3.

When PAKE clients authenticate themselves, they send the password hashed with a sha256 hash salted with 200,000 rounds and with a salt size of 16. Such a computationally heavy hashing algorithm was seen as necessary since the password is also used for encrypting the KDC information that is sent to the client. An alternative to this could be to exchange keys with the RP, but as PAKE key exchange is also computationally heavy to perform, this was seen as better to avoid and instead use simple password encryption when the RP should only encrypt one message to each client connecting.

The PAKE solution has an additional standard message compare to the RSA solution. This standard messages is an “ERR” which is always followed by a informative message. It is used for the RP to inform clients attempting to connect that the RP is locked by the authentication server so that users trying to connect new clients would get informed of unusual circumstances.

8.5.3 RSA

The RSA implementation has a pickle hash, which does not behave the same way as the hash in the PAKE implementation. While it does employ a SHA-1 hashing, it is only used to ensure that the object received is the same as the object originally sent. It does so by having a hash- length, which if the same length would not raise an error message. However, the reason why it is possible to extract the information from the hashed Pickle is because the hash is not on the password itself. The hash is only applied to the encrypted message as a checksum, and does therefore not aﬀect the ciphertext itself. This is why the method could send ciphertexts with a hash, and still decrypt it to plaintext. This means that the encrypted messages are not as safe, as they lack a hash.

8.6 Attacks

The attacks tested were chosen because of their relative ease to emulate, as well as their fre- quency. The MitM attacks and brute force attacks will be discussed in more detail here, as they were not performed properly on the system. The results from the DoS and DDoS-attacks will also be discussed.

71 8.6.1 MitM

For an attempted MitM attack in this project, Ettercap was used on a laptop. The laptop with Ettercap entered the network, and began sniﬃng, and found the two Raspberry Pis as clients, as well as the KDC_desktop. This attack was performed twice, with using the KDC and the RP as the targets for the separate runs.

Ettercap was set up with ARP-spoofing, and then a client tried to connect. This was repeated with a client already connected, in order to see what would happen with the already connected clients. Unfortunately, there were some issues with Ettercap, such as freezing, and being unable to send data. It was unsolvable, and therefore could only provide a incomplete result for both key exchange protocols. A different tool was used in order to verify the semi-results that Ettercap was showing. The tool was called bettercap, and ARP-spoofing were performed.

When using Ettercap, the attack was done, and managed to intercept the messages with an ARP-spooﬁng attack. It is believed that it therefore got the encrypted and hashed key from the client, and was trying to send it to the rendezvous point.

However, it was unable to send the messages, and crashed multiple times. The same attack was repeated with bettercap, and it was seen that when using only ARP-spooﬁng, the connection between the client and the attacked rendezvous point suﬀered delays or was completely blocked.

Theoretically, PAKE should prevent MitM attacks, which attempts to get ahold of vital information. As mentioned in section 3.6.3, the PAKE protocol uses a password as a common secret to obfuscate the inputs. Specifically, the J-PAKE implementation used performs three steps, where thefinal step is based on the password chosen. Should an attacker get ahold of this data, even during the key exchange session, it cannot get any meaningful information from the small set of data it would be able to collect. However, blocking MitM attacks will still harm the system, as this will make it so that new clients cannot connect to the system. Already connected clients will not be affected, unless they are the target of the blocking attack. But when the blocking MitM attack only targets the RP, this will only stop new clients.

For RSA, it should not stop a MitM. As mentioned before, RSA uses public and secret keys in order to ensure the messages cannot be read by any outside recipient. However, should an attacker be present when a client and a KDC tries to establish a connection, the attacker can perform an ARP spooﬁng, making the client and KDC exchange their keys with the attacker. Thus, the MitM has access to all the messages, and can decrypt them as they seeﬁt.

Should an attacker enter the network after the client and the RP or the KDC have established connection with the RSA protocol, it should be impossible for the attacker to be able to decrypt the ciphertexts sent. However, the attacker can still alter the ciphertext itself, without knowing what it contains. This would mean the intended destination would get a message with a diﬀerent meaning than originally sent. In addition, the MitM can also hide the messages, which could make the KDC think there is a dead client, and boot it from the network. This way, should

72 the client try to connect again, the MitM could be there at the start, and therefore perform a proper MitM attack where they impersonates the KDC.

8.6.2 DoS and DDoS

In theﬁgures in section 7.2, it can be seen that when the overnight run was done, the rendezvous point went down at 06.00. It was unclear whether it was because of a crash, an overloaded network, or because the hotspot used to create the network went down. Because both the solutions stayed alive when simply run during the night, it is believed that the crash was because the network got overloaded, instead of the hardware during the attacks.

Because of the many threads running in the applications, a DoS and DDoS-attack might be effective. The threads must all handle the incoming traffic, and correctly deal with any wrong input or clients trying to connect. Should the system beflooded, there is a risk that the threads will not be able to keep up, causing it to crash.

8.6.3 Brute force

Before any actual brute force attacks were started, a rough calculation of the worst case scenario time for the chosen passwords was calculated. As the passwords used for both PAKE and RSA were pseudo-randomly generated 32-character passwords with lowercase letters and digits, each character has a total of 26 (Lowercase) + 10 (digits) = 36 different alphanumeric characters. With a 32-character password, this gives a total of 3236 = 1, 53 10 54 maximum guesses before ∗ finding the correct password, deeming it a worst case scenario attempts. Best case scenario is that the attackfinds the password in one attempt. This is highly unbelievable in this case. The best and worst case scenario in combination gives an average of1, 53 10 54/2 = 7, 66 10 53 ∗ ∗ guesses beforefinding the correct password.

If the brute force algorithm is optimized, and the attacker has access to IBM’s Supercomputer Summit, mentioned in 3.9.5, it takes one instruction to test a password. This would result in an average brute force time of7, 66 10 53/(7, 36 10 15) = 1, 04 10 38 seconds, equalling7, 93 10 31 ∗ ∗ ∗ ∗ years. With this information in mind, a brute force attack on the system itself was seen as useless since it would neverﬁnish theoretically.

However, the vulnerability to brute-force attacks are instead in the machine that the parts of the systems are hosted in, the client, the KDC and the RP, all contain at least one of the passwords needed to enter the system. If any machine with access to the machine code gets compromised, the passwords will be known to an attacker.

In order to test if these calculations were correct, several diﬀerent tools for brute force attacks were evaluated, such as John The Ripper and THC Hydra. Unfortunately, none of them managed to run on Attacker_1 or Attacker_2, and they were instead dropped. Therefore, no actual brute force attack was performed.

73 Proper brute force attacks were never actually tested against the systems. But the importance of including information about a theoretical brute force attack was still recognized. As the setup is in current solutions, no brute force attack would be able to give a malicious user the opportunity to enter the system as an approved client to get access to vital information. If a password of lower entropy would have been chosen, a brute force attack would have been justiﬁed to perform. As of current passwords chosen for the solution, no brute force attack was launched as such an attack would at most have the same eﬀect as a DoS or DDoS-attack. If passwords of lower entropy is used at any time, a proper brute force attack against the system should be performed in order to further ensure security.

8.6.4 VPN hijacking

As the solutions are developed to bootstrap VPN systems, VPN hijacking could be a potential threat against any user implementing the solutions together with a VPN system. As of right now, the solutions only deliver necessary information between KDC, RP and client(s). So VPN hijacking was seen as an attack that had no eﬀect on current solutions.

VPN Hijacking can also already be attempted against VPN systems, which should mean that any VPN system already up and running should have proper protection against such attacks, which security is not aﬀected by how the solutions relay information but rather how well the system that will use that information protects itself from such attacks.

While Heartbleed only aﬀected OpenSSL, and got access that way, a MitM attack on RSA could potentially be seen as a VPN hijacking.

8.7 Tools

Both Ettercap and bettercap were used to perform the MitM attacks. Unfortunately, both programs seemed so suﬀer from performance issues, with both being able to show any information of the data they intercepted, nor being able to send the information to the victims. This gave an incomplete result, and merely showed that a MitM could at the very least block any packets from getting sent. This could lead to one or more clients getting kicked from the KDC, as they would fail to answer the alive-messages.

Originally, only Ettercap had been used to perform a MitM attack. The second tool bettercap was used only later, in order to make sure there was not an issue with Ettercap alone. In addition, bettercap would become an issue in of itself, as it infected Attacker_1 with malware (coinminer). It got infected once the web UI had to be used, and the anti-virus running on that laptop had to be turned oﬀ in order for bettercap to even want to start the UI.

There are certainly better tools out on the Internet, and it seems that most of them would work best with Kali Linux instead of any other operating system.

74 XerXeS on the other hand workedflawlessly, even though it did not employ a zombie network or networks. It could be argued that in order to be certain of the robustness of the system, zombie networks should be used. Other programs that are popular to do DDoS with is LOIC (Low Orbit Ion Cannon) and HOIC (High Orbit Ion Cannon). Unfortunately, it was incredibly difficult to find any version of the programs that did not seem to be malicious to the host computer, and therefore they were not used.

When XerXeS was used, it was revealed that the program did not seem to be parallelized, as running XerXeS on diﬀerent terminals on the same laptop seemed to add to the packages sent. This is why it was possible to increase the attacking power by simply adding a few terminals to the laptops. Because the laptops used were dual-core, only two terminals per laptop was used at the most, in order to use their full potential. However, the laptops were not completely focused on carrying out the attacks, as both were running graphical interfaces in the background, and one was running an antivirus program as well.

8.8 Related work

In section 4, multiple related work were presented, and in this section they will be discussed. The discussion will revolve around how similar they are to the solution presented in this paper. In addition, it will question whether the solution in this project could be integrated with the related work. Diﬀerences and similarities will be discussed to an extent as well.

8.8.1 GET VPN

GET VPN was seen as related work during the initial phase of the project. It extends regular IPSec protocols to provide scalability and eﬃcient encrypted communications. It is Cisco’s own solution to implement a KDC system, which is not what was handled directly in the end of the project. Instead, delivering automatic setup to these types of system is what was implemented.

GET VPN is related to the current solution in a way that it can be integrated with the solution to get a full function KDC system with proper bootstrapping implemented by just altering the solution’s information distribution and storage standard toﬁt those of GET VPN. GET VPN employs an access control list (ACL), which the current solution does not support. It is used in order to keep track of which traﬃc between what clients has to be encrypted. Adding functionality to support such a list would be necessary to integrate it with GET VPN.

GET VPN gives users easy to manage, high scale encrypted communications with any to any connectivity while the project solution has most of its focus on setting up requirements for high scale encrypted communications without providing the any to any connectivity as there is aﬁx point of entry to the system. Managing the system during runtime is not anything that has been given much focus either in the project solution, but GET VPN deems to be essential. This

75 is due to the fact that GET VPN has full KDC functionality while the project solution does not.

8.8.2 IKEv2

This might not seem to be relevant because it deals with IPSec, but because IPSec was originally going to be included in order improve safety, it is still seen as a relevant related work.

The paper which focuses on security of communication, not unlike what this project has focused on. However, it solves it in a diﬀerent way, as instead of focusing on the key exchange protocol, it utilizes the network protocol to ensure safety through security associations and authentication. Through all of these actions, the data would be protected. While it perhaps would be a good solution to integrate together with the presented solution in this thesis, it should be partly unnecessary because of the protection of the data. When the presented system in the paper is properly built, the data will be protected because of the tunneling.. It could be seen as an extra layer of added protection if the IKEv2 was used together with the solution, but it would make the system’s performance suﬀer, as more calculations would have to be done.

In contrast, the authentication part of the IKEv2 would be beneficial, as it would remove the need for a password and would properly authenticate the client to the RP and KDC. Perhaps this would imply that it would be more difficult to do an MitM attack, as the parts would be authenticated. This would especially benefit the RSA solution, where it blindly trusts every device to be the one they claim to be.

If IPSec was used, it could be possible to use IKEv2 as a mean to negotate the keys that should be used for the tunnel.

8.8.3 Kerberos

Kerberos has become a commonly used system when it comes to KDCs and authentication. The largest diﬀerence between how Kerberos functions compared to the implemented KDC is that Kerberos requires a list of the clients that will use the KDC. This would still require Advenica to update the KDC whenever a new client would be added, either remotely or on site. It would present its own set of issues, depending on where the server hosting the Kerberos KDC is, and if it is possible to reach it remotely. The list would contain the private keys of the clients as well, such as passwords, which could prove to be a fatalﬂaw, should some malicious host manage to get inside the Kerberos KDC. Because of this, it is seen as dangerous to use Kerberos, because of the possible risk of having the private keys of several clients stolen.

Kerberos wouldfill the role of a third party authenticator that the RSA solution would benefit from. It is unclear whether Kerberos would be possible to integrate with the presented solution, and, if possible, how that would affect the result.

76 Because of the mentioned reasons, Kerberos diﬀers quite remarkably from the solution implemented in this project, and both of them do have their own advantages. It is unclear, for example, how a Kerberos KDC would handle attacks such as a DDoS, with only Kerberos V5 having a backup of the KDC. It is a widely used system that has proven to be eﬀective, something that the solution in this project has yet to do.

It is important to remember that the KDC implemented in this project lacked most of the functionalities a KDC would have, as it was not the focus of the project. Therefore, it is diﬃcult to compare the ticket-granting service, as the functionality Advenica has in their KDC is unknown.

8.8.4 Decentralized bootstrapping in Pervasive Application

This related work tries to solve the same bootstrapping issue as the one this project has tried to solve, albeit in a different way. While the solution presented in this project is closer to a mediator-based approach, the solution presented in the paper Decentralized Bootstrapping in Pervasive Application focuses on having a decentralized solution. This means there is no rendezvous point or KDC, and instead the network should befluid, with the topology changing yet every client being able to join andfind other peers.

While such a solution could have been viable for this project, it was not seen as important to keep the solution decentralized. Instead, it was decided that a centralized solution was the better option. The related work would be more usable for systems which have many devices connected at all times, and that has to jump in and out of the network often, such as a sensor network.

8.8.5 Bootstrapping in ad hoc networks

In section 4.5, some research into the bootstrapping issue in regards to ad hoc networks are presented. All of those papers deal with the issue of bootstrapping, and how to make it secure. Since they deal with ad hoc network, all their solutions are decentralized, unlike the solution presented in the report of this project.

In the paper written by GauthierDickey and Grothoff, the generated stream is a more secure version of the random probing method in decentralized networks. While this solution would entail that the system would have an increased hit-ratio, it would still present a lot of misses. In addition, it would not present any security against malicious hosts. The solution with the KDC and RP is not decentralized, but it solves the issue offinding other nodes and increases the security. If decentralization is not a requirement, the solution presented in the related work can be seen as the preferable option, since it would increase the rate of failure in regards to connecting with clients. Because the solution presented by GauthierDickey and Grothoff is a

77 version of the random probing method, it has a much higher rate of failure than the usage of a KDC with a transmitted list of connected clients.

On the other hand, the paper written by Hoeper and Gong focuses on ensuring the security of decentralized networks. It deals less with the issue of bootstrapping, and presents a solution that increases the security through the use of key renewal and revocation. The method of checking whether a key has been revoked or renewed can be a beneﬁcial further implementation in the KDC and the RP solution, but not a necessary one. The KDC and the RP should not have to revoke or renew a key, and the solution employing the KDC and RP deals with the bootstrapping issue, which the related work does not.

The paper written by Tseng et al. mentions the possibility of including IPv6 in ad hoc networks in order to increase the security. The usage of IPv6 is already integrated into the solution that employs the KDC and the RP. Therefore, the paper by Tseng et al. is not integratable with the project presented in our report, but is a viable option for solving the bootstrapping issue in ad hoc networks.

9 Future work

While the idea of having an RP was an idea appreciated by Advenica. However, we entertained the possibility of removing such an RP, and instead replace it with some other method used to ﬁnd unknown machines over the Internet. There were ideas of eliminating the RP, and instead have a diﬀerent architecture, but due to the time constraints of this project, those were deemed as future work. It would be far superior if this was possible, as the solution would be the most useful if it was possible to use it on the Internet.

In addition, in order to ensure the robustness of the system remains strong, the KDC should be able to retain knowledge of the clients it had connected to before it went offline due to any unforeseen circumstances. This could be done by either caching the list of connected clients, and have it regularly saved to memory. It would be loaded from memory once the KDC has gone online again. This would affect performance, as it would need to regularly write to memory, which is slow. Once it had loaded the list of clients, it would have to make sure that none of the clients had gone offline in the time the KDC had been unavailable, and it would have to send out alive-messages to every client, updating the list as it got responses.

Because of the issues previously mentioned with LAC.AKE, it remained an incomplete implementation. Since LAC.AKE is deemed to be post quantum safe, it would be beneﬁcial to complete the implementation and test how well it would resist attacks and integrates with such a system overall.

Proper executions of MitM attacks and brute force attacks would be beneﬁcial, as it would properly test the security of the system. Without those attacks, the security of the system is not veriﬁed, and is only theoretical. In order to ensure that the MitM would not succeed to breach

78 the RSA system, a third party authenticator would be beneﬁcial, as it would verify the parties communicating.

As of now, a single password is being used for all clients who authenticate themselves. If one of the clients was to be breached, all clients would have to have their passwords changed. This goes back to the initial problem with having to update all clients. This could be prevented by assigning each new client that is to connect to the network its own password. This password would only have to be added to the new client and the RP. This eliminates both the issues of a single password being compromised and the problem about updating every device with new information.

Currently, passwords are being hashed before being sent to the RP for authentication. When the RP receives aﬁrst message from a client, it attempts to verify this by hashing the expected password and checks if it is equal to the given hashed message. Hashed messages are of static length depending on the hashing method. A simple hash length check could be implemented to drop all messages of invalid length. However, this does not change the circumstances for sophisticated DDoS-attacks where an attacker would send hashed messages of the correct length.

As of right now, the KDC is vulnerable to DoS and DDoS-attacks if it was to be found. A future work to be done to further increase resistance against DoS and DDoS-attacks would be to make the RP tell the KDC which clients has authenticated itself to it. This would protect further against DoS and DDoS-attacks since the KDC could drop any incoming connections from unauthenticated clients.

Instead of sending a password in the beginning, the system employing PAKE could simply authenticate itself through the act of being able to decrypt messages. This is because the RP and the client would have the same password, and that in itself would mean that both devices would be authorized. This would remove the risk that comes with sending a password, even a hashed one. It is a simple solution that would be easy to implement. A similar approach could be used for RSA, where the password would be the secret key. This would mean that the authorized parties would be able to decipher messages without sending the actual password.

10 Conclusion

In conclusion, using an RP together with a KDC proved to be an eﬀective solution, albeit only theoretical beyond a test environment, and the discussion that arose around it has successfully answered the questions raised in the beginning of the thesis.

The solution, consisting of an RP, a KDC, and clients, could all communicate in the designed way, and the RP managed to ensure that the KDC would not be attacked by any DDoS. In addition, the KDC was able to send out the information to the connected clients containing the IP of all the clients connected to the KDC.

It is not a solution that could be deployed today, as it is highly theoretical in regards to the

79 security, and there are multiple aspects that could be improved or properly tested. Therefore, the solution is not seen as complete, but a good foundation to continue building on until it can be properly used.

11 My contribution

Below, the contribution of each author will be described in order to explain what each author accomplished during the timeframe of the project presented.

11.1 Joakim Ingnäs

Initially, it was realized that there would be a lot of background research for the project. In order to effectively get it all done, it was divided between the authors. Joakim was focused mostly on the PAKE and LAC.AKE protocol, with research initially divided as equally as possible to divide knowledge and responsibility between the authors. In order to keep theflow of the project going, in the end of the research phase, Nicole had more focus on the Background, as Joakim started writing the base of the code for the commonly implemented parts. This was agreed upon and seen as necessary to be able tofinish within the time initially set.

When designing, this was done together, using a whiteboard and brainstorming, sorting out the best possible designs that the two authors could come up with together. This was done as knowledge was divided and all knowledge was necessary for making the best design. The design phase was completely divided equally between the two authors.

During the initial phase of implementation, Joakim implemented the basis of the solution, during the implementation phase, implementations that was mirrored in both solutions was done by Joakim as he had a better check on the built solution not counting in the protocols. The PAKE protocol was purely implemented by Joakim, as well as the attempted LAC.AKE protocol. This was due to the fact that it had been his heavier area of knowledge during the background phase.

During the attack and test phase, starting with attacks, which were organized and mostly performed by Nicole, while Joakim was monitoring, catching bad outputs andﬁnding bugs to quickly patch up to be able to test the system properly. General testing was orchestrated by Joakim,planning scalability and eﬃciency testing and performing these. Robustness testing was done over night by both authors. Results were noted by whoever performed actual tests or attacks.

The method parts were written by whoever had performed that speciﬁc thing. As mentioned when going through implementation, attacks and testing.

The discussion were written together, simultaneously, no speciﬁc parts were divided here. Who- ever came up with a good idea discussed it orally with the other party and when it was agreed

80 on by both authors it was added to the discussion. This made it so the discussion was evenly divided between the two authors.

When talking about how the division of work had been, both authors agreed that it had been quite natural and in some parts even occurred automatically. This is probably because both authors has done both smaller and bigger projects together and are aware of how they best work together.

11.2 Nicole Tutsch

Because of the large amount of research that had to be performed at the start of the project, the background section was divided between the two authors, where Nicole focused more on the RSA section, as well as the general background. In addition, the attacks were mostly written by Nicole. The research was divided equally at the start, in order to give both the authors equal amount of responsibility of the project. However, in order to ensure that the project would be ﬁnished within the time allotted, the background was mostly written by Nicole, as Joakim wrote the code base for the project. This was a unanimous decision in order to complete the project successfully. Therefore, whenever more information had to be added to the background section, it was most often Nicole that added it.

The design was created together, with only the chosen protocols as a object of separate focus. However, it was for the most part done on a whiteboard, with diﬀerent choices as alternatives. This was because of the research done in the beginning, and because both the authors comple- mented one another very well in terms of knowledge. Because of this, informed decisions about the design could be made. The authors even talked with one another about the chosen protocols at the start, in order to ensure that they were not missing anything of importance.

However, once the implementation started, Nicole was still writing on the background section, while Joakim had started on the code base. She only helped with some implementation errors. When the protocols wereﬁnally going to be implemented, Nicole worked on the RSA implementation, in all the separate parts that would need the cryptography system.

Once the systems were implemented, attacks were performed. Because Nicole had written the most of the background, she was the one who performed the majority of the attacks. She downloaded the tools, and often searched for any other tool that might assist in the testing. However, Joakim was monitoring it all in order to detect any abnormalities in the code.

The method section of the thesis was written by whomever was performing that action. It lead that most of the general section of the method [label plz] was written together, while the separate sections were mostly written by their more knowledgeable author. This meant that Nicole mostly wrote about the RSA part of the method, but both authors helped one another with the method section.

The discussion was far less divided, and both authors wrote equally on all the subsections.

81 This meant that the workload was equal, and both authors constantly communicated with one another in order to ensure that the discussion would be as in depth as possible.

The division of the work was a natural occurrence, as the authors have worked together on many projects.

References

[1] K. Tillman, “How many internet connections are in the world? right. now.” last updated 29/7 - 2013, accessed 14/5 - 2019. [Online]. Available: https: //blogs.cisco.com/news/cisco-connections-counter

[2] C. GaunthierDickey and C. Grothoﬀ, “Bootstrapping of peer-to-peer networks,” Interna- tional Symposium on Applications and the Internet, August 2008.

[3] M. Knoll, A. Wacker, and T. W. G. Schiele, “Decentralized bootstrapping in pervasive application,” Fifth Annual IEEE International Conference on Pervasive Computing and Communications Workshops (PerComW’07), pp. 589–592, April 2007.

[4] Advenica, “Master’s thesis: Self-organising high assurance privacy,” accessed 14/5 - 2019. [Online]. Available: https://career.advenica.com/jobs/ 35585-master-s-thesis-self-organising-high-assurance-privacy

[5] “Secure network,” last updated 27/6-2017, accessed 15/2 - 2019. [Online]. Available: https://www.computerhope.com/jargon/s/secure-network.htm

[6] “Network security,” accessed 15/2 - 2019. [Online]. Available: https://www.techopedia. com/deﬁnition/24783/network-security

[7] “What is network security?” accessed 15/2 - 2019. [Online]. Available: https: //www.cisco.com/c/en/us/products/security/what-is-network-security.html

[8] “P2P,” accessed 11/2 - 2019. [Online]. Available: https://techterms.com/deﬁnition/p2p

[9] “What is a vpn?” accessed 11/2 - 2019. [Online]. Available: https://www.expressvpn. com/what-is-vpn

[10] J. Mason, “VPN beginner’s guide,” last updated 26/2 - 2019, accessed 11/2 - 2019. [Online]. Available: https://thebestvpn.com/what-is-vpn-beginners-guide/

[11] J. Gokulakrishnan and D. V. T. Bai, “A survey report on vpn security and its technologies,” Indian Journal of Computer Science and Engineering (IJCSE), vol. 5, 4, Aug-Sep 2014, accessed 11/2 - 2019.

[12] C. Hoﬀman, “What is a VPN, and why would i need one?” last updated 30/4 - 2019, accessed 11/2 - 2019. [Online]. Available: https://www.howtogeek.com/133680/ htg-explains-what-is-a-vpn/

82 [13] M. Gargiulo, “What is a business VPN, and how can it secure your company?” last updated 15/11 - 2018, accessed 11/2 - 2019. [Online]. Available: https://www.forbes.com/sites/forbestechcouncil/2018/11/ 15/what-is-a-business-vpn-and-how-can-it-secure-your-company/#2d89e69563a5

[14] “What is a VPN tunnel?” last updated 15/11 - 2018, accessed 12/2 - 2019. [Online]. Available: https://www.ivpn.net/what-is-a-tunnel

[15] B. Mitchell, “VPN tunnels tutorial,” last updated 12/3 - 2019, accessed 12/2 - 2019. [Online]. Available: https://www.lifewire.com/vpn-tunneling-explained-818174

[16] “Dynamic multipoint VPN (DMVPN),” accessed 5/3 - 2019. [Online]. Available: https:// www.cisco.com/c/en/us/products/security/dynamic-multipoint-vpn-dmvpn/index.html

[17] M. Rouse and T. Parmenter, “Dynamic multipoint VPN (DMVPN),” accessed 5/3 - 2019. [Online]. Available: https://searchnetworking.techtarget.com/deﬁnition/ dynamic-multipoint-VPN-DMVPN

[18] J. Dinger and O. P. Waldhorst, “Decentralized bootstrapping of P2P systems: A practical view,” NETWORKING 2009, pp. 703–715, November 2009.

[19] M. Rouse, “multicast,” accessed 6/3 - 2019. [Online]. Available: https://searchnetworking. techtarget.com/deﬁnition/multicast

[20] H. Zhang, B. Croft, B. Levine, and V. Lesser, “A multi-agent approach for peer-to-peer based information retrieval system,” AAMAS ’04 Proceedings of the Third International Joint Conference on Autonomous Agents and Multiagent Systems, vol. 1, pp. 456 – 463, 2004.

[21] “Security token,” accessed 20/2 - 2019. [Online]. Available: http://mathworld.wolfram. com/RSAEncryption.html

[22] S. Hsu, “Session vs token based authentication,” last updated 30/6 - 2018, accessed 20/2 - 2019. [Online]. Available: https://medium.com/@sherryhsu/ session-vs-token-based-authentication-11a6c5ac45e4

[23] M. Rouse, “security token (authentication token),” accessed 20/2 - 2019. [Online]. Available: https://searchsecurity.techtarget.com/deﬁnition/security-token

[24] C. Sevilleja, “The ins and outs of token based authentication,” last updated 21/1 - 2015, accessed 20/2 - 2019. [Online]. Available: https://scotch.io/tutorials/ the-ins-and-outs-of-token-based-authentication

[25] M. Rouse, “IPsec (internet protocol security),” accessed 14/2 - 2019. [Online]. Available: https://searchsecurity.techtarget.com/deﬁnition/IPsec-Internet-Protocol-Security

83 [26] “Introduction to IP security (IPSec),” accessed 14/2 - 2019. [Online]. Available: https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/20/IPSec/b_20_ IPSec/b_20_IPSec_chapter_01.pdf

[27] S. Taylor and J. Wexler, “IPSec’s remote-access drawbacks,” last updated 11/11 - 2004, accessed 7/3 - 2019. [Online]. Available: https://www.networkworld.com/article/ 2326793/the-pros-and-cons-of-ipsec.html

[28] ——, “Advantages and disadvantages of IPsec,” accessed 7/3 - 2019. [Online]. Available: https://www.networkworld.com/article/2326793/the-pros-and-cons-of-ipsec.html

[29] T. Brewster, “Shadow brokers leak just revealed how the nsa broke american-made encryption,” last updated 19/8 - 2016, accessed 8/3 - 2019. [Online]. Available: https://www. forbes.com/sites/thomasbrewster/2016/08/19/cisco-nsa-vpn-hack-shadow-brokers-leak/

[30] B. Preneel, “Cryptography and information security in the post-Snowden era,” last updated February 2015, accessed 8/3 - 2019. [Online]. Available: https: //pdfs.semanticscholar.org/03ee/f5e2bf41a9656697d26969f3920ea2795052.pdf

[31] A. Spottka, “How to design a trustworthy IPsec VPN device employing nested tunnels?” Independent thesis Advanced level, Luleå University of Technology, 2018. [Online]. Available: http://www.diva-portal.org/smash/get/diva2:1252171/FULLTEXT01.pdf

[32] M. Rogers and G. Eden, “The snowden disclosures, technical standards, and the making of surveillance infrastructures,” International Journal of Communication, vol. 11, pp. 802 – 823, 2017.

[33] N. Pohlmann, M. Sparenberg, I. Siromaschenko, and K. Kilden, “Secure communication and digital sovereignty in europe,” ISSE 2014 Securing Electronic Business Processes, pp. 155–169, 2014.

[34] Y. SHeﬀer, H. T. G. Zorn, and S. Fluhrer, “An eap authentication method based on the encrypted key exchange (EKE) protocol,” Internet Engineering Task Force (IETF), February 2011.

[35] S. M. Bellovin and M. Merritt, “Encrypted key exchange: password-based protocols secure against dictionary attacks,” Proceedings of the IEEE Symposium on Research in Security and Privacy, pp. 72 – 84, May 1992.

[36] “associative,” accessed 10/7 - 2019. [Online]. Available: https://www.dictionary.com/ browse/associativity

[37] A. Arampatzis, “How is diffie-hellman key exchange different than RSA?” last updated 21/12 - 2018, accessed 18/2 - 2019. [Online]. Available: https://www.venafi.com/blog/ how-diffie-hellman-key-exchange-different-rsa

[38] A. Roy, “Brief comparison of rsa and diﬃe-hellman (public key) algorithm,” ACCENTS Transactions on Information Security, vol. 1, 1, 2016.

84 [39] “Diffie-hellman key exchange,” accessed 18/2 - 2019. [Online]. Available: https: //www.techopedia.com/definition/16085/diffie-hellman-key-exchange

[40] J. Dubin, “Choosing the right public key algorithm: Rsa vs. diﬃe-hellman,” last updated 23/4 - 2007, accessed 8/3 - 2019. [Online]. Available: https://www.networksasia.net/ article/choosing-right-public-key-algorithm-rsa-vs-diﬃe-hellman-1177257600

[41] “What’s the difference between diffie-hellman and RSA?” last updated 23/12 - 2017, accessed 8/3 - 2019. [Online]. Available: https://medium.com/@theporkskewer/ whats-the-difference-between-diffie-hellman-and-rsa-a7a9a8923be7

[42] J. Raymond and A. Stiglic, “Security issues in the diﬃe-hellman key agreement protocol,” IEEE Trans. on Information Theory, pp. 1 – 17, 2000.

[43] “RSA algorithm in cryptography,” published 18/4 - 2014, accessed 20/2 - 2019. [Online]. Available: https://www.geeksforgeeks.org/rsa-algorithm-cryptography/

[44] M. Rouse, M. Cobb, F. Hazan, and F. Rundatz, “RSA algorithm (Rivest-Shamir- Adleman),” accessed 20/2 - 2019. [Online]. Available: https://searchsecurity.techtarget. com/deﬁnition/RSA

[45] “Rsa encryption,” accessed 20/2 - 2019. [Online]. Available: http://mathworld.wolfram. com/RSAEncryption.html

[46] “Totient function,” accessed 10/7 - 2019. [Online]. Available: http://mathworld.wolfram. com/TotientFunction.html

[47] A. Arampatzis, “How is diffie-hellman key exchange different than RSA?” last updated 21/12 - 2018, accessed 8/3 - 2019. [Online]. Available: https://www.venafi.com/blog/ how-diffie-hellman-key-exchange-different-rsa

[48] C. Osborne, “As devastating as KRACK: New vulnerability undermines RSA encryption keys,” last updated 7/10 - 2017, accessed 8/3 - 2019. [Online]. Available: https://www.zdnet.com/article/ as-devastating-as-krack-new-vulnerability-undermines-rsa-encryption-keys/

[49] D. Boneh, “Twenty years of attacks on the rsa cryptosystem,” Notices of the American Mathematical Society (AMS), vol. 46, 2, pp. 203 – 213, 1999.

[50] A. H. Karbasi, R. E. Atani, and S. E. Atani, “A new ring-based SPHF and PAKE protocol on ideal lattices,” The ISC International Journal of Information Security, vol. 11, 1, pp. 75 – 85, January 2019.

[51] M.Abdalla, F. Benhamouda, and P. MacKenzie, “Security of the J-PAKE password- authenticated key exchange protocol,” 2015 IEEE Symposium on Security and Privacy, 2015.

85 [52] R. Canetti, J. K. S. Halevi, Y. Lindell, and P. MacKenzie, “Universally composable password-based key exchange,” Annual International Conference on the Theory and Ap- plications of Cryptographic Techniques, Eurocrypt 2005, pp. 404 – 421, 2005.

[53] E. Dongna, Q. Cheng, and C. Ma, “Password authenticated key exchange based on RSA in the three-party settings,” International Conference on Provable Security, ProcSec 2009: Provable Security, pp. 168 – 182, 2009.

[54] “Secure packager and encoder key exchange API speciﬁcation,” accessed 20/2 - 2019. [Online]. Available: https://docs.aws.amazon.com/speke/latest/documentation/speke.pdf

[55] P. Shor, “Algorithms for quantum computation: discrete logarithms and factoring,” Pro- ceedings 35th Annual Symposium on Foundations of Computer Science, pp. 124 – 134, 11 1994.

[56] D. Micciancio and O. Regev, “Lattice-based cryptography,” Post-Quantum Cryptography, November 2008.

[57] X. Lu, Y. Liu, D. Jia, H. Xue, J. He, and Z. Zhang, “LAC (lattice-based cryptosystems),” National Institute of Standards and Technology, 2017. [Online]. Available: https://cs.rit.edu/~ats9095/csci762/pdfs/LAC.pdf

[58] E. Fujisaki and T. Okamoto, “Secure integration of asymmetric and symmetric encryption schemes,” Advances in Cryptology — CRYPTO’ 99, pp. 537 – 554, 1999.

[59] D. Hofheinz, K. Hövelmanns, and E. Kiltz, “A modular analysis of the fujisaki-okamoto transformation,” Theory of Cryptography, pp. 314 – 371, 2017.

[60] J. Sen, “Reputation- and trust-based system for wireless self-organizing networks,” Security of Self-Organizing Networks, pp. 91 – 120, 2011.

[61] “What are the most common cyberattacks?” accessed 26/6 - 2019. [Online]. Available: https://www.cisco.com/c/en/us/products/security/common-cyberattacks.html

[62] “What is a ddos attack?” accessed 20/2 - 2119. [Online]. Avail- able: https://www.cloudﬂare.com/learning/ddos/what-is-a-ddos-attack/?utm_referrer= https://www.google.com/

[63] S. Weisman, “What is a distributed denial of service attack (DDoS) and what can you do about them?” accessed 21/2 - 2019. [Online]. Available: https://us.norton.com/ internetsecurity-emerging-threats-what-is-a-ddos-attack-30sectech-by-norton.html

[64] M. Rouse and K. Beaver, “Distributed denial of service (ddos) attack,” last updated April 2019, accessed 8/5 - 2019. [Online]. Available: https://searchsecurity.techtarget. com/deﬁnition/distributed-denial-of-service-attack

86 [65] K. Ferreira, “The difference between DOS and DDOS attacks,” accessed 8/5 - 2019. [Online]. Available: http://www.differencebetween.net/technology/ the-difference-between-dos-and-ddos-attacks/

[66] L. Munson, “DOS vs DDOS - what is the diﬀerence?” last updated May 29 - 2012, accessed 8/5 - 2019. [Online]. Available: http://www.security-faqs.com/ dos-vs-ddos-what-is-the-diﬀerence.html

[67] S. Weisman, “What are denial of service (DOS) attacks? DOS attacks explained,” accessed 8/5 - 2019. [Online]. Available: https://us.norton.com/ internetsecurity-emerging-threats-dos-attacks-explained.html

[68] M. Sherr, “Eavesdropping,” Encyclopedia of Cryptography and Security, pp. 378 – 379, 2011.

[69] “Eavesdropping,” accessed 22/2 - 2019. [Online]. Available: https://www.techopedia.com/ deﬁnition/13612/eavesdropping

[70] Z. Chen, S. Guo, K. Zheng, and Y. Yang, “Modeling of man-in-the-middle attack in the wireless networks,” 2007 International Conference on Wireless Communications, Network- ing and Mobile Computing, pp. 2255–2258, 2007.

[71] B. Vigliarolo, “Man-in-the-middle attacks: A cheat sheet,” published 30/11 2018, accessed 22/2 - 2019. [Online]. Available: https://www.techrepublic.com/article/ man-in-the-middle-attacks-a-cheat-sheet/

[72] “Ethical hacking - arp poisoning,” accessed 9/5 - 2019. [Online]. Available: https://www.tutorialspoint.com/ethical_hacking/ethical_hacking_arp_poisoning.htm

[73] C. L. Abad and R. I. Bonilla, “An analysis on the schemes for detecting and preventing arp cache poisoning attacks,” 27th International Conference on Distributed Computing Systems Workshops (ICDCSW’07), July 2007. [On- line]. Available: https://www.researchgate.net/proﬁle/Cristina_Abad/publication/ 4264370_An_Analysis_on_the_Schemes_for_Detecting_and_Preventing_ARP_ Cache_Poisoning_Attacks/links/0046351656f0d82ce6000000.pdf

[74] A. P. Ortega, X. E. Marcos, L. D. Chiang, and C. L. Abad, “Preventing arp cache poisoning attacks: A proof of concept using openwrt,” 2009 Latin American Network Operations and Management Symposium, pp. 1–9, November 2009.

[75] S. S. Sengar, “How to do a man-in-the-middle attack using arp spooﬁng and poisoning,” last updated 6/12 - 2017, accessed 9/5 - 2019. [Online]. Available: https://medium.com/secjuice/man-in-the-middle-attack-using-arp-spooﬁng-fa13af4f4633

[76] “What is a brute force attack?” last updated 7/2 - 2018, accessed 19/3 - 2019. [Online]. Available: https://www.cloudways.com/blog/what-is-brute-force-attack/

87 [77] “Brute force attack,” accessed 19/3 - 2019. [Online]. Available: https://www.techopedia. com/deﬁnition/18091/brute-force-attack

[78] “What is a brute force attack?” accessed 19/3 - 2019. [Online]. Available: https://www.kaspersky.com/resource-center/deﬁnitions/brute-force-attack

[79] J. Petters, “What is a brute force attack?” last updated 6/10 - 2018, accessed 19/3 - 2019. [Online]. Available: https://www.varonis.com/blog/brute-force-attack/

[80] M. Rouse, “Brute force attack,” accessed 19/3 - 2019. [Online]. Available: https: //searchsecurity.techtarget.com/deﬁnition/brute-force-cracking

[81] “Instructions per second,” accessed 13/5 - 2019. [Online]. Available: https: //en.wikipedia.org/wiki/Instructions_per_second

[82] “Intel® core™ i9-9900k processor,” accessed 13/5 - 2019. [Online]. Available: https://www. intel.com/content/www/us/en/products/processors/core/i9-processors/i9-9900k.html

[83] “Us summit supercomputer leads the latest top500 list,” last updated 25/6 - 2018, accessed 13/5 - 2019. [Online]. Available: https://www.cdrinfo.com/d7/content/ us-summit-supercomputer-leads-latest-top500-list

[84] “Dictionary attack,” accessed 19/3 - 2019. [Online]. Available: https://www.techopedia. com/deﬁnition/1774/dictionary-attack

[85] G. Fawkes, “Can VPNs be hacked? we did the research, here’s the guide,” accessed 15/2 - 2019. [Online]. Available: https://www.vpnmentor.com/blog/ can-vpns-hacked-take-deeper-look/

[86] M. Mimoso, “Targeted attack uses heartbleed to hijack VPN sessions,” published 18/4 - 2014, accessed 15/2 - 2019. [Online]. Available: https://threatpost.com/ targeted-attack-uses-heartbleed-to-hijack-vpn-sessions/105567/

[87] “Session hijacking (cookie side-jacking),” accessed 9/4 - 2019. [Online]. Available: https://doubleoctopus.com/security-wiki/threats-and-tools/session-hijacking/

[88] M. Bray, “Session hijacking: all you need to know,” latest updated 2/10 - 2018, accessed 9/4 - 2019. [Online]. Available: https://vpnpro.com/data-protection/session-hijacking/

[89] “Session hijacking attack,” last updated 14/8 - 2014, accessed 9/4 - 2019. [Online]. Available: https://www.owasp.org/index.php/Session_hijacking_attack

[90] L. M. Garcia, “Programming with libpcap - sniﬃng the network from our own application,” Hakin9, vol. 3, 2, pp. 39 – 46, 2008.

[91] B. Mitchell, “What is a network sniffer?” last updated 26/2 - 2019, accessed 13/5 - 2019. [Online]. Available: https://www.lifewire.com/definition-of-sniffer-817996

[92] “Network sniffing,” accessed 13/5 - 2019. [Online]. Available: https://securebox.comodo. com/ssl-sniffing/network-sniffing/

88 [93] “Ettercap and middle-attacks tutorial,” last updated 1/3 - 2017, accessed 9/5 - 2019. [Online]. Available: https://pentestmag.com/ettercap-tutorial-for-windows/

[94] T. E. D. Team, “Ettercap,” accessed 9/5 - 2019. [Online]. Available: https: //github.com/Ettercap/ettercap

[95] “ettercap (8) - linux man pages,” accessed 9/5 - 2019. [Online]. Available: https://www.systutorials.com/docs/linux/man/8-ettercap/

[96] “bettercap,” accessed 14/5 - 2019. [Online]. Available: https://www.bettercap.org/

[97] S. Margaritelli, “Bettercap stable documentation,” last updated 2016, accessed 14/5 - 2019. [Online]. Available: https://www.bettercap.org/legacy/

[98] T. Shorey, D. Subbaiah, A. Goyal, A. Sakxena, and A. Kumar Mishra, “Performance comparison and analysis of slowloris, goldeneye and xerxes ddos attack tools,” Confer- ence: 2018 International Conference on Advances in Computing, Communications and Informatics (ICACCI), pp. 318–322, 09 2018.

[99] “Xerxes the most powerful dos tool,” latest commit 21/4 - 2017, accessed 16/5 - 2019. [Online]. Available: https://github.com/zanyarjamal/xerxes

[100] “Ddos attack deﬁnitions - ddospedia,” accessed 10/5 - 2019. [Online]. Available: https://security.radware.com/ddos-knowledge-center/ddospedia/xerxes/

[101] A. M. Freed, “The jester hits wikileaks site with xerxes dos attack,” last updated 29/11 - 2010, accessed 10/5 - 2019. [Online]. Available: http://www.infosecisland.com/blogview/ 9865-The-Jester-Hits-WikiLeaks-Site-With-XerXeS-DoS-Attack.html

[102] “About apache,” accessed 1/7 - 2019. [Online]. Available: https://httpd.apache.org/ ABOUT_APACHE.html

[103] “Key distribution center (KDC),” accessed 25/2 - 2019. [Online]. Available: https: //www.techopedia.com/deﬁnition/12883/key-distribution-center-kdc-cryptography

[104] E. Okamoto and K. Tanaka, “Key distribution system based on identiﬁcation information,” IEEE journal on selected ares in communications, vol. 1, 4, pp. 481 – 485, May 1989.

[105] “Key distribution center,” last updated 13/5 - 2018, accessed 25/2 - 2019. [Online]. Available: https://docs.microsoft.com/en-us/windows/desktop/secauthn/ key-distribution-center

[106] “Security of the J-PAKE password-authenticated key exchange protocol,” accessed 14/5 - 2019. [Online]. Available: https://doubleoctopus.com/security-wiki/authentication/ key-distribution-center/

[107] Y. Bhaiji, “Group encrypted transport VPN (GETVPN),” Network Security Technologies and Solutions (CCIE Professional Development Series), pp. 503 – 520, November 2016.

89 [108] B. Weis, S. Rowles, and T. Hardjonom, “The group domain of interpretation,” Internet Engineering Task Force (IETF), October 2011.

[109] M. Baugher, B. Weis, T. Hardjono, and H. Harney, “The group domain of interpretation,” Internet Engineering Task Force (IETF), July 2011.

[110] “Introduction to group VPN,” published February 2011, accessed 22/2 - 2019. [Online]. Available: https://www.juniper.net/us/en/local/pdf/app-notes/3500202-en.pdf

[111] B. Weis, U. Mangla, T. Jark, and N. Maheshwari, “The group domain of interpretation,” Internet Engineering Task Force (IETF), June 2017.

[112] C. Kaufman, P. Hoﬀman, Y. Nir, P. Eronen, and T. Kivinen, “Internet key exchange protocol version 2 (IKEv2),” RFC 7296, 2014. [Online]. Available: https://tools.ietf.org/html/rfc7296

[113] “What is IKEv2,” accessed 15/4 - 2019. [Online]. Available: https://www.purevpn.com/ what-is-vpn/protocols/ikev2

[114] J. G. Steiner, C. Neuman, and J. I. Schiller, “Kerberos: An authentication service for open network systems,” In Usenix Conference Proceedings, pp. 191–202, 01 1988.

[115] J. Kohl and C. Neuman, “The kerberos network authentication service (V5),” RFC 1510, September 1993. [Online]. Available: https://tools.ietf.org/html/rfc1510

[116] C. Neuman, T. Yu, S. Hartman, and K. Raeburn, “The kerberos network authentication service (V5),” RFC 4120, July 2005. [Online]. Available: https: //tools.ietf.org/html/rfc4120

[117] “What is kerberos authentication?” last updated 8/10 - 2009, accessed 28/2 - 2019. [Online]. Available: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/ windows-server-2003/cc780469(v=ws.10)

[118] “Kerberos key distribution center (KDC) and administration tools,” last updated 2010, accessed 28/2 - 2019. [Online]. Available: https://docs.microsoft.com/en-us/windows/ desktop/secauthn/key-distribution-center

[119] M. Knoll, A. Wacker, G. Schiele, and T. Weis, “Decentralized bootstrapping in pervasive applications,” Proceedings of the Fifth Annual IEEE International Conference on Pervasive Computing and Communications Workshops(PerComW’07), pp. 589–592, 2007.

[120] C. GauthierDickey and C. Grothoﬀ, “Bootstrapping of peer-to-peer networks,” 2008 In- ternational Symposium on Applications and the Internet, pp. 205 – 208, 2008.

[121] K. Hoeper and G. Gong, “Bootstrapping security in mobile ad hoc networks usingidentity- based schemes with key revocation,” Ad-Hoc, Mobile, and Wireless Networks, pp. 224–237, 2006.

90 [122] Y.-C. Tseng, J.-R. Jiang, and J.-H. Lee, “Secure bootstrapping and routing in an ipv6- based ad hoc network,” Journal of Internet Technology, pp. 375 – 382, 2003.

[123] “What is a raspberry pi?” accessed 14/5 - 2019. [Online]. Available: https: //www.raspberrypi.org/help/what-%20is-a-raspberry-pi/

[124] “Raspberry pi 3 model B+,” accessed 14/5 - 2019. [Online]. Available: https: //www.raspberrypi.org/products/raspberry-pi-3-model-b-plus/

[125] N. Jennings, “Socket programming in python (guide),” updated 1/8 - 2018, accessed 16/5 - 2019. [Online]. Available: https://realpython.com/python-sockets/

[126] “Pure-python j-pake,” latest commit 16/10 - 2010, accessed 16/5 - 2019. [Online]. Available: https://github.com/warner/python-jpake

[127] “Encryption and decryption in python,” last updated 16/9 - 2018, accessed 16/5 - 2019. [Online]. Available: https://nitratine.net/blog/post/ encryption-and-decryption-in-python/

[128] “If pickling was interrupted, will unpickling necessarily always fail? - python,” asked 9 years ago, accessed 16/5 - 2019. [Online]. Available: https://stackoverﬂow.com/questions/ 1653897/if-pickling-was-interrupted-will-unpickling-necessarily-always-fail-python

[129] “Lacv1,” latest commit 15/10 - 2018, accessed 16/5 - 2019. [Online]. Available: https://github.com/dd4rk/LACv1/tree/master/Reference_Implementation

91 Appendices

A Dictionary

Meaning Abbreviation Access Control List ACL Authentication Header AH Authentication Service AS Customer Edge CE Denial-of-Service DoS Diﬃe-Hellman Key Exchange DHEKE Digital Rights Management DRM Distributed Denial-of-Service DDoS Dynamic Multipoint VPN DMVPN Encapsulating Security Payload ESP Encrypted Key Exchange EKE The Group Domain of Interpretation GDOI Group Controller/Key Server GCKS Group Encrypted Transport VPN GET VPN Internet Key Exchange IKE Internet Protocol Security IPSec Internet Security Association and Key Management Protocol ISAKMP Key Distribution Center KDC Key Encryption Key KEK Layer 2 Tunneling Protocol L2TP L2TP Access Concentrator L2TPAC Local Area Network LAN L2TP Network Server LNS multipoint Generic Routing Encapsulation mGRE Man-in-the-Middle MitM Multiprotocol Label Switching MPLS Next Hop Resolution Protocol NHRP Peer-to-Peer P2P Password authenticated key exchange PAKE Provider Edge PE Point to Point Tunneling Protocol PPTP Rendezvous Point RP Secure Packager and Encoder Key Exchange SPEKE Traﬃc Encryption Key TEK Ticket-Granting Service TGS Virtual Private Networks 92 VPN Well Known Entry Point WKEP