How to Design a Trustworthy Ipsec VPN Device Employing Nested Tunnels?

How to design a trustworthy IPsec VPN device employing nested tunnels?

Alexander Spottka

Information Security, master's level (60 credits) 2018

Luleå University of Technology Department of Computer Science, Electrical and Space Engineering ABSTRACT

nterprises use site-to-site Virtual Private Network (VPN) technology to securely transmit data over insecure networks, such as the Internet. By utilizing commercial VPN products, Eorganizations partially rely on the vendors to keep their communication out of reach from malicious groups or individuals. These VPN servers consist of thousands of subcomponents, which can be grouped into hardware, operating system, general software, protocols, and algorithms. The main idea of this study is to design an IPsec VPN architecture based on IPsec nesting. This is achieved by designing two servers that consist of different subcomponents on each layer. Thus, a vulnerability in one component will not necessarily put the entire IPsec communication at risk. The subcomponents picked for deployment are investigated and reviewed based on their trustworthiness, which will be based on later deﬁned criteria. This trust analysis will act as a potential starting point for providing a framework for future trust assessments.

ACKNOWLEDGEMENTS

efore presenting details of this study, I want to thank Combitech, and especially Per Westerberg and Daniel Arvidsson for their support of this thesis. Despite their busy Bschedule, we managed to initiate the thesis. Furthermore, I wish to thank Tero Päivärinta and Parvaneh Westerlund. Even though I decided to pursue this study on late notice, they supported me with detailed feedback and simplicity in the process. Personally, I want to thank my girlfriend Melina who, despite her own work, took care of everything else in order to help me stay focused on the study. Lastly, I need to express my appreciation to have such a caring family at home. My mother Dagmar and brother Matthias especially kept me motivated and helped me unwind after long days of writing.

iii TABLEOF CONTENTS

Page

List of Tables vi

List of Figures vii

1 Introduction 1 1.1 Literature Review...... 2 1.1.1 Trust...... 3 1.1.2 Hardware ...... 4 1.1.3 Operating System ...... 5 1.1.4 IPsec Applications...... 6 1.1.5 Protocols and Cryptography ...... 6 1.2 Research Question...... 7 1.3 Motivation ...... 7 1.4 Limitation ...... 7 1.5 Target Group...... 8 1.6 Outline ...... 8

2 Theoretical Context9 2.1 Assurance and Security ...... 9 2.2 IPsec...... 10 2.2.1 Symmetric vs. Asymmetric cryptography ...... 10 2.2.2 Key Exchange...... 11 2.2.3 Functionality of IPsec...... 11

3 Methodology 13 3.1 Research Method ...... 14 3.2 Reliability and Validity...... 16 3.3 Ethical Considerations...... 17

4 Design 19 4.1 Hardware...... 20

iv 4.1.1 UDOOx86...... 20 4.1.2 ODROID-XU4...... 22 4.2 Operating System...... 23 4.2.1 RedHat Enterprise Linux...... 23 4.2.2 Debian Jessie...... 24 4.3 IPsec Applications...... 25 4.3.1 strongSwan ...... 26 4.3.2 Libreswan...... 27 4.4 Cryptography...... 28 4.4.1 ESP-Encryption Algorithms ...... 29 4.4.2 Integrity...... 31 4.4.3 Difﬁe-Hellman Group...... 32 4.4.4 Digital signatures ...... 33 4.5 Finalized design...... 34

5 Implementation 37 5.1 Conﬁguration of the strongSwan servers ...... 37 5.2 Conﬁguration of the Libreswan servers...... 39

6 Demonstration 41

7 Evaluation 43 7.1 Summarized trust score for all ...... 43 7.2 IPsec Testing and Certiﬁcation Program Criteria Version 3.0...... 45 7.2.1 IPsec ...... 46 7.2.2 Logging...... 46 7.2.3 Administration...... 47 7.2.4 Authentication using Certiﬁcates...... 47 7.3 Performance ...... 48

8 Discussion 51

9 Conclusion 53 9.1 Future research ...... 54

A Appendix A 1

Bibliography 5

v LISTOF TABLES

LISTOF TABLES

TABLE Page

4.1 Pros and cons of SECO and their product: UDOOx86...... 21 4.2 Trust Score for SECO/UDOOx86...... 21 4.3 Pros and cons of Hardkernel and their product ODROID-XU4 ...... 22 4.4 Trust Score for Hardkernel / ODROID-XU4...... 23 4.5 Pros and cons of RHEL v.7...... 24 4.6 Trust Score for RHEL v.7...... 24 4.7 Pros and cons of Debian ...... 25 4.8 Trust Score for Debian ...... 25 4.9 Pros and cons of strongSwan...... 26 4.11 Pros and cons of Libreswan ...... 27 4.10 Trust Score for strongSwan ...... 27 4.12 Trust Score for Libreswan ...... 28 4.13 Algorithm Choices...... 29 4.14 Trust Score for AES, CHACHA20, Camellia ...... 31 4.15 Trust Score for SHA...... 32 4.16 Trust Score for MODP and X25519...... 33 4.17 Trust Score for RSA, ECDSA, and EdDSA ...... 34 4.18 Algorithm Choices...... 34 4.19 Final design...... 35

7.1 Trust Score for Device 1 ...... 43 7.2 Trust Score for Device 2 ...... 44 7.3 Throughput result...... 49 7.4 Average Throughput in relation to baseline...... 49 7.5 Latency result ...... 50

vi LISTOF FIGURES

FIGURE Page

2.1 IP vs. IPsec datagram...... 12

3.1 IPsec topology ...... 14

4.1 IPsec topology ...... 19 4.2 Architecture of the artefact ...... 36

6.1 Raw ICMP traffic ...... 41 6.2 Traffic after establishing one IPsec tunnel ...... 42 6.3 Traffic after establishing nested IPsec tunnels...... 42

A.1 UDP throughput no tunnel...... 1 A.2 TCP throughput no tunnel...... 1 A.3 UDP throughput with tunnel between RHEL machines ...... 2 A.4 TCP throughput with tunnel between RHEL machines...... 2 A.5 UDP throughput with tunnel between Debian machines...... 2 A.6 TCP throughput with tunnel between Debian machines...... 2 A.7 UDP throughput with tunnel between both machines ...... 2 A.8 TCP throughput with tunnel between both machines...... 3

vii

mrc [ America nwihoetne ol eatce ihu h osqecso opoie ytm Each system. compromised a of consequences the architecture, without failover attacked a be in could results at tunnel This expert tunnels. one VPN VPN which Arvidsson, layering in Daniel of compromise, idea of initial risk the subcomponents decrease had such to Combitech, order developing In organizations questioned. the be into to puts needs one VPN trust as of such party amount products, third The hypercomplex in servers. today’s assurance regarding of manufacturers importance their the and show to components example an established is server the This of VPN channel. availability a and communication Using integrity, confidentiality, study. endangers the TPM in flawed available a machine contains test that the within keys vulnerable of quarter on [ distributed library, al. cryptographic et used Modules Nemec widely a of in paper a flaw journal of particular the consist that in shown they described since As unfeasible, subcomponents. currently of is number servers high VPN of correctness the of of States investigation United the in agencies intelligence of surveillance digital scale and large miscommunication, revealed Snowden to leading terminology definitions, [ the multiple structures clarify vulnerable to its therefore attempts indicates study the Gollman This safety. so since their functionality trust, their of of assurance of correctness of the degree assure high can a statement devices has previous VPN user The if Internet. true the deemed as be such only media, can untrusted an over channels secure establish manipulation. or eavesdropping from free I h vrg sr h raino lblsann ytmrqie euecommunication, secure requires system spanning global for a incomprehensible of and creation abstract The increasingly user. become average imper- have the become systems has IT it assets, it. valuable protect most to world’s ative the of one becoming information of times n TM n te ares uha Dcrsadpsprs hc eutdi ogl a roughly in resulted which passports, and cards ID as such carriers, other and (TPM) 2 ,auigciia unrblte nawd pno rwl rdcs tl,tethorough the Still, products. firewall of span wide a in vulnerabilities critical abusing ], 1 .Tutcno etkna rne,epcal ic Edward since especially granted, as taken be cannot Trust ]. ita rvt Networks Private Virtual 1 VN fe h aaiiyto capability the offer (VPN) I NTRODUCTION rse Platform Trusted

3 C HAPTER ,hsoyhas history ], 1 CHAPTER 1. INTRODUCTION

VPN server in this architecture will further be divided into different modular sub-groups that will interact with each other. The first layer consists of hardware. Most importantly for cryptographic activities is the processor, since it holds the TPM, which holds highly important properties, such as private keys [4]. On top of the hardware lies the operating system (OS). The OS provides a platform for applications as well as basic functionality for accessing hardware components. For this study, applications are narrowed down to Internet Protocol Security (IPsec) VPN applications. IPsec applications need to be configured to utilize desired protocols and encryption algorithms. Organizations such as NIST publish standards and recommendations, e.g Key Management [5], to guide administrators securing their devices and networks. End-users often rely on trusting what vendors develop and sell. Individuals rarely have the knowledge or capacity for analysing the entirety of the VPN encryption devices they are using. While this is already worrisome, the impact on critical infrastructures and high-security systems is something that needs to be revised. Governmental instances have a funded interest in keeping classified information out of reach from potential harmful parties. Furthermore, critical communication systems need to be reliant and protected at any cost in order to protect the social sector. This study’s purpose is investigating possibilities of building a VPN device with potentially untrusted components, yet high degree of assurance. Redundancy of subcomponents will be a central concept and elaborated further in the report. In detail, the idea is to employ redundancy in each block of subcomponents (Hardware, Operating System (OS), Software, and Protocols). A redundant system using different subcomponents, e.g. encryption algorithms, operating systems, and others, will likely be less affected by sudden appearances of vulnerabilities due to its flexible nature. A potential scenario is that an encryption algorithm is found to have a vulnerability. If the VPN device is already layering encryption algorithms, the consequences will be less problematic. This will certainly affect the performance, which will be investigated throughout this thesis.

1.1 Literature Review

Literature and research on trustworthiness and assurance of VPN encryption devices is sparse. On the other hand, there exists plenty of material towards trust of subcomponents, such as processors, encryption, software, and others. Relevant findings of these, which are connected to this study, will be shown below. Research that aims to investigate the possibilities of developing a highly distrusting VPN device employing nested tunnels could not be identified during the literature review. After discussion with the external supervisor Daniel Arvidsson, it might have to do with the proprietary nature of commercial VPN devices. The idea of this thesis stems from the need of high assurance VPN connections and was identified by Daniel Arvidsson. Therefore, it could be classified as a niche research that has not yet been investigated by researchers. Nevertheless, the following subsections should provide a frame of information about the security of subcomponents. Also, it will show results from other researchers tackling the issue of assurance

2 1.1. LITERATURE REVIEW

of the deﬁned subcomponents. These results cannot always be applied due to their high degree of complexity.

1.1.1 Trust

Researchers from different research areas have published plenty of definitions for trust. Gollmann identifies the different definitions as problematic and states: “First, security needs clarity and precision. Using a term like trust that has many different meanings (many more than explored in this paper) is unlikely to promote clarity and precision” [1]. Without the same notion of trust, discussing trusted systems becomes increasingly difficult. If a project leader has a different understanding of trust compared to his employees, communicating about trusted systems according to the project manager’s vision will prove problematic. Important to mention is that trust in components and humans does not necessarily lead to a secure system, but rather towards predictability [6]. In their article, McKnight et. al investigated over sixty-five definitions of trust from various researchers and developed an interdisciplinary typology for trust. They condensed sixteen categories for trust into four definitions of trust constructs. The constructs that apply most for the relationship between users and vendors are Institution-based Trust (IBT) and Trusting Beliefs (TB). IBT is defined as the following: “Institution-based Trust means one believes the needed conditions are in place to enable one to anticipate a successful outcome in an endeavor or aspect of one’s life”. The definition of TB according to [7] is “Trusting Beliefs means one believes (and feels confident in believing) that the other person has one or more traits desirable to one in a situation in which negative consequences are possible”. The sub constructs of IBT and TB will be the criteria for trustworthiness of this study. Necessary to mention is that situational normality has been excluded, since longer observation periods are necessary for an accurate assessment. Therefore, the criteria for assessing trust are the following:

• Structural Assurance

• Competence

• Benevolence

• Integrity

• Predictability

Structural Assurance achieves assurance through regulations, guarantees, contracts, processes, policies, and other methodical approaches. First, a product is more likely to be trusted if the vendor shows competence in their core business. This is done by publishing scientiﬁc papers or conference participation. Also, benevolence is considered an important factor in today’s IT landscape. Even technology giants like Intel and Samsung present a benevolent attitude that

3 CHAPTER 1. INTRODUCTION

one may believe they are human and caring. Often this affects several topics, not only their customers privacy. A major issue in technology is integrity. Even well-respected organizations such as the NSA, NIST, and IETF lost their credibility after the Snowden revelations [2]. Lastly, predictability describes that one is more trusted if the actions of the opposite party are consistent and therefore forecast-able. A problem with trust in general is that there is no assurance in the correctness of a fact. The Oxford dictionary deﬁnes trust as follows: “Firm belief in the reliability, truth, or ability of someone or something”. Merely believing in the security of a nuclear power plant seems oddly unsatisfactory. Therefore, a system should be trustworthy instead of simply trusted. Trustworthy is deﬁned as the following by the Oxford English dictionary: “Able to be relied on as honest or truthful”. Trustworthiness is the property of any kind of computer system to function exactly how it is intended to be. In the case of VPN devices, trustworthiness is the assurance of a secure communication over an insecure medium, such as the Internet. Therefore, critical encryption devices should not merely be trusted, but show a high level of trust.

1.1.2 Hardware

Hardware is the base layer of every IT-System. There is a vast number of different hardware that is used all over the globe. Hardware is a physical component that consists of a circuit board and several integrated circuits (IC). These circuits are fabricated in semiconductor fabrication plants, which are commonly located in Asia for reasons of production cost. These factories are often utilized by several customers that need customized hardware for their projects. Companies like Samsung and Intel hold respectable parts of the market share, but there are also other producers which have different supply chains and security mechanisms. Commonly, the Trusted Platform Module (TPM) is considered the root of trust, which means that, in case of compromise, the entire system can be considered endangered. ISO/IEC 11889-1:2009 defines TPM and its use. It is described as a passive component that receives commands and processes responses. The commands towards the TPM are meant to perform primitive and confidential calculations. These calculations are mostly related to cryptographic keys [4]. Highly complex hardware builds the foundation for every server, PC, smartphone, and more, each with different operating systems and user applications. The problem with low-level hardware products is their high complexity and the difficulty of analysis. A research team around Joanna Rutkowska faced the challenge of analysing an Intel x86-based notebook. Their results are insufficient boot security and the identification of a black-box element that is not analysable. This element (Intel Management Engine) has permissions to the memory as well as the network card, which poses a risk for the assurance of data confidentiality [8]. This is just one example to highlight the importance of the problem. It is not recommended to simply trust hardware manufacturers. The revelations of Spectre and Meltdown, presented by joined researchers of different universities, further strengthen this statement [9][10]. With those vulnerabilities deployed, millions of devices are vulnerable if no

4 1.1. LITERATURE REVIEW

countermeasures by the processor manufacturers or end users are taken. Another important task facing hardware security is to secure the supply chain process from malicious manipulation. Adam Waksman identified the hardware supply chain as a weak link in the system and worked out an approach where he uses self-developed tools to prevent hardware manipulation during the production process [11]. The same problem is discussed in a paper from researchers of the university college of London, the Masaryk university cooperating with the security governance company “Enigma Bridge”. Their product called Myst combines redundancy and cryptographic techniques to withstand malicious or faulty subcomponents [12]. These artefacts are not mature enough to be used on larger scale and would cause this thesis to require more than double the time. Still, it seemed fitting to mention them for the interested reader. Another angle facing hardware security is the view of the industry, which can be of help in understanding the entire scope of this study. The industry traditionally has three methods to ensure product trustworthiness. These are Trusted foundries, Split-Manufacturing, and Post- Fabrication inspection. The trusted foundry program initiated by the department of defence accredits suppliers of hardware if they have a trusted product flow. ”A trusted supply chain begins with trusted design and continues with trusted mask, foundry, packaging/assembly, and test services” [13]. Establishing secure, separate product flows and trusted associations is costly and requires the foundry to be run in-house. However, the risk of an inside job is always present. Split-Manufacturing is more cost effective. The design is handled in-house while fabrication is handled from a third-party supplier. Integrated circuits can fall victim to attacks from their production to the arrival on-site. Chen et al. analysed if Split-Manufacturing can prevent attacks such as hardware Trojans but had unsatisfactory results. However, they present approaches on how to defend against the most common attacks [14]. The least level of trustworthiness is achieved by Post-Fabrication inspection. The previously mentioned papers, show that despite intense Post-Fabrication inspection malicious ICs are implemented in productive environments.

1.1.3 Operating System

Hardware security is the foundation for building a secure system. On top of that lies the operating system. There exists research and regulations concerning operating systems that have been assessed prior to the research phase of this thesis. The International Organization for Stan- dardization (ISO) standard 15408-3:2008 covers the challenges on the methodology of grading operating system software with respective security levels, enabling end users taking decisions if a product is appropriate towards the security requirements [15]. Evaluation Assurance Levels Levels (EAL) range from one to seven, with seven meaning the highest assurance. Operating system vendors like Cisco, Checkpoint, and Redhat achieved an EAL level of 4+. In 2.1, further explanation is given on why EAL might not be the best single best only criteria for assurance of operating systems. An interesting approach worth mentioning is QubesOS. Johanna Rutkowska and her team created an operating system that follows this approach: ”security by compartmen-

5 CHAPTER 1. INTRODUCTION

talization“. It consists of a bare metal hypervisor that invokes light virtual machines for arbitrary functions of a user (browsing, USB usage, etc.). Unfortunately, QubesOSs hardware requirements cannot be met by affordable Single Board Computer (SBC) [16].

1.1.4 IPsec Applications

On top of the operating system, applications are installed. Therefore, assembling a system with untrusted components also involves software. This study’s concerns are limited to IPsec applications. A major problem in application security is assuring the correctness of third-party software. In the past, there have been several major security breaches, due to the fact that companies relied on flawed third-party software. A paper by researchers of Carnegie Mellon University asks the question if third-party certification of software is necessary. Sadly, there was no conclusion that would have yielded a definite answer to the problem, but it has some valid information that seems relevant to this thesis [17]. Other papers propose different models on how to mitigate the risk of implementing third-party software. One is based on software-wrapping that offers developers an understanding of what the third-party software does, while the other paper presents three controls, two being technical and one being a clear policy towards the usage of third-party software. The importance of collaborating with vendors is stated, but not shown [18][19]. As with the other subcomponents, it would be possible to dive into the details and apply all models and recommendations from previous papers. Nonetheless, this is not the objective of this study. Instead, the definition of trust in this study has been be given in 1.1.1 and will be empirically applied on vendors and products.

1.1.5 Protocols and Cryptography

IT systems range from a microchip on a personal computer to highly complex, global networks. Common protocols and standards help building these systems. Most protocols are widely deployed and developed by organizations that are connected with governments. The question arises if they really are as trustworthy as we might think, especially after the revelations of Edward Snowden in 2014 became public. In an article that aims to summarize and order these leaked documents, the authors discuss the technicalities and procedures that have led to what is known from the leaks. Standards are described as “an instance of governance in the absence of government”, since they deﬁne conditions all over the globe without a higher authority of control. This can be interpreted positively due to the distribution of powers, but also negatively because of a missing control organ. Furthermore, most standards are overly complex and therefore often incorrectly implemented, which makes them vulnerable. The authors mention the IPsec protocol as an example. IPsec, for example, has an unnecessary amount of options, leading to a less than correct implementation [2]. Encryption is another hot topic. According to the leaked documents, the National Security Agency (NSA) has implemented a backdoor by design into Dual Elliptic Curve Deterministic Random

6 1.2. RESEARCH QUESTION

Bit Generator (Dual DRBG). Still, it passed the requirements of ISO and the National Institute of Standards and Technology (NIST), and has been implemented in multiple software libraries [20]. History has shown that this was not the only case of deliberate weakening of standards by political instances. Troublesome is that there might be more encryption standards out there that we blindly trust. On the blackhat IT security conference 2017, two researchers presented the results of their mathematical backdoor. They created a symmetric encryption algorithm, BSA-1, which has many parallels with the widely deployed, and standardized, AES algorithm. Interestingly, BSA-1 passed all cryptographic tests of ISO and the NIST. They state that no one has found the intentionally placed backdoor to this date. Hence, the question arises how one can believe that the cryptographic standards, developed by the enormous cryptographic competence of the NSA, does not contain a similar backdoor [21] Another problem could be unintentionally insecure protocols or badly implemented protocols. An example of this is the key distribution protocol “Diffie-Hellman”. In the journal article “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice”, researchers present their findings on the weaknesses of protocol implementation. They advise cryptographers and system architects to peek on the other side of the table and collaborate closer to prevent further security violations [22]

1.2 Research Question

• How to employ trust models on subcomponents of VPN servers?

• How to design a trustworthy IPsec VPN device using untrusted subcomponents, based on subcomponent redundancy?

1.3 Motivation

The idea of this thesis was developed together with Daniel Arvidsson and Tomas Stewén (Com- bitech). The expected result will beneﬁt Combitech along with VPN/Network architects and potential users. The results of this work provide trust-oriented implementation to IPsec VPNs, one of the fundamental concepts of privacy and communication security. The prototype introduces the concept of nested IPsec tunnels implemented on trust-evaluated subcomponents.

1.4 Limitation

The possibilities of designing architecture, as performed in this study, can be taken to a new level with more resources available. This project had the time frame of a regular master thesis project and processes needed to be adjusted accordingly. In a more extensive time-frame, further research and features could have been performed. Another crucial thing to be mentioned is the ﬁnancial limitation. During the phase of determining the ﬁnal choices of subcomponents to be

7 CHAPTER 1. INTRODUCTION

implemented, some potential objects needed to be ignored due to their price tag. During the research, it became clear that the potential extent of this topic exceeded the limits of a master thesis. An example thereof is that researching hardware trustworthiness would alone provide enough content for extensive research. An expert reader might ﬁnd the results therefore slightly shallow. Nevertheless, this study provides an overview of the concept of trust and can be used as an entry point into further research.

1.5 Target Group

This study is aimed towards technical operators, whose responsibilities include implementation and maintenance of VPN solutions. Moreover, it might give new views on current IPsec solutions and may propose an alternative to them. Also, the architecture is mainly based on open-source units, which might be interesting to the open-source community. The design created in this study can be replicated and used to tunnel trafﬁc all over the world

1.6 Outline

After the literature review in 1.1 , the terminology found in section2 will clarify terms such as trust, trustworthiness, and others that are essential for deﬁning trust in third-parties and their products. Afterwards, chapter3, methodology, will introduce the concept of Design Science Research (DSR) and how exactly it will be applied in this study. Chapter4 will validate subcomponent choices and their level of trust. It will furthermore demonstrate an initial design of the functional artefact. Lastly, section5, implementation, documents the actual assembly and conﬁguration of the functional IPsec server architecture.

8 T ihrgrsto regards with a ouetto fteTEadtedvlpetpoesfreauto.Ciisagethat argue Critics evaluation. for process development theoreti- the requires and only TOE EAL1-EAL4 the that to of is able documentation be flaw cal to Another order institutions. in governmental label certified to but solely sold necessary, often be as are evaluation products see non-cost-effective; researchers, certification as CC well as the Symantec, as such products IT of seven of [ out one achieve can ToE’s Levels success, Assurance of Evaluation degree the on Depending requirements. functional named equivalent Criteria European the as well of as out Book”, developed CC standard. Germany, ISO/IEC France, became Canada, and the States, Kingdom United United the the and by Common Netherlands, developed utilizing the been by have is func- CC requirements is CC. security something short certain that evaluate Criteria, assurance to of way degrees One entirely validate intended. as and as classified define tioning be to can realistic system more no is reality, It In secure. reader means. the exactly requires “secure” subcomponents what untrusted understand on to based system secure a designing and Discussing Security and Assurance 2.1 between distinguish carefully to importance high of is It 15 .Ciiimhsbe eeldaantC yWlimJcsni i eoti 07 Vendors 2007. in report his in Jackson William by CC against levelled been has Criticism ]. rse optrSse vlainCriteria Evaluation System Computer Trusted edri eurdt cur neatudrtnigo h emnlg sdi hsstudy. this in used terminology the the systems, of understanding VPN exact untrusted an acquire and the to trusted understand required to understand is reader reader to the order helping In context, chapters. theoretical following provide to aims section his ISC.C novstsigthe testing involves CC (ITSEC). nomto Technology Information EL.Hge suac eesipyahge ereo security of degree higher a imply levels assurance Higher (EAL). I)security. (IT) agto Evaluation of Target 9 nomto ehooyScrt Evaluation Security Technology Information TSC,otnrfre oa h “Orange the as to referred often (TCSEC), rs,trustworthiness trust, T HEORETICAL TE oad it security sixty towards (ToE) and ,

C C HAPTER ONTEXT assurance 2 CHAPTER 2. THEORETICAL CONTEXT

evaluating a product solely on its paperwork is insufficient [23]. In the book from 1991 titled “Computers at Risk”, the predecessors of CC are mentioned, as well as guidelines on how to achieve a higher degree of assurance. Even though it was published twenty-six years ago, the procedure is still relevant. Assurance evaluation is divided into two stages: Design Evaluation and Implementation Evaluation. Evaluation of the design assures that the design is providing the necessary functionality. An external, qualified instance should perform this test. Detecting and correcting problems in the design phase is considered cheaper and less troublesome than in later stages, such as the implementation phase[24]. The vendor’s implementation of IPsec encryption devices is tested by laboratories, such as In- ternational Computer Security Association (ICSA), FIPS140-1-approved testing labs, or others. Often, cost-efficiency is the critical factor deciding if a product is certified or not. For this study’s prototype, this will not be possible due to cost reasons.

2.2 IPsec

VPNs can use different protocol suites to operate. Popular choices are Layer-2-Tunnelling- Protocol (L2TP), Openvpn, Secure Socket Tunnelling Protocol (SSTP), and IP security (IPsec). For this study, IPsec was chosen since it operates independent of the applications running on top. Furthermore, IPsec is the main standard for VPN defined in various documents of the IETF [25].Thus, it is preferable for organizations that have compliance responsibilities to a third party. IPsec was developed to add an additional security level on the IP protocol. In the Request For Command (RFC), defining the IPsec standard, the Internet Engineering Task Force (IETF) states the services as follows : “The set of security services offered includes access control, connectionless integrity, data origin authentication, detection and rejection of replays (a form of partial sequence integrity), confidentiality (via encryption), and limited traffic flow confidentiality” [26]. Problems with IPsec where identified when the German newspaper agency “Der Spiegel” published leaked documents. These leaked NSA documents show that the key exchange protocol embedded in IPsec, the Internet Key Exchanged (IKE), contains vulnerabilities. This may result in a leak of the symmetric keys used for encryption [27].Security researchers have analysed the document and stated that if correctly implemented, there is no risk in using IPsec. Correct implementation involves the usage of Perfect Forward Secrecy and avoidance of Pre-Shared Keys (PSK).

2.2.1 Symmetric vs. Asymmetric cryptography

The understanding of encryption algorithms is essential to understanding IPsec, including IKE. Encryption algorithms lay the foundation for authenticity, conﬁdentiality, and integrity in computer systems. Cryptographic algorithms can commonly be grouped into two categories: Public-key and Private-key, or asymmetric and symmetric algorithms. Symmetric keys utilize

10 2.2. IPSEC

a single private key that encrypts and decrypts data. It is imperative to protect the key at any costs, otherwise, the payload is endangered. A problem with symmetric key cryptography is that it does not scale on a system as the Internet, due to impracticalities of key distribution. Asymmetric cryptography solves this problem by utilizing a secret/private key and a public key. The public key can be published and stands in mathematical relation to the private key, in a way that authentication and encryption can be performed.

2.2.2 Key Exchange

In IPsec, keys can be exchanged out of band e.g. USB sticks, physical delivery, or via IKE protocol. Manual key exchange runs into problems of scalability if the number of communication partners increases. The scalable protocol IKEv1/IKEv2 utilizes Internet Security Association Key Management Protocol (ISAKMP) to establish the previously mentioned SA. Since this study focuses on embedding redundancy in mechanisms, one VPN tunnel will utilize IKEv2 while the other keys will be transported out of band. The reason for using IKEv2 over IKEv1 are improvements such as mobile support, NAT traversal, limitation to secure cryptographic properties, and DDoS resilience mechanisms.

2.2.3 Functionality of IPsec

The two main protocols are Authentication Header (AH) and Encapsulation Security Payload (ESP). AH only provides authentication, whereas ESP offers authentication as well as encryption. Hence, this study has the need for both which makes ESP the protocol of choice. The datagram of a regular IP packet differs from an IPsec packet. The exact differences between an IP and the IPsec ESP tunnel mode datagram can be seen in 2.1 taken from [28]. The payload of the normal IPv4 package is used to nest the encrypted IP and TCP header, as well as the payload along some other necessary values. Thus, a potential eavesdropper cannot see the content or the ﬁnal recipients IP address. In order to establish an IPsec tunnel between to hosts a Security Association is needed. A SA is the relation between IPsec peers and deﬁnes which security services (algorithms, protocols, etc.) are used for the connection. SAs can be seen as unidirectional policies. This can be explained the following: To initiate a two-way communication tunnel the server will offer the client a SA. If the client accepts this policy, he sends it back. A security association contains variables that are needed for a successful IPsec tunnel creation, such as a security parameter index (SPI), the destination address, if the connection will be based on the ESP or AH protocol, keys, and others. The SPI can be compared to port numbers in UDP or TCP based connections. It enables the receiving OS to identify the corresponding SA for an incoming packet and therefore on how to further process it [29]. IPsec can operate in two modes, namely transport mode and tunnel mode. Transport mode only encapsulates the payload of the raw IPv4 packet, whereas tunnel mode encapsulates the entire IP packet as well as its header. Therefore, tunnel mode VPNs are commonly installed on gateways, which act as tunnel entrance or exit.

11 CHAPTER 2. THEORETICAL CONTEXT

Figure 2.1: IP vs. IPsec datagram

After arrival of the packet, the IPsec frame gets stripped of the IP packet and delivered to the original destination address. This study will focus on a solution based on ESP in tunnel mode.

12 T Dsg cec eerhi o nomto ytm ora” h uhrage htDSR that argues author the Journal”, Systems Information Top in Research Science “Design Hrwr,O,Sfwr,Pooo/tnad)it n reat hr r ifrn oeson models different are There artefact. one into Protocol/Standards) Software, OS, (Hardware, o osrcueaDRsuy fe h ieauerve,tesxpae-oe fPfese al. et Peffers of six-phases-model the review, literature the [ After study. DSR areas a separated [ structure from to in technologies how live of we assembly and state design current the the is to study humanity this of led challenge construction, process, main structured reflection this where for a engineering, example with aeronautical An up building. as followed knowledge well for as force architecture, driving classical main of is one creation been The has trustworthiness. and subcomponent VPN is on a focus artefacts of high prototype a a with creating artefact, finally device and encryption designing is purpose project’s DSR.[ This as reasons. such multiple requires methodologies, This new globe. relatively the accept over all to happening academia progress is scientific mentioning of worth amount phenomena exponential helps currently Another DSR together. the that Systems elaborates Information further of He factors innovation. all drive combining further to needed indeed are publications [ projects science computer for applied be also projects should IT but while projects sciences, engineering solutions[ natural research and applicable social be on based to are tend tech- they information because traditional in is whether problems This solving around studies. to nology revolves approach argument elements preferable the Their the on necessarily DSR. decide are of to methodologies process order in the areas define different should from input that brought They DSR. of outline the 30 emdt etepeeal hiefrti td.I ossso h olwn hssthat phases following the of consists It study. this for choice preferable the be to seemed ] t utblt o cdmcI rjcs eerhr rmdfeetaeswr novdin involved were areas different from Researchers projects. and IT research academic science for design suitability describe its al. et. Peffers systems, information called management is of study this in applied method he 30 .Acrigt efr ta.ti scmol sdfor used commonly is this al. et Peffers to According ]. 13 einSineResearch Science Design 32 .DRfisti rjc for project this fits DSR ]. ] M DR.I h journal the In (DSR). ETHODOLOGY 31

.I i paper his In ]. C HAPTER 3 31 .The ]. CHAPTER 3. METHODOLOGY

need to be carried out sequentially, with potential re-initiation of previous activities in case their output was insufﬁcient.

3.1 Research Method

The process of DSR is summarized in the following activities that have been created by Peffers et al. [30]. The correlation of these studies will be explained in the respective activities below.

Activity 1: Problem identification and motivation In activity one it needs to be justified why the solution is meaningful for the academic world. It should motivate the researcher and audience to pursue the solution. Furthermore, the value for non-academical parties can be stated. Along the problem identification the problem is divided into task which will be solved during this study [30]. Sonnenberg and vom Brocke describe a similar activity involving practices such as literature review, assertion, and expert interviews as the “justification” activity [33]. They combine problem identification and objective definition into one phase. This study’s problem can be defined as follows: As mentioned before, the problem is that current IPsec devices e.g. firewalls, rely on a single layer of subcomponents. If a subcomponent is found to have a vulnerability, the entire system security relies on patching or other measures from third parties in order to keep the system secure. However, the priorities of vendors and consumers might not align, which puts the VPN device at risk. As 3.1 shows, this study approaches this problem by configuring

Figure 3.1: IPsec topology a site-to-site VPN architecture. In practice, it consists of two IPsec servers that are going to be designed to employ entirely different subcomponents. They will be conﬁgured to nest two IPsec tunnels towards each site. This means that an attacker must compromise both devices in order to break the system. This adds another layer of security. A vulnerability or backdoor in one server on any level will not necessarily result in the breach of the entire communication.

Activity 2: Definition of the objectives for a solution In activity two, objectives for the artefact must be defined. These objectives are based on the previous problem definition. This can only be performed with knowledge gathered from the literature review, along with a clear consid- eration of this studies scope [30]. The objectives defined below are the indicators for evaluation

14 3.1. RESEARCH METHOD

later in the study. The objectives for this project are the following: Firstly, the components and organizations used in this project will be investigated with regards to their trustworthiness, based on the justified and defined criteria in 1.1.1. The criteria score ranges from one to five, with five being considered very well satisfied. Sources for grading different subjects is based on material found throughout the research phase. The amount of available material found on public platforms, such as the Internet, Newspaper articles, and others differs from organization to organization. Secondly, the artefact should be designed, prototyped, and well documented. It is to be seen if performance, cryptographic functionality, and the general implementation satisfies the following frameworks:

1. IPsec Testing and Certiﬁcation Program Criteria Version 3.0" by the independent testing organization ICSA [34]

2. Simpliﬁed performance test according to the IETF draft "Methodology for Benchmarking IPsec Devices" [35]

Activity 3: Design and development In activity three, the artefact is designed and realized. An artefact is meant to be an object, model, method, or something else that embeds values for academia, as well as the industry. Questions on how functional requirements are satisfied are going to be answered. Peffers et. al further state that the design can only be moulded into the actual artefact by applying theory gathered in the literature research process [30]. The artefact of this study is going to be an IPsec VPN device. This is done by carefully selecting, installing, and configuring hardware, operating systems, IPsec applications, protocols, and cryptographic algorithms. The word “carefully” implies that the reasoning and justification is involved in the selection of components, as well as reasons for other design choices. In the beginning, this artefact will be a conceptual design. Afterwards, the implementation/development will be taking place. Here, it will be clear if the design can be applied in a practical context. Once a prototype is functional, activity four will be initiated.

Activity 4: Demonstration The demonstration phase, as defined by Peffers et al.[30] aims to validate if the artefact yields relevant results towards the problem definition. They mention that artefacts can be tested in experiments, case studies, or any other suitable activity. This activity can be correlated to the “prototyping and experimentation” activity of Sonnenberg et al. [33]. The demonstration will be an experiment that establishes a nested VPN tunnel. Success at this phase is defined by communication through the nested tunnels. In the case of sufficient results, the evaluation phase is initiated, and a deeper inspection focuses on the previously formulated objectives performed.

15 CHAPTER 3. METHODOLOGY

Activity 5: Evaluation Activity five is the activity that reveals the success of the study. According to Peffers et al. [30] phase five involves determining the level of satisfaction of the artefact towards the research questions. Objectives need to be brought in relation to the results. In activity two, trust evaluation criteria were defined in order to be able to measure the trustworthiness of the artefact. We can correlate the final “applicability check” phase of Sonnenberg and vom Brocke [33] to activity five of the paper of Peffers et al. [30]. In order to evaluate the level of trust of the artefact, values from each subcomponent will be accumulated to a final score. The score will be translated into a percentage value that reflects the level of trust. The higher this level is, the more trustworthy an artefact can be considered. Afterwards, the performance of the artefact is measured. It needs to be noted that the above- mentioned testing frameworks will not be used in their entirety due to their extensive structure. Only requirements with relation to the study objectives are going to be tested. In the respective sections, it will be explained why certain requirements might be relevant or irrelevant. The exact installation of the experiment will be explained in7

Activity 6: Communication Communication is only mentioned in the paper of Peffers et al. [30]. Not only researchers or security experts are intended to understand the relevance of it, but also decision makers with little to no technical background. This study will be revised by Combitech beforehand in order to prevent any leaks of even the slightest conﬁdential information. Afterwards, it will be available to the public on the Digitala Vetenskapliga Arkivet (DiVa).

3.2 Reliability and Validity

The results of this thesis are based on two main resources. The evaluation of trust can be seen as a starting point for a more in-depth analysis. Every subcomponent trust analysis could have filled the frame of an entire thesis project if performed thoroughly. Nevertheless, all information that has been gathered was proven to be accurate by its references. The evaluation itself was conducted as objectively as humanly possible. Still, unconscious, subjective influence is likely to be found in the results. The reader is encouraged to challenge and question the outcome of this evaluation. This builds the foundation for the rather practical part. Testing the artefact against the previously mentioned framework is also an extensive task by itself. Limiting the frameworks to the most essential part enabled the author to use a well thought-out testing methodology without potential unnecessary overhead. In the end, the target of evaluation is a prototype, not a commercial product that requires extensive CC evaluation. Performance tests have been executed in the same environment, shortly after each other in order to decrease non-IPsec related noise. Noise can be parallel traffic, high CPU usage, or others. This ensures that measured values can

16 3.3. ETHICAL CONSIDERATIONS

be compared to the best of the authors belief.

3.3 Ethical Considerations

This work was developed without the participation of research participants and therefore cannot harm their privacy or dignity. Persons mentioned in the report gave consent in being mentioned or are known as public personalities. Furthermore, all non-material resources towards this study can be found in the reference section at the end of the thesis. The thesis itself will be publicly available after being reviewed by Combitech for potential information leakage. Data and results presented in this study are either taken from other researchers, marked with a citation, or developed by the author of this thesis.

h orsodn ot sals unl ewe ahohr eutn nalyrdtunnel layered a in resulting other, each between tunnels establish hosts corresponding The olwd hsipista h rtdcso eovsaon h adae olwdb h OS, the by followed hardware, the was on. approach around so bottom-up revolves and a decision applications, problem, ﬁrst this the counter that to implies be order This cannot In followed. subcomponents compatible. best not the are consider; they to if important utilized behind also organizations currently the is and practicality products the of them, the evaluation in mentioned implemented previously be the all may Besides analyse that artefact. to alternatives necessary potential therefore evaluate is and It thoroughly algorithms. subcomponents and software OSs, hardware, on rely server VPN commercial All trust. of idea the around circles thesis This 4.1. medium in insecure seen be the can over like site-to-site look nested should a topology is the study how for about this order idea of in initial artefact The explained The architecture. choices. be IPsec design must the architecture understand general to the reader phase, the design the into diving Before iue41 Pe topology IPsec 4.1: Figure 19

C HAPTER D 4 ESIGN CHAPTER 4. DESIGN

4.1 Hardware

Hardware is the foundation of every computer system. As presented in the literature review in 1.1 there exist security issues on processors, RAM, graphics cards, and other parts. The main issue of this industry is its dependence on the chain-of-trust, upon which every intermediary party relies. Simply said, the majority of hardware is based on microcontrollers that are being fabricated by a few companies. If one of these vendors has a security bug in one of its products, the flaw cascades down to various end devices. An example of this was the ROGA vulnerability that created a cryptographic weakness. It was located in the software library RSALib of Infineon, a major micro controller vendor from Germany. According to the researchers of the paper, these affected millions of end devices [3]. A design decision for this study’s artefact is to base the VPN device on Single-Board-Computers. One reason behind this decision is that performance for small/medium sized businesses are likely to be satisfied while running capable SBCs. Common proprietary products of market leaders often come along with a considerable price tag, license costs, and service fees. Another idea is to case the two connected units into a single product of a small form factor. Baseline requirements for the selection process of SBCs are the following:

• CPU with minimum 2.0 GHz

• 2GB of RAM

• Gigabyte Ethernet

• Max. 200C/device

Furthermore, both SBCs should integrate different processor brands. Even though Spectre and Meltdown affect the majority of Intel, AMD, and ARM processors, the likelihood of all three types of processors falling victim to future vulnerabilities can be considered lower. During the hardware search, it became obvious that there were hardly any boards based on x86-processors that comply to the previously mentioned parameters to be found. The most promising board is the UDOOx86. UDOOx86 was developed by the company SECO in cooperation with Aidilab from Italy. It utilizes the Intel Celeron N3160 processor, hence not only SECO’s but also Intel’s level of trustworthiness needs to be examined. On the other device, the ODROID-XU4 board with an embedded ARM architecture is the preferred choice.

4.1.1 UDOOx86

The company behind UDOOx86 is SECO and based in Italy with branches in other countries. SECOs manufacturing is entirely in-house, from the design, hardware, software, and testing [36].This limits the risk for any problems in the supply chain from potential third party producers. Unfortunately, there are no security oriented reviews of the UDOOx86. On the other hand, there are no vulnerabilities to be found in any public vulnerability database. In terms of reputation,

20 4.1. HARDWARE

Pros Cons Transparency of board components (exclude No CC evaluation processor) Processor vulnerable to Spectre/Meltdown SECO with thirty years of business experi- vulnerabilities ence Integrity issues of Intel CPU according to In-house production -> control over entire [16] production process Quality Management Systems (ISO 9001:2008) certiﬁed Engaged in research and development

Table 4.1: Pros and cons of SECO and their product: UDOOx86

SECO appears to be focused on business rather than appearing in press. On the other hand, Intel is the market leader of CPUs with a market share of 78 percent. Intel receives considerable respect from the industry and has immense ﬁnancial resources to push innovative products. The Intel Transparent Supply Chain addresses the need for end users to track their parts and prevent malicious “dangerous fakes” to be implemented. Still, some vulnerabilities appear in Intel products. Over the last nineteen years, 103 vulnerabilities were registered in the vulnerability database of cvedetails.com [37]. Spectre and Meltdown, as well as the impenetrability of the Intel Management Engine (ME) mentioned in 1.1.2 have impacted the trustworthiness of Intel heavily. The problem is that due to the duopoly nature of the processor market gives little chance in buying components other than Intel or AMD. Leading vendors like Cisco are also using processors of Intel. This analysis of all attainable factors of SECO and UDOOx86 leads to the numeral score seen in 4.2

Criteria for Trust Score Structural Assurance 4 Competence 5 Benevolence 4 Integrity 3 Predictability 4 Total 20

Table 4.2: Trust Score for SECO/UDOOx86

21 CHAPTER 4. DESIGN

Pros Cons Transparency of board components (exclude No CC evaluation processor) Processor vulnerable to Spectre/Meltdown No known vulnerabilities of ODROID (ex- vulnerabilities clude processor) Little information about Hardkernel (even Active community in Korean) Passed EC declaration, meaning that the XU- No information about manufacturing process 4 is aligning with the technical drawings

Table 4.3: Pros and cons of Hardkernel and their product ODROID-XU4

4.1.2 ODROID-XU4

The second board of choice had to utilize a different processor. Also, since AMD processors rely on the x86-architecture, the search was narrowed down to ARM processors. After researching different products, the ODROID-XU4 was chosen. ODROID platforms are developed by Hardkernel co., Ltd, which is based in South Korea. Hardkernel supports the open source movements with its production and design process being completely transparent. On their Wiki page, information such as revision history, block diagrams, schematics, the board layout, and in-depth specifications can be found. Opening up the design strengthens the trustworthiness, since it is less likely that backdoors are hidden. Nevertheless, there is no definite proof of higher or lower level of trust with regards to closed- or open-source design choices [38]. In vulnerability databases, neither ODDROID or Hardkernel appear, which can an indicator of a secure product. As the processor of choice, engineers at Hardkernel decided to implement two Samsung processors. One Exynos5422 Cortex™-A15 with 2Ghz, plus a Cortex™-A7 Octa core. This concept is called ARM big.LITTLE, which aims to intelligently incorporate a powerful processor and a battery-saving processor into one. These CPUs are prone to the speculative execution and indirect branch predictions, just like the previously presented Intel processors. ARM processors for 64/32 Bit architecture were introduced in 2011 and are therefore relatively new. On CVE Details, only twelve vulnerabilities are registered, including Spectre and Meltdown. Historically, there were no scandals or major upsets found on the ARM holding. Nevertheless, ARM sells the architecture as intellectual property, in this case to Samsung, which may add any features they desire. The final processor can be referred to as a System on Chip (SoC). The ARM trust zone intends to establish trust in ARM platforms, but Johanna Rutkowska describes that vendors can change the ARM trust zone into something similar to Intel ME [8].In the end, this does not positively affect the trustworthiness. This analysis of all attainable factors of Hardkernel and ODROID-XU4 leads to the numeral score seen in 4.4

22 4.2. OPERATING SYSTEM

Criteria for Trust Score Structural Assurance 2 Competence 4 Benevolence 5 Integrity 4 Predictability 3 Total 18

Table 4.4: Trust Score for Hardkernel / ODROID-XU4

4.2 Operating System

On top of the hardware resides the operating system. When researching compatible operating systems, trust and security was of great importance. Unfortunately, it was not possible to receive free copies of Windows and Apple’s operating systems. It would have been of great interest using two completely different operating systems with regards to redundancy. Nevertheless, two Linux distributions with different origins were chosen. Firstly, RHEL version seven, which is based on the fedora distribution, as well as Debian Jessie. Next, these operating systems were analysed towards trust requirements deﬁned in 1.1.1.

4.2.1 RedHat Enterprise Linux

On the UDOOx86 board, the Linux enterprise solution RHEL provided by Red Hat will be installed. For developers, RHEL is free of charge but may not be used for commercial operation. This implies that the license of the artefact is in the case of productive use. Another option would be the use of a non-commercial operating system. RHEL is based on its predecessor Red Hat Linux, which was discontinued in 2003 in favour of RHEL. In 2016 RHEL version seven achieved common criteria certification on EAL 4+. Security functionalities in RHEL are auditing, cryptographic support, packet filtering, identification, authentication, discretionary access control, mandatory access control, security management, runtime protection mechanism, and Linux container framework support [39]. A CC evaluation is ensuring a high level of structural assurance. Red Hat supports Open Source software organizations in order to improve the quality of Open Source products. This way they utilize the fact that Open Source software is reviewed by many eyes. In return, Red Hat utilizes and hardens security of these products to use them in their enterprise solutions. Therefore, it can be said that RHEL products are partially open source. RHEL was used by the entirety of airlines, telecommunication, healthcare, and commercial banks in the Fortune 500 list in 2014 [40]. These areas have critical requirements for security. This consensus indicates strong competence within Red Hat and their product. Furthermore, RedHat utilizes reactive product security, which led to fast reaction towards critical vulnerabilities. In

23 CHAPTER 4. DESIGN

Pros Cons CC EAL 4+ evaluation Hardening, reﬁning of Open Source software Support of Open Source community not transparent Widely used in critical business area License costs Fast and transparent reaction towards vulnerabilities

Table 4.5: Pros and cons of RHEL v.7

RHEL version seven, 82 percent of all vulnerabilities were ﬁxed within one day [41].Documenting vulnerability management publicly indicates integrity and benevolence. RHEL releases new versions about every three to four years. Every version since ﬁve has ensured support for a minimal of ten years. This means that users can predict the near future of their operating system. This analysis of all attainable factors of RHEL v.7 yields the following numeral score seen in table 4.6

Criteria for Trust Score Structural Assurance 5 Competence 5 Benevolence 3 Integrity 5 Predictability 5 Total 23

Table 4.6: Trust Score for RHEL v.7

4.2.2 Debian Jessie

The operating system running on the ODROID-XU4 was Debian Jessie. One reason is that Debian is developed by users from all over the world; there is no company behind Debian that has any financial interest in adding unnecessary features. This strengthens the benevolence of Debian. Also, Debian states that they are not certified by CC or another organization due to cost reasons. Still, certain parts of the CC certification process are included in the Linux Testing Project (LTP), which is available for Debian. Releases of Debian come in three shapes: stable, testing, and unstable, with stable being the recommended version to use. The testing distribution, named ”frozen“ if considered mature enough. Frozen means that the development of new features is slowed down, sometimes completely. When the number of bugs is below the

24 4.3. IPSEC APPLICATIONS

Pros Cons Holistic approach of transparency No CC certiﬁcation Quality assurance process Strong community following ethical values Non-proﬁt

Table 4.7: Pros and cons of Debian maximum allowed limit, the frozen testing distribution becomes the new stable version [42]. This shows that developers of Debian are carefully inspecting and releasing their distribution, which supports structural assurance. To become a Debian Developer (DD), the community requires active work in some other form for the Debian project, e.g. maintenance of packages. This ensures that developers display some form of knowledge and competence, which supports the competence criterion. Unlike most companies, the developers also provide technical support, often leading to the user receiving help in less than ﬁfteen minutes. Integrity is provided by the open culture embedded in the Debian project. The entire structure of Debian can be seen on the website of the Debian operating systrem [43]. Furthermore, all sources are publicly available. The stability and consistency that can be found throughout Debian supports the last criteria: predictability. Users of Debian can expect the current testing version to be the next stable version. The summarized evaluation of Debian towards trust can be seen in table 4.7 This analysis of all attainable factors of Debian yields the numeral score seen in table 4.8

Criteria for Trust Score Structural Assurance 4 Competence 5 Benevolence 5 Integrity 5 Predictability 4 Total 23

Table 4.8: Trust Score for Debian

4.3 IPsec Applications

VPN server applications are the next building block on top of the OS. Two Linux-supporting VPN suites needed to be chosen. After researching potential candidates, the decision fell for strongSwan and Libreswan. The similar names of strongSwan and Libreswan might make it

25 CHAPTER 4. DESIGN

Pros Cons Holistic approach of transparency No CC certiﬁcation Implements the IKEv1 (RFC 2409) and IKEv2 (RFC 4306) Decreasing amount of vulnerabilities over the last versions years

Table 4.9: Pros and cons of strongSwan seem to the reader that they are related. The thought is not far-fetched, since they both originate from the discontinued FreeS/WAN IPsec project. Libreswan oriented itself closer to the original implementation, while strongSwan was completely rewritten. Hence, the redundant approach of this thesis is supported.

4.3.1 strongSwan strongSwan is an IPsec implementation that is completely OpenSource. Its roots lie in the discontinued FreeS/WAN project. The leading maintainer is Andreas Steffen, professor for security in communications and head of the Institute for Internet Technologies and Applications at the University of Applied Sciences Rapperswil in Switzerland. The entire architecture and source code is transparent, leading to increased integrity and benevolence. It is further supported by the open culture of issue tracking. strongSwan libraries are tested with Unit tests on a Kernel-based Virtual Machine (KVM) to assure the same environment for each test. Still, no other information about the actual development processes and certification can be found, which has a negative impact on structural assurance. strongSwan was analysed on the online platform Black Duck Open Hub (BDOH). Its results include contributors, vulnerabilities, commits, and more. Two metrics are calculated for each project that is being uploaded to BDOH: Security Confidence Index (SCI) and Vulnerability Exposure Index (VEI). Further information on the calculations of these values can be found on the BDOH website. strongSwan is an active project and scores better than average on the SCI and nearly perfectly on the VEI metric. These are indicators for competence as well as integrity of the development team. On OpenHub, it was established which developers did which commits. The main contributors are Tobias Brunner and Andreas Steffen with about six-hundred to seven-hundred commits over the past years. Both are highly proficient in developing security focused applications, including strongSwan, which yields high competence. strongSwan has been under development since 2005 and can be considered stable. Additionally, the support of the University of Applied Sciences Rapperswil is a positive indicator for predictability. This analysis of all attainable factors of strongSwan yields the following numeral score seen in table 4.10

26 4.3. IPSEC APPLICATIONS

Pros Cons High level of transparency No CC certiﬁcation Implements various RFC standards Open vulnerabilities found Few reported vulnerabilities Favorable security track-record

Table 4.11: Pros and cons of Libreswan

Criteria for Trust Score Structural Assurance 3 Competence 4 Benevolence 5 Integrity 5 Predictability 4 Total 21

Table 4.10: Trust Score for strongSwan

4.3.2 Libreswan

As described before, Libreswan also originated from the discontinued FreeS/WAN project. Just like strongSwan, Libreswan also has a highly transparent development culture. The source-code is published on their Github repository and updated continuously. Transparency automatically affects integrity positively. The authors of Libreswan can also be found on Github. Most commits are done by Paul Wouters, who has been actively involved in the FreeS/WAN project. This can be an indicator for competence. Nevertheless, very little information about the development is given. Similar to strongSwan, there are no policies or certifications stating the workflow of Libreswan, which has negative impact on structural assurance. However, Libreswan satisfies several RFC standards regarding IPsec, IKEv1, and IKEv2. Security vulnerabilities are reported on the website, linking to the official CVE vulnerabilities. This way, users can immediately see what potential problems could arise, which positively affects benevolence. On BDOH, Libreswan scored nearly perfect in the previously mentioned vulnerability analysis. The development team is constantly working on Libreswan, which can be concluded by inspecting the github repository. The maintenance of the sourcecode is predictable and steady, whereas announcements are solely distributed via a mailing list. This analysis of all attainable factors of Libreswan yields the following numeral score seen in table 4.12

27 CHAPTER 4. DESIGN

Criteria for Trust Score Structural Assurance 3 Competence 4 Benevolence 5 Integrity 5 Predictability 4 Total 21

Table 4.12: Trust Score for Libreswan

4.4 Cryptography

IPsec requires different cryptographic properties in order to be functional. One encryption algorithm for the en/decryption of packets (EA), a hash algorithm for satisfying integrity and authenticity needs (HA), Diffie-Hellman for key agreement (DH), and an asymmetric algorithm for authentication in the form of digital signing and verification (AA). These four groups were extracted from a CC evaluation document of a VPN device by the “Bundesamt für Sicherheit in der Informatik” [39]. Since there are two tunnels, two different cipher suites must be chosen while conducting a trust analysis. In the documentation of strongSwan supported cipher suites are mentioned. These are oriented to the published documents of the Internet Assigned Numbers Au- thority (IANA) [44]. Possible EAs are 3DES, Cast128, Blowfish, AES, Camellia, and Chacha20. All come with different key sizes and modes. Supported IAs are MD5, SHA-1, AES-XBC, AES-CMAC, AES-GMAC, and SHA-2. Different possible Diffie-Hellman groups are MODP, ECP, ECPBP, and Curve. Since AA algorithms are independent from the IPsec application, no ciphers are mentioned in the documentation of strongSwan. Regarding supported algorithms the Libreswan project refers to the RFC8221 titled “Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)” [45]. This document lists the following EAs: DES, 3DES, Blowfish, 3IDEA, DESIV32, AES, and CHACHA20. Mentioned HAs are MD5, SHA1, DES-MAC, KPDK-MD5, AESXCBC, AES-GMAC, and SHA-2. IKEv2 related specifications can be found in RFC8247, which is also mentioned on the Libreswan website [46]. Viable DH groups are MODP with different key lengths. Authentication algorithms are defined and are the following: RSA, Shared Key, DSS, ECDSA, and Digital Signature. As- sumptions on the security or vulnerabilities requires the correct implementation in software libraries using satisfying key lengths.

28 4.4. CRYPTOGRAPHY

Cryptographic property strongSwan Libreswan Encryption/Decryption AES AES 3DES 3DES Blowfish Blowfish Cast128 DES Camellia DES-IV32 CHACHA20 CHACHA20 3IDEA Integrity and Authenticity MD5 MD5 SHA-1 SHA-1 AES-XBC AES-XCBC AES-GMAC AES-GMAC AES-CMAC AES-CMAC SHA-2 SHA-2 DES-MAC KPDK-MD5 Diffie-Hellman Mode MODP MODP ECP NIST X25519 Signatures/Verification ECDSA ECDSA RSASSA-PSS* RSASSA-PSS DSS DSS

Table 4.13: Algorithm Choices

*"RSA Signature Scheme with Appendix-Probabilistic Signature Scheme"

4.4.1 ESP-Encryption Algorithms

The fact that strongSwan and Libreswan support encryption algorithms mentioned in 4.13 does not imply their robustness against cryptographic attacks. In the RFC documents mentioned before, only Advanced Encryption Standard (AES) and CHACHA20 are described as secure, currently as well as in the future. In a paper about insecurity of 64-Bit block ciphers, collision attack vulnerabilities of 3DES and Blowﬁsh are thematized [47]. DES is ruled out due to the small key size of 56-bit. These algorithms will not be considered as a design choice.

Camellia has been designed by researchers of Mitsubishi Electric and NTT in Japan. The robustness of the Japanese cipher is comparable to the AES, which will be presented later.

29 CHAPTER 4. DESIGN

Camellia has been standardized by respectable organizations/projects, such as International Organization for Standardization (ISO), New European Schemes for Signatures, Integrity, and Encryption (NESSIE), and the Internet Engineering Task Force (IETF). OpenSSL adopted Camel- lia in 2006 and provides it under an open-source license. Well-established projects, such as MIT Kerberos, FreeBSD, and strongSwan have added support for Camellia, which further strengthens structural assurance and competence. Also, Camellia was disclosed to the public, which enabled cryptographic researchers from all over the world to test it. This shows that the creators have nothing, such as a backdoor, to hide. The last updates on Camellias website date back to 2013 and leaves room for upcoming changes. This negatively affects predictability.

CHACHA20 is not to be broken at the time of this report. It was developed by Daniel J. Bernstein, security/cryptography researcher who is known from his court case titled “Bernstein v. United States”. Bernstein is involved in many alternative cryptographic projects, such as x25519, EdDsa, CHACHA20, and is actively criticizing privacy invading actions of the NSA and NIST. Accordingly, benevolence, predictability, and integrity were strengthened, having Bernstein as CHACHA20s main author. Predictability in the sense that it is hardly imaginable that Bernstein will agree with, or cooperate to full extent, the privacy invading actions performed by the NSA. Bernstein has published several papers in the area of cryptography, mathematics, and computa- tion. He works as a research professor at the University of Illinois and personal professor at the University in Eindhoven. Therefore, one can say that Bernstein is highly competent in the ﬁelds of cryptography, which directly affects his products mentioned before. So far, CHACHA20 has only been proposed to be standardized by the RFC 7634. Still, it is utilized as a replacement for RC4 in the TLS implementation of Google and OpenSSH and has been adopted in the random number generator of the Berkeley Software Distribution (BSD) operating systems. Therefore, structural assurance is not satisﬁed as the next algorithm to be inspected, AES[48].

Another well-known algorithm is AES. AES is defined as the official encryption standard for electronic data by NIST. The algorithm was formerly called Rijndael, named after its creators, and won AES selection competition held by NIST. Since then, it has become the standard for US governmental use. The competition involved structures and detailed analyses of the algorithms, which supports structural assurance and competence. Positive thoughts from Bruce Schneier, a renowned cryptographer, towards the transparency of the selection process supports the integrity of AES. Furthermore, AES is certified by CRYPTREC, and NESSIE, as no known practical attacks have been successfully launched. Nevertheless, it needs to be kept in mind that NIST is an organization closely linked to the NSA. This affects benevolence of AES, since the intentions of NIST are not one hundred percent interpretable. Since AES is the current standard, one can predict that any future problems with AES will be taken seriously by the cryptographic community. A problem with raw AES or AES-CBC is that it does not provide encryption authentication. As

30 4.4. CRYPTOGRAPHY

Matthew Green mentions in his article, missing encryption authentication poses a serious risk of eavesdropping or tampering packets sent between two communication partners. AES- GCM provides encryption authentication and has become a popular choice due to performance. Furthermore, Libreswan and strongSwan support AES. This analysis of all attainable factors yields the following numeral score seen in table 4.14

Criteria for Trust AES CHACHA20 Camellia Structural Assurance 5 3 4 Competence 5 4 4 Benevolence 3 5 4 Integrity 4 5 4 Predictability 5 4 3 Total 22 21 19

Table 4.14: Trust Score for AES, CHACHA20, Camellia

4.4.2 Integrity

Next, algorithms for integrity and authenticity need to be seeded out. RFC8221 states the insecurity of MD5, SHA-1, DES-MAC, KPDK-MD5, which is reason to remove them from closer selection in this study. The security of AES-XCBC relies on the underlying security of AES and targets Internet of Things (IoT) usage. AES-GMAC is the authentication-only variant of Galois/Counter Mode, which shares the same security properties. It may be used in RFC8221 compliant products, but no recommendations are given [45]. This leaves SHA as the only remaining choice as integrity algorithm for this study’s artefact. SHA was developed by the NSA, which automatically affects benevolence in a negative way. Nevertheless, the newest version SHA-3 was selected in a transparent multi-step process involving researchers from all over the world. Each round seeded out algorithms due to problems in cryptographic strength, applicability, or other factors. In the last round, only ﬁve contestants were left to be analysed [49].The selection process strengthens three criteria: Structural Assurance, Integrity, and Competence. SHA-2 is widely used by independent security-oriented software, such as Transport Layer Security (TLS), Secure Socket Layer (SSL), Pretty Good Privacy (PGP), Secure Shell (SSH), and others. Problematic is that SHA-2 is vulnerable towards length-extension attacks. The successor, SHA-3, is not exposed to any risks by today and will be implemented on both server variants. The trust analysis translates into the numerical values seen in 4.15

31 CHAPTER 4. DESIGN

Criteria for Trust SHA Structural Assurance 5 Competence 5 Benevolence 4 Integrity 5 Predictability 5 Total 24

Table 4.15: Trust Score for SHA

4.4.3 Difﬁe-Hellman Group

Modular Exponential (MODP) groups are for key exchanges in IKE. Most commonly used MODP groups are compliant towards standards from ISO, American National Standards Institute (ANSI), NIST, and IEEE and contain “safe” primes. They are defined in the RFC3526 document [50]. These groups are used to perform cryptographic calculations and can become the security bottleneck in any cryptographic procedure. In the NIST special publication 800-57 Pt. 1 Rev.4, a comparison of cryptographic algorithms can be found. It shows that the MODP group would need to be of size 15360-bit in order to be equivalent to the cryptographic strength of AES-256. AES-192 only requires a 7680-bit sized group. strongSwan only supports 8192-bit sized groups [5]. Luckily, AES-192 is still considered secure at the time of this study, but does not scale well, as clarified in the NIST special publication. Therefore, AES-256 will be utilized using a 8192-bit modulus group Libreswan supports MODP as well as Elliptic Curve Protocol (ECP) groups, created by NIST. ECP is considered cryptographically secure according to RFC8221. Nevertheless, respected cryptographers like Daniel J. Bernstein and Bruce Schneier do not trust the mathematical constants of NISTs ECP after the NSA-Dual_EC_DRBG backdoor scandal. Their thesis is supported by the analysis report of cryptographic requirements which labels NISTs ECP curves as “not safe” [51]. TThe last contestant, x25519, was developed by Daniel J. Bernstein who was previously mentioned. Accordingly, all statements towards the author of CHACHA20 can also be applied at x25519. Additionally, x25519 and its underlying elliptic curve offering became a considerable choice and is supported by various libraries, such as OpenSSL, LibreSSL, GnuTLs, and more. Curve25519 is now also defined in the NIST special publication 800-186 as well as RFC 7748. This standardization affects structural assurance of x25519 positively. Due to the concerns of Bruce Schneier, Bernstein and others, ECP will be ignored, which leaves MODP and x25519 as the only two remaining choices. Trust values which have been extracted from both DH-groups can be seen in 4.16

32 4.4. CRYPTOGRAPHY

Criteria for Trust MODP X25519 Structural Assurance 5 3 Competence 4 4 Benevolence 4 5 Integrity 4 5 Predictability 2 4 Total 19 22

Table 4.16: Trust Score for MODP and X25519

4.4.4 Digital signatures

Lastly, digital signature and verification algorithms are reviewed. After some of Bernsteins algorithms have already been reviewed, Ed25519 can be utilized for digital signatures. Ed25519 is a signature scheme based on EdDSA algorithm. It is documented in the Request for Comments (RFC) 8032 document and was first introduced in a paper in 2011 [52]. Besides general information about Ed25519, considerations about its robustness can be found in this document. There are several mechanisms in place to prevents attacks, such as side-channel leaks, randomness, and others. Ed25519 and EdDSA have been proven vulnerable to fault attacks, while simultaneously having excellent protection towards other attacks [53]. Ed25519 has a cryptographic strength that can be compared to RSA using a key length of about 3000 bits. On the other hand, it is a relatively new algorithm that has not been around for a sufficient amount of time for the cryptographic community to analyse it. Also, Ed25519 is not mentioned in the previously mentioned RFC 8247 document, which is the main indicator for structural assurance. RFC8247’s documents exclude Digital Signature Standard (DSS) from recommended algorithms. Hence, it will not be considered to be used for this study’s artefact. The most used algorithm for digital key signature is using Rivest–Shamir–Adleman, commonly known as RSA. RSA is an asymmetric algorithm, published in 1978, that is yet to be mathematically broken. Due to its low speed, RSA is used for digital signatures or the transmission of symmetric keys. RSASSA-PSS is a widely deployed digital signature scheme, which is based on the RSA algorithm [46]. Since one design decision was to deliver one key-pair out of band, a raw RSA will be the choice for this project. The previously mentioned concerns regarding the trustworthiness of ECP also affects the NIST product ECDSA. Even though ECDSA conforms to RFC 8247 and cryptographers’ endorsement on the mathematical properties, undocumented constants pose an advantage to NIST and the NSA breaking the algorithm [20].Since Ed22519 is a viable alternative, it will be the second choice, due to the earlier mentioned concerns of ECDSA. These facts can be condensed to numerical values in 4.17.

33 CHAPTER 4. DESIGN

Criteria for Trust RSA ECDSA EdDSA Structural Assurance 5 3 3 Competence 5 4 4 Benevolence 3 2 5 Integrity 4 3 4 Predictability 5 4 4 Total 22 16 20

Table 4.17: Trust Score for RSA, ECDSA, and EdDSA

After the seeding process, all but the EA group has been boiled down to two algorithms. In the case of EA algorithms AES will be used on one device, while CHACHA20 will be the second choice. The ﬁnal choice of algorithms, including key-lengths and sub-protocols can be seen in table 4.18

Cryptographic property strongSwan Libreswan Encryption/Decryption CHACHA20 AES-256-GCM-16 Integrity and Authenticity SHA-256HMAC-128 SHA-256HMAC-128 Difﬁe-Hellman Groups X25519 MODP8192 Signatures/Veriﬁcation EdDSA RSA-2048/4096

Table 4.18: Algorithm Choices

4.5 Finalized design

The ﬁnal design choices for the artefacts subcomponents can be seen in table 4.19

34 4.5. FINALIZED DESIGN

Hardware Device A Device B Device ODROID-XU4 UDOOx86 Processor Cortex-A15 + A7 Intel Celeron N3160 Operating System Debian Jessie RHEL Minimal IPsec application strongSwan Libreswan Key Exchange IKEv2 Out-of-band Cryptography Encryption/Decryption AES-256-GCM-16 Camellia/CHACHA20 Integrity/Authenticity SHA-256HMAC-128 SHA-256HMAC-128 Difﬁe-Hellman Groups X25519 MODP 8192 Signatures/Veriﬁcation EdDSA RSA-2048/4096

Table 4.19: Final design

This leads to the following topology.

35 CHAPTER 4. DESIGN

Figure 4.2: Architecture of the artefact

36 lo adaeseictos uha A,ntoksed n te aaees ih differ might parameters, other and speed, network RAM, as such specifications, hardware Also, h ups ftesrnSa Pe evri oatetct t er tlzn .0 certificates. X.509 utilizing peers its authenticate to is server IPsec strongSwan the of purpose The sfuddo h ocp ftut nodrt ofiuecrict-ae uhniain a was authentication, certificate certificate-based root commands: self-signed configure following a the to Therefore, issuing established. order created be In to had trust. (CA) of authority concept certification the on delegation founded trust of is concept their since Additionally, capabilities. authentication, cryptographic (PSK) stronger Key have Pre-Shared certificates a over chosen was authentication Certificate-based servers strongSwan the of Configuration 5.1 topology. shown to as refer previously to “right” the referred and on be “left” position will terms their servers The the RHEL-Right. and sections, RHEL-Left, following Debian-Right, the Debian-Left, In SBCs. on x86-processors. implementation on an run from to virtualized are machines the SBC, of Instead design. the from deviation I -i rvt/togwne.e --type private/strongSwanKey.pem --in 3650 --lifetime --ca --self pki > ipsec pem --outform 128 --size ed25519 --type --gen pki ipsec , , , → → → -otompm> pem --outform CA" CN=strongSwan O=strongSwan, cacerts/strongSwanCert.pem "C=CH, --dn ed25519 private/strongSwanKey.pem h reatwsipeetdi h ewr iuainsfwr N3 hslast a to leads This GNS3. software simulation refined network Therefore, be the time. to in in implemented likely arrive was an not artefact did step the SBCs first needed a the Unfortunately, only use. is productive proof-of-concept towards a as design the mplementing 37 I MPLEMENTATION

C HAPTER 5 CHAPTER 5. IMPLEMENTATION

In order to perform certificate-based authentication, each host requires a host certificate. There- fore, a private key was created and afterwards used to sign the host certificate. ipsec pki --gen --type ed25519 --outform pem > private/leftHostKey.pem ipsec pki --gen --type ed25519 --outform pem > private/rightHostKey.pem ipsec pki --pub --in private/left-host-key.pem | ipsec pki --issue --lifetime

, 730 --cacert cacerts/strongSwanCert.pem --cakey private/strongSwanKey.pem → , --dn "C=CH, O=Debian-left, CN=Debian-left.left.com" --san → , Debian-left.left.com --flag serverAuth --flag ikeIntermediate --outform pem → , > certs/leftHostKey.pem → ipsec pki --pub --in private/rightHostKey.pem | ipsec pki --issue --lifetime

, 730 --cacert cacerts/strongSwanCert.pem --cakey private/strongSwanKey.pem → , --dn "C=CH, O=Debian-left, CN=Debian-right.right.com" --san → , Debian-right.right.com --flag serverAuth --flag ikeIntermediate --outform → , pem > certs/rightHostCert.pem →

For strongSwan to find them, the certificates then needed to be moved into the defined directories. The CA certificate had to be moved to /etc/ipsec.d/cacerts/, host keys had to be moved to /etc/ipsec.d/private/, and lastly, the host certificates need to be stored in /etc/ipsec.d/certs/. The configuration files of both strongSwan servers can be seen in the snippet below. First, a default connection is defined. In the case where no parameters are overwritten, these settings are applied. strongSwan uses the terms “left” and “right”. “Left” is used to modify or define parameters of the host the configuration file is on. “Right” describes the peer to which the IPsec tunnel is created. Setting IDs ensures that only machines that use certificates with the IDs specified can establish a tunnel.

#Debian-Left conn host-to-host left=192.168.1.1 leftcert=leftHostCert.pem leftid=Debian-left.left.com right=192.168.6.1 rightid=Debian-right-host-cert.pem auto=add

#Debian-Right conn host-to-host left=192.168.6.1

38 5.2. CONFIGURATION OF THE LIBRESWAN SERVERS

leftcert=rightHostCert.pem leftid=Debian-right.right.com right=192.168.1.1 rightid=Debian-left-host-cert.pem auto=add

Lastly, strongSwan requires a link to the private key in the /etc/ipsec.secrets ﬁle.

5.2 Conﬁguration of the Libreswan servers

Before Libreswan can be configured, static IP addresses, routes, and IPv4-forwarding needed to be configured. The interested reader can find the entire setup-script in the appendix. Libreswan acts as a site-to-site VPN, routing traffic between the Debian servers. As described above, the inner tunnel utilizes raw RSA keys. These were created and stored for both hosts equally, using the following command: ipsec newhostkey --output /etc/ipsec.secrets

Furthermore, these keys needed to be mentioned in /etc/ipsec.conf as can be seen below:

#RHEL-left conn mytunnel leftid=@left left=10.255.255.2 rightid=@right right=10.255.255.1 authby=rsasig auto=add leftrsasigkey=PUTKEYHERE rightrsasigkey=PUTKEYHERE

#RHEL-right conn mytunnel leftid=@rightx left=10.255.255.1 rightid=@left right=10.255.255.2 authby=rsasig auto=add leftrsasigkey=PUTKEYHERE rightrsasigkey=PUTKEYHERE

sbfr, CPtafi a etbtenDba-etadDba-ih.Teitretdtraffic intercepted The Debian-Right. and Debian-Left between sent was traffic ICMP before,e As h reatwl edmntae yetbihn w etdIsctnes fewrs rfcis traffic Afterwards, tunnels. IPsec nested two establishing by demonstrated be will artefact The h rtEPpce noaohr l nal tcnb adta h eosrto hw htthe that shows demonstration the that said nesting be by can added it layer all, additional in an All by another. explained into be packet can packet’s ESP each This first that each. the is bytes difference 230 main to The increased identified. is be can size packets ESP only as similar, established. very was looks tunnel encrypted second regular the A Next, 6.2. bytes. figure 166 in of seen size be the can increased traffic has is packet intercepted packet the ICMP-request/response each Since of of medium. size excerpt insecure the An the parameters, bytes. specific over 62 IPsec transit by embeds in packet read IP be the expected, cannot of As and payload tunnel. ESP the the the through in sent enclosed traffic is ICMP traffic and the installed was servers Debian the between tunnel the Next, packet. ICMP per a bytes for 98 analysable of are size packets packet ICMP the without case, is that this Notable seen In eavesdropper. be possible. potential can is 6.1it analysis figure traffic On tunnel, established. a tunnel establishing the IPsec First, any attacker. without potential a analysed of is monitored eavesdropping is traffic the traffic simulates network This any RHEL-servers. process, the that During between tunnels. the through sent and generated iue61 a CPtraffic ICMP Raw 6.1: Figure 41 D EMONSTRATION

C HAPTER 6 CHAPTER 6. DEMONSTRATION

Figure 6.2: Trafﬁc after establishing one IPsec tunnel

Figure 6.3: Trafﬁc after establishing nested IPsec tunnels

artefact satisﬁes the basic functionality of IPsec.

42 . umrzdtutsoefrall for score trust Summarized 7.1 fewrs et ilb efre oeaut te ucs-eae criteria. success-related other evaluate to performed be will tests Afterwards, The met. been have objectives research the if determines activity evaluation the 3, in described As h rvosypromdtutaayi ntesbopnn snwt ebogtit context. into brought be to now is subcomponent the on analysis trust performed previously The hnar ic dqaeraoshv engvnfrte ntersetv sections. respective the in of them out for made given not been are have values reasons these of adequate Nevertheless, comprehension since research. authors air, the the thin during of found translation a been are has values that these data that mention to imperative is It architecture. IPsec the of trustworthiness of level the determine trust to completed order the in Initially, parameters. examined deﬁned is previous analysis on based evaluated be will artefact UDOOx86 Total RSA-2048/4096 8192 MODP SHA-256HMAC-128 AES-256-GCM-16 Libreswan RHEL7 al .:TutSoefrDvc 1 Device for Score Trust 7.1: Table 32 5 5 5 5 3 5 4 SA 43 33 5 4 5 5 4 5 5 C 28 4 4 4 4 5 3 4 B 30 4 4 5 4 5 5 3 I 30 5 2 5 5 4 5 4 P 153 23 19 24 23 21 23 20 Total E VALUATION C HAPTER 7 CHAPTER 7. EVALUATION

SA C B I P Total

ODROID-XU4 2 4 5 4 3 18 Debian Jessie 3 5 5 5 4 22 strongSwan 3 4 5 5 4 21 CHACHA20 3 4 5 5 4 21 SHA-256HMAC-128 5 5 4 5 5 24 X25519 3 4 5 5 4 21 EdDSA 3 4 5 4 4 20

Total 22 30 34 33 28 147

Table 7.2: Trust Score for Device 2

The trust scores of both devices are relatively close, with only a six point difference. This could be an indicator of a well-balanced distribution of trust. The biggest variation of criteria results between Device 1 (D1) and Device 2(D2) is structural assurance. While D1 scores thirty-two, D1 is only at twenty-two. This may be explained by the characteristics of the subcomponents chosen. D1 uses components that can be described as industry standards (RHEL7, AES, SHA, RSA), with only Libreswan being excluded. These “top dogs” are often extensively certiﬁed and tested to meet legal and customer requirements. D2 on the other hand focuses on trustworthy alternatives, including the usage of an alternative cipher suite that scores fourteen instead of the maximum of twenty points. The second biggest discrepancy is the benevolence score. With a nearly perfect score, D2’s components and its creators seem to communicate the security of their users as a leading goal. This is not the case for D1 since doubts about NIST and the NSA are lowering the cipher suites benevolence. Other criteria score rather close between both devices.

At best, a device could achieve 175 points. With 87,42 and 84 percent, both devices range in the top twenty percent, which is an indicator of a decent level of trustworthiness. The foundation for evaluating trust are resources that are publicly available. Unlike opensource and/or free projects such as strongSwan, Debian often provides extensive information about the project, documentation, and ethical values that others do not. Commercial choices, e.g. RHEL7, UDOOx86, are consistent in their documentations, since it helps them attract customers. Thus, the quality of a trust analysis is heavily affected. Another problem was to baseline trust criteria on different subcomponents. It proved difﬁcult to compare e.g. a commercially available hardware product, including producer, to a “simple” encryption algorithm. Therefore, special care has been taken on the selection of criteria.

44 7.2. IPSEC TESTING AND CERTIFICATION PROGRAM CRITERIA VERSION 3.0

7.2 IPsec Testing and Certiﬁcation Program Criteria Version 3.0

The ICSA testing guide is a testing guideline for IPsec products. In order to get a certiﬁcation, different requirements need to be met. Some of the requirements will be ignored or adjusted to meet the scope of this study. Requirements towards products are grouped as follows:

1. General

2. IKE

3. IKEv2

4. IPsec

5. Security Testing

6. Logging

7. Administration

8. Authentication using Certiﬁcates

9. IRAC

As mentioned in the testing program, vendors choose to test their product against either IKE or IKEv2. Since IKEv2 is the choice for this study’s artefact, only the IKEv2 conﬁguration will be evaluated. A holistic, methodical security test, as well as cryptographic analysis of the Linux kernel, is not feasible at the current state. However, it will be considered for after the thesis period. IRAC analysis will also be discarded due to its irrelevance towards the study.

7.2.0.1 IKEv2

The IKEv2 requirements are

1. Support of PSK authentication

2. Support of AES-CBC-256, SHA2-256, DH Group 14 key exchange

3. Support of proper responses to liveness checks

4. Acceptance of incoming requests with source ports other than 500/4500

PSK is supported by strongSwan and Libreswan, but as mentioned in section 2.2, it should be avoided. AES-CBC-256 can be used as requested, while AES-GCM is considered to have a higher performance and is therefore the standard of this study’s artefact [? ]. ]. Liveness checks are

45 CHAPTER 7. EVALUATION

supported by strongSwan and Libreswan as defined in RFC3706 and will be used in the finished artefact. This is done by adding dpdaction or dpddelay connection parameters in the respective ipsec.conf-files. Incoming requests with other source ports than the default ports can be accepted by defining it in the ipsec.conf file using ikeport=#portNumber. This concludes that the IKEv2 requirements are either met or have been changed due to explained reasons.

7.2.1 IPsec

The IPsec requirements are:

1. Support of tunnel mode

2. Support of AES-CBC-256 and SHA2-256

3. Rejection of replayed packet

This study’s artefact is designed to only run in tunnel mode. Furthermore, the cryptographic requirements are satisfied as described in the previous section. Replay protection exists by enabling the “replay-window” in the configuration files of strongSwan and Libreswan. This utilizes unique sequence numbers to prevent an attack.

7.2.2 Logging

Logging requires:

1. Capability to enable logging of IKE negotiation failures

2. Capability to log administrative access and conﬁguration changes

Both IPsec server applications as well as the two operating systems offer plenty of ways to configure logging and auditing mechanisms. strongSwan has logging capabilities based on levels. The administrator can choose a level to receive the amount of details he or she requires. Logging messages have tags that indicate from which system they originate. This includes configuration management as well as IKE. By default, basic auditing logs are displayed [54]. Libreswan includes barf, which displays IPsec encryption or authentication related information. The operating systems contain audit capabilities in order to detect changes to certain directories or files. These have not been configured, but it is strongly recommended to do so in the case of running the artefact in a productive environment. All in all, the logging requirements can be considered satisfied, since the guide mentions that the target of evaluation needs to have the capabilities, which is true in this case.

46 7.2. IPSEC TESTING AND CERTIFICATION PROGRAM CRITERIA VERSION 3.0

7.2.3 Administration

The only administrative requirement is the capability to enable cryptographically protected remote administration and to disable other remote administrative access [IRAC]. No remote administration has been conﬁgured since there has been no need for it so far. If remote administration is required in the future, it will be investigated at that point. This should be no problem since both Linux based operating systems have natively embedded SSH capabilities for doing so.

7.2.4 Authentication using Certiﬁcates

Requirements towards certiﬁcate-based authentication are:

1. Support RSA Signature authentication method with a key length of 2048 and using SHA2- 256. As shown in ?? this is satisﬁed by the artefact.

2. Support secure enrollment and installation of a certiﬁcate from an external CA

3. Support of certiﬁcate validation and rejection of IKE negotiation with a peer that presents a certiﬁcate that has:

a) expired or is not yet valid

b) an invalid signature

c) been revoked

Secure enrolment of certiﬁcates from external CAs is not implemented in the current state of the architecture, since only self-signed certiﬁcates are in use. Therefore, this requirement will be ignored.

4. Support one of the following methods to check certiﬁcate revocation status:

a) CRL retrieval via LDAP or HTTP

b) Certiﬁcate status checking via OCSP [RFC 2560]

Certificate validation is supported by strongSwan and Libreswan through configuring Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRL). Since all certificates of the prototype are created by the author, such a configuration was unnecessary.

5. Support of at least one of the following phase 1 ID types:

a) CD_IPV4_ADDR

b) ID_DER_ASN1_DN

c) ID_FQDN

47 CHAPTER 7. EVALUATION

d) ID_RFC822_ADDR

The default ID type deﬁned on the IPsec servers is a FQDN. Others are possible but will be discarded for now.

6. interoperate with dynamically addressed peers [IRAC] Due to the fact of a host-to-host based connection the interoperability with dynamically addressed peers is irrelevant for the sake of the artefact.

In order to be successfully certified, with either “IKE Basic” or “IKEv2 Basic”, the target of evaluation needs to meet the following requirements. If the artefact additionally satisfies the “Authentication using Certificates” requirement, an enhanced certification is awarded.

• General - not satisﬁed

• IKE or IKEv2 - IKEv2 satisﬁed

• IPsec - satisﬁed

• Security Testing - not satisﬁed

• Logging - satisﬁed

• Administration - satisﬁed

After applying the ICSA framework, it became clear that the entirety of the ICSA testing and certification program is currently not applicable by the current state of the artefact. Hence, not all requirements can be met. Also, the requirements of the ICSA certification program and the study do not align entirely with each other. Tests on IKE, IRAC, and parts of the general section are intended to be supported by the artefact and have no relevance towards the artefact’s current state. Thus, they have simply been discarded. Nevertheless, all congruent requirements have been satisfied or improved. This is an indicator supporting the design choices made by the author.

7.3 Performance

Performance related parameters defining the success of the artefacts are throughput, and latency. For both parameters, the same procedure is used. First, a baseline needs to be established. The baseline measures throughput and latency on an unencrypted channel. Afterwards, a tunnel between the inner servers is established and values measured. Then, the first tunnel is closed down. A tunnel will be established by the outer servers and traffic measured according to the previous procedure. Lastly, both tunnels are raised, and traffic is measured. The layered approach is expected to have a lower performance than a normal VPN set-up. In order to have comparable values for delay and throughput, a repeatable environment needed to be created.

48 7.3. PERFORMANCE

Further explanation is given in the subsections below. Screenshots of measured values can be found in the appendix. The tools iPerf3 and qPerf are used to measure the throughput between the Debian machines. The results from both tools were compared to detect application specific deviations. Both programs support the benchmarking of UDP and TCP traffic, which are likely to yield different results. It should be mentioned that the focus of the measurements is on the decrease of throughput by establishing IPsec tunnels and not the comparison between UDP and TCP traffic. Still, it seems necessary to measure both protocols. Both variants will be measured for twenty seconds to have comparable results. The results of the measurements TCP throughput were achieved by issuing iperf3 -c 192.168.6.1 -t 30. UDP was measured with the following command: iperf3 -c 192.168.6.1 -t 30 -u -b 1G The flag “-u” defines that the UDP packets should be sent while “-b” sets the bandwidth to 1G. The bandwidth for TCP traffic cannot be set manually and is always unlimited. Due to the fact that the virtualized network cards support a maximum of 1Gbit/second, this is the maximum possible. The results of the measurement can be seen below. qPerf permits to start multiple tests with only one command: qperf -t –use_bits_per_sec -v 192.168.6.1 tcp_bw udp_bw tcp_lat udp_lat. The last two flags indicate latency benchmarking, the results of which will be shown later. Results of the measurements can be seen in 7.3.

Mbit/s UDP-IPerf TCP-IPerf UDP-QPerf TCP-QPerf No Tunnel 67,8 120,0 73,1 123,0 RHEL Tunnel 68,1 86,9 75,4 91,0 Debian Tunnel 56,0 66,7 74,9 76,1 Both Tunnels 56,5 62,4 75 70,9

Table 7.3: Throughput result

Calculating the average throughput and taking it into account with regards to the baseline with no tunnels leads to the table 7.4

Mbit/s UDP TCP UDP-% TCP-% No Tunnel (Baseline) 70,4 121,5 100% 100% Libreswan Tunnel 71,75 88,95 102% 73% strongSwan Tunnel 65,05 71,4 92% 59% Both Tunnels 65,75 66,65 93% 55%

Table 7.4: Average Throughput in relation to baseline

49 CHAPTER 7. EVALUATION

Latency is measured by utilizing qPerf once more. This time, the parameter “bw” was changed to “lat” in order to measure latency: qperf -t –use_bits_per_sec -v 192.168.6.1 tcp_lat udp_lat As seen in 7.4, the throughput of UDP packets decreased by only seven percent after the installation of both tunnels. On the other hand, TCP traffic speed decreased by about forty-five percent. This is because UDP is a connectionless protocol. iPerf and qPerf are sending as many UDP packets as possible encrypting them on the way to the server. Another occurrence worth mentioning is the difference between the performance of both single tunnels. While using the Libreswan tunnel, throughput is only slowed by twenty-seven percent. The single strongSwan tunnel reduces it by forty-one percent. This is not necessarily related to the software itself, but possibly to the location of the IPsec server as well. More specifically, the routing functionality in RHEL servers is likely to be the cause for the additional loss of speed. The most significant result is that the nested IPsec structure slows the connection down by only four percent, which, compared to the single IPsec, is relatively insignificant.

In Table 7.5, the results of latency measurements are presented. Latency was measured with qPerf, as iPerf does not support built-in latency measurement. All latency measurement results are at ﬁfteen percent or below. It indicates that this study’s artefact affects the latency to a lower extent. The anomaly of decreasing latency when enabling the tunnel between the Debian machines can be disregarded, since it is likely caused by the experiment environment.

Latency UDP TCP UDP-% TCP-% No Tunnel 395us 370us 100% 100% RHEL Tunnel 449us 419us +14% +13% Debian Tunnel 375us 378us -5% +2% Both Tunnels 418us 426us +6% +15%

Table 7.5: Latency result

50 O h reatmgtntb stcnclyhree scmeca rdcsaalbe Nevertheless, available. products commercial as hardened technically as be not might artefact The eudnyo Pe unl sa prea twsi h einn fti td.Potentially, which study. problems, this cause of unpopularity. parameters beginning this other explain the and the might in traffic, on protocols, was topology, it information the as the of sparse variations why certain as questioned is is tunnels it IPsec Thus, throughput of architecture. less redundancy insignificantly tunnel yields single prototype a a current to to the security that compared IPsec shown elevate been industry. could has the study It in this level. players behind higher big idea by the or and research standards current industrial time, in Combining this identified At been choices. have technology cannot different thought adopting redundancy, this complete of idea the employs it Thoughts studies. future in refined 9.1. be section to in a needs mentioned be it are to evaluation, this intends trust on study of this area Since review. the literature into the point during starting found be to where endeavours such eea rmwrscnrdaon h oi ftuthv enaatdi re to no Currently, order organizations. in and Existing, adapted components been namely trust. evaluation, have assessing of trust targets in of different approach topic fit the analytical around an centred proposed frameworks study general this of part ne 51 D

ISCUSSION C HAPTER 8

T ihhgl estv aa uha elhcr,bnig n tes hsacietr a eof be can architecture this others, and banking, health-care, as such data, sensitive highly with h rsnainadcneun edakwl ercie taltrpiti time. in point later a at received be will feedback consequent and presentation The dealing ventures In security. of layer added an to comes throughput of loss minor relatively The auso ujc n oetal hneteresults. the change potentially and subject a of values u otesme ra,wihrslsi ag at fteSeihwresgigo holidays. on going workers Swedish the of parts Combitech large to in presented results not which was break, report, summer the the well to as due prototype, the date, this To interest. special communication. internet given a of security the increase knowledge to additional utilized offer be study may this and of topic results the resemble The about not alternative. does trusted it or security, IPsec secure with entirely problems an several addresses prototype the the though impact Even might research Future situation. that current mentioning the of worth snapshot is a It represents ME). currently evaluation (Intel are the black-boxed identiﬁed processors issues or major trust Current Meltdown) hardware. biggest (Spectre, on the vulnerable based of either is One artefact future. the near on the research in this many appear during that not security likely of will assurance where for holistic hoping the world, Unfortunately, are key whole. interconnected a a highly becomes as trustworthiness security the in-house, for In completely requirement held modules. be in cannot production tackled and further development be can which topic, ope hniiilyepce.Tuti Pe rohrcmue ytm sa expansive an is systems computer other or more IPsec became in process Trust evaluation expected. The initially trust. than of complex concept computer entire general the and IPsec, potentially to and regards systems, with trust about concerns several covered study his 53 C ONCLUSION C HAPTER 9 CHAPTER 9. CONCLUSION

9.1 Future research

As mentioned before, the trust analysis of this study may function as the foundation for more in-depth analysis of every subcomponent’s trust. Available literature mentioned in 1.1 has very promising results in different areas. Due to the reduction of parameters, the results of the evaluation were simpliﬁed. A suggestion for future endeavours could be the addition of additional criteria that are speciﬁcally aimed towards the relationship of organizations and their customers/users. A possible implementation on SBCs could be realized in order to see the potential implications for smaller or medium sized organizations. Unfortunately, this was not realizable at the time of writing. Another interesting project could be a case study with further detailed monitoring on performance using the architecture presented.

54 H cenht ftruhu measurement throughput of Screenshots r r oeo h cenht r otdwihmgtb eeatfrteinterested the for relevant be might which posted are reader. screenshots the of some are ere iueA1 D hogptn tunnel no throughput UDP A.1: Figure iueA2 C hogptn tunnel no throughput TCP A.2: Figure 1 A

PPENDIX A PPENDIX A A APPENDIXA.APPENDIXA

Figure A.3: UDP throughput with tunnel between RHEL machines

Figure A.4: TCP throughput with tunnel between RHEL machines

Figure A.5: UDP throughput with tunnel between Debian machines

Figure A.6: TCP throughput with tunnel between Debian machines

Figure A.7: UDP throughput with tunnel between both machines

2 Figure A.8: TCP throughput with tunnel between both machines

BIBLIOGRAPHY

[1] D. Gollmann, “Why Trust is Bad for Security,” Electronic Notes in Theoretical Computer Science, vol. 157, no. 3, pp. 3–9, 2006. [Online]. Available: http: //dx.doi.org/10.1016/j.entcs.2005.09.044

[2] M. Rogers and G. Eden, “The Snowden Disclosures, Technical Standards, and the Making of Surveillance Infrastructures,” International Journal of Communication, vol. 11, no. 0, p. 22, 2017.

[3] M. Nemec, M. Sys, P. Svenda, D. Klinec, and V. Matyas, “The Return of Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli,” 24th ACM Conference on Computer and Communications Security (CCS’2017), pp. 1631–1648, 2017. [Online]. Available: http://dl.acm.org/citation.cfm?doid=3133956.3133969{%}0A

[4] ISO/IEC, “International standard iso/iec 11889-1,” 2016.

[5] E. Barker, “Recommendation for Key Management – Part 1: General,” NIST Special Publication 800-57, pp. 1–142, 2016. [Online]. Available: http://nvlpubs.nist.gov/ nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf

[6] A. Martin and Others, “The ten page introduction to trusted computing,” Computing Labo- ratory, Oxford University Oxford, pp. 1–8, 2008.

[7] D. H. McKnight and N. L. Chervany, “What is Trust ? A Conceptual Analysis and an Interdisciplinary Model,” Proceedings of the 2000 Americas Conference on Information Systems AMCI2000 AIS Long Beach CA August 2000, vol. 346, p. 382, 2000. [Online]. Available: http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1876{&}context=amcis2000

[8] J. Rutkowska, “State considered harmful: A proposal for a stateless laptop,” 2015. [Online]. Available: http://blog.invisiblethings.org/papers/2015/state{_}harmful.pdf

[9] P. Kocher, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, and Y. Yarom, “Spectre Attacks: Exploiting Speculative Execution,” 2018. [Online]. Available: http://arxiv.org/abs/1801.01203

5 BIBLIOGRAPHY

[10] M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, S. Mangard, P. Kocher, D. Genkin, Y. Yarom, and M. Hamburg, “Meltdown,” 2018. [Online]. Available: http://arxiv.org/abs/1801.01207

[11] A. Waksman, “Producing Trustworthy Hardware Using Untrusted Components , Personnel and Resources,” 2014.

[12] V. Mavroudis, A. Cerulli, P. Svenda, D. Cvrcek, D. Klinec, and G. Danezis, “A Touch of Evil: High-Assurance Cryptographic Hardware from Untrusted Components,” 2017. [Online]. Available: https://arxiv.org/pdf/1709.03817.pdf

[13] J. J. V. Rajendran, O. Sinanoglu, and R. Karri, “Is Split Manufacturing Secure?” Design, Automation & Test in Europe Conference & Exhibition (DATE), no. Ic, pp. 1259 – 1264, 2013.

[14] Z. Chen, P. Zhou, T. Y. Ho, and Y. Jin, “How secure is split manufacturing in preventing hardware trojan?” Proceedings of the 2016 IEEE Asian Hardware Oriented Security and Trust Symposium, AsianHOST 2016, 2017.

[15] (ISO/IEC), “ISO/IEC 15408-3:2008 Information technology Security techniques — Evalua- tion criteria for IT security — Part 3: Security assurance components,” 2008.

[16] J. Rutkowska, “Software compartmentalization vs . physical separation ( Or why Qubes OS is more than just a random collection of VMs ),” 2014.

[17] J. Stafford, “Is third party certiﬁcation necessary?” Proceedings of the 4th ICSE Workshop on, pp. 1–5, 2001. [Online]. Available: http://scholar.google.com/scholar?hl=en{&}btnG= Search{&}q=intitle:Is+Third+Party+Certiﬁcation+Necessary+?{#}0

[18] J. M. Haddox, G. M. Kapfhammer, and C. C. Michael, “An approach for understanding and testing third party software components,” Proceedings of the Annual Reliability and Maintainability Symposium, pp. 293–299, 2002.

[19] M. Connely, M. Dontamsetti, P. Fulton, K. Gordon, R. Jones, T. Mathias, D. Smith, and J. Routh, “Appropriate Software Security Control Types for Third Party Service and Product Providers,” 2015.

[20] D. J. Bernstein, T. Lange, and R. Niederhagen, “Dual EC: A standardized back door,” Lecture Notes in Computer Science (including subseries Lecture Notes in Artiﬁcial Intelligence and Lecture Notes in Bioinformatics), vol. 9100, pp. 256–281, 2016.

[21] A. Bannier, N. Bodin, and E. Filiol, “Partition-Based Trapdoor Ci- phers,” 2016. [Online]. Available: https://www.researchgate.net/publication/ 303406502{_}Partition-based{_}Trapdoor{_}Ciphers

6 BIBLIOGRAPHY

[22] D. Adrian, K. Bhargavan, Z. Durumeric, P. Gaudry, M. Green, J. A. Halderman, N. Heninger, D. Springall, E. Thomé, L. Valenta, B. Vandersloot, E. Wustrow, and S. Z.-b. Paul, “Imperfect Forward Secrecy : How Difﬁe-Hellman Fails in Practice,” Ccs, pp. 5–17, 2015. [Online]. Available: https://weakdh.org/imperfect-forward-secrecy.pdf

[23] W. Jackson, “Under attack,” Tech. Rep., 2007. [Online]. Available: https://gcn.com/Articles/ 2007/08/10/Under-attack.aspx?Page=1

[24] N. R. Council, Computers at Risk: Safe Computing in the Information Age. Washington, DC: The National Academies Press, 1991. [Online]. Available: https: //www.nap.edu/catalog/1581/computers-at-risk-safe-computing-in-the-information-age

[25] IETF, “IP Security Protocol (ipsec).” [Online]. Available: https://datatracker.ietf.org/wg/ipsec/ documents/

[26] K. Seo and S. Kent, “Request for Comments: 4301 Security Architecture for the Internet Protocol,” 2005.

[27] National Security Agency, “Intro to the VPN Exploitation Process.”

[28] S. Friedl, J., “An Illustrated Guide to IPsec,” 2005.

[29] A. Mason, VPNs and VPN Technologies. Cisco Press, 2002. [Online]. Available: http://www.ciscopress.com/articles/article.asp?p=24833{&}seqNum=7

[30] K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A Design Science Research Methodology for Information Systems Research,” Journal of Management Information Systems, vol. 24, no. 3, pp. 45–77, 2007. [Online]. Available: http://www.tandfonline.com/doi/full/10.2753/MIS0742-1222240302

[31] B. Kuechler and S. Petter, “Design Science Research in Information Systems,” Design Science Research in Information Systems:, pp. 1–66, 2017. [Online]. Available: http://www.desrist.org/design-research-in-information-systems/

[32] P. B. Goes, “Design Science Research in Top Information Systems Journals By,” 2001.

[33] C. Sonnenberg and J. vom Brocke, “Practical Aspects of Design Science,” vol. 286, no. August 2014, 2012. [Online]. Available: http://link.springer.com/10.1007/978-3-642-33681-2

[34] ICSA, “ICSA Labs IPSec Testing and Certiﬁcation Program Criteria Version 3.0,” Tech. Rep., 2016.

[35] M. Kaeo, Double Shot Security, T. Van Herck, and Cisco System, “Methodology for Bench- marking IPsec Devices,” 2009.

7 BIBLIOGRAPHY

[36] SECO, “Manufacturing Unit: PSM.” [Online]. Available: http://www.seco.com/en/what-we-do

[37] M. cooperation, “Intel : Vulnerability Statistics,” 2018. [Online]. Available: https: //www.cvedetails.com/vendor/238/Intel.html

[38] A. Boulanger, “Open-source versus proprietary software: Is one more reliable and secure than the other? &,” 2005.

[39] Bundesamt für Sicherheit in der Informationstechnik, “Certiﬁcation Report BSI-DSZ-CC- 0511-2008,” Tech. Rep., 2008.

[40] Red Hat Inc., “Tried. Tested. Trusted.” 2017. [Online]. Available: https://www.redhat.com/ en/about/trusted

[41] ——, “Security Data.” [Online]. Available: https://www.redhat.com/security/data/metrics/

[42] Debian, “Debian Releases,” 2017. [Online]. Available: https://www.debian.org/releases/

[43] ——, “Debian’s Organizational Structure,” 2016. [Online]. Available: https://www.debian. org/intro/organization

[44] IANA and T. Kivinen, “Internet Key Exchange Version 2 (IKEv2) Parameters,” 2018. [Online]. Available: https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml

[45] P. Wouters, Red Hat Inc., D. Migault, J. Mattson, Ericsson, Y. Nir, Check Point, and T. Kivi- nen, “RFC 8221 - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH),” 2017.

[46] Emc, Dell, and T. Kivinen, “RFC 8247 - Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2),” 2017.

[47] K. Bhargavan, “On the Practical (In-) Security of 64-bit Block Ciphers Collision Attacks on HTTP over TLS and OpenVPN,” Ccs 2016, pp. 456–467, 2016. [Online]. Available: https://eprint.iacr.org/2016/798{%}0Ahttps://eprint.iacr.org/2016/798.pdf

[48] D. J. Bernstein, “Curriculum vitae.” [Online]. Available: https://cr.yp.to/cv.html

[49] S.-j. Chang, R. Perlner, W. E. Burr, J. M. Kelsey, and L. E. Bassham, “Third-Round Report of the SHA-3 Cryptographic Hash Algorithm Competition NISTIR 7896,” US Department of Commerce, National Institute of Standards and Technology, pp. 1–84, 2012. [Online]. Available: http://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7896.pdf

[50] T. Kivinen and M. Kojo, “More Modular Exponential (MODP) Difﬁe-Hellman groups for Internet Key Exchange (IKE),” Tech. Rep., 2003. [Online]. Available: https://www.rfc-editor.org/info/rfc3526

8 BIBLIOGRAPHY

[51] D. J. Bernstein and T. Lange, “SafeCurves: choosing safe curves for elliptic-curve cryptography,” 2017. [Online]. Available: https://safecurves.cr.yp.to

[52] D. J. Bernstein, N. Duif, T. Lange, P. Schwabe, and B.-Y. Yang, “High-Speed High-Security Signatures,” 2011. [Online]. Available: http://link.springer.com/10.1007/ 978-3-642-23951-9{_}9

[53] Y. Romailler and S. Pelissier, “Practical fault attack against the Ed25519 and EdDSA signature schemes,” 2017.

[54] J.-P. Lang, “Logger Conﬁguration.” [Online]. Available: https://wiki.strongswan.org/projects/ strongswan/wiki/LoggerConﬁguration

ABSTRACT