Securing the internet of things with DTLS.

Abstract

Usecases for wireless sensor networks, such as building automation or patient care, often collect and transmit sensitive information. Yet, many deployments currently do not protect this data through suitable security schemes. We propose an end-to-end security scheme build upon existing internet standards, specifically the Datagram Transport Layer Security protocol (DTLS). By relying on an established standard existing implementations, engineering techniques and security infrastructure can be reused which enables easy security uptake. We present a system architecture for this scheme and show its feasibility through the evaluation of our implementation.

Full text

Page 1

Securing the Internet of Things with DTLS
Thomas Kothmayr1, Wen Hu2, Corinna Schmitt1, Michael Br¨ unig2, Georg Carle1
1Department of Computer Science, Chair for Network Architectures and Services, Technische Universit¨ at M¨ unchen, Germany
2CSIRO ICT Centre, Australia
kothmayr@in.tum.de, {schmitt, carle}@net.in.tum.de, {wen.hu, michael.bruenig}@csiro.au
Abstract
Usecases for wireless sensor networks, such as building
automation or patient care, often collect and transmit sensi-
tive information. Yet, many deployments currently do not
protect this data through suitable security schemes. We pro-
pose an end-to-end security scheme build upon existing in-
ternet standards, specifically the Datagram Transport Layer
Security protocol (DTLS). By relying on an established stan-
dard existing implementations, engineering techniques and
security infrastructure can be reused which enables easy se-
curity uptake.We present a system architecture for this
scheme and show its feasibility through the evaluation of our
implementation.
Categories and Subject Descriptors
J.7 [Computer Applications]: Computers in Other Sys-
tems
General Terms
Design, Standardization
Keywords
Wireless Sensor Network (WSN), DTLS, Security
1 Introduction
After the standardization of the physical and MAC layer
(IEEE 802.15.4) as well as the routing (6LoWPAN RPL) and
application layer (CoAP) for the Internet of Things, an ef-
fort to standardize security follows naturally. In the internet,
security is often achieved through the Transport Layer Se-
curity protocol (TLS). However, it requires reliable messag-
ing and is therefore not suited to lossy low power networks.
An alternative that is built upon datagram semantics exists in
the Datagram Transport Layer Security (DTLS) protocol [3]
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. To copy otherwise, to republish, to post on servers or to redistribute
to lists, requires prior specific permission and/or a fee.
SenSys’11, November 1–4, 2011, Seattle, WA, USA.
Copyright 2011 ACM XXX-X-XXXXX-XXX-X ...$5.00
which we propose as a basis for the standardization of an
end-to-end security scheme in the Internet of Things.
2 Hardware
We rely on the RSA algorithm to secure the key ex-
change.Previous work has shown RSA to be infeasible
for deployment on sensor nodes when implemented in soft-
ware [1]. Hu et al. presented a sensor node platform called
secfleck which uses a Trusted Platform Module (TPM) as a
cryptographic accelerator for RSA operations [1]. We use
the successor of secfleck, which features an Atmel Cortex
SAM3U4E micro controller at 48 MHz and an integrated At-
mel AT97SC3203S TPM for our purposes [2]. A TPM offers
the unique benefit of physical tamper resistance, meaning an
attacker cannot gain knowledge about the keys stored in the
TPM even if physical access is possible. Furthermore the
TPM acts as a hardware accelerator for RSA operations and
as a unique source of identity based on the RSA keypair gen-
erated within the TPM.
3Datagram Transport Layer Security
DTLS is an adaption of TLS for datagram based com-
munication which provides equivalent security guarantees.
Figure 1 shows a client authenticated handshake as defined
by DTLS and supported in our implementation.
Server
Client
(Sensor Mote)
ClientHello
HelloVerifyRequest
ClientHello
ServerHello, Certificate, CertificateRequest,
ServerHelloDone
Certificate, CertificateVerify, ClientKeyExchange,
[ChangeCipherSpec], Finished
[ChangeCipherSpec],
Finished
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Figure 1. Client authenticated DTLS Handshake
The modifications made to TLS mostly consist of adding
explicit sequence numbers to the messages and the introduc-
tion of retransmission timers during the handshake. This en-
ables implementations to handle message loss and reorder-

Page 2

ing during the handshake phase of the protocol. DTLS only
allows block ciphers for encryption because stream ciphers,
which are also allowed by TLS, are not randomly accessible
and thus unsuitable for datagram transport.
4System Architecture
IPv6
Data Sink
Mobile
Device
Access
Ticket
Certificate
Base
Station
Internet
Access Control
Server
Data
Flow
Communica-
tion Link
Figure 2. System Architecture
Figure 2 illustrates our architecture which is built around
the usage of DTLS as security protocol. Every mote estab-
lishes a secured connection with the Data Sink after booting.
Both the sensor node and the Data Sink are authenticated: If
the mote supports hardware acceleration of RSA operations
this is achieved by using TLS’ RSA key exchange algorithm.
During the handshake certificates signed by a trusted Certifi-
cate Authority which contain the mote’s and server’s RSA
public key are exchanged. If a mote is incapable of perform-
ing RSA operations it is authenticated via a modification of
the TLS Pre Shared Key algorithm. This means every mote
supports one form of the DTLS handshake.
5 Evaluation
We have implemented a prototype that supports a client
and server authenticated DTLS handshake as a proof of con-
cept. On the server side we use OpenSSL 1.0.0d with minor
modifications: The padding for RSA signature verification
has been changed from PKCS#1 version 1.5 to version 2 and
the Client only has to sign a SHA1 hash instead of the con-
catenation of a MD5 and SHA1 hash. These changes were
necessary to maintain compatibility with the TPM hardware.
We also introduced a 500ms delay between sending two
handshake packets from the DTLS server to avoid flooding
the sensor mote with data.
1024 bit
Drop RateMin. Avg. Max.
0%5,7895,8515,938
5% 5,83516,435 27,592
10% 11,04551,973171,925
Table 1. Connection latency over a lossy link (ms)
Table 1 shows the average time over ten measurements
that was needed to establish a DTLS connection when using
1024 and 2048 bit RSA keys for the server and Certificate
Authority X.509 certificates. The column ”drop rate” speci-
fies the chance for a packet to be lost in the link layer. Lost
packets result in all information from the current step being
Secure Com-
munication
Cluster
Head
Sensor
Node
Certificate
Authority
2048 bit
Avg.
6,949
26,945
37,386
Min.
6,861
16,600
21,706
Max.
7,065
39,680
52,443
retransmitted so that the receiver has a chance to reconstruct
it. We use BLIP as the routing protocol which leaves 100
byte of payload in each 802.15.4 packet. This results in 14
and 18 packets being sent for step 4 (size 1,311 byte) and
5 (1,794 byte) with 1024 bit RSA key length and 19 and
24 packets for step 4 (size 1,835 bytes) and 5 (2,337 bytes)
with 2048 bit RSA keys respectively. Measurements have
been conducted with a retransmission time of 5 seconds and
a Maximum Transmission Unit (MTU) of 500 byte for both
the server and sensor node. The measurements show that
smaller packets due to smaller key sizes generally lead to a
decrease in latency. The outlier at 10% packet loss with 1024
bit keys was caused by the finished message from the server
being lost twice. With our current toolchain this inevitably
leads to a timeout and restart for the handshake, causing a
very large latency of over 170 seconds in that particular case.
Overall, the figures show that even a relatively small percent-
age of lost packets leads to a significant increase in retrans-
missions and latency.
Current (mA)
11.4
18
57.6
49.4
59.8
57
57.6
Time (ms)
49
350
880
730
120
43
875
Energy (mJ)
2.1
23.8
191
136
27
9.2
190
579 mJ
Computation
Radio TX
TPM Start
TPM TWI Bus
TPM Verify
TPM Encrypt
TPM Sign
Total
Table 2. Energy usage breakdown
The energy consumption of a successful handshake with
2048-bit RSA keys and without packet loss is shown in Ta-
ble 2. The computation energy is the amount of energy spent
for parsing the received certificates, hashing each handshake
message and computing the HMAC for the last message as
well as encrypting it. Radio transmission includes the stan-
dard TinyOS CSMA channel access. The overall energy us-
age proves that this is a feasible key exchange method: Our
motes are powered by 3.7 V battery pack rated at 6600 mAh.
Intotalitstores87,900J,meaningamotecouldperformover
150,000 key exchange operations on one battery charge.
6Conclusion and Future Work
Our prototype implementation has shown a DTLS Hand-
shake with strong security parameters is feasible for key es-
tablishment in the Internet of Things. Future work will focus
on an efficient scheme for key renegotiation and reducing the
size ofcertificate messages and/orthe sensitivity tolink layer
packet loss.
7 References
[1] W. Hu, P. Corke, W. Shih, and L. Overs. secfleck: A public
key technology platform for wireless sensor networks. Wireless
Sensor Networks, pages 296–311, 2009.
[2] W. Hu, B. Kusy, C. Richter, M. Br¨ unig, and C. Huynh. Demo
abstract: Radio-diversity collection tree protocol.
2011.
[3] E. Rescorla and N. Modadugu. Rfc4347: Datagram transport
layer security. IETF, Request For Comments, 2006.
In IPSN,

Page 3

Securing the Internet of Things with DTLS
ACM SenSys
Nov 2011
Thomas Kothmayr, Corinna Schmitt, Georg Carle
Technische Universität München, Munich, Germany
kothmayr@in.tum.de, [schmitt, carle]@net.in.tum.de
Wen Hu, Michael Brünig
CSIRO ICT Centre, Brsibane, Australia
[Wen.Hu, Michael.Bruenig]@csiro.au
Energy Cost
System Architecture
DTLS Handshake
MotivationHardware
Latency
Conclusion
Handshake protected by 2,048-bit RSA:
579 mJ spent in total
More than 15,000 key exchanges on one AA NiMH battery (2100mAh)
Chart shows the average latency
over ten DTLS Handshakes
Retransmission timer 5s
Timeout 60s
MTU 500 byte
Steps 4 and 5 of the handshake
require large packets
1,311 & 1,794 bytes for
1,024-bit RSA Keys
1,835 & 2,337 bytes for
2,048-bit RSA Keys
1000
750
500
250
0
250
187.5
125
72.5
0
Time (ms)
Energy (mJ)
49 ms
2.1 mJ
350 ms
23.8 mJ
880 ms
730 ms
875 ms
190 mJ
191 mJ
136 mJ
Computation
Radio TX
TPM Start
TPM TWI Bus
TPM Verify
TPM Encrypt
TPM Sign
120 ms
27 mJ
43 ms
9.2 mJ
60
0%5%
10%
45
30
15
0
Avg. Latency (s)
5.9 s
6.9 s
16.4 s
26.9 s
37.4 s
52.0 s
IPv6
Data Sink
Mobile
Device
Access
Ticket
Certificate
Base
Station
Internet
Access Control
Server
Data
Flow
Communica-
tion Link
Secure Com-
munication
Cluster
Head
Sensor
Node
Certificate
Authority
Many Usecases for Wireless Sensor Networks involve collection and transmission
of sensitive data
E.g building automation, medical applications, metering, etc..
Standardization for other layers in network stack progressing
Physical & MAC: IEEE 802.15.4
Routing & Transport: 6LoWPAN, RPL
Application: CoAP (Constrained Application Protocol)
Standardized security based on existing internet protocols offers many benefits
Established security engineering practices
Reuse of existing infrastructure (e.g. Certificate Authorities)
Reuse of existing implementations (e.g. OpenSSL, GnuTLS, etc..)
à Increased security uptake
Sensornode with embedded Trusted Platform
Module (TPM)
Atmel SAM3U Microcontroller, 48 MHz
50 kB SRAM
AT97SC3203S TPM
TPM has tangible security benefits
Tamper proof storage of RSA-Keys
Hardwaresupport for RSA Operations
Unique Identity (asymmetric key-pair)
Security based on Datagram Transport Layer Security
protocol (DTLS)
Data protected from data source to sink
Confidentiality, integrity and authenticity
guaranteed through protocol
Multiple levels of security
RSA capable devices authenticated via X.509
certificates during key exchange
Constrained devices perform variant of TLS Pre
Shared Key algorithm
Data Sink authenticated via certificate either
directly with the mote or with Access Control Server
Motes organized in Clusters with common key to
enable in-network aggregation
Peer-To-Peer Communication supported
Access Control Server grants Tickets to
authenticated devices with sufficient rights
Device requests conection from
communication partner, key establishment
based on DTLS
à Device level access control
Application layer security protocol
Drawbacks: routing information unprotected,
potential for DOS Attacks
Benefits: Only need keys for Data consumers
instead of all neighbours, packet routing
without additional decryption overhead,
untrusted devices can still forward data
RSA Keys:
1024 bit
2048 bit
Link layer packet loss rate (%)
A Client and Server authenticated DTLS Handshake for WSNs is feasible
TPM consumes most of the energy, but necessary for RSA
Connection latency sensitive to lost packets, but only leads to major
increase in energy usage if handshake times out and TPM operations have
to be performed again
Future work
Efficient key renegotiation
Reducing message size or improving retransmission scheme à Handshake
timeouts become less likely
Implementing pre shared key algorithm for contrained devices
Server
Sensor Mote
ClientHello
HelloVerifyRequest
ClientHello
ServerHello, Certificate, CertificateRequest,
ServerHelloDone
Certificate, CertificateVerify, ClientKeyExchange,
[ChangeCipherSpec], Finished
[ChangeCipherSpec],
Finished
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
*
*Caused by lost „finished“ messages from server à Handshake times out and is restarted