Veilige communicatie in het Internet of Things via een vertrouwde gateway

Veilige communicatie in het Internet of Things via een vertrouwde gateway Tom Vandewinckele

Promotoren: prof. dr. ir. Ingrid Moerman, dr. ir. Jeroen Hoebeke Begeleiders: ir. Floris Van den Abeele, Jen Rossey Masterproef ingediend tot het behalen van de academische graad van Master of Science in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2013-2014

Veilige communicatie in het Internet of Things via een vertrouwde gateway Tom Vandewinckele

Promotoren: prof. dr. ir. Ingrid Moerman, dr. ir. Jeroen Hoebeke Begeleiders: ir. Floris Van den Abeele, Jen Rossey Masterproef ingediend tot het behalen van de academische graad van Master of Science in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2013-2014

Voorwoord Als afsluiter van mijn opleiding Ingenieurswetenschappen in de Computerwetenschappen aan Universiteit Gent werkte ik een gedurende een jaar aan mijn masterproef. Deze verliep in nauwe samenwerking met de onderzoeksgroep IBCN binnen iMinds. Gezien mijn interesse voor netwerken en beveiliging is de keuze voor dit onderwerp vanzelfsprekend. Bovendien is het Internet of Things momenteel zeer populair: er worden dagelijks nieuwe artikels gepubliceerd. Hierbij wil ik een aantal personen bedanken. In de eerste plaats mijn ouders die mij de kans geboden hebben om verder te studeren. Graag dank ik ook mijn vriendin voor de vele steun gedurende het ganse jaar. Daarnaast gaat mijn dank uit naar mijn begeleider Floris Van den Abeele voor de wekelijkse opvolging. Jeroen Hoebeke wil ik bedanken voor de hulp met het aanleren van Click en het nalezen van mijn scriptie. Ik bedank professor Ingrid Moerman voor deze opportuniteit.

Tom Vandewinckele, Gent 2014

Toelating tot bruikleen “De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Tom Vandewinckele, Gent 2014

Veilige communicatie in het Internet of Things via een vertrouwde gateway door Tom VANDEWINCKELE Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2013–2014 Promotoren: prof. dr. ir. I. MOERMAN dr. ir. J. HOEBEKE Begeleiders: ir. F. VAN DEN ABEELE J. ROSSEY Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. D. De Zutter

Samenvatting In deze masterproef wordt nagegaan wat de impact is van het toepassen van DTLS in low power and lossy networks, wat betreft energieverbruik, responstijd, packet overhead en geheugenvereisten. Er wordt voorgesteld om het DTLS–verkeer te termineren op de gateway en via een langdurige DTLS–sessie, tussen de gateway en het constrained device, beveiligd te communiceren. Op deze manier hoeft het constrained device slechts één DTLS–sessie te onderhouden voor de communicatie met verschillende clients. Aan de hand van de eerder vermelde metrieken wordt de winst van deze manier van werken besproken, samen met de voor– en nadelen.

Trefwoorden Internet of Things, DTLS, beveiliging, ContikiOS, low power and lossy network, PSK

Secure communication in the Internet of Things via a trusted gateway Tom Vandewinckele Supervisor(s): Ingrid Moerman, Jeroen Hoebeke, Floris Van den Abeele, Jen Rossey Abstract— In this paper we propose a fully implemented secure communication architecture for the Internet of Things based on existing Internet standards, specifically the Datagram Transport Layer Security (DTLS) protocol. As the use of DTLS on constrained devices requires a lot of energy, we aim to be more energy efficient by terminating the DTLS session at the gateway between the Internet and the low power and lossy network (LLN). Moreover, we use a pre–shared key cipher suite instead of relying on certificates. Traffic for all Internet nodes use the same DTLS session in the LLN, more specifically the one between the gateway and the constrained device. This allows for only one DTLS session at the constrained device for multiple clients. In this paper, the implementation is explained and evaluated using multiple metrics. These metrics were evaluated in the Cooja network simulator for ContikiOS on the RM090 hardware platform. Keywords—IoT, DTLS, PSK, security, Contiki, gateway

I. I NTRODUCTION HE Internet as we know it today is used for communication between several people. Typical applications are: e–mail, VoIP, social networks, blogs,... A typical trend, that has been growing for the last couple of years, is the vast amount of data that’s available on this Internet. Another trend is that more and more machines are connected to this Internet: laptops, smart phones, tablets,... It is expected that this number will only grow: more and more devices, or “things” will be connected to this Internet and communicate using the Internet Protocol. We call this trend the Internet of Things. The applications in this Internet of Things can be found in every application domain: health care, environmental sector, home appliances, food sector,... Multiple appliances are already on the market: the smart thermostat (Nest), the keyring (Tile), configurable lamp (Philips Hue), the smart lock (August Smart Lock), the smart plant (Botanicalls),... Like most of today’s applications on the Internet, these IoT applications also require security mechanisms: you don’t want a stranger to know what’s in your fridge, to turn off your lights or open your front door. Thus, certain applications require authentication. Others require confidentiality: certain information cannot be read by unauthorized parties. To realize these security mechanisms in the Internet of Things, we try to reuse existing Internet standards. This approach has many advantages: less work (only a few adaptations necessary), interoperability with Internet nodes,... The IETF security working group, DICE [1], prefers DTLS over IPsec to provide secure communication in the Internet of Things. However, DTLS can’t be fully reused for some constrained devices. DTLS is already an adaptation of the TLS protocol that is used on the Internet. This modification of the TLS protocol was necessary because the UDP protocol is used for wireless networks instead of the TCP protocol. Another challenge of using DTLS in LLNs is the amount of energy that is spent on security and the amount of ROM– and RAM–memory that’s required to run the DTLS client or server

T

on this constrained node. Most of these devices are equipped with a small battery: every Joule of energy is important. All the energy that is spent on security can’t be used for the communication of useful data. Moreover, constrained devices in LLNs are typically located in places where you can’t change the battery every six months. Even if you can, it’s an infeasible job: constrained devices are cheap and thus deployed in large quantities. Because of the low cost of these devices, they are very constrained: the processor isn’t very powerful, the memory capacity is very limited and the radio isn’t the strongest one either. These constraints have certain consequences for running DTLS on these motes. Most of today’s research, including DICE research, tries to limit the footprint of DTLS on these constrained devices by for example compressing the DTLS packets. Our approach (Figure 1) tries to save energy by terminating the DTLS session at the gateway between the Internet and the LLN. Moreover, we use a pre–shared key cipher suite instead of certificates to limit the memory requirements by avoiding asymmetric cryptography. Traffic for all Internet nodes use the same DTLS session in the LLN. This allows for only one DTLS session at the constrained node for multiple clients. This approach requires a trusted gateway, because all traffic is decrypted and encrypted again on this device. This paper is organized as follows: We outline related work in Section 2. In section 3 we explain the design and implementation. Practical information about the experiments is given in Section 4. The evaluation of the use cases, by performing measurements in the Cooja network simulator, is presented in Section 5. Section 6 concludes our work and proposes some future work. II. R ELATED WORK This section gives a brief guide of the DICE research and handles two existing security proposals for constrained devices in LLNs. A. DICE working group DTLS In Constrained Environments (DICE) is a working group in the IETF, that focuses its research on end–to–end DTLS secured communication in constrained environments. These environments are characterized by very low power devices and a lossy network. The constrained devices are equipped with a weak micro controller and a low amount of memory. On top of that, these devices have a weak radio. The most important job for DICE, is to define a DTLS profile for constrained environments. The second task to accomplish is to support DTLS for multicast communication. DICE’s third task is to solve the issues with fragmentation and retransmission of DTLS handshake messages in constrained environments. DICE already published

a few Internet-Drafts to support DTLS in constrained environments: • Compression of Record and Handshake Headers for Constrained Environments [2]: This draft explains header compression for DTLS, using the Next Header Compression mechanism described in RFC 6282. The DTLS record header, handshake header and optionally the headers of the handshake messages are compressed. • CoDTLS: DTLS Handshakes over CoAP [3]: DTLS messages are usually sent on top of the UDP protocol. A lot of packet loss can appear in constrained environments, and the room for useful data in the packets is rather small. Often applications can adapt the size and retransmission settings of these packets. This motivates the idea to communicate DTLS on top of CoAP. • Profiling of DTLS for CoAP-based IoT Applications [4]: This document describes several implementation issues for DTLS in constrained environments. A DTLS profile for CoAP–based applications is presented. A DTLS handshake based on the REST principles is proposed, which uses CoAP Blockwise Transfer to solve fragmentation issues. • A DTLS 1.2 Profile for the Internet of Things [5]: This draft defines a DTLS profile for applications in the Internet of Things. Topics as authentication based on pre–shared secret keys, raw public keys or certificates are discussed.

Because of the heterogeneity of the communicating parties, different DTLS implementations are required. The use of constrained devices and more powerful desktops demand for various cipher suites. A. Design The goal of this research is to discover what the impact of security is on the constrained devices regarding packet delay, energy consumption, memory requirements and packet overhead. Furthermore, to reduce the energy consumption on the constrained devices, we propose to terminate the DTLS traffic on the gateway. This allows for the gateway to choose a less energy consuming security mechanism in the LLN. A constrained environment doesn’t always require security, or link layer security can be performed by the radio using pre–shared keys. If a more secure mechanism is required, the gateway can always set up a long–lived DTLS session with the constrained device (Figure 1). This session can be used to send traffic from several Internet clients to the device. This approach saves a lot of energy by minimizing the number of executed DTLS handshakes to one, even for communication with several clients. On the other hand, for the constrained device, all requests appear to be sent from the gateway. To calculate the cost of secured DTLS communication on a constrained device, a reference case is implemented that exchanges plain text CoAP messages.

B. Lithe Lithe [6] secures CoAP messages in the Internet of Things with DTLS. The authors propose a novel DTLS header compression scheme that aims to significantly reduce the energy consumption by leveraging the 6LoWPAN standard. The header compression scheme significantly reduces the number of transmitted bytes and ensures interoperability with other DTLS implementations. Their approach is evaluated using the open source TinyDTLS implementation on ContikiOS. Significant gains in terms of packet size, energy consumption, processing time, and network-wide response times are observed. C. Delegation-based Authentication and Authorization for the IP-based IoT Paper [7] introduces an architecture for delegation purposes that executes the DTLS Handshake on a trusted and powerful delegation server. Afterwards, the security context is transferred securely to the constrained device by using the session resumption mechanism in DTLS. This transfer is secured by symmetric key cryptography that requires a secret pre–shared key between the constrained device and the delegation server. This allows for the delegation server to authenticate and authorize Internet nodes. The approach saves a lot of resources on the constrained device: memory requirements decrease with 64 %, calculations drop with 97 % and there’s 68 % less traffic. This research is very similar to our research. Opposed to the research presented in [7], a lot of options are still open in our case: the use of DTLS in the LLN is an option, not a must. III. D ESIGN & IMPLEMENTATION This section describes the design goals of the research together with the implementation of the communicating parties.

Fig. 1. Design: terminate DTLS sessions at the gateway. Use a long–lived DTLS session in the constrained environment for all Internet nodes.

B. Implementation For constrained devices, their low processing power and low memory capacity have its consequences on the used algorithms, and thus the chosen cipher suite. Typically, a pre–shared key cipher suite is used in constrained environments: TLS-AES-128CCM-8. It uses the block cipher Advanced Encryption Standard algorithm. This algorithm is symmetrical, so it uses the same operations for encryption and decryption, which allows for a smaller code size. Moreover, executing the AES algorithm in CCM mode ensures both confidentiality and authentication. In addition to these advantages, devices often contain an AES hardware accelerator. For these experiments, an open source DTLS implementation is used: TinyDTLS [8]. For plain text CoAP communication, the Contiki Erbium server is employed. One can assume that an Internet node typically has less constrained specifications. Therefor, it supports more powerful and stronger cipher suites. Because this research also contains a scenario where end–to–end DTLS is communicated with a constrained device, we want the Internet node to also support the typical cipher suite for constrained devices. A library that sup-

ports both the more powerful and less powerful cipher suites is Scandium [12]. Scandium is a DTLS implementation for the Californium CoAP–framework [11]. Our gateway is very similar to the Internet node: it’s a normal computer and has to support both types of cipher suites. In contrast to the Internet node, the gateway consists of both a DTLS client and server. This is necessary to terminate DTLS traffic coming from the Internet and send the traffic via a new DTLS session in the constrained environment. The gateway is build by the IBCN research group at iMinds using Click [10]. It is extended with CyaSSL [9] to support DTLS. IV. E XPERIMENTS The experiments, performed to evaluate our approach, are executed in the Cooja network simulator. The motes consist of the RM090 hardware platform with the ContikiOS. The RM090 hardware platform is equipped with the 5th series (msp430f5437) Texas Instrument MCU and the CC2520 radio transceiver. The msp430 is a 16–bit micro controller. 20–bit memory access is supported. The RM090 contains 16 kB RAM and 128 kB ROM memory. The Energest [14] software tool is used to measure the energy consumption on the constrained devices. Memory requirements are provided by the msp430–size and msp430–objdump tools. Because the RM090 doesn’t contain an AES accelerator in hardware, encryption and decryption operations are executed in software. The ContikiOS is configured to use the µIP–stack and the RPL routing protocol. The distance between the 6LoWPAN border router and the DTLS server is only one hop. No radio duty cycling (RDC) mechanism is used, because of compatibility issues with TinyDTLS. Moreover, the use of an RDC driver influences the results, which will be different for every driver. Hardware interrupts are enabled in order to measure the energy that is consumed while actually receiving a packet.

B. Packet overhead The packet containing the CoAP request is 72 bytes long and the response contains 70 bytes. A simple GET message is sent for the HELLO–resource. The DTLS secured CoAP request is 101 bytes long, while the secured answer is 99 bytes long. The DTLS message contains a DTLS header (13 bytes) and the encrypted CoAP message requires 16 more bytes. On top of that, the exchange of DTLS Application Data requires the execution of a DTLS handshake. 1225 bytes are exchanged during this handshake: this is 86 % of all exchanged bytes. C. Energy consumption The radio consumes most of the energy: the reception of the CoAP request consumes 0.29 µJ, while the transmission of the answer consumes 0.39 µJ (Figure 2). While the answer is only one byte larger than the request, we observe a larger energy consumption for transmission. This is due to the specifications of the radio: transmission is more expensive than reception. The CPU consumes 0.0092 µJ, while the constrained device consumes 0.017 nJ in low power mode. For end–to–end DTLS communication, the same observation can be made: the radio is the biggest energy consumer. Transmission consumes 4.6 µJ, while the reception consumes 4.4 µJ (Figure 2). These values are much larger than for plain text CoAP messages because of the performed DTLS handshake.

V. E VALUATION To get an idea what the cost of secured CoAP communication is, we first perform an experiment where plain text CoAP messages are exchanged between an Internet node and a constrained device. Afterwards end–to–end DTLS secured communication is evaluated. Subsequently, an experiment is performed where the DTLS traffic is terminated at the gateway and sent via a long–lived DTLS session between the gateway and the constrained node for all Internet nodes. A. Memory Requirements The Contiki CoAP server, Erbium, consumes 46.33 kB ROM and 5.94 kB RAM memory. To be able to secure CoAP with DTLS, both the Erbium and TinyDTLS server are required: the memory requirements rise to 68.7 kB ROM and 8.1 kB RAM memory. When support for multiple clients is enabled, the TinyDTLS server consumes 0.21 kB more ROM memory, and 1.75 kB more RAM memory per client. This is the first advantage of terminating the DTLS traffic at the gateway: support for only one DTLS session is required at the constrained device, which minimizes the memory requirements.

Fig. 2. Energy consumption for the exchange of a plain text versus DTLS secured CoAP request and response.

Although the energy consumption of the CPU is also small compared to the radio, it’s larger than compared with plain text CoAP messages: 0.24 µJ. This is due to the computation of the premaster secret, master secret, secret keys and encryption/decryption operations executed in software. When multiple clients are supported, the energy consumption rises linearly with the number of clients: multiple DTLS handshakes are executed before exchanging DTLS application data. Using the approach presented in this paper, only one DTLS handshake has to be performed in the constrained environment. When multiple clients communicate with the constrained device, only the energy for exchanging DTLS application data packets is consumed. This saves a lot of energy on the constrained device that can be used for the communication of useful data.

Fig. 3. Round–trip time for end–to–end DTLS versus DTLS termination at the gateway for multiple clients.

D. Round–trip time The median round–trip time for a plain text CoAP exchange is 143.21 ms. The average is larger than the median value because of retransmissions that occurred in some cases. The worst observed case had a round–trip time of more than two seconds. 1000 CoAP requests were sent to the constrained device, whereof 15 had to be retransmitted. As can be seen in Figure 3, the round–trip times for DTLS secured CoAP (first application data message) are much higher: respectively 2037.9, 2787.84 and 1844.72 ms for end–to–end DTLS, the termination of DTLS for the first client (execution of two DTLS handshakes) and for a second client that benefits of an existing DTLS session in the LLN and only executes a DTLS handshake with the gateway. These larger RTTs can be explained by the execution of one or multiple DTLS Handshake(s). For end–to–end DTLS, the median round–trip time for the following Application Data messages is 147.48 ms. This is 4 ms more than the plain text CoAP case, which can be explained by the larger packet that has to be sent over the network in combination with the encryption/decryption operations on the constrained device. When terminating the DTLS session at the gateway, the median round– trip time for a secured CoAP request is 191.43 ms. About 50 ms higher than the end–to–end case, which is caused by decryption and encryption operations at the gateway. Although the DTLS handshake takes about 500 ms longer for end–to–end DTLS, the round–trip time of the DTLS Application Data messages is smaller. This means that for the exchange of 25 messages between an Internet node and a constrained device, the client already saves 580 ms by setting up an end–to–end DTLS session compared to the termination approach presented in this paper. VI. C ONCLUSION With this research, we try to minimize the cost of secured DTLS communication on the constrained device by using a common long–lived DTLS session in the constrained environment for all Internet nodes. DTLS traffic is terminated at the gateway and another, less expensive, security mechanism can be applied in the constrained environment (for example the long– lived DTLS session). Advantages of this approach are that different cipher suites can be applied on the Internet than in the constrained environment. Moreover, as proved with the evalua-

tion, the energy consumption on the constrained device is much lower because of the use of only one DTLS session. Only one DTLS handshake has to be performed. Furthermore, the DTLS server on the constrained device requires less memory when communication with only one client can be supported. On the other hand, we proved that the Internet node actually doesn’t have a lot of advantages with this approach: the round–trip time rises when terminating DTLS traffic compared to end–to–end DTLS, if multiple requests/responses are exchanged. Moreover, the client allows a trusted third party in his secured communication. A compromised gateway exposes secured traffic with all constrained devices. For future work, we propose research on multiple hops between the 6LoWPAN border router and the DTLS server in the constrained environment, the compatibility of TinyDTLS with an RDC driver and the appearance of a bad link and the use of constrained devices as clients. An interesting topic to work on is the possibility of the gateway to cache CoAP responses. This approach allows the minimization of traffic in the constrained environment and saves energy on the motes. Furthermore, the use of an AES accelerator module on the constrained device can lower the energy consumption on the MCU and decrease the response times. Finally, one must not forget that these measurements were obtained in a simulator: measurements in a real environment on actual motes are necessary. R EFERENCES [1] DICE working group [Online. Last accessed: 10.05.2014]. http://datatracker.ietf.org/wg/dice/ [2] S. Raza, H. Shafagh, O. Dupont. “Compression of Record and handshake Headers for Constrained Environments”, in Active Internet-Draft, March 2014. https://datatracker.ietf.org/doc/draft-raza-dice-compresseddtls/ [3] L. Schmertmann, K. Hartke, C. Bormann. “CoDTLS: DTLS handshakes over CoAP.”, in Active Internet-Draft, February 2014. https://datatracker.ietf.org/doc/draft-schmertmann-dice-codtls/ [4] S. Keoh, S.S. Kumar, Z. Shelby. “Profiling of DTLS for CoAPbased IoT Applications.”, in Active Internet-Draft, November 2013. https://datatracker.ietf.org/doc/draft-keoh-dice-dtls-profile-iot/ [5] K. Hartke, H. Tschofenig. “A DTLS 1.2 Profile for The Internet of Things.”, in Active Internet-Draft, February 2014. https://datatracker.ietf.org/doc/draft-hartke-dice-profile/ [6] S. Raza, H Shafagh, K. Hewage, R. Hummen, and T. Voigt “Lithe: Lightweight Secure CoAP for the Internet of Things”, in IEEE SENSORS JOURNAL, VOL. 13, NO. 10, oct 2013. [7] R. Hummen, H. Shafagh, et al. “Delegation-based Authentication and Authorization for the IP-based Internet of Things”, in in 11th IEEE International Conference on Sensor, Communication, and Networking (SECON 2014). Singapore, Publisher: IEEE, June 2014. [8] TinyDTLS Documentation [Online. Last accessed: 02.04.2014]. http://tinydtls.sourceforge.net/ [9] Embedded SSL Library [Online. Last accessed: 28.04.2014]. http://www.yassl.com/yaSSL/Home.html [10] The Click Modular Router Project [Online. Last accessed: 06.05.2014]. http://read.cs.ucla.edu/click/click [11] GitHub: Californium [Online. Last accessed: 28.04.2014]. https://github.com/mkovatsc/Californium [12] GitHub: Scandium [Online. Last accessed: 28.04.2014]. https://github.com/mkovatsc/Scandium ¨ [13] F. Osterlind, “A sensor network simulator for the Contiki OS”, February 2006. [14] A. Dunkels, F. Osterlind, N. Tsiftes, Z. He. “Software-based On-line Energy Estimation for Sensor Nodes”, in EmNets 07, June 25-26, 2007, Cork, Ireland.

INHOUDSOPGAVE

i

Inhoudsopgave 1 Inleiding

1

2 Literatuurstudie

4

2.1

2.2

2.3

2.4

Achtergrondinformatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.1

Low power and lossy networks . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.2

Constrained devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.1.3

Het CoAP–protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

(Datagram) Transport Layer Security . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2.1

Transport Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2.2

Datagram Transport Layer Security . . . . . . . . . . . . . . . . . . . . .

12

2.2.3

Cipher suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

Gerelateerd werk: beveiligde communicatie . . . . . . . . . . . . . . . . . . . . .

18

2.3.1

Linklaag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.3.2

Netwerklaag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.3.3

Transportlaag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.3.4

Applicatielaag

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.3.5

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

State of the art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

2.4.1

IETF: DICE–werkgroep . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

2.4.2

IETF: ACE–werkgroep

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

2.4.3

Lithe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.4.4

Delegatie van de DTLS Handshake naar een krachtige vertrouwde partij .

24

2.4.5

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

INHOUDSOPGAVE

3 Ontwerp & Implementatie 3.1

3.2

3.3

ii

26

Ontwerp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.1.1

Gebruikersscenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.2.1

Constrained device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.2.2

Traditioneel toestel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

3.2.3

Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

3.2.4

Interoperabiliteitsprobleem . . . . . . . . . . . . . . . . . . . . . . . . . .

44

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

4 Resultaten

46

4.1

Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

4.2

Metrieken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.3

Evaluatiemethodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

4.4

Experimenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

4.4.1

Referentiecase: plain text CoAP . . . . . . . . . . . . . . . . . . . . . . .

52

4.4.2

Experiment 1: End–2–end DTLS . . . . . . . . . . . . . . . . . . . . . . .

55

4.4.3

Experiment 2: Terminatie DTLS op de gateway . . . . . . . . . . . . . . .

62

4.4.4

Experiment 3: Meerdere clients . . . . . . . . . . . . . . . . . . . . . . . .

64

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

4.5

5 Conclusie

68

A RM090 mote

71

A.1 Key Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

A.2 Technical Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

INLEIDING

1

Hoofdstuk 1

Inleiding Het Internet zoals we het nu kennen wordt vooral gebruikt als communicatiemiddel tussen verschillende personen. Welgekende voorbeelden hiervan zijn e-mail, chat, forums, VoIP, sociale netwerken,... Reeds gedurende enkele jaren observeert men dat enorme hoeveelheden data beschikbaar worden gesteld op het Internet. Daarnaast worden meer en meer toestellen er op aangesloten. Door de komst van smartphones, tablets, laptops, etc. is het aantal aangesloten toestellen op het Internet geëxplodeerd. Bovendien verwacht men dat dit aantal alleen maar verder zal groeien. Zo zullen ook machines, of meer algemeen ‘dingen’, worden aangesloten op het Internet en communiceren aan de hand van het alombekende Internet Protocol. Deze trend is bekend onder de naam “The Internet of Things” (IoT). De naam wordt al gebruikt sedert 1999 [1], maar op basis van de schaal, toepasbaarheid en complexiteit van dit ensemble kan men spreken over een volledig nieuwe trend in het applicatiedomein van het Internet. De technologie laat toe om producten en andere fysieke objecten informatie op te laten slaan, te versturen en te ontvangen op een manier dat het mogelijk maakt om onze volledige leefwereld te wijzigen. In de industrie spreekt men namelijk al over een vierde industriële revolutie of ‘industry 4.0’. Het aantal toepassingen van het Internet of Things is onvoorstelbaar groot. In elke sector is het aantal mogelijkheden enorm. Een aantal toepassingen die reeds op de markt zijn: De Asthmapolis is een apparaat voor astmapatiënten dat constant luchtwaardes, de locatie en de hoeveelheid ge¨ınhaleerd middel meet. Op deze manier kunnen artsen een beter inzicht krijgen in de klachten van de patiënt. Via een applicatie op de smartphone is het mogelijk om te zien welke gebieden in de stad het meest astmagevoelig zijn. De Nest Thermostaat is een slimme thermostaat. Met behulp van sensoren weet de thermostaat wanneer er iemand in de

INLEIDING

2

kamer is. De thermostaat is online te bedienen via het Internet én is op de hoogte van de weersverwachtingen. Philips presenteerde een serie lampen die online aan te sturen zijn. De lampen kunnen veranderen van kleur en intensiteit. Het is bijvoorbeeld mogelijk om deze te gebruiken als lichtbron, die steeds feller wordt, samen met je wekkerradio, die steeds luidere muziek afspeelt. Dankzij een API is het zelfs mogelijk om zelf aan de slag te gaan met de lampen. Veel van deze nieuwe toepassingen vereisen uiteraard beveiliging, net zoals de meeste applicaties op het huidige Internet. Het is namelijk ondenkbaar dat je buur je wekkerradio kan programmeren of nagaan welke producten er in je koelkast zitten. Gevoelige informatie moet vertrouwelijk worden gecommuniceerd. Voor andere toepassingen is authenticatie van de communicerende partijen een belangrijkere vereiste. Hiervoor probeert men om, in de mate van het mogelijke, zo veel mogelijk protocollen uit het Internet te hergebruiken. Dit heeft tot gevolg dat men sneller de ‘goede’ oplossingen kiest, waardoor er veel tijd wordt uitgespaard. Daarenboven is de interoperabiliteit met bestaande technologieën verzekerd, wat ook een grote troef is. Een groot aantal toepassingen in het IoT maakt gebruik van constrained devices die zich bevinden in “low power and lossy networks”(LLN’s). Deze constrained devices beschikken niet over krachtige processoren en bovendien zijn ze uitgerust met een zwakke radio. Deze zwakke radio wordt gekenmerkt door een lage bandbreedte en wordt zeer zuinig gebruikt: meestal is deze radio uitgeschakeld en wordt periodiek ingeschakeld om na te gaan of iemand probeert te communiceren met dit toestel. Vaak beschikken deze devices over een batterij als energiebron. Door de minder krachtige toestellen en zwakke radio spreekt men van LLN. Her en der zijn dus enkele aanpassingen vereist aan de bestaande protocollen, bijvoorbeeld voor het omgaan met pakketverlies door de zwakke radio’s. Daarenboven worden bestaande protocollen op het Internet uitgevoerd door krachtige desktop computers, die voorzien zijn van netstroom. Deze toestellen zijn helemaal niet te vergelijken met de zeer beperkte toestellen uit LLN’s qua rekenkracht, geheugencapaciteit en energieverbruik. De beperkingen die door het gebruik van constrained devices worden opgelegd, zorgen voor problemen indien men bepaalde protocollen, die zware berekeningen of veel geheugen vereisen, wil uitvoeren. Een grote uitdaging die vandaag bestaat, is het efficiënt uitvoeren van deze protocollen, met zo weinig mogelijk aanpassingen. ´ en Zo zijn er een aantal werkgroepen binnen het IETF aan het werk om dit te realiseren. E´ van deze werkgroepen is DICE, die onderzoek uitvoert omtrent het toepassen van DTLS als

INLEIDING

3

beveiligingsmechanisme in LLN’s. Het werk dat in deze masterproef wordt gerealiseerd, staat zeer dicht bij het werk van de DICE–werkgroep. Terwijl de onderzoekers van de DICE–werkgroep werken aan end–to–end DTLS–oplossingen, wordt in deze masterproef een vertrouwde en krachtige derde partij ingevoerd (e.g. de gateway) om de zware berekeningen uit te voeren en op deze manier het energieverbruik op de constrained devices te beperken tot een minimum. Voor de meest beperkte toestellen is het gebruik van end–to–end DTLS namelijk geen optie. Zo moet er bijvoorbeeld voor elke client een nieuwe DTLS–sessie worden opgezet, wat de levensduur van de batterij op het constrained device sterk beperkt. In deze masterproef wordt de DTLS–sessie afgebroken op de vertrouwelijke partij (gateway) en daarna verdergezet in het LLN. Een aantal scenario’s zijn mogelijk in het LLN: onbeveiligd communiceren, de vertrouwelijke partij (gateway) kan een langdurige DTLS–sessie opzetten met een constrained device die kan worden gebruikt voor verschillende clients, of er kan voor elke client een nieuwe sessie worden opgezet met het constrained device. Deze verschillende scenario’s worden met elkaar vergeleken op basis van packet delay, geheugenvereisten, kost van de DTLS–handshake en –headers, en uiteraard het energieverbruik. De indeling van deze masterproef is als volgt: in hoofdstuk 2 wordt meer achtergrondinformatie gegeven over LLN’s, (D)TLS en constrained devices. Daarna worden enkele bestaande beveiligingsmechanismen voor LLN’s op de verschillende protocollagen besproken. Ten slotte wordt de state–of–the–art omtrent DTLS in LLN’s behandeld. Hoofdstuk 3 bespreekt het ontwerp van de gebruikersscenario’s en de implementatie van de communicerende partijen. Hier worden eerst enkele scenario’s besproken en vervolgens de implementatie van de deelnemende partijen. Hoofdstuk 4 richt zich op de experimenten en bespreekt de bekomen resultaten. Daarna volgt de conclusie van deze masterproef, waarbij ook nuttig toekomstig werk wordt besproken.

LITERATUURSTUDIE

4

Hoofdstuk 2

Literatuurstudie 2.1 2.1.1

Achtergrondinformatie Low power and lossy networks

Low power and Lossy Networks (LLN’s) zijn een type van netwerken die bestaan uit beperkte toestellen en zwakke verbindingen. De toestellen zijn beperkt qua processorkracht, geheugen en energie. Ze communiceren via draadloze technologieën zoals IEEE802.15.4, low power WiFi, Bluetooth,... Een categorie binnen deze LLN’s zijn Wireless Sensor Networks (WSN’s). Een WSN is een netwerk dat bestaat uit nodes die data verzamelen, aan de hand van een sensor, over fysische eigenschappen uit de omgeving zoals bijvoorbeeld temperatuur, geluidsniveau, vervuiling,... De nodes communiceren draadloos met elkaar aan de hand van bovenvermelde technologieën. Het aantal nodes in een netwerk is heel variabel. Dit kan variëren tussen een paar, honderden of duizenden nodes in een netwerk. Door de omvang van deze LLN’s worden deze devices heel goedkoop geproduceerd. Naast een sensor hebben deze nodes ook een radio– ontvanger, een microcontroller en een energiebron (vaak een batterij). Nadat de sensoren hun data hebben verzameld, wordt deze vervolgens doorgestuurd naar een sinknode. Dit is vaak een gateway die zich bevindt tussen het sensornetwerk en de externe wereld. Deze gateways zijn meestal toestellen met veel rekenkracht die aangesloten zijn op het elektriciteitsnet. Bovendien zijn ze vaak verbonden met elkaar en/of met de externe wereld via een betrouwbare link, bijvoorbeeld een IEEE802.11– of een IEEE802.3–verbinding. Een ander type netwerk is het Wireless Sensor and Actuator Network of WSAN (zie Figuur 2.1)1 . Naast de sensoren bevat dit netwerk ook actuatoren die op basis van de metingen van de 1

Bron: cursus Mobiele en Breedbandtoegangsnetwerken, UGent, prof. Moerman

2.1 Achtergrondinformatie

5

Figuur 2.1: Wireless Sensor and Actuator Network (WSAN).

sensoren een bepaalde actie ondernemen. Deze toestellen zijn vaak minder beperkt. Zo beschikken ze meestal over meer rekenkracht en betere communicatiemogelijkheden dan de sensoren. Bovendien kan men opteren om deze actuatoren op het elektriciteitsnet aan te sluiten. De actuatoren krijgen informatie toegestuurd van de verschillende sensoren in hun omgeving. Deze informatie wordt op het toestel verwerkt en op basis van deze data worden acties gegenereerd en uitgevoerd. Hierdoor kunnen WSAN’s heel snel reageren op veranderingen in de omgeving. Zo is het bijvoorbeeld mogelijk om aan de hand van informatie verkregen van een bewegingsdetector de lichten aan te schakelen. Typisch zijn deze actuatoren duurder wegens hun hogere hardwarespecificaties. In een WSAN komen veel meer sensoren voor dan actuatoren. De radio–ontvangers op deze constrained devices maken meestal gebruik van de IEEE802.15.4standaard. Deze standaard werd speciaal ontwikkeld voor WPAN’s (low power and low speed wireless personal area networks): netwerken met lage zendvermogens en lage transmissiesnelheden voor apparaten in een kleine omgeving. De standaard beschrijft de specificaties van de fysische laag en de MAC-laag om het energieverbruik te beperken. IEEE802.15.4 is een zeer populaire standaard voor LLN’s, mede dankzij de integratie ervan in industriële standaarden, zoals de ZigBeeprotocolstack. Origineel werden draadloze sensornetwerken gezien als een aparte infrastructuur verantwoordelijk voor het verzamelen van data. Daarna werd deze data doorgestuurd naar de gateway die verbonden is met het Internet. Deze rol voor constrained devices werd echter compleet hergedefinieerd. Zo’n toestel wordt nu gezien als een actieve entiteit op het Internet, dat van overal


6

en vanop elk toestel bereikbaar moet zijn via het IP-protocol. In dit geval spreekt men over een IP–WSN. Er zijn veel voordelen verbonden met deze nieuwe aanpak: 1. Het IP-protocol is welgekend, goed verspreid en door iedereen aanvaard. Bovendien heeft het reeds zijn diensten bewezen. Momenteel spreekt elk toestel aangesloten op het Internet het IP-protocol, dus elk toestel zal kunnen communiceren met de constrained devices en vice versa. 2. De onafhankelijkheid van het protocol ten opzichte van de gebruikte fysische laag en MAC-laag is een groot voordeel. Zo kan voor sensornodes IP worden toegepast bovenop IEEE802.15.4. 3. Alle bestaande protocollen en applicaties bovenop IP zullen beschikbaar worden voor LLN’s. Voor deze bestaande applicaties en protocollen zullen de energievereisten en het IEEE802.15.4–berichtformaat meer dan waarschijnlijk problemen geven. 4. Er bestaan reeds verschillende applicaties voor het beheer (diagnostiek, management,...) van IP-netwerken. Deze argumenten verantwoorden het gebruik van het IP–protocol voor LLN’s. In [2] wordt verklaard waarom IPv6 een betere keuze is dan IPv4 voor dit type netwerken. Er blijven echter nog een aantal problemen bij de adoptatie van IPv6 in LLN’s die te maken hebben met het verschil in algemene structuur tussen IPv6 en IEEE802.15.4. De maximale pakketgrootte in deze standaard is namelijk heel klein, terwijl IPv6 over een grote header beschikt. Dit reduceert het beschikbaar aantal bytes per pakket voor nuttige data aanzienlijk. Om deze reden is de 6LoWPAN-werkgroep van het IETF aan het werk gegaan om een adaptatielaag te definiëren die het mogelijk maakt om gecomprimeerde IPv6–pakketten te versturen over 802.15.4–links.

2.1.2

Constrained devices

Zoals reeds vermeld in sectie 2.1.1 omtrent LLN’s kunnen deze bestaan uit duizenden nodes. Wegens het grote aantal toestellen dat wordt geplaatst in een WSN of WSAN, moeten deze goedkoop worden geproduceerd. Hierdoor beschikken ze over zeer zwakke hardwarespecificaties. Dit drukt de prijs, maar is bovendien noodzakelijk omdat de enige energiebron een batterij is. Constrained devices beschikken typisch over wat ROM– en RAM–geheugen, een centrale verwerkingseenheid en een batterij. Toestellen die metingen moeten uitvoeren zijn bovendien


7

uitgerust met één of meerdere sensoren om bepaalde fysische waarnemingen te verrichten. Wegens de beperkte specificaties is ook het besturingssysteem op maat gemaakt. De bekendste zijn ContikiOS en TinyOS. Voor deze masterproef is gewerkt met ContikiOS. Contiki [3] is een open source, uiterst draagbaar, multitasking besturingssysteem met als hoofddoelstelling energiezuinige en geheugenefficiënte constrained devices. Contiki werd voorgesteld in 2004 en is sedertdien heel populair. Contiki ondersteunt met zijn µIP de volledige IPv6–stack. De µIP– stack voorziet standaard niet in authenticatie of confidentialiteit van de communicatie tussen de verschillende constrained devices. Contiki is geschreven in C en vereist minimum 2 kilobytes RAM-geheugen en 40 kilobytes ROM-geheugen voor het basissysteem. Het besturingssysteem ´ en van is overdraagbaar naar verschillende platformen zoals de MSP430, AVR, HC 12 en Z80. E´ de sterkste punten van Contiki is de mogelijkheid om tijdens uitvoering individuele applicaties of diensten dynamisch te laden of te vervangen. Dit is handig in toepassingen waarbij men na uitrol van de constrained devices van plan is om het gedrag nog aan te passen. Contiki bevat een event-gebaseerde kernel, waarboven de applicaties draaien. Bij het optreden van een gebeurtenis of event wordt een proces (event handler) uitgevoerd. Contiki blokkeert threads, tot op het moment dat er een gebeurtenis optreedt. Op dit moment kan de thread een stuk code uitvoeren tot aan een instructie die de thread opnieuw doet wachten. Contiki combineert events met multithreading. Multithreading wordt echter enkel toegepast wanneer de applicatie dit vereist. Contiki introduceert met zijn protothreads een nieuwe event–gebaseerde manier van programmeren, dat geen statenmachine (of automaat) meer vereist om events af te handelen. Deze protothreads zijn speciale structuren die opgeroepen worden bij een bepaalde gebeurtenis zoals het ontvangen van een bericht op de radio. Dit concept laat toe dat alle processen een gemeenschappelijke stack gebruiken, wat ervoor zorgt dat applicaties heel weinig geheugen vereisen. Er is ondersteuning voor zowel IPv6 als IPv4, voor zowel UDP als TCP, voor 6LoWPAN (RFC 4944), RPL [4] en CoAP (zie sectie 2.1.3). Deze stack is weergegeven in Figuur 2.2.

Figuur 2.2: Constrained devices: een mogelijke netwerkprotocolstack.


8

Contiki-nodes vormen vaak grote LLN’s. Door het grote aantal communicerende partijen en de beperktheid van de nodes is het bouwen van software voor dergelijke netwerken niet eenvoudig. De Cooja netwerksimulator [38] maakt dit veel eenvoudiger door een testomgeving aan te bieden die het mogelijk maakt voor ontwikkelaars om hun applicaties eerst te testen in grote virtuele netwerken op geëmuleerde hardware. Uiteraard blijft dit een eerste test. Verdere testen op echte hardware en in een reële omgeving zijn noodzakelijk: een simulator kan maar tot op een bepaald niveau de werkelijke omstandigheden simuleren.

2.1.3

Het CoAP–protocol

Het CoAP–protocol [5] is een protocol op de applicatielaag dat wordt gebruikt door constrained devices om te communiceren. Bovendien is het ontwikkeld om snel te kunnen vertalen in het HTTP–protocol. Dit verzekert eenvoudige integratie met het web. CoAP ondersteunt multicast, kent een lage overhead en is zeer eenvoudig. Dit zijn eigenschappen die zeer belangrijk zijn voor het Internet of Things: voor constrained devices met lage geheugencapaciteiten en een batterij als energiebron is efficiëntie namelijk van groot belang. CoAP komt vaak bovenop het UDP–transportlaagprotocol (Figuur 2.2), maar kan ook worden toegepast bovenop andere transportprotocollen zoals bijvoorbeeld het TCP–protocol. Het CoAP–protocol is ontwikkeld door de IETF Constrained RESTful Environments (CoRE) working group. Deze werkgroep wil een framework definiëren voor eenvoudige resource–gebaseerde applicaties in een LLN. Enkele voorbeelden zijn het opvolgen van data uit sensoren: temperatuurssensoren, bewegingssensoren,... Maar ook het manipuleren van lichtschakelaars, deursloten,... Het doel is om CoAP te kunnen gebruiken tussen toestellen in hetzelfde LLN, maar ook tussen Internet nodes en constrained nodes, en tussen constrained devices uit verschillende LLN’s. Zeer belangrijk in WS(A)N’s is het localiseren van de beschikbare resources. CoAP biedt ondersteuning hiervoor aan de hand van een resource per device: de /.well-known/core resource. Een GET–request naar deze resource geeft een lijst terug van alle resources die op dit constrained device beschikbaar zijn. Gecombineerd met multicast biedt dit een manier om alle resources in het netwerk te ontdekken. De header van een CoAP–bericht (Figuur 2.3)2 is zeer klein in vergelijking met het HTTP– protocol: slechts vier bytes groot (minimaal). Net zoals bij HTTP worden in het code–veld de 2

Bron: CoAP Internet Draft

2.2 (Datagram) Transport Layer Security

9

Figuur 2.3: Het CoAP–berichtenformaat.

request en response codes aangegeven. CoAP biedt ondersteuning voor GET, PUT, POST en DELETE als request codes. De response code bestaat uit een major en minor nummer. Het major nummer geeft de status van het antwoord aan: succes, client error of server error. Het minor nummer zorgt voor een meer gedetailleerde foutcode. De CoAP–header bevat bovendien een token (tussen 0 en 8 bytes groot) dat uniek wordt bepaald door de client. Dit token zorgt voor de mapping tussen vraag en antwoord. De server stuurt dit token terug in zijn antwoordbericht. Daarna is het mogelijk om het CoAP–bericht uit te breiden met opties. Deze opties zijn van het type Type-Length-Value. Een optie start met het Option Number gedefinieerd in de CoAP– standaard. Daarna volgt de lengte van de optie en de waarde. Opties worden in volgorde toegevoegd aan het CoAP–bericht volgens stijgend optienummer. Bovendien wordt niet het optienummer zelf meegegeven, maar wel het verschil tussen het huidig optienummer en het optienummer van de vorige optie (delta encodering). Na de opties kan eventueel de payload marker (1 byte: 0xFF) en de payload worden toegevoegd. Zoniet is het bericht ten einde na de opties.

2.2 2.2.1

(Datagram) Transport Layer Security Transport Layer Security

Transport Layer Security (TLS) [6] is een zeer populair protocol voor de beveiliging van e-mail, Voice over IP, surfen op het Internet en vele andere applicaties. Het is namelijk mogelijk om confidentialiteit, authenticatie of beide te voorzien aan de hand van TLS. Het protocol is gebaseerd op zijn voorganger Secure Socket Layer (SSL), ontworpen door Netscape Communications. TLS bestaat uit enkele lagen met verschillende protocols (Figuur 2.4). Zo is er het Record protocol om data te fragmenteren in blokken of records waarop eventueel compressie plaatsvindt.


10

Figuur 2.4: TLS-protocol: gelaagde structuur bovenop TCP.

Figuur 2.5: TLS-protocol: een eenvoudige handshake waar de server zich authenticeert aan de hand van een certificaat. Dit scenario komt typisch voor bij beveiligde communicatie met een web server. De pijlen stellen vluchten voor, die soms meerdere berichten groeperen.

Vervolgens wordt een Message Authentication Code (MAC) toegepast en pas daarna wordt de payload geëncrypteerd. Deze records worden verstuurd aan de hand van het TCP-protocol. Het Record protocol verwerkt data afkomstig van vier andere protocols. Deze protocollagen zijn ook weergegeven in Figuur 2.4. De inhoud van een ClientHello–bericht bevat eerst het Record protocol, met daarboven het Handshake protocol. De vier mogelijke protocollen bovenop het Record protocol: Handshake protocol: dit protocol specifieert hoe wordt onderhandeld omtrent de keuze van

encryptie- en compressiealgoritmen die zullen worden gebruikt gedurende de beveiligde communicatie. Bovendien dient het protocol ook voor authenticatie, eventueel m.b.v. uitgewisselde certificaten, en voor het uitwisselen van data waaruit de geheime sessiesleutels worden afgeleid. Dit protocol omvat verschillende berichten (Figuur 2.5):


11

– ClientHello: De client start de TLS–handshake door het versturen van een ClientHello– bericht naar de server. Dit bericht bevat de cipher suites ondersteund door de client, hash– en compressiealgoritmen en een willekeurig getal of het ClientRandom (zie Figuur 2.6). – ServerHello: De server antwoordt op dit ClientHello–bericht met de ServerHello. Hierbij laat de server weten welke cipher suite en algoritmen hij heeft gekozen uit de voorgestelde mogelijkheden in het ClientHello–bericht. Ook dit bericht omvat een willekeurig getal of ServerRandom. Deze getallen zullen worden gebruikt, samen met andere data, om het master secret te berekenen. – ServerCertificate: Indien de cipher suite dit voorschrijft, moet de server zichzelf authenticeren aan de hand van een certificaat. – CertificateRequest: Wanneer de server zijn certificaat stuurt naar de client kan hij de client om een certificaat vragen, zodat ook deze partij geauthenticeerd is. – ServerKeyExchange: Voor sommige cipher suites is nog extra data vereist voor het berekenen van het master secret. Deze additionele data wordt meegestuurd in dit bericht. Bijvoorbeeld: voor een cipher suite met vooraf uitgewisselde sleutels mag de server via dit bericht een hint geven omtrent welke sleutel hij wil gebruiken. – ServerHelloDone: Aangezien voorgaande berichten optioneel zijn, dient dit bericht voor het afsluiten van de communicatie van de server. Nu weet de client dat er geen berichten meer volgen zodat hij kan antwoorden. – ClientCertificate: Indien de server authenticatie van de client heeft gevraagd, dan stuurt de client onmiddellijk zijn certificaat om zich te authenticeren. Het certificaat bevat de publieke sleutel van de client. Dit bericht is niet weergegeven in Figuur 2.5, omdat deze figuur een TLS–handshake voorstelt waarbij enkel de server zich authenticeert. – ClientKeyExchange: De client zendt een ClientKeyExchange–bericht na berekening van het premaster secret, waarvoor het ClientRandom en ServerRandom worden gebruikt. Dit premaster secret wordt geëncrypteerd met de publieke sleutel van de server vooraleer het wordt verstuurd. Beide partijen berekenen nu elk afzonderlijk het master secret en kunnen hieruit de sessiesleutel bepalen. Indien de server het premaster secret kan decrypteren, is de client zeker dat het communiceert met de correcte server. Deze stap is dus cruciaal in het aantonen van de authenticiteit van de server.


12

Dit bericht bevat ook de TLS–protocolversie. De server zal deze versie nagaan met de versie die in het eerste ClientHello–bericht voorkwam. Deze maatregel zorgt ervoor dat rollbackaanvallen worden vermeden. Rollbackaanvallen manipuleren dit bericht om de client en server een oudere, minder veilige versie van het TLS–protocol te gebruiken. – CertificateVerify: Dit bericht wordt enkel verstuurd na een ClientCertificate–bericht. De client wordt geauthenticeerd door met zijn private sleutel een hash van alle berichten tot op heden te tekenen. De ontvanger verifieert de handtekening met de publieke sleutel van het certificaat van de client. – ChangeCipherSpec: Dit bericht geeft aan dat vanaf nu alle berichten worden versleuteld met de zonet onderhandelde sleutels en algoritmen. – Finished: Dit bericht bevat een hashwaarde berekend over alle berichten uitgewisseld tijdens de handshake. De server finaliseert de handshake door ook zijn ChangeCipherSpec– en Finished–bericht te versturen. Vanaf nu kan beveiligde nuttige data worden uitgewisseld. ChangeCipherSpec protocol: Dit protocol is zeer eenvoudig: het omvat slechts één be-

richt, het ChangeCipherSpec–bericht, dat wordt verstuurd na het uitwisselen van de cryptografische data. Dit bericht geeft aan dat vanaf nu de uitgewisselde berichten geauthenticeerd en geëncrypteerd zijn. Alert protocol: Een alert verwittigt de andere partij dat er wordt afgeweken van de normale

handshakeprocedure. Afhankelijk van de ernst van de afwijking kan een alert–bericht een waarschuwing of een fout zijn. In de meeste gevallen moet de opgezette sessie worden afgesloten of moeten er nieuwe sleutels worden uitgewisseld. Application Data protocol: Dit protocol is verantwoordelijk voor het transport van

geëncrypteerde data nadat de handshakefase voorbij is.

2.2.2

Datagram Transport Layer Security

Naast het TCP–protocol zijn er echter heel wat applicaties die het gebruik van het UDP-protocol vereisen op de transportlaag. Dit zijn meestal applicaties waar vertragingen veel belangrijker zijn dan de betrouwbaarheid van het TCP–protocol. Voorbeelden hiervan zijn audio– en videoconferenties in ware tijd, online spellen, IP-telefonie,... Deze toepassingen vereisen echter


13

Figuur 2.6: DTLS–pakketformaat van een ClientHello–bericht.

ook beveiliging, wat heeft geleid tot een aangepaste versie van TLS: Datagram TLS [7], ofwel TLS over UDP. Aangezien men DTLS heeft gebaseerd op TLS, zijn deze sterk verwant met elkaar. De aanpassingen hebben te maken met het gebrek aan een retransmissiemechanisme en de mogelijk out-of-order aankomst van berichten. Hiervoor zijn er in de DTLS Record Header twee nieuwe velden gedefineerd: epoch en sequence number. Het epoch is een nummer dat wordt gebruikt door beide eindpunten om aan te geven welke cipher state de payload beschermt. De cipher state is de huidige toestand van het encryptie–algoritme. Deze toestand bestaat uit de gebruikte sleutel voor deze sessie. Bovendien bevat deze cipher state toestandsinformatie voor het encryptie–algoritme om te encrypteren of decrypteren, zoals bijvoorbeeld een initialisatievector, het voorgaande blok dat werd geëncrypteerd (voor blokcijferencryptie–algoritmen: data wordt blok per blok afzonderlijk geëncrypteerd),... Bij elke verandering van de cipher state (m.a.w. bij het ontvangen van een ChangeCipherSpec–bericht) wordt dit nummmer ge¨ıncrementeerd. Het epoch nummer laat toe om berichten met hetzelfde sequence number, maar een andere cipher state, van elkaar te onderscheiden. Dit is van toepassing wanneer verschillende DTLS– handshakes op korte termijn worden uitgevoerd. Het sequence number, een volgnummer, wordt


14

bijgehouden om detectie van verloren pakketten mogelijk te maken. Bovendien laat dit toe om pakketten in volgorde te rangschikken.

Figuur 2.7: DTLS-protocol: een eenvoudige handshake op basis van vooraf uitgewisselde sleutels.

Om het risico op denial of service aanvallen te beperken, wordt een staatloos cookie uitgestuurd door de server. Het is de bedoeling dat de client dit cookie terugstuurt, waarop de server de DTLS–handshake verderzet. Dit mechanisme vereist twee extra pakketten: HelloVerifyRequest en een tweede ClientHello met het cookie uit de HelloVerifyRequest (zie Figuur 2.7). Dit pakket is een antwoord op het eerste ClientHello-bericht. Pas daarna wordt de ServerHello verstuurd. Deze methode moet verplicht worden ondersteund door clients, maar servers moeten geen HelloVerifyRequest versturen. Bij DTLS worden deze eerste berichten (ClientHello en HelloVerifyRequest) niet meegenomen in de hashberekening die wordt verstuurd in het Finished–bericht. Het is tijdens de handshakefase zeer belangrijk dat pakketten in volgorde aankomen. Zoniet is het mogelijk dat de client of server in een deadlock (impasse) terechtkomt: wachtend op een bepaald pakket. Om dit te verhinderen is een retransmissiemechanisme noodzakelijk waarbij beide partijen het vorige bericht opnieuw verzenden tot het verwachtte bericht van de tegenpartij aankomt. Om efficiëntieredenen wordt niet voor elk bericht een retransmissietimer bijgehouden, maar worden berichten gegroepeerd in vluchten. Zo’n vlucht bundelt alle berich-


15

ten tot net voor de zendzijde wijzigt. Na de handshakefase is het feit dat pakketten verloren gaan geen probleem meer voor DTLS, maar wel voor de applicatie in de hogere laag van de protocolstack. De afhandeling van verloren pakketten is voor deze applicatie. Er is namelijk geen retransmissie voor beveiligde application data voorzien in het DTLS–protocol (enkel voor DTLS–handshakeberichten). De laatste aanpassing aan het TLS-protocol betreft het pakketformaat van de handshakeberichten. Wegens het feit dat DTLS-pakketten mogelijk worden gesplitst over verschillende records, kunnen de records van een bericht ook in verschillende volgorde aankomen of verloren gaan. Om dit te vermijden is opnieuw een sequentienummer, maar ook een offset en lengte van het fragment opgenomen in de handshakeheader. Het gebruik van deze nummers laat ook toe om aanvallers tegen te gaan die een replayaanval uitvoeren door een bericht af te luisteren en later opnieuw te sturen. DTLS heeft namelijk een replay–check–mechanisme waarbij een venster van toegelaten record–sequentienummers wordt bijgehouden. Bij het Alert–protocol van DTLS wordt vaak een waarschuwing gestuurd (geen fout), omdat bij connectieloze protocollen een aanvaller anders zomaar de connectie kan afsluiten door een willekeurig bericht te sturen naar één van de eindpunten. Wanneer geen application data meer hoeft verstuurd te worden kan de client of de server via een CloseNotify–alert de connectie sluiten. Er zijn echter twee manieren om met deze CloseNotify–alerts om te gaan. Ten eerste is het mogelijk dat dit bericht slechts door één partij wordt verstuurd. Het gebruik van deze methode laat de client toe om de DTLS–sessie opnieuw op te starten zonder de volledige DTLS– handshake te herbeginnen. Indien beide partijen elkaar een CloseNotify sturen, zal de sessie– informatie worden vrijgegeven en kan het constrained device eventueel met een andere partij een DTLS–sessie starten. Dit scenario wordt uiteraard enkel toegepast wanneer de client er van uitgaat dat er binnenkort geen data meer zal worden verstuurd.

2.2.3

Cipher suites

In LLN’s worden voor DTLS typisch slechts twee cipher suites ondersteund. Deze twee cipher suites verschillen in de manier waarop de gebruikte geheime sleutels worden bepaald. Er zijn twee mogelijkheden: aan de hand van publieke sleutelcryptografie, of aan de hand van vooraf uitgewisselde sleutels. Er is discussie in verband met het gebruik van publieke sleutelcryptografie op constrained devices. Het gebruik van publieke sleutelalgoritmen vereist namelijk zware berekeningen. Recente bevindingen tonen echter aan dat elliptische–curve–cryptografie (ECC)


16

wel kan worden gebruikt op constrained devices voor de publieke sleuteluitwisseling. Het gebruik van elliptische curve Diffie–Hellman (ECDH) en het elliptische curve Digital Signature Algorithm (ECDSA) zorgt voor een veel snellere uitvoering dan het RSA–algoritme. Bovendien is minder geheugen vereist om de sleutels op te slaan, want deze zijn veel korter bij ECC (typisch 128 bytes ten opzichte van 1024 bytes bij RSA met dezelfde cryptografische sterkte). Concreet worden volgende cipher suites gebruikt in LLN’s: TLS PSK WITH AES 128 CCM 8 TLS ECDHE ECDSA WITH AES 128 CCM 8

Sleuteluitwisseling

De eerste cipher suite maakt gebruik van vooraf uitgewisselde sleutels.

Deze aanpak is handig in constrained omgevingen, want op deze manier kan men de zware berekeningen van publieke sleutelcryptografie omzeilen. Uiteraard is deze aanpak echter niet schaalbaar: de omvang van LLN’s is vaak heel groot. Het vooraf instellen van de geheime sleutel op elk constrained device vraagt dan ook heel wat werk. De werking van de cipher suite is als volgt: indien de DTLS–client een PSK–cipher suite wil gebruiken, zal dit worden aangegeven in het ClientHello–bericht bij de voorgestelde cipher suites. Als de DTLS–server deze cipher suite verkiest, dan wordt dit aangegeven in het ServerHello–bericht. Omdat DTLS– communicatie kan worden opgezet met verschillende partijen, is het logisch dat verschillende sleutels worden bijgehouden. Daarom mag de server een hint geven welke sleutel hij verkiest. Dit gebeurt in het ServerKeyExchange–bericht. Het is echter de client die de sleutel zal bepalen via het ClientKeyExchange–bericht. Het pre–master secret wordt gevormd door de lengte van de vooraf uitgewisselde sleutel (N) te concateneren met N bytes nullen, opnieuw de waarde N en de sleutel zelf. De tweede cipher suite maakt gebruik van publieke sleuteluitwisseling aan de hand van ECDH en ECDSA. De server stuurt zijn efemere ECDH–publieke sleutel en specifieert de gebruikte elliptische curve in het ServerKeyExchange–bericht. Deze parameters worden ondertekend aan de hand van het ECDSA–algoritme met de private sleutel van de server, die overeenkomt met de publieke sleutel uit het certificaat. De client genereert vervolgens zijn eigen publieke en private sleutel op dezelfde elliptische curve en stuurt zijn publieke sleutel door in het ClientKeyExchange–bericht. Nu voeren client en server afzonderlijk een ECDH–operatie uit en bekomen het premaster secret.


17

Het uitwisselen en bijhouden van certificaten in constrained omgevingen is, wegens de grootte, niet de beste keuze. Een Internet Draft [8] specifieert een nieuw certificaattype en twee TLS– extensies voor het uitwisselen van ruwe publieke sleutels voor authenticatie. Door enkel de nuttige informatie over te houden uit de certificaten kan men de grootte ervan beperken. Bovendien is het parsen van het certificaat hierdoor eenvoudiger. Dit mechanisme verzekert enkel authenticatie wanneer op een of andere manier de publieke sleutel kan worden verbonden aan de entiteit met de private sleutel. Deze methode zorgt voor twee extensies in het ClientHello–bericht: het type van het client– en servercertificaat. Het master secret wordt gevormd door de pseudorandomfunctie (HMAC op een geheime waarde en een willekeurige waarde) toe te passen op het premaster secret geconcateneerd met de tekst “master secret”, het ClientRandom en het ServerRandom. De eerste 48 bytes van het resultaat stellen het master secret voor. Het master secret wordt daarna aan een expansie onderworpen door de pseudorandomfunctie. Hierdoor wordt het sleutelblok gevormd. Dit sleutelblok wordt opgesplitst in vier sleutels (client write MAC key, server write MAC key, client write encryption key, server write encryption key) en twee initialisatiewaarden (client write IV, server write IV).

Figuur 2.8: Advanced Encryption Standard (AES) in CCM–mode.

Confidentialiteit en Authenticatie Beide cipher suites maken gebruik van het Advanced Encryption Standard (AES)–algoritme in CCM–mode (Counter with CBC–MAC). CCM–mode is een algemene mode die voor verschillende blokcijferalgoritmen kan worden gebruikt (zie Figuur 2.83 ). Blokcijferalgoritmen vereisen als input blokken plain text van een welbepaalde 3

Bron: cacm.acm.org

2.3 Gerelateerd werk: beveiligde communicatie

18

lengte. Er bestaan ook stroomcijferalgoritmen die bit per bit de plain text behandelen. AES is een symmetrisch blokcijferalgoritme (zelfde operaties voor encryptie en decryptie), gebaseerd op het Rijndael–algoritme, dat in CCM–mode zowel berichtauthenticatie als confidentialiteit voorziet. De CCM–mode combineert de reeds bestaande counter–mode en CBC–MAC–mode. Voor encryptie wordt AES in CTR–mode toegepast, maar eerst wordt een authenticatieveld berekend aan de hand van AES in CBC–MAC-mode. De CBC–MAC–mode creëert een ketting van blokken zodat elk blok afhankelijk is van het vorige. Deze afhankelijkheid zorgt er voor dat een verandering aan een plain text bit het finale geëncrypteerde blok (de authenticatietag) op een onvoorspelbare manier wijzigt. Aan de payload wordt deze 64–bit authenticatietag geconcateneerd. Daarna gebeurt encryptie met AES in CTR–mode. Als initialisatievector wordt een oplopende teller gebruikt. Deze wordt geëncrypteerd met de geheime sleutel door het AES– algoritme en daarna aan een XOR–operatie onderworpen met de plain text. Hier komt geen afhankelijkheidsketting voor. Indien AES wordt toegepast in CCM–mode is het dus niet meer noodzakelijk om een MAC–algoritme in te schakelen om de integriteit van het bericht te verzekeren. AES in CCM–mode genereert namelijk een Message Integrity Check (MIC), die wordt geconcateneerd aan de payload en daarna versleuteld.

2.3

Gerelateerd werk: beveiligde communicatie

Reeds heel wat onderzoek is verricht naar technieken om de communicatie in LLN’s te beveiligen. Bovendien moet ook end–to–end beveiligde communicatie mogelijk zijn met het Internet. Voor constrained devices met de laagste geheugencapaciteiten is publieke sleutelcryptografie met het RSA–sleuteluitwisselingsalgoritme onmogelijk gebleken, wegens de grote sleutellengte (1024 bytes). Een oplossing is publieke sleuteluitwisseling met elliptische-curve-cryptografie (ECC), wat veel kortere sleutels oplevert (160 bytes). Deze manier van werken is voor veel nodes haalbaar, maar niet voor de aller zwaksten. De beveiligingsmechanismen voor de meest beperkte nodes gaan uit van een reeds gedeelde geheime code of sleutel tussen beide partijen. In deze sectie worden deze beveiligingsmechanismen besproken.

2.3.1

Linklaag

TinySec [9] is de eerste volledig ge¨ımplementeerde beveiliging op niveau van de linklaag. De implementatie was bedoeld voor TinyOS en is dus volledig in NesC geschreven. Velen pleiten voor beveiliging op de linklaag wegens het communicatiepatroon in vele draadloze sensornetwerken:


19

sensoren verzamelen data en sturen deze daarna door naar een sink. Wegens het grote aantal berichten dat wordt verstuurd en de beperkte levensduur van de sensornodes, worden berichten geaggregeerd. Dit vereist echter dat nodes toegang moeten krijgen tot de berichten en deze zelfs moeten aanpassen. Beveiligingsmechanismen op hogere lagen in de netwerkstack laten dit niet toe. Een nadeel van beveiliging op de linklaag is het feit dat end–to–end beveiliging met het Internet niet haalbaar is. TinySec laat zowel alleen authenticatie toe, als authenticatie met encryptie. Encryptie gebeurt aan de hand van de Skipjack–blokencoder terwijl voor authenticatie CBC–MAC–mode wordt gebruikt. Enkel de payload van het bericht wordt geëncrypteerd. De authenticatie gebeurt over het ganse pakket. TinySec vereist 256 bytes RAM- en 8152 bytes ROM-geheugen. Alle cryptografische bewerkingen gebeuren in software. In 2009 werd ContikiSec [10] voorgesteld: een beveiligingsmechanisme op de linklaag voor het populaire ContikiOS. In tegenstelling tot TinySec laat ContikiSec ook encryptie zonder authenticatie toe. Indien enkel encryptie wordt toegepast, koos men voor AES in CBC-CS– modus, terwijl voor encryptie en authenticatie gekozen werd voor AES in OCB–modus. Het CMAC–algoritme wordt gebruikt om een vier bytes lange MAC te genereren. Het grootste nadeel van ContikiSec is het gebruik van een gemeenschappelijke sleutel tussen alle constrained devices. De beveiliging in het volledige LLN is dus verloren indien een node is gecompromitteerd. Veel andere implementaties voor beveiliging op de linklaag zijn beschikbaar, maar algemeen hebben ze allen dezelfde problemen: Met beveiliging op de linklaag is geen end–to–end beveiligde communicatie te realiseren.

Op elke hop in het netwerk wordt het pakket gedecrypteerd en geëncrypteerd om door te sturen naar de volgende hop. Een gecompromitteerde node kan dus alle data die voorbijkomt lezen. Schaalbaarheid is een groot probleem omdat een node met elk van zijn buren een geheime

sleutel moet uitwisselen indien een beveiligd kanaal wordt opgezet. Bovendien zorgen de encryptie– en decryptie–operaties op elke hop voor een grote extra kost.

2.3.2

Netwerklaag

De laatse jaren is het integreren van de beveiliging op de netwerklaag zeer populair. Zo werden vele papers gepresenteerd die beschrijven hoe beveiliging kan worden toegepast in de 6LoWPANadaptatielaag. Een bekend protocol dat wordt gebruikt op het Internet is IPsec of Internet Protocol Security [15]. IPsec maakt gebruik van twee protocollen om zijn beveiligingsfuncties


20

te realiseren: de authenticatieheader (AH) [12] en het Encapsulating Security Protocol (ESP) [13]. Het AH–protocol voorziet in integriteit en authenticatie van de oorsprong van de data met een aantal optionele anti–replayfuncties. ESP laat confidentialiteit toe. Omdat de meeste beveiligingsvereisten voldaan worden door het gebruik van ESP, is dit protocol verplicht bij IPsec. De authenticatieheader is optioneel. Beide protocollen kunnen zowel in tunnelmode als in transportmode worden toegepast. In tunnelmode wordt een volledig IP-pakket geëncrypteerd en/of geauthenticeerd en vervolgens geëncapsuleerd in een nieuw pakket met een nieuwe IPheader. In transportmode wordt de IPsec-header toegevoegd na de IP-header waardoor enkel de hogere lagen worden beveiligd. IPsec maakt gebruik van Security Associations (SA) die in beide richtingen moeten worden opgezet. Een SA tussen twee eindpunten beschrijft de beveiligingsdiensten die worden toegepast op het netwerkverkeer. Het is dus een verzameling van gebruikte algoritmen, sleutels,... Het manueel opzetten van zo’n SA’s is niet schaalbaar. IPsec rekent hiervoor op het Internet Key Exchange Protocol (IKEv2) [14]. Het is duidelijk dat IPsec een heel complex protocol is. Verschillende pogingen zijn uitgevoerd om IPsec compacter te maken voor LLN’s [15]. Toch lijkt het IETF DTLS te verkiezen om beveiligde communicatie te realiseren met LLN’s. De meerderheid van het IETF verkiest DTLS (DICE, zie sectie 2.4) boven IPsec, maar IPsec wordt niet afgeschreven. Bovendien is het TLS– protocol ook populairder op het Internet dan IPsec.

2.3.3

Transportlaag

Wegens de populariteit van het TLS-protocol op het Internet is ook de transportlaag zeer populair voor het toepassen van beveiligingsmechanismen in LLN’s. Het gebruik van TLS omvat namelijk sleuteluitwisseling, authenticatie, vertrouwelijkheid en integriteit. Verschillende implementaties van TLS werden dan ook voorgesteld. De eerste implementatie is Sizzle [16] of HTTP over TLS (SSL). Sizzle gebruikt zowel MD5 en SHA-1 als hashalgoritmen en RC4 voor bulkencryptie. Voor elliptische–curve–sleuteluitwisseling wordt het Diffie Helman–algoritme (ECDH) en het Digital Signature Algorithm–algoritme (ECDSA) toegepast. Sizzle toonde als eerste aan dat deze protocollen wel degelijk gebruikt kunnen worden op constrained devices. De verschillende devices, met TinyOS als besturingssysteem, waren geconnecteerd via de gateway, terwijl de beveiligde web servers waren gemapt op de verschillende poorten van de gateway. De TCP–verbindingen werden getermineerd op de gateway om de prestaties te verbeteren. Op de draadloze link naar de constrained devices


21

werd UDP voorzien. Bovendien werden verschillende veronderstellingen gemaakt om het aantal berichten in de SSL-handshake te drukken. Achteraf is Sizzle echter zeer belangrijk gebleken voor het onderzoek rond beveiligde communicatie in LLN’s. Het toonde namelijk aan dat het gebruik van ECC voor publieke sleutelcryptografie meer geschikt is voor constrained devices dan RSA, vanwege de kortere sleutellengte. SSNAIL [17] is een lichte SSL-implementatie ontwikkeld voor een project ”Sensor Networks for All-IP worLd”(SNAIL). Dit project had als doel om een IP–WSN–platform te implementeren op een wijd verspreid testbed. SSNAIL is heel gelijkaardig aan Sizzle, maar het vermijdt het gebruik van de gateway. De implementatie bedraagt 30 kilobytes ROM–geheugen en 500 bytes RAM–geheugen. Wegens de overhead dat het TCP-protocol met zich meebrengt wordt meer en meer geopteerd voor de onbetrouwbare tegenhanger UDP in draadloze netwerken [18]. Dit heeft als gevolg dat DTLS wordt toegepast, de aangepaste versie van TLS voor onbetrouwbare transportprotocollen. Dit reflecteert zich in de voorgestelde CoAP–standaarden van het IETF. De CoAP-draft definieert namelijk een binding voor DTLS [19]. Een ander voorstel probeert de DTLS–overhead te reduceren door headercompressie toe te passen [20]. Verschillende architecturen om endto-end beveiliging te realiseren aan de hand van DTLS zijn voorgesteld. Zo wordt in [21] een architectuur gepresenteerd waarbij zowel de client als de server zich authenticeren aan de hand van X509-certificaten met RSA-sleutels. Deze authenticatie gebeurt tijdens een DTLShandshake. Er wordt gebruikgemaakt van de Opal–sensornode die een Atmel SAM3U microcontroller en de Atmel AT97SC3203S TPM bevat. De node bevat 48 kB RAM. Deze implementatie is uiteraard niet geschikt voor de meest beperkte devices.

2.3.4

Applicatielaag

Beveiliging op de applicatielaag komt slechts weinig voor. De reden is duidelijk: voor elke applicatie moet de beveiliging afzonderlijk worden voorzien. In bepaalde gevallen is het echter wel nuttig. Een voorbeeld hiervan (op het Internet) is het User-based Security Model (USM) voor het SNMPv3-protocol [22]. Dit protocol is verantwoordelijk voor authenticatie en confidentialiteit van SNMP-pakketten. Het SNMP–protocol wordt gebruikt voor de overdracht tussen managementinformatie tussen verschillende machines maar deze informatie is uiteraard niet voor iedereen beschikbaar.

2.4 State of the art

2.3.5

22

Besluit

Het is duidelijk dat reeds heel wat onderzoek is verricht naar beveiliging voor LLN’s. Voor de meest beperkte constrained devices is het, wegens de lage geheugencapaciteiten niet mogelijk om publieke sleuteluitwisseling te gebruiken. Er is aangetoond dat ECC beter presteert dan RSA vanwege de kortere sleutellengte. Enkele voorgestelde oplossingen die gebruikmaken van certificaten introduceren een vertrouwde derde partij die aangesloten is op het elektriciteitsnet en over meer processorkracht en geheugen beschikt. Deze derde partij helpt het constrained device bij het opzetten van de beveiliging. In het constrained netwerk wordt dan typisch een goedkoper of gewoon geen beveiligingsmechanisme gebruikt. De meeste end–to–end oplossingen maken gebruik van vooraf uitgewisselde sleutels. Men verwacht echter verbeterde hardware, groter geheugen en energiezuinigere processoren voor constrained devices. Dit zou het mogelijk maken om certificaatgebaseerde cryptografie toe te passen zonder een derde vertrouwde partij. Beveiliging op de linklaag is de meest eenvoudige vorm van beveiliging maar laat geen end–to– end beveiligde communicatie toe. Oplossingen op de netwerken transportlaag zijn om deze reden dan ook heel populair. Het IETF lijkt te opteren voor DTLS op de transportlaag, eerder dan voor IPsec op de netwerklaag. De reden hiervoor is de complexiteit van het IPsec-protocol en de populariteit van het TLS–protocol op het Internet. Beveiliging op de applicatielaag komt zeer weinig voor, maar kan zijn nut bewijzen in bepaalde situaties. Het grootste nadeel is dat de beveiliging voor elke applicatie apart moet worden opgezet, terwijl dit op de lagere lagen transparant kan gebeuren voor alle verkeer (afkomstig van verschillende applicaties).

2.4 2.4.1

State of the art IETF: DICE–werkgroep

DICE of DTLS In Constrained Environments is een werkgroep van het IETF die zich focust op het toepassen van DTLS–beveiliging op de transportlaag in omgevingen met constrained devices. In deze omgevingen zijn de grootste problemen gerelateerd aan de constrained devices (beperkt geheugen en zwakke processor) en aan het netwerk (kleine pakketgroottes en pakketverlies). De belangrijkste taak van DICE is het definiëren van een DTLS–profiel voor zo’n beperkte omgevingen. Een profiel wordt gedefinieerd om slechts een beperkt deel van de standaard, specifiek voor de situatie, te implementeren, maar waarbij toch interoperatibiliteit met de verschillende partijen wordt verzekerd. Een tweede taak van DICE is het ontwerpen van DTLS


23

voor multicastcommunicatie. Tenslotte moet DICE ook de problemen rond de DTLS–handshake (fragmentatie, retransmissie) aanpakken in LLN’s. DICE heeft reeds enkele Internet Drafts geschreven om DTLS meer geschikt te maken voor LLN’s: Compression of Record and Handshake Headers for Constrained Environments [23]: Dit

document beschrijft headercompressie voor DTLS gebruikmakende van Next Header Compression (NHC) uit RFC 6282. De DTLS Record Header, Handshake Header en eventueel ook de headers van handshakeberichten worden aan compressie onderworpen. CoDTLS: DTLS–handshakes over CoAP [24]: DTLS–berichten worden vaak verstuurd

over het UDP–protocol. In LLN’s kan dit ernstige limitaties met zich meebrengen. Zo kan er veel pakketverlies optreden en kan de ruimte voor nuttige data in pakketten zeer klein zijn. Vaak kunnen applicaties de grootte en retransmissievereisten van hun datapakketten aanpassen. Dit motiveert het idee om DTLS bovenop CoAP te spreken. Profiling of DTLS for CoAP-based IoT Applications [25]: Dit document bespreekt ver-

schillende implementatie–moeilijkheden van DTLS op constrained devices. Bovendien wordt een DTLS–profiel voorgesteld voor CoAP–gebaseerde IoT–applicaties. Er wordt een DTLS–handshake voorgesteld volgens de REST–principes, waarbij gebruik wordt gemaakt van de CoAP Blockwise Transfer om het probleem met fragmentatie van DTLS– handshakeberichten op te lossen. A DTLS 1.2 Profile for the Internet of Things [26]: Dit document is het antwoord van

DICE op hun belangrijkste taak: het definiëren van een DTLS–profiel voor IoT–applicaties. Onderwerpen als authenticatie aan de hand van een vooraf uitgewisselde geheime waarde, het gebruik van ruwe publieke sleutels en certificaten worden hier besproken.

2.4.2

IETF: ACE–werkgroep

De werkgroep “Authentication and Authorization for Constrained Environments”(ACE) binnen het IETF focust zijn onderzoek op het beveiligd gebruik van REST–diensten in LLN’s. Het doel is om constrained devices in staat te stellen om de andere communicerende partij te authenticeren, beveiligd met hen te communiceren en hun toegang tot bronnen te autoriseren. Om dit te realiseren zal de ACE–werkgroep een krachtige vertrouwde partij invoeren die de zware berekeningen uitvoert, autorisatiepolicies bijhoudt en een groot aantal sleutels kan


24

opslaan. Er wordt bovendien gebruikgemaakt van CoAP en DTLS. De ACE–werkgroep heeft een aantal taken: Documenteer de gebruikersscenario’s en hoog–niveau vereisten om beveiligde communica-

tie te realiseren tussen constrained devices. Definieer een profiel voor certificaten: welke types van certificaten en attributen worden

gebruikt. Definieer een mechanisme voor geauthenticeerde en beveiligde communicatie van autorisatie–

informatie tussen constrained devices. Definieer een toegangsticket en een autorisatie–informatieformaat geschikt voor constrained

devices. Definieer bootstrapping voor autorisatie–informatie, gebruikmakende van de Resource

Directory 4 .

2.4.3

Lithe

Lithe [27] is een lichte manier om beveiligde CoAP–berichten te versturen. Dit project werd uitgevoerd door dezelfde personen die de draft “Compression of Record and Handshake Headers for Constrained Environments”van DICE hebben geschreven. Ook hier wordt 6LoWPAN NHC toegepast om de DTLS–headers te comprimeren. In deze paper wordt besproken wat de kost (in tijd) is van het toepassen van de compressie, en hoeveel de winst (in bytes, en uiteraard vervolgens in Joule) bedraagt per bericht. Zo blijkt dat 15% energie wordt bespaard gedurende de DTLS–handshake door het comprimeren van de headers. Bovendien wordt het vereiste ROM– en RAM–geheugen van de implementaties bepaald. Deze experimenten en doelstellingen zijn zeer gelijkaardig aan het experiment dat in deze masterproef is uitgevoerd. Alleen zijn de middelen om de doelstelling te bereiken verschillend.

2.4.4

Delegatie van de DTLS Handshake naar een krachtige vertrouwde partij

In de recente paper [28] wordt een delegatie–architectuur voorgesteld die de DTLS Handshake uitvoert op een vertrouwde en krachtige delegatieserver. Daarna wordt de beveiligingscontext 4

Een Resource Directory wordt gebruikt om bij te houden welke bronnen op welke servers beschikbaar zijn

(draft-ietf-core-resource-directory).


25

overgeheveld naar het constrained device. Deze aanpak maakt gebruik van het session resumption mechanisme in DTLS om deze beveiligingscontext te kunnen overhevelen. Via symmetrische encryptie aan de hand van pre–shared keys tussen het constrained device en de delegatieserver, wordt deze context daarna doorgestuurd. Op deze manier kan de delegatieserver clients op het Internet authenticeren en autoriseren. Bovendien worden op het constrained device heel wat minder resources verbruikt: de geheugenvereisten dalen met 64 %, de berekeningen met 97 % en de netwerktransmissie met 68 %. Dit onderzoek is heel gelijkaardig aan wat in deze masterproef wordt voorgesteld. In tegenstelling tot deze aanpak is er bij het termineren van het DTLS– verkeer op de gateway nog heel wat mogelijk in het LLN, het gebruik van DTLS is namelijk niet verplicht.

2.4.5

Besluit

Het is duidelijk dat het realiseren van DTLS in beperkte omgevingen een populair thema is in de onderzoekswereld. Veel verschillende pogingen worden ondernomen om DTLS zo licht mogelijk te maken. Terwijl de DICE–werkgroep van het IETF meer op zoek gaat naar manieren om het DTLS–protocol minder log te maken door bijvoorbeeld compressie, wordt in deze masterproef meer gezocht naar een situatie waarin DTLS zodanig kan worden toegepast dat het constrained device zo weinig mogelijk belast wordt. Het samenbrengen van beide oplossingen zal waarschijnlijk naar het optimum leiden.

ONTWERP & IMPLEMENTATIE

26

Hoofdstuk 3

Ontwerp & Implementatie 3.1

Ontwerp

Figuur 3.1: Communicatie tussen een traditioneel toestel (links) en een constrained device (rechts).

De communicatie tussen een traditioneel toestel en een constrained device moet vaak worden beveiligd (Figuur 3.1, bron: [31]). Wegens de beperkte capaciteiten van constrained devices is het aangeraden om weinig energiebehoevende berekeningen uit te voeren om beveiliging te realiseren. Dit betekent dat de meest beperkte constrained devices niet in staat zijn om verschillende, of zelfs één DTLS–sessie op te zetten. Voor deze nodes is de aanpak van de DICE–werkgroep bij het IETF, namelijk end–to–end DTLS mogelijk maken, geen optie. De onderzoeksopdracht die hier zal worden uitgevoerd focust zich op het breken van de end–to–end DTLS–beveiliging op de gateway. Over dit onderwerp is weinig literatuur te vinden, maar de aanpak is gelijkaardig aan een reverse proxy die voor het constrained device wordt geplaatst (CoAP–jargon). In [32] wordt een gelijkaardig idee besproken over een beveiligingsprotocol–adaptatielaag om de beveiliging af

3.1 Ontwerp

27

te breken op de gateway. Dit idee werd nooit experimenteel uitgevoerd. Om de meest energie– efficiënte methode te bepalen om confidentialiteit en/of authenticatie te verzekeren aan de hand van DTLS, zijn er een aantal te realiseren gebruikersscenario’s opgesteld. Deze worden besproken in de volgende sectie. De implementatie en realisatie van deze verschillende scenario’s wordt in het volgende hoofdstuk besproken.

3.1.1

Gebruikersscenario’s

In onderstaande scenario’s treedt het constrained device steeds op als DTLS–server. Uiteraard is het theoretisch ook mogelijk om het constrained device als DTLS–client te laten functioneren. Dit werd echter niet beschouwd in dit onderzoek. De gebruikte DTLS–implementatie bevat zowel een DTLS–client als –server. Onbeveiligde CoAP

Figuur 3.2: Tussen de client en server worden onbeveiligde CoAP–berichten verstuurd.

In Figuur 3.2 worden onbeveiligde CoAP–berichten uitgewisseld tussen een client op een traditioneel toestel, aangesloten op het Internet, en een server op een constrained device (of omgekeerd). De gateway komt hier niet tussen: berichten worden gewoon doorgelaten. Dit geval is de referentiecase om na te gaan wat de extra kost is om beveiligde communicatie te realiseren. Het is interessant om te meten hoeveel extra energie, extra pakketten, vertraging,... optreedt om beveiligde communicatie te verzekeren. End–to–end DTLS Beveiligd communiceren kan met behulp van een end–to–end DTLS–sessie. Dit vereist een DTLS–handshake die moet worden uitgevoerd vooraleer er nuttige (geëncrypteerde) data kan

3.1 Ontwerp

28

Figuur 3.3: De communicatie tussen de client en server wordt van begin tot einde beveiligd aan de hand van DTLS.

worden uitgewisseld. De client spreekt rechtstreeks met het constrained device of end–to–end. De gateway komt hier niet tussen: berichten worden doorgestuurd naar het LLN (Figuur 3.3). Het is mogelijk om voor elke vraag een nieuwe DTLS–sessie te openen met het constrained device, maar dit vereist uiteraard telkens een nieuwe DTLS–handshake. Daarnaast kan de client een DTLS–sessie voor lange termijn openen met het constrained device om hier meerdere requests over te versturen. Het afsluiten van een DTLS–sessie gebeurt aan de hand van een CloseNotify–bericht. DTLS afbreken op de gateway In dit geval kan uiteraard niet meer worden gesproken van end–to–end: de client voert een DTLS–handshake uit met de gateway en verstuurt daarna (beveiligd) zijn vraagbericht, met als bestemming het constrained device, naar de gateway. De client wacht op een antwoord en vertrouwt dat de gateway correct handelt. Op het Internet kan voor de DTLS–sessie eventueel een cipher suite worden geselecteerd met ondersteuning van certificaten voor een sterkere vorm van authenticatie en eventueel een betere schaalbaarheid. Dit staat namelijk los van het mechanisme dat wordt gebruikt in LLN’s. Typisch zijn de constrained devices echter niet krachtig genoeg om ook cipher suites met certificaten toe te passen. Het is nu aan de gateway om te bepalen welk beveiligingsmechanisme hij zal toepassen in het LLN: Langdurige DTLS–sessie

Het is mogelijk dat de gateway een DTLS–sessie opent met het

desbetreffende constrained device en deze openhoudt om opeenvolgende aanvragen beveiligd te versturen. Deze DTLS-sessie wordt gebruikt voor verschillende clients uit het Internet (Figuur 3.4).

3.1 Ontwerp

29

Figuur 3.4: De gateway breekt de DTLS-sessie met de client af en maakt gebruik van een langdurige DTLS-sessie voor alle clients in het Internet die met dezelfde server in het LLN communiceren.

Figuur 3.5: De DTLS-sessie wordt afgebroken op de gateway, waarna telkenmale een nieuwe sessie wordt opgezet en afgesloten per client.

Tijdelijke DTLS–sessie

De gateway kan er ook voor kiezen om voor elke vraag, afkomstig

van het Internet, een nieuwe DTLS–sessie te openen en deze daarna terug af te sluiten (Figuur 3.5). Dit betekent dat voor elke vraag een nieuwe DTLS–handshake wordt uitgevoerd en op het einde een CloseNotify wordt uitgewisseld. Dit scenario zal heel wat duurder zijn op vlak van energieverbruik. Onbeveiligd

Indien er geen beveiligingsrisico optreedt in het LLN is het mogelijk om gewoon

plain text CoAP te versturen. Het is bijvoorbeeld ook mogelijk om te filteren op de methode van het bericht: in sommige gevallen kan een GET–aanvraag weinig kwaad dus mag deze onbeveiligd worden verstuurd, terwijl een PUT/POST–bericht wel beveiligd moet worden (Figuur 3.6).

3.1 Ontwerp

30

Figuur 3.6: De DTLS-sessie wordt afgebroken op de gateway, waarna de communicatie onbeveiligd gebeurt in het LLN.

Figuur 3.7: Het DTLS-verkeer wordt afgebroken op de gateway, waarna het wordt doorgestuurd in het LLN met beveiliging op de linklaag.

Beveiliging op de linklaag

De gateway kan via een vooraf uitgewisselde sleutel pakketten

door de radio laten versleutelen. Dit scenario is het enige dat niet werd ge¨ımplementeerd maar behoort zeker ook tot de mogelijkheden (Figuur 3.7).

3.2 Implementatie

3.2

31

Implementatie

In dit hoofdstuk worden de drie partijen besproken die deelnemen aan de verschillende scenario’s. Elke partij moet DTLS kunnen spreken. Wegens de heterogeniteit en verschillende omgeving van de toestellen is het niet mogelijk om dezelfde implementatie toe te passen op alle toestellen. Het is uitdagend gebleken om deze verschillende implementaties met elkaar te laten communiceren, nochtans werden ze allen ge¨ımplementeerd naargelang de DTLS–standaard. Dit bevestigt de nood aan een werkgroep zoals DICE.

3.2.1

Constrained device

Wegens de lage processorkracht en beperkte geheugencapaciteiten van de constrained devices wordt typisch gekozen voor algoritmen die weinig vereisten hebben op dit vlak. Dit heeft als gevolg dat voor LLN’s typisch enkele goedgekozen algoritmen worden toegepast. Voor het AES– algoritme bijvoorbeeld zijn zeer compacte implementaties beschikbaar, wat de toepasbaarheid in LLN’s uiterst geschikt maakt. Wegens het gebruik van AES is voor de implementatie van decryptie geen extra ruimte nodig, want dezelfde operaties worden uitgevoerd voor encryptie en decryptie. Bovendien beschikken veel hardwareplatformen over ondersteuning om deze AES– encryptie uit te voeren. Bij gebruik van AES–CCM is de confidentialiteit en authenticatie van de bron verzekerd. Als CoAP–client en –server is geopteerd voor de Erbium–client en –server die standaard ter beschikking zijn op Contiki. Een DTLS-implementatie voor embedded toestellen is TinyDTLS [33], ontworpen door Olaf Bergmann aan de universiteit van Bremen. Deze implementatie bevat een zeer eenvoudige DTLS-server en -client die ontworpen zijn om meerdere sessies te ondersteunen in een applicatie met slechts één thread. Dit wijst er op dat TinyDTLS vooral gericht is op embedded devices, maar het werkt ook op het x86-platform. TinyDTLS biedt de mogelijkheid om twee cipher suites te gebruiken, beide met AES–CCM. TinyDTLS was vroeger gebaseerd op de populaire bibliotheek OpenSSL, maar werd daarna volledig aangepast naar een eigen DTLS-implementatie. TinyDTLS ondersteunt DTLS versie 1.2. TinyDTLS werd aangepast om energiemetingen uit te voeren op het constrained device. Bovendien is er gesleuteld aan de code om de explicit nonce af te handelen (zie sectie 3.2.4

3.2 Implementatie

32

omtrent het interoperabiliteitsprobleem). Radio Duty Cycling Radio Duty Cycling of RDC is uiterst belangrijk voor de levensduur van de batterij van de constrained devices. De grootste energieverbruiker op een constrained device is namelijk de radio: het luisteren tot er nieuwe berichten aankomen kost heel veel energie. RDC–drivers kunnen de radio uitschakelen en periodiek het draadloze medium nakijken voor nieuwe berichten. Wanneer een nieuw bericht wordt gedetecteerd, blijft de radio aan tot het pakket is ontvangen. Het kanaal wordt zo enkele keren per seconde gecontroleerd op activiteit. Wanneer er een pakket wordt verstuurd naar een bepaalde bestemming moet de transmissie typisch enkele keren worden herhaald tot de ontvanger detecteert dat er activiteit is op het medium. Dit zorgt voor een stijging van de verzendenergie: bij gebruik van RDC-protocollen wordt de kost verschoven van de ontvanger naar de zender. Bovendien wordt er hierdoor veel meer trafiek verstuurd over het draadloze medium. Indien synchronisatie wordt toegepast kan men het herhalen beperken tot op het moment dat de ontvanger waarschijnlijk wakker zal worden. Dit vereist echter periodieke synchronisatieberichten tussen de zender en de ontvanger. Er zijn verschillende RDC–drivers beschikbaar voor Contiki. De bekendste zijn ContikiMAC, X-MAC, CX-MAC, LPP, en NullRDC. ContikiMAC is het standaardmechanisme dat goeie resultaten voorlegt, maar specifiek gebouwd is voor de 802.15.4–radio en de CC2420–radio– ontvanger. X-MAC is minder strict maar kent dan ook mindere resultaten. NullRDC betekent dat de radio nooit wordt uitgeschakeld. In deze stand verbruikt het constrained device uiteraard het meeste energie doordat het onnodig lang moet luisteren naar activiteit op het radiomedium. Het blijkt dat TinyDTLS niet compatibel is met RDC. Alle resultaten bekomen tijdens de experimenten geven dus een hoog luisterverbruik aan omdat de radio steeds ingeschakeld is. Om toch een idee te krijgen van de verbruikte ontvangstenergie is in de experimenten gepoogd om de tijd te meten dat een constrained device effectief een frame ontvangt (meer hierover in sectie 4.3). Wanneer berichten verloren gaan, kan de partij zijn laatst verstuurde vlucht opnieuw versturen. Dit retransmissiemechanisme blijkt niet correct te functioneren. Er wordt door de TinyDTLS–server niet gereageerd op retransmissies van de vlucht met het ClientKeyExchange– , ChangeCipherSpec– en Finished–bericht. In RFC 6347 worden de aanpassingen besproken

3.2 Implementatie

33

´ en aanpassing is het retransmissiemevan DTLS 1.2 ten opzichte van de eerste DTLS–versie. E´ chanisme: een server wordt verplicht om zijn ChangeCipherSpec– en Finished–bericht opnieuw door te sturen wanneer de client een retransmissie uitvoert van zijn Finished–bericht. Dit is noodzakelijk aangezien de client anders in een deadlock terechtkomt, terwijl voor de server de handshake afgelopen is en application data wordt verwacht. Met TinyDTLS kan dit nog steeds voorkomen, wat een mislukte handshake tot gevolg heeft. TinyDTLS werkt niet met vluchten waarin verschillende berichten worden gegroepeerd. Het groeperen van verschillende berichten in een pakket heeft als voordeel dat het aantal pakketten daalt. Indien het pakket toch verloren gaat, dan moeten alle berichten uit het pakket opnieuw worden verstuurd.

3.2.2

Traditioneel toestel

Het traditioneel toestel moet, net zoals de gateway, naast de moderne sterk beveiligde cipher suites ook cipher suites ondersteunen specifiek voor LLN’s. Om end–to–end te communiceren met een constrained device moet de implementatie de typische LLN–cipher suites ondersteunen. Een implementatie die hieraan voldoet is Scandium. Scandium (Sc) is een DTLS-implementatie voor het Californium (Cf) CoAP–raamwerk [36]. Deze implementatie ondersteunt de recentste versie van DTLS, namelijk DTLS 1.2. Het Cf–raamwerk is een modulaire CoAP-implementatie, geschreven in Java. Aan de hand van Cf is het mogelijk om op een gemakkelijke manier cloudgebaseerde client- en serverapplicaties te bouwen. Scandium [37] maakt gebruik van de Connector-interface uit het Californium–raamwerk. Dit is een API die zich gedraagd als socket om ruwe data te versturen en te ontvangen. Het is echter ook mogelijk om Scandium te gebruiken zonder hierboven Californium te draaien. In Californium zijn aanpassingen gebeurd aan de afhandelingscode van de explicit nonce (zie sectie 3.2.4 i.v.m. interoperabiliteitsprobleem), er is code toegevoegd om energiemetingen te starten en ontvangen via een telnet–sessie en er is een wijziging ingevoerd om te kiezen wanneer de DTLS–sessie wordt afgesloten door het versturen van een CloseNotify–alertbericht.

3.2.3

Gateway

Wegens het gebruik van specifieke cipher suites in LLN’s moet ook de gateway deze ondersteunen indien deze beveiligd wil communiceren met constrained devices aan de hand van DTLS. Een populaire en gratis bibliotheek om DTLS te implementeren is OpenSSL. OpenSSL ondersteunt

3.2 Implementatie

34

echter de cipher suites aan de hand van AES–CCM niet. De API met cryptografische algoritmen bevat wel de functionaliteit om deze cipher suites te realiseren maar de koppeling met een cipher suite bestaat niet. Dit biedt de mogelijkheid om de koppeling zelf te implementeren en dus OpenSSL uit te breiden met de nodige cipher suites. Er is eerst geopteerd om uit te kijken naar andere bibliotheken die deze wel ondersteunen. Zo’n bibliotheek is CyaSSL [34] : gericht op embedded systemen, maar werkt ook perfect op reguliere desktops. CyaSSL ondersteunt DTLS 1.2 en bevat een OpenSSL–compatibiliteitslaag. Naast de cipher suites om te communiceren met constrained devices is het noodzakelijk dat CyaSSL ook de hedendaagse cipher suites, die gebruikt worden tussen traditionele toestellen op het Internet, ondersteunt. De methode van deze masterproef is om de beveiliging te onderbreken op de gateway. De gateway zet beveiligde communicatie op met een toestel uit het Internet en kan hiervoor gebruikmaken van computationeel zwaardere cipher suites, eventueel met certificaten. Zeer constrained devices ondersteunen typisch slechts een enkele cipher suite op basis van vooraf uitgewisselde sleutels. Bij IBCN werd een gateway ontwikkeld die CoAP ondersteunt. Deze implementatie gebeurde aan de hand van Click [35]. Het Click modulaire router project werd gestart aan MIT en daarna onder andere verder gezet in de Universiteit van Antwerpen. Click laat toe om een router samen te stellen aan de hand van bouwstenen die met elkaar verbonden zijn via inputs en outputs. Deze bouwstenen zijn elementen, geschreven in C++, die worden gedefinieerd in configuratiebestanden. CyaSSL is aan de Click router toegevoegd door nieuwe bouwstenen toe te voegen aan de bestaande configuratie. Omdat CyaSSL berichten verstuurt via de Click router was het ook noodzakelijk om de CyaSSL–code aan te passen. Standaard worden berichten verstuurd via sockets en wordt gewacht op het nieuwe bericht van de tegenpartij. In deze implementatie worden echter geen sockets gebruikt. CyaSSL geeft zijn bericht af aan de Click router en deze zorgt voor het versturen van het bericht. Click vereist uiteraard de controle om het bericht te versturen en krijgt deze standaard niet van CyaSSL omdat deze aan het wachten is op een antwoordbericht. Daarom is er in de berichtenafhandelingscode van CyaSSL een nieuwe returnwaarde toegevoegd. Wanneer deze wordt opgegooid, krijgt de Click router opnieuw de controle. Op dit moment kan Click het bericht versturen. Ondermeer het overhevelen van de te versturen of ontvangen berichten tussen Click en CyaSSL gebeurt aan de hand van enkele callbackmethodes:

3.2 Implementatie

35

i n t recvFrom (CYASSL * s s l , char * buf , i n t sz , v o i d * c t x ) i n t sendTo (CYASSL * s s l , char * buf , i n t sz , v o i d * c t x ) u n s i g n e d i n t cl i e nt P SK (CYASSL* s s l , const char * h i n t , char * i d e n t i t y , u n s i g n e d i n t i d m a x l e n , u n s i g n e d char * key , u n s i g n e d i n t k e y m a x l e n ) i n t EmbedGenerateCookie (CYASSL* s s l , byte * buf , i n t sz , v o i d * c t x )

De functie ‘recvFrom’ wordt opgeroepen wanneer een bericht binnenkomt via Click, terwijl de functie ‘sendTo’ wordt geraadpleegd door CyaSSL om berichten te versturen via Click. De functie ‘clientPSK’ stelt de geheime sleutel in bij de client. ‘EmbedGenerateCookie’ wordt gebruikt op de server om een uniek cookie te genereren. Opbouw De Click router kan zich gedragen als CoAP–client en/of –server via het COAPClientServer– element. Bovendien bevat de Click router een interface naar het LLN (al dan niet gevirtualiseerd aan de hand van de Cooja netwerksimulator). Om de DTLS–functionaliteit toe te voegen aan de Click router zijn enkele nieuwe elementen vereist: 1. DTLSState: Dit is een klasse die informatie bijhoudt over het inkomende en uitgaande verkeer. De logische werking van dit element is weergegeven in Figuur 3.8. Bij een binnenkomend pakket wordt eerst en vooral gecontroleerd of het pakket beveiligd is aan de hand van DTLS of niet. Dit gebeurt aan de hand van de aanwezigheid van de DTLS– versie bij de start van de DTLS–header. Indien dit zo is wordt het doorgestuurd naar de DTLSModule (zie verder) voor verdere afhandeling. Daarna kan het pakket verder naar zijn bestemming. Indien het pakket onbeveiligd werd verstuurd kan het uiteraard onmiddellijk verder. Onbeantwoorde aanvragen worden bijgehouden. Tot op het ogenblik dat de gateway het antwoord verstuurt naar de client, worden alle nieuwe vraagberichten tegenhouden zodat de bestemming de tijd krijgt om op het bericht te antwoorden. De DTLS–client kiest namelijk zelf zijn retransmissietijd. Indien er geen rekening wordt gehouden met het feit dat de communicerende partij zich

3.2 Implementatie

36

Figuur 3.8: Werking van het DTLSState–element.

in een LLN bevindt, dan staat deze retransmissietijd veel te laag ingesteld. Het gevolg is dat de server wordt overspoeld met aanvragen en niet genoeg kan rekenen, of dat er veel pakketverlies optreedt in het LLN. In de LLN’s kan dit dus even duren vooraleer er een antwoord komt. Uiteraard is deze aanpak niet mogelijk in de realiteit, want indien het pakket echt verloren gaat is retransmissie noodzakelijk. Voor dit onderzoek is deze vereenvoudiging voldoende. Dit element zorgt er ook voor dat antwoordberichten opnieuw beveiligd worden verstuurd over de DTLS–sessie indien het vraagbericht beveiligd is binnengekomen. 2. DTLSModule: Deze module bevat zowel een instantie van de DTLS–client– als –server– context en is bovendien ook de interface naar CyaSSL. De hierna besproken werking van de DTLSModule is weergegeven in Figuur 3.9. De DTLSModule gaat voor elk pakket na of het een handshake–bericht betreft of application data. Daarna wordt het bericht in de juiste context afgehandeld: handshake afwerken, application data encrypteren of decrypteren.

3.2 Implementatie

37

Figuur 3.9: Algemene werking van het DTLSModule–element.

Alle DTLS-verkeer, met als bestemming een node waarvoor is geopteerd om het verkeer af te breken op de gateway, wordt in deze module aangepast. Het afzenderadres wordt ingesteld op het IPv6–adres van de gateway. In Figuur 3.10 is een voorbeeld weergegeven waarbij het afzenderadres van de Internet client (bbbb::2) wordt aangepast naar het IPv6– adres van de gateway (bbbb::1). Dit is noodzakelijk om van dezelfde DTLS–sessie gebruik te kunnen maken in het LLN. Het nadeel is dat het voor het constrained device lijkt alsof alle aanvragen van de gateway afkomstig zijn. Wanneer het antwoord van het constrained device terug binnenkomt op de gateway, wordt aan de hand van het CoAP–token het originele afzenderadres opgehaald. Het CoAP–token is standaard aanwezig in een CoAP– bericht en zorgt voor de koppeling tussen vraag en antwoord. Bij ontvangst van een pakket door de Click router wordt, in een callbackmethode, de

3.2 Implementatie

38

Figuur 3.10: Aanpassing van het IPv6–adres in het LLN om de gedeelde DTLS–sessie mogelijk te maken.

ontvangstbuffer gekopieerd naar een buffer leesbaar voor CyaSSL. CyaSSL kan daarna het pakket behandelen en plaatst zijn antwoordbericht in een buffer. CyaSSL roept een callback–methode op waarin dit antwoordbericht wordt gekopieerd in de verzendbuffer van de Click router. Nu kan het bericht door Click worden verstuurd. 3. DTLSClassifier: De classifier controleert of het verkeer, komende van het LLN, een DTLS– laag bevat of niet. Indien dit het geval is, wordt het pakket via de DTLSModule naar zijn bestemming verstuurd. 4. DTLSSelector: De DTLSSelector bepaalt op basis van at–runtime ingestelde parameters of het pakket in een nieuwe DTLS-sessie verstuurd moet worden of onbeveiligd mag worden verstuurd in het LLN. Deze parameters worden ingesteld per constrained device (zie verder). Daarnaast zijn enkele hulpklassen toegevoegd die geen Click-elementen definiëren, maar op de achtergrond belangrijke taken vervullen. De rollen van de hulpklassen ten opzichte van de centrale DTLSModule zijn weergegeven in Figuur 3.11. Deze hulpklassen worden hier besproken: 1. DTLS(Client)Context: De DTLSContext en DTLSClientContext zijn respectievelijk de DTLS-server– en DTLS–client–context. Beiden zijn singleton–objecten en bevatten de DTLS–sessie–objecten. Wanneer een CyaSSL-methode wordt opgeroepen is het noodzakelijk om dit sessie–object mee te geven. Daarnaast bevatten deze singleton–objecten enkele CyaSSL-callbacks: sendTo, receiveFrom, EmbedGenerateCookie en clientPSK. De methode EmbedGenerateCookie komt enkel voor in de DTLSContext–klasse, terwijl de methode clientPSK enkel voorkomt in de DTLSClientContext–klasse. In EmbedGenerateCookie wordt een staatloos cookie opgemaakt die in het HelloVerify–bericht wordt verstuurd tijdens de DTLS–handshake. De clientPSK–methode stelt de vooraf uitgewisselde sleutel in. De methodes sendTo en receiveFrom kopiëren berichten tussen de Click– en CyaSSL–buffers.

3.2 Implementatie

39

2. DTLSTerminationInfo: Zowel het DTLSSelector– als het DTLSState–element maken gebruik van deze klasse. Een DTLSTerminationInfo–instantie is een singleton die informatie bevat in verband met het al dan niet termineren van DTLS–verkeer op de gateway. Indien er wordt getermineerd op de gateway, wordt ook dit object geraadpleegd door de DTLSModule om na te gaan of het nodig is om het bericht te encrypteren vooraleer het wordt doorgestuurd in het LLN.

Figuur 3.11: De rol van de hulpklassen ten opzichte van het DTLSModule–element in de Click router.

Het al dan niet termineren op de gateway en het kiezen welk beveiligingsmechanisme daarna wordt toegepast in het LLN kan ingesteld worden terwijl de router in uitvoering is. Dit gebeurt door met een CoAP–client berichten te sturen naar de gateway. Standaard wordt alle DTLS–verkeer doorgelaten door Click. Indien het DTLS–verkeer moet worden getermineerd, wordt een POST–bericht gestuurd naar Click met als payload “dtls;”, gevolgd door het IPv6–adres van het constrained device met daarna een “;”. Vervolgens komt een veld waarin wordt gespecifieerd indien er in het LLN ook DTLS vereist is. Dit veld is 1 indien ja, 0 indien nee en wordt opnieuw afgesloten met een “;”. Deze payload kan daarna nog meerdere IPv6-adressen met de optie termineren of niet bevatten. Om de instellingen ongedaan te maken wordt een DELETE–bericht verstuurd met het IPv6–adres als payload. De Click router maakt geen ’/dtls’–resource aan, maar het is logischer om een POST–operatie uit te voeren naar iets. Aan de hand van de ’/dtls’ in de URI herkent de router dat het gaat om een bericht die de instellingen bevat voor terminatie.

3.2 Implementatie

40

Voorbeeld: POST coap://[aaaa::1]/dtls ”dtls;aaaa::200:0:0:1;1;” Berichtenstroom in Click router Om meer inzicht te krijgen in de toegevoegde Click–elementen wordt hier besproken hoe de berichten zich een weg banen van het binnenkomen tot het verlaten van de gateway. In alle scenario’s is er op het Internet een DTLS–client die een vraagbericht wil versturen naar een bepaalde bestemming. In het eerste scenario is de bestemming de lokale DTLS–server: COAPClientServer. Het tweede scenario bespreekt de communicatie met een DTLS–server in het LLN. Alle elementen worden weergegeven in Figuur 3.12. Berichtenstroom met de COAPClientServer Zoals reeds beschreven kan de COAPClientServer kan zowel als CoAP–client en als CoAP–server optreden. Indien deze de serverrol vervult, werd als DTLS–client Scandium ingezet. De client start de DTLS–handshake met een ClientHello–bericht. Dit bericht komt via de Click–router aan in het dynIPv6Routing-element waarna het wordt gerouteerd naar de coapIPv6TrafficClassifier. Indien het bericht een CoAP– laag bevat, gaat het bericht verder naar het DTLSState–element. Hier wordt het pakket gecontroleerd op de aanwezigheid van een DTLS–header. Indien dit zo is, wordt het eerst naar de DTLSModule gestuurd (via ingang 0), vooraleer het eventueel de COAPClientServer kan bereiken. De DTLSModule controleert over welk type bericht het gaat: handshake of application data? Dit kan worden afgeleid uit het Type–veld in de DTLS–header. Indien het om een handshakebericht gaat wordt de DTLS–servercontext opgeroepen om het bericht af te handelen. De servercontext meldt aan CyaSSL, door het oproepen van de receiveFrom–handler, dat er een pakket is aangekomen. CyaSSL kan de afhandeling van het bericht starten. CyaSSL plaatst zijn antwoordbericht in de buffer en dit wordt door Click opnieuw verstuurd via uitgang 1 van de DTLSModule. Pas wanneer er application data is aangekomen van de client, wordt het gedecrypteerde CoAP-bericht via uitgang 0 doorgestuurd naar de COAPClientServer. Op deze manier kan DTLS transparant worden afgehandeld voor de COAPClientServer. Het CoAP– antwoordbericht van de COAPClientServer komt plain text aan in de DTLSModule via ingang 1, nadat het DTLSState-element beslist heeft om het antwoordbericht te encrypteren (uitgang 2). Deze beslissing is gebaseerd op het feit dat het vraagbericht afkomstig van de client al dan niet geëncrypteerd was. Het bericht wordt eventueel geëncrypteerd door de servercontext en wordt door de DTLSModule verstuurd via uitgang 1 naar de DTLS–client. Indien de COAPClientServer zich als CoAP–client gedraagt, dan verstuurt deze een vraag-

3.2 Implementatie

41

bericht. Mits het bestemmingsadres als schema ”coaps”draagt, wordt een annotatie toegevoegd aan het pakket. Dit is noodzakelijk omdat in een CoAP–pakket het URI–schema niet wordt bijgehouden. Deze annotatie wordt door het DTLSState-element opgemerkt, wat resulteert in het doorsturen van het bericht naar de DTLSModule. Deze laat de clientcontext de handshake opstarten door het versturen van een ClientHello-bericht. Het antwoordbericht van de server (HelloVerifyRequest) bevat uiteraard een DTLS-laag en wordt door het DTLSState-element doorgestuurd naar de DTLSModule. Op deze manier wordt de handshake afgewerkt zodat de DTLSModule daarna het vraagbericht van de COAPClientServer kan encrypteren en de application data (met de CoAP–request) kan versturen. Berichtenstroom met een constrained device Berichten komen de Click router binnen en worden via het DynIPv6Routing- en het dynVirtualDeviceClassifier-element tot bij het DTLSState–element gebracht. Hier worden, net zoals bij de berichtenstroom naar de COAPClientServer, alle controles uitgevoerd: DTLS? Termineren? Verwijderen(retransmissie)? Indien nodig wordt het pakket doorgestuurd naar de DTLSModule waar de handshake wordt afgehandeld. Daarna gaat de gedecrypteerde application data door naar de DTLSSelector. Deze bepaalt of het verkeer opnieuw moet worden geëncrypteerd op basis van at–runtime ingestelde parameters. Indien dit zo is, wordt het bericht doorgestuurd naar een tweede instantie van de DTLSModule (SensorNetworkDTLSModule) waar ook gebruikgemaakt wordt van de singleton contextobjecten om de DTLS–handshake af te handelen. Vervolgens worden de berichten doorgestuurd naar een ClickToSensor-element (de instantie: contikiInterface). Via het SLIP-protocol ontvangt een 6LoWPAN–border router deze pakketten. Met behulp van een draadloos netwerk communiceert de 6LoWPAN–border router met de DTLS–server in het LLN. De antwoordberichten komen de Click–router opnieuw binnen via het ClickToSensor-element en worden gestuurd naar de SensornetworkSecurityClassifier. Hier wordt nagegaan of het pakket een DTLS– header bevat. Indien dit zo is, wordt het doorgestuurd naar de SensorNetworkDTLSModule om het antwoord te decrypteren. In het andere geval verlaat het pakket de Click–router via het DTLSState–element naar de DTLS–client (de bestemming). Objecten Zoals te zien is op Figuur 3.12 bevat de Click router drie instanties van de DTLSModule: de dtlsModule handelt het DTLS–verkeer af richting het COAPClientServer–element, de DTLSmodule termineert het DTLS–verkeer richting het LLN en de SensorNetworkDTLSModule treedt op als client of server voor het DTLS–verkeer in het LLN. Alle instanties maken

3.2 Implementatie

42

gebruik van de singleton client- en servercontextobjecten. Deze objecten bevatten bovendien ook de CyaSSL–statusobjecten die de huidige toestand bijhouden van de SSL-sessie. Deze sessie– objecten worden bijgehouden in de router en telkens meegegeven als argument bij het oproepen van functies uit de CyaSSL–bibliotheek.

Figuur 3.12: Click router

3.2 Implementatie 43

3.3 Besluit

3.2.4

44

Interoperabiliteitsprobleem

In de verschillende scenario’s voorgesteld in de sectie 3.1 nemen drie partijen deel. Op elk van deze toestellen is een verschillende implementatie van DTLS 1.2 ge¨ımplementeerd. Allen ondersteunen ze dezelfde cipher suite en volgen ze de standaard. Toch liep de realisatie van de beveiligde communicatie tussen de partijen moeizaam. In de CCM–cipher suites wordt gebruikgemaakt van een nonce (RFC 6655). Deze moet 12 bytes lang zijn en bestaat uit een salt en een expliciete nonce. Deze laatste zorgt voor problemen. De salt is het impliciete deel van de nonce en wordt niet meegestuurd in pakketten, in tegenstelling tot het expliciete gedeelte. Deze salt wordt bepaald uit het handshakeproces: dit is de client write IV–waarde wanneer de client stuurt, ofwel de server write IV–waarde wanneer de server stuurt. Het expliciete gedeelte is een unieke waarde per bericht dat door de client wordt gekozen en wordt meegestuurd in het bericht. De RFC stelt voor om voor DTLS als expliciete nonce de 16–bit epoch, geconcateneerd met het 48–bit seq num te nemen. Deze expliciete nonce mag worden gelijkgesteld aan deze vorm, maar dit hoeft niet zo te zijn. Althans, dit is de interpretatie die ik volg en ook bevestigd werd door de submit van een pull-request1 voor Scandium op Github. De enige voorwaarde is dat de expliciete nonce uniek is per record. Zowel TinyDTLS als Scandium maken gebruik van deze vorm van expliciete nonce, maar CyaSSL maakt gebruik van een waarde die telkens wordt ge¨ıncrementeerd per record. Indien de explicit nonce niet overeenkomt wordt een BAD MAC ERROR–alertbericht uitgestuurd. Aan de hand van deze ontvangen waarde kan de authenticatie herberekend worden om na te gaan of het bericht onderweg niet gewijzigd is. Eens deze aanpassingen doorgevoerd op de implementaties, werkten de implementaties goed samen. Uiteraard moeten ook de correcte sleutels worden ingesteld voor de PSK cipher suite.

3.3

Besluit

Het is duidelijk dat bij deze gebruikersscenario’s een aantal communicerende partijen deelnemen. Deze partijen zijn eerdere heterogeen: (1) een krachtig toestel aangesloten op het Internet dat CoAP moet kunnen communiceren en minder krachtige cipher suites voor constrained devices moet ondersteunen (2) de krachtige gateway met een interface naar het Internet en een interface naar het LLN, die DTLS–verkeer afbreekt en bovendien zowel de meer krachtige als de minder krachtige cipher suites moet ondersteunen (3) een constrained device waarop een DTLS– en 1

https://github.com/mkovatsc/Scandium/pull/4/files, laatst geraadpleegd op 28/05/’14.

3.3 Besluit

45

CoAP–server draait. Het is niet eenvoudig gebleken om de gebruikersscenario’s met de verschillende types toestellen werkende te krijgen. Het aantal DTLS–implementaties voor constrained devices in LLN’s is eerder klein en bovendien wordt typisch niet alle functionaliteit ondersteund. De keuze voor OpenSSL moest worden gewijzigd naar CyaSSL wegens het niet ondersteunen van de cipher suites voor constrained devices. Het optreden van het probleem omtrent de explicit nonce en de CloseNotify–alerts die niet volledig worden ondersteund tonen aan dat de implementaties niet afgewerkt zijn. Het debuggen van problemen bij communicerende toestellen is bovendien niet eenvoudig.

RESULTATEN

46

Hoofdstuk 4

Resultaten In dit hoofdstuk worden een aantal gebruikersscenario’s uit sectie 3.1.1 geëvalueerd. Eerst en vooral wordt in detail de testopstelling besproken. Daarna volgt de bespreking van de metrieken en de evaluatiemethodologie. Vervolgens wordt elk scenario besproken op vlak van geheugengebruik, pakketkost, energieverbruik en de vertragingstijd. Tenslotte worden de scenario’s met elkaar vergeleken en kan een besluit worden geformuleerd omtrent de goedkoopste aanpak om verkeer tussen het Internet en het LLN te beveiligen aan de hand van DTLS.

4.1

Testopstelling

De testopstelling bestaat uit een desktop waarop twee virtuele machines draaien. Op de eerste virtuele machine draait het traditionele toestel zoals besproken in sectie 3.2.2. Deze kan zowel als client en als server optreden. Voor beide implementaties worden de voorbeelden uit Scandium en Californium ingezet. Deze virtuele machine krijgt een IPv6–adres toegewezen en een route naar het LLN via de tweede virtuele machine. De tweede virtuele machine bevat de Click router, die een interface biedt naar het virtuele LLN in de Cooja netwerksimulator. Via het SLIP– protocol worden berichten die aankomen in Click, met als bestemming een constrained device, doorgestuurd naar het LLN. Dit LLN bestaat uit een 6LoWPAN–border router die aangekomen berichten verstuurt via het draadloze netwerk. De afstand tussen het constrained device en de 6LoWPAN–border router is slechts één hop. De twee constrained devices zijn manueel op een vaste locatie geplaatst zodat de round–trip tijden in de experimenten vergelijkbaar zijn. Op de achtergrond in Figuur 4.1 is een kader te zien met zijdes van 10 m. De constrained devices staan dicht bij elkaar om goede radiotransmissie te verzekeren.

4.1 Testopstelling

47

Figuur 4.1: De netwerkomgeving in de Cooja netwerksimulator

Het RM090–platform (Figuur 4.2 en Bijlage A) wordt gebruikt voor de nodes die virtueel worden nagebootst in de Cooja netwerksimulator met behulp van een aangepaste versie van MSPSim1 . Dit is een ultra-low power draadloze module die naadloos samenwerkt met andere apparatuur dankzij het gebruik van USB en IEEE 802.15.4. De RM090 bevat de 5e generatie (msp430f5437) van Texas Instrument MCU MSP430[40, 41] en de CC2520 radio–ontvanger [42]. Deze msp430 is een 16–bit microcontroller. Slechts 20–bit geheugentoegang wordt ondersteund. Zo is er 16 kB RAM–geheugen en 128 kB ROM–geheugen beschikbaar. Er werd voor dit platform geopteerd omdat het over genoeg geheugen beschikt om een DTLS–server te draaien. Om programma’s voor de de msp430–microcontroller te compileren, werd gebruikgemaakt van de gratis beschikbare msp430-gcc compiler versie2 4.7.0 [39]. Voor deze experimenten wordt de encryptie en decryptie (het AES–algoritme) in software uitgevoerd wegens het ontbreken van een AES–versnellermodule in hardware. Dit resulteert in een hoger geheugengebruik en slechtere performantie. Op het constrained device draait het besturingssysteem ContikiOS3 . ContikiOS is geconfigureerd om gebruik te maken van het RPL–routeringsprotocol en de µIP–stapel. Beiden zijn 1 2

MSPSim is een Java-gebaseerde emulatie van de MSP430-serie microprocessor. Uitvoer van het commando msp430-gcc –version geeft als output: msp430-gcc (GCC) 4.7.0 20120322 (mspgcc

dev 20120716) 3 Contiki versie 2.7

4.2 Metrieken

48

Figuur 4.2: RM090

standaard aanwezig in Contiki. Het gebruik van dit routeringsprotocol is niet noodzakelijk wegens de afstand van slechts 1 hop tussen de border router en het constrained device. In realiteit zal er echter wel een routeringsprotocol aanwezig zijn. Om deze reden is hier geopteerd om dit protocol ingeschakeld te houden zodat de resultaten niet positiever overkomen dan ze werkelijk zijn. Het gebruik van Radio Duty Cycling (RDC) is uitgeschakeld wegens het feit dat de huidige TinyDTLS–implementatie er niet mee samenwerkt. Bovendien bestaan er verschillende mogelijke RDC–drivers. Het gebruik van een bepaalde driver kan andere resultaten opleveren. Het gevolg is dat de radio nooit wordt uitgeschakeld, waardoor in deze experimenten een zeer hoog luisterenergieverbruik gemeten wordt. RDC probeert de radio zo vaak mogelijk uit te schakelen, waardoor dit energieverbruik normaliter veel lager ligt.

4.2

Metrieken

Een aantal scenario’s worden met elkaar vergeleken op basis van de volgende metrieken: 1. Geheugengebruik: Hoeveel ROM– en RAM–geheugen is vereist om (on)beveiligde CoAP te communiceren? In de testopstelling wordt de Erbium–server gebruikt om CoAP te communiceren. TinyDTLS is de gebruikte implementatie voor de DTLS–server. 2. Energieverbruik: Het energieverbruik is van primair belang in LLN’s. Het is dus uiterst interessant om na te gaan hoeveel energie [µJ] er verbruikt wordt om een boodschap over te brengen. Bij onbeveiligde CoAP–berichten gaat dit over het versturen van één pakket, maar dit kan bij gebruik van DTLS hoog oplopen wegens de eventueel nog uit te voeren

4.3 Evaluatiemethodologie

49

handshake. 3. Round–trip tijd: Hoe lang duurt het vooraleer de client het antwoord van de server ontvangt? Een nog uit te voeren DTLS–handshake kan deze round–trip tijd doen exploderen. 4. Packet overhead: Hoeveel berichten (bytes) moeten worden verstuurd? Ook hier is de DTLS–handshake van groot belang. De packet overhead wordt veel groter indien een DTLS–handshake wordt uitgevoerd.

4.3

Evaluatiemethodologie

In deze sectie wordt besproken hoe de experimenten worden uitgevoerd. De manier waarop de metingen bekomen zijn, is belangrijk om te kunnen vergelijken met andere resultaten. Om de impact van de metingen op de experimenten te beperken, worden alle metingen via de seriële connectie van het constrained device gecommuniceerd. Er treedt echter regelmatig een nullpointer– exceptie op bij het uitschrijven van deze gegevens naar de socket. De experimenten waarbij er zo’n exceptie optreedt zijn niet opgenomen in de resultaten. 1. Geheugengebruik: Aan de hand van de commando’s msp430-size en msp430-objdump (meer detail, bijvoorbeeld per symbool in de binary) is het mogelijk om de hoeveelheid statische ROM– en RAM–geheugen van applicaties te bepalen. 2. Energieverbruik: Deze energiemetingen gebeuren softwarematig aan de hand van Energest [29]. Veel populaire hardwareplatformen zoals Tmote Sky en ESB ondersteunen geen hardwarematige mechanismen voor het bepalen van de energieconsumptie. Energest is op een zeer eenvoudige manier toe te voegen aan een besturingssysteem: zonder wijzigingen uit te voeren aan bestaande applicaties of netwerkprotocollen. Het programma voert metingen uit in ware tijd en maakt gebruik van een simpel lineair model. Er bestaan ook andere softwaregebaseerde tools voor energiemetingen, maar deze vereisen meestal wijzigingen aan de bestaande applicaties (e.g. het mechanisme van Younis en Fahmy [30]). Daarenboven vereist het gebruik van Energest slechts enkele extra regels code. Om energie te besparen gaat een constrained device typisch zijn componenten aan– en uitschakelen. Energest registreert de tijdstippen waarop dit gebeurt en bepaalt op deze manier de totale aan–tijd van een component. Zo wordt voor elke component de energieconsumptie bepaald. In de driver van de component worden twee regels code toegevoegd


50

die de tijdsperiode tussen het aan– en uitschakelen van de component registreren en optellen bij de huidige totale aan–tijd van de component. Het meten van de tijd gebeurt aan de hand van de timers op de chip van de MSP430. Deze tijdsmetingen verstoren de energiemetingen niet omdat de on–chip timers ook werken in low power mode van de MCU. Deze kan dus gerust slapen terwijl de metingen verder lopen. Uit evaluaties van Energest blijkt dat gemiddeld 1800 cycles overhead per seconde, of 0.7 procent van de totale verwerkingstijd wordt besteed aan Energest. De voetafdruk van de code bedraagt 394 bytes, terwijl het programma 48 bytes geheugen vereist [29]. Het energieverbruik wordt gemeten met als eenheid een aantal timerticks. Het omzetten van deze ticks naar energie gebeurt aan de hand van Formule 4.1. Zowel de processor (MSP430) als de radio (CC2520) hebben een operationeel voltage van 3 V. Het stroomverbruik van de processor en de radio zijn weergegeven in Tabel 4.1. Deze cijfers zijn gemiddelde waardes. De klokfrequentie bedraagt 16 MHz. Opvallend is het hoge energieverbruik van de radio ten opzichte van de MCU. Dit is typisch voor constrained devices. Bovendien is het stroomverbruik bij idle listening hoger dan bij het ontvangen van een bericht. De oorzaak hiervoor is het feit dat de radio tijdens idle listening zoekt naar het zwakst mogelijke signaal, wat een hoger stroomverbruik veroorzaakt. Bij het ontvangen van een bericht is dit signaal meestal sterker: het stroomverbruik wordt kleiner. Omdat op het constrained device TinyDTLS niet samenwerkt met een RDC–driver, wordt constant naar het draadloze medium geluisterd voor een radiotransmissie. De resultaten van Energest voor de luistercomponent zijn dan ook zeer hoog. Om toch een idee te krijgen van het effectieve verbruik voor het ontvangen van berichten werd via een interrupt de tijd gemeten dat de radio een frame ontvangt. Door het configureren van de CC2520’s GPIO4– en GPIO5–pinnen om Start Frame Delimiter (SFD) en TX ACTIVE te communiceren op de msp430 werd een interrupthandler opgeroepen telkenmale de radio start of stopt met versturen of ontvangen. Op deze manier kan de totale tijd worden opgemeten dat de radio ingeschakeld is. Door na te gaan via de TX ACTIVE–lijn van de CC2520 of de radio aan het versturen is, kan beslist worden indien de gemeten tijd toebehoort tot de luister– of verzendtijd. Deze TX ACTIVE–lijn kan afwijkingen vertonen op echte constrained devices, maar dit is in simulatie met MSPSim niet het geval. De luister– en verzendtijden bekomen op deze manier rekenen ook het versturen en ontvangen van laag–2–ACK’s (frame acknowledgements) mee. Dit is voor de Energest–waarden niet het


51

geval. De totale gemeten tijd waarbij de radio actief is, is kleiner dan in realiteit want deze techniek begint pas te meten wanneer de SFD–pin hoog komt. Op dit moment is de SFD reeds verstuurd of ontvangen.

Energie =

(OperationeelV oltage) · (OperationeleStroom) · (AantalT icks) Klokf requentie

(4.1)

De CoAP–client (Californium) is aangepast zodat telkens voor het versturen van een vraagbericht, er een bericht wordt verstuurd naar het constrained device via een telnet–sessie. Deze telnet–sessie komt binnen via de seriële poort op het constrained device. Als reactie op dit bericht verstuurt het constrained device de huidige energiewaardes naar de CoAP– client. Dit gebeurt via een telnet–sessie over een asynchrone socket die wordt geopend in de CoAP–client. Na deze initialisatie verstuurt het constrained device op specifieke tijdstippen de nieuwe energiewaarden. Zo kan het energieverbruik worden bepaald gedurende het verloop van het experiment. Mode

Operationeel stroomverbruik [µA]

MCU

86

LPM

2,6

Receive

18500

Transmit

25800

Idle listening

22300

Tabel 4.1: Stroomverbruik van de radio en processor in de RM090. 3. Round–trip tijd: De round–trip tijd wordt door de CoAP(s)–client (Californium & Scandium) bepaald bij het ontvangen van het antwoordbericht aan de hand van de “System.nanoTime()”–methode in Java die de huidige tijd van de Java virtuele machine teruggeeft. 4. Packet overhead: Aan de hand van de pcap–output ge¨ıntegreerd in de Cooja netwerksimulator kunnen alle berichten verstuurd in het LLN worden opgevraagd. Via Wireshark [43] is het mogelijk dieper in deze pakketten te kijken naar de inhoud en grootte van elke laag.

4.4 Experimenten

4.4

52

Experimenten

In dit hoofdstuk worden een aantal experimenten uit sectie 3.1.1 besproken. De geselecteerde scenario’s zijn interessant op gebied van de gekozen metrieken. Niet alle gebruikersscenario’s worden hier dus besproken. Voor elk van deze situaties worden de metrieken gemeten om op deze manier een besluit te kunnen vormen over welke situatie de meest energiezuinige beveiligde communicatie voorziet. Voor alle beveiligde verbindingen wordt DTLS toegepast met de TLSAES-128-CCM-8 cipher suite.

Figuur 4.3: Een CoAP–GET–vraag met antwoord.

4.4.1

Referentiecase: plain text CoAP

Als referentiecase wordt het geval besproken waarbij de client (Californium CoAP–client) een onbeveiligd CoAP–bericht (Figuur 4.3) stuurt naar de server (Erbium CoAP–server) in het LLN. De gateway laat het verkeer ongewijzigd door. 1. Geheugenvereisten: Zoals in Tabel 4.2 af te lezen, vraagt de Erbium–server 46,33 kB ROM– en 5,94 kB RAM– geheugen. Deze geheugenvereisten zijn niet hooggegrepen en dienen als referentie. Deze cijfers zijn platformafhankelijk en uiteraard ook afhankelijk van de CoAP–resources aanwezig op de server. In deze experimenten wordt enkel de HELLO–resource geactiveerd.

4.4 Experimenten

53

ROM–geheugen [kB]

RAM–geheugen [kB]

Erbium

46,33

5,94

TinyDTLS

62,15

8,00

TinyDTLS + Erbium

68,70

8,10

Tabel 4.2: Geheugenvereisten van de CoAP– en DTLS–server.

Figuur 4.4: Energieverbuik op een RM090 bij ontvangen/beantwoorden van een GET hello. De waarde voor de ontvangstenergie is exclusief idle listening.

2. Energieverbruik: Zoals in Figuur 4.4 duidelijk opvalt, is het vooral de radio die de grote energieverbruiker speelt. Voor het ontvangen van een CoAP–HELLO–request (71 bytes) wordt ongeveer 0,29 µJ energie verbruikt. Voor het versturen van het antwoord (70 bytes), is dit 0,39 µJ. De reden hiervoor is terug te vinden in Tabel 4.1: het is duurder om een bericht te

versturen dan te ontvangen. Het energieverbruik van de MCU, low power mode en de interruptafhandelingen zijn verwaarloosbaar: respectievelijk 0,0092, 0,0057 en 0,000017 µJ.

3. Round–trip tijd: De gemiddelde round–trip tijd voor een GET hello bedraagt 190,82 ms. De mediaan bedraagt 143,21 ms. In het slechtste (geobserveerde) geval loopt dit op tot meer dan 2000 ms. Na onderzoek blijkt dit te wijten te zijn aan de noodzaak om het bericht meerdere keren te versturen. Wegens pakketverlies in het LLN komt het bericht niet goed

4.4 Experimenten

54

Figuur 4.5: Cumulatieve distributiefunctie van de round–trip tijd bij een onbeveiligd CoAP– vraagbericht.

aan. Er zijn 15 retransmissies gebeurt over de 1000 aanvragen en een pakket is na vier (het ingestelde maximaal aantal) retransmissies nog steeds niet aangekomen. Figuur 4.5 bevat de cumulatieve distributiefunctie van de round–trip tijden voor onbeveiligde CoAP– vragen. De sterke stijging bij 140 ms is duidelijk zichtbaar: dit is de tijd waar de meeste round–trip tijden zich ongeveer bevinden. Zo’n 10 % van de vraagberichten moet langer dan 300 ms wachten op een antwoord.

Figuur 4.6: Packet overhead in een plain text CoAP–bericht.

4.4 Experimenten

55

4. Packet overhead: Het is op Figuur 4.6 duidelijk te zien dat de omschakeling naar 6LoWPAN zorgt voor compressie in het LLN. Voor het vraagbericht is deze winst beperkt (1 byte) wegens het voorkomen van een extra IPv6 Hop–by–hop–optie (8 bytes groot). Dit is een optie van het type Type-Length-Value die uitbreidingen aan een IPv6–pakkket mogelijk maakt. Deze optie wordt hier gebruikt door de border router om RPL–informatie toe te voegen aan het pakket. Het antwoordbericht is wel een stuk kleiner. Dit bericht bevat namelijk geen UDP–header, maar wel een grotere 6LoWPAN–header. Er wordt in het antwoordbericht namelijk gebruikgemaakt van UDP–headercompressie. Dit levert 1 byte winst op. Deze winst is te wijten aan het lengte-veld (2 bytes) dat weggelaten wordt, maar er komt een UDP–headercompressie–byte bij die aangeeft welke compressievorm wordt gebruikt. Het antwoordbericht bevat in het LLN geen IPv6 Hop–by–hop–optie. De overige winst is te wijten aan een kleinere grootte van de combinatie van de IEEE802.15.4– en de 6LoWPAN– header in vergelijking met de Ethernet– en IPv6–header. Omdat er slechts één hop tussen de border router en het constrained device is, kan men telkens ofwel het IPv6–bronadres of –doeladres comprimeren. In een groter netwerk met meer dan één hop is dit niet meer mogelijk op de tussenliggende links. Dit zorgt voor een extra overhead van 8 bytes.

4.4.2

Experiment 1: End–2–end DTLS

Als eerste experiment zal een CoAPS–bericht verstuurd worden door de client (Scandium) op een traditioneel toestel naar de DTLS–server (TinyDTLS) in het LLN. De gateway (Click) zal het DTLS-verkeer niet termineren. Dit is end–to–end beveiligde communicatie die enkel geschikt is voor de krachtigere constrained devices. 1. Geheugenvereisten: Zoals in Tabel 4.2 af te lezen, vraagt de TinyDTLS–server 62,15 kB ROM– en 8,00 kB RAM–geheugen. TinyDTLS verbruikt dus aanzienlijk meer ROM– en RAM–geheugen dan Erbium. Omdat het echter de bedoeling is om beveiligde CoAP–berichten te versturen moet de plain text output van TinyDTLS doorgegeven worden naar de Erbium–server op het constrained device. De combinatie van beide applicaties vraagt 68,70 kB ROM– en 8,10 kB RAM–geheugen. Dit geheugengebruik is reeds relatief hoog, waardoor het voor sommige beperkte devices niet mogelijk is om een DTLS–server te draaien. Bijvoorbeeld voor

4.4 Experimenten

56

de meeste 16–bit MCU’s kan slechts 64 kiB aan geheugen worden geadresseerd. TinyDTLS en Erbium zitten hier al ruim over. Bovendien moet er ook nog een applicatie draaien.

Figuur 4.7: Energieverbuik op een RM090 bij ontvangen/beantwoorden van een (on)beveiligde CoAP–vraag (GET hello).

2. Energieverbruik: Uit Figuur 4.7 is opnieuw af te leiden dat de radio de grootste energieverbruiker is. Het ontvangen van het beveiligde CoAP–bericht, met de vraag naar de HELLO–resource, verbruikt ongeveer 4,4 µJ. Dit is ongeveer vijftien keer het energieverbruik voor dezelfde onbeveiligde CoAP–vraag. Het hoge energieverbruik is te wijten aan het uitvoeren van de DTLS–handshake: heel wat meer berichten (bytes) worden ontvangen en verstuurd. Hetzelfde verschijnsel is op te merken bij het transmissieverbruik: 4,6 µJ. De MCU verbruikt 0,24 µJ. Ook hier zien we verwaarloosbare energiemetingen voor low power mode en interruptafhandeling: 0,09 en 0,0003 µJ. Het energieverbruik van de MCU, relatief ten opzichte van het verbruik van de radio, is gestegen. Figuur 4.8 geeft het belang aan van radio duty cycling duidelijk. Het constrained device zou heel wat minder energie verbruiken dankzij dit mechanisme. In Figuren 4.9, 4.10 en 4.11 zien we het relatieve energieverbruik per bericht op de MCU, tijdens het ontvangen en tijdens het verzenden. Op vlak van MCU–gebruik zien we dat de aankomst van het Finished–bericht van de client het grootste stuk van de taart voor zijn rekening neemt. Dit bericht komt aan in een vlucht van drie berichten: ClientKeyExchange, ChangeCipherSpec en het ClientFinished–bericht. De DTLS–server behandelt deze berich-

4.4 Experimenten

57

ten en moet de hash berekenen over alle DTLS–handshakeberichten (behalve ClientHello en HelloVerifyRequest), om deze te vergelijken met de hash van de client en zijn hash daarna ook door te sturen in het server Finished–bericht. De server berekent bovendien het premaster secret en het master secret. Hieruit worden daarna de verschillende geheime waarden bekomen (zie sectie 2.2.3). Al deze berekeningen vereisen het uitvoeren van de SHA256–hashfunctie, die wordt gekarakteriseerd door een hoog MCU–gebruik. De twee taartdiagrammen die de relatieve verzend– en ontvangstenergie weergeven kunnen onmiddellijk verklaard worden door de grootte van de berichten die worden verstuurd of ontvangen (Tabel 4.3 op pagina 63). Bovendien is in deze tabel aangegeven uit hoeveel fragmenten elk bericht bestaat. Figuur 4.10 is minder opgedeeld omdat CyaSSL verschillende berichten groepeert in vluchten. TinyDTLS doet dit niet voor de ServerHello, ServerKeyExchange en ServerHelloDone. Deze worden dus afzonderlijk verstuurd.

Figuur 4.8: Het energieverbruik van idle listening versus het effectief ontvangen van pakketten tijdens een DTLS–handshake en een CoAP–request/response.

4.4 Experimenten

58

Figuur 4.9: Relatief MCU–energieverbruik van de DTLS–handshakeberichten.

Figuur 4.10: Relatief radio–energieverbruik bij het ontvangen van de DTLS–handshakeberichten.

Figuur 4.11: Relatief radio–energieverbruik bij het versturen van de DTLS–handshakeberichten.

4.4 Experimenten

59

3. Round–trip tijd: De gemiddelde round–trip tijd bedraagt 2037,9 ms. Dit is hoger dan de mediaan van 1844,72 ms. De reden hiervoor is het optreden van retransmissies bij pakketverlies. Deze retransmissies doen uiteraard de round–trip tijd toenemen. In Figuur 4.13, reeks “DTLS sensornetwerk”, is duidelijk te zien dat de gemiddelde wachttijd op een antwoord meestal net onder de 2 s ligt. Er werden round–trip tijden geobserveerd van meer dan 7 s, waarbij drie retransmissies nodig waren. De vlucht met ClientKeyExchange–, ChangeCipherSpec– en Finished–berichten wordt vaak opnieuw verstuurd. Er treden bij dit grote bericht problemen op in het LLN waardoor niet alles wordt ontvangen door het constrained device. Dit bericht wordt gefragmenteerd in twee fragmenten. Indien de berichten niet meer in een vlucht worden verstuurd, dan wordt het ClientKeyExchange–bericht apart verzonden. Het ChangeCipherSpec– en Finished–bericht worden samen verstuurd, maar hier treedt fragmentatie op. Op deze wijze worden drie delen verkregen ten opzichte van twee bij de groepering, waardoor de kans op pakketverlies toeneemt. Bovendien worden meer bytes verstuurd (261 ten opzichte van 201). Zoals besproken in sectie 3.2.1 mislukt de handshake indien de server niet reageert op retransmissies van de ClientKeyExchange–, ChangeCipherSpec– en Finished–berichten.

Figuur 4.12: Cumulatieve distributiefunctie van de round–trip tijd bij een onbeveiligd CoAP– vraagbericht versus beveiligde CoAP (zonder DTLS–handshake).

4.4 Experimenten

Figuur 4.13:

60

Cumulatieve distributiefunctie van de round-trip tijd voor een beveiligde

CoAP–vraag/antwoord met DTLS–handshake. DTLS–handshake met de gateway versus het constrained device.

Deze round–trip tijd is geldig voor een DTLS–sessie waarin slechts één vraag wordt verstuurd. Indien dezelfde sessie wordt gebruikt voor opeenvolgende vragen, daalt de round–trip tijd uiteraard sterk vanaf de tweede vraag.

Hier is immers geen DTLS–

handshake meer nodig. De mediaan voor de round–trip tijd vanaf de tweede vraag– en antwoordronde in dezelfde DTLS–sessie bedraagt 147,48 ms. Voor plain text CoAP bedroeg dit 143,21 ms. Er zijn dus ongeveer 4 ms extra nodig om de encryptie/decryptie uit te voeren op het constrained device in software (Figuur 4.12). Bovendien bevat het pakket een DTLS–header waardoor meer bytes worden verstuurd. 4. Packet overhead: Ten opzichte van plain text CoAP valt het op dat de pakketten die over een DTLS–sessie worden verstuurd veel groter zijn. In Figuur 4.14 is de grootte van het DTLS application data bericht weergegeven. Dit is te verwachten: er is een extra laag bijgekomen. De DTLS–header zorgt voor een extra overlast van 13 bytes. Dit is een grote last, wetende dat de CoAP ’GET Hello’–vraag slechts 12 bytes groot is. In Figuur 4.15 is de overhead van de DTLS–handshake visueel weergegeven. Het gedeelte “DTLS Application Data” in de figuur komt overeen met het vraag– en antwoordbericht uit Figuur 4.14. Deze handshake

4.4 Experimenten

61

Figuur 4.14: Packet overhead in een beveiligd CoAP–bericht.

Figuur 4.15: Overhead van de DTLS–handshake ten opzichte van de beveiligde nuttige data (vraag en antwoord).

neemt 1225 bytes in beslag, vooraleer beveiligde nuttige data kan worden verstuurd. Voor een vraag– en antwoordbericht (GET Hello) bedraagt de grootte van de nuttige data slechts 200 bytes. Dit is ongeveer 14 % van alle verstuurde bytes. Figuur 4.16 geeft de relatieve overhead van de DTLS–handshake weer, wanneer het aantal bytes nuttige data stijgt. Deze figuur bespreekt de overhead van de DTLS–handshake, er is ook nog overhead van de DTLS header in het application–data–bericht. Indien voor 4800 bytes aan application– data–berichten wordt verstuurd, bedraagt de relatieve overhead nog slechts 20 %, ten opzichte van 86 % voor een vraag– en antwoordbericht (GET Hello) van 200 bytes.

4.4 Experimenten

62

Figuur 4.16: Relatieve overhead van de DTLS–handshake bij stijgende grootte van de nuttige data.

4.4.3

Experiment 2: Terminatie DTLS op de gateway

Het tweede experiment bestaat uit een DTLS–client (Scandium) op een traditioneel toestel dat een CoAPS–bericht verstuurd naar een CoAP–server (Erbium) in het LLN. De gateway (Click) zal het DTLS-verkeer termineren. Daarna wordt het bericht ongeëncrypteerd doorgestuurd in het LLN. Uiteraard komt dit experiment, qua energiemetingen op het constrained device, exact overeen met de referentiecase plain text CoAP. Enkel de round–trip tijd is anders omdat in het Internet een DTLS–handshake moet worden uitgevoerd met de gateway. Dit experiment werd uitgevoerd om aan te tonen dat zware beveiliging in het LLN niet steeds noodzakelijk is. Soms is geen beveiliging nodig, of kan beveiliging op de linklaag kan in hardware worden uitgevoerd door de radio. Het is voor de client op het Internet zeer voordelig dat de cipher suite op het Internet los staat van de beveiliging in het LLN: hier kan een krachtigere cipher suite (met certificaten) worden toegepast. 1. Geheugenvereisten: Hier draait op het constrained device enkel de Erbium-server. Deze zijn dus identiek aan het geval waar onbeveiligde CoAP wordt verstuurd tussen client en server (sectie 4.4.1).

4.4 Experimenten

63

Pakketlengte [bytes]

Aantal fragmenten

ClientHello

158

2

ClientHelloVerify

93

1

ClientHello (with cookie)

174

3

ServerHello

111

2

Server Key Exchange

91

1

Server Hello Done

74

1

+ ClientFinished

165

2

ChangeCipherSpec

86

1

ServerFinished

102

1

Application Data

101/99

1

CloseNotify

91/80

1

ClientKeyExchange + ChangeCipherSpec

Tabel 4.3: Lengte van de DTLS–handshake berichten in het LLN. Application data bevat een beveiligde GET hello of het antwoord. Indien berichtlengte van elkaar verschilt (afkomstig van client of server) zijn beide aangegeven, gescheiden door een ’/’. 2. Round–trip tijd: De round–trip tijden zijn weergegeven in Figuur 4.13, reeks “DTLS Internet”. De DTLS– handshake wordt hier uitgevoerd met de gateway. Gemiddeld bedraagt deze 1310,31 ms. De grafiek toont een veel steilere helling ten opzichte van het geval waarbij de DTLS– handshake uitgevoerd wordt met het constrained device. Dit is logisch gezien de verbinding op het Internet veel beter is dan deze in het LLN. Bovendien is de gateway ook veel krachtiger dan het constrained device. Deze karakteristiek laat zich ook merken in de variantie: bij de DTLS–handshake met de gateway bedraagt deze slechts 26,91 ms. Voor de DTLS–handshake met het constrained device is dit 773,66 ms. 3. Energieverbruik: Het energieverbruik is uiteraard ook identiek aan het geval waar onbeveiligde CoAP wordt verstuurd tussen client en server (sectie 4.4.1). 4. Packet overhead: In het LLN is de packet overhead identiek aan deze uit sectie 4.4.1. Op het Internet is er

4.4 Experimenten

64

uiteraard wel de DTLS–overhead.

4.4.4

Experiment 3: Meerdere clients

Indien er meerdere clients DTLS willen spreken met het constrained device (end–to–end, zoals in sectie 4.4.2), wordt de last voor het constrained device nog groter. Elke client moet een DTLS– handshake uitvoeren met het constrained device, verschillende sleutels moeten worden bijgehouden, de buffers moeten meer berichten kunnen bevatten,... De voorgestelde oplossing in deze masterproef onderbreekt het DTLS–verkeer op de gateway, en maakt in het LLN gebruik van de DTLS-sessie tussen de gateway en het constrained device voor alle clients. Het constrained device hoeft nu maar één sessie te onderhouden voor verschillende partijen. Bovendien zorgt het optreden van gelijktijdige DTLS–handshakes, die kunnen voorkomen wanneer meerdere clients end– to–end willen communiceren met het constrained device, voor problemen in het LLN. Meestal lukt slechts één DTLS–handshake en start de rest van de DTLS–handshakes met retransmissie. Omdat het retransmissiemechanisme niet correct functioneert resulteert dit uiteindelijk in het mislukken van de DTLS–handshake. 1. Geheugenvereisten: Zoals hierboven besproken is het duidelijk dat de DTLS–server op het constrained device meer geheugen zal verbruiken indien meerdere clients moeten worden ondersteund. Concreet komt dit voor een extra client neer op 210 bytes ROM– en 1746 bytes RAM–geheugen (Tabel 4.4). Deze worden veroorzaakt door het bijhouden van meerdere sleutels, grotere buffers en het ondersteunen van gelijktijdige handshakes. Vanaf de ondersteuning van een derde client verhoogt enkel het vereiste RAM–geheugen telkens met 1,67 kB4 . Aantal clients

ROM–geheugen [kB]

RAM–geheugen [kB]

1

68,70

8,10

2

68,91

9,85

3

68,91

11,52

4

68,91

13,18

5

68,91

14,86

Tabel 4.4: Geheugenvereisten van de DTLS–server voor een aantal gelijktijdige clients. 4

Deze metingen werden bekomen via het commando msp430-size.

4.4 Experimenten

65

Indien wordt geopteerd voor de oplossing met terminatie op de gateway hoeft de DTLS– server op het constrained device slechts één sessie te onderhouden: deze met de gateway. Verschillende clients kunnen hiervan gebruikmaken. De geheugenvereisten zijn dan identiek aan deze uit sectie 4.4.2. 2. Energieverbruik: De energiemetingen komen overeen met deze van sectie 4.4.2 omtrent end–to–end DTLS. Uiteraard is het energieverbruik lineair afhankelijk van het aantal deelnemende clients.

Figuur 4.17: Totale energieverbruik van de DTLS–server bij meerdere clients indien al dan niet wordt getermineerd.

Indien wordt geopteerd voor de oplossing met terminatie op de gateway kan de tweede (en opeenvolgende) client(s) gebruikmaken van de reeds bestaande DTLS–sessie in het LLN. Dit zorgt voor heel wat energiebesparingen. Enkel het energieverbruik van de beveiligde data wordt nog aangerekend. Dit is weergegeven in Figuur 4.17: het geval waarbij elke client een GET hello verstuurt naar het constrained device via een eigen DTLS–sessie (“E2E DTLS”) en het geval waarbij alle clients in het LLN gebruikmaken van dezelfde DTLS–sessie tussen de gateway en het constrained device (“Terminatie”). 3. Round–trip tijd: De round–trip tijden bij terminatie zijn veel lager dan deze waarbij telkens een nieuwe verbinding moet worden opgezet voor elke client. Enkel het eerste bericht draagt de

4.4 Experimenten

66

Figuur 4.18: Cumulatieve round–trip tijd voor een client gebruikmakende van (a) “end–to– end”: eigen end-to-end DTLS–sessie met het constrained device (b) “terminatie 1e client”: eigen DTLS–sessie met de gateway en een nog op te zetten DTLS–sessie in het LLN tussen de gateway en het constrained device (c) “terminatie daaropvolgende clients”: eigen DTLS–sessie met de gateway en bestaande DTLS–sessie in het LLN.

last van het opzetten van twee DTLS–handshakes: tussen client en gateway, en tussen gateway en het constrained device. Daarna profiteren de clients van de reeds bestaande DTLS–sessie in het LLN. De mediaan (gemiddelde) van de round–trip tijden voor het eerste application data bericht bedraagt 2787,84 ms (3178,12 ms). Dit is het hoogste geobserveerde cijfer van alle experimenten, wat te verklaren is door het uitvoeren van twee DTLS–handshakes. De mediaan (gemiddelde) voor de daaropvolgende berichten bedraagt 191,43 (235,89) ms. Voor een client (en het constrained device) is het een groot voordeel om gebruik te maken van de reeds bestaande DTLS–sessie in het LLN. Maar na verloop van tijd wordt het voor de client toch performanter om zelf een DTLS–sessie op te zetten met het constrained device, indien deze HELLO resource regelmatig wordt opgevraagd. Na 12 aanvragen blijkt het, op vlak van delay, reeds voordeliger om zelf een DTLS–sessie op te zetten met het constrained device. Het opzetten van een DTLS–sessie met het constrained device is namelijk duurder dan het opzetten van een DTLS–sessie met de gateway, maar de DTLS–berichten die daarop volgen (en van bestaande sessies gebruikmaken) hebben een

4.5 Besluit

67

kleinere round–trip tijd dan bij het termineren van de DTLS–sessie op de gateway (Figuur 4.18). Dit is te wijten aan het encrypteren en decrypteren van het verkeer op de gateway. De plaats waar dit snijpunt optreedt in de grafiek is afhankelijk van de specificaties van de gateway. 4. Packet overhead: In dit scenario worden berichten verstuurd in het LLN die beveiligd worden door DTLS. Er treedt dus een identieke overlast op zoals in sectie 4.4.2.

4.5

Besluit

Logischerwijze is het versturen van onbeveilige CoAP–berichten de goedkoopste oplossing: zowel op vlak van energieverbruik en geheugenverbruik op het constrained device, als op het vlak van round–trip tijd. De reden is duidelijk: het constrained device hoeft geen DTLS–server te draaien, er hoeft geen DTLS–handshake worden uitgevoerd en er zit geen DTLS–laag in het te versturen pakket. DTLS kan worden toegepast tussen client en server, wat impliceert dat het constrained device over een DTLS–server moet beschikken. Dit brengt geheugenvereisten en extra energieverbruik met zich mee. Bovendien stijgt de round–trip tijd van het eerste bericht aanzienlijk wegens het uitvoeren van de DTLS–handshake. Wanneer meerdere clients in het verhaal stappen en herhaaldelijk communiceren met het constrained device, moet deze DTLS–server meerdere gelijktijdige DTLS–sessies ondersteunen. Dit zorgt voor een hoger ROM– en RAM–gebruik op het constrained device. Er worden dus ook meerdere DTLS–handshakes worden uitgevoerd door het constrained device, wat voor een hoger energieverbruik zorgt. De oplossing, die in dit onderzoek wordt voorgesteld, zorgt voor een lager geheugengebruik op het constrained device wegens het onderhouden van slechts één DTLS–sessie en het dalen van het energieverbruik door het uitvoeren van slechts een DTLS–handshake voor verschillende clients. Er zijn aan deze aanpak voor het constrained device dus twee grote voordelen verbonden. Voor de client echter is het performanter om zelf een DTLS–sessie op te zetten met het constrained device, wanneer er meerdere berichtuitwisselingen moeten gebeuren. De round–trip tijd is namelijk groter wanneer wordt getermineerd op de gateway. Dit is te wijten aan het encrypteren en decrypteren van het verkeer op de gateway.

CONCLUSIE

68

Hoofdstuk 5

Conclusie Beveiliging op het Internet is vandaag een zeer populair onderwerp. Ook in LLN’s is beveiligde communicatie uiterst belangrijk. Door het grote aantal constrained devices dat wordt ingezet, is vereist dat deze zeer goedkoop aan te schaffen zijn. Dit heeft zijn gevolgen voor de hardware: een constrained device beschikt over zeer beperkte rekencapaciteiten en een zwakke radio. Deze beperktheid vertaalt zich in grote uitdagingen wat betreft de toepasbaarheid van bestaande communicatieprotocollen in LLN’s: de huidige beveiligingsprotocollen vereisen te zware berekeningen voor de constrained devices. Het IETF, en meerbepaald de DICE–werkgroep heeft zijn voorkeur uitgesproken om DTLS te verkiezen boven IPsec om beveiligde communicatie te realiseren in LLN’s. Voor de meest beperkte constrained devices is het toepassen van DTLS nog steeds een zware klus: er moeten een aantal wijzigingen gebeuren aan het DTLS–protocol. Een aantal state–of–the–art onderzoeken gaat het protocol zelf aanpassen door compressie uit te voeren op de DTLS–handshakeberichten. In deze masterproef wordt aan de hand van een vertrouwde gateway gepoogd om beveiligde communicatie tussen een traditioneel toestel en een constrained device goedkoper te maken voor het constrained device. De vertrouwde gateway zet een langdurige DTLS–sessie op met het constrained device en gebruikt deze DTLS–sessie om verkeer voor verschillende clients op het Internet te beveiligen. Een nadeel van deze aanpak is dat het voor het constrained device lijkt alsof alle verkeer afkomstig is van de gateway. In realiteit zijn de CoAP–berichten afkomstig van meerdere clients. Op basis van metingen voor een aantal metrieken (packet overhead, round–trip tijd, energieverbruik en geheugenvereisten) in de Cooja netwerksimulator, is het besluit dat er aan deze aanpak inderdaad een aantal voordelen zijn voor het constrained device. Zo is het aantal DTLS–

CONCLUSIE

69

sessies beperkt tot één: deze met de gateway, terwijl er wordt gecommuniceerd met verschillende clients. Dit resulteert in een minimum vereist ROM– en RAM–geheugen voor de DTLS–server op het constrained device. Bovendien zorgt de langdurige DTLS–sessie met de gateway voor een klein aantal uit te voeren DTLS–handshakes. Elke handshake verspilt namelijk energie die niet besteed kan worden aan het uitwisselen van nuttige informatie. Voor de client is het grote voordeel dat deze gebruik kan maken van een reeds bestaande DTLS–sessie in het LLN. Indien er slechts een eenmalige vraag moet worden gestuurd naar het constrained device kan dit veel tijd uitsparen. De kans dat dit optreedt in realiteit is echter klein. Vaak wordt dezelfde operatie regelmatig herhaald. Het blijkt dat, indien dit het geval is, het constrained device voor een klein aantal aanvragen beter een eigen DTLS–sessie met het constrained device opzet. Vooral indien de client de enige communicerende partij is met het constrained device. Zoniet kunnen gelijktijdige DTLS–handshakes problemen veroorzaken in het LLN. Het termineren van het DTLS–verkeer op de gateway brengt namelijk wat vertraging met zich mee. Bovendien is het voor de client geen voordeel om een derde partij te laten deelnemen in zijn beveiligd communicatiekanaal. Hierbij gaat ook de end–to–end–semantiek verloren. Indien de gateway gecompromitteerd raakt, is het volledige verkeer zomaar te bekijken. Bovendien gaat dit niet over het verkeer naar één constrained device, maar naar alle nodes in het LLN. Een voordeel voor de client is de mogelijkheid om op het Internet een andere cipher suite (e.g. met certificaten) te gebruiken dan de gebruikelijke cipher suites in LLN’s met een gedeelde private sleutel. De gateway kan namelijk op het Internet een andere cipher suite gebruiken dan in het LLN. Voordelig voor het LLN is een aanpak waarbij de gateway het verkeer naar het LLN beperkt door bijvoorbeeld een cache met CoAP responses bij te houden. Dit is noch ge¨ımplementeerd, noch onderzocht in deze masterproef, maar het is interessant om in de toekomst na te gaan wat de impact hiervan is. We kunnen dus besluiten dat deze aanpak zijn doel heeft bereikt: beveiligde communicatie met een constrained device is gerealiseerd met een minimum aan kost. Zoals elk mechanisme heeft ook dit zijn voor– en nadelen. Er zijn nog heel wat onderzoeksmogelijkheden rond beveiliging in het Internet of Things. Het onderzoek in deze masterproef zorgt voor een nieuwe kijk op het gebruik van DTLS in LLN’s. Beveiliging brengt een grote kost met zich mee voor de constrained devices. Het onderzoek beperkt de inspanning in het LLN om beveiligde communicatie te voorzien. Er is echter nog heel wat onderzoek vereist naar de werking van het mechanisme indien:

CONCLUSIE

70

1. meerdere hops aanwezig zijn tussen de border router en de DTLS–server. 2. radio duty cycling wordt toegepast. 3. er een slechte link voorkomt. In dit onderzoek zijn de constrained devices enkel als server opgetreden in de communicatie. Verdere testen met de constrained devices als client zijn nog nodig. Daarnaast mag niet vergeten worden dat de meetresultaten weergegeven in deze masterproef bekomen zijn via metingen in een simulator. Het meten van de energie op echte constrained devices in een reële omgeving is noodzakelijk. Ten slotte kan het ook interessant zijn om na te gaan wat de impact is van een AES–versnellermodule in hardware om de encryptie– en decryptie–operaties uit te voeren.

RM090 MOTE

71

Bijlage A

RM090 mote RM090

1

is an ultra-low power wireless module for use in sensor networks, monitoring applica-

tions and rapid application prototyping. Industry standards like USB and IEEE 802.15.4 are used to interoperate seamlessly with other devices. With the onboard temperature and humidity sensors and the providing of flexible interconnection with peripherals, the RM090 enables a wide range of radio-network applications. The modules are programmable and support TinyOS.

A.1

Key Features

Based on Texas Instruments leading edge 802.15.4 Chipcon wireless transceiver (CC2520) and MSP430 (16k RAM, 256k Flash) technology Industry-leading 250 kps, 2.4 GHz performance in low power conservation and functionality. Interoperability with other 802.15.4 devices Utra Low Power consumption. Ideal for power-restricted or battery-operated applications Integrated boost convertor for Alkaline batteries USB powered, and 9V DC Configurable GPIO, ADC and Timers JTAG and USB/BSL programmable Onboard temperature and humidity sensors TinyOS support : mesh networking Integrated onboard antenna 50m range Indoors/ 125m outdoors

A.2

Technical Data

ADC, DIO, Serial, I2C, USB, JTAG Frequency 2400 2483,5 GHz Output Power Up to +3dBm Range 50m indoor, 125m outdoors RF Baudrate 250 kbps Memory 2x64kByte Flash, 2kByte EEPROM Internal Sensors NTC, SHT21 Storage temperature -40Cto +80C Antenna Integrated Inverted-F, External connector Power 9V DC, Battery, USB Approvals None 1

Bron: http://www.rmoni.com/en/products/hardware/rm090

A.2 Technical Data

72

Figuur A.1: RM090 blokdiagram.

Figuur A.2: RM090 blokdiagram.

Figuur A.3: RM090 in detail.

BIBLIOGRAFIE

73

Bibliografie [1] That Internet of Things Thing: In the real world, things matter more than ideas [Online. Last accessed: 03.05.2014]. http://kevinjashton.com/2009/06/22/the-internet-of-things/ [2] Johnaan W. Hui, Arch Rock Corporation, and David E. Culler. “IP is dead, long live IP for wireless sensor networks.”, in THE 6TH INTERNATIONAL CONFERENCE ON EMBEDDED NETWORKED SENSOR SYSTEMS (SENSYS’08), pages 15-28, ACM, 2008. [3] Adam Dunkels, Oliver Schmidt, Niclas Finne, Joakim Eriksson, Fredrik, “The Contiki OS The Operating System for the Internet of Things”, http://www.contiki-os.org/, Accessed November 2013. [4] T. Winter, JP. Vasseur, Cisco Systems, et al., “RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks”, IETF RFC 6550, March 2012. [5] Z. Shelby, Sensinode, K. Hartke, C. Bormann, Universitaet Bremen TZI, “Constrained Application Protocol (CoAP)”, draft-ietf-core-coap-18, June 2013. [6] T. Dierks and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, IETF RFC 5246, August 2008. [7] E. Rescorla, RTFM Inc. , N. Modadugu, Stanford University, “Datagram Transport Layer Security”, IETF RFC 4347, April 2006. [8] P. Wouters, H. Tschofenig, et al., “Using Raw Public Keys in TLS and DTLS”, draft-ietftls-oob-pubkey-11, January 2014. [9] C. Karlof, N. Sastry and D. Wagner, “TinySec: a link layer security architecture for wireless sensor networks.”, in Networks, pages 3:162-175, 2004. [10] L. Casado and P. Tsigas, “ContikiSec: A Secure Network Layer for Wireless Sensor Networks under the Contiki Operating System”, in Proceedings of the 14th Nordic Conference

BIBLIOGRAFIE

74

on Secure IT Systems: Identity and Privacy in the Internet Age, pages 133-147, SpringerVerlag, 2009. [11] S. Kent and K. Seo, “Security Architecture for the Internet Protocol”, in RFC 4301 (Proposed Standard), December 2005. http://www.ietf.org/rfc/rfc4303.txt [12] S. Kent, “IP Authentication Header”, in RFC 4302 (Proposed Standard), December 2005. http://www.ietf.org/rfc/rfc4302.txt [13] S. Kent, “IP Encapsulating Security Payload (ESP)”, in RFC 4303 (Proposed Standard), December 2005. http://www.ietf.org/rfc/rfc4303.txt [14] C. Kaufman, P. Hoffman, Y. Nir, and P. Eronen. tocol Version 2 (IKEv2)”,

“Internet Key Exchange Pro-

in RFC 5996 (Proposed Standard), September 2010.

http://www.ietf.org/rfc/rfc5996.txt [15] S. Raza, S. Duquennoy, T. Chung, D. Yazar , T. Voigt en U. Roedig. Securing Communication in 6LoWPAN with Compressed IPsec, in Proceedings of the 7th IEEE International Conference on Distributed Computing in Sensor Systems, Barcelona,2011. [16] Vipul Gupta et al., “Sizzle A standards-based end-to-end security architecture for the embedded internet.”, in In Pervasive Computing and Communications, pages 247-256, 2005. [17] Wooyoung Jung et al., “SSL-Based Lightweight Security of IP-Based Wireless Sensor Networks.”, in International Conference on Advanced Information Networking and Applications Workshops, pages 1112-1117, May 2009. [18] A. Gosai, B. Goswami, “Experimental Performance Testing of TCP and UDP Protocol over WLAN Standards, 802.11b and 802.11g”, in Karpagam Journal of Computer Science, Volume 07, Issue 03, March April 2013, pg. no. 168 to 183, ISSN 0976-2926 [19] Z. Shelby, Sensinode, K. Hartke, and C. Bormann, “Constrained Application Protocol (CoAP)”, in draft-ietf-core-coap-18, June 2013. https://datatracker.ietf.org/doc/draft-ietfcore-coap/ [20] S. Raza, D. Trabalza, and T. Voigt, “6LoWPAN Compressed DTLS for CoAP”, in Proceedings of the 8th IEEE International Conference on Distributed Computing in Sensor Systems, May 2012.

BIBLIOGRAFIE

75

[21] T. Kothmayr, C. Schmitt, W. Hu, M. Brunig and G. Carle, “A DTLS Based End-To-End Security Architecture for the Internet of Things with Two-Way Authentication”, in Local Computer Networks Workshops (LCN Workshops), 2012 IEEE 37th Conference on, 2012. [22] U. Blumenthal and B. Wijnen. “User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3).”, in RFC 3414 (Standard), December 2002. http://www.ietf.org/rfc/rfc3414.txt [23] S. Raza,

H. Shafagh,

O. Dupont.

Headers for Constrained Environments”,

“Compression of Record and Handshake in Active Internet-Draft, March 2014.

https://datatracker.ietf.org/doc/draft-raza-dice-compressed-dtls/ [24] L. Schmertmann, K. Hartke, C. Bormann. “CoDTLS: DTLS handshakes over CoAP.”, in Active Internet-Draft, February 2014. https://datatracker.ietf.org/doc/draft-schmertmanndice-codtls/ [25] S. Keoh, S.S. Kumar, Z. Shelby. “Profiling of DTLS for CoAP-based IoT Applications.”, in Active Internet-Draft, November 2013. https://datatracker.ietf.org/doc/draft-keoh-dicedtls-profile-iot/ [26] K. Hartke, H. Tschofenig. “A DTLS 1.2 Profile for The Internet of Things.”, in Active Internet-Draft, February 2014. https://datatracker.ietf.org/doc/draft-hartke-dice-profile/ [27] S. Raza, H Shafagh, K. Hewage, R. Hummen, and T. Voigt “Lithe: Lightweight Secure CoAP for the Internet of Things”, in IEEE SENSORS JOURNAL, VOL. 13, NO. 10, oct 2013. [28] R. Hummen, H. Shafagh, et al. “Delegation-based Authentication and Authorization for the IP-based Internet of Things”, in 11th IEEE International Conference on Sensor, Communication, and Networking (SECON 2014), Singapore, Publisher: IEEE, June 2014. [29] A. Dunkels, F. Osterlind, N. Tsiftes, Z. He. “Software-based On-line Energy Estimation for Sensor Nodes”, in EmNets 07, June 25-26, 2007, Cork, Ireland. [30] O. Younis and S. Fahmy. “An experimental study of routing and data aggregation in sensor networks”, in Proceedings of the IEEE International Workshop on Localized Communication and Topology Protocols for Ad Hoc Networks (IEEE LOCAN), Washington, DC, USA, November 2005.

BIBLIOGRAFIE

76

[31] R. Bonetto, N. Bui, V. Lakkundi , A. Olivereau, A. Serbanati and M. Rossi, “Secure Communication for Smart IoT Objects: Protocol Stacks, Use Cases and Practical Examples”, in World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2012 IEEE International Symposium, San Francisco, CA, 2012. [32] R. Hummen, T. Heer, and K. Wehrle “A Security Protocol Adaptation Layer for the IP-based Internet of Things” [33] TinyDTLS

Documentation

[Online.

Last

accessed:

02.04.2014].

[Online.

Last

accessed:

28.04.2014].

http://tinydtls.sourceforge.net/ [34] Embedded

SSL

Library

http://www.yassl.com/yaSSL/Home.html [35] The

Click

Modular

Router

Project

[Online.

Last

accessed:

06.05.2014].

http://read.cs.ucla.edu/click/click [36] GitHub:

Californium

[Online.

Last

accessed:

28.04.2014].

accessed:

28.04.2014].

https://github.com/mkovatsc/Californium [37] GitHub:

Scandium

[Online.

Last

https://github.com/mkovatsc/Scandium ¨ [38] F. Osterlind, “A sensor network simulator for the Contiki OS”, February 2006. [39] GCC

toolchain

for

MSP430.

[Online.

Last

accessed:

02.04.2014].

http://sourceforge.net/projects/mspgcc/ [40] Texas Instruments: MSP430 Ultra-Low Power 16-Bit Microcontrollers. [Online. Last accessed: 02.04.2014]. http://www.ti.com/msp430 [41] MSP430F543x, MSP430F541x Mixed Signal Microcontroller.

[Online. Last accessed:

02.04.2014]. http://www.ti.com/lit/ds/symlink/msp430f5436.pdf [42] cc2250

data

sheet

[Online.

Last

accessed:

02.04.2014].

http://www.ti.com/lit/ds/symlink/cc2520.pdf [43] Wireshark

network

monitoring

http://www.wireshark.org/

tool

[Online.

Last

accessed:

02.04.2014].

LIJST VAN FIGUREN

77

Lijst van figuren 2.1

Wireless Sensor and Actuator Network (WSAN). . . . . . . . . . . . . . . . . . .

5

2.2

Constrained devices: een mogelijke netwerkprotocolstack. . . . . . . . . . . . . .

7

2.3

Het CoAP–berichtenformaat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.4

TLS-protocol: gelaagde structuur bovenop TCP. . . . . . . . . . . . . . . . . . .

10

2.5

TLS-protocol: een eenvoudige handshake waar de server zich authenticeert aan de hand van een certificaat. Dit scenario komt typisch voor bij beveiligde communicatie met een web server. De pijlen stellen vluchten voor, die soms meerdere berichten groeperen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.6

DTLS–pakketformaat van een ClientHello–bericht. . . . . . . . . . . . . . . . . .

13

2.7

DTLS-protocol: een eenvoudige handshake op basis van vooraf uitgewisselde sleutels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.8

Advanced Encryption Standard (AES) in CCM–mode.

17

3.1

Communicatie tussen een traditioneel toestel (links) en een constrained device

. . . . . . . . . . . . . .

(rechts). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.2

Tussen de client en server worden onbeveiligde CoAP–berichten verstuurd. . . . .

27

3.3

De communicatie tussen de client en server wordt van begin tot einde beveiligd aan de hand van DTLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4

28

De gateway breekt de DTLS-sessie met de client af en maakt gebruik van een langdurige DTLS-sessie voor alle clients in het Internet die met dezelfde server in het LLN communiceren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5

De DTLS-sessie wordt afgebroken op de gateway, waarna telkenmale een nieuwe sessie wordt opgezet en afgesloten per client. . . . . . . . . . . . . . . . . . . . . .

3.6

29

29

De DTLS-sessie wordt afgebroken op de gateway, waarna de communicatie onbeveiligd gebeurt in het LLN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

LIJST VAN FIGUREN

3.7

78

Het DTLS-verkeer wordt afgebroken op de gateway, waarna het wordt doorgestuurd in het LLN met beveiliging op de linklaag. . . . . . . . . . . . . . . . .

30

3.8

Werking van het DTLSState–element. . . . . . . . . . . . . . . . . . . . . . . . .

36

3.9

Algemene werking van het DTLSModule–element. . . . . . . . . . . . . . . . . .

37

3.10 Aanpassing van het IPv6–adres in het LLN om de gedeelde DTLS–sessie mogelijk te maken. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

3.11 De rol van de hulpklassen ten opzichte van het DTLSModule–element in de Click router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

3.12 Click router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

4.1

De netwerkomgeving in de Cooja netwerksimulator . . . . . . . . . . . . . . . . .

47

4.2

RM090 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.3

Een CoAP–GET–vraag met antwoord. . . . . . . . . . . . . . . . . . . . . . . . .

52

4.4

Energieverbuik op een RM090 bij ontvangen/beantwoorden van een GET hello. De waarde voor de ontvangstenergie is exclusief idle listening. . . . . . . . . . . .

4.5

53

Cumulatieve distributiefunctie van de round–trip tijd bij een onbeveiligd CoAP– vraagbericht. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

4.6

Packet overhead in een plain text CoAP–bericht. . . . . . . . . . . . . . . . . . .

54

4.7

Energieverbuik op een RM090 bij ontvangen/beantwoorden van een (on)beveiligde CoAP–vraag (GET hello). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.8

Het energieverbruik van idle listening versus het effectief ontvangen van pakketten tijdens een DTLS–handshake en een CoAP–request/response.

4.9

56

. . . . . . . . . .

Relatief MCU–energieverbruik van de DTLS–handshakeberichten.

. . . . . . . .

57 58

4.10 Relatief radio–energieverbruik bij het ontvangen van de DTLS–handshakeberichten. 58 4.11 Relatief radio–energieverbruik bij het versturen van de DTLS–handshakeberichten. 58 4.12 Cumulatieve distributiefunctie van de round–trip tijd bij een onbeveiligd CoAP– vraagbericht versus beveiligde CoAP (zonder DTLS–handshake). . . . . . . . . .

59

4.13 Cumulatieve distributiefunctie van de round-trip tijd voor een beveiligde CoAP– vraag/antwoord met DTLS–handshake. DTLS–handshake met de gateway versus het constrained device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

4.14 Packet overhead in een beveiligd CoAP–bericht. . . . . . . . . . . . . . . . . . . .

61

LIJST VAN FIGUREN

79

4.15 Overhead van de DTLS–handshake ten opzichte van de beveiligde nuttige data (vraag en antwoord). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

4.16 Relatieve overhead van de DTLS–handshake bij stijgende grootte van de nuttige data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

4.17 Totale energieverbruik van de DTLS–server bij meerdere clients indien al dan niet wordt getermineerd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

4.18 Cumulatieve round–trip tijd voor een client gebruikmakende van (a) “end–to– end”: eigen end-to-end DTLS–sessie met het constrained device (b) “terminatie 1e client”: eigen DTLS–sessie met de gateway en een nog op te zetten DTLS– sessie in het LLN tussen de gateway en het constrained device (c) “terminatie daaropvolgende clients”: eigen DTLS–sessie met de gateway en bestaande DTLS– sessie in het LLN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

A.1 RM090 blokdiagram.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

A.2 RM090 blokdiagram.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

A.3 RM090 in detail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

LIJST VAN TABELLEN

80

Lijst van tabellen 4.1

Stroomverbruik van de radio en processor in de RM090. . . . . . . . . . . . . . .

51

4.2

Geheugenvereisten van de CoAP– en DTLS–server. . . . . . . . . . . . . . . . . .

53

4.3

Lengte van de DTLS–handshake berichten in het LLN. Application data bevat een beveiligde GET hello of het antwoord. Indien berichtlengte van elkaar verschilt

4.4

(afkomstig van client of server) zijn beide aangegeven, gescheiden door een ’/’. .

63

Geheugenvereisten van de DTLS–server voor een aantal gelijktijdige clients. . . .

64

Veilige communicatie in het Internet of Things via een vertrouwde gateway

Recommend Documents