Simple Keys for Simple Smart Objects

During recent years, a working infrastructure for the Internet of Things (IoT, [1]) has evolved. This eco-system of networked devices is based on inexpensive but powerful hardware: microcontroller chips with low-power RF transmitters for licensefree frequency bands, sufficient memory, and enough I/O ports to attach sensors and actuators. Moreover, various technical bodies have cooperated to foster open standards for machineto-machine (M2M) communication between devices. Besides the basic communication infrastructure, foundations were laid to make objects smart, i. e. to create self-describing services that are offered by identifiable entities and use common data formats. Like every node in a network, interconnected Smart Objects are susceptible to various threats, accentuated here by the special characteristics of wireless sensor networks (WSNs). As the nodes communicate wirelessly, conversations can easily be eavesdropped on, and fake messages can be injected into the network. Moreover, in many scenarios nodes are installed in places where physical access is easy. Thus, nodes may be damaged or captured. Therefore, specific attention must be given to protecting Smart Objects from attacks against data confidentiality, integrity, and service availability. However, common security measures are not easily applicable to Smart Objects due to the constrained nature of the nodes. The memory of many devices, RAM as well as Flash memory (code space), is restricted. To gain a rough but usable terminology, Bormann clusters the large variety of devices into two groups of interest to this discussion [2]: Class 1 devices have a data (RAM) size of about 10 KiB and a code (Flash) size of about 100 KiB, whereas class 2 devices possess a data size of about 50 KiB and a code size of about 250 KiB. The computational power of devices in most cases is limited by CPU clock rates of less than 25 MHz. Operating system support is often limited, e. g. no process scheduling is provided, so only one process at a time can run on each device. The achievable goodput within the network depends on the state of the wireless medium but has a low upper bound such as 250 kbit/s, the bit rate IEEE 802.15.4 chose in order to save energy. Most importantly, Smart Objects are often installed where they cannot easily be supplied with power and therefore run on primary batteries. Because of these limitations, protection of Smart Objects against attacks is not easy to accomplish. Encryption mechanisms that have been used in other Internet-enabled environments to protect sensitive data often severely stress the abilities of the small devices. For instance, public-key cryptography requires a good amount of processing power and memory. (The way it has been used on the Web, it also needs a working certificate infrastructure to validate the peer’s identity; it is not clear how such infrastructures will evolve for the requirements of the Smart Object space.) Smart Object security will not come about by blindly copying the approaches that so far have worked in the “Big Things Internet”. It is, however, also not necessary to reinvent the entire area of security for Smart Objects. The objective of our work is to obtain credible Smart Object security at a reasonable cost, which includes cost of design and deployment and therefore profits from re-using as many proven components of Internet technology as reasonably possible. If the devices are simple, there is an even stronger requirement for simplicity on the usability side. The integrity of the life-savings of an individual are not going to be in danger when their neighbor manages to switch one of their lamps on and off. Still, some level of security is advised, and this is more likely to actually be deployed and used correctly if it can be made to work in simple steps. The most important attack scenario to be prevented in these environments is one of low-effort remote takeover of a large mass of Smart Objects.

[1]  Frank Stajano,et al.  The Resurrecting Duckling: Security Issues for Ad-hoc Wireless Networks , 1999, Security Protocols Workshop.

[2]  Frank Stajano,et al.  The Resurrecting Duckling: security issues for ubiquitous computing , 2002, S&P 2002.

[3]  Adam Dunkels,et al.  Contiki - a lightweight and flexible operating system for tiny networked sensors , 2004, 29th Annual IEEE International Conference on Local Computer Networks.

[4]  Robert Richards,et al.  Representational State Transfer (REST) , 2006 .

[5]  David A. McGrew,et al.  An Interface and Algorithms for Authenticated Encryption , 2008, RFC.

[6]  Mukesh Singhal,et al.  Security in wireless sensor networks , 2008, Wirel. Commun. Mob. Comput..

[7]  Joseph Salowey,et al.  AES-GCM Cipher Suites for TLS , 2008 .

[8]  Behcet Sarikaya,et al.  Security Bootstrapping of Resource-Constrained Devices , 2010 .

[9]  Jari Arkko,et al.  CoAP Security Architecture , 2011 .

[10]  Salvatore Loreto,et al.  Implementing Tiny COAP Sensors , 2011 .

[11]  K. Kuladinithi,et al.  Implementation of CoAP and its Application in Transport Logistics , 2011 .

[12]  Hannes Tschofenig,et al.  TLS out-of-band public key validation , 2011 .

[13]  Eric Rescorla,et al.  Datagram Transport Layer Security Version 1.2 , 2012, RFC.

[14]  Carsten Bormann,et al.  Secure bootstrapping of nodes in a CoAP network , 2012, 2012 IEEE Wireless Communications and Networking Conference Workshops (WCNCW).

[15]  Carsten Bormann CoRE Simple Server Discovery , 2012 .

[16]  Carsten Bormann Guidance for Light-Weight Implementations of the Internet Protocol Suite , 2012 .

[17]  Oscar Garcia-Morchon,et al.  Security Considerations in the IP-based Internet of Things , 2013 .

[18]  Carsten Bormann,et al.  The Constrained Application Protocol (CoAP) , 2014, RFC.