Ville Vehkaoja END-TO-END ENCRYPTION PROTOCOL for INTERNET of THINGS DEVICES

Home , Cryptographic primitive, PKCS, Silent Circle (software)

FACULTY OF INFORMATION TECHNOLOGY AND ELECTRICAL ENGINEERING

Ville Vehkaoja

END-TO-END ENCRYPTION PROTOCOL FOR INTERNET OF THINGS DEVICES

Master’s Thesis Degree Programme in Computer Science and Engineering May 2017 Vehkaoja V.(2017) End-to-end encryption protocol for Internet of Things devices. University of Oulu, Degree Programme in Computer Science and Engineering. Mas- ter’s thesis, 38 p.

ABSTRACT

Secure communication is an important requirement for many applications, even if the communicating devices are resource-constrained. The emergence of Inter- net of Things (IoT) has also raised the demand for low-power devices that can communicate with each other or send data to a central location for processing. Commonly used protocols that provide secure messaging to different applications are reviewed in this document. Some IoT applications are also described to provide more context and different types of attacks against IoT systems are also brieﬂy presented. An encrypted messaging protocol employing the Double Ratchet Algorithm is described and the protocol implementation evaluated and compared to a simple reference protocol implementation. The results show that the protocol has improved backward secrecy and forward secrecy properties compared to commonly used protocols at the cost of slightly decreased performance and a relia- bility trade-off. Different cryptographic primitives and their suitability for use in the protocol are also evaluated.

Keywords: Double Ratchet Algorithm, cryptographic key compromise Vehkaoja V.(2017) Päästä päähän -salausprotokolla esineiden internetin laitteille. Oulun yliopisto, tietotekniikan tutkinto-ohjelma. Diplomityö, 38 s.

TIIVISTELMÄ

Turvallinen kommunikointi on tärkeä vaatimus monille sovelluksille vaikka kom- munikoivilla laitteilla olisikin vain hyvin rajallinen määrä resursseja käytettävis- sään. Esineiden internetin syntyminen on myös nostanut kysyntää pienitehoisille laitteille, jotka voivat kommunikoida toistensa kanssa tai lähettää dataa keskei- seen sijaintiin prosessoitavaksi. Tässä dokumentissa arvioidaan yleisesti käytettyjä protokollia, jotka toteutta- vat turvallisen kommunikaation erilaisissa sovelluksissa. Myös joitakin esineiden internetin sovelluksia ja erilaisia hyökkäyksiä niitä vastaan esitetään. Dokumentissa myös kuvaillaan viestintäprotokolla, joka käyttää Double Ratc- het Algoritmia. Protokollan toteutus arvioidaan ja sitä vertaillaan yksinkertai- seen vertailuprotokollaan. Tulokset näyttävät esitetyn protokollan toteuttavan yleisesti käytettyjä protokollia paremmat backward secrecy- ja forward secrecy -ominaisuudet vähäisellä suorituskyvyn laskun, ja joissakin tapauksissa luotetta- vuuden, kustannuksella. Myös erilaisia kryptograﬁsia primitiivejä ja niiden so- veltuvuutta protokollassa käytettäväksi arvioidaan.

Avainsanat: Double Ratchet Algoritmi, kryptograﬁsen avaimen vaarantuminen TABLE OF CONTENTS

ABSTRACT

TIIVISTELMÄ

TABLE OF CONTENTS

FOREWORD

ABBREVIATIONS

1. INTRODUCTION 6

2. LITERATURE REVIEW 7 2.1. A general overview of cryptography ...... 7 2.1.1. Symmetric-key cryptography ...... 7 2.1.2. Public-key cryptography ...... 9 2.1.3. Cryptographic hash functions ...... 10 2.2. Internet of Things ...... 12 2.3. Related work ...... 13

3. PROTOCOL REQUIREMENTS 15 3.1. Protocol usage ...... 15 3.2. Threat model ...... 15 3.3. Security requirements ...... 16 3.4. Resource usage requirements ...... 17

4. PROTOCOL DESCRIPTION 18 4.1. Session initialisation ...... 18 4.2. Double Ratchet Algorithm ...... 21

5. EVALUATION 26 5.1. Security requirements ...... 26 5.2. Cryptographic primitives ...... 28 5.3. Implementation ...... 30

6. DISCUSSION 32

7. SUMMARY 33

8. REFERENCES 34 FOREWORD

The aim of this master’s thesis is to review encrypted communication protocols and to present their importance to Internet of Things, and to present a protocol that improves upon commonly used protocols. I would like to thank my thesis supervisor Juha Par- tala, second examiner Olli Silven, and technical supervisor Srikanth Kyatham for their involvement in the process of writing this thesis.

Oulu, Finland May 16, 2017

Ville Vehkaoja ABBREVIATIONS

IoT Internet of Things IV initialisation vector CBC Cipher Block Chaining CTR counter mode GCM Galois/Counter Mode AES Advanced Encryption Standard DSA Digital Signature Algorithm ECDSA Elliptic Curve Digital Signature Algorithm ECDH elliptic curve Difﬁe–Hellman SHA Secure Hash Algorithm MAC message authentication code HMAC hash-based message authentication code KDF key derivation function HKDF HMAC-based Extract-and-Expand Key Derivation Function PBKDF2 Password-Based Key Derivation Function 2 NFC Near ﬁeld communication OSI Open Systems Interconnection E2EE end-to-end encryption IP Internet protocol IPsec Internet Protocol Security TLS Transport Layer Security DTLS Datagram Transport Layer Security UDP User Datagram Protocol DCCP Datagram Congestion Control Protocol TCP transmission control protocol CoAP Constrained Application Protocol MQTT Message Queue Telemetry Transport 6

1. INTRODUCTION

Internet of Things (IoT) has become to refer to a wide range of different technologies, services and standards, which can make the term somewhat intangible despite the no- tion that all of the IoT concepts share the same idea: establishing networks of concrete smart objects. These objects are able to interact with the physical world by gather- ing data using sensors or controlling different systems, as well as communicating with each other. The emergence of ubiquitous devices of which a signiﬁcant part can receive or transmit conﬁdential data has security implications which should be taken into account when designing new IoT systems. In the same time these systems can be constrained by scarce computation resources, available memory, and the requirement for low power usage. Especially embedded devices relying on a battery as a power supply require use of lightweight processes for energy conservation. The development of robust solutions in terms of hardware as well as software is important for ensuring the security of IoT systems. Different types of attacks on IoT systems comprise physical attacks, side channel attacks, cryptanalysis attacks, software attacks and network attacks [1]. All of the aforementioned domains for attacks are relevant for continuing research and engineering work, and a general overview of each one is given later in this document. The focus of this work is in securing the IoT communications over potentially untrusted networks and limiting the effectiveness of attacks that compromise cryptographic keys used to encrypt the communications. An encrypted messaging protocol for IoT devices addressing these issues is presented in this document. 7

2. LITERATURE REVIEW

2.1. A general overview of cryptography

This section gives a general overview of cryptographic techniques and their properties, and how they can be used to create secure communication channels. Common cryptographic primitives are described, which are also required to implement the encryption protocol presented later in this document. A cryptographic primitive is a fundamental mathemathical construct that can be combined with other primitives to form cryptographic protocols, also known as cryptosystems. Common cryptographic primitives include encryption algorithms, key-agreement protocols, cryptographic hash functions and pseudo-random number generators.

2.1.1. Symmetric-key cryptography

A Symmetric-key algorithm is an algorithm that encrypts and decrypts data using the same key, i.e., it uses plaintext and a key to produce ciphertext, or ciphertext and a key to produce plaintext [2 p.4]. This means that both the sender and the receiver of an encrypted message share the same key, and can communicate securely over an insecure channel like the public internet given that only they know the key and that the symmetric-key algorithm is secure, i.e., it is not susceptible to cryptographic attacks. Cryptographic attacks can be constructed by exploiting a ﬂaw in the encryption algorithm itself or in its implementation, and are studied by the ﬁeld of cryptanalysis. Figure 1 illustrates the usage of a symmetric-key algorithm.

Figure 1. Symmetric encryption and decryption.

Symmetric-key algorithms can be categorised as either block ciphers or stream ciphers, although, a block cipher can be used as a stream cipher. A block cipher operates on fixed-length blocks of data, whereas a stream cipher combines the data stream with a cipher digit stream, also known as a keystream. When using a block cipher it is required to pad the message so that its length is a multiple of the cipher block size, which may be inefficient in the case of short messages. This can be avoided by using certain block cipher modes of operation or techniques such as ciphertext stealing [3]. Stream ciphers avoid this disadvantage as the cipher digit is typically a bit. In addition to a secret key, both types of ciphers typically require an initialisation vector (IV) which is a fixed-length bit sequence and usually required to be random or pseudo-random. IV 8 is used to achieve semantic security which means that repeatedly using the same key for encryption does not yield any feasibly extractable information about the encrypted message. Block cipher modes of operation describe how to use a block cipher to securely encrypt arbitrarily long messages. A simple and commonly used mode of operation is Cipher Block Chaining (CBC) which is presented in Figures 2 and 3. Examples of other modes include counter mode (CTR) which turns a block cipher into a stream cipher, and Galois/Counter Mode (GCM) which provides message authentication in addition.

Figure 2. Cipher Block Chaining (CBC) mode encryption. ⊕ denotes XOR operation.

Figure 3. Cipher Block Chaining (CBC) mode decryption. ⊕ denotes XOR operation.

An example of a commonly used block ciphers is the Rijndael family of which a subset is standardised as the Advanced Encryption Standard (AES) [4]. An example of stream ciphers is Salsa20 [5]. 9

2.1.2. Public-key cryptography

Key management is a common problem that is difﬁcult to solve using symmetric- key cryptography alone since the keys have to be distributed over a secure channel. Public-key cryptography addresses this issue by using schemes in which there are two mathemathically related keys, a private key and a public key. The private key is known only by the key owner, and the public key can be revealed to anyone. A random number generator or a cryptographically secure pseudo-random number generator is required for the generation of key pairs. A widely used public-key algorithm is RSA [6] which can be used for encrypting the message with the public key and decrypting it with the corresponding private key as illustrated in Figure 4. RSA can also be used to digitally sign messages by encrypting them with the private key and using the corresponding public key for decryption, verifying that the message was indeed encrypted with the private key. However, in practice a hash value of the message is encrypted instead of the message itself as encrypting the message has been shown to be insecure [7]. This method is also faster and produces a shorter signature, and is presented in Figure 5. Hash functions are described in the next subsection. Other signature algorithms include the Digital Signature Algorithm (DSA) and the Elliptic Curve Digital Signature Algorithm (ECDSA) [8].

Figure 4. Asymmetric encryption and decryption.

Figure 5. Digital signature scheme.

Other commonly used public-key algorithms include key-agreement protocols in which the public keys are exchanged between the remote parties and combined with 10 their private keys to calculate a shared secret as illustrated in Figure 6. Examples of such systems include the Difﬁe–Hellman key exchange [9] that is in use to this day and its newer variant elliptic curve Difﬁe–Hellman (ECDH) [10].

Figure 6. Key-agreement protocol.

2.1.3. Cryptographic hash functions

A cryptographic hash function is an algorithm that maps an arbitrarily long sequence of input data commonly called a message to a fixed-length sequence of bits often called a hash value [2 p.293]. It is also cryptographically secure which means that it must ful- fill a set of required properties to be deemed secure for cryptographical applications. The properties are pre-image resistance, second pre-image resistance and collision resistance. Pre-image resistance means that it is computationally infeasible to obtain a message given its corresponding hash value. Ideally the only way to invert the function is to perform an exhaustive search for all the possible inputs. Second pre-image resistance means that it is infeasible to find a message hashing to the same value as a given message. Collision resistance is the property is that it is infeasible to find a hash collision, i.e., any two different messages with the same hash output value. The process of hashing various hexadecimal input strings using SHA-256 algorithm is illustrated in Figure 7. 11

Figure 7. SHA-256 maps input values to 32-byte hash values.

Cryptographic hash functions have many applications in information security such as verifying the integrity of files, file identifiers, password verification, construction of message authentication codes, proof-of-work systems and key derivation functions. Examples of widely used cryptographic hash functions are the SHA-2 family; a set of functions with varying hash value lengths [11]. Other prominent algorithms include the Keccak family (SHA-3) [12] and BLAKE2 [13].

Message authentication codes

A message authentication code (MAC) is a short code used to verify that the message it is used to authenticate has not been modiﬁed in transit and that it came from the stated sender [14]. A MAC algorithm produces a MAC for a given message using the message itself and a secret key known to both the sender and the recipient. The recipient can generate the same code and compare it to the received code to conﬁrm that the received message is the one that was sent and that the sender knows the key. The described process is illustrated in Figure 8. This process is possible because a secure MAC is unforgeable, meaning that it is computationally infeasible to produce a valid MAC without knowing the secret key. A commonly used MAC utilising a cryptographic hash function is keyed-hash message authentication code (HMAC) [15]. 12

Figure 8. Message authentication scheme.

Key derivation functions

A key derivation function (KDF) uses a pseudo-random function to derive secret key material from a secret value such as a password or a shared secret obtained using a key- agreement protocol [16]. This pseudo-random function can be a cryptographic hash function. KDFs are useful in deriving strong keys from short or otherwise weak secret values. The resulting key material can be used as keys in, e.g., symmetric encryption and message authentication codes. A simple HMAC-based KDF is the HMAC-based Extract-and-Expand Key Deriva- tion Function (HKDF) [17]. HKDF uses the "extract-then-expand" paradigm which comprises two stages. In the extract-stage a ﬁxed-length pseudo-random key is ex- tracted from the input material and in the expand-stage the key is expanded to the desired output length using iterations of the HMAC function. HKDF is suitable for a wide variety of applications but a slowing down mechanism is not a part of the spec- iﬁcation. This may make other KDFs such as Password-Based Key Derivation Func- tion 2 (PBKDF2) [16] more preferable when using a password as the input material. However, HKDF is ideal for the purpose of deriving enough strong key material from automatically generated shared secrets in encrypted communication protocols.

2.2. Internet of Things

The most potential application domains for IoT are transportation and logistics, healthcare, and smart environments [18]. However, actual implementations of these applications are at varying stages of development. The actual devices used by the domains can vary significantly in size and capabilities but they all share the principle of machine- to-machine communication. Transportation and logistics can utilise IoT in, e.g., monitoring road and rail conditions, monitoring the status of individual units of cargo, and traffic routing. For example, different sensors along a route can transmit information about temperature, 13 humidity and light conditions to interested parties. Near field communication (NFC) tags can be attached to transported goods for identification and tracking. Vehicles can communicate with each other as well as other devices along the roads to avoid collisions and traffic congestion. Healthcare can benefit from IoT by having cheap and small devices for identification and tracking to improve workflows as well as health monitoring. For example, real- time tracking of personnel, patients, tools, and materials in hospitals can improve time management and reduce errors. Devices can also automatically monitor the health status of individuals and alerting necessary parties when detecting a condition that requires treatment. Smart environments include homes, offices, public spaces and industrial facilities that are equipped with devices that can improve comfort and energy-efficiency, and reduce accidents. For example, heating and lighting can adapt to the weather, the time of the day, and the preferences of individuals. Electrical equipment can also be automatically turned on when their usage is predicted or off when not used. The usage of proper encryption methods is important but different for all of the application domains. For example, devices that generate or operate on data that is critical to road safety need to be tamper-resistant in addition to proper authentication and communication encryption. Devices that monitor health of an individual may have to operate on very little power without making it possible to compromise or forge critical data. Devices monitoring or even being in control of personal everyday items and equipment need to be secured according to their privacy considerations as well as their ability of causing physical damage if compromised.

2.3. Related work

Several encrypted communication protocols have been designed to operate on different Open Systems Interconnection model (OSI) [19] layers. Encrypting the network traffic on data link layer means that the devices routing the traffic decrypt it as they receive it and encrypt it again when transmitting to the next routing device. This has some use cases in certain setups like sensor networks that are under reasonable control [20] but routing devices having access to cleartext traffic renders it unusable for securing communications over the public internet where the routing devices cannot be trusted with unencrypted data. An example of data link layer encryption is the Point-to-Point Encryption Control Protocol [21]. Achieving end-to-end encryption (E2EE) in the internet requires the routing information like IP addresses and ports to be visible to intermediate routing nodes, and encrypting only the payload data. In a E2EE system only the communication endpoints are in possession of the cryptographic keys needed to decrypt the messages. This means that the underlying transport of messages does not need to be trusted at any point, including any service providers. A viable approach is to encrypt the traffic on the network layer using protocol suites like Internet Protocol Security (IPsec) [22] which provides the possibility for E2EE. The most flexible and practical option to provide E2EE would be to implement the encryption protocol at application layer, of which the widely used Transport Layer Se- curity (TLS) [23] and Datagram Transport Layer Security (DTLS) [24] are examples. 14

TLS uses a handshake protocol to negotiate connection details such as which cryptographic algorithms to use. TLS also uses X.509 certificates [25] for authentication, and provides many additional functions that all add overhead with memory consumption overhead being most significant. DTLS is based on the TLS protocol and standardised independently. It is typically used with datagram protocols such as User Datagram Protocol (UDP) [26] and Datagram Congestion Control Protocol (DCCP) [27] instead of stream-oriented protocols such as TCP [28]. The Constrained Application Protocol (CoAP) [29] is designed for resource-constrained devices and makes use of DTLS to provide end-to-end encryption. Message Queue Telemetry Transport (MQTT) [30] is an another messaging protocol similar to CoAP but its specification omits encryption completely to keep it lightweight, and leaves it to be implemented at the application layer if desired. The existing encryption protocols are inadequate in terms of resource usage [31] and security properties which calls for an improved solution. Security properties such as forward secrecy and backward secrecy (also known as future secrecy) are becoming more important and recognised in the field [32, 33, 34]. Forward secrecy is a property in which compromise of cryptographic keys does not compromise past keys or messages corresponding to past keys. Backward secrecy is the property in which compromise of cryptographic keys does not compromise future keys or messages. The aforementioned encryption protocols can provide session level forward secrecy which may be acceptable in the case of relatively short sessions but becomes problematic if the session can last for months or even years. Some encrypted chat messaging protocols have attempted to improve on these features such as Off- the-Record Messaging [35], Silent Circle Instant Messaging Protocol [36] and Signal Protocol [37]. The Double Ratchet Algorithm [38, 39] introduced as a part of Signal Protocol provides a strong variation of these features: individual message level forward secrecy and message round trip level backward secrecy [40]. The Double Ratchet Algorithm is also used as the core part of the protocol presented in this document. 15

3. PROTOCOL REQUIREMENTS

3.1. Protocol usage

The encryption protocol is designed to work in a client-server model where a client can start an encrypted session with a server. Multiple clients can have their own encrypted session with the server but can not communicate with other clients. If client-to-client communication is required for some use cases, it must be implemented on top of the encryption protocol. If client-to-client end-to-end encryption is required, nothing pre- vents a pair of clients using the same encryption protocol between them and treating the original server as a traffic intermediary if needed. The server generates and stores a long-term private key which it uses to provide authentication. Initialising an encrypted session requires that the server’s corresponding public key is pre-distributed to the client over a secure channel, i.e., distributing a configuration file together with the client software or even embedding the key in the client software. In this way all clients can verify the server’s identity but the clients do not have a pre-determined identity, i.e., knowing the server’s public key is enough to act as a client. The protocol can be trivially adapted to provide individual client authentication if desired, however, this requires the clients to store their own long-term private keys and the corresponding public keys to be stored on the server. The encryption protocol is designed for devices which are not extremely constrained by computational or memory resources meaning that even a small improvement in limiting the effects of a key compromise at the cost of increased protocol complexity is desirable, i.e., the proportion of resources allocated for the encryption protocol is relatively small. Typically, but not necessarily, the client devices would be embedded systems such as single-board computers and the server would be a central, more capa- ble system handling multiple sessions with different client systems. A message broker forwards messages between the clients and the server in a typical use case.

3.2. Threat model

Attacks on IoT devices

Physical attacks have a direct physical access to the target hardware and can be ex- pensive and difficult against well secured systems but ultimately have the potential to compromise a system completely. A physical attack can be as simple as just accessing a system using a compromised password or a private key. If the system does not have an easily accessible direct interface or it can not be used for some reason, an attacker could read the process memory using a micro-probe on a chip memory bus [41]. How- ever, in some cases even otherwise successful physical attacks can be prevented from exposing any confidential data by renewing the cryptographic keys used in data trans- fers. The encrypted messaging protocol presented in this document addresses some of these cases. Side channel attacks use side channel information obtainable from the device such as timing information, radiation or power consumption that is related to the encryption process. These characteristics can potentially be used to reveal the encryption key as 16 they depend on the input data of the encryption process. Some side channel attacks are fundamentally different from physical attacks by not requiring close proximity to the device such as a timing attack employed over a network. Cryptanalysis attacks attempt to break the encryption using partial knowledge about plaintexts, ciphertexts and keys in combination of exploiting a flaw in the encryption algorithm. Although such attacks can be carried out with smaller computational resources than a brute force attack, they are often quite theoretical and computationally infeasible. Software attacks can be carried out by exploiting the security vulnerabilities of a system’s own communication interface. For example, a server processing queries may answer to a deliberately crafted malicious request and yield private information. An another example would be a replay attack where valid messages are recorded and sent again to either disrupt the communication or to obtain secret information as a response. Network attacks can be classified as passive and active attacks. An example of passive attacks is traffic analysis and example of active attacks include denial of service, node malfunction, node capture, false nodes, and message corruption.

Attacks to be considered

In a typical use case, all encrypted trafﬁc goes through the public internet as well as a service provider operating a message broker. The service provider is also assumed to be potentially malicious and to attempt to read the contents of encrypted trafﬁc. The encryption protocol should be resistant against side channel attacks and software attacks. Network attacks are considered and potential threats evaluated and mitigated if possible. The effects of succesful physical attacks and cryptanalysis attacks are mitigated as well as possible but preventing physical attacks themselves is out of scope of this work. The communication end-points are assumed to be secure prior to being compromised by a physical attack.

3.3. Security requirements

The following security requirements are set for the encryption protocol: authentication of communicating devices, message conﬁdentiality, message integrity, protection against replay attacks, forward secrecy, and backward secrecy. Authentication of communicating devices means that the parties can verify that they are communicating with the intended recipient and that it should be computationally infeasible for an attacker to masquerade as a sender. Message conﬁdentiality means that it should be computationally infeasible for an attacker to gain any partial information on the contents of an encrypted message without knowledge of cryptographic keys used in communication. Message integrity means that the recipient should be able to verify that the received message is the same that was sent by the sender. Protection against replay attacks means that a replay attack can not disrupt or compromise the communication. For- ward secrecy means that if a long-term private key is compromised, no past messages are revealed. This requirement applies to keys used for the encryption of messages 17 as well. Backward secrecy means that the compromise of a key used for message encryption does not compromise future keys or messages.

3.4. Resource usage requirements

In terms of resource usage, the encryption protocol should primarily minimise the usage of both volatile and non-volatile memory resources, as well as the usage of network bandwidth. Minimising energy usage is desirable as well with a lower priority. How- ever, fullﬁlling the security requirements has the priority over fullﬁlling the resource usage requirements. 18

4. PROTOCOL DESCRIPTION

The encryption protocol is based on the Double Ratchet Algorithm which combines two cryptographic ratchets; a Difﬁe-Hellman ratchet based on the Difﬁe-Hellman key exchange or a variant of it, and a hash ratchet based on a cryptographic hash function. The protocol presented here requires the following cryptographic primitives: a key- agreement protocol, a symmetric-key algorithm and a cryptographic hash function. The key-agreement protocol is used to establish shared secrets. The symmetric-key algorithm is used to encrypt and decrypt protocol messages. The hash function is used to derive certain cryptographic keys. Additionally, a message authentication code and a key derivation function are needed. The encryption protocol uses a client-server model where a client can start an encrypted session with a server. The server stores a private key which it uses to provide authentication. Initialising an encrypted session requires that the server’s corresponding public key is pre-distributed to clients over a secure channel. In this way all clients can verify the server’s identity but the clients are not authenticated during the session initialisation. The protocol can be trivially adapted to provide individual client authentication if desired. Only the case where the server is authenticated is presented here.

4.1. Session initialisation

The encryption protocol message format is comprised of 4 fields: a context byte that indicates the possible presence of an ephemeral public key and if a given message is a session initialisation message, an optional ephemeral public key, a MAC and an encrypted message payload. Since the length for all of the fields except the message payload is fixed, the payload length can be calculated without additional information. An example implementation with defined field byte lengths is presented in Figure 9.

Figure 9. Message format using example ﬁeld byte lengths.

First, the client generates an ephemeral key pair and sends the public key to the server. Next, the server generates its own ephemeral key pair and computes the initial shared secret using its private identity key, the new private ephemeral key and the client’s public key. The server constructs its initial session state and sends the client a reply containing server’s ephemeral public key and a MAC generated using the shared secret. After receiving the message, the client computes the initial shared secret using its private ephemeral key and the server’s public identity and ephemeral keys. The client veriﬁes the authenticity of the server’s ephemeral public key by generating the MAC using the shared secret and checking it against the received code. Finally, the client constructs its initial session state after which the session has been initialised and either of the two parties can send and receive encrypted messages. 19

Figure 10. Initialisation sequence.

The initial shared secret is calculated by using a key derivation function on the concatenated shared secrets acquired from two key-agreement exchanges as shown in equation 1 for the client and in equation 2 for the server. The client and server both end up with the same secret that is dependent on the server’s identity key as well as the session-speciﬁc ephemeral keys. This double key exchange is further illustrated in Figure 11. 20

a a s = KDF(Bi kBe ), (1) where s = the initial shared secret, KDF = a key derivation function, a = client’s ephemeral private key,

Be = server’s ephemeral public key,

Bi = server’s identity public key, a a Bi and Be = shared secrets, k = concatenation

s = KDF(Abi kAbe ), (2) where s = the initial shared secret, KDF = a key derivation function, A = client’s ephemeral public key,

be = server’s ephemeral private key,

bi = server’s identity private key, Abi and Abe = shared secrets, k = concatenation

Figure 11. Double key exchange. Each double-ended arrow represents a computation of a shared secret based on a public key and a private key. 21

4.2. Double Ratchet Algorithm

The session state for each participant consists of the root key, a chain key for encrypting messages, a chain key for decrypting messages, an ephemeral key-agreement protocol key pair and a ﬂag indicating if a new ephemeral public key should be sent in the next message. The root key is used in combination with new shared secrets to derive chain keys and links the key material together in order to make new ephemeral public keys trustable. The chain keys are used to derive message keys which are used only once per message. This makes the message keys independent of each other and unable to be used to derive any other keys. A message key comprises a payload encryption key, a MAC key and an IV for payload encryption. The key-agreement protocol key pair is used to derive shared secrets and is renewed with each message round trip. The ﬂowchart in Figure 12 presents the progression of session state when a party sends a message to the other party after the session has been succesfully initialised. First, a message key is derived from the encryption chain key (1) using a KDF as shown in equation 3.

ekkmkkiv = KDF(ck), (3) where ek = a payload encryption key, mk = a message authentication code key, iv = an initialisation vector, KDF = a key derivation function, ck = the chain key, k = concatenation

Next, the encryption chain key (2) is updated by hashing it as shown in equation 4. Alternatively, a KDF could be used if the hash function output length is shorter than the chain key length deﬁned in the implementation.

ck1 = H(ck0), (4)

where ck1 = the new chain key,

ck0 = the current chain key, H = a cryptographic hash function

The payload is encrypted using the message key, specifically the payload encryption key and the IV (3) and the ephemeral public key is included in the message if the flag indicating it is set (4). In this case the flag is unset afterwards. Finally, calculate a MAC using the MAC key and included message protocol fields (5), and send the message (6). 22

Figure 12. Message sending process.

The ﬂowchart in Figure 13 presents the progression of session state when a party receives a message sent by the other party after the session has been succesfully initialised. If the message contains an ephemeral public key, a new shared secret is calculated (A.1) using the received key and the local ephemeral private key. Next, a new root key and a decryption chain key are derived (A.2) from the current root key and the newly calculated shared secret using a KDF as shown in equation 5. 23

rk1kck = KDF(rk0ks), (5)

where rk1 = the new root key, ck = the new chain key, KDF = a key derivation function,

rk0 = the current root key, s = the shared secret, k = concatenation

The message key is derived (A.3) from the updated decryption chain key, and the message authenticity is verified (A.4). The decryption chain key is updated (A.5) by hashing as shown in equation 4. A new ephemeral key-agreement protocol key pair is generated (A.6), replacing the previous key pair, and a new shared secret is calculated (A.7) using the previously received ephemeral public key and the newly generated local ephemeral private key. A new root key and an encryption chain key are derived (A.8) as shown in equation 5. Finally, the flag indicating to include a new ephemeral key in the next message sent is set (A.9) and the message payload is decrypted. In the case that the message does not contain an ephemeral key, the current decryption chain key is used to derive the message key (B.1). The message authenticity is verified (B.2) and the decryption chain key is updated by hashing (B.3) before decrypting the message payload. 24

Figure 13. Message receiving process. 25

Figure 14 illustrates an example session between Alice and Bob from the perspective of Alice. Alice sends three messages to Bob (1) and receives two messages afterwards (2). Lastly, Alice sends one more message (3).

Figure 14. Example session. 26

5. EVALUATION

5.1. Security requirements

The Double Ratchet Algorithm based protocol fulﬁls all the set security requirements. Authentication of communicating devices is achieved by the initial key-agreement exchange. Message conﬁdentiality is achieved by a symmetric encryption algorithm. Message integrity is achieved by validating the messages using a message authentication code. Protection against replay attacks is achieved by the hash-ratchet as any duplicate messages encrypted with a key that has been already used once can be safely ignored. The correct message order is also cryptographically enforced this way. For- ward secrecy is also achieved by the hash-ratchet and backward secrecy is achieved by new key agreements each message round trip.

An example scenario

An example scenario is considered where the security of a messaging protocol is compromised, highlighting the advantage of using the Double Ratchet Algorithm based protocol as presented in this document. The following messaging protocols are considered: a single-key protocol, a simple hash-ratchet based protocol, a simple key- agreement-ratchet protocol, and the Double Ratchet Algorithm based protocol. The single-key protocol establishes the session using a key-agreement protocol once and encrypts all subsequent messages using the derived key. The hash-ratchet based protocol uses a key-agreement protocol only for session establishment, i.e, is just the hash-ratchet functionality of the Double Ratchet Algorithm based protocol. The key-agreement-ratchet protocol renews the encryption key on each message round-trip without a hash-ratchet, i.e, is just the key exchange functionality of the Double Ratchet Algorithm based protocol. The following assumptions are made about the adversary’s capabilities: the adversary can capture encrypted messages and compromise cryptographic keys without de- tection. However, it is not possible or feasible for the adversary to continue compromising keys or access the data unencrypted for any considerably long time. A possible example situation is that the cryptographic keys are compromised once but no malicious software can be installed on the device. An another hypothetical situation would be that the underlying encryption algorithm is broken and one cryptographic key obtained but it is not feasible to continue solving the keys for all of the messages. The outcome of the scenario depends on the encryption protocol used. By using the single-key protocol all of the past and future messages are compromised. This is illustrated in Figure 15. By using the hash-ratchet protocol all of the future messages are compromised as presented in Figure 16. By using the key-agreement-ratchet protocol all of the messages since the last key exchange are compromised until the next key exchange as illustrated in Figure 17. By using the Double Ratchet Algorithm based protocol no past messaging is compromised and only the messages until the next key exchange are compromised as presented in Figure 18. Additionally the window to ini- tiate a man-in-the-middle attack is limited in the protocols where the key material is renewed using new key-agreements as opposed to the single-key protocol and hash- 27 ratchet protocol where an attack can be carried out at any time after compromising the key.

Figure 15. The window of compromised message trafﬁc using a single-key protocol.

Figure 16. The window of compromised message trafﬁc using a hash-ratchet protocol.

Figure 17. The window of compromised message trafﬁc using a key-agreement-ratchet protocol.

Figure 18. The window of compromised message trafﬁc using the Double Ratchet Algorithm based protocol.

Protocol variations

The encryption protocol presented in this document assumes reliable in-order delivery of messages. If this assumption can not be made the protocol can be extended with a key store that caches the message keys for delayed messages. When receiving a new message, the algorithm would simply ratchet the chain key forward until a 28 message key corresponding to the received message is derived and cache the preced- ing message keys. Any delayed messages can then be decrypted later by retrieving the corresponding message key from the key store. However, this solution gives rise to a new problem of determining the acceptable size for the key store. For example, an adversary sending an arbitrary message triggers the look-ahead process of iterating the chain key but in this case no valid message key can be found so the search has to be limited. An another potential attack linked to the key store size limit is preventing enough legitimate messages from being received to desynchronise the session and causing any new messages to be unencryptable by the receiver. This means that even though the adversary is not able to access message contents, there exists an increased potential for disrupting the communication. It should be noted that omitting the hash-ratchet resulting in a simple key-agreement- ratchet protocol also removes the need for the key store or reliable in-order delivery of messages at the cost of losing message level forward secrecy. This can be critical in the case of only one party sending messages frequently thus causing long message round-trip times and subsequently large time intervals between new key agreements.

5.2. Cryptographic primitives

The cryptographic primitives to be used by the encryption protocol should be chosen primarily according to the their security properties. Security of cryptographic primitives is evaluated based on existing cryptanalysis results. Other desirable properties include minimal memory usage and minimal computation workload for increased speed and decreased energy usage. Evaluation of these properties is also presented.

Key-agreement protocol

ECDH cryptography comprises the state of the art algorithms in key-agreement protocols and the important decision is choosing a satisfactory elliptic curve to use with the ECDH key-agreement scheme. Different elliptic curves have varying security concerns [42, 43] as well as performance differences in terms of computation time and key sizes. For example, Bitcoin uses the Secp256k1 curve [44]. Curve25519 is an another elliptic curve which has been proposed as a high-speed curve with short public- and private key sizes. It is also conjectured to be extremely difﬁcult to break [45]. ECDH using short keys is presented to be vulnerable to computationally feasible attacks with suff- ciently large quantum computers [46], which is an important consideration depending on how long the messages must remain unencryptable for potential adversaries.

Symmetric-key algorithm

One of the well-known candidates for a symmetric-key algorithm would be the Ad- vanced Encryption Standard (AES). The advantage of AES is its relatively wide atten- tion in the field of cryptography which has lead to many cryptanalysis results. Promi- nent newer algorithms include ChaCha20 and NORX which have been studied less and 29 as a result less confidence should be placed in their security. However, they can have performance advantages or they can be designed in a way that allows easier cryptanalysis which in turn leads to more confident claims about their security. It is more relevant to evaluate the symmetric-key algorithm security under a single- key model rather than models that give the attacker more capabilities. The single- key model in this case means that the keys used for encryption are not related in any way and that the attacker can not affect the key generation process. Since all practical encryption protocols operate under the single-key model, it is safe to ignore related-key attacks as a threat [47]. However, even related-key attacks can hint towards weaknesses in an algorithm and should be noted when evaluating its future security [48]. State of the art attacks against AES under a single-key model are impossible differential cryptanalysis [49], Square attacks [50] and biclique attacks [47]. The most well-known approach to break AES under the related-key model is analysis using local collisions [48]. Even though some of the weaker AES variants are broken by these attacks, none of them are computationally practical. ChaCha20 has been proposed as an alternative to AES due to concerns of advancing cryptanalysis revealing flaws in AES [51]. Recent cryptanalysis has not shown vulnerabilities against full-round ChaCha20 [52, 51] and it is considerably faster than AES in software implementations [53]. NORX is an authenticated encryption algorithm which means that message authentication is combined with encryption. It is a third-round candidate in CAESAR [54], a competition for authenticated encryption algorithms, and as such will likely see further cryptanalysis results. Some of the attacks against NORX include rotational cryptanalysis attacks, differential cryptanalysis attacks and existential forgery attacks [55]. Even though existing attacks are not considered a threat to the security of NORX, the security bounds are not as well defined as in cryptanalysis of AES [55, 56]. NORX compares well against AES and ChaCha20 in terms of performance [57] and variants for resource-constrained systems are presented to retain the security properties of original NORX [58]. It is concluded that any of these symmetric-key algorithms are suitable for the encryption protocol. The performance NORX offers makes it an attrac- tive choice for low-end embedded systems. However, AES seems like the best choice for the encryption protocol when adjusting for the fact that the encryption protocol heavily prioritises security over performance.

Cryptographic hash function

A cryptographic hash function is needed for message authentication code and key derivation function. Popular candidates to be considered are SHA-2 and Keccak (SHA- 3). Collision attacks [59] and theoretical preimage attacks [60] against some number of rounds of SHA-2 are possible, even though they do not threaten the security of the full SHA-2 family. Attacks against reduced-round Keccak have been presented, although there is no reason to believe they lead to a computationally practical break [61, 62, 63]. One of the advantages of Keccak is that it does not have the length-extension weak- ness like SHA-2 which means that it can be used to produce message authentication code without using the HMAC construction, thus saving some processor cycles [64]. 30

Either way, both of the hash functions are deemed sufﬁciently secure to be used in the encryption protocol.

5.3. Implementation

The encryption protocol was implemented using the C programming language according to the presented protocol description and consists of two independent software libraries: the client library and the server library. The implementation is not dependent on any specific cryptographic primitives as long as they fulfil the functions of a key- agreement protocol, a symmetric-key algorithm and a cryptographic hash function. However, some interfacing code is needed depending on the selected cryptographic primitive implementations. The implementation of the presented protocol is compared to a reference protocol in order to determine the trade-off between security properties and resource usage. The reference protocol is computationally less demanding, uses less memory and less network bandwidth. However, the reference protocol offers weaker security as well. The only functional difference between the protocols is that the reference protocol uses a single message key throughout the session which is derived during the session initialisation. This means that the reference protocol implementation does fewer com- putations and has a smaller binary size, and that no ephemeral public keys are included in the messages. The forward secrecy and backward secrecy properties of the reference protocol are as presented in the single-key case in the example scenario of the previous section. Both protocols are compared using the same implementations of cryptographic primitives. A small and fast ECDH implementation, micro-ecc [65], was selected as the key-agreement protocol. The axTLS AES implementation [66] is optimised to have a small as possible binary size and was selected as the symmetric-key algorithm. The axTLS SHA-256 implementation [66] was selected as the cryptographic hash function which is subsequently used in the HMAC and HKDF implementations. The binary sizes were obtained by compiling the libraries and examining their binary sizes. The client library and server library have approximately the same binary size. An approximate maximum volatile memory usage was determined using GNU C compiler [67] by compiling the libraries with "-fstack-usage" flag and examining the stack usage. This is possible since the libraries do not allocate memory dynamically. The results can be seen in Table 1.

Table 1. Protocol implementation comparison presented protocol reference protocol binary size 53 KiB 50 KiB maximum volatile memory usage 2200 B 1800 B header size 33 B 33 B header size (with a new public key) 65 B - 31

The cryptographic primitive implementations comprise a significant part of the com- piled binary. In addition, the presented protocol and reference protocol both share same kind of functionality such as message serialising and deserialising, message integrity verifying, and session initialisation. For these reasons the binary sizes differ relatively little between the protocols. The approximated maximum volatile memory usage of the presented protocol is a little higher than the reference protocol. The result depends on library configuration to some degree since some buffers are allocated statically depending on configured maximum plaintext message size. In the examined binaries the maximum plaintext message size is set to 1000 bytes. Header sizes are the same unless a new ephemeral public key is sent in the case of the presented protocol. Nearly doubling the header size can have significance in a use case where lots of very short messages are repeatedly being exchanged by the communicating parties. Considering the small difference in resource usage between the protocols and that the reference protocol implements the bare minimum functionality for a secure messaging protocol, it is concluded that the presented protocol fulfills the performance requirements. 32

6. DISCUSSION

The encrypted messaging protocol using the Double Ratchet Algorithm has improved security properties compared to a single-key algorithm with only a minor additional performance cost. However, the properties of the Double Ratchet Algorithm open up an increased potential for disrupting the communication as presented in protocol evaluation. These shortcomings can limit the use cases of the presented protocol. It was also shown that using a key-agreement-ratchet protocol variation where the hash- ratchet is omitted removes the need for the key store or reliable in-order delivery of messages. avoiding these problems with the hash ratchet makes the protocol variation a performant alternative for the case where both parties send messages alternately. The full protocol can be more suitable if primarily only one party is sending messages or if the security demands override the heightened vulnerability to communication disruption. 33

7. SUMMARY

An overview of different encrypted communication protocols and the common cryptographic primitives used to build them was presented in this document. A general overview of Iot use cases was also described and the importance of secure communications for IoT was considered. Different types of attacks on IoT systems were brieﬂy presented. An encrypted messaging protocol employing the Double Ratchet Algo- rithm and thus improving some security properties of commonly used protocols was described and the trade-offs were discussed. Different cryptographic primitives and their suitability to be used in the protocol were also evaluated. Finally, an implementation of the presented protocol was evaluated and the results were discussed in relation to the speciﬁed requirements. 34

8. REFERENCES

[1] Babar S., Stango A., Prasad N., Sen J. & Prasad R. (2011) Proposed embedded security framework for internet of things (iot). In: Wireless Communication, Ve- hicular Technology, Information Theory and Aerospace & Electronic Systems Technology (Wireless VITAE), 2011 2nd International Conference on, IEEE, pp. 1–5.

[2] Paar C. & Pelzl J. (2009) Understanding cryptography: a textbook for students and practitioners. Springer Science & Business Media.

[3] Dworkin M. (2010) Recommendation for block cipher modes of operation: three variants of ciphertext stealing for cbc mode .

[4] FIPS P. 197, advanced encryption standard (aes), national institute of standards and technology, us department of commerce (november 2001). Link in: http://csrc. nist. gov/publications/fips/fips197/fips-197. pdf .

[5] Bernstein D.J. (2005) Salsa20 speciﬁcation. eSTREAM Project algorithm description, http://www. ecrypt. eu. org/stream/salsa20pf. html .

[6] Jonsson J. & Kaliski B. (2003) Public-key cryptography standards (pkcs)# 1: Rsa cryptography speciﬁcations version 2.1 .

[7] Goldwasser S., Micali S. & Rivest R.L. (1988) A digital signature scheme secure against adaptive chosen-message attacks. SIAM Journal on Computing 17, pp. 281–308.

[8] Fips P. (2000) 186-2. digital signature standard (dss). National Institute of Stan- dards and Technology (NIST) .

[9] Difﬁe W. & Hellman M. (1976) New directions in cryptography. IEEE transactions on Information Theory 22, pp. 644–654.

[10] Brown D. (2009) Standards for efﬁcient cryptography, sec 1: elliptic curve cryptography. Released Standard Version 1.

[11] FIPS P. (2012) 180-4. Secure hash standard (SHS),” March .

[12] Bertoni G., Daemen J., Peeters M. & Assche G.V., The keccak sponge function family: Speciﬁcations summary. URL: http://keccak.noekeon.org/specs_ summary.html. Accessed 1.9.2016.

[13] Saarinen M.J. & Aumasson J.P. (2015), The blake2 cryptographic hash and message authentication code (mac). URL: https://tools.ietf.org/html/rfc7693.

[14] Oded G. (2001), Foundations of cryptography basic tools.

[15] Krawczyk H., Bellare M. & Canetti R. (1997), Hmac: Keyed-hashing for message authentication. URL: https://tools.ietf.org/html/rfc2104. 35

[16] Kaliski B. (2000), Pkcs #5: Password-based cryptography speciﬁcation, version 2.0. URL: https://www.ietf.org/rfc/rfc2898.txt.

[17] Krawczyk H. & Eronen P. (2010), Hmac-based extract-and-expand key derivation function. URL: https://tools.ietf.org/html/rfc5869.

[18] Atzori L., Iera A. & Morabito G. (2010) The internet of things: A survey. Com- puter networks 54, pp. 2787–2805.

[19] Iso/iec standard 7498-1:1994. URL: http://standards.iso.org/ittf/ PubliclyAvailableStandards/s020269_ISO_IEC_7498-1_1994%28E% 29.zip.

[20] Karlof C., Sastry N. & Wagner D. (2004) Tinysec: a link layer security architecture for wireless sensor networks. In: Proceedings of the 2nd international conference on Embedded networked sensor systems, ACM, pp. 162–175.

[21] Meyer G. (1996), The ppp encryption control protocol (ecp). URL: https://tools. ietf.org/html/rfc1968.

[22] Kent S. & Seo K. (2005), Security architecture for the internet protocol, ietf rfc 4301. URL: https://tools.ietf.org/html/rfc4301.

[23] Dierks T. & Rescorla E. (2008), The transport layer security (tls) protocol version 1.2. URL: https://tools.ietf.org/html/rfc5246.

[24] Rescorla E. & Modadugu N. (2012), Datagram transport layer security version 1.2. URL: https://tools.ietf.org/html/rfc6347.

[25] Dzambasow Y., Joseph S., Nicholas R., Hesse P. & Cooper M. (2005) Internet x. 509 public key infrastructure: Certiﬁcation path building .

[26] Postel J. (1980) User datagram protocol. Tech. rep.

[27] Floyd S., Handley M. & Kohler E. (2006) Datagram congestion control protocol (dccp) .

[28] Cerf V., Dalal Y. & Sunshine C. (1974) Speciﬁcation of internet transmission control program. Tech. rep.

[29] Shelby Z., Hartke K. & Bormann C. (2014) The constrained application protocol (coap). Tech. rep.

[30] Stanford-Clark A. & Truong H.L. (2008) Mqtt for sensor networks (mqtt-s) protocol speciﬁcation. International Business Machines Corporation version 1.

[31] Bonetto R., Bui N., Lakkundi V., Olivereau A., Serbanati A. & Rossi M. (2012) Secure communication for smart iot objects: Protocol stacks, use cases and practical examples. In: World of Wireless, Mobile and Multimedia Networks (WoW- MoM), 2012 IEEE International Symposium on a, IEEE, pp. 1–7. 36

[32] (2011), Protecting data for the long term with forward secrecy. URL: https://security.googleblog.com/2011/11/protecting-data-for-long-term- with.html. Accessed 1.9.2016.

[33] Hoffman-Andrews J. (2013), Forward secrecy at twitter. URL: https://blog. twitter.com/2013/forward-secrecy-at-twitter-0. Accessed 1.9.2016.

[34] Foundation W. (2014), Tech/news/2014/27 - meta. URL: https://meta. wikimedia.org/wiki/Tech/News/2014/27. Accessed 1.9.2016.

[35] Borisov N., Goldberg I. & Brewer E. (2004) Off-the-record communication, or, why not to use pgp. In: Proceedings of the 2004 ACM workshop on Privacy in the electronic society, ACM, pp. 77–84.

[36] Moscaritolo V., Belvin G. & Zimmermann P. (2012) Silent circle instant messaging protocol protocol speciﬁcation. Online, White Paper (December 2012) .

[37] Open whisper systems. URL: https://github.com/WhisperSystems. Accessed 1.9.2016.

[38] Marlinspike M. (2013), Advanced cryptographic ratcheting. URL: https:// whispersystems.org/blog/advanced-ratcheting/. Accessed 1.9.2016.

[39] Perrin T., Double ratchet algorithm. URL: https://github.com/trevp/double_ ratchet/wiki. Accessed 1.9.2016.

[40] Unger N., Dechand S., Bonneau J., Fahl S., Perl H., Goldberg I. & Smith M. (2015) Sok: Secure messaging. In: 2015 IEEE Symposium on Security and Pri- vacy, IEEE, pp. 232–249.

[41] Anderson R. & Kuhn M. (1996) Tamper resistance-a cautionary note. In: Pro- ceedings of the second Usenix workshop on electronic commerce, vol. 2, vol. 2, pp. 1–11.

[42] Bernstein D.J. & Lange T. (2013) Security dangers of the nist curves. In: Invited talk, International State of the Art Cryptography Workshop, Athens, Greece.

[43] Bernstein D.J. & Lange T., Safecurves: choosing safe curves for elliptic-curve cryptography. URL: https://safecurves.cr.yp.to. Accessed 27.3.2017.

[44] Malvik A.G. & Witzoee B. (2015) Elliptic curve digital signature algorithm and its applications in bitcoin .

[45] Bernstein D.J. (2006) Curve25519: new difﬁe-hellman speed records. In: Inter- national Workshop on Public Key Cryptography, Springer, pp. 207–228.

[46] Proos J. & Zalka C. (2003) Shor’s discrete logarithm quantum algorithm for elliptic curves. arXiv preprint quant-ph/0301141 .

[47] Bogdanov A., Khovratovich D. & Rechberger C. (2011) Biclique cryptanalysis of the full aes. In: International Conference on the Theory and Application of Cryptology and Information Security, Springer, pp. 344–371. 37

[48] Biryukov A., Dunkelman O., Keller N., Khovratovich D. & Shamir A. (2010) Key recovery attacks of practical complexity on aes-256 variants with up to 10 rounds. In: Annual International Conference on the Theory and Applications of Cryptographic Techniques, Springer, pp. 299–319.

[49] Mala H., Dakhilalian M., Rijmen V. & Modarres-Hashemi M. (2010) Improved impossible differential cryptanalysis of 7-round aes-128. In: International Con- ference on Cryptology in India, Springer, pp. 282–291.

[50] Dunkelman O., Keller N. & Shamir A. (2010) Improved single-key attacks on 8-round aes-192 and aes-256. In: International Conference on the Theory and Application of Cryptology and Information Security, Springer, pp. 158–176.

[51] Procter G. (2014) A security analysis of the composition of chacha20 and poly1305. IACR Cryptology ePrint Archive 2014, p. 613.

[52] Maitra S. (2016) Chosen iv cryptanalysis on reduced round chacha and salsa. Discrete Applied Mathematics 208, pp. 88–97.

[53] Nir Y. & Langley A. (2015), Chacha20 and poly1305 for ietf protocols. URL: https://tools.ietf.org/html/rfc7539.

[54] Bernstein D.J., Caesar. URL: http://competitions.cr.yp.to/index.html. Ac- cessed 27.3.2017.

[55] Chaigneau C., Fuhr T., Gilbert H., Jean J. & Reinhard J.R. (2017) Cryptanalysis of norx v2. 0. IACR Transactions on Symmetric Cryptology 2017, pp. 156–174.

[56] Bagheri N., Huang T., Jia K., Mendel F. & Sasaki Y. (2016), Cryptanalysis of reduced norx. Cryptology ePrint Archive, Report 2016/436. http://eprint.iacr. org/2016/436.

[57] Birr-Pixton J., Benchmarking modern authenticated encryption on e1 devices. URL: https://jbp.io/2015/06/01/modern-authenticated-encryption- for-1-euro/. Accessed 27.3.2017.

[58] Aumasson J.P., Jovanovic P. & Neves S. (2015), Norx8 and norx16: Au- thenticated encryption for low-end systems. Cryptology ePrint Archive, Report 2015/1154. http://eprint.iacr.org/2015/1154.

[59] Sanadhya S.K. & Sarkar P. (2008) New collision attacks against up to 24-step sha-2. In: International Conference on Cryptology in India, Springer, pp. 91– 103.

[60] Aoki K., Guo J., Matusiewicz K., Sasaki Y. & Wang L. (2009) Preimages for step-reduced sha-2. In: International Conference on the Theory and Application of Cryptology and Information Security, Springer, pp. 578–597.

[61] Qiao K., Song L., Liu M. & Guo J. (2017), New collision attacks on round- reduced keccak. Cryptology ePrint Archive, Report 2017/128. http://eprint.iacr. org/2017/128. 38

[62] Jean J. & Nikolic I. (2015), Internal differential boomerangs: Practical analysis of the round-reduced keccak-f permutation. Cryptology ePrint Archive, Report 2015/244. http://eprint.iacr.org/2015/244.

[63] Amy M., Matteo O.D., Gheorghiu V., Mosca M., Parent A. & Schanck J. (2016), Estimating the cost of generic quantum pre-image attacks on sha-2 and sha-3. Cryptology ePrint Archive, Report 2016/992. http://eprint.iacr.org/2016/992.

[64] team K., The keccak sponge function family. URL: http://keccak.noekeon.org/. Accessed 27.3.2017.

[65] micro-ecc. URL: https://github.com/kmackay/micro-ecc. Accessed 27.3.2017.

[66] axtls embedded ssl cryptographic primitive implementations. URL: https:// sourceforge.net/p/axtls/code/HEAD/tree/trunk/crypto. Accessed 27.3.2017.

[67] Gcc, the gnu compiler collection. URL: https://gcc.gnu.org/. Accessed 27.3.2017.