Vttls: a Vulnerability-Tolerant Communication Protocol

Home , Biclique attack, Multiple encryption

vtTLS: A Vulnerability-Tolerant Communication Protocol

André de Matos Joaquim

Thesis to obtain the Master of Science Degree in Information Systems and Computer Engineering

Supervisors: Professor Miguel Nuno Dias Alves Pupo Correia Professor Miguel Filipe Leitão Pardal

Examination Committee Chairperson: Professor António Manuel Ferreira Rito da Silva Supervisor: Professor Miguel Nuno Dias Alves Pupo Correia Member of the Committee: Professor Nuno Fuentecilla Maia Ferreira Neves

November 2016 2 Acknowledgments

First of all, I would like to thank God for the gift of Life and for the strength He gave me to overcome the difficulties and remain strong during my journey to become a Master. Secondly, I would like to thank my girlfriend, Filipa, for the endless support, caring, and understanding. I would like to thank my whole family, my friends, especially the ones I met in college. I was not intending to mention anyone because I am afraid that I miss someone, but here it goes, by alphabetical order: Andre,´ Diogo L., Diogo R., Gonçalo, Joao˜ A., Joao˜ C., Manuel, Miguel, Pedro B., Pedro L., Pedro R., Pedro V., Rafael, Rita, and all the others who crossed paths with me during the last five years. Finally, I would like to thank Grupo de Jovens da Arrentela, an amazing group that has always supported me when I needed. I would like to express my deepest appreciation to my supervisors, Professor Miguel Correia and Professor Miguel Pardal. Your amazing guidance, support, and teaching have been an inspiration to me. You were without a doubt the best supervisors I could have ever asked for, and I just wish you for the best. I would also like to thank my fellow Masters’ colleagues Diogo, Filipe, and Karan. This journey would not have been the same without your support and camaraderie. This work was supported by the European Commission through project H2020-653884 (SafeCloud) and by national funds through Fundaçao˜ para a Cienciaˆ e a Tecnologia (FCT) with reference UID/CEC/50021/2013 (INESC-ID).

3 4 Abstract

VTTLS is a diverse and redundant vulnerability-tolerant communication protocol. There are often concerns about the strength of some of the encryption mechanisms used in SSL/TLS channels, with some regarded as insecure at some point in time. These mechanisms play a massive role in network security, including cloud computing and infrastructures. VTTLS is our solution to mitigate the problem of secure communication channels being vulnerable to attacks due to unexpected vulnerabilities in its mechanisms. It is based on diversity and redundancy of cryptographic mechanisms and certiﬁcates to ensure a secure communication even when one or more mechanisms are vulnerable. VTTLS relies on a combination of k cipher suites which ensure that even if k − 1 cipher suites are insecure or vulnerable, the communication channel remains secure due to the remaining secure cipher suite. We evaluated the performance and cost of VTTLS by comparing it to a recent TLS implementation, OpenSSL.

Keywords: Security protocols; Secure communication channels; Diversity; Redundancy; Vulnerability- Tolerance; Transport Layer Security protocol

5 Resumo

VTTLS e´ um protocolo de comunicaçao˜ diverso, redundante e tolerante a vulnerabilidades. Exis- tem preocupaçoes˜ acerca da segurança de alguns dos mecanismos de cifra usados em canais de comunicaçao˜ SSL/TLS, sendo que alguns desses mecanismos foram considerados inseguros. Estes mecanismos temˆ um papel importante na segurança de redes de comunicaçao,˜ inclu´ındo computaçao˜ na nuvem e infraestruturas. VTTLS e´ a nossa soluçao˜ para mitigar o problema de canais de comunicaçao˜ seguros serem vulneraveis´ a ataques devido a vulnerabilidades inesperadas nos seus mecanismos de encriptaçao.˜ E´ baseado na diversidade e redundanciaˆ de mecanismos criptograficos´ e certificados para assegurar uma comunicaçao˜ segura mesmo quando um ou mais mecanismos estao˜ vulneraveis.´ VT- TLS utiliza uma combinaçao˜ de k conjuntos de mecanismos que garantem que, mesmo quando k − 1 conjuntos de mecanismos sao˜ inseguros ou vulneraveis,´ o canal de comunicaçao˜ permanece seguro devido ao conjunto de mecanismos remanescente. Avaliou-se o desempenho e custo do VTTLS com- parando os resultados com o OpenSSL, uma implementaçao˜ recente de um canal TLS.

Palavras-chave: Protocolos de seguranc¸a; Canais de comunicac¸ao˜ seguros; Diversidade; Redundancia;ˆ Toleranciaˆ a vulnerabilidades; protocolo Transport Layer Security

6 Contents

1 Introduction 13 1.1 Contributions...... 15 1.2 Overview...... 15 1.3 Publications...... 15

2 Background and Related Work 17 2.1 Diversity in Security...... 17 2.1.1 N-version Programming...... 18 2.1.2 Moving-target Defenses...... 19 2.1.3 Proﬁle-guided Automated Software Diversity...... 19 2.2 SSL/TLS Protocol...... 20 2.2.1 Brief History...... 20 2.2.2 TLS Handshake Protocol...... 21 2.2.3 TLS Record Protocol...... 23 2.2.4 TLS Conﬁguration Variants...... 23 2.2.5 TLS Vulnerabilities...... 24 2.3 Vulnerabilities in Cryptographic Mechanisms...... 26 2.3.1 Public-key Cryptography...... 27 2.3.2 Symmetric Cryptography...... 27 2.3.3 Hash Functions...... 29 2.4 Combining Cryptographic Mechanisms...... 30 2.4.1 Hybrid Encryption...... 31 2.4.2 Multiple Encryption...... 31

3 Vulnerability-Tolerant TLS 33 3.1 Protocol Speciﬁcation...... 33 3.2 Combining Diverse Cipher Suites...... 36 3.2.1 Hash Functions...... 36 3.2.2 Public-key Encryption Mechanisms...... 37 3.2.3 Symmetric-key Encryption Mechanisms...... 38 3.3 Implementation...... 40

7 4 Experimental Evaluation 45 4.1 Performance...... 45 4.1.1 Handshake...... 46 4.1.2 Data Communication...... 46 4.2 Cost...... 48

5 Conclusion 49 5.1 Future work...... 49

Bibliography 51

8 List of Tables

2.1 Key exchange algorithms supported by TLS 1.2...... 24 2.2 Symmetric-key cipher algorithms supported by TLS 1.2...... 24 2.3 Algorithms supported by TLS 1.2 to check data integrity and authenticity...... 25

3.1 VTTLS hash functions’ diversity metrics...... 36

3.2 VTTLS hash functions’ known attacks...... 37

3.3 VTTLS public-key encryption functions’ diversity metrics...... 38

3.4 VTTLS public-key encryption mechanisms’ known attacks...... 38

3.5 VTTLS symmetric encryption mechanisms’ diversity metrics...... 39

3.6 VTTLS symmetric encryption mechanisms’ known attacks...... 39

4.1 Comparison of average Handshake length...... 46

4.2 Comparison between the time to send a message using VTTLS and OpenSSL...... 47

4.3 Comparison between the time to receive a message using VTTLS and OpenSSL..... 47 4.4 Comparison between the message sizes...... 48

9 10 List of Figures

2.1 Sequence diagram of the TLS Handshake Protocol, adapted from Section 7.3 of [27]... 21

3.1 VTTLS Handshake messages using diversity factor k...... 35

3.2 VTTLS API: Additional functions in relation to the OpenSSL API...... 41

3.3 First four steps regarding the ordering of the encryption and signing of VTTLS using a diversity factor k = 2...... 42

3.4 Remaining three steps regarding the ordering of the encryption and signing of VTTLS using a diversity factor k = 2. Here is represented the second signing and the second encryption, employing diversity and redundancy in the communication...... 43

4.1 Comparison between the time it takes to send and receive a message using VTTLS and OpenSSL...... 46

11 12 Chapter 1

Introduction

Secure communication protocols are fundamental building blocks of the current digital economy. Trans- port Layer Security (TLS) alone is responsible for protecting most economic transactions done using the web, with a value so high that it is hard to estimate.

These protocols allow entities to exchange messages or data over a secure channel on the Inter- net. A secure communication channel has three properties: authenticity, confidentiality, and integrity. Regarding authenticity, in an authenticated channel no one can impersonate the sender. Regarding confidentiality, in a confidential channel, only the receiver of the message is able to read that message. Finally, regarding integrity, the messages cannot be modified without the receiver detecting it.

Several secure communication channel protocols exist nowadays, with different purposes but with the same goal of securing communication. TLS is a secure communication protocol widely used. Orig- inally called Secure Sockets Layer (SSL), its ﬁrst standard was SSL 2.0, released in 1995. SSL 3.0 was released in 1996, bringing improvements to its predecessor such as allowing forward secrecy and supporting SHA-1. Deﬁned in 1999, TLS 1.0 introduced the support for extensions in the Client and Server Hello messages, among other changes. These changes were enough to make TLS 1.0 incompatible with SSL 3.0. In order to provide compatibility, a TLS 1.0 connection can be downgraded to SSL 3.0, which raises security concerns. TLS 1.1 and TLS 1.2 brought improvements such as mitigating cipher block chaining (CBC) attacks and supporting more block cipher modes to use with the Advanced Encryption Standard (AES).

Other two secure communication protocols are Internet Protocol Security (IPsec) and Secure Shell (SSH). IPsec is a network layer protocol that protects the communication at a lower level than SSL/TLS [1]. It is an extension of the IP protocol that contains two sub-protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP). SSH is an application-layer protocol used for secure remote login and other secure network services over an insecure network allowing for remote interactive shell, ﬁle copying, and more [2]. Both these protocols are used for more restrict purposes, while SSL/TLS is used by almost every person daily while accessing the Internet.

Such a secure communication protocol becomes insecure when a vulnerability is discovered. Vul- nerabilities may concern the protocol’s speciﬁcation, the cryptographic mechanisms used or speciﬁc

13 implementations of the protocol. Many vulnerabilities have been discovered in SSL/TLS originating new versions of the protocol with new security features such as deprecating cryptographic mechanisms or enforcing security measures. Concrete implementations of SSL/TLS have been also found vulnerable due to implementation bugs, causing security breaches and affecting devices worldwide.

VTTLS is a protocol proposed in this work that provides vulnerability-tolerant communication channels. Its acronym stands for Vulnerability-Tolerant Transport Layer Security. These channels are characterized by not relying on individual cryptographic mechanisms, so that if one is found vulnerable (or possibly a few of them) the channels still remain secure. The idea is to leverage diversity and redundancy of cryptographic mechanisms and keys, i.e. the use of different and more than one set of mechanisms and keys, respectively. More clearly, diversity is employed in the following aspects:

• Pair certiﬁcate/private key;

• Key exchange mechanism;

• Authentication mechanism;

• Encryption mechanism;

• Message Authentication Code (MAC).

This use of diversity and redundancy is inspired in previous works on diversity in security [3,4], moving-target defenses [5], and computer immunology [6].

In the context of VTTLS, diversity and redundancy consist in using two or more different mechanisms with the same objective. For example, SHA-1 and SHA-3 are both hash functions that may be used to generate message digests. If used redundantly and SHA-1 eventually becomes insecure, VTTLS would rely upon SHA-3 to keep the channel secure.

VTTLS is configured with a parameter k, the diversity factor (k > 1). This parameter indicates the number of different cipher suites and different mechanisms for key exchange, authentication, encryption, and signing. We expect k to be usually small, e.g., k = 2 or k = 3. Vulnerabilities, including zero-day vulnerabilities which cannot be removed as they are unknown [7], do not appear in large numbers in the same components and efficiency and performance issues must be addressed. Although TLS supports strong encryption mechanisms such as AES and RSA, there are factors beyond mathematical complexity that can contribute to vulnerabilities. Diversifying encryption mechanisms includes diversifying certificates and consequently keys (public, private, shared). The individual who configures the channel, can explicitly state which cipher suites to be used. VTTLS can also determine a good combination of cipher suites if no combination is configured. Diversity of certificates is a consequence of diversifying encryption mechanisms due to the fact that each certificate is related to an authentication and key exchange mechanism. Managing the diverse certificates and private keys may not be trivial when configuring VTTLS to use a high diversity factor. Nevertheless, with the predicted diversity factor, managing the pairs certificate/private keys should not represent a challenge.

14 VTTLS aims at protecting mainly against zero-day vulnerabilities and weak or unexpectedly insecure cryptographic mechanisms. While it may prevent such vulnerabilities, VTTLS probably does not protect against version downgrade attacks (only by not allowing weak mechanisms) and speciﬁc implementation vulnerabilities.

VTTLS was developed in the context of SafeCloud, an European project started in September 2015. This project aims at providing a complete solution to address privacy in cloud computing and infrastructures. Despite all their advantages and importance, cloud infrastructures raise privacy, integrity, and security of data storage and processing tasks issues. These concerns are not yet satisfactorily addressed by existing technologies. SafeCloud’s objective is to investigate and provide a secure communication despite the existence of powerful adversaries.

1.1 Contributions

The main contribution of this thesis is VTTLS, a new protocol for secure communication channels that uses diversity and redundancy to tolerate vulnerabilities in cryptographic mechanisms. It also presents and experimental evaluation of the protocol and shows that it has an acceptable overhead in relation to the TLS implementation in which our prototype is based, OpenSSL v1.0.2g [8]. A VTTLS channel takes, in average, 22.88% longer to send a message than an OpenSSL channel. This is considered an acceptable overhead considering non-timely critical applications. Also, the additional cost of managing and acquiring k − 1 more certiﬁcates is not considered signiﬁcant considering the increase in security and vulnerability tolerance provided by VTTLS.

1.2 Overview

The rest of the document is organized as follows. Chapter2 presents the background and related work.

Chapter3 presents the VTTLS protocol and its implementation. Chapter4 presents the experimental evaluation. Chapter5 concludes the document.

1.3 Publications

This work was partially published as: vtTLS: A Vulnerability-Tolerant Communication Protocol Andre´ Joaquim, Miguel L. Pardal, and Miguel Correia Proceedings of the 15th IEEE International Symposium on Network Computing and Applications (NCA 2016)

15 16 Chapter 2

Background and Related Work

This chapter presents related work on diversity and redundancy in security, provides background information on TLS, discusses vulnerabilities in cryptographic mechanisms and protocols, and provides insight on combining cryptographic mechanisms. Section 2.1 refers to arguments presented by several researchers defending the use of diversity in security and some approaches on how to employ this diversity. Section 2.2 describes the SSL/TLS protocol and its layers, and discusses some vulnerabilities of this protocol. Section 2.3 discusses vulnerabilities in the most used cryptographic mechanisms and the changes made in order to correct those vulnerabilities. Section 2.4 shows how combining encryption mechanisms can be useful in order to increase the security of the ﬁnal encryption mechanism.

2.1 Diversity in Security

The term diversity is used to describe multi-version software in which redundant versions are deliberately created and made different between themselves [3]. Without diversity, all instances are the same, with the same implementation vulnerabilities. Using diversity it is possible to present the attacker different versions, hopefully with different vulnerabilities. Diversity targets mostly software implementation and the ability of the attacker to replicate the user’s environment. Nevertheless, diversity does not change a program’s logic, so it will not be helpful if a program is badly designed. According to Littlewood and Strigini, multi-version systems on average are more reliable than those with no versions. They also state that the key to achieving effective diversity is to make the different programs the least dependent on one another. Therefore, attention is needed when choosing the diverse versions. The trade-off between individual quality and dependence needs to be assessed and evaluated, as it impacts the correlation between version failures. The best possible effect of diversity would be when the there is no possibility of common failure between versions. There are two main decisions which a programmer has to make while implementing diversity – when does he introduce diversity and what should he diversify [9]. There are many opportunities to introduce

17 diversity during software’s life cycle: earlier, in the implementation phase; later, when patches and updates are applied; or somewhere in the middle. Different approaches in implementing diversity use different entry points for diversity and introduce diversity in distinct ways. These are key design decisions as they can affect the performance and the level of security and determine if diversity is applied to binary or source code. In practice, each programmer has his coding style and his favourite libraries, algorithms or design patterns. Diversity can exploit this property by randomising software implementations in order to dis- mantle attacks. Forrest et al. studied analogies between immunology and computer systems proposing the creation of multiple distributed detectors to attempt detecting malicious code [6]. This kind of detectors is classi- ﬁed as reactive defenses, as they are structured to scan for abnormal behaviour. The same authors also claimed that introducing diversity in a deliberate fashion into computer systems can make them more robust to replicated attacks [10]. Earlier Avizienisˇ and Chen introduced N-version programming (NVP) [11] (see Section 2.1.1). There is some work on obtaining diversity without explicitly developing N versions [12]. Garcia et al. show that there is enough diversity among operating systems for several practical purpose [4]. Homescu et al. use proﬁle-guided optimization for automated software diversity generation [13] (see Section 2.1.3). Trans- parent runtime randomization dynamically and randomly relocates program’s parts to provide different versions [14]. Proactive obfuscation aims to generate replicas with different vulnerabilities [15].

2.1.1 N-version Programming

The concept of N-version programming, or multi-version programming, was first introduced by Chen and Avizienisˇ in 1977 [16]. N-version programming is defined as the independent generation of N ≥ 2 functionally equivalent programs from the same initial specification – versions. Although redundancy is useful in order to enable a program to recover from faults, it does not improve the reliability of a program. Given the same input and state, the program will produce the same error. Chen and Avizienisˇ also state that if we want to use redundant software to achieve software fault-tolerance and, consequently, reliability, then it should meet three constraints:

1. It does not require complete self-checking;

2. It does not rely on run-time software diagnosis;

3. It must contain independently developed alternatives routines for the same functions.

The N from N-version programming comes from the N diverse versions of the program by N different programming teams, or programmers, that do not interact with each other regarding the programming process. Although N-version programming seems a very good form of diversity, it has some issues. First of all, even though the separate individuals or groups that program different versions of the program do not interact with each other, there is no guarantee that a certain vulnerability is not going to be in all

18 of those N-versions of the program. It might be an algorithm vulnerability or just a programming bug or flaw shared by all versions. Another limitation of the N-version programming is that every version is originated from the same initial specification. With that being said, we need to assure the initial specification’s correctness, completeness and unambiguity prior to the versions development.

2.1.2 Moving-target Defenses

Recently there has been some discussion on the need for moving-target defenses. Such defenses dynamically alter properties of programs and systems in order to overcome vulnerabilities that eventually appear in static defense mechanisms [17]. In daily life, people use moving-target defenses without even noticing, e.g. periodically changing passwords. There are two types of moving-target defenses: reactive and proactive [5]. Proactive defenses are generally slower than reactive defenses as they prevent attacks by increasing the system complexity periodically. Reactive defenses are faster than proactive defenses as they are activated when they are triggered when an attack is detected. Using only reactive defenses may cause a problem where an attack is performed but not detected. In this case, where these defenses are worthless, proactive defenses may help prevent those undetected attacks from being successful. Proactive defenses must be more sparse in time as they are more complex, but they are helpful in anticipating a potential attack. At the same time, reactive defenses are useful to prevent attacks which were not anticipated by the proactive defenses. The best approach is to implement both – adaptive response [18]. Nevertheless, these defenses are as good as their ability to make an unpredictable change to the system. Although moving-target defenses are a good defensive measure, they have some negative aspects. They increase the system’s complexity and are not one hundred per cent secure. Attackers can react to the system changes’ and make successful attacks. While moving-target defenses changes’ to the system are unpredictable to the attacker, they can also become unpredictable to the defenders which can make the system difﬁcult to maintain and to track possible issues in it.

2.1.3 Proﬁle-guided Automated Software Diversity

Code injection is a type of attack that consists in injecting code into a vulnerable program. A major prevention technique to this kind of attack called W⊕X appeared in 2003 and was implemented in the OpenBSD 3.3 [19]. This technique prevents a page from being executable and writeable at the same time. When attackers realized they were not able to inject code anymore, they came up with the idea to reuse code from the program itself to perform the attack. In order to counter these attacks, Homescu et al. suggested an approach in 2013 using software diversity and NOP insertion [20]. A NOP instruction is an instruction which execution has no effect on the processor or memory. Also, NOP instructions do not affect the logic of a program. The insertion of NOP instructions diversiﬁes the code layout and presents a powerful counter to attacks that reuse tiny code fragments, named gadgets, such as Return-Oriented Programming (ROP), a technique by which an attacker can introduce arbitrary

19 behaviour in a program whose control ﬂow he has diverted, without injecting any code [21]. Although it seems to be a good technique, the insertion of NOPs can produce a high-performance overhead, even if combined with proﬁled data.

2.2 SSL/TLS Protocol

This section presents the SSL/TLS protocol, as this is the protocol in which VTTLS is based. We start by presenting a brief history of SSL/TLS and proceed by explaining its two layers: the TLS Handshake Protocol and the TLS Record Protocol. We also approach its different conﬁguration variants and present and discuss some of its vulnerabilities and how they were mitigated.

2.2.1 Brief History

Secure Sockets Layer (SSL) [22] is a security protocol developed by Netscape Communications in 1994. SSL was created with the purpose of ensuring the existence of an open security standard and to provide privacy and reliability between two communicating applications. The ﬁrst version of SSL, SSL 1.0, was never publicly released due to its several security ﬂaws as it implemented weak cryptographic algorithms.

SSL 2.0, an improved version of SSL 1.0, was released in 1995. SSL 2.0 used RSA [23] for authentication and key exchange and MD5 [24] for hashing. Several encryption mechanisms could be used, such as Triple DES, with an effective key of 112 bits. SSL 2.0 was deprecated in 2011 due to strong security ﬂaws including allowing man-in-the-middle attacks and using MD5, according to the RFC 6176 [25].

Version 3 of SSL, SSL 3.0, resulted from a collaboration between Netscape Communications and Paul Kocher. It was released in 1996 and its speciﬁcation is regarded as a historic document for the Internet community. Among other improvements, SSL 3.0 allowed forward secrecy using Difﬁe-Hellman key exchange and supported SHA-1 for hashing. SSL 3.0 was deprecated in 2015 [26].

Transport Layer Security (TLS) [27] is the successor of SSL. The ﬁrst version of TLS, TLS 1.0, deﬁned in 1999, was an upgrade to SSL 3.0. Some of the changes include the support for extensions in the Client and Server Hello messages. Those changes were enough to make TLS 1.0 incompatible with SSL 3.0. Although, TLS 1.0 supports a connection downgrade to SSL 3.0 which causes security issues. TLS 1.0 supports all the authentication and key exchange mechanisms supported by the most recent version of TLS, TLS 1.2.

TLS 1.1 was released in 2006 as an upgrade from TLS 1.0. This version introduced a few changes in order to correct some ﬂaws which allowed cipher block chaining (CBC) attacks.

TLS 1.2, released in 2008, is the third and current version of TLS. It includes several improvements over TLS 1.1 such as supporting more block cipher modes of operation to use with AES and supporting some variations of SHA-2 (see Table 2.3).

20 Figure 2.1: Sequence diagram of the TLS Handshake Protocol, adapted from Section 7.3 of [27].

2.2.2 TLS Handshake Protocol

The TLS Handshake Protocol is a protocol used to establish or resume a secure session between two communicating parties – a client and a server. A session is established in several steps, each one corresponding to a different message (see also Fig. 2.1). Although, this protocol’s message sequence is not straight-forward. There are various conditions that inﬂuence the exchanged messages. Beurdouche et al. studied the TLS protocol and describe a TLS state machine representing all the possible messages and transitions [28]. In this section, we do not cover all possibilities (e.g., session resumption) just a major part.

The client sends a CLIENTHELLO message to the server in order to start a connection. This message is composed by the client’s TLS version, a structure denominated Random (which has a secure random number with 28 bytes and the current date and time), the session identiﬁer, a list of the cryptographic mechanisms supported by the client and a list of compression methods supported by the client, both lists ordered by preference. The client may also request extended functionality by sending data in the extensions ﬁeld.

The server responds with a SERVERHELLO message. This message is composed by the server’s

TLS version, a structure denominated Random analogous to CLIENTHELLO’s message, the session

21 identiﬁer, a cryptographic mechanism and a compression method, both of them chosen by the server from the lists received in the CLIENTHELLO message, and a list of extensions.

If the key exchange algorithm agreed between client and server requires authentication, the server sends its certiﬁcate chain to the client using a CERTIFICATE message. This message is sent nearly at all times as server’s certiﬁcates play a major part in the establishment of a secure channel.

If the server’s certiﬁcate does not contain enough information in order to allow the client to share a premaster secret, the server sends a SERVERKEYEXCHANGE message.

The server may send a request for the client’s certificate – CertificateRequest. This message is composed of a list of types of the certificates the client may send, a list of the server’s supported signature algorithms and a list of certificate authorities accepted by the server. This message is not usually sent, as most clients do not own a certificate.

Afterwards, the server sends a SERVERHELLODONE message to conclude its ﬁrst sequence of messages.

After receiving the SERVERHELLODONE message, the client sends its certiﬁcate to the server if requested. If the client does not send its certiﬁcate or it does not meet the server’s conditions, the server may choose to abort the handshake at this point.

The client proceeds to send to the server a CLIENTKEYEXCHANGE. The content of this message is dependent upon the key exchange mechanism chosen by the server, and it can be empty in some cases. Some possible content of this message includes the client Difﬁe-Hellman public value or an encrypted premaster secret.

If the client sent a certificate and it possesses signing capability (i.e. do not contain fixed Diffie-

Hellman parameters), a CERTIFICATEVERIFY message is sent to the server. Its purpose is to explicitly verify the client’s certiﬁcate.

The client sends a CHANGECIPHERSPEC message to the server to inform that he will now use the agreed-upon algorithms to send encrypted data. This message is still unencrypted. TLS has a speciﬁc protocol to signal transitions in encryption strategies denominated Change Cipher Spec. According to this protocol, a CHANGECIPHERSPEC message must be sent by both client and server to notify one another that they are now using the algorithms agreed-upon.

The client sends its last handshake message, the FINISHED message which veriﬁes the success of the key exchange and the authentication. This is the ﬁrst encrypted message sent by the client to the server.

After receiving the CHANGECIPHERSPEC message, the server sends a CHANGECIPHERSPEC message to the client. Analogously to the client’s CHANGECIPHERSPEC message, this message is still also unencrypted. The server puts an end to the handshake protocol by sending its ﬁrst encrypted message

–FINISHED – to the client.

At this point, the session is established. Client and server can now exchange application-layer data through the secure communication channel.

22 2.2.3 TLS Record Protocol

The TLS Record protocol is the top layer which processes the messages to sent and received during and after the handshake. Regarding an outgoing message, the first operation performed by the TLS Record protocol is frag- mentation. The message is divided into blocks. Each block contains the protocol version, the content type, the fragment of application data and this fragment’s length in bytes. The fragment’s length must be 214 bytes or less. After fragmenting the message, each block may be optionally compressed, using the compression method defined in the Handshake. The compression operation transforms each block into a compressed block. Each compressed block contains the protocol version, content type, the compressed form of the fragment and its length. The fragment’s length must be 214et al. 1024 bytes or less. Al- though there is always an active compression algorithm, the default one is CompressionMethod.null. CompressionMethod.null is an operation that does nothing, i.e. no fields are altered. In this case, the compressed blocks are identical to the initial blocks as no changes are made. Each potentially compressed block is now transformed into a ciphertext block by encryption and message authentication code (MAC) functions. Each ciphertext block contains the protocol version, content type and the encrypted form of the compressed fragment of application data, with the MAC, and the fragment’s length. The fragment’s length must be 214 +2048 bytes or less. When using block ciphers, it is also added padding and its length to the block. The padding is added in order to force the length of the fragment to be a multiple of the block cipher’s block length. When using AEAD ciphers, no MAC key is used. The message is then sent to its destination. Regarding an incoming message, the process is the inverse. The message is decrypted, verified, optionally decompressed, reassembled and delivered to the application.

2.2.4 TLS Conﬁguration Variants

As mentioned before, TLS does not oblige the use of pre-established algorithms. On the contrary, TLS supports several optional algorithms. The one implementing the protocol is given freedom to choose among those supported algorithms. TLS needs to specify, at least, one public-key algorithm, such as RSA, one symmetric key algorithm, such as AES, and one hash function, such as SHA-1. Table 2.1 presents all the key exchange algorithms supported by TLS [27]. Table 2.2 presents all the symmetric key algorithms supported by TLS. Table 2.3 presents all the hash functions supported by TLS. A keyed-hash message authentication code (HMAC) is an algorithm that combines a secret key with an hash function to compute a message authentication code (MAC) to verify data integrity and authenticity of a message. Additional to the algorithms mentioned in Table 2.3, there is also a mechanism called authenticated encryption with associated data (AEAD) [29]. AEAD provides conﬁdentiality for a ciphered message and, additionally, integrity and authenticity. AEAD provides a way of authenticating additional information attached to that message. The most recent member of the SHA family, SHA-3 (Keccak), is not yet supported by TLS 1.2.

23 Algorithm Description Perfect Forward Secrecy Secure RSA RSA key exchange algorithm DH-RSA DH with DSS-based certificates DH-DDS DH with DSS-based certificates DHE-DSS Ephemeral DH with DDS (DSA) signatures DHE-RSA Ephemeral DH with RSA signatures DH-anon Anonymous DH without signatures Elliptic curve Diffie-Hellman ECDH-RSA with RSA signatures Elliptic curve Diffie-Hellman ECDH-ECDSA with ECDSA (variant of DSA) Ephemeral elliptic curve Diffie-Hellman ECDHE-RSA with RSA signatures Ephemeral elliptic curve Diffie-Hellman ECDHE-ECDSA with ECDSA (variant of DSA) RSA-PSK Pre-shared key exchange with RSA DHE-PSK Pre-shared key exchange with ephemeral DH ECDHE-PSK Pre-shared key exchange with ECDHE ECDHE-anon Anonymous ECDHE without signatures

Table 2.1: Key exchange algorithms supported by TLS 1.2. If the algorithm provides forward secrecy, it is marked with a () in the third column. In case the algorithm is regarded as insecure, it is marked with a () in the Secure column.

Cipher RFC Mode of operation Type Bits Secure 5288 GCM (Galois/Counter Mode) AES 6655 CCM (Counter with CBC-MAC) Block 128, 256 - CBC (Cipher block chaining) 3DES EDE - CBC Block 112 Weak 6367 GCM Camellia Block 128, 256 5932 CBC 6209 GCM ARIA Block 128, 256 6209 CBC SEED 4162 CBC Block 128 RC4 - ——— Stream 128

Table 2.2: Symmetric-key cipher algorithms supported by TLS 1.2. The Bits column refers to the strength of the algorithm. In case the algorithm is regarded as insecure, it is marked with a () in the Secure column. 3DES EDE in not yet regarded as insecure but has low strength.

2.2.5 TLS Vulnerabilities

To show the relevance of our work, we discuss some of the vulnerabilities discovered in TLS in the past. TLS vulnerabilities can be classified in two types: specification vulnerabilities and implementation vulnerabilities. Specification vulnerabilities concern the protocol itself. A specification vulnerability can only be fixed by a new protocol version or an extension. Implementation vulnerabilities are related to vulnerabilities in certain implementations of SSL/TLS, such as OpenSSL. The Internet Engineering Task Force (IETF) released an RFC in February 2015 summarizing known TLS attacks and vulnerabilities [30]. This section presents some of the most recent. DROWN is one of the most recent attacks against a specification vulnerability [31]. It was presented in August 2016 and it is a complex cross-protocol attack on TLS. Although many servers nowadays do not allow downgrading connections, due to some misconfigurations or inappropriate default settings a server might still support SSL 2.0. This should not be an issue by itself as no one uses this version of SSL/TLS anymore but it causes a security flaw. The attack consists of listening to a TLS connection,

24 Algorithm Hash function Digest size in bits Collisions found HMAC-MD5 MD5 128 HMAC-SHA1 SHA (SHA-1) 160 HMAC-SHA256 SHA-256 (SHA-2) 256 HMAC-SHA384 SHA-384 (SHA-2) 384

Table 2.3: Algorithms supported by TLS 1.2 to check data integrity and authenticity. retrieving information about the connection and the secrets shared. The attacker then uses the SSL 2.0 to send modiﬁed ciphertexts to the server. In several steps, and using different techniques (including an adapted Bleichenbacher iteration technique [32]), the attacker can decrypt a message and transform it into the original plaintext. The authors claim that this attack is expected to decrypt one out of 1,000 intercepted TLS handshakes.

Another recent attack against a specification vulnerability is Logjam, which was discovered in May 2015 [33]. The Logjam attack consists in exploiting several Diffie-Hellman key exchange weaknesses. Logjam is a man-in-the-middle attack that downgrades the connection to a weakened Diffie-Hellman mode. TLS supporting Diffie-Hellman with weak parameters is one aspect that makes this attack possible. The other aspect concerns export cryptography. In the 90’s, the United States of America legislated some restrictions over exporting cryptography. In order to support SSL/TLS in some countries, not allowed to import U.S.A. cryptography, SSL/TLS supports weakened Diffie-Hellman modes – EXPORT modes [34]. Previous attacks, such as the one made possible due to the FREAK vulnerability [28], have made already use of this weakness of TLS. Adrian et al. consider Logjam a result of a protocol specification vulnerability due to the fact TLS still allowing the use of Diffie-Hellman with weak parameters [33].

In order to understand the attack itself, the concept of number field sieve algorithm has to be taken into account. A number field sieve algorithm is an efficient algorithm used to factor integers bigger than one hundred digits. The authors used a number field sieve algorithm to precompute two weak 512-bit Diffie-Hellman groups used by more than 92% of the vulnerable servers [33]. This measure has been taken due to the fact that it is computationally heavy to generate prime numbers with certain characteristics. It is a safe measure for prime numbers with a safe length.

This man-in-the-middle attack trades the cipher suites used to DHE EXPORT, forcing the use of weakened Diffie-Hellman key exchange parameters. As the server supports DHE EXPORT, a com- pletely valid Diffie-Hellman mode, the handshake proceeds without the server noticing the attack. The server proceeds to compute its premaster secret using weakened Diffie-Hellman parameters. From the client’s point-of-view, the server chose a seemingly normal DHE option and proceeds to compute its secret also with weak Diffie-Hellman parameters. By this point, the man-in-the-middle can use the pre- computation results to break one of the secrets and establish the connection to the client pretending to be the server. One aspect worth noticing is that this attack will only succeed if the server does not refuse to accept DHE EXPORT mode.

The solution for this vulnerability is simple and has already been implemented. Browsers simply deny the access to servers using weak Difﬁe-Hellman cipher suites, such as DHE EXPORT, although

25 TLS still allows it. Another attack concerning the protocol specification is a padding attack named POODLE [35]. POO- DLE stands for Padding Oracle On Downgraded Legacy Encryption and was discovered by Google engineers in 2014. The origin of this attack is the backwards compatibility for SSL 3.0 by many TLS implementations. To be successful, the attacker should induce a downgrade attack first, in order to transition from TLS 1.x to SSL 3.0. POODLE targets the CBC mode of operation used in SSL 3.0. Although, an assumption that the attacker can modify communications between the client and the server must be made. POODLE is a padding attack relied on the fact. As the CBC padding is not deterministic and not covered by the MAC, the integrity of the CBC padding is not fully verified when decrypting. The POODLE attack can be used to decrypt HTTP cookies in web sites. The authors state that for every byte revealed, 256 SSL 3.0 requests are needed. The attack has been proved to be possible in TLS [36]. The implementations affected are those that do not properly check the padding used. The most obvious solution is to avoid SSL 3.0 by disallowing the backwards compatibility and deprecating SSL 3.0. Another solution is to use TLS Fallback Signalling Cipher Suite Value (SCSV), as described in [37]. This SCSV intends to prevent an unnecessary downgrade of the connection when both client and server actually do support the most recent version of TLS. Regarding implementation vulnerabilities, Heartbleed, discovered in 2014, is one of the most recent. Its name is originated from the mechanism where the vulnerability lies, the heartbeat extension. Heart- bleed was a security vulnerability in OpenSSL 1.0.1, through 1.0.1f, when the heartbeat extension [38] was introduced and enabled by default. The Heartbleed vulnerability allowed an attacker to perform a buffer over-read [39]. A buffer over-read happens when is read more data than allowed. Heartbleed can be explained in a very simple manner. OpenSSL trusted the client’s input correctness. In a normal heartbeat request, the client sends a message to the server saying: “If you are alive, send me “Bob” which has 3 letters”. The server responds “Bob”. In a abnormal heartbeat request, the client sends a message to the server saying “If you are alive, send me “Bob” which has 500 letters”. The server responds “Bob” followed by 497 bytes taken from the positions of memory following where “Bob” was stored. The server did not check if the real length of the word matched the length the user said the word had.

2.3 Vulnerabilities in Cryptographic Mechanisms

To further motivate the relevance of our work, this section presents vulnerabilities in cryptographic mechanisms, speciﬁcally in some of those used by the TLS protocol (see Section 2.2.4). As stated in Section 2.2, TLS may use a variety of cryptographic mechanisms which not all are secure. Several of these mechanisms have vulnerabilities which can make the communication insecure if exploited. In order to use diversity and redundancy to increase security, studying the known vulnerabilities of these mechanisms will help us understand which are the most common vulnerabilities and which mechanisms are secure.

26 2.3.1 Public-key Cryptography

Proposed by Rivest et al. in 1978, RSA is a cryptographic mechanism used to cipher and sign messages or information. RSA’s security is based on two problems: factorization of large integers and the RSA problem [40]. RSA’s strength is inversely proportional to one’s available computational power. As the years pass by, it is expected that performing the factorization of large integers becomes a possible task. RSA can be considered to be broken when those problems are solved within a practical amount of time. Kleinjung et al. performed the factorization of RSA-768, a RSA number with 232 digits [41]. The researchers state they spent almost two years in the whole process, which is clearly a non-feasible time. Factorizing a large integer is a very different concept from breaking RSA. RSA is still secure (see Table 2.1). As of 2010, the researchers concluded that RSA-1024 would be factored within ﬁve years, i.e. in 2015. Other attacks do not rely upon breaking RSA’s mathematical complexity, but rather focus on other details simpler to attack. A chosen plaintext attack [42] is an attack which exploits the fact that RSA is deterministic – given the same input, the same output will be produced. Let’s assume the attacker has the public key, knows some of the content of the original message, and has the original message ciphered. He can try to cipher multiple plaintexts of his own with the public key, compare them with the original ciphered message, and discover the message. A chosen ciphertext attack [43] is another possible attack to RSA. It beneﬁts from the multiplicative property of RSA. The product of two ciphertexts is equal to encrypting the product of the two plaintexts. In these attacks, an attacker sends a ciphered message of his own, consisting of the original ciphered message M multiplied by a random value R, ciphered with the same key as M. If the attack is successful, the attacker can now obtain M by decomposing the message sent. These attacks assume that an attacker can obtain plaintexts from ciphertexts from the system. Adaptive chosen ciphertext attacks are an adaptive form of chosen ciphertext attacks in the sense that they use the results of previously sent ciphertexts to select future ciphertexts. Shor designed a quantum computing algorithm to factorize integers in polynomial time [44]. However, it requires a quantum computer able to run it, which is still not available. For the time being, quantum computers are just theoretical models.

2.3.2 Symmetric Cryptography

Triple DES, or 3DES, is an encryption mechanism based on DES [45]. As the name says, Triple DES consists on multiple encryption using DES. Triple DES can be implemented using one of three keying options:

1. All three keys are independent;

2. Key 1 is equal to Key 3. Key 1 and Key 2 are independent;

3. All three keys are equal.

27 Associated with each keying option there is a set of vulnerabilities. Keying option one uses three different 56-bit keys, i.e. a 168-bit key but, due to meet-in-the-middle (MITM) attacks, the real security is 112-bit. Lucks presented an attack to the keying option one of Triple DES [46]. The proposed attack consists in a meet-in-the-middle attack which reduced the number of steps to roughly 2108 steps from 2112 steps. While being an improvement compared to the brute-force attack, this attack still requires a lot of time to be performed, which makes it impracticable. NIST states that Triple DES with keying option one is viable until the end of 2030. From there onwards, its use is disallowed [47]. Keying option two uses two different 56-bit keys, i.e. a 112-bit key. Keying option two, also known as two-key triple encryption, can be attacked using chosen plaintext attacks with about 2k steps, k = 56 [48]. Merkle et al. concluded it is preferable to use a single encryption algorithm with a longer key rather than a multiple encryption algorithm with a smaller key. Keying option three has the same security as DES, which makes it a insecure option. The Advanced Encryption Standard (AES), originally named Rijndael, is an encryption mechanism created by Rijmen and Daemen [49]. AES can be employed with different key sizes – 128, 192 or 256 bits. The number of rounds corresponding to each key size is, respectively, 10, 12 and 14. AES has become the standard encryption mechanism, used by many protocols such as TLS. The growth of its popularity attracted attackers to try to find vulnerabilities in it. The most successful cryptanalysis of AES was published by Bogdanov et al. in 2011, using a biclique attack, a variant of the MITM attack [50]. It performed slightly better than brute-force attacks. In order to understand how difficult it is to do the cryptanalysis of AES, this attack achieved a complexity of 2126.1 for the full AES with 128-bit (AES-128). The key is therefore reduced to 126-bit from the original 128-bit, but it would still take many years to successfully attack AES-128. Prior to Bogdanov et al., while Rijndael was just a candidate to AES, Ferguson et al., in 2010, presented the first known attacks on the first seven and eight rounds of Rijndael [51]. Although it shows some advance in breaking AES, AES with a key of 128 bits has 10 rounds. Related-key attacks were also used to try to exploit AES [52] but the fact is that no properly designed software will use related-keys. Side-channel attacks are one kind of attacks to AES. These attacks rely on certain unexpected outputs of the computational execution of AES, such as the power consumed, the heat generated or the time taken to perform the operation. As of today, there are no known practical attacks that succeeded in breaking AES encrypted data. Camellia is also a symmetric block cipher originated in Japan in 2000 [53, 54]. Mitsubishi Electric and NTT are the corporations responsible for the development of Camellia. Using a Feistel network as a structure, Camellia can be used with three different key sizes: 128, 192 or 256 bits. In fact, TLS only supports Camellia with 128 and 256 bits keys [55]. Camellia can be employed using the Galois/Counter mode or the cipher block chaining mode. Although TLS supports both modes of operation [56], OpenSSL does not support Camellia with GCM. Camellia, such as AES, is considered a secure cipher but several attacks have been performed against Camellia’s security. Several researchers tried to use impossible differential attacks against Camellia. These type of attacks focus [57], Meet-in-the-middle attacks have also been used to test

28 Camellia’s security [58, 59]. The majority of these attacks focused reduced versions of Camellia. There- fore, although the results of these attacks demonstrate some advance in breaking the ﬁrst rounds of Camellia, Camellia is still a secure symmetric encryption function which can be used in secure communication channels.

2.3.3 Hash Functions

The main applications for hash functions in modern cryptography regard data integrity and message authentication. Sometimes also called message digest or digital ﬁngerprint, the hash is a compact representation of the input string and can be used to uniquely identify that hashed input string [60]. According to Menezes et al., a hash function h must have a minimum of two properties:

• compression – h maps an input string s of ﬁnite length to an output h(s) of a ﬁxed length x.

• ease of computation – given h and an input string s, the hash h(s) is easy to compute.

Menezes et al. also list three potential properties, additionally to those above:

• preimage resistance – for all pre-specified outputs, it is computationally infeasible to find any input string which hashes to that output, i.e. finding the input string s, given the output h(s).

• 2nd-preimage resistance – it is computationally infeasible to ﬁnd any second input string which has

the same hash as any speciﬁed input string, i.e. given s1, ﬁnding s2 6= s1, where h(s1) = h(s2).

• collision resistance – it is computationally infeasible to ﬁnd two input strings whose hash is identi-

cal, i.e. ﬁnding s1 = s2, where h(s1) = h(s2).

If a hash function is not preimage resistant or 2nd-preimage resistant, it is, therefore, vulnerable to preimage attacks. If a hash function is not collision resistant, it is vulnerable to collision attacks. Some generic attacks to hash function include brute force attacks, birthday attacks and side-channel attacks. MD5, the successor of MD4, was created by Rivest in 1991 [24]. MD5 is a cryptographic hash function that, although being proved to be insecure, is still widely used nowadays. MD5 produces a 128-bit message digest and is commonly used to verify data integrity. Wang et al. proved in the year of 2005 that MD5 is not collision resistant [61]. The employed attack was a differential attack which is a form of attack that consists in studying how differences in the input affect the output. The Secure Hash Algorithm 1 (SHA-1) is another cryptographic hash function which produces a 160-bit message digest. Although there have not been publicly found actual collisions for SHA-1, it is considered insecure and it is recommended to use SHA-2 or SHA-3 [62]. Other attacks have been successful against SHA-1. Stevens et al. presented a freestart collision attack for SHA-1’s internal compression function [63]. Taking into consideration the Damgard-Merkle [64] construction for hash functions and the input of the compression function, a freestart collision attack is a collision attack where the attacker can choose the initial chaining value, also known as the initialization vector (IV). Although, freestart collision attacks being successful does not imply that SHA-1 is insecure, but it is a step forward in that direction.

29 In 2005, Wang et al. presented a collision attack on SHA-1 that reduced the number of calculations needed to ﬁnd collisions from 280 to 269 [65]. The researchers claim that this was the ﬁrst collision attack on the full 80-step SHA-1 with complexity inferior to the 280 theoretical bound. By the year of 2011, Stevens improved the number of calculations needed to produce a collision from 269 to a number between 260.3 and 265.3 [66]. Nowadays it is still computationally expensive to perform these number of calculations. In the near future, by the year of 2021, a collision attack is expected to be affordable to a university research project [67].

Regarding SHA-2 and its security, Khovratovich et al. presented in 2011 a biclique attack against SHA-2’s preimage resistance [68]. This attack only breaks SHA-2’s preimage resistance for 57 rounds of SHA-512 and for 52 rounds of SHA-256 and does not represent a real threat against SHA-2 security. For several years, other researchers have also tried differential attacks for collisions and pseudo-collisions [69, 70, 71, 72]. Similarly to the biclique attack, these attacks do not mean that SHA-2 is insecure, as they could only break a small number of rounds of SHA-2 variants. Concluding, SHA-2 is still a secure hash function without collisions and preimage and second preimage resistant.

2.4 Combining Cryptographic Mechanisms

This section describes possible ways of combining cryptographic mechanisms, discusses the best approaches and the advantages and disadvantages of combining these mechanisms comparing to using a single mechanism.

Our proposal includes diversity and redundancy of encryption mechanisms by combining two or more different mechanisms in several steps of the communication. Nevertheless, combining those mechanisms is not trivial. Encryption mechanisms can be categorised by two parameters – the type of key or the type of input data – and can use two types of keys – asymmetric or symmetric. In asymmetric encryption, also known as public-key encryption, each user has a pair of keys of his own, a private and a public key. Symmetric encryption is associated with a key shared by both sender and receiver entitled secret or shared key.

Both of these models have strengths and weaknesses so several solutions were proposed to try solving their issues. On one side, asymmetric encryption mechanisms tend to be slower. On the other side, using symmetric encryption mechanism client and server need to exchange keys in a secure fashion, which can pose a problem.

As for the type of input data, we can have one of two types: block ciphers or stream ciphers. Block ciphers are characterized by encrypting blocks of data of ﬁxed size while stream ciphers are characterized by encrypting streams of data. Symmetric ciphers can use block or stream cipher but asymmetric cipher can not be used with stream ciphers.

Several people tried to combine symmetric encryption with asymmetric encryption and different approaches surged with time.

30 2.4.1 Hybrid Encryption

Hybrid encryption consists in using both symmetric encryption and asymmetric encryption. The shared key is encrypted using asymmetric encryption and shared between client and server. From there on, now that the shared key was shared securely, client and server use symmetric encryption to communicate. Pretty Good Privacy (PGP) uses hybrid encryption and follows the OpenPGP standard (RFC 4880) [73] for the encryption and decryption of data. First of all, a random symmetric key is generated. This symmetric key is used by a symmetric encryption mechanism to cipher the message to be sent. This is done because encrypting with a symmetric encryption mechanism is faster than with an asymmetric encryption mechanism, as stated above. In PGP, every symmetric key randomly generated is called session key and is used only once. PGP then uses an asymmetric encryption mechanism to cipher again the message (previously ciphered with the symmetric encryption algorithm) using the receiver’s session key. This way, only the receiver can decrypt the message with his private key. According to the OpenPGP standard, several symmetric and asymmetric algorithms can be used. As for public-key algorithms, the most commonly implemented is RSA, with keys of size greater than or equal to 1024 bits. Concerning symmetric-key algorithms, RFC 4880 obliges to, at least, implement 3DES. Although, the current standard is AES-128. Fujisaki et al. proposed in 2005, a new hybrid encryption mechanism [74] that is chosen ciphertext secure, following a set of assumptions:

• Asymmetric encryption has one-wayness property;

• Symmetric encryption has one-time security;

• Any plaintext of the asymmetric encryption has, at least, 2ω(logk) possible cipher texts.

Theoretically, this hybrid encryption scheme seems to be very good, the authors did not perform a practical evaluation of the scheme. Therefore, there is no comparison being made with any other hybrid encryption scheme already existent. Kurosawa-Desmedt [75] was another hybrid encryption scheme proposed by Kurosawa and Desmedt in 2004 using a key encapsulation mechanism (KEM) that was not necessarily chosen ciphertext secure. Further research on the Kurosawa-Desmedt proved the key encapsulation part is not by itself chosen ciphertext secure. This was proved by presenting a chosen ciphertet attack (CCA) attack on the Kurosawa-Desmedt’s KEM [76].

2.4.2 Multiple Encryption

Multiple encryption consists in using more than one mechanism to cipher a message or information. Its purpose is to strengthen security over simple encryption. Multiple encryption can be employed using different or identical cipher mechanisms. Double encryption was one of the ﬁrst multiple encryption mechanisms. When DES was considered insecure due to its small 56-bit key [48], the solution found was to encrypt information using two consecutive DES with two independent keys. Difﬁe and Hellman proved that this solution is susceptible to a known plaintext attack with 256 operations [77]. Therefore, the

31 suggested approach was to use triple DES encryption, also known as TripleDES or 3DES. As mentioned before, this mechanism provides 112-bit real security due to being susceptible to a meet-in-the-middle attack which requires 2112 operations to succeed. Multiple encryption, while seemingly improving security, is not always a good solution. In some cases, multiple encryption can have the reverse outcome of decreasing security. In symmetric encryption, the mechanism to encrypt is also the mechanism to decrypt. If one encrypts twice a message or information using the same key, the first layer of encryption will cipher the message and the second layer will undo the encryption made by the first layer. Multiple encryption mechanisms are also less secure than single encryption mechanisms designed to use a longer key. Multiple encryption consists mainly in aggregating several weak encryption mechanisms. This aggregate may be susceptible to some other attacks, such as the double-DES. Layered encryption can be considered a sub-type of multiple encryption. It consists of encrypting layers of information or messages with identical or similar encryption mechanisms using different keys. One example of layered encryption is the encryption model of onion routing [78]. Onion routing provides real-time, bi-directional and anonymous communication for any protocol which can be modified to use a proxy. Onion routing’s anonymity is based on the fact that an onion router only knows its immediate predecessor and its successor. Onion routing uses a structure called onions. Onions are composed by layers of encrypted data structures, each layer corresponding to a routing node or “onion router”. Each onion router peels its layer and sends the message forward to the next onion router.

32 Chapter 3

Vulnerability-Tolerant TLS

VTTLS is a protocol for diverse and redundant vulnerability-tolerant secure communication channels. It aims at increasing security using diverse and redundant cryptographic mechanisms and certiﬁcates. It is based on the TLS protocol. The protocol aims to solve the main problem originated by having only one cipher suite negotiated between client and server: when one of the cipher suite’s mechanisms becomes insecure, the communication channels using that cipher suite may become vulnerable. Although most cipher suites’ cryptographic mechanisms supported by TLS 1.2 are believed to be secure, Section2 shows clearly that new vulnerabilities may be discovered and not disclosed to the public.

Unlike TLS, a VTTLS communication channel does not rely in only one cipher suite. VTTLS negotiates more than one cipher suite between client and server and, consequently, more than one cryptographic mechanism will be used for each phase: key exchange, authentication, encryption and MAC.

Diversity and redundancy appear ﬁrstly in VTTLS in the Handshake protocol, in which client and server negotiate k cipher suites to be used in the communication.

The strength of VTTLS resides in the fact that, even when (k − 1) cipher suites become insecure, e.g., because (k − 1) of the cryptographic mechanisms are vulnerable, our protocol remains secure. It is up to the developer to choose the best combination of k cipher suites according to the cipher suites server and client have available. However, the choice of the cipher suites might be conditioned by the certiﬁcates of both server and client. Diversity and redundancy will also be introduced in the following communication between client and server. VTTLS uses a subset of the k cipher suites agreed-upon in the Handshake Protocol to encrypt the messages.

VTTLS negotiates a default of k = 2 cipher suites, implying a diversity factor k = 2. While performance and management costs must be taken into account, this is the estimate of a reasonable k cipher suites to use in the communication.

3.1 Protocol Speciﬁcation

The VTTLS Handshake Protocol is similar to the TLS Handshake Protocol. The names of the messages are identical in order to provide easier migration and transition from TLS. Using this simpliﬁcation, the

33 reader familiarized with TLS can more easily understand VTTLS.

The messages that require diversity are CLIENTHELLO,SERVERHELLO,SERVERKEYEXCHANGE, K-

SERVERKEYEXCHANGE, (Server and Client) CERTIFICATE,CLIENTKEYEXCHANGE and K-CLIENTKEY-

EXCHANGE.

The ﬁrst message to be sent is CLIENTHELLO. Its purpose is to inform the server that the client wants to establish a secure channel for communication. The content of this message consists in the client’s protocol version, a Random structure (analogous to TLS 1.2) containing the current time and a 28-byte pseudo-randomly generated number, the session identiﬁer, a list of the client’s cipher suites and a list of the client’s compression methods, if compression is to be used.

The server responds with a SERVERHELLO message. This is where the server sends to the client the k cipher suites to be used in the communication. The server also sends its protocol version, a Random structure identical to the one received from the client, the session identiﬁer, and the k cipher suites chosen by the server from the list the client sent. It also sends the compression method to use, if compression is enabled.

The server proceeds to send a single (SERVER)CERTIFICATE message containing all of its k certificates to the client. The k chosen cipher suites are dependent from the server’s certificates. Each certificate is associated with one key exchange mechanism (KEM). Therefore, the k cipher suites must use the key exchange mechanisms supported by the server’s certificates. A further improvement is to make possible to send multiple certificate chains. This can be achievable by sending each chain in a different message which would make the relationships between the certificates clearer.

VTTLS behaves correctly if the server has c certiﬁcates, with 0 < c ≤ k . The cipher suites to be used are chosen considering the available certiﬁcates. If c < k, the diversity is not fully achieved due to the fact that a number of cipher suites will share the same key exchange and authentication mechanisms.

The SERVERKEYEXCHANGE message is the next message to be sent to the client by the server. This message is only sent if one of the k cipher suites includes a key exchange mechanism like ECDHE or DHE that uses ephemeral keys, i.e. that generates new keys for every key exchange. The contents of this message are the server’s DH ephemeral parameters. For every other k − 1 cipher suites using

ECDHE or DHE, the server sends additional SERVERKEYEXCHANGE messages with additional diverse DH ephemeral parameters. Instead of computing all the ephemeral parameters and sending them all on a single larger message, the server, after computing one parameter, sends it immediately, sending each parameter in a separate message.

The remaining messages sent by the server to the client at this point of the negotiation, CERTIFI-

CATEREQUEST and SERVERHELLODONE, are identical to TLS 1.2 [27].

The client proceeds to send a (CLIENT)CERTIFICATE message containing its i certiﬁcates to the server, analogous to the (SERVER)CERTIFICATE message the client received previously from the server.

After sending its certiﬁcates, the client sends k CLIENTKEYEXCHANGE messages to the server. The content of these messages is based on the k cipher suites chosen. If m of the cipher suites use RSA as KEM, the client sends m messages, each one with a RSA-encrypted pre-master secret to the server (0 ≤ m ≤ k). If j of the cipher suites use ECDHE or DHE, the client sends j messages to the server

34 Figure 3.1: VTTLS Handshake messages using diversity factor k. The places where diversity and redundancy are introduced are marked in bold and underlined. PRF stands for pseudo-random function. containing its j Diffie-Hellman public values (0 ≤ j ≤ k). Even if a subset of the k cipher suites share the same KEM, this methodology still applies as we introduce diversity by using different parameters for each cipher suite being used. The server may need to verify the client’s i certificates. If they have signing capabilities (i.e. do not contain fixed Diffie-Hellman parameters), the client digitally signs all the previous handshake messages and sends them to the server for verification.

Client and server now exchange CHANGECIPHERSPEC messages, like in the Cipher Spec Protocol of TLS 1.2, in order to state that from now on they will use the previously negotiated cipher suites to encrypt messages.

In order to ﬁnish the Handshake, the client and server send each other a FINISHED message. This is the ﬁrst message sent encrypted using the k cipher suites negotiated earlier. Its purpose is to each

35 Designers Year Digest Size Structure Rounds AEAD (GCM) McGrew, D., and Viega J. (U.S.A.) 2005-2009 Does not apply SHA-2 (SHA-384) 384 bits 80 2000 SHA-2 (SHA-256) NIST (U.S.A.) 256 bits 64 Merkel-Damgard˚ SHA-1 1993 160 bits 80 MD5 Rivest, R. (U.S.A.) 1992 128 bits 4

Table 3.1: VTTLS hash functions’ diversity metrics party receive and validate the data received in this message. If the data is valid, client and server can now exchange messages over the communication channel.

3.2 Combining Diverse Cipher Suites

Diversity between cryptographic mechanisms can be taken in a soft sense as the use of different mechanisms, or in a hard sense as the use of mechanisms that do not share common vulnerabilities (e.g. because they are based on different mathematical problems). In VTTLS we are interested in using strong diversity in order to claim that no common vulnerabilities will appear in different mechanisms. Neverthe- less, it is very difﬁcult to afﬁrm that different mechanisms tolerate the same vulnerabilities. Therefore,

VTTLS uses a soft diversity. Given different heuristics, we compare the diverse mechanisms and try to choose the ones which do not share vulnerabilities. Measuring the level of diversity is not simple, so we leverage previous research on heuristics for comparing diversity among cryptographic mechanisms [79]. Moreover, not all cryptographic mechanisms can be used together in the context of TLS 1.2 and other security protocols.

Diversity can be assessed using different metrics. As VTTLS uses the same cryptographic mechanisms as TLS, more speciﬁcally those available in OpenSSL, we assess diversity among VTTLS’s mechanisms.

3.2.1 Hash Functions

Regarding hash functions, the metrics used were the designers (people, entity or organization who created or designed the function) and their country of origin, the year when it was ﬁrst published, the digest size, the structure, the number of rounds, the properties (collision, preimage, and second preimage resistant), and the known attacks. Table 3.1 and 3.2 show the metrics for each hash function supported by VTTLS. We consider the most diverse ciphers to be those with a different structure, and no common weaknesses. The other metrics are considered less relevant. AEAD was included in this study due to the fact that, although not being a hash function, it is considered an alternative mechanism which can be used redundantly with a HMAC to achieve even higher diversity.

All VTTLS cipher suites use either AEAD (MAC-then-Encrypt mode), SHA-2 (SHA-256 or SHA- 384), SHA-1 or MD5. The ﬁrst metric to be taken into account is the current security of each hash function. While AEAD (which is not a hash function) and SHA-2 are considered secure, SHA-1 is being

36 Properties (Complexity) Other relevant Collision Preimage Second preimage known attacks resistant resistant resistant (number of rounds attacked) AEAD (GCM) Yes Yes Yes Biclique attack (57), SHA-2 (SHA-384) Yes Yes Yes Meet-in-the-middle attack (46) Biclique attack (52), SHA-2 (SHA-256) Yes Yes Yes Pseudo-collision attack (46), Meet-in-the-middle (43) SHA-1 No (260.3) Yes Yes Freestart collision attack (on full SHA-1) MD5 No (230) No No

Table 3.2: VTTLS hash functions’ known attacks deprecated and MD5 is considered insecure. Therefore, we excluded SHA-1 and MD5 from the possible combinations of hash functions. The small range of available hash functions limits the maximum diversity factor achievable. The choice for a combination is restricted to choosing between AEAD + SHA-2 (SHA-384 or SHA-256) or SHA-384 + SHA-256. Our choice for creating maximum diversity relies on AEAD plus a variant of SHA-2. As AEAD is a different approach to MACs, it is supposedly vulnerable to different attacks than the ones targeting pure hash functions, such as SHA-2. Using a combination of two SHA-2 variants would not create maximum diversity. Although having different digest sizes and rounds, their structure is identical. In a near future, it is expected that a new version of TLS supports SHA-3 and makes possible more diverse combinations. With a sponge construction structure and an arbitrary digest size , SHA-3 would provide a higher diversity factor if used with AEAD or SHA-2.

3.2.2 Public-key Encryption Mechanisms

VTTLS supports several public-key functions used for both key-exchange and authentication. The metrics used to classify public-key functions include the designers, similarly to hash functions, the publishing year, the mathematical hard problems on which the mechanism is based upon, perfect forward secrecy (PFS), the semantic security (i.e. given a ciphertext and the public key, it must be unfeasible to derive any information about the original message), and known attacks. As we want to maximize diversity in order to increase security, we prioritize mechanisms which grant PFS. After PFS, we prioritize mechanisms with disjoint mathematical hard problems. Table 3.3 demonstrates the ﬁrst set of metrics used to assess diversity among public-key mechanisms supported by TLS. Table 3.4 demonstrates the known attacks of the considered mechanisms. Of course, there are not listed all attacks because it is difﬁcult to enumerate all existing attacks and not all attacks are of public knowledge. A wrong conclusion is that the mechanisms with most known attacks are less safe. A more popular mechanism will likely be a more attractive target than a less popular mechanism. The attacks complexity is also important to take into account as a great part of them is either theoretical or computationally unfeasible. After comparing these public-key encryption mechanisms using the metrics stated above, we conclude that the best three combinations are:

37 Mathematical Perfect Forward Semantic Designers Year Hard Problem Secrecy Security Rivest, R., Yes (Using a random and Shamir, A., RSA 1977 Integer Factorisation Problem No encryption padding and Adleman, L. scheme) (U.S.A. and Israel) Miller, V., Yes (If used with ECDH(E) and Koblitz, N. 1985 Elliptic-curve discrete logarithm problem No ephemeral keys) (U.S.A.) Difﬁe, W. Yes (If used with DH(E) and Hellman, M. 1976 Discrete Logarithm Problem No ephemeral keys) (U.S.A.) Vanstone, S. ECDSA 1992 Elliptic-curve discrete logarithm problem Yes No (Canada) NIST DSA 1991 Discrete Logarithm Problem Yes No (U.S.A.)

Table 3.3: VTTLS public-key encryption functions’ diversity metrics

Known attacks Chosen plaintext attack, Chosen ciphertext attack, Adaptive chosen ciphertext attack, RSA Coppersmith’s attack, Hastad’s˚ broadcast attack Man-in-the-middle attack, Menezes-Okamoto-Vanstone (MOV) attack, Frey-Rueck attack, ECDH(E) Pollard’s rho method, Weil descent attack DH(E) Man-in-the-middle attack, Logjam attack Menezes-Okamoto-Vanstone (MOV) attack, Frey-Rueck attack, Pollard’s rho method, ECDSA Weil descent attack, Timing attack, Collision attack, Lattice attack DSA Adaptive chosen-ciphertest attack, Lattice attack

Table 3.4: VTTLS public-key encryption mechanisms’ known attacks

• RSA + ECDH(E): This combination is possible as TLS 1.2 supports both functions for key exchange

• ECDSA + ECDH(E): This combination is possible as TLS 1.2 supports both functions for authentication. However, TLS 1.2 speciﬁc cipher suites only support ECDSA

• ECDSA + RSA: This combination is possible as TLS 1.2 supports both functions for authentication

VTTLS uses public-key encryption mechanisms for key exchange and authentication. Although there is not a wide range of supported mechanisms, VTTLS provides a good possibility of diversity. Regarding authentication, the preferred combination is ECDSA + RSA. Using elliptic curves results in a faster computation and lower power consumption [80]. Regarding key exchange, the chosen combination is RSA + ECDH(E). In order to grant perfect forward secrecy, ECDH must be used with ephemeral keys. Concluding, the preferred combination for key exchange is RSA + ECDHE.

3.2.3 Symmetric-key Encryption Mechanisms

We also evaluated diversity among symmetric encryption mechanisms, similarly to hash functions and public-key functions.

In order to classify each symmetric mechanism supported by VTTLS, we consider the following metrics: the type (block cipher or stream cipher), the mode of operation, the designers, the year it was ﬁrst published, the strength (the key size in bits), the number of rounds, the block size (also in bits), the internal structure, and the current status (secure, low strength or insecure)

38 Block Mode of Strength Type Designers Year Rounds size Structure Status Operation (in bits) (in bits) 256 14 GCM Rijmen, V., Substitution- 128 10 AES and Daemen, J. 1998 128 -permutation Secure 256 14 CBC (Belgium) network 128 10 Mitsubishi Electric, 256 24 Camellia CBC 2000 128 Feistel network Secure and NTT (Japan) 128 18 Block Nested Feistel SEED CBC KISA (South Korea) 1998 128 16 128 Secure network 128 12 Secure ARIA GCM Large group Substitution- 256 16 Secure (Not available of researchers 2003 128 -permutation 128 12 Secure in VTTLS) CBC (South Korea) network 256 16 Secure IBM Low 3DES EDE CBC 1998 112 48 64 Feistel network (U.S.A.) strength

Table 3.5: VTTLS symmetric encryption mechanisms’ diversity metrics

Known attacks AES XSL attack, Biclique attack Impossible differential attack, Cache timing attack, Collision attack, Camellia High-order differential attack, Differential attack, Square attack SEED Differential attack ARIA (Not available Meet-in-the-middle attack, Impossible differential attack, Boomerang attack in VTTLS) 3DES EDE Meet-in-the-middle attack, Chosen-plaintext attack, Known-plaintext attack

Table 3.6: VTTLS symmetric encryption mechanisms’ known attacks

We do not consider semantic security (i.e. an attacker must not be able to extract any information about the original message from its ciphertext) for symmetric encryption. If a mechanism is not seman- tically secure, it is considered insecure.

Table 3.5 presents the metrics above applied to VTTLS supported mechanisms. Table 3.6 shows the known attacks to each studied mechanism.

We also included ARIA [81] in our comparison, although not being implemented in VTTLS. IDEA [82] is also a symmetric-key encryption mechanism supported by some versions of TLS but it was removed from TLS 1.2. Therefore it is not part of our study nor supported by VTTLS. GOST 28147-89 [83] is also another symmetric-key encryption mechanism originated in Russia but its inclusion in TLS was only proposed in RFC drafts. Regarding stream ciphers, VTTLS only supports RC4 which use has been prohibited in all versions of TLS due to being insecure [84]. ChaCha20-Poly1305 is another stream cipher available in some implementations of TLS but VTTLS and OpenSSL do not support this cipher [85]. Nevertheless, ChaCha20-Poly1305 is considered a secure cipher and could possibly be used in the future to increase diversity. We consider symmetric-key encryption mechanisms’ three most important metrics to be structure, mode of operation and common known attacks. In a certain sense, these metrics are related as attacks target a speciﬁc structure or mode of operation. Additionally, we will only consider secure mechanisms, preferably with different key sizes. Concluding, the combinations of symmetric encryption mechanisms we consider to be the most diverse are:

• AES + Camellia (Using a different mode of operation and key size)

• AES256-GCM + SEED128-CBC

39 Both AES and Camellia are supported by TLS 1.2 and are considered secure. We consider the most diverse combination to be AES256-GCM + CAMELLIA128-CBC. Regarding the priority metrics, their structure is different, as its mode of operation and the set of known attacks is disjoint. Although, using a cipher suite that contains Camellia or SEED in order to maximize diversity in symmetric encryption has some drawbacks. There is no cipher suite that uses RSA for key exchange, Camellia for encryption and a SHA-2 variant for MAC. Although RFC 6367 [56] describes the support for

Camellia HMAC-based cipher suites, extending TLS 1.2, these cipher suites are not supported by VT- TLS. Using Camellia or SEED implies using SHA-1 for MAC, and not using ECDHE for key exchange nor ECDSA for authentication, at least in that cipher suite. Concluding, using Camellia or SEED increases diversity in symmetric encryption but forces reduced diversity and security in MAC. Nevertheless, diversity in symmetric encryption is still an objective to accomplish. We decided that the best option is AES256-GCM + AES128-CBC. In theory, these are the same symmetric mechanism but employed with a different key size (strength) and mode of operation, we consider them diverse. Nevertheless, they have an inferior degree of diversity comparing to other combinations. The ideal scenario would be the one where Camellia HMAC-based cipher suites would be available in OpenSSL (and consequently VTTLS) allowing to combine AES and Camellia to maximize diversity. Concluding, the best combination of cipher suites is arguably:

• TLS ECDHE ECDSA WITH AES 256 GCM SHA384 and

• TLS RSA WITH AES 128 CBC SHA256TLS RSA WITH AES 128 CBC SHA256

For key exchange, VTTLS will use ECDHE and RSA; for authentication, it will use ECDSA and RSA; for symmetric encryption, it will use AES-256 with Galois/Counter mode (GCM) and AES-128 with cipher block chaining (CBC) mode; and for MAC it will use AEAD and a SHA-2 variant (SHA-256). Using this combination of cipher suites, we aim to achieve the maximum possible diversity, with a diversity factor k = 2. The least diversiﬁed parts of the communication are the MAC and the symmetric encryption due to the fact that TLS does not support SHA-3 and OpenSSL does not support Camel- lia HMAC-based cipher suites. If those two encryption mechanisms were available to use, the best combination of cipher suite would contain those mechanisms.

3.3 Implementation

VTTLS was implemented as a modiﬁcation of OpenSSL v1.0.2g.1 Implementing a secure communication channel from scratch would be a bad option as it might lead to the creation of vulnerabilities; existing software such as OpenSSL has the advantaged of being extensively debugged, although se- rious vulnerabilities like Heartbleed still appear from time to time. Furthermore, creating a new secure communication channel, and consequently a new API, would create adoption barriers to programmers otherwise willing to use our protocol. Therefore, we chose to implement VTTLS based on OpenSSL and

1https://www.openssl.org

40 const char* SSL_get_n_cipher(short n, const SSL* s); const SSL_CIPHER* SSL_get_current_n_cipher(short n, const SSL* s); int SSL_CTX_use_n_certificate(short n, SSL_CTX* ctx, X509* x); int SSL_CTX_use_n_certificate_file(short n, SSL_CTX* ctx, const char* file, int type); int SSL_CTX_use_n_PrivateKey(short n, SSL_CTX* ctx, EVP_PKEY* pkey); int SSL_CTX_use_n_PrivateKey_file(short n, SSL_CTX* ctx, const char* file, int type); int SSL_CTX_check_n_private_key(short n, const SSL_CTX* ctx); X509* SSL_get_n_peer_certificate(short n, const SSL* s); int SSL_CTX_add_n_preferred_cipher_suite(short n, SSL_CTX *ctx, int hex);

Figure 3.2: VTTLS API: Additional functions in relation to the OpenSSL API. keeping the same API. Nevertheless, OpenSSL is a huge code base (currently 438,841 lines of code) and modifying it so support diversity was quite a challenge.

Although being based on OpenSSL, VTTLS is not compatible with OpenSSL. Due to its diversity and redundancy features, VTTLS can not connect to a OpenSSL server or client. Moreover, the current

VTTLS prototype does not support all OpenSSL cipher suites, e.g. Pre-shared key (PSK) and Secure Remote Password (SRP).

VTTLS adds a few functions to the OpenSSL API. These functions are represented in Figure 3.2. The meaning of the functions is pretty straightforward. They allow defining additional certificates, keys, cipher functions, etc. The parameter n should be set to the number of the certificate, key, etc. being added. For example, with k = 2 the parameter n takes only value 2 as we have to add just the second of each. For k = 3 every function has to be called twice, with parameter n set to 2 and 3.

In order to establish a VTTLS communication channel, additional functions are required to fulfill the requirements of VTTLS, such as loading two certificates and corresponding private keys. These functions have a similar name of the ones belonging to the OpenSSL API, to reduce the learning curve. The most relevant functions regarding the setup of the channel are the functions that allow to load the second certificate and private key and allow to check if the second private key corresponds to the second certificate.

Regarding the Handshake Protocol, we opted for sending k SERVERKEYEXCHANGE and CLIEN-

TKEYEXCHANGE messages, instead of sending one single SERVERKEYEXCHANGE, and one single

CLIENTKEYEXCHANGE, each one with several parameters. This is due to the fact that it is easier to understand and to maintain the code. If k is increased, VTTLS sends an additional message instead of changing the code related to sending and retrieving SERVERKEYEXCHANGE and CLIENTKEYEXCHANGE messages.

The signing and encryption ordering is also important for VTTLS. Figure 3.3 shows the ordering for one cipher and one MAC in the OpenSSL implementation. eivlen refers to the length of the initialization vector. The approach taken was the following, ordered from ﬁrst to last:

1. Apply the ﬁrst MAC to the plaintext message;

2. Encrypt the ﬁrst message and its MAC with the ﬁrst encryption function;

41 Figure 3.3: First four steps regarding the ordering of the encryption and signing of VTTLS using a diversity factor k = 2.

3. Apply the second MAC to the ﬁrst ciphertext;

4. Encrypt the ﬁrst ciphertext and its MAC with the second encryption function.

We opted to maintain the signing prior to the encryption. Using this approach, both message and MACs are encrypted with both ciphers. Figure 3.4 shows the ﬁnal ordering of VTTLS communication. In relation to the Record Protocol, signing and encrypting k times has a cost in terms of message size. Figures 3.3 and 3.4 show also the expected increase of the message size due to the use of a second MAC and a second encryption function (for k = 2). For TLS 1.2 (OpenSSL), the expected size of a message is first len = eivlen + msg length + padding + mac size, where eivlen is the size of the initialization vector (IV), msg length the original message size, padding the size of the padding in case a block cipher is used, and mac size the size of the MAC (Figure 3.3). For VTTLS, the additional size of the message is eivlen sec + first len + padding sec + mac size sec, where eivlen sec is the size of the IV associated with the second cipher and mac size sec the size of the second MAC.

In the best case, the number of packets is the same for OpenSSL and VTTLS. In the worst case, one additional packet may be sent if the encryption function requires a ﬁxed block size and the maximum size of the packet, after the second MAC and the second encryption, is exceeded by, at least, one byte. In this case, an additional full packet is needed due to the constraint of having ﬁxed block size.

42 Figure 3.4: Remaining three steps regarding the ordering of the encryption and signing of VTTLS using a diversity factor k = 2. Here is represented the second signing and the second encryption, employing diversity and redundancy in the communication.

43 44 Chapter 4

Experimental Evaluation

We evaluated VTTLS in terms of two aspects: performance and costs. We considered OpenSSL 1.0.2g as the baseline, due to the fact that VTTLS is based on that version of OpenSSL.

Implementing diversity has performance costs and creates overhead in the communication. Every message sent needs to be ciphered and signed k − 1 times more than using a TLS implementation and every message received needs to be deciphered and veriﬁed also k − 1 times more. In the worst case, users should experience a connection k times slower than using OpenSSL. We considered k = 2 in all experiments, as this is the value we expect to be used in practice (we expect vulnerabilities to appear rarely, so the ability to tolerate one vulnerability per mechanism sufﬁcient). With this experimental evaluation, we want to be able to state if VTTLS is a viable mechanism for a daily usage, not only cloud computing, and if the cost of replacing TLS channels for VTTLS channels is not prohibitive.

In order to perform these tests, we used two virtual machines in the same Intel Core i7 computer with 8 GB RAM. The virtual machines run Debian 8 and openSUSE 12 playing the roles of server and client, respectively. All the tests were done in the same controlled environment and same geographic location in order to maintain the evaluation valid, exact and precise.

4.1 Performance

In order to evaluate VTTLS’ performance, we executed several tests. The main goal was to understand if the overhead of VTTLS is lower, equal, or bigger than k times in relation to OpenSSL. We conﬁgured

VTTLS to use the following cipher suites:

• TLS RSA WITH AES 256 GCM SHA384;

• TLS ECDH ECDSA WITH AES 256 GCM SHA384.

The suite used with OpenSSL was the later.

45 Handshake length (ms) Standard deviation Conﬁdence interval (95%) VTTLS 3.909 0.963 0.180 OpenSSL 2.345 0.933 0.174

Table 4.1: Comparison of average Handshake length

9000 8000 7000 6000 5000 4000

3000 Time (milliseconds)Time 2000 1000 0 1 MB 10 MB 50 MB 100 MB 500 MB 1 GB Message Size

vtTLS Send vtTLS Receive OpenSSL Send OpenSSL Receive

Figure 4.1: Comparison between the time it takes to send and receive a message using VTTLS and OpenSSL.

4.1.1 Handshake

To evaluate the performance of the handshake, we executed 100 times the Handshake Protocol of both

VTTLS and OpenSSL. In average, the VTTLS’ handshake took 3.909 milliseconds to conclude and the

OpenSSL’s handshake 2.345 milliseconds. Therefore, the VTTLS’s Handshake takes 66.7% longer than

OpenSSL’s Handshake. The VTTLS’ Handshake is only 1.67 slower than the OpenSSL’s Handshake, which is better than the worst case. Table 4.1 provides a better insight.

4.1.2 Data Communication

After evaluating the Handshake, we performed data communication tests to assess the overhead generated by the diversity and redundancy of mechanisms. As the Handshake, the communication is expected to be at most k = 2 times slower than a TLS communication. For this test, we considered a sample of 100 messages sent and received using VTTLS, and other 100 messages sent and received using OpenSSL. Figure 4.1 shows the comparison between the time it takes to send and receive a message using

46 VTTLS Send OpenSSL Send Average St. dev. Conf. I. (95%) Average St. dev. Conf. I. (95%) 1 MB 12.8 3.324 0.652 11.28 3.985 0.781 10 MB 105.89 17.573 3.444 76.61 10.413 2.041 50 MB 534.55 149.697 29.340 435.01 212.065 41.564 100 MB 1004.3 194.701 38.161 757.02 206.709 40.514 500 MB 4579.4 727.519 142.591 2834.18 217.378 42.605 1 GB 8289.78 757.167 148.402 5851.08 480.423 94.161

Table 4.2: Comparison between the time to send a message using VTTLS and OpenSSL.

VTTLS Receive OpenSSL Receive Average St. dev. Conf. I. (95%) Average St. dev. Conf. I.(95%) 1 MB 14.7 3.324 0.652 13.48 3.985 0.781 10 MB 113.41 17.573 3.444 80.42 10.413 2.041 50 MB 549.61 149.697 29.340 443.1 212.065 41.564 100 MB 1004.54 194.701 38.161 757.13 206.709 40.514 500 MB 4580.13 727.519 142.591 2834.37 217.378 42.605 1 GB 8227 757.167 148.402 5850.96 480.423 94.161

Table 4.3: Comparison between the time to receive a message using VTTLS and OpenSSL.

VTTLS and OpenSSL/TLS. Table 4.2 and 4.3 show a more descriptive and detailed comparison. The measurements concern the time each channel needs to perform the local operations in order to send the message (including encryption, signing, second encryption and second signing). These values do not include the time taken by the message to reach its destination through the network. The timer is started before the call to SSL write and stopped after the function returns. As for the results regarding the reception of messages, the measured time is the time taken to perform the operations necessary to retrieve the message (including second decrypting and second verifying), i.e. the time of execution of SSL read. This methodology is only possible due to the fact that SSL write is a synchronous call. It only returns after writing the message to the buffer. And also due to the fact that SSL read is also synchronous as it only returns when the message is read.

In average, a message sent through a VTTLS channel takes 22.88% longer than a message sent with OpenSSL. For example, a 50 MB message takes, in average 534.55 ms to be sent with VTTLS. Using OpenSSL, the same message takes 435.01 ms to be sent. The overhead generated by using diverse encryption and signing mechanisms exists, as expected, but it is much smaller than the worst case. In Section 3.3, we do an analysis of the expected message size increase. In order to validate the premise that the message increase is the same considering the same message size, we measured the increase in the message size comparing once again VTTLS and OpenSSL channels. A 100 KB plaintext message converts into a ciphertext of 102,771 bytes with VTTLS. Using OpenSSL, the same message corresponds to a ciphertext of 102,603 bytes. Concluding, sending a 100 KB message through VTTLS costs an additional 168 bytes. Although, as stated before, the number of extra bytes sent is not directly proportional to the message size. We also evaluated the message size of the ciphertext of a 1 MB plaintext message. A 1 MB plaintext message corresponds to a ciphertext of 1,029,054 bytes using VTTLS, while using OpenSSL the same message converts into a message of 1,025,856 bytes. Concluding, sending 1 MB through a VTTLS

47 Message VTTLS OpenSSL Overhead (difference) size Encrypted Average # Encrypted Average # Packets Message size message size packets message size packets 100 102,771 6.3 102,603 5.3 1 168 000 1 1,029,054 38.3 1,025,856 37.6 0.7 3,198 000 000 100 105,362,077.10 2,830.2 104,956,194.50 2,553.5 276.7 405,883 000 000

Table 4.4: Comparison between the message sizes. channel costs an additional 3,198 bytes than using a OpenSSL channel. Table 4.4 shows all the results obtained and some reached conclusions.

We chose not to evaluate latency of the communication using VTTLS. Latency is deﬁned as the time interval between a request and response. VTTLS, as OpenSSL, does not respond to requests by default. Additionally, measuring latency in one-way communications is very difﬁcult. Although, some protocols for communication which use secure channels, such as HTTPS, respond to requests, but this is not the case of standalone VTTLS.

4.2 Cost

Similarly to TLS, VTTLS uses certificates that require some management effort and costs. A server using OpenSSL/ TLS to protect the communication with clients needs only one certificate. If the administrator decides to use VTTLS instead of TLS, at least 2 certificates are needed for maximum diversity, and at most k certificates.

Although certificates are not expensive, they represent a cost. VTTLS can be used with just one certificate, but this diminishes the diversity and, consequently, the potential security increase. Using a diversity factor k = 2, the cost associated with certificates duplicates. Nevertheless, we believe that the additional cost of having two certificates instead of one is compensated by the increase in security and vulnerability tolerance provided by VTTLS. Regarding management, there is the need to manage two certificates instead of one. We believe this does not represent a substantial increase in management effort. If it is decided to use VTTLS with a diversity factor k > 2, the management costs of maintaining k certificates might represent an significant increase of management costs.

48 Chapter 5

Conclusion

VTTLS is a diverse and redundant vulnerability-tolerant secure communication protocol designed for communication between clouds. It aims at increasing security using diverse cipher suites to tolerate vulnerabilities in the encryption mechanisms used in the communication channel. In order to evaluate our solution, we compared it to an OpenSSL 1.0.2g communication channel. While expected to be k = 2 times slower than an OpenSSL channel, the evaluation showed that using diversity and redundancy of cryptographic mechanisms in VTTLS does not generate such a high overhead. VTTLS takes, in average, 66.7% longer to establish a connection and 22.88% longer to send a message than TLS (OpenSSL). Although, considering the increase in security and the additional ability to tolerate vulnerabilities, this overhead is acceptable. Also considering the additional costs of having extra k − 1 certiﬁcates, the time increase, and potential management costs, VTTLS seems to provide an interesting trade-off for a set of critical applications. Overall, VTTLS is a viable option for establishing secure communication in non-timely critical applications.

5.1 Future work

Diversity and redundancy are growing areas regarding networks and cloud security. Each advance in these areas is a step further on the road to achieving a vulnerability-tolerant Internet infrastructure where diverse and redundant mechanisms play a leading role in securing communications and infrastructures.

Although VTTLS shows some advance in these areas, there is a lot of work to be done. Regarding implementation, VTTLS is based upon one single implementation of SSL/TLS. An interesting implementation would be introducing diversity at the library level, i.e., to base VTTLS in two different libraries while making them compatible with each other. This would increase diversity in the code and, optionally, programming languages potentially tolerating speciﬁc implementation vulnerabilities.

As a consequence of being built using as core library OpenSSL, VTTLS is restricted to OpenSSL’s available cryptographic mechanisms. It would be a good improvement to make more mechanisms available to VTTLS, such as SHA-3. As stated before, this would represent a potential increase of diversity, and consequently, an increase of security.

49 Another implementation improvement would concern SERVERKEYEXCHANGE message sending.

Currently, VTTLS sends several of these messages, each one containing one parameter, or none. In terms of performance, this might not be the best approach, as several messages are sent instead of just one. One possible improvement would be to implement this feature and compare both possibilities to decide which one has the best overall performance.

Regarding certificates, the opposite is verified. VTTLS sends only one message with all certificates but this might prove to be a liability. When a server sends a certificate chain, it is more difficult for the client to know to which certificate chain a certain certificate belongs. A further improvement would be sending several certificate messages, neglecting performance to improve security. Another improvement could be diversifying certificate chains among diverse certificates. This means that not only the certificate would be diverse, all the chain would be different among certificates.

Regarding evaluation, VTTLS performed rather well comparing with OpenSSL. Another approach other than VTTLS could be TLS-over-TLS tunneling. A further improvement of our evaluation would be to compare VTTLS with it and draw some conclusions.

50 Bibliography

[1] S. Kent and K. Seo. Security Architecture for the Internet Protocol. RFC 4301, RFC Editor, Decem- ber 2005.

[2] T. Ylonen and C. Lonvick. The Secure Shell (SSH) Protocol Architecture. RFC 4251, RFC Editor, January 2006.

[3] B. Littlewood and L. Strigini. Redundancy and diversity in security. In Computer Security – ES- ORICS 2004, 9th European Symposium on Research Computer Security, pages 227–246, 2004.

[4] M. Garcia, A. Bessani, I. Gashi, N. Neves, and R. Obelheiro. OS diversity for intrusion tolerance: Myth or reality? In Proceedings of the IEEE/IFIP 41st International Conference on Dependable Systems and Networks, pages 383 –394, 27–30 June 2011.

[5] M. Carvalho and R. Ford. Moving-target defenses for computer networks. IEEE Security and Privacy, 12(2):73–76, 2014.

[6] S. Forrest, S. A. Hofmeyr, and A. Somayaji. Computer immunology. Communications of the ACM, 40(10):88–96, Oct. 1997.

[7] L. Bilge and T. Dumitras. Before we knew it: an empirical study of zero-day attacks in the real world. In Proceedings of the ACM Conference on Computer and Communications Security, pages 833–844, 2012.

[8] J. Viega, M. Messier, and P. Chandra. Network Security with OpenSSL: Cryptography for Secure Communications. O’Reilly, 2002.

[9] P. Larsen, S. Brunthaler, and M. Franz. Automatic Software Diversity. IEEE Security & Privacy, (April), 2015.

[10] S. Forrest, A. Somayaji, and D. Ackley. Building diverse computer systems. In Proceedings of the 6th Workshop on Hot Topics in Operating Systems. IEEE Computer Society, 1997. ISBN 0-8186- 7834-8.

[11] A. Avizienisˇ and L. Chen. On the implementation of N-version programming for software fault tolerance during execution. In Proceedings of the IEEE International Computer Software and Ap- plications Conference, pages 149–155, 1977.

51 [12] P. Larsen, A. Homescu, S. Brunthaler, and M. Franz. SoK: Automated software diversity. In Pro- ceedings of the 2014 IEEE Symposium on Security and Privacy, pages 276–291, 2014.

[13] A. Homescu, S. Neisius, P. Larsen, S. Brunthaler, and M. Franz. Proﬁle-guided automated software diversity. In Proceedings of the 2013 IEEE/ACM International Symposium on Code Generation and Optimization, pages 1–11, 2013.

[14] J. Xu, Z. Kalbarczyk, and R. K. Iyer. Transparent runtime randomization for security. In Proceedings of the 22nd International Symposium on Reliable Distributed Systems, pages 260–269, 2003.

[15] T. Roeder and F. B. Schneider. Proactive obfuscation. ACM Transactions on Computer Systems (TOCS), 28(2):4:1–4:54, July 2010. ISSN 0734-2071.

[16] A. Avizienisˇ and L. Chen. On the implementation of N-version programming for software fault tolerance during execution. In Proceedings of the IEEE International Computer Software and Ap- plications Conference, pages 149–155, 1977.

[17] D. Evans, A. Nguyen-Tuong, and J. Knight. Effectiveness of moving target defenses. In Moving Target Defense, volume 54, pages 29–48. Springer, 2011.

[18] P. Sousa, A. N. Bessani, M. Correia, N. F. Neves, and P. Verissimo. Highly available intrusion- tolerant services with proactive-reactive recovery. IEEE Transactions on Parallel and Distributed Systems, 21(4):452–465, Apr. 2010.

[19] T. de Raadt. OpenBSD 3.3. http://www.openbsd.org/33.html, 2003. Last time accessed: 2015- 10-20.

[20] A. Homescu, S. Neisius, P. Larsen, S. Brunthaler, and M. Franz. Proﬁle-guided automated software diversity. Proceedings of the 2013 IEEE/ACM International Symposium on Code Generation and Optimization (CGO), pages 1–11, 2013.

[21] R. Roemer, E. Buchanan, H. Shacham, and S. Savage. Return-oriented programming: Systems, languages, and applications. ACM Transactions on Information and System Security (TISSEC), 15 (1):2:1–2:34, Mar. 2012.

[22] A. Freier, P. Karlton, and P. Kocher. The Secure Sockets Layer (SSL) Protocol Version 3.0. RFC 6101, RFC Editor, August 2011.

[23] R. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2):120–126, 1978.

[24] R. L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, RFC Editor, April 1992.

[25] S. Turner and T. Polk. Prohibiting Secure Sockets Layer (SSL) Version 2.0. RFC 6176, RFC Editor, March 2011.

[26] R. Barnes, M. Thomson, A. Pironti, and A. Langley. Deprecating Secure Sockets Layer Version 3.0. RFC 7568, RFC Editor, June 2015.

52 [27] T. Dierks and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246, RFC Editor, August 2008.

[28] B. Beurdouche, K. Bhargavan, A. Delignat-Lavaud, C. Fournet, M. Kohlweiss, A. Pironti, P. Y. Strub, and J. K. Zinzindohoue. A messy state of the union: Taming the composite state machines of tls. In 2015 IEEE Symposium on Security and Privacy, pages 535–552, May 2015.

[29] P. Rogaway. Authenticated-Encryption with Associated-Data. (September), 2002.

[30] Y. Sheffer, R. Holz, and P. Saint-Andre. Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS). RFC 7457, RFC Editor, February 2015.

[31] N. Aviram, S. Schinzel, J. Somorovsky, N. Heninger, M. Dankel, J. Steube, L. Valenta, D. Adrian, J. A. Halderman, V. Dukhovni, E. Kasper,¨ S. Cohney, S. Engels, C. Paar, and Y. Shavitt. DROWN: Breaking TLS with SSLv2. In 25th USENIX Security Symposium, Aug. 2016.

[32] D. Bleichenbacher. Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS #1, pages 1–12. Springer Berlin Heidelberg, Berlin, Heidelberg, 1998. ISBN 978- 3-540-68462-6.

[33] D. Adrian, K. Bhargavan, Z. Durumeric, P. Gaudry, M. Green, J. Halderman, N. Heninger, D. Springall, E. Thome,´ L. Valenta, B. Vandersloot, E. Wustrow, and S. Paul. Imperfect forward secrecy: How Difﬁe-Hellman fails in practice. In Proceedings of the 22nd ACM Conference on Computer and Communications Security, October 2015.

[34] F. Valsorda. Logjam: the latest TLS vulnerability explained. https://blog.cloudflare.com/ logjam-the-latest-tls-vulnerability-explained/, 2015. Last time accessed: 2015-11-13.

[35] B. Moller,¨ T. Duong, and K. Kotowicz. This POODLE Bites: Exploiting The SSL 3.0 Fallback. 2014.

[36] A. Langley. The POODLE bites again (08 Dec 2014). https://www.imperialviolet.org/2014/ 12/08/poodleagain.html, 2014. Last time accessed: 2015-11-13.

[37] B. Moeller and A. Langley. TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Pro- tocol Downgrade Attacks. Internet-Draft draft-ietf-tls-downgrade-scsv-00, IETF Secretariat, July 2014.

[38] R. Seggelmann, M. Tuexen, and M. Williams. Transport Layer Security (TLS) and Datagram Trans- port Layer Security (DTLS) Heartbeat Extension. RFC 6520, RFC Editor, February 2012.

[39] M. Carvalho, J. DeMott, R. Ford, and D. A. Wheeler. Heartbleed 101. IEEE Security Privacy, 12(4): 63–67, July 2014.

[40] A. Menezes, P. van Oorschot, and S. Vanstone. Public-Key Encryption. In Handbook of Applied Cryptography, chapter 8. CRC Press, Inc., 1996.

53 [41] T. Kleinjung, K. Aoki, J. Franke, A. Lenstra, E. Thome,´ J. Bos, P.Gaudry, A. Kruppa, P.Montgomery, D. Osvik, H. Te Riele, A. Timofeev, and P. Zimmermann. Factorization of a 768-bit RSA modulus. In Proceedings of the 30th Annual Conference on Advances in Cryptology, volume LNCS 6223, pages 333–350, 2010.

[42] W. Difﬁe and M. Hellman. New Directions in Cryptography. IEEE Transactions on Information Theory, 22(6):644–654, 1976.

[43] C. Rackoff and D. Simon. Non-Interactive Zero-Knowledge Proof of Knowledge and Chosen Ci- phertext Attack. Advances in Cryptology — CRYPTO ’91 SE - 35, 576:433–444, 1992.

[44] P.Shor. Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer. SIAM Journal on Scientiﬁc and Statistical Computing, 26:1484, 1995.

[45] H. Feistel. Data Encryption Standard (DES). Fips Pub 46-3, 3, 1999.

[46] S. Lucks. Attacking Triple Encryption. Fast Software Encryption, 5th International Workshop, FSE ’98, Paris, France, March 23-25, 1998, Proceedings, 1372:239–253, 1998.

[47] NIST. Recommendation for Key Management - Part 1: General. NIST Special Publication 800-57, Revision 3(July):1–147, 2012.

[48] R. Merkle and M. Hellman. On the security of multiple encryption. Communications of the ACM, 24 (7):465–467, 1981.

[49] V. Rijmen and J. Daemen. Advanced Encryption Standard. U.S. National Institute of Standards and Technology (NIST), 2009:8–12, 2001.

[50] A. Bogdanov, D. Khovratovich, and C. Rechberger. Biclique cryptanalysis of the full AES. In Pro- ceedings of the 17th International Conference on the Theory and Application of Cryptology and Information Security, volume LNCS 7073, pages 344–371, 2011. ISBN 9783642253843.

[51] N. Ferguson, J. Kelsey, S. Lucks, B. Schneier, M. Stay, D. Wagner, and D. Whiting. Improved cryptanalysis of Rijndael. In G. Goos, J. Hartmanis, J. van Leeuwen, and B. Schneier, editors, Proceedings of Fast Software Encryption, volume LNCS 1978, pages 213–230. Springer, 2001.

[52] A. Biryukov, D. Khovratovich, and I. Nikolic.´ Distinguisher and Related-Key Attack on the Full AES- 256. Advances in Cryptology – CRYPTO 2009, 5677:231–249, 2009.

[53] M. Matsui, J. Nakajima, and S. Moriai. A Description of the Camellia Encryption Algorithm. RFC 3713, RFC Editor, April 2004.

[54] A. Kato, M. Kanda, and S. Kanno. Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms. RFC 5528, RFC Editor, April 2009.

[55] A. Kato, M. Kanda, and S. Kanno. Camellia Cipher Suites for TLS. RFC 5932, RFC Editor, June 2010.

54 [56] S. Kanno and M. Kanda. Addition of the Camellia Cipher Suites to Transport Layer Security (TLS). RFC 6367, RFC Editor, September 2011.

[57] C. Blondeau. Impossible differential attack on 13-round Camellia-192. Information Processing Letters, 115(9):660 – 666, 2015. ISSN 0020-0190.

[58] L. Li and K. Jia. Improved Meet-in-the-Middle Attacks on Reduced-Round Camellia-192/256. Cryp- tology ePrint Archive, Report 2014/292, 2014. http://eprint.iacr.org/.

[59] J. Lu, Y. Wei, E. Pasalic, and P.-A. Fouque. Meet-in-the-Middle Attack on Reduced Versions of the Camellia Block Cipher, pages 197–215. Springer Berlin Heidelberg, Berlin, Heidelberg, 2012. ISBN 978-3-642-34117-5.

[60] A. Menezes, P. van Oorschot, and S. Vanstone. Hash Functions and Data Integrity. In Handbook of Applied Cryptography, chapter 9, pages 321–383. CRC Press, Inc., 1996. ISBN 0-8493-8523-7.

[61] X. Wang and H. Yu. How to Break MD5 and Other Hash Functions. In Proceedings of the 24th Annual International Conference on Theory and Applications of Cryptographic Techniques, EURO- CRYPT’05, pages 19–35, Berlin, Heidelberg, 2005. Springer-Verlag. ISBN 3-540-25910-4, 978-3- 540-25910-7.

[62] B. Schneier. SHA-1 freestart collision. https://www.schneier.com/blog/archives/2015/10/ sha-1_freestart.html, 2015. Last time accessed: 2016-01-03.

[63] M. Stevens, P. Karpman, and T. Peyrin. Freestart collision on full SHA-1. Cryptology ePrint Archive, Report 2015/967, 2015.

[64] R. C. Merkle. Secrecy, Authentication, and Public Key Systems. PhD thesis, Stanford, CA, USA, 1979.

[65] X. Wang, Y. Yin, and H. Yu. Finding collisions in the full SHA-1. In Proceedings of the 25th Annual International Conference on Advances in Cryptology, pages 17–36. Springer-Verlag, 2005. ISBN 3-540-28114-2, 978-3-540-28114-6.

[66] M. Stevens. Attacks on Hash Functions and Applications. PhD thesis, Mathematical Institute, Leiden University, 2012.

[67] B. Schneier. When will we see collisions for SHA-1? https://www.schneier.com/blog/archives/ 2012/10/when_will_we_se.html, 2012. Last time accessed: 2016-01-03.

[68] D. Khovratovich, C. Rechberger, and A. Savelieva. Bicliques for Preimages: Attacks on Skein-512 and the SHA-2 family. Cryptology ePrint Archive, Report 2011/286, 2011. http://eprint.iacr. org/.

[69] C. Dobraunig, M. Eichlseder, and F. Mendel. Analysis of SHA-512/224 and SHA-512/256. Cryptol- ogy ePrint Archive, Report 2016/374, 2016. http://eprint.iacr.org/.

55 [70] M. Eichlseder, F. Mendel, and M. Schlaffer.¨ Branching Heuristics in Differential Collision Search with Applications to SHA-512. Cryptology ePrint Archive, Report 2014/302, 2014. http://eprint. iacr.org/.

[71] M. Lamberger and F. Mendel. Higher-Order Differential Attack on Reduced SHA-256. Cryptology ePrint Archive, Report 2011/037, 2011. http://eprint.iacr.org/.

[72] F. Mendel, T. Nad, and M. Schlaffer.¨ Improving Local Collisions: New Attacks on Reduced SHA-256, pages 262–278. Springer Berlin Heidelberg, Berlin, Heidelberg, 2013. ISBN 978-3-642-38348-9.

[73] J. Callas, L. Donnerhack, H. Finney, D. Shaw, and R. Thayer. OpenPGP Message Format. RFC 4880, RFC Editor, November 2007.

[74] E. Fujisaki and T. Okamoto. Secure Integration of Asymmetric and Symmetric Encryption Schemes. Journal of Cryptology, 26(1):80–101, 2013.

[75] K. Kurosawa and Y. Desmedt. A new paradigm of hybrid encryption scheme. CRYPTO 2004, pages 426–442, 2004.

[76] S. Choi, J. Herranz, D. Hofheinz, J. Hwang, E. Kiltz, D. Lee, and M. Yung. The Kurosawa–Desmedt key encapsulation is not chosen-ciphertext secure. Information Processing Letters, 109(16):897– 901, 2009. ISSN 00200190.

[77] W. Difﬁe and M. Hellman. Exhaustive Cryptanalysis of the NBS Data Encryption Standard. Com- puter, 10(6):74–84, June 1977. ISSN 0018-9162.

[78] D. Goldschlag, M. Reed, and P. Syverson. Hiding Routing information. Information Hiding, 1174: 137–150, 1996.

[79] R. Carvalho. Authentication security through diversity and redundancy for cloud computing. Mas- ter’s thesis, Instituto Superior Tecnico,´ Lisbon, Portugal, 2014.

[80] V. Gupta, S. Gupta, S. Chang, and D. Stebila. Performance analysis of elliptic curve cryptography for SSL. In Proceedings of the 1st ACM Workshop on Wireless Security, pages 87–94. ACM, 2002. ISBN 1-58113-585-8.

[81] J. Lee, J. Lee, J. Kim, D. Kwon, and C. Kim. A Description of the ARIA Encryption Algorithm. RFC 5794, RFC Editor, March 2010.

[82] X. Lai and J. L. Massey. A Proposal for a New Block Encryption Standard. pages 389–404. Springer-Verlag, 1991.

[83] A. Afanasiev, N. Nikishin, B. Izotov, E. Minaeva, S. Murugov, I. Ustinov, A. Erkin, G. Chudov, and S. Leontiev. GOST 28147-89 Cipher Suites for Transport Layer Security (TLS). Internet-Draft draft- chudov-cryptopro-cptls-04, IETF Secretariat, December 2008.

[84] A. Popov. Prohibiting RC4 Cipher Suites. RFC 7465, RFC Editor, February 2015.

56 [85] A. Langley, W.-T. Chang, N. Mavrogiannopoulos, J. Strombergson, and S. Josefsson. ChaCha20- Poly1305 Cipher Suites for Transport Layer Security (TLS). Internet-Draft draft-ietf-tls-chacha20- poly1305-04, IETF Secretariat, December 2015.

57 58