Trabajo Fin de Grado

Transcription

1 ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INDUSTRIALES Y DE TELECOMUNICACIÓN UNIVERSIDAD DE CANTABRIA Trabajo Fin de Grado Arquitectura de seguridad ligera para el Internet de las Cosas basada en HIMMO (Lightweight security architecture for the Internet of Things based on HIMMO) Para acceder al Título de Graduado en Ingeniería de Tecnologías de Telecomunicación Autor: José Luis Torre Arce Julio

2

3 Resumen Millones de dispositivos inteligentes desplegados en escenarios como ciudades inteligentes, domótica o cuidados médicos están conectados a Internet formando el llamado Internet de las Cosas. Las soluciones de seguridad desarrolladas para redes de ordenadores no son válidas en este nuevo escenario en el que el poder de cómputo, la memoria y los datos intercambiados son mínimos. HIMMO presenta una solución ligera para el establecimiento de claves que es segura y eficiente en este tipo de dispositivos. En este Trabajo de Fin de Grado, analizamos los objetivos que una arquitectura de seguridad para el Internet de las Cosas debe satisfacer. Tomando como base esos objetivos, diseñamos una arquitectura de seguridad completa, basada en HIMMO, que tiene en cuenta el ciclo de vida de un dispositivo inteligente. También diseñamos una extensión para DTLS basada en HIMMO (DTLS-HIMMO) para ser utilizada con la arquitectura de seguridad. Creamos una implementación genérica de HIMMO y la usamos para medir su rendimiento en diferentes dispositivos y el de DTLS-HIMMO. Los resultados de rendimiento muestran como nuestra implementación genérica de HIMMO se ejecuta de manera eficiente en diferentes tipos de dispositivos. También muestra como DTLS-HIMMO permite lograr propiedades de seguridad de DTLS con certificados, manteniendo el coste computacional de DTLS-PSK. Parte de este trabajo ha llevado a la publicación de varios artículos que han sido aceptados en diferentes conferencias y grupos de trabajo.[1][2] iii

4

5 Abstract Billions of resource-constrained devices working in scenarios such as smart cities, healthcare and smart homes are connected to the Internet forming the so-called Internet of Things. Security solutions developed for computer networks are not suitable in this new scenario where computation power, memory, and data exchanged are restricted. HIMMO presents a lightweight solution for key agreement that is secure and efficient in embedded platforms. In this thesis, we analyze the requirements that a security architecture for the Internet of Things should fulfill. Based on those requirements, we design a complete security architecture based on HIMMO that takes into account the lifecycle of an IoT device. We also design a DLTS extension based on HIMMO to be used in this architecture. We create a generic implementation of HIMMO and we use it to test the performance of HIMMO in different devices and of DTLS-HIMMO. The performance results show that our generic HIMMO implementation can run efficiently in different types of devices and that DTLS-HIMMO can achieve DTLS-certificate security properties at the cost of symmetric-key cryptography. Part of this work has lead to some papers that have been accepted in different conferences and workshops. [1][2] v

6

7 Acknowledgements First and foremost I would like to thank my supervisor Óscar García Morchón for his guidance and advice during the development of this thesis and for giving me the opportunity to work in Philips Research, Eindhoven. I would also like to thank Domingo Gómez Pérez, Jaime Gutiérrez and Jorge Lanza, from the University of Cantabria. Domingo for his support during the first months of the thesis, Jaime, who was the first who told me about this opportunity, and Jorge, for his help during the final steps of this thesis. This thesis would not exist without the work of all the people in the HIMMO project: Ludo Tolhuizen, Ronald Rietman, and Sahil Sharma. All of them have shaped the ideas that form this thesis. Last but not least, to my family for always being there. Part of this work was supported by Philips Research under a grant. vii

8

9 Contents Resumen Abstract Acknowledgements List of Figures List of Tables Listings v vii ix xiii xiv xv 1 Introduction Problem statement Contributions Structure of the Thesis Background Internet of Things Smart cities Cryptography Modern cryptography Security protocols in the Internet of Things HIMMO HIMMO operation Implicit certification and verification of credentials Enhancing privacy by using multiple TTPs Security principles Design Design goals Operation and performance Attack model and security goals Architecture design TTP infrastructure and smart object manufacturing The authentication process for network access Secure operation Secure software update ix

10 Contents 3.3 DTLS-HIMMO DTLS-HIMMO configurations DTLS-HIMMO handshake Software design TTP design HIMMO library for embedded devices Implementation HIMMO TTP Key agreement Portability Multiple precision arithmetic DTLS-HIMMO Evaluation Security architecture HIMMO library DTLS-HIMMO and comparison with existing DTLS alternatives Conclusions and future work 38 Glossary 40 Bibliography 41 x

11 List of Figures 2.1 IoT network overview DTLS handshake Lifecycle of an IoT device Security architecture phases overview DTLS-HIMMO handshake Logical structure of the HIMMO library Long number schoolbook multiplication Long number What if? multiplication Optimized keying material storage Screenshot of the TTP application Detail of keying material generation DTLS-HIMMO capture overview DTLS-HIMMO Identity-Hint capture Compared performance of DTLS with HIMMO, ECDH-ECDSA, and PSK DTLS handshake overhead for 1 KB payload Ratio between exchanged data and payload in DTLS xi

12 List of Tables 3.1 DTLS-HIMMO identity hint format Long number structure Security architecture comparison HIMMO performance for B = b = 128 as a function of α HIMMO performance for α = 26 as a function of b = B HIMMO Challenges HIMMO performance overview Modes of operation of DTLS-HIMMO profile xii

13 Listings 4.1 Word length selector Long number structure xiii

14

15 1 Introduction The ubiquitous connection of devices to the Internet, the Internet of Things (IoT), will account for more than a third of all Internet connections by 2018, according to the Cisco M2M Devices Forecast [3]. These devices are being deployed in scenarios such as smart homes, healthcare, or smart cities, enabling multiple applications. Taking the example of a smart city, the IoT allows us to create a network that interconnects the whole city infrastructure water meters, environmental sensors, and lighting infrastructure making possible to control it, improving city flow and functionalities. According to the same Cisco Forecast, privacy and security are still two of the technical issues that remain unsolved in the IoT. The reason is that solutions created for traditional computer networks do not suit the IoT performance, operational, and security requirements. The importance of security in the IoT gets a prominent relevance when we take into account that the use cases in which IoT devices are deployed include healthcare, home automation, and smart cities. A security breach in one of those scenarios could lead to malfunctions in life-support systems, home alarms, or city traffic lighting systems. Modern day computer networks are usually secured by a combination of asymmetric and symmetric-key cryptography. Asymmetric cryptography (also known as publickey cryptography) is used for authentication, verification and key agreement, while symmetric-key cryptography is used for encryption. Porting this design to the IoT is not a good option: asymmetric cryptography is computationally expensive and requires the exchange of long keys which has a negative impact during IoT operation, on the other hand, symmetric-key cryptography is lightweight but it does not scale regarding key distribution and management and this can lead to a lower security level. It is also worth noting that symmetric-key cryptography on its own cannot provide key agreement, authentication, or verification capabilities. Finally, IoT deployments, that will likely be on the field for many years, have to take into consideration that the advent of quantum computers will break all commonly used asymmetric-key algorithms [2]. Security solutions for the IoT can choose to support asymmetric cryptography, knowing that it will suppose a performance loss, or rely solely in symmetric-key cryptography and use Pre-Shared Key (PSK). Relying on a PSK presents a notable security problem: if a device is capture and its key retrieved, the security of the whole network is compromised. The recently introduced HIMMO scheme [4] is a fully collusion-resistant Key Pre- Distribution Scheme (KPS) that enables lightweight identity-based key agreement between devices in a single message, making it very interesting for an IoT scenario. HIMMO also provides direct authentication, and enables credential verification at the cost of a 1

16 1 Introduction hash function. 1.1 Problem statement The IoT lacks a security architecture that is able to grant scalability, good performance, and quantum-security while conforming with the tight constrains this scenario presents in terms of computation power, memory availability, and energy consumption. To address this problem, we need: Overview of requirements of an IoT security. Suitable security architecture that takes into account the above requirements. Portable implementation that can be easily integrated into standard protocols while being efficient. 1.2 Contributions We propose a new security architecture for the IoT based on HIMMO that is able to address these problems. To do this, we analyze the IoT scenario and present a list of requirements that a security architecture for the IoT should fulfill, taking into account the whole lifecycle of a device [5] from the moment it is manufactured. Based in this analysis, we design a security architecture for the IoT and its software implementation. We create a software implementation for the cryptographic primitives used in our architecture in a way that can be used in a future to test its performance in different scenarios. Finally, we present performance results that support our claim that our solution is feasible under the constrains of IoT devices and we compare them with other approaches. 1.3 Structure of the Thesis The rest of the thesis is organized as follows: Chapter 2 describes the use cases for IoT in a smart city scenario, provides the required background on cryptography and secure communication protocols and reviews the HIMMO scheme. Chapter 3 analyzes operational and security goals for the IoT, details the proposed security architecture and discuss the software implementation of HIMMO and the DTLS- HIMMO extension. Chapter 4 details the software implementation of HIMMO and DTLS-HIMMO and discuss some optimizations. Chapter 5 compares our solution with other security architectures and presents performance measures of HIMMO s software implementation. We end this thesis in Chapter 6 drawing conclusions from our work and pointing future lines of research. 2

17 2 Background In this chapter, we provide the reader with some basic background related with the topics covered in this thesis. We talk about the IoT and its use cases, present a few useful cryptography concepts and describe HIMMO. 2.1 Internet of Things The IoT is connecting billions of smart devices deployed in critical applications like healthcare, distributed control systems, smart cities, and smart energy. These devices are usually very resource-constrained in terms of memory, computational power, and energy. The devices on a typical IoT network are organized in clusters, each cluster managed by a border router which is connected to a back-end server. Information gathered by the devices is send to the border router directly, if there is a direct link, or relaying the message via other devices, if there is no direct link. We call mesh network, to this network architecture where the devices relay the messages of other devices, forming a mesh or grid. The border router can then send the information to the back-end server. Figure 2.1 shows an overview of this architecture. Back-end server Border Router Node Figure 2.1: IoT network overview. Some of the protocols used in the IoT are 6LoWPAN [6] and IEEE [7]. 3

18 2 Background Smart cities The major problems of today s cities did not exist when they were built: most cities are not prepared for things like the massive increment in the number of cars over the last twenty years. Along with this problem, over the last years humanity has developed an ecological conscience that looks after the efficient use of resources and punish its waste. These are the type of problems that Smart City projects try to solve, and they do so by using the latest advances in technology to offer services both to the inhabitants of the cities and to their leaders. The IoT in the context of smart cities enables services such as outdoor lighting control, water control, smart energy networks, and environmental sensing [8]. For instance, an environmental sensing network based on the IoT can be realized by means of a wireless mesh network that enables the communication between sensors: the environmental sensors would use the mesh network to reach a border router that would further forward the messages containing the gathered measurements towards a back-end system in charge of device and data management. Here, the devices constitute one of the key enablers of these services. Another use cases [8] that can be enabled by the IoT in a smart city are: Environmental information: Light intensity, noise and air quality sensors gather information which is publicly available to the inhabitants of the city. Traffic monitoring: The traffic sensors located in the entrances of the city can be used to provide better route calculation. Parking spots monitoring: Information about free parking spots is shown in panels and also is available on the Internet. 2.2 Cryptography Cryptography is the study of mathematical techniques related to aspects of information security such as confidentiality, data integrity, entity authentication, and data origin authentication. [9] In the following examples and definitions, we use the classical example of a communication between two parties: Alice and Bob. The most important goals of cryptography are four: 1. Confidentiality: Alice wants to be sure that only Bob can read the message she is sending. 2. Data integrity: Bob wants to be sure that the message he received is unaltered and exactly how Alice wrote it. 3. Authentication: Bob wants to be sure that the message was sent by Alice. 4. Non-repudiation: Bob wants to be sure that Alice will not deny in the future the content of the communication. 4

19 2 Background As a cryptosystem is discussed in this work, we must first define a cryptosystem in a general way: A cryptosystem is a five-tuple (P, C, K, E, D where the following conditions are satisfied:[10] 1. P is a finite set of possible plaintexts; 2. C is a finite set of possible ciphertexts; 3. K, the keyspace, is a finite set of possible keys; 4. For each K K, there is an encryption rule e K E and a corresponding decryption rule d K D. Each e K : P C and d K : C P are functions such that d K (e K (x)) = x for every plaintext element x P Modern cryptography Modern cryptosystems can be classified in 2 types: Symmetric cryptosystems: Alice and Bob have a shared secret, a key, and they use it to encrypt their communication. Asymmetric cryptosystems: Alice and Bob have a duple of private key and public key. When Alice want to send a message to Bob, she encrypts the message with Bob s public key, only Bob with his private key can decrypt the message. Most common asymmetric cryptosystems rely on the intractability of certain mathematical problems: the discrete logarithm problem and the factoring of large integers. Cryptosystems based on these problems can be attacked with a sufficiently powerful quantum-computer by using Shor s algorithm [11] Security protocols in the Internet of Things The architecture shown in Figure 2.1 in which a device communicates over a mesh network with a back-end server can be realized by means of multiple communication protocols. For instance, 6LoWPAN [6]/IEEE [7] networks enable IP connectivity in a mesh network. Network connectivity from the border router to the back-end can be based on a cellular link. End to end communication can be based on OMA LWM2M, in which application data is exchanged between client and server by means of CoAP [12] and the end to end communication is secured by means of DTLS [13] using pre-shared keys, raw public-keys or certificates. (D)TLS is becoming the security standard for the IoT. TLS is used in the architectures and protocols based on TCP, such as MQTT[14] or ETSI s SmartM2M [15]; while DTLS is used in the ones that rely on UDP for its transport layer, as OMA LightweightM2M (LWM2M) that uses CoAP [12]. All public-key ciphersuites currently offered in TLS can be broken with a quantum computer. The first step in a DTLS connection is the DTLS handshake, in which the devices agree on a key and establish a secure data channel. The DTLS handshake message exchanges are shown in Figure 2.2, with the respective steps explained below: 5

20 2 Background - Step 1: The client sends a ClientHello message to the server indicating use of the PSK mode, such as the TLS_PSK_WITH_AES_128_CCM_8. - Step 2: HelloVerifyRequest message, with a cookie, is sent from the server to the client. - Step 3: The client replies back with ClientHello along with the cookie. - Step 4: The server replies with ServerHello, ServerKeyExchange* (optional) and ServerHelloDone. - Step 5: The client sends the ClientKeyExchange. It also sends the ChangeCipher- Spec and Finished messages to the server. - Step 6: The Server sends back the usual ChangeCipherSpec and Finished messages to the client. After the handshake, all the data is sent through a secure channel encrypted with the agreed key. DTLS mechanisms for key agreement rely on Public Key Cryptography (PKC) like RSA, or PSK. Client DDDDDDD ClientHello HelloVerifyRequest DDDDD(withDcookie) ClientHelloD (withdcookie) Server ServerHello ServerKeyExchange* ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished ApplicationDData Figure 2.2: DTLS handshake 2.3 HIMMO HIMMO [16] is a KPS that enables any pair of devices in a system to agree on a common symmetric key based on their identifiers and a secret key-generating polynomial. The concept of KPS was first introduced by Matsumoto and Imai in 1987 [17]; in 1993, Blundo et al. [18] presented an elegant and efficient KPS based on symmetric polynomials, but 6

21 2 Background it was vulnerable to collusion attacks (attacking the whole system by compromising a subset of nodes). HIMMO is the first KPS that is both efficient and resistant to collusion attacks. This section reviews the operation of the HIMMO scheme and describes two protocol extensions of the scheme as described in [19]. This section also presents the underlying security principles on which HIMMO relies. We use the following notation: for each integer x and positive integer M, we denote by x M the unique integer y {0, 1,..., M 1} such that x y mod M HIMMO operation Like any KPS, HIMMO requires a trusted third party (TTP), and three phases can be distinguished in its operation [17]. In the setup phase, the TTP selects positive integers B, b, m and α, where m 2. The number B is the bit length of the identifiers that will be used in the system, while b denotes the bit length of the keys that will be generated. The TTP generates the public modulus N, an odd number of length exactly (α + 1)B + b bits (so 2 (α+1)b+b 1 < N < 2 (α+1)b+b ). It also randomly generates m distinct secret moduli q 1,..., q m of the form q i = N 2 b β i, where 0 β i < 2 B and at least one of β 1,..., β m is odd. Finally, the TTP generates the secret root keying material, that consists of the coefficients of m bi-variate symmetric polynomials of degree at most α in each variable. For 1 i m, the i-th root keying polynomial R (i) (x, y) is written as R (i) (x, y) = α α j=0 k=0 R (i) j,k xj y k with 0 R (i) j,k = R(i) k,j q i 1. In the keying material extraction phase, the TTP provides each node ξ in the system, with 0 ξ < 2 B, the coefficients of the key generating polynomial G ξ : G ξ (y) = α G ξ,k y k (2.1) k=0 where G ξ,k = m α R (i) j,k ξj qi N. (2.2) i=1 j=0 In the key generation phase, a node ξ wishing to communicate with node η with 0 η < 2 B, computes: K ξ,η = G ξ (η) N 2 b (2.3) It can be shown that K ξ,η and K η,ξ need not be equal. However, as shown in Theorem 1 in [19], for all identifiers ξ and η with 0 ξ, η 2 B, K ξ,η { K η,ξ + jn 2 b 0 j 2m} 7

22 2 Background In order to perform key reconciliation, i.e. to make sure that ξ and η use the same key to protect their future communications, the initiator of the key generation (say node ξ) sends to the other node, simultaneously with an encrypted message, information on K ξ,η that enables node η to select K ξ,η from the candidate set C = { K η,ξ + jn 2 b 0 j 2m}. No additional communication thus is required for key reconciliation. The key K ξ,η will be used for securing future communication between ξ and η. As an example of information used for key reconciliation, node ξ sends to node η the number r = K ξ,η 2 s, where s = log 2 (4m + 1). Node η can efficiently obtain the integer j such that j 2m and K ξ,η K η,ξ + jn mod 2 b by using that jn K ξ,η K η,ξ r K η,ξ mod 2 s. As N is odd, the latter equation allows for determination of j. As r reveals the s least significant bits of K ξ,η, only the b s most significant bits K ξ,η, that is, the number 2 s K ξ,η, should be used as key Implicit certification and verification of credentials Implicit certification and verification of credentials is further enabled on top of the basic HIMMO scheme. A node that wants to register with the system provides the TTP with its credentials, e.g., device type, manufacturing date, etc. The TTP, which can also add further information to the node s credentials such as a unique node identifier or the issue date of the keying material and its expiration date, obtains the node s identity as ξ = H(credentials), where H is a public hash function. When a first node with identity ξ wants to securely send a message M to a second node with identity η, the following steps are taken. Step 1: Node ξ computes a common key K ξ,η with node η, and uses K ξ,η to encrypt and authenticate its credentials and message M, say e = E Kξ,η (credentials M). Step 2: Node ξ sends (ξ, e, r) to node η, where r is data helping node η to find K ξ,η. Step 3: Node η receives (ξ, e, r ). Using r, it computes its common key K η,ξ with ξ to decrypt e obtaining the message M and verifying the authenticity of the received message. Furthermore, it checks whether the credentials in e correspond with ξ, that is, it validates if ξ = H(credentials ). This method not only allows for direct secure communication of message M, but also for implicit certification and verification of ξ s credentials because the key generating polynomial assigned to a node is linked to its credentials by means of H. If the output size of H is long enough, e.g., 256 bits, the input (i.e., the credentials) contains a unique node identifier, and if H is a secure one-way hash function, then it is infeasible for an attacker to find any other set of credentials leading to the same identity ξ. The fact that credential verification might be prone to birthday attacks motivates the choice for the relation between identifier and key sizes, namely, B = 2b. In this way, the scheme provides an equivalent security level for credential verification and key generation. The capability for credential verification enables e.g. the verification of the expiration date of the credentials (and the keying material) of a node, or verification of the access roles of the sender node ξ. 8

23 2 Background Enhancing privacy by using multiple TTPs Using multiple TTPs was introduced by Matsumoto and Imai [17] for KPS and can also be elegantly supported by HIMMO [19]. In this scheme, a number of TTPs provide a node with keying materials linked to the node s identifier during the keying material extraction phase. Upon reception, the device combines the different keying materials by adding the coefficients of the key generating polynomials modulo N. Key generation is performed as usual. This scheme enjoys two interesting properties without increasing the resource requirements of the nodes. First, privacy is enhanced since a single TTP cannot eavesdrop the communication links. In fact, all TTPs should collude to monitor the communication links. Secondly, compromising a sub-set of TTPs does not break the overall system Security principles The security of HIMMO is based on two interpolation problems: Hiding Information (HI problem [4]): Let f Z[x] of degree at most α, x i Z and y i = f(x i ) N r for 0 i c. Given α, N, r, (x 1, y 1 ),..., (x c, y c ) and x 0 find y 0. This is equivalent to a close lattice vector problem in a lattice of dimension α+1+c. For HIMMO parameters r = 2 b and N 2 (α+1)b+b, c must be (α + 1)( αb αb + 1) to find a unique y 0. For α 20, all known lattice techniques fail to give a correct answer. Mixing Modular Operations (MMO problem [20]): Let m 2 and g 1,..., g m Z[x], all of degree at most alpha, let x i Z and y i = m j=1 g j (x i ) qj for 0 i c. Given α, m(x 1, y 1 ),..., (x c, y c ) and x 0, find y 0. If q 0 known: lattice problem in dimension m(α c), and c must be m(α + 1) to find a unique y 0. As there is no efficient way to reconstruct q i, the problem is considered infeasible. As the cryptanalysis of HIMMO leads to lattice problems, and there is no known algorithm for solving these problems that can take advantage of a quantum computer, HIMMO can be considered quantum-secure. 9

24 3 Design In this chapter, we propose solutions to the problems described in Section 1.1. To do that, first we describe the goals that a security architecture for the IoT should fulfill. We do this, not only from a security point of view, but also from a operational perspective. With the objectives established, we describe a security architecture that aims to fulfill them using HIMMO. After this, we describe how HIMMO can be implemented in software, thus allowing to test the feasibility of our solution. Finally, we show DTLS-HIMMO [1], a mode for DTLS that, by using HIMMO for key agreement, enables credential verification and authentication at a suitable cost for the IoT. 3.1 Design goals In this section, we analyze the smart city scenario we described in Chapter 2 and we identify a series of goals related to security, operation, and performance that a security architecture for the IoT should aim to fulfill Operation and performance Because of the resource-constrained nature of the devices, security solutions should achieve good performance (O-1) regarding energy consumption, bandwidth requirements, number of round trips, memory needs, and CPU usage. This is very important specially in small devices such as some sensors and also when the devices are connected through a data link where every transmitted bit costs money. The deployment of an IoT network is usually done in several phases, as usually the number of devices is very high. It should thus be possible to add devices to a running system in a simple way (O-2). Scalability is a key requirement so that a very high number of devices and back-end servers can be easily supported (O-3). In order to ensure this scalability, it is required to enable easy management of device s credentials and attributes in both centralized and distributed communication patterns (O-4). Another important requirement refers to the easy integration with existing communication protocols and architectures (O-5). This facilitates adoption and allows for a smooth transition by avoiding the costs related to a change in the technology of the network. Finally, solutions should fit the use cases not only during the operational phase but throughout all the lifecycle of a device [5] (Figure 3.1) (O-6). In the context of IoT, where the devices are being deployed for a long period of time, this also means that the deployed solutions have to remain secure during a long period 10

25 3 Design Manufactured Installed Commissioned Application running SWbupdate Application reconfigured Application running Decommissioned Removedband replaced Reownershipband recommissioned Maintenanceband Bootstrapping Operational Operational re-bootstrapping Maintenanceband re-bootstrapping Figure 3.1: Lifecycle of an IoT device. of time (10, 20, or even 30 years) (O-7). As the devices are very different one from each other, it is important that the architecture is portable and easy to adapt to different devices and scenarios (O-8) Attack model and security goals In addition to the above operational and performance goals, we consider an attack model in which the opponent can aim at disrupting the system operation at different stages of the lifecycle of a device. Next, we identify potential attacks and discuss security goals that aim to prevent them. First of all, the attacker (either external or insider) can aim at compromising a root of trust, such as a Certification Authority (CA) in a Public Key Infrastructure (PKI). This would allow him to gain full control over the system. One example of this type of attack is the one suffered by DigiNotar [21]. Therefore, the first security goals refer to being resilient to the compromise of a root of trust (S-1) and ensuring that a single root of trust cannot monitor and control communication links (S-2). This last requirement should still be compatible with key escrow if required (S-3). The next type of attack focuses on the manufacturing process in which the devices are configured with credentials and secret keys. If an opponent manages to get control on a manufacturing facility, then he can modify or copy this information. An important security goal is to facilitate a secure manufacturing process that prevents this (S-4). The next type of attack can happen when the devices are being deployed. In this case, the back-end server might be exposed to fake devices and, in a similar way, fake servers might impersonate the actual back-end server to gain control over the devices. Authentication and authorization of device (S-5) and back-end server (S-6) is required to prevent this situation. Even with end to end authentication, the devices that are routing the information could still be exposed to a Denial of Service (DoS) attack, since they would not be able to identify by themselves the communicating parties. Thus, another goal is the prevention of DoS attacks during network access (S-7). During operation, an attacker might aim at physically capturing devices to misuse their 11

26 3 Design (i) TTP 1 R 1... TTP Q R Q G η 1 Back-end server 1 G η Q... η G η 1 (ii) Factory 1... G η M Factory M (v) Back-end server P Border Router η Relay Node (iv) (iii) η Figure 3.2: Security architecture phases overview. secret keys and credentials towards the back-end server or towards any other device in the network. Therefore, a key goal will be that the compromise of any number of devices does not affect the security of the whole system (S-8). Another goal to deal with this attack is to facilitate the identification and blacklisting of compromised devices (S-9). Also during operation, another security goal refers to the capability of establishing a common shared key for providing further security services (S-10). As the devices will be on the field for many years, a security solution should provide long term security including resilience against post-quantum attacks (S-11). Other security goals are perfect forward secrecy (S-12), meaning that a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in future, and non-repudiation (S-13), e.g. allowing a metering device signing the energy consumption so that there is proof of the amount of consumed energy. 3.2 Architecture design In the following sections, we detail our solution accordingly to the lifecycle of a smart object. First, we show how a Trusted Third Party (TTP) infrastructure can be used to enable secure manufacturing of smart objects (Section 3.2.1). Then, after being securely provided with HIMMO keying materials, those keying materials are used to enable secure network access Section After accessing the network, using the keying material is also possible to ensure secure operation and credential management Section Finally, a protocol for secure software updates is also enabled supporting secure Over The Air Programming (OTAP). 12

27 3 Design We can see in fig. 3.2 the different phases in the proposed security architecture: (i) Infrastructure of roots of trust in charge of handling the HIMMO root keying materials. (ii) A number of factories producing smart objects configured with secret keys and credentials. (iii) Authentication process, in which a smart object registers with a back-end system in order to get credentials for access to the network. (iv) Secure operation phase in which smart objects can securely communicate with each other, using the credentials obtained in the previous step. (v) Secure software update protocol enabling secure OTAP TTP infrastructure and smart object manufacturing Our architecture relies on the HIMMO capability for working with multiple TTPs to address goals S-1, S-2, S-3, S-4, and S-11. We consider multiple TTPs can generate and securely manage HIMMO root keying materials. The role of these TTPs is similar to today s CA infrastructure with the obvious differences in the underlying technology. When a new set of devices needs to be manufactured, the back-end server in charge of those devices will request a subset of the TTPs to extract HIMMO keying materials linked to some device credentials. In the following we will assume that these credentials depend on the unique MAC address of each device, e.g., η = MAC address of device η. The back-end server will also determine which factories will get HIMMO keying materials from which TTPs. Next, TTP j will extract HIMMO keying material G j η(y) for device η and securely send these keying materials to the corresponding manufacturing facility l. Here, each device η will receive G j η(y) and update its locally aggregated keying material as G η (y) = G η (y) + G j η(y) In a similar way, the back-end server ξ can request at any time a new N set of keying materials from those TTPs and obtain its aggregated keying material in a similar way The authentication process for network access We use the HIMMO keying material to enable secure network access and device registration, addressing goals S-5, S-6, S-7, S-8, S-9, S-10. In this procedure, the joining node η aims to register with a back-end server after verification of such back-end server and the back-end server aims to register the joining node after authenticating it. On top of the server verifying the client, the devices in the network can also verify the authenticity of the joining node during this process, in order to prevent possible abuse that could lead to DoS attacks by the means of flooding the network with joining requests. In IoT scenarios the devices are usually the bottleneck of the network, so this is specially important. The verification could be done at different levels in the network to thwart an attack as early as possible. In the process described below, the devices 13

28 3 Design are organized in an IEEE [7] mesh network, which is typical example of an IoT network. - Step 1: A joining node η is installed and waits to hear beacons from devices in a network. - Step 2: A neighboring node, working as relay node or a border router, regularly sends a broadcast beacon as part of the normal network traffic. - Step 3: Upon reception of a network beacon originating, e.g., from a relay node r, node η will securely send a IEEE message protected with the HIMMO key K η,r = G η (r) N 2 b. The Key Identifier and Key Identifier Mode [7] can be used to indicate that HIMMO key derivation is in use. - Step 4: The relay node will process this message protected at IEEE and reply with the identity of the border router, if verification of the message sent by η is successful. K η,r could be cached by r for further communication. - Step 5: Node η then will start a DTLS [13] handshake towards the back-end server through relay node r in which the communication at IEEE is protected by K η,r. Note that the relay node operates as described in [22]. Furthermore, the first DTLS message, Client Hello, includes the identity of the joining node and an authentication token created with K η,br so that the border router can verify it. - Step 6: Node r will relay only DTLS traffic from device η. Furthermore, the border router will only forward the DTLS traffic if the verification of the authentication token is successful and the identity of the joining node is not blacklisted. - Step 7: The back-end server gets the request from the joining node and engages in a DTLS handshake in which both joining node and back-end server mutually authenticate each other and verify their credentials. This handshake may be based on the lightweight scheme as proposed in [1]. Upon successful establishment of the DTLS session, the joining node will receive the network key, K Network, from the server. Upon successful completion of this protocol, the key used to secure IEEE layer communication on the link between node η and any node ξ is computed as Kη,ξ Network = K η,ξ K Network, where denotes bit-wise XOR. We note that the above protocol relies on the identity-based nature of HIMMO and its properties to mutually authenticate the joining device and back-end server. This is achieved by means of DTLS-HIMMO since HIMMO can be easily integrated in DTLS [1]. Furthermore, the above protocol uses HIMMO identities to allow for early detection and prevention of DoS attacks at relaying devices and at the border router Secure operation Secure operation aims at fulfilling security goals S-3, S-5, S-6, S-8, S-9, S-10, S-11 and all operational and performance objectives. 14

29 3 Design Firstly, we illustrate how HIMMO ensures a fully collusion resistant mesh network based on IEEE IEEE supports the usage of pairwise keys between devices, however, key agreement is left out of the standard. Therefore, in practice, most standards rely on a network or system-wide key so that if a single device is captured, then the whole network or system breaks down. Furthermore, compromised devices cannot be easily identified since an attacker can fake any identity so that securely updating such a network or system wide key is infeasible (in addition to being very costly from an operational point of view). In our security architecture, secure operation in a IEEE network works as follows: - Step 1: Note ξ will advertise its presence by means of unsecured broadcast beacon. - Step 2: Node η will obtain a common HIMMO key with device η as K η,ξ = Gη (ξ) N. Node η will also obtain helper data σ 2 b η,ξ. If node η has joined the network, then it will use pairwise key Kη,ξ Network = K η,ξ K Network. If node η has not joined the network yet, then it will use pairwise key K η,ξ. - Step 3: Node η sends a secure IEEE message to ξ protected with the pairwise key determined in the previous step. This message contains the MAC address of the sender (η) and σ η,ξ in the Key Identifier field of the security header. - Step 4: Node ξ receives the secure message from η. It generates the pairwise HIMMO key with the MAC address of η as K ξ,η = G ξ (η) N and recovers 2 b K η,ξ from K ξ,η and σ η,ξ. Assuming that node ξ has already joined the network, then ξ knows K Network so that it can compute Kη,ξ Network and process the incoming message with both K η,ξ and Kη,ξ Network. If the verification of the message with K η,ξ is successful, then node η is considered a joining device and only DTLS traffic for network access is allowed. Alternatively, the message is verified with Kη,ξ Network so that the device is identified as part of the network and normal routing and data traffic is enabled. This solution enables pairwise keys between devices based on HIMMO so that the IEEE network becomes fully collusion resistant to the physical capture of devices. Note that this represents a huge improvement with the state-of-the-art in which most deployments rely on a single network-wide or even system-wide key that represents a single point of failure. Furthermore, compromised devices can be identified since the HIMMO keying material is cryptographically bound to the device identifier and in this case it is chosen to be the MAC address of the device. This means that captured devices can be blacklisted. Finally, this method allows us to easily differentiate devices that have joined the network from devices that have not done so yet. This differentiation, however, could also be determined by indicating which key is used to protect the packet by using the Key Index field of the Key Identifier in the IEEE Auxiliary Security Header (ASH) [7]. This would avoid verification of the packet with two keys in Step 4. The Key Index field (or a part of it) will indicate to node ξ which key, K η,ξ or Kη,ξ Network, was used to secure the packet. 15

30 3 Design We further note that HIMMO cannot only be used at MAC layer to generate pairwise keys between neighboring devices, but it can also be used to enable secure communication between any pair of devices in the network/system at application layer by means of DTLS [1]. This is similar to the process described in previous section with the difference that the communication is not between the joining device and the back-end server, but between two arbitrary devices. As a consequence any pair of devices can securely agree on a common symmetric key used in DTLS and verify any other set of credentials. Performance benefits will become clear in Chapter Secure software update A protocol for secure software updates is also enabled, ensuring message integrity and source authentication. For this scenario, we assume that software updates are sent by the back-end server. We propose here two different designs for this protocol. The benefits and drawbacks of each one will be analyzed in Chapter 5. The first design is directly based on the scenario in Figure 3.2. The process for a secure software update will be the following: On the back-end server: - Step 1: Compute hash of the software image: H(M). - Step 2: Send H(M) to the TTPs. - Step 3: The TTPs will generate a keying material with H(M) as its credentials: G H(M) (y). This keying material will be sent to the back-end server. - Step 4: The back-end server will append G H(M) (y) to the software update, working as a signature. Upon reception of the complete software update, the node will: - Step 5: Extract the signature from the message. - Step 6: Compute hash of received software image as: H(M ). - Step 7: Using H(M ) as credentials, the node will calculate the HIMMO key, using their keying material as: G ξ (H(M )). - Step 8: Using the received keying material, the node will calculate the HIMMO key, using his own ID as input: G H(M) (ξ). - Step 9: Compare G ξ (H(M )) and G H(M) (ξ). Testing that both keys are equal authenticates the source and the integrity of the message, as only the TTPs is able to generate the keying materials. The second proposed design builds on the idea of the back-end server working also as a TTP. In this scenario, the back-end server will generate and distribute through the secure links described in Section another set of keying materials. From then on the process is very similar to the described above, the only difference is that the back-end server does not need to rely on the TTPs in order to sign the software update. 16

31 3 Design The signing procedure for the back-end server would be as follows: - Step 1: Compute hash of the software image: H(M). - Step 2: Generate a keying material with H(M) as its credentials: G H(M) (y). - Step 3: Append G H(M) (y) to the software update. protocol in the node will be as above, with the difference that the used keying material for verification of the signature would be different than the one used in secure operation shown in Section DTLS-HIMMO This section details the DTLS-HIMMO protocol used in the security architecture. This protocol improves existing DTLS ciphersuites in order to fulfill the goals in Section 3.1. Current DTLS cipher suites for key agreement are based on PKC, which is too computationally expensive for an IoT scenario and also does not provide quantum-security, or in PSK that does not scale and presents some security problems as discussed before in Section 1.1 and Section The properties we want it to have are: Low operational cost, as DTLS-PSK. Enable mutual authentication and credential verification as with certificate-based schemes. Scalable like solutions based on public-key cryptography and infrastructure. Quantum-secure. To this end, we take the DTLS-PSK mode that is based on identities, and we extend it without need of changing the standard so that it can work with HIMMO. The main difference from the usual PSK profile lies in using identities to generate a pairwise symmetric key and, then, deriving the session keys from the pairwise symmetric key. A TTP provisions keying material to client nodes and the server. HIMMO can be directly used in (D)TLS-PSK mode by exchanging HIMMO s identifiers in the ClientKeyExchange and ServerKeyExchange messages DTLS-HIMMO configurations The existing PSK profile, such as the one used in TLS_PSK_WITH_AES_128_CCM_8, involves the exchange of two fields, the PSK identity and PSK identity hint, in the ClientKeyExchange and ServerKeyExchange messages respectively. Instead of sending a PSK identifier, we use these fields, which can be up to 128 bytes long [23], to exchange HIMMO information. 1 Creation of a new profile to indicate DTLS-HIMMO (eg. TLS_DTLS-HIMMO_WITH_AES_128_CCM_8) can also be considered, but will require standardization. 17

32 3 Design Table 3.1 illustrates these fields of information with exemplary lengths. First, we find an identifier/flag indicating the use of DTLS-HIMMO. Next, we find a DTLS-HIMMO message type to indicate which properties are enabled by HIMMO. The third and fourth field refer to the number of TTPs as well as their identifiers. These are the TTPs associated with generating and distributing the key material of the client and server. These two fields are followed by an identifier. Next, we optionally find the HIMMO credentials length as well as the credentials themselves. Finally, a field that contains the key reconciliation data is present. Table 3.1: Exemplary format of the PSK-identity-hint and PSK-identity fields enabling DTLS-HIMMO. Mandatory (M) and Optional (O) fields. Flag Type # TTP TTP ID ID Credentials length Credentials CF Bytes N B (122 B) N M/O M M M M M O O O This message format is used in the PSK-identity-hint and PSK-identity fields of the ServerKeyExchange and ClientKeyExchange messages. With these fields we can enable different ways of using HIMMO with DTLS-PSK. If only the HIMMO identifier is exchanged in the identifier field, then only mutual authentication is achieved between client and server. Alternatively, the client, or server, or both of them might exchange their credentials. The credentials could be any information that today is exchanged in regular digital certificates and, for IoT scenarios, information such as manufacturer, device type, date of manufacturing, etc. In this case, the exchange enables unilateral or mutual implicit credential verification of the parties. We note that in this case, the identifier field does not contain the HIMMO identifier but a unique random value that concatenated with the information in the HIMMO credentials length and HIMMO credentials is hashed to obtain the HIMMO identifier. The fields containing the TTP information enable the option of using multiple TTPs in different ways we can use all of them, one, or a subset thus, enhancing privacy as seen in Section DTLS-HIMMO handshake The DTLS-HIMMO handshake is shown in Figure 3.3, messages inside a box represent where the HIMMO information is exchanged, with the respective steps explained below: - Step 1: The client sends a ClientHello message to the server indicating use of the PSK mode, such as the TLS_PSK_WITH_AES_128_CCM_8. - Step 2: The usual HelloVerifyRequest message, with a cookie, is sent from the server to the client. - Step 3: The client replies back with ClientHello along with the cookie. - Step 4: The server replies with ServerHello, ServerKeyExchange containing the HIMMO information in the PSK-identity-hint and ServerHelloDone. 18

33 3 Design - Step 5: The client calculates the HIMMO key and (optionally) verifies the server credentials. The client sends the ClientKeyExchange containing the HIMMO information in the PSK-identity-hint. It also sends the usual ChangeCipherSpec and Finished messages to the server. - Step 6: The server calculates the HIMMO key and (optionally) verifies the client credentials. The server sends back the usual ChangeCipherSpec and Finished messages to the client. Client ClientHello HelloVerifyRequest (with cookie) ClientHello (with cookie) ServerHello ServerKeyExchange (Step 4) ServerHelloDone Server ClientKeyExchange (Step 5) ChangeCipherSpec ComputeDkey VerifyDcredentials* Finished ChangeCipherSpec Finished Application Data ComputeDkey VerifyDcredentials* Figure 3.3: DTLS-HIMMO handshake 3.4 Software design In order to realize if the architecture fits the goals and do proper testing of the protocols that form the architecture, we need software that implements them. For this purpose, we have built a generic HIMMO implementation. We detail here the design of this software. In Figure 3.4 we can see the logical structure of the HIMMO library for embedded devices: the main component is the HIMMO key generation function, that is build upon the multiple precision arithmetic; on top of the key generation function, we can see the HIMMO extensions for multiple TTP support and credential verification TTP design A HIMMO TTP needs to implement the functionalities described in Section 2.3: generate a root keying material, store it, and use it to generate the keying materials of the nodes. On top of that, we want for our TTP implementation to be able to register new 19

34 3 Design Multiple TTP Credential verification HIMMO_key Multiple precision arithmetic Figure 3.4: Logical structure of the HIMMO library. nodes, select if there is a need for credentials or only identification, and distribute keying materials. In order to use the TTP as a reference implementation, we want to be able to simulate a complete HIMMO system, including simulating of the key agreement between registered nodes HIMMO library for embedded devices HIMMO has been designed keeping in mind that we want to achieve very good performance. As we saw in Equation (2.3), the key generation consists of the evaluation of a polynomial modulo N and taking the b LSBs. A good choice for N is 2 B(α+1)+b 1 because this simplifies the implementation of modular reductions on the devices. In Algorithm 1 we show an optimization of the key generation algorithm whose underlying method is the well-known Horner s Rule. Each intermediate value is computed as follows temp j N = temp j+1 η + G ξ,j N for j = α 1,..., 0. To perform the modular reduction we take advantage of N s specific form, 2 B(α+1)+b 1 and the small size of η. Thus, temp j N = temp H j 2 (α+1)b+b + temp L j N temp H j + temp L j where temph j and temp L j are b and (α + 1)B + b bits long, respectively. This is an approximation because there might be a carry in the addition of temp H j and temp L j, requiring a second reduction. However, as shown in the appendix, this second reduction is needed at most once during the calculation, and ignoring it leads to a difference of one (mod 2 b ) between the wanted key and the value returned by the algorithm, so that α G ξ,j η j N 2 b {key, key b}. j=0 20

35 3 Design Algorithm 1 Optimized key generation 1: INPUT: B, b, α, η, G ξ,j with j {0,..., α} 2: OUTPUT: key 3: key G ξ,α 2 b 4: temp G ξ,α 2 b 5: for j = α 1 to 0 do G 6: temp temp η + ξ,j 2 (α 1 j)b+b 7: key key η 2 b + G ξ,j 2 b 8: key key + temp 2 (j+2)b 2 b 9: temp temp 2 (j+2)b 2 B 10: end for 11: return key As we have seen, the HIMMO key agreement generates b bits long pairwise keys between any 2 devices in the system, instead of choosing a high value of b, we use several instances each of them with a lower value of b, e.g. we can generate a 128 bits long key with 4 HIMMO instances of b = 32. This is done for security reasons, as the value of α should be close to be value of b. It is worth noting that each of the n b bit keys has to be generated from a different keying material, meaning that all nodes have to be provided with n keying materials. Interface The interface to interact with the HIMMO library has to be very simple. This interface should include two calls: himmo_key: generate a HIMMO key. It also generates the reconciliation data or updates the key with a certain reconciliation data. himmo_verify: verify that some credentials are linked to a certain HIMMO ID. It computes the hash of the credentials and compare it with the ID. Portability The library needs to be portable so that it can be easily used on different devices with different architectures and capabilities. Multiple precision arithmetic The size of the numbers involved in the HIMMO key agreement makes necessary to use multiple precision arithmetic. We decided to implement our own multiple precision arithmetic library, as the operations we need to support are just a few and using a complete and well-known library like GMP [24] would greatly increase the size of the code. 21

36 3 Design First, we define a way to store the numbers. For this purpose, we use a structure with 2 fields: size, length in words of the number, and data, array containing the data of the number. The number is stored in the array from less significant word to most significant word Table 3.2 shows an example of the structure, this makes the implementation of operations a lot easier, as the number are already aligned. Table 3.2: Long number representation of , assuming words that can store integers from 0 to 99. Long number size -> 5 data -> (89, 67, 45, 23, 01) We observe that the most expensive operation of the implementation is the multiplication. In the key agreement algorithm, all of them share two properties: one of the operands is always much larger than the other, and the result can be truncated to the length of the bigger. We propose 3 multiple precision multiplication algorithms: the most simple one a binary multiplication, then we present a naive schoolbook multiplication, finally we tweak the naive schoolbook implementation into a What if? multiplication. The binary multiplication takes two numbers a, b, being a the bigger. We multiply the first bit in b times a, which will produce either a copy of a or zero. Then, we shift a one bit to the left and multiply again. We add these intermediate results to get the final result. This algorithm is easy to implement, but it is also quite slow.[25] The naive schoolbook multiplication implements the classic pen and paper multiplication algorithm. Here, we have to take into account the long_number structure. As each chunk of the number is represented using the biggest word length of the architecture, if we multiply two of them the result will be two times the word length of the architecture. To avoid that, we transform the uintw_t into uinthw_t before the multiplication. Now, the size of the result of multiplying 2 uinthw_t will fit in a uintw_t. Because of doing this transformation, we end up having uintw_t shifted one half word, as we can see in Figure 3.6. This makes necessary to add more logic to the implementation, degrading its performance, but even taking this into account, this algorithm is much faster than the binary multiplication presented before. What if? is based on the naive schoolbook multiplication, but tries to get rid of the extra logic needed to handle the results and does the multiplication in a more sequential way. Instead of checking in each iteration for the correct alignment of the result, we group the multiplications so that the alignment is the same in each group. This way, we get rid of a condition that otherwise is checked each iteration. Keying material storage From Algorithm 1 it is also clear that part of the coefficients G ξ,j with j {0,..., α} are not used in the key generation process. This is because of the smaller size of the HIMMO 22

37 3 Design Figure 3.5: Long number schoolbook multiplication. uinthw_t in light blue, uintw_t in dark blue. Figure 3.6: Long number What if? multiplication. uinthw_t in light blue, uintw_t in dark blue. 23

38 3 Design identifiers (B bits) compared with the relatively long coefficients ((α + 1)B bits). This allows for a further optimization in which only the required parts of the coefficients are stored, namely the b least significant bits and the (j + 1)B most significant bits of each coefficient G ξ,j. C α C α-1 C α-2 C 1 C 0 B B b Figure 3.7: Optimized keying material storage. Key reconciliation One particularity of HIMMO is that the pairwise keys need not to be equal, but it is enough for them to be within a given range. Because of that, in order to agree in a pairwise key, it is necessary to go through the key reconciliation process explained on Section 2.3. The algorithm for key reconciliation in η, after receiving σ ξ,η from ξ is the following: < 0, K η,ξ = ˆK (σ η,ξ σ ξ,η ) if(σ ξ,η σ η,ξ ) = 0, > 0, K η,ξ = ˆK K η,ξ = ˆK + (σ ξ,η σ η,ξ ) (3.1) As our long number structure does not define negative numbers, it is necessary to manually check the difference between the keys before updating. 24

39 4 Implementation We describe in this chapter the implementation of key elements of the architecture presented in Chapter 3. TTP functionality, HIMMO library for embedded devices, and the DTLS-HIMMO mode for DTLS. 4.1 HIMMO TTP A basic TTP implementation must enable the setup and keying material extraction phases described in Section 2.3 that are the basis of the HIMMO scheme. The keying material extraction should be compatible with the implementation of the HIMMO key agreement algorithm in order to be able to provide the nodes implementing the key agreement library with keying materials. On top of the basic TTP functionalities we add a couple of interesting features: Taking advantage of the fact that the TTP is not going to run in a constrained device, we add the simulation of a complete HIMMO infrastructure. This lets us test any other HIMMO implementations and also provides a useful overview of a HIMMO infrastructure. As the devices running the HIMMO key agreement will likely be quite different one from another, we add the possibility to select the target architecture of the device in order to optimize the library for its particular architecture (Figure 4.2). The TTP is implemented in a Java desktop application (Figure 4.1). We build a simulation of a complete HIMMO infrastructure based on two classes: HimmoTTP and HimmoNode. HimmoTTP contains the TTP functionalities, it sets up the system and register new nodes by providing them with keying materials and credentials. When the HimmoTTP wants to register a node, it creates a HimmoNode object. The HimmoNode object simulates a node storing the key material along with its own identifier and credentials, and implements the key agreement algorithm. We can use this to simulate a key agreement process between 2 nodes and we can also extract its keying material. Using the TTP application is very easy. First, we choose the public parameters of the HIMMO system. Based on these parameters, the TTP creates a secret root keying material and a HimmoTTP object. Upon creation of the HimmoTTP, we can start registering nodes into the system. Each node registration will create a HimmoNode object that will appear in the right panel of the application. These nodes can be selected to simulate pairwise key agreement between 2 of them or to extract its keying material and credentials. Finally, the created HIMMO infrastructure can be saved and retrieved later. 25

40 4 Implementation Figure 4.1: Screenshot of the TTP application. 4.2 Key agreement The implementation of the key agreement algorithm should be portable as we aim at the broad range of devices that form the IoT, fast computationally inexpensive, and easy to use should be easy to integrate in proof of concept projects. The HIMMO key agreement algorithm had been implemented before in [26] and [25], but only for specific devices. The HIMMO key agreement is implemented in a C library, being able to run in a wide range of devices with good performance. Lower level approaches can achieve better performance at the cost of running on a specific device or architecture. Higher level approaches are unlikely to work on constrained devices, as most of them do not implement the virtual machines or interpreters needed for those languages Portability We define two new types to support the different architectures uintw_t for word-size and uinthw_t for half-word size. The naming convention is inspired in the stdint.h library for fixed-length integers. The selection is shown in Listing 4.1. The half-word size is needed for the multiplication implementation, as a multiplication between two operands of word size can overflow. 26

41 4 Implementation Figure 4.2: Detail of keying material generation. Listing 4.1: Word length selector # if WORD == 16 typedef uint16_ t uintw_t ; typedef uint8_t uinthw_ t ; # elif WORD == 32 typedef uint32_ t uintw_t ; typedef uint16_ t uinthw_ t ; # elif WORD == 64 typedef uint64_ t uintw_t ; typedef uint32_ t uinthw_ t ; # endif // WORD Multiple precision arithmetic After defining a word size type, we can define a structure that makes use of it to store long integers as shown in Section Listing 4.2 shows the long_number structure. Listing 4.2: Long number structure typedef struct { int size ; uintw_t * data ; } long_ number ; For the multiplication, we have implemented the schoolbook algorithm as well as the What if? algorithm described in Section

42 4 Implementation 4.3 DTLS-HIMMO We have implemented the DTLS-HIMMO mode in the CyaSSL [27] library to test its feasibility and be able to assess its performance. CyaSSL is an open source and commercial lightweight SSL/TLS library written in C for resource-constrained devices, this allows us to use our C HIMMO library. The DTLS-HIMMO implementation builds on the DTLS-PSK mode and modifies it as described in Section 3.3. To do this, we add HIMMO to the cryptographic primitives supported by the library and we use the key agreement function along with the data exchanged in the PSK-Identity-Hint to generate the pairwise key. We also create a structure that contains the fields of the PSK-Identity-Hint used in DTLS-HIMMO as well as a serialization function to send it and a de-serialization function to retrieve it. We can see in Figure 4.3 a Wireshark capture showing the DTLS-HIMMO handshake. In Figure 4.4 we can see the format of the Identity Hint as described in Section 3.3. Figure 4.3: DTLS-HIMMO capture overview. 28

43 4 Implementation Figure 4.4: DTLS-HIMMO Identity-Hint capture. 29