Embed Size (px)
Citation preview
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 CorreiaProfessor Miguel Filipe Leitão Pardal
Examination Committee
Chairperson: Professor António Manuel Ferreira Rito da SilvaSupervisor: 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.,
Goncalo, 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 Fundacao 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 con-
cerns 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 se-
curity, 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 certificates 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 comunicacao diverso, redundante e tolerante a vulnerabilidades. Exis-
tem preocupacoes acerca da seguranca de alguns dos mecanismos de cifra usados em canais de
comunicacao SSL/TLS, sendo que alguns desses mecanismos foram considerados inseguros. Estes
mecanismos tem um papel importante na seguranca de redes de comunicacao, incluındo computacao
na nuvem e infraestruturas. VTTLS e a nossa solucao para mitigar o problema de canais de comunicacao
seguros serem vulneraveis a ataques devido a vulnerabilidades inesperadas nos seus mecanismos de
encriptacao. E baseado na diversidade e redundancia de mecanismos criptograficos e certificados para
assegurar uma comunicacao segura mesmo quando um ou mais mecanismos estao vulneraveis. VT-
TLS utiliza uma combinacao de k conjuntos de mecanismos que garantem que, mesmo quando k − 1
conjuntos de mecanismos sao inseguros ou vulneraveis, o canal de comunicacao permanece seguro
devido ao conjunto de mecanismos remanescente. Avaliou-se o desempenho e custo do VTTLS com-
parando os resultados com o OpenSSL, uma implementacao recente de um canal TLS.
Palavras-chave: Protocolos de seguranca; Canais de comunicacao 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 Profile-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 Configuration 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 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 first 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. Defined 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 incom-
patible 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,
file 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 specification, the cryptographic mechanisms used or specific
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 chan-
nels. Its acronym stands for Vulnerability-Tolerant Transport Layer Security. These channels are char-
acterized 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 certificate/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 specific 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 infrastruc-
tures. Despite all their advantages and importance, cloud infrastructures raise privacy, integrity, and se-
curity 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 certificates is not considered significant considering the increase in security
and vulnerability tolerance provided by VTTLS.
1.2 Overview
The rest of the document is organized as follows. Chapter 2 presents the background and related work.
Chapter 3 presents the VTTLS protocol and its implementation. Chapter 4 presents the experimental
evaluation. Chapter 5 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 in-
formation 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 vul-
nerabilities 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 final 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-
fied 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
profile-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 im-
prove 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 difficult to maintain and to track possible issues in it.
2.1.3 Profile-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 diversifies 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 flow 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 profiled 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 configuration 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 first version of SSL, SSL 1.0, was
never publicly released due to its several security flaws 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 authen-
tication 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 flaws 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 specification is regarded as a historic document for the
Internet community. Among other improvements, SSL 3.0 allowed forward secrecy using Diffie-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 first version of TLS, TLS 1.0, defined
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 flaws 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 influence 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 identifier, 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 field.
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
identifier, 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 certificate chain to the client using a CERTIFICATE message. This message is sent nearly at
all times as server’s certificates play a major part in the establishment of a secure channel.
If the server’s certificate 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 com-
posed 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 first sequence of mes-
sages.
After receiving the SERVERHELLODONE message, the client sends its certificate to the server if
requested. If the client does not send its certificate 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 Diffie-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 certificate.
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 specific
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 verifies the success of
the key exchange and the authentication. This is the first encrypted message sent by the client to the
server.
After receiving the CHANGECIPHERSPEC message, the server sends a CHANGECIPHERSPEC mes-
sage 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 first 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 com-
pressed 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 Configuration 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 confidentiality 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 SecureRSA RSA key exchange algorithm 7 3
DH-RSA DH with DSS-based certificates 7 3
DH-DDS DH with DSS-based certificates 7 3
DHE-DSS Ephemeral DH with DDS (DSA) signatures 3 3
DHE-RSA Ephemeral DH with RSA signatures 3 3
DH-anon Anonymous DH without signatures 7 7
ECDH-RSA Elliptic curve Diffie-Hellmanwith RSA signatures 7 3
ECDH-ECDSA Elliptic curve Diffie-Hellmanwith ECDSA (variant of DSA) 7 3
ECDHE-RSA Ephemeral elliptic curve Diffie-Hellmanwith RSA signatures 3 3
ECDHE-ECDSA Ephemeral elliptic curve Diffie-Hellmanwith ECDSA (variant of DSA) 3 3
RSA-PSK Pre-shared key exchange with RSA 7 3
DHE-PSK Pre-shared key exchange with ephemeral DH 3 3
ECDHE-PSK Pre-shared key exchange with ECDHE 3 3
ECDHE-anon Anonymous ECDHE without signatures 7 7
Table 2.1: Key exchange algorithms supported by TLS 1.2. If the algorithm provides forward secrecy, itis marked with a (3) in the third column. In case the algorithm is regarded as insecure, it is marked witha (7) in the Secure column.
Cipher RFC Mode of operation Type Bits Secure
AES5288 GCM (Galois/Counter Mode)
Block 128, 2563
6655 CCM (Counter with CBC-MAC) 3
- CBC (Cipher block chaining) 3
3DES EDE - CBC Block 112 Weak
Camellia 6367 GCM Block 128, 256 3
5932 CBC 3
ARIA 6209 GCM Block 128, 256 3
6209 CBC 3
SEED 4162 CBC Block 128 3
RC4 - ——— Stream 128 7
Table 2.2: Symmetric-key cipher algorithms supported by TLS 1.2. The Bits column refers to the strengthof the algorithm. In case the algorithm is regarded as insecure, it is marked with a (7) in the Securecolumn. 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 foundHMAC-MD5 MD5 128 3
HMAC-SHA1 SHA (SHA-1) 160 7
HMAC-SHA256 SHA-256 (SHA-2) 256 7
HMAC-SHA384 SHA-384 (SHA-2) 384 7
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 modified 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 possi-
ble. 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 al-
lowed 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 spec-
ification 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 Diffie-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 dep-
recating 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 correct-
ness. 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 mech-
anisms, specifically 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 mecha-
nisms 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 five 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 benefits 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 first rounds of
Camellia, Camellia is still a secure symmetric encryption function which can be used in secure commu-
nication 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 fingerprint, 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 finite length to an output h(s) of a fixed 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 find any second input string which has
the same hash as any specified input string, i.e. given s1, finding s2 6= s1, where h(s1) = h(s2).
• collision resistance – it is computationally infeasible to find two input strings whose hash is identi-
cal, i.e. finding 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 find collisions from 280 to 269 [65]. The researchers claim that this was the first 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 ap-
proaches 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 mecha-
nisms 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 fixed size while stream ciphers are character-
ized 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 ap-
proaches 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 se-
cure. 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 first 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. Diffie 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 mecha-
nisms. 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 certificates. 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, Section 2
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 nego-
tiates more than one cipher suite between client and server and, consequently, more than one crypto-
graphic mechanism will be used for each phase: key exchange, authentication, encryption and MAC.
Diversity and redundancy appear firstly 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 certificates 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 perfor-
mance 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 Specification
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 simplification, 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 first 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 identifier, 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 identifier, 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 cer-
tificates 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 certificates, with 0 < c ≤ k . The cipher suites to be used
are chosen considering the available certificates. 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 certificates to the
server, analogous to the (SERVER) CERTIFICATE message the client received previously from the server.
After sending its certificates, 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 andredundancy 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 finish the Handshake, the client and server send each other a FINISHED message. This
is the first message sent encrypted using the k cipher suites negotiated earlier. Its purpose is to each
35
Designers Year Digest Size Structure RoundsAEAD (GCM) McGrew, D., and Viega J. (U.S.A.) 2005-2009 Does not applySHA-2 (SHA-384)
NIST (U.S.A.) 2000 384 bits
Merkel-Damgard
80SHA-2 (SHA-256) 256 bits 64SHA-1 1993 160 bits 80MD5 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 mech-
anisms, 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 difficult to affirm 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 mecha-
nisms 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 mech-
anisms as TLS, more specifically 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 cre-
ated or designed the function) and their country of origin, the year when it was first published, the digest
size, the structure, the number of rounds, the properties (collision, preimage, and second preimage re-
sistant), 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 con-
sidered 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 first 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 relevantknown attacks
(number of rounds attacked)Collisionresistant
Preimageresistant
Second preimageresistant
AEAD (GCM) Yes Yes Yes
SHA-2 (SHA-384) Yes Yes Yes Biclique attack (57),Meet-in-the-middle attack (46)
SHA-2 (SHA-256) Yes Yes YesBiclique attack (52),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 met-
rics 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 or-
der to increase security, we prioritize mechanisms which grant PFS. After PFS, we prioritize mechanisms
with disjoint mathematical hard problems.
Table 3.3 demonstrates the first set of metrics used to assess diversity among public-key mecha-
nisms 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 difficult 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 con-
clude that the best three combinations are:
37
Designers Year MathematicalHard Problem
Perfect ForwardSecrecy
SemanticSecurity
RSA
Rivest, R.,and Shamir, A.,and Adleman, L.(U.S.A. and Israel)
1977 Integer Factorisation Problem NoYes (Using a randomencryption paddingscheme)
ECDH(E)Miller, V.,and Koblitz, N.(U.S.A.)
1985 Elliptic-curve discrete logarithm problem Yes (If used withephemeral keys) No
DH(E)Diffie, W.and Hellman, M.(U.S.A.)
1976 Discrete Logarithm Problem Yes (If used withephemeral keys) No
ECDSA Vanstone, S.(Canada) 1992 Elliptic-curve discrete logarithm problem Yes No
DSA NIST(U.S.A.) 1991 Discrete Logarithm Problem Yes No
Table 3.3: VTTLS public-key encryption functions’ diversity metrics
Known attacks
RSA Chosen plaintext attack, Chosen ciphertext attack, Adaptive chosen ciphertext attack,Coppersmith’s attack, Hastad’s broadcast attack
ECDH(E) Man-in-the-middle attack, Menezes-Okamoto-Vanstone (MOV) attack, Frey-Rueck attack,Pollard’s rho method, Weil descent attack
DH(E) Man-in-the-middle attack, Logjam attack
ECDSA Menezes-Okamoto-Vanstone (MOV) attack, Frey-Rueck attack, Pollard’s rho method,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 authenti-
cation. However, TLS 1.2 specific 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
first 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
Type Mode ofOperation Designers Year Strength
(in bits) RoundsBlocksize(in bits)
Structure Status
AES
Block
GCM Rijmen, V.,and Daemen, J.(Belgium)
1998
256 14
128Substitution--permutationnetwork
Secure128 10
CBC 256 14128 10
Camellia CBC Mitsubishi Electric,and NTT (Japan) 2000 256 24 128 Feistel network Secure128 18
SEED CBC KISA (South Korea) 1998 128 16 128 Nested Feistelnetwork Secure
ARIA(Not availablein VTTLS)
GCM Large groupof researchers(South Korea)
2003
128 12
128Substitution--permutationnetwork
Secure256 16 Secure
CBC 128 12 Secure256 16 Secure
3DES EDE CBC IBM(U.S.A.) 1998 112 48 64 Feistel network Low
strength
Table 3.5: VTTLS symmetric encryption mechanisms’ diversity metrics
Known attacksAES XSL attack, Biclique attack
Camellia Impossible differential attack, Cache timing attack, Collision attack,High-order differential attack, Differential attack, Square attack
SEED Differential attackARIA (Not availablein VTTLS) Meet-in-the-middle attack, Impossible differential attack, Boomerang attack
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 specific 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, di-
versity 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 diversified 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 modification of OpenSSL v1.0.2g.1 Implementing a secure communi-
cation 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 and1https://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 first to last:
1. Apply the first MAC to the plaintext message;
2. Encrypt the first message and its MAC with the first encryption function;
41
Figure 3.3: First four steps regarding the ordering of the encryption and signing of VTTLS using adiversity factor k = 2.
3. Apply the second MAC to the first ciphertext;
4. Encrypt the first 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 final 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 fixed 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 fixed block size.
42
Figure 3.4: Remaining three steps regarding the ordering of the encryption and signing of VTTLS usinga diversity factor k = 2. Here is represented the second signing and the second encryption, employingdiversity 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 verified 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 sufficient). 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 configured
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 Confidence interval (95%)VTTLS 3.909 0.963 0.180OpenSSL 2.345 0.933 0.174
Table 4.1: Comparison of average Handshake length
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
1 MB 10 MB 50 MB 100 MB 500 MB 1 GB
Tim
e (m
illis
eco
nd
s)
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 andOpenSSL.
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 gen-
erated by the diversity and redundancy of mechanisms. As the Handshake, the communication is ex-
pected 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 SendAverage St. dev. Conf. I. (95%) Average St. dev. Conf. I. (95%)
1 MB 12.8 3.324 0.652 11.28 3.985 0.78110 MB 105.89 17.573 3.444 76.61 10.413 2.04150 MB 534.55 149.697 29.340 435.01 212.065 41.564100 MB 1004.3 194.701 38.161 757.02 206.709 40.514500 MB 4579.4 727.519 142.591 2834.18 217.378 42.6051 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 ReceiveAverage St. dev. Conf. I. (95%) Average St. dev. Conf. I.(95%)
1 MB 14.7 3.324 0.652 13.48 3.985 0.78110 MB 113.41 17.573 3.444 80.42 10.413 2.04150 MB 549.61 149.697 29.340 443.1 212.065 41.564100 MB 1004.54 194.701 38.161 757.13 206.709 40.514500 MB 4580.13 727.519 142.591 2834.37 217.378 42.6051 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
Messagesize
VTTLS OpenSSL Overhead (difference)Encryptedmessage size
Average #packets
Encryptedmessage size
Average #packets Packets Message size
100000 102,771 6.3 102,603 5.3 1 168
1000 000 1,029,054 38.3 1,025,856 37.6 0.7 3,198
100000 000 105,362,077.10 2,830.2 104,956,194.50 2,553.5 276.7 405,883
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 defined 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 difficult. 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 certificates, 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 implemen-
tation 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 specific 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 avail-
able 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 improve-
ment 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. Profile-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. Profile-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 Diffie-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. Diffie 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 Scientific 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. Diffie 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
