8.2.1 Lightweight Formats for Cryptosecurity Protocols

Since many IoT devices are expected to be resource constrained, there is the need to provide security services in a particularly efficient way, and hence reduce the amount of information to be stored, transmitted, and processed. This means that not only plain application-level content, but also encrypted content, digital signatures, and even cryptographic keys are required to be represented and encoded in a compact and efficient way.

To this end, CBOR Object Signing and Encryption (COSE) aims at creating cryptographic formats based on Concise Binary Object Representation (CBOR) (Bormann and Hoffman, 2013). CBOR is a succinct binary format for the serialization of data structures, suitable for resource-constrained devices (Bormann et al., 2014). A major share of envisioned billions of IoT devices will consist of battery-powered or energy-harvested devices. For these IoT devices, COSE has a huge potential to produce lightweight CBOR-based representations of cryptographic keys, encryption, message hashes, and digital signatures.

COSE is inspired by JavaScript Object Signing and Encryption (JOSE) that has already standardized cryptographic formats using JavaScript. Although COSE tries to reuse functionalities from JOSE, they are not directly compatible for straightforward adoption. One of the major differences that CBOR brings compared with JOSE is the direct use of binary data format with no need to first convert it into, for example, a string encoded in base64. The CBOR Encoded Message Syntax details the basic COSE structure and common COSE headers (Schaad, 2017). Furthermore, it elaborates the COSE objects by means of dedicated cryptographic key materials, as well as through cryptoalgorithms for data encryption/authentication and for computation of Message Authentication Codes (MACs). There already exist proposals for encoding parameters, keys and outcomes of RSA (Jones, 2017), and other algorithms (Schaad, 2016) as COSE messages. Also, lightweight COSE representation of cryptographic data structures and their implementation and evaluation, when compared with JOSE, could be an interesting research topic.

8.2.2 CoAP and DTLS

CoAP is a novel web transfer protocol especially designed for resource-constrained devices and networks. It relies on request/response interactions between endpoints and can easily integrate with the widely adopted Hyper Text Transfer Protocol (HTTP) for integration with the classical Web (Fielding and Reschke, 2014a, 2014b). Although the CoAP protocol has been designed for constrained devices and networks (Bormann et al., 2014), on the other hand it does not provide itself any particular primitives to secure communication (Shelby et al., 2014). Instead, CoAP messages can be protected either by means of object security, as discussed in Section 8.2.3 or through actual secure communication protocols. In such a case, the CoAP specification recommends to adopt the DTLS protocol (Rescorla and Modadugu, 2012). In particular, Shelby et al. (2014) specify the CoAP binding to DTLS as a set of deltas to plain unsecure CoAP. From a practical perspective, if a CoAP message is secured using DTLS, the coaps://URL scheme is considered, rather than the coap://scheme for unsecure communication. In particular, the three security modes PreSharedKey, RawPublicKey, and Certificate are available. That is, the PreSharedKey mode relies on preshared cryptographic keys, each of which include a list of devices allowed to use that key for secure communication. If the RawPublicKey is considered, a device owns a pair of asymmetric private–public keys with no associated certificate, hence entrusting validation to out-of-band mechanisms. In addition, the device maintains an identity computed from the public key, as well as a list of devices it is allowed to communicate with. Finally, in case it considers the Certificate mode, a device stores an asymmetric private–public key pair, together with an X.509 certificate. The certificate binds the public key to its subject, and includes a digital signature from a well-known trust root (Cooper et al., 2008). In particular, the device additionally maintains a list of root trust anchors, which can be referred to in case certificate validation has to be performed.

Practically, DTLS allows two devices to establish a security association, authenticate with one another, and exchange protected CoAP messages. The Internet Engineering Task Force (IETF) has recently released a profile for Transport Layer Security (TLS) and DTLS 1.2. The profile provides communication security for resource-constrained devices employed for collecting data by means of sensors or for controlling actuators in applications for industrial control systems, home automation, smart cities, and other IoT deployments (Tschofenig and Fossati, 2016).

DTLS has been voluntarily conceived to be very similar to the TLS protocol (Dierks and Rescorla, 2008), and in fact fulfills equivalent security requirements. That is, it makes it possible for applications running on clients and server units to exchange secure messages, namely, DTLS records, especially preventing tampering, forgery, and eavesdropping of such messages. At the same time, DTLS displays a number of differences compared to TLS, so making it possible to provide secure message exchange on top of UDP and other unreliable datagram transport protocols. For instance, RC4 and other stream ciphers are not allowed to be used. Besides, a sequence number value is explicitly included in each DTLS message. So doing, DTLS messages result to be not related with one another, thus making it possible for recipients to correctly process them, even when out-of-sequence delivery occurs. Furthermore, DTLS addresses packet loss through message retransmission and local timeouts. Upon the reception of an invalid message, the related DTLS session may still be preserved, and that message can simply be silently discarded.

In order to exchange protected messages over DTLS, two client and server devices perform a handshake process in order to establish a secure session, as depicted in Figure 8.2. Handshake messages transmitted at a same step are grouped together as part of one DTLS Flight. Optional or situation-dependent messages are indicated in square brackets and not always sent.

The client typically takes the initiative and sends a ClientHello message to the server in order to start establishing the DTLS session. DTLS admits a stateless cookie value that can be optionally exchanged between the server and the client by means of Fligth2 and Flight3, with the intent to address DoS against the server. Then, client and server exchange Flight4 and Flight5 in order to authenticate each other, negotiate a cipher suite and security parameters, and establish cryptographic key material. Finally, Flight6 confirms that a DTLS session has been fully established on both sides, and thus client and server can consider it for secure communication. The reader can refer to Dierks and Rescorla (2008) and (Rescorla and Modadugu), (2012) for additional information concerning the handshake and the specific format of DTLS Flights.

Before starting a handshake, two DTLS peers have to be provided with preliminary security material. This includes, for instance, preinstalled cryptographic keys that are employed to establish a premaster secret during the handshake. Then, client and server use this premaster secret together with self-generated random values in order to derive a master secret, out of which the actual security material for the DTLS session is finally derived. In order to distribute preinstalled keys, there are two main approaches that can be considered. The first one leverages asymmetric keys. Additionally to the typical usage of X.509 certificates (Cooper et al., 2008), there are also available raw public key profiles, where private–public keys are provided without a certificate. In particular, such keys can be generated by device manufacturers and then installed before the device deployment (Wouters et al., 2014). In such a case, a device validates raw public keys received from other peers by means of out-of-band techniques. In particular, it usually stores a list of peers it is allowed to communicate with. Instead, an alternative approach leverages symmetric preshared keys (PSKs) (Eronen and Tschofenig, 2005). That is, the client stores a number of symmetric keys, each of which shared with a server that the client is allowed to communicate with. Then, during the handshake, the client specifies the particular key to use, indicating the related PSK identity. Finally, the client and server derive the DTLS premaster secret out of the symmetric key that they have been sharing. Adopting the approach based on preshared key is especially convenient for environments that are closed and within which one can easily provide cryptographic keys to the deployed devices. Furthermore, it does not require sending and receiving public certificates, or to engage in asymmetric cryptography operations, which are costly and particularly important to limit on resource-constrained DTLS servers. Besides, it makes key management operations considerably easier, particularly in IoT deployments within which manual and early configuration of connections is often common practice, and hence the provisioning of certificates often results to be a nonpreferable or even nonfeasible option.

8.2.3 Object Security for Constrained RESTful Environments

The CoAP standard specifies the possible use of proxies as intermediary entities between CoAP clients and servers, to improve efficiency and scalability in a number of network and application scenarios (Shelby et al., 2014). At the same time, as previously discussed in this chapter, CoAP refers to the DTLS protocol to provide secure communication (Rescorla and Modadugu, 2012). This represents a problem in the presence of intermediary proxies, since the latter must be able to access, and possibly manipulate, specific portions of a CoAP message, in order to perform the intended proxy functionality. As a consequence, proxy operations on CoAP messages require that DTLS communication from a CoAP client terminates at the proxy. On the other hand, it is still very important to prevent the proxy from accessing and/or manipulating portions of the CoAP messages that are not strictly necessary for the correct performance of the intended proxy functionality. In particular, this would also contribute to reduce and relax the security and trust assumptions on the proxy units deployed in the network. To this end, it would be convenient to rely on a secure communication protocol that is able to protect CoAP messages in an end-to-end fashion, even when intermediary nodes are present.

At the time of writing, the document (Selander et al., 2018) describes a relevant proposal named Object Security for Constrained RESTful Environments (OSCORE). In principle, OSCORE is a data object-based security protocol enabling the exchange of CoAP messages that are end-to-end protected across intermediary nodes. OSCORE uses COSE objects (Schaad, 2017) in order to provide integrity, end-to-end encryption, and replay protection of CoAP messages. The usage of OSCORE is signaled in the first place by including a newly defined Object Security CoAP option in the secured CoAP messages. As a possible alternative, message protection can be limited to the payload only of individual messages, according to an akin approach named object security of content (OSCON). The end-to-end security services provided by OSCORE are also particularly desirable in constrained network settings where solutions like DTLS can not be supported. On the other hand, OSCORE can actually be combined and used together with DTLS. That is, OSCORE can enable end-to-end security of CoAP messages between a CoAP server and a CoAP client, together with protection of the entire CoAP messages (i.e., header included) in a hop-by-hop fashion provided by DTLS during the message transport between an endpoint and an intermediary node like a proxy.

More practically, OSCORE assumes that a security context has been preestablished and agreed upon between a CoAP client and a CoAP server considered as endpoints of the secure communication. In particular, a security context is the set of information and parameters that the two OSCORE endpoints use to perform the specific cryptographic operations. Furthermore, OSCORE is very similar to DTLS, and borrows a number of its mechanisms such as key derivation and construction of nonce values. However, OSCORE relies on COSE (Schaad, 2017) rather than the DTLS record layer, and thus is able to use security context identifiers and sequence numbers of variable length.

8.2.4 Compressed IPsec

The 6LoWPAN standard (Hui and Thubert, 2011) defines how heavyweight IPv6 datagrams can be transmitted over low-power and lossy networks based on IEEE 802.15.4 (IEEE Computer Society, 2011). To achieve this, 6LoWPAN introduces a number of schemes for header compression, which are able to considerably reduce the size of the UDP headers, IP datagrams, and IP extensions. In IP networks based on IEEE 802.15.4, also referred to as 6LoWPAN networks, security is particularly important due to the high exposure to the Internet and the resulting network vulnerability. Currently, IP security (IPsec) (Kent and Seo, 2005; Jankiewicz et al., 2011) is the standard security solution for IPv6. In particular, IPv6 hosts on the Internet should implement it and be able to handle and process IPsec-protected packets. In particular, the transport mode of IPsec provides secure end-to-end communication between two nodes on the Internet. Hence, it is expedient to adapt 6LoWPAN in order to enable IPsec communications among IPv6-enabled things (e.g., sensor nodes) in 6LoWPAN networks and generic IPv6 nodes on the Internet.

A number of different proposals have been presented for compressing headers of IPsec packets. The majority of compression schemes is adoptable to generic Internet hosts, and does not specifically consider 6LoWPAN networks composed of resource-constrained devices. Migault et al. have proposed Diet-ESP (Migault and Guggemos, 2015; Migault et al., 2016) that specify how to perform compression of IPsec packets, but needs a number of changes and adoptions in conventional hosts on the Internet. Furthermore, RObust Header Compression (ROHC) relies on a flexible and efficient concept for header compression, but it is intended to generic hosts on the Internet and hence is not specifically intended for 6LoWPAN networks (Sandlund et al., 2010; Ertekin et al., 2010). Therefore, Raza et al. (2011) propose the 6LoWPAN-compressed IPsec, which is primarily targeted for resource-constrained IoT devices and network.

The schemes Diet-ESP and ROHC together with Generic Header Compression (Bormann, 2014) are accessory to the compressed IPsec described in Raza et al. (2011), where mechanisms for header compression specifically target 6LoWPAN networks, work with generic Internet hosts using IPsec, and do not result in any change of the standards Encapsulated Security Protocol (ESP) and IPsec Authentication Header (AH).

Currently, the IPsec's ESP protocol that provides both confidentiality and integrity of the ESP payload is mostly used. For the IoT, a number of use cases are envisioned where it is useful that ESP, as well as AH, protects the integrity of IPv6 headers in addition to the IPsec payloads. Because of different reasons, the usage of AH in the Internet is currently limited. That is, AH is not compatible with Network Address Translation (NAT), which modifies the IP source address while in transit, thus making the packet integrity check fail and ultimately causing the packet rejection at the recipient IPSec host. Moreover, ESP is able to provide both encryption and integrity protection of IPsec packets, but it makes it possible only to secure the application data and the ESP header, while leaving the IP header unprotected. Practically, this is fine in case the tunnel mode of IPsec is used, since the inner application data, ESP header, and IP header are both confidentiality and integrity protected.

Since IoT scenarios relying on IPv6-connectivity do not comprise NATs, it is possible and favorable to use the transport mode for providing end-to-end security. Thus, using AH along with ESP makes particularly more sense in the IoT. In particular, since the AH integrity check takes into account the IP address, IPsec can be effectively used to provide protection against IP spoofing, which is among the most common and likely security attacks mounted against resource-constrained devices communicating over IPv6. In addition, despite the stateless autoconfiguration of IPv6 addresses has been proposed, this is not considered to be an actual requirement to fulfill. That is, resource-constrained nodes in 6LoWPAN networks are assigned with IPv6 addresses at deployment time, and likely maintain the very same address during their lifetime, except in case of manual intervention by means of firmware/software updates. On the other hand, it is practically infeasible to address autoconfiguration in 6LoWPAN networks in a way that ensures end-to-end connectivity, unless a suitable and efficient mechanism specifically targeting 6loWPAN networks is designed and developed; this is in fact an interesting research challenge to take. Note that even if only a single application runs on a 6LoWPAN node, IPv6 potentially provides an unlimited address space. Therefore, one has the luxury to reserve many different IPv6 addresses for one single 6LoWPAN node. As a consequence, this enables the setup of unique IPsec security associations for each different application. In addition, in case IKEv2 (Bormann, 2015) is specifically considered as key management protocol, it is then possible to dynamically establish unique security associations on a per-application basis.

Besides, a number of use cases such as alarm actuating and simple environmental monitoring require only integrity protection, hence the usage of AH only is a convenient choice. At the time of writing, there is a pending IETF standard draft that defines the actual encoding of IPsec AH and ESP (Raza et al., 2016). The detailed implementation and evaluation of this draft are also available in Raza et al. (2011, 2014).

8.2.5 IEEE 802.15.4 and Bluetooth Low Energy

The IEEE 802.15.4 standard provides specifications for the physical and the Media Access Control (MAC) layer intended for wireless low-rate personal area networks. It entrusts other protocols like ZigBee or WirelessHART for additional services at the higher layers, or can alternatively rely on 6LoWPAN as an adaptation layer to operate together with standard Internet protocols.

In addition, the MAC layer of IEEE 802.15.4 directly provides a number of security services, that is, data authenticity, data confidentiality, and replay protection on a per-packet basis (IEEE Computer Society, 2011). In particular, the standard refers to a cryptosuite relying on the Advanced Encryption Standard (AES) 128 bits symmetric-key cryptography (National Institute of Standards and Technology, 2001). In case secure communication is enabled, an Auxiliary Security Header (ASH) is included next to the standard MAC header of each packet, which is secured upon its transmission based on what specified in the ASH. The recipient node receives and correctly unsecures the packet according to the same information.

In particular, IEEE 802.15.4 provides three different security modes, that is, CTR (encryption only), CBC MAC (authentication only), and CCM (encryption and authentication). The CCM and CBC MAC modes use a Message Integrity Code (MIC), which can be 4, 8, or 16 bytes in size. Security operations in IEEE 802.15.4 make use of a fresh nonce value. In particular, a nonce is generated at random on the sender side, and provides protection from replay attacks. The different available security modes and the different available configurations make it possible to trade specific application constraints with the security and performance requirements.

Finally, the IEEE 802.15.4 standard does not describe how to establish and distribute the key material in the network, or how to address device authentication. Instead, it assumes that both such security services are provided and enforced by the higher layers. As a consequence, the standard assumes that a given pair of sender and recipient nodes has successfully agreed on the same security settings and shared common key material, before they can start to securely communicate.

The same security services are provided in the enhanced standard IEEE 802.15.4e, which extends the previous standard IEEE 802.15.4 in order to specifically target embedded applications with critical requirements (e.g., healthcare or industrial applications) (IEEE Computer Society, 2012). In particular, it defines the MAC behavior mode Time Slotted Channel Hopping (TSCH), which combines multichannel and channel hopping functionalities with time slotted access. This not only makes it possible to provide better performance in terms of high reliability, large network capacity, energy efficiency, and predictable latency, but also contributes to make networks more robust against security attacks mounted at the physical layer, such as jamming and radio interference, thanks to the channel hopping mechanisms.

While on one hand IEEE 802.15.4 is currently the de facto standard covering the physical and link layers for 6LoWPAN networks, other new technologies are evolving as well. For instance, BLE, practically marketed as Bluetooth Smart, is among the energy efficient communication technologies currently available, and does represent an appealing alternative. In particular, BLE has asserted itself as a lightweight alternative for resource-constrained devices, compared to Classic Bluetooth. The Bluetooth 4.0 standard now also includes the BLE specifications, which comprise the broadcast communication mode in addition to the power-efficient connections among Bluetooth devices. Bluetooth 4.2 was published in December 2014, and provides a number of novel features which do make BLE a promising and valuable technology for the IoT (Bluetooth Special Interest Group, 2014).

The most important addition that enriches Bluetooth with IoT capabilities is the support for the Internet Protocol Support Profile (IPSP) (Bluetooth Special Interest Group, 2016). IPSP adds IPv6 support in the Bluetooth peripheral device and in the central master device acting as network coordinator, and specifies how devices are supposed to discover one another and to establish a connection at the link layer with each other. Besides, the BLE Generic Attribute Profile (GATT) can be employed in order to determine whether a device has IPSP support enabled, which in turn enables the exchange of IP packets by means of the Bluetooth L2CAP Credit Based Flow Control Mode.

Furthermore, Nieminen et al. connect BLE with 6LoWPAN by specifying the standard way for transmission of compressed IPv6 packets on top of BLE (Nieminen et al., 2015). In particular, they propose using the header compression mechanisms of 6LoWPAN on top of BLE. On the other hand, they do suggest to not use the fragmentation mechanisms of 6LoWPAN, but rather to rely on the ones already outlined in Bluetooth L2CAP.

Also, one of the most relevant improvements brought by Bluetooth 4.2 is the increased size of packets, that is, the BLE payload at the link layer is increased from 27 to 251 bytes. Also, Bluetooth 4.2 improves the throughput up to 2:5 times. These enhanced capabilities enable efficient IPv6 communication over BLE, frequent and speedy updates of device firmware, as well as fast uploading of data from sensor devices to backend units. Also, it makes it possible to run even in the IoT a number of complex security protocols, for example, DTLS (Rescorla and Modadugu, 2012) and IPsec (Kent and Seo, 2005; Jankiewicz et al., 2011).

Prior to Bluetooth 4.2, the Bluetooth standard provides stronger security in comparison with BLE, mostly for achieving energy efficiency. However, it also displays a small packet size of 27 bytes, and hence does not allow devices to use asymmetric-key cryptographic protocols. Instead, Bluetooth 4.2 LE brings BLE to the same security level of the standard Bluetooth, by recommending to rely on Elliptic Curve Cryptography (ECC). Specifically, the National Institute of Standards and Technology (NIST) has recommended to use elliptic curves, whereas the Federal Information Processing Standards (FIPS) has recommended to use AES-CCM symmetric cryptography for encryption and integrity protection.

In addition, Bluetooth 4.2 also brings enhanced privacy by adding private address resolution both in the Bluetooth Host as well as in the controller segments of a Bluetooth node. Also, Bluetooth 4.2 specifies the controller to maintain a white list of private addresses at the link layer. So doing, the controller is able to generate and resolve private addresses at the link layer with no need to interact with the host, and to reject or accept incoming connection according to the maintained white list. This significantly reduces the rate according to which the host has to “wake up,” therefore, considerably limiting the energy consumption of the BLE chip. The enhanced security and privacy with new low-power features and the fact that BLE is supported out of the box in most commodity smartphones makes BLE a valuable and promising technology for IoT deployment that involves mobility and allows a 6LoWPAN network to be directly connected to a smartphone, such as in deployments involving wearables. The standard IEEE 802.15.4 is still a preferable and more suitable choice for static deployments, such as smart homes.

8.2.6 OAUTH-Based Authorization in the IoT

According to the Internet Security Glossary, authorization is defined as the process for granting approval to a client to access a resource (Shirey, 2007). A typically adopted approach consists in managing the authorization of users, services, and their devices by means of dedicated Authorization Server (AS) entities. The OAuth 2.0 authorization framework relies on this fundamental approach, and has asserted itself as one of the most widely adopted standard for managing authentication processes (Hardt, 2012). In fact, it makes it possible to address all typical issues of alternative approaches based on credential sharing, thanks to the introduction of an authorization layer, and the separation of the role of the client from the role of the actual resource owner. In principle, the OAuth 2.0 authorization framework allows a client entity (i.e., a host, a process, a user) to request and obtain a specific, regulated, and limited access to a resource available at a resource server (RS) by enforcing the permission of the related resource owner.

Specifically, the resource owner grants authorization to the client by means of an intermediary AS, which provides the client with the actual authorization-related information specified in an access token. More specifically, an access token is practically represented as a string, which encodes an authorization decision issued to the specific client, and is typically opaque to that client. Among other things, an access token specifies the duration and scope of authorized resource accesses, which are ultimately determined by the AS and enforced by the RS. Furthermore, the AS ensures that possible unauthorized parties are not able to generate, modify, or guess any issued access tokens for producing valid access tokens. Then, the client can contact the RS in order to access the intended resource, according to the credentials specified in the access token. That is, the RS verifies that the access token is valid and, in such a case, proceeds with serving the request received from the requesting client. Before starting to perform the authorization protocol, the client must have registered at the AS, and all access token credentials must be always transferred through a secure communication channel, that is, both from the AS to the client and from the client to the RS. Also, the AS must verify the identity of the resource owner upon every authentication request on behalf of a client, and is required to have preestablished a trust relation with the involved RS hosting the resources to access. Note that the same AS can be associated with, and issue access tokens to be used with, multiple resource servers.

Having said that, it is more than reasonable to assume that end consumers and enterprises will want to adopt the same kind of approach for managing authorization as well as resource access control in IoT application scenarios. Also, this will become more and more likely with the rapidly increasing number of services provided by applications hosted on IoT devices organized in large-scale deployments. This has led to an IETF proposal (Seitz et al., 2018) aimed at reusing the OAuth 2.0 framework to extend authorization to IoT devices with different kinds of constraints, by using the basic OAuth 2.0 mechanisms where possible, while providing implementers with additional guidance, profiles, and extensions for using it in a secure and a friendly way with privacy. In particular, Seitz et al. (2018) describe a framework for authorization in the IoT that combines together a number of building blocks—(i) the original OAuth 2.0 authorization framework, (ii) the transfer protocol CoAP (Shelby et al., 2014), and (iii) the application layer security services, based on object security to CBOR-encoded data (Selander et al., 2018)—required when transport layer security provided by protocols like DTLS is not sufficient, adequate, or convenient. The DTLS protocol as well as object security to CBOR-encoded data have been discussed in more detail in the previous sections of this chapter.

8.2.7 Overview of Security Protocols and Mechanisms in the IoT

Table 8.1 provides a compact overview of the security mechanisms and protocols discussed throughout Section 8.2, highlighting the layer that benefits from their contributions.

8.3.1 Denial-of-Service Against CoAP

Energy-constrained, even battery-powered, IoT devices are substantially exposed to a number of security attacks, especially if they are directly connected to the Internet with no particular protection implemented through dedicated gateway or firewall boxes. A particular well-known class of security attacks is DoS, which in turn may be mounted with the specific intent to keep IoT devices constantly busy in receiving and processing invalid messages, so preventing them from switching to any energy-saving sleep mode and quickly draining their battery energy supply (see Figure 8.3).

This specific kind of DoS attacks is often referred as denial-of-sleep, and is considered a particularly severe security threat against constrained, battery-powered, IoT devices (Stajano and Anderson, 1999; Martin et al., 2004; Raymond et al., 2009; Gehrmann et al., 2015). In addition, their occurrence cannot be avoided altogether. That is, an active adversary that continuously transmits bogus messages can always induce a victim recipient IoT device to receive them and perform processing operations at different layers. This means that a practical countermeasure should instead focus on reducing the attack impact as much as possible, with particular reference to the energy consumption due to the useless message processing. However, counteracting this class of attacks in an effective and efficient way is definitely a challenging task, particularly in the presence of IoT devices that are directly connected to the Internet, that is, globally accessible to enable remote management and configuration, operation requests, and information retrieval.

Nowadays, CoAP has asserted itself as the de facto application layer protocol for the IoT, with particular reference to resource-constrained devices (Shelby et al., 2014). However, when it comes to providing secure communication, CoAP does not provide any particular security primitives or countermeasures against DoS attacks. Instead, CoAP suggests adopting the DTLS protocol (Rescorla and Modadugu, 2012), which relies on a costly and complex handshake process in order to setup a secure session, and results in a nonnegligible overhead to provide a whole set of security assurances, some of which may even not be necessary in some application scenarios.

A number of works have proposed detection techniques against denial-of-sleep attacks, typically considering traffic analysis or other anomaly detection mechanisms. For instance, Bhattasali and Chaki (2012) proposes a probabilistic model to detect denial-of-sleep attacks, based on Absorbing Markov Chains. Instead, Buennemeyer et al. (2007) describe B-SIPS, a system based on an innovative Dynamic Threshold Calculation algorithm that provides alerts upon detecting power changes. As pointed out in Raymond et al. (2009), these solutions based on intrusion detection techniques typically require to capture and analyze a considerable large amount of network traffic, and thus can be difficult or even unfeasible to deploy and run them on resource-constrained IoT devices.

Different proposed approaches consider traditional security services, especially at the link layer. For instance, Martin et al. (2004) propose a power-secure architecture, which processes only requests that deserve a high level of trust, but does not describe any concrete scheme to improve battery drain robustness. Instead, Raymond and Midkiff (2007) present an approach for rate limiting that relies on host-based intrusion detection mechanisms enforced at the link layer, considering messages to be legitimate only if both authenticated and not replayed, and taking actions to mitigate the attack effects. Also, Raymond et al. (2009) propose a framework based on classic link layer authentication, replay protection, and jamming identification. These detection approaches relying on traditional link layer security are however likely to result in a considerable overhead, especially as to energy consumption (Daidone et al., 2011). Also, they imply that validity of messages must be checked by every network node, along the path from the source to the destination device. This evidently produces a considerable additional impact on network performance as a whole. Furthermore, these approaches require to establish secure trust relations among all devices in the communication path (e.g., by distributing pairwise cryptographic keys), thus likely failing in efficiently providing protection against denial-of-sleep attacks from an end-to-end perspective.

More recently, Gehrmann et al. (2015) have proposed a security service relying on a short Message Authentication Code directly embedded in the CoAP message header, in order to early and efficiently detect invalid messages upon their reception. That is, it makes it possible to quickly determine whether received messages are valid or not, namely, whether they have been possibly transmitted by illegitimate sources. In such a case, a victim IoT device can early discard invalid messages and avoid performing useless additional parsing and processing operations. This considerably reduces the impact of denial-of-sleep attacks as to energy consumption, and thus preserves battery life in constrained IoT devices.

8.3.2 Denial-of-Service and Scalability Issues in DTLS

The DTLS handshake process displays two relevant security and performance issues that mostly affect devices acting as DTLS server.

First of all, as also stressed in the DTLS specification, a device acting as DTLS server is particularly vulnerable to DoS attacks mounted during the handshake process (Rescorla and Modadugu, 2012). Specifically, an active adversary has the possibility to continuously transmit ClientHello messages to the DTLS server, and induce it to start a great amount of DTLS handshakes. This in turn forces the server to start the setup of new (invalid) DTLS sessions. From a DTLS server point of view, this means allocating network and memory resources, and performing a number of resource-demanding operations. Moreover, this may exhaust available network and memory resources, so making the server less responsive or, in the worst case, even unavailable to process legitimate requests sent by DTLS clients. As a further drawback, attacks mounted through spoofed valid IP addresses force the DTLS server to send reply messages to “innocent” devices, so displaying a well-known amplification effect. The specification of DTLS provides a tentative solution against the DoS attack mentioned above, which leverages the stateless and optional exchange of a piece of information, namely, cookie, occurring during the first phases of the handshake between a DTLS client and server (Rescorla and Modadugu, 2012). Specifically, the DTLS server may reply to the first ClientHello message with an additional HelloVerifyRequest message, which includes a cookie as a locally generated value. After that, the DTLS client replies with another ClientHello message, which must include exactly the same cookie. However, the cookie exchange process only complicates the considered DoS attack, while it does not fundamentally provide any real protection against it. More in detail, as shown in Figure 8.4, an adversary able to intercept messages sent by the DTLS server during the handshake can still be able to perform the DoS attack, and induce the server to set up a considerable number of invalid, half-open DTLS sessions. It follows that the countermeasure based on the cookie exchange performed between client and server is actually not a good solution against DoS attacks mounted by a resourceful and well determined on-path adversary.

Furthermore, if the handshake is based on the PSK approach (Eronen and Tschofenig, 2005), the DTLS server may require to store and manage a nonnegligible number of symmetric keys associated with DTLS clients. As shown in Figure 8.5, this means that a DTLS server stores in the worst case one preshared key for every possible DTLS client. Of course, this approach scales poorly with the number of DTLS clients in the network. Moreover, it considerably complicates key provisioning and management operations, especially in dynamic scenarios. Nevertheless, the PSK scheme is very useful, convenient, and widely adopted in several dynamic IoT environments that involve resource-constrained devices as well as end users with no capability to securely manage a more complex public key infrastructure.

In Tiloca et al. (2017c), a security architecture has been proposed in order to address both issues discussed already. In particular, the proposed approach makes it possible for the DTLS server to detect an invalid ClientHello message upon its reception, and then immediately terminate the handshake at its very beginning, so practically neutralizing the attack and substantially limiting its impact. Also, it provides an alternative PSK scheme that greatly reduces the number of preshared keys stored at the server to one, thus preventing scalability and management issues. Furthermore, the proposed solution displays a number of advantages. First, it relies on a standardized method to extend ClientHello messages, and thus it is not required to modify the DTLS standard. Second, the DTLS client and server are not required to perform any further message exchange, and even the cookie exchange is not necessary anymore. Besides, the computing overhead on the client and server is not significantly affected, as the same computational complexity is preserved for the handshake process. Finally, it can be easily readopted in TLS, again with no required changes.

8.3.3 DTLS-Based Group Communication

As discussed in Section 8.2.2, the CoAP protocol (Shelby et al., 2014) mandates the adoption of the DTLS protocol (Rescorla and Modadugu, 2012) to secure unicast communications between a given pair of IoT devices. At the same time, in several IoT deployments involving groups with IoT devices as members, using multicast communication over IPv6 has several advantages, particularly as to scalability and performance. This is the reason why the standard (Rahman and Dijk, 2014) has explicitly defined group communication based on the CoAP protocol, with reference to a number of different use cases where the group communication model is particularly beneficial to IoT devices. For instance, group communication is highly convenient, or even inevitable, in IoT application scenarios such as firmware and software updates, lighting control, configuration and parameter updates, integrated building control, emergency broadcast, and commissioning of 6LoWPAN networks. In many IoT deployments, these use cases display a number of specific security requirements to be fulfilled, including the secure exchange of multicast messages among IoT devices within the same group. However, at the time of writing this chapter, CoAP does not provide support, or recommend an interoperable way, for securing multicast group communications.

At the same time, DTLS is the de facto security protocol to secure IoT unicast communications. Therefore, it is especially convenient to enhance DTLS so that it can also support secure group communication in the IoT. This choice would also be particularly convenient if compared with possible different alternatives. For instance, opting for IPsec multicast (Weis et al., 2008) would also require to use the heavyweight IPsec (Kent and Seo, 2005; Briscoe, 2010), and likely even additional supporting protocols, such as IKEv2 (Kaufman et al., 2014). Furthermore, DTLS is currently supposed to be used for protecting unicast communications in the IoT, hence opting for IPsec solutions would be even less practical and convenient in real-world application scenarios.

So far, there have been only a few initiatives to provide DTLS-based secure group communication for CoAP, in the remit of the standardization activities carried out within the IETF. In particular, the first approaches toward this direction were presented in the two documents Keoh et al. (2014) and Kumar and Struik (2015), which propose to protect communications in a multicast group of IoT devices by conveniently adapting the DTLS record layer, but were questioned because of a number of reasons. Among them it was pointed out that source authentication is a fundamental security requirement to be fulfilled, as group authentication alone may not be enough for several IoT application scenarios. Also, the protection of group response messages to multicast request messages was provided by means of traditional, pairwise, DTLS sessions. However, this can result in a number of practical issues and can display considerable degradation of performance, particularly in highly dynamic and large-scale groups of IoT devices.

On the other hand, the method described in Tiloca et al. (2015, 2017b) and Tiloca (2014) elaborates on the previous approaches, and proposes how to provide two-way secure group communication based on DTLS, while addressing the limitations displayed by the previously proposed approaches. Specifically, all the members of the multicast group consider the same group key material or efficiently derive individual key material. Group members rely on the overall key material in their possession to protect both requests sent to the group as multicast messages as well as possible responses sent back as unicast messages. The common key material is provided to a new group member upon its joining, and it is not necessary to perform DTLS handshakes among group members to enable secure communication in the group. Finally, the proposed approach ensures either source authentication or group authentication of messages sent within the group, according to the requirements of the specific application scenario.

8.3.4 Efficient and Scalable Group Key Management

As already mentioned, group communication is a convenient approach to adopt in many IoT application scenarios, in order to improve performance, responsiveness, and energy efficiency. However, it also requires a complex management of the group key material, as to generation, revocation, and (re)distribution. In general, the group key material comprises the secrets shared among the group members that enable secure communication only among devices in that group, at a given communication layer. For simplicity, the following refers to the group key material as a single symmetric group key, which all the group members commonly share and use to secure communications within the group at the application layer.

According to the group communication model, an IoT device explicitly joins a multicast group in order to become an active member. From then on, the device is able to receive (send) broadcast messages from (to) other devices in the same group. At some point in time, the device may want to leave the group, or can be forced to leave, in case it is compromised or suspected so. In order to allow only the actual group members to participate to the communications in the group, it is necessary to revoke and renew the current group key, that is, rekeying, according to the following policies. When a new device becomes member of the group, it must be prevented from decrypting and accessing messages exchanged before its joining, even if it has recorded them (backward security). Also, when a device decides to leave the group, or is forced to as compromised or suspected so, it must be prevented from decrypting and accessing any further future communication in the group (forward security). Practically, upon a change in the group membership, it is necessary to revoke the current group key and to distribute a new one to the current/remaining devices in the group. Therefore, it is particularly important that rekeying is performed in an efficient and highly scalable way, especially in highly dynamic and large-scale groups where joining and leaving can be very frequent events.

Furthermore, it is of particular importance to effectively deal with collusion attacks, which occur when multiple devices in the group are compromised, share their security material, and take part to the rekeying procedure anyway. Thus, these compromised nodes cooperate to regain knowledge of the group key, and would not be effectively removed from the multicast group. There are no group rekeying protocols that are not exposed to collusion attacks altogether, albeit they are characterized by different levels of resilience. However, only a few provide countermeasures to address collusion attacks. Moreover, several rekeying schemes recover the group from collusion attacks by means of a total member reinitialization, that is, each noncompromised device in the group has to be individually reinitialized. As a consequence, the collusion recovery displays a communication overhead that linearly grows with the group size, and can very negatively impact on the network scalability and performance.

Protocols for group key management have been typically classified as centralized, distributed, and decentralized (Rafaeli and Hutchison, 2003). Centralized approaches are particularly preferable in case of highly dynamic and large-scale groups, and especially good at minimizing communication, storage, and computing overhead. Centralized schemes use a set of administrative key material, which is logically organized for providing scalable rekeying upon node leaving (Dini and Savino, 2011; Dini and Tiloca, 2013; Gu et al., 2009; Tiloca and Dini, 2016; Wallner et al., 1999; Wong et al., 2000).

Furthermore, Logical Key Hierarchy (LKH) is a centralized protocol that relies on a hierarchical logical tree to organize administrative keys (Wallner et al., 1999). Specifically, the group key is the root of the tree, the group members' individual keys are the leaves of the tree, and the additional administrative keys are the internal tree nodes. In a group composed of n members, and assuming the key material to be organized in a balanced tree, both the storage overhead at the device side as well as the leave communication overhead grow as O(log n).

Figure 8.6 shows the key material managed by LKH in a group composed of eight devices, namely, u₁, u₂,…, u₈. In particular, each device owns the keys along the path from its related leaf node in the logical tree, up to the root node associated to the group key K_G. For instance, device u₃ owns the individual key K₃, the additional administrative keys K_1–4 and K_3–4, and the group key K_G.

Other protocols deriving from LKH do not achieve better performance (Dini and Savino, 2011; Gu et al., 2009; Wong et al., 2000). Furthermore, the centralized protocols HIghly Scalable Scheme (HISS) (Dini and Tiloca, 2013) and Group REkeying Protocol GREP (Tiloca and Dini, 2016) leverage logical subgrouping in order to provide highly scalable and efficient group rekeying, display the same storage and computing overhead, that is, O(√n), and distribute a new group key by using a number of rekeying messages that is constant, small, and independent of the group size, that is, O(1). In addition, the GREP protocol relies on the novel idea of member join history, and in fact leverages it in order to perform collusion recovery in a considerably more scalable and efficient fashion, with no recourse to a total member reinitialization. Specifically, HISS displays a recovery overhead that always grows as O(n). In contrast, the recovery overhead due to GREP gradually increases with the severity of the specific collusion attack and smoothly grows as O(√n), albeit only in the very unlikely worst case conditions.

On the other hand, distributed protocols rely on key management actions performed in a distributed way, involving the group members themselves or relying on additional key (sub)managers. However, they are harder to implement, are often less scalable, and raise security concerns. Moreover, some do not provide recovery from collusion attacks (Cheung et al., 2007; Fan et al., 2002), while others always require a total member reinitialization (Wang et al., 2008; Younis et al., 2006) or trade performance with collusion resistance (Chorzempa et al., 2005).

8.3.5 Selective Jamming in Wireless Networks

Jamming attacks are well known to be among the most common and severe kinds of DoS attacks against networks relying on wireless communication technologies (Lazos et al., 2009; Lu et al., 2014; Mustafa et al., 2012; Stojanovski and Kulakov, 2015; Xu et al., 2004, 2005, 2006). Specifically, jamming attacks consist in deliberately interfering with the operational frequencies in the network, and have been typically classified as constant, random, deceptive, and reactive (Xu et al., 2005).

On one side of the spectrum, constant jamming is extremely easy to perform. Its main objective consists in corrupting all transmitted network packets, by performing continuous overlapping transmissions of random signals. Note that this jamming strategy can be well considered as “always-on,” since it relies on the constant presence of a high level of interference, which thus makes the attack much easier to detect (Xu et al., 2004, 2005). On the other side of the spectrum, reactive jamming denotes a particularly smart and power-efficient approach, according to which an adversary actively jams communications in the network only during transmissions from other devices. Moreover, it is very likely that reactive jamming is actually confused with normal collisions of network packets, which makes it much more difficult to detect than other forms of jamming attack. Even more specifically, selective jamming is a specific type of reactive jamming, and it aims at interfering with communications between network devices, in accordance to well defined and specific objectives and criteria. With respect to other kinds of jamming attacks and strategies, selective jamming is more power efficient to perform, and even more difficult to counteract and detect, due to the reduced exposure of the adversary. A common criterion considered for selective jamming consists in disrupting all communication of one particular device in the network. In particular, this attack is particularly easy to perform in a wireless network using Time Division Multiple Access (TDMA). Specifically, TDMA divides time into a periodic sequence of superframes, each of which is composed of a fixed amount of transmission slots. However, such slots are typically assigned to network devices in a way that every device can remain active only during its own slot(s), and it can instead go to sleep mode during the other slots, so limiting its energy consumption. On the other hand, a network device typically retains exactly the same slot(s) for several consecutive superframes. As a consequence, an adversary has to simply monitor network communications, determine the slots accessed by its victim devices, and jam them to completely thwart the devices' communications. Note that such an attack is also very efficient from a power consumption point of view, since the adversary requires to keep her radio active only during the transmission slots assigned to her victim devices.

The countermeasures proposed to counteract jamming attack have been typically divided into physical-layer and cyber solutions. In principle, physical-layer solutions try to prevent an adversary from successfully interfering with the frequencies used in the network. The most important techniques belonging to this category have been overviewed in Mpitziopoulos et al. (2009), and are often based on Frequency-Hopping Spread Spectrum (FHSS) (Pickholtz et al., 1982), that is, a method that selects a different carrier from the available frequency channels, in accordance to an algorithm shared by the receiver and transmitter device. However, physical-layer approaches are not actually capable to fundamentally neutralize jamming attacks. Conversely, cyber solutions assume the adversary as always able to interfere at the physical layer with regular transmissions in the network. Hence, cyber solutions contrast jamming attacks by means of appropriate security schemes. Most of cyber countermeasures are specialized to address constant jamming (Cagalj et al., 2007; Raymond and Midkiff, 2008; Xu et al., 2004; Xu et al., 2007). Instead, only a few solutions have been specifically designed to target selective jamming attacks. For instance, Wood et al. (2007) describe Defeating Energy-Efficient JAMming in IEEE 802.15.4-based wireless networks (DEEJAM), that is, a MAC protocol that provides protection against selective jamming attacks mounted by means of hardware supporting IEEE 802.15.4. In principle, DEEJAM tries to hide packets from an adversary jammer node, in order to evade its search and thus limiting the impact due to packets that are corrupted anyway. However, DEEJAM is specifically tailored to IEEE 802.15.4 networks, and results in a considerable computational overhead and energy consumption. Furthermore, Ashraf et al. (2012) proposed the low-overhead framework Jam-Buster, which leverages equal size of packets, multiblock payloads, and randomization wake up time of devices. By doing so, it tends to reduce predictability of transmission times on network devices and to eliminate differentiation of packet types. As a consequence, the adversary has to transmit additional jamming signals, and hence is required to consume additional energy to remain effective, and is faster and easier to detect as source of the jamming attack. However, Jam-Buster does not fundamentally counteract the attack by means of an actual solution against jamming, but instead tries to make selective jamming less efficient and convenient to perform. Proano and Lazos (2012) consider a particular kind of selective jamming, where only specifically important types of packets are jammed upon their transmission, and proposes some techniques to mitigate the attack effects, based on cryptographic primitives. While this can be a good solution to counteract packet classification, it also requires that the packets in their entirety are encrypted, so preventing receiver devices from early aborting the reception of packets not addressed to them. In Daidone et al. (2014), the authors propose a solution that counteracts selective jamming in IEEE 802.15.4 networks and use the mechanism Guaranteed Time Slot (GTS). In the GTS mode, a central coordinator can allocate at most seven reserved time slots to sensor nodes in the network, at each superframe. The proposed solution addresses the GTS severe vulnerability to selective jamming previously described in Sokullu et al. (2009), and entirely relies on the central coordinator node, which computes and randomly changes the utilization pattern of GTS slots at each superframe. This makes it possible to reduce the effectiveness of the attack to 1/7, but at the same time makes the central coordinator a single point of failure. Moreover, the proposed countermeasure specifically considers the IEEE 802.15.4 standard and thus is not general. Finally, Tiloca et al. (2013, 2015) present JAMMY, a dynamic and distributed solution that counteracts selective jamming in general TDMA wireless networks. In principle, JAMMY permutes the slot utilization pattern of network devices in a random way, at each superframe. It follows that the slots associated with every network device unpredictably change on a superframe basis. As a consequence, the adversary has the only option left to jam slots picked at random, hoping to guess the ones that the intended victim device uses for transmission at that superframe. In case only one slot per device is used at every superframe, then a successful selective jamming attack has a probability of 1/N, given N the number of slots composing the superframe. More important, JAMMY does not rely on any central entity and is totally distributed, that is, every network device determines the slots to use for transmission in the next superframe in an autonomous way (i.e., with no data exchange with other devices) and in a consistent fashion (i.e., with no resulting collisions with other devices). Furthermore, JAMMY is dynamic, since multiple devices can join and leave the network at any time. Finally, it is in principle usable in any TDMA wireless network, regardless the specific technology.

8.3.6 Intrusion Detection Systems and Firewalls

Although communication security can protect against attacks that target confidentiality and integrity of sensitive data, there are a number of attacks aimed at disrupting sensor networks as a whole (Karlof and Wagner, 2003), such as DoS attacks. Especially for mission-critical networks, it is therefore necessary to adopt countermeasures against such kinds of attacks.

There are many approaches that can protect sensor networks against DoS attacks, by detecting and possibly counteracting intrusions and other anomalies. These intrusion detection systems (IDS) for sensor networks can be categorized as watchdog-based where a designated component is used for the detection of selfish nodes and malicious attackers (Marti et al., 2000; Rong et al., 2011); signature or rule-based that detect known types of intrusions by recognizing bad patterns (da Silva et al., 2005; Bhuse and Gupta, 2006); anomaly-based that detects deviations from a model of normal or good behavior (Onat and Miri, 2005; Loo et al., 2006); or cluster-based detection where a group of nodes elect a leader that participates in the detection process (Lazos et al., 2005; Rong et al., 2011). These conventional approaches target wireless sensor networks and are not directly applicable in the IoT. In fact, they assume that no central controller or management entity is available, messages within the sensor network are not secured, and nodes are not globally identifiable. Unlike a traditional sensor network, a 6LoWPAN network includes a 6LoWPAN Border Router (6BR) that is always reachable, sensor nodes are globally identified by means of an IPv6 address, and communication security is a fundamental requirement to fulfill. In addition, building an IDS that is suitable to the IoT remains a very challenging task, because 6LoWPAN devices are supposed to be globally reachable, are connected through lossy wireless links, are mostly resource-constrained units, and use not well tested new IoT protocols, for example, CoAP, 6LoWPAN, and RPL.

By exploiting these opportunities and threats, an IDS suitable to the IoT named SVELTE has been developed (Raza et al., 2013). SVELTE primarily defends against routing attacks against 6LoWPAN networks running the RPL protocol. A crucial decision in an IDS design concerns the placement of IDS modules in the network. SVELTE is a hybrid system where heavyweight detection modules are hosted in a 6BR, and lightweight notification functions are added in sensor nodes. SVELTE has two centralized modules hosted in 6BR: (i) the 6LoWPAN Mapper (6Mapper) that collects RPL-specific information from individual sensor nodes and rebuilds the RPL network in the 6BR and (ii) detection modules that analyze the mapped data and then perform the actual intrusion detection. The module 6Mapper has a corresponding function in each individual node that provides the mapping information to the 6BR.

Although SVELTE can protect 6LoWPAN networks against in-network routing attacks, it is fundamental that the sensor devices are safeguarded against global, much powerful, intruders. For example, a host on the Internet can easily perform DoS attacks aimed to deplete a sensor node's limited resources. A firewall is typically used to screen messages from Internet hosts destined to local area networks. For IoT deployments where end-to-end message integrity and confidentiality is enforced between a sensor device and a host on the Internet, a firewall cannot scrutinize the encrypted contents. SVELTE features a distributed mini-firewall for 6LoWPAN networks. Both the 6BR and each constrained node have a firewall module. In addition to offering classic blocking functionalities against external attackers specified by a system administrator, the firewall can filter and block malicious external hosts as notified by the legitimate nodes in the 6LoWPAN network in real time.