Securing SDN-Based IoT Group Communication

Abstract

IoT group communication allows users to control multiple IoT devices simultaneously. A convenient method for implementing this communication paradigm is by leveraging software-defined networking (SDN) and allowing IoT endpoints to “advertise” the resources that can be accessed through group communication. In this paper, we propose a solution for securing this process by preventing IoT endpoints from advertising “fake” resources. We consider group communication using the constrained application protocol (CoAP), and we leverage Web of Things (WoT) Thing Description (TD) to enable resources’ advertisement. In order to achieve our goal, we are using linked-data proofs. Additionally, we evaluate the application of zero-knowledge proofs (ZKPs) for hiding certain properties of a WoT-TD file.

1. Introduction

The Internet of Things (IoT) considers “unconventional” communication paradigms such as “publish–subscribe” or “one-to-many” communication; in this paper, we focus on the latter paradigm, which is usually referred to as group communication. Although this paradigm is not typical in mainstream communication systems, we postulate that this is not the case for the IoT. We consider as a use case the crowd monitoring system presented in [1]. This system includes gas and ultrasonic sensors, UAVs equipped with cameras and LiDARs, as well as CCTV systems (see also Figure 1). In this system, tasks such as “collect all measurements in area X” or “turn on all cameras in area Z” are not uncommon scenarios, and the reasonable approach for implementing them is using group communication.

Group communication using the constrained application protocol (CoAP) [2] is a promising direction, which is impeded by the lack of adoption of IP Multicast, however. On the other hand, interconnecting IoT devices over software-defined networking (SDN)—such as in the architecture presented in [1]—enables alternative approaches for implementing group communication that removes the need for IP multicast and enables “self-organizing” IoT groups, where IoT endpoints can “advertise” the CoAP URIs of their resources, and groups can be automatically created based on these advertisements. Therefore, it is obvious that this advertisement process must be protected; otherwise, malicious entities may “pollute” the network with “fake” advertisements, affecting this way the group formation process.

In this paper, we provide a solution to this problem by allowing only authorized endpoints to perform advertisements. From a high-level perspective, we consider that each endpoint “represents” its available resource using a JSON-encoded file and by following the W3C Web of Things, Thing Description (WoT-TD) specifications [3]. This WoT-TD file is signed by a trusted service provider, and it is included in the advertisements, together with proof of ownership. The recipients of such an advertisement can then easily verify its validity. In this paper, we make the following contributions:

• We design an IoT onboarding process that ensures that only authorized IoT devices participate in a group;
• We leverage linked-data signatures to provide advertisement validity and proof of ownership;
• We extend our solution to support selective advertisement of resources using zero-knowledge proofs.

The remainder of this paper is organized as follows: In Section 2, we introduce the technologies used as building blocks of our system. In Section 3, we detail the design of our solution, and in Section 4, we present its implementation and evaluation. We discuss related work in this area in Section 5, and we conclude our paper in Section 6.

2. Background

2.1. SDN and Bloom Filter-Based Forwarding

Software-defined networking (SDN) [4] is a technology that allows a centralized entity, known as the “network controller” (or simply controller) to control programmable switches. SDN switches forward packets based on rules defined by the controller. In particular, in order for a switch to determine how to handle an incoming packet, it either queries the controller or uses a set of rules stored in the switch using a protocol such as OpenFlow [5].

SDN can be used for implementing Bloom filter [6]-based packet forwarding [7]. This type of forwarding enables multicast communication in an efficient, fast, and stateless way. From a high-level perspective, the solution in [7] assumes that each outgoing interface of an SDN switch is identified by a bitstring identifier; then, it uses a Bloom filter to encode the identifiers of all interfaces through which a packet should be forwarded; finally, it stores this forwarding identifier in the IPv6 address field of the packet. SDN switches are preconfigured with rules that allow them to decide the outgoing interface of each incoming packet simply by “ORing” the packet’s forwarding identifier with the identifiers of all outgoing interfaces.

2.2. CoAP and CoAP Group Communication

CoAP [8] is a lightweight protocol, designed to be the “HTTP of the IoT”. CoAP resources are identified by a URI scheme, similar to HTTP URIs, and the CoAP interaction model is similar to the client–server model of HTTP. Therefore, IoT endpoints act as CoAP “servers”, exposing one or more CoAP URIs that can be accessed by CoAP “clients” using a suitable CoAP “method”.

CoAP group communication is a CoAP extension that allows CoAP clients to retrieve (or set) resources from a group of CoAP servers, e.g., retrieve the temperature measurements from all sensors of a building, turn on and off all the lights of a smart city, etc. An approach for realizing CoAP group communication is using IP multicast (Section 2 of [2]). With this approach, CoAP servers belonging to the same group join an IP multicast address, and CoAP clients learn the IP multicast address of a group using DNS resolution. Then, CoAP clients can send CoAP requests to an IP multicast address and receive the corresponding response(s) using unicast. Nevertheless IP multicast is not the only option; other underlay networking architectures can be used instead. For example, as as we discuss in the following section, our solution relies on SDN to implement one-to-many communication.

2.3. Web of Things

The goal of W3C’s Web of Things (WoT) working group is to improve the interoperability and usability of the Internet of Things (IoT) [9] by specifying universal means for accessing IoT devices. This goal is achieved by providing building blocks that leverage and extend existing, standardized Web technologies in the context of IoT. Such a building block is the Thing Description specification draft [3].

A Thing Description (WoT-TD) is a JSON-LD [10] document that describes the “metadata” and “interfaces” of a “thing”, where a thing can be a physical IoT device or a virtual entity that is composed of multiple IoT devices. An interface can be a “property”, an “action”, or an “event”, that can be accessed using a Web technology such as CoAP or HTTP. A WoT-TD describes how these interfaces can be accessed by specifying suitable URIs, security policies, and other information that can be used by an interested client.

Being encoded using JSON-LD, a WoT-TD includes a context property, which is an array of URLs pointing to documents that include “vocabulary” terms. All WoT-TD include the “https://www.w3.org/2019/wot/td/v1” context, but additional contexts can be added, allowing the extension of the WoT-TD vocabulary (see also Section 7.1 of [3] for more information).

3. Overview

3.1. System Entities and Security Assumptions

Our solution considers an SDN network that interconnects IoT endpoints acting as CoAP servers with IoT service clients. Each IoT endpoint owns an Ed22519 public key [11], denoted by $Endpoin{t}_{ID}$. Network operators maintain a list of $Endpoin{t}_{ID}$ identifiers belonging to authorized IoT devices. IoT devices are connected to the SDN network through an access device; the type of this device depends on the available communication technology (e.g., WiFi, ZigBee, LoRa, etc.); nevertheless, our solution is oblivious to used technology. Access devices are connected to edge switches acting as the network attachment point (NAP), and it is assumed that there are mechanisms that allow NAPs to access this list of authorized IoT devices. Therefore, it should be not possible for an attacker to join a network by impersonating an authorized IoT device inside the SDN network. Similarly, the network operator owns a well-known Ed22519 public key, denoted by $Networ{k}_{ID}$, which acts as the root of trust in our system; all endpoints are preconfigured with this key, and all NAPs can generate signatures using the private key that corresponds to a $Networ{k}_{ID}$. Whenever a key is included in a text-based file, we are using its Base64url encoding [12].

IoT devices provide access to resources. We focus on resources that can be accessed using CoAP and CoAP group communication.

Additionally, we consider that the SDN controller knows the full network topology, and it is capable of constructing forwarding paths from an $Endpoin{t}_{ID}$ toward one or more $Endpoin{t}_{ID}$ identifiers (see also Section 2.1). These paths are identified by a Bloom filter-based identifier denoted as $Fw{d}_{ID}$. Finally, we consider that there is a well-known $Fw{d}_{ID}$ that can be used by endpoints to broadcast packets in the network.

Our solution is focused on IoT endpoints acting as CoAP servers; for this reason, we neither consider clients as part of our threat model nor are we concerned with client-facing security operations such as client authentication and authorization.

3.2. IoT Device Onboarding

Each IoT device is preconfigured with a WoT-TD file for the resources it provides. An example of a WoT-TD is one that includes an ultrasonic sensor deployed in a stadium, which can be seen in Listing 1. Lines 1–5 define the context of the WoT-TD file and include the identifier of the IoT device, i.e., the $Endpoin{t}_{ID}$. This example also includes an action used for “turning off” the sensor (line 8). This action can be invoked using either plain CoAP (lines 10–13) or CoAP group communication (lines 14–23). As it can be observed, this action can be invoked through two different groups, one representing “all sensors of the stadium” (line 15) and another representing “all sensors of a city” (line 20).

Listing 1. An example of a WoT-TD file.

1	{
2	“context”: “https://www.w3.org/.../v1”,
3	...
4	“id”: EndpointID,
5	}
6	“properties”: {…},
7	“actions”: {
8	“turnoff_sensor”: {
9	“forms”:
10	[{
11	“href”: “coap://gate7.stadium/sensor1/turnoff”,
12	“cov:methodName”: “POST”
13	},
14	{
15	“href”: “coap://stadium/sensors/turnoff”,
16	“cov:methodName”: “POST”
17	“subprotocol”: “cov:group”
18	},
19	{
20	“href”: “coap://city1/sensors/turnoff”,
21	“cov:methodName”: “POST”
22	“subprotocol”: “cov:group”
23	}]
24	}
25	},
26	“events”: {...}
27	}

Listing 1. An example of a WoT-TD file.

1	{
2	“context”: “https://www.w3.org/.../v1”,
3	...
4	“id”: EndpointID,
5	}
6	“properties”: {…},
7	“actions”: {
8	“turnoff_sensor”: {
9	“forms”:
10	[{
11	“href”: “coap://gate7.stadium/sensor1/turnoff”,
12	“cov:methodName”: “POST”
13	},
14	{
15	“href”: “coap://stadium/sensors/turnoff”,
16	“cov:methodName”: “POST”
17	“subprotocol”: “cov:group”
18	},
19	{
20	“href”: “coap://city1/sensors/turnoff”,
21	“cov:methodName”: “POST”
22	“subprotocol”: “cov:group”
23	}]
24	}
25	},
26	“events”: {...}
27	}

In order for an IoT device to join the network, it establishes a (D)TLS communication channel with a NAP. The (D)TLS handshake uses the “client authentication” option. The goal of this handshake is to allow the IoT device to verify that the NAP knows the private key that corresponds to $Networ{k}_{ID}$, and the NAP to verify that the IoT device is the owner of $Endpoin{t}_{ID}$.

As a next step, the IoT device sends its WoT-TD file to the NAP, and the NAP verifies that it includes the same $Endpoin{t}_{ID}$ used during the handshake, as well as that the $Endpoin{t}_{ID}$ is in the list of authorized identifiers. Then, the NAP signs the WoT-TD file using a linked-data proof (LDP) [13]. An LDP is a mechanism for ensuring the authenticity and integrity of linked-data documents, such as WoT-TD files, which is extensible and supports contemporary cryptographic solutions, such as zero-knowledge proofs (ZKPs). An LDP is encoded using JSON, and an example of an LDP used in our system is included in Listing 2. As it can be seen, line 2 defines the type of the proof, which, in our example, is an EdDSA signature [11]; line 3 includes a timestamp indicating the proof creation time; line 4 includes information that can be used for verifying the proof, which, in our case, is the $Networ{k}_{ID}$; line 5 includes the purpose of the proof, which, in this listing, is to provide an “assertion” about the integrity of the WoT-TD file; finally, line 6 is the actual proof value.

Listing 2. A linked-data proof used in our system.

1	{
2	“type”: “Ed25519Signature2020”,
3	“created”: “2021-17-06T11:01:24Z”,
4	“verificationMethod”: NetworkID,
5	“proofPurpose”: “assertionMethod”,
6	“proofValue”: "VqpLMweBrSxMY2x…aqA3Q1geV6”
7	}

Listing 2. A linked-data proof used in our system.

1	{
2	“type”: “Ed25519Signature2020”,
3	“created”: “2021-17-06T11:01:24Z”,
4	“verificationMethod”: NetworkID,
5	“proofPurpose”: “assertionMethod”,
6	“proofValue”: "VqpLMweBrSxMY2x…aqA3Q1geV6”
7	}

The received proof is appended to the WoT-TD file. From this point on, the IoT device can participate in the rest of the operations of our system.

3.3. SDN-Based IoT Group Communication

Our system adapts the solution presented in [14] for providing SDN-based IoT group communication and implements IoT group communication as a two-step process. The first step involves the advertisement of the available resources, and the second step implements the actual CoAP group requests.

3.3.1. Resource Advertisement

IoT devices should advertise their resources by broadcasting their WoT-TD files. As a reminder, we assume a well-known $Fw{d}_{ID}$ that can be used for broadcasting. In order to protect advertisements from replay attacks, IoT devices generate a new LDP, similar to the one they have received by the NAP, which, however, includes a nonce, and is generated using the private key that corresponds to $Endpoin{t}_{ID}$. Nonces in our system must not be reused within a specific time frame. This can be easily implemented by maintaining a list of used nonces: each nonce should remain in the list for the duration of the selected time frame, and devices must make sure that a nonce they send or receive is not included in that list.

Upon receiving an advertisement, clients validate the integrated LDPs. In particular, they validate that the advertisement includes an LDP that can be verified using $Networ{k}_{ID}$, which is “well known,” and another that can be verified using $Endpoin{t}_{ID}$ included in the WoT-TD file. Additionally, they verify that the latter proof is adequately fresh, and it includes a unique nonce. If all verifications are successful, each client updates a lookup table that includes mappings from CoAP group URIs to the corresponding $Endpoin{t}_{ID}$ identifiers.

3.3.2. CoAP Group Request

A CoAP client wishing to send a request to a CoAP group implements the related protocol described in [14]. From a high-level perspective the client executes the following steps:

• From the lookup table, it retrieves the $Endpoin{t}_{ID}$ identifiers of the CoAP servers that are members of the group;
• If it knows a $Fw{d}_{ID}$ for all retrieved $Endpoin{t}_{ID}$ identifiers, it proceeds to step 4;
• It constructs a message that includes all $Endpoin{t}_{ID}$ identifiers for which it does not know a $Fw{d}_{ID}$ and sends it to a “special” MAC address used for forcing SDN switches to forward a packet to the controller. The controller responds with a list of $Fw{d}_{ID}$ that is eventually returned back to the client;
• It creates a new $Fw{d}_{ID}$ by ORing the $Fw{d}_{ID}$ identifiers of the retrieved $Endpoin{t}_{ID}$ identifiers and forwards the CoAP request using the created $Fw{d}_{ID}$. Due to the properties of Bloom filter-based forwarding (see [7] for more details), the CoAP request will be forwarded to the appropriate IoT devices.

4. Implementation and Evaluation

4.1. Implementation

We implemented our solution using Eclipse’s Thingweb node-wot (https://github.com/eclipse/thingweb.node-wot accessed on 5 August 2021) as an IoT endpoint, and libcoap library (https://libcoap.net/ accessed on 5 August 2021) for emulating CoAP clients. For the SDN underlay, we relied on the tools presented in [15], i.e., we used the Open vSwitch [16] SDN switch, the POX [17] SDN controller, and we emulated the network using the mininet network emulator [18]. Finally, we used the JSON-LD library (https://github.com/digitalbazaar/jsonld-signatures accessed on 5 August 2021) to generate and verify LDPs.

In order to not modify libcoap to support the used SDN-based group communication, we developed a CoAP proxy that implements the related protocols; CoAP clients wishing to send a request to a group simply forward their request to the proxy using plain CoAP (see Section 5.7 of [8]). Using this approach, group communication is implemented transparently from the used CoAP library. This is a useful property since it allows the use of our solution even with constrained IoT devices, acting as a CoAP client, although using CoAP libraries with limited functionality.

We measured the time required to generate and verify an LDP in a desktop PC equipped with an Intel-i5 CPU and 4GB RAM, running Xubuntu, and a Raspberry Pi 2 Model B Rev 1.1 with a 900 MHz quad-core ARM Cortex-A7 CPU and 1GB RAM, running Raspberry Pi OS.

Table 1. LDP generation and verification times.

Operation	Desktop	Raspberry Pi
LDP generation	0.93 ms	5.2 ms
LDP verification	0.83 ms	6.0 ms

shows the results. The size of the corresponding base64-encoded LDP is 508 bytes.

4.2. Security Evaluation

The security goal of our solution is to prevent “fake” advertisements. Indeed, with our solution, only authorized IoT endpoints can advertise WoT-TD files. Furthermore, because these WoT-TD files are singed, neither an active attacker nor the IoT endpoint itself can modify them.

An active attacker in our system is able to replay valid advertisements. Although, in general, replay attacks are prevented by the use of the nonce, there can be cases in which the replayed advertisement is received before the real one. In these cases, an endpoint will believe that the attacker is a legitimate IoT device and that the real advertisement was a replayed one. Although this attack cannot be prevented in a straightforward way, we argue that its impact is limited, and it can be easily detected and i mitigated. Advertisements in our system do not contain any location-specific information, since $Endpoin{t}_{ID}$ identifiers are just public keys. Therefore, if an $Endpoin{t}_{ID}$ still provides the advertised resources, the attack will have no impact apart from the added network overhead. Moreover, advertisements in our system are broadcasted; hence, it will be trivial for a monitoring entity to detect the replay attack. Finally, we consider an SDN-based architecture, in which a controller can remove any endpoint from the network in a straightforward manner.

Similarly, an attacker that has access to the private key that corresponds to an $Endpoin{t}_{ID}$ can only sent valid advertisements of WoT-TD files belonging to the corresponding IoT device, i.e., since the $Endpoin{t}_{ID}$ is included in the WoT-TD, the attacker cannot use the breached key to sign an advertisement of another IoT device. Therefore, the impact of this attack is similar to the impact of the replay attack.

From a security perspective, the most critical component of our solution is the private key that corresponds to $Networ{k}_{ID}$. If this key is compromised, then it must be revoked; hence, all endpoints must be reconfigured with the new $Networ{k}_{ID}$, and all LDPs must be regenerated.

4.3. Private Advertisements Using ZKPs

Zero-knowledge proofs (ZKP) are a class of proofs in which a prover can prove to a verifier the knowledge of a value without revealing what the value is [19,20]. In the context of our system, ZKPs can be used by a user in order to generate a WoT-TD that reveals only affordances that are accessed through CoAP group communication. In order to achieve this, the proof of the TD signature must have been generated using an appropriate signature algorithm. In our implementation, we used the BBS+ linked signature algorithm for this purpose [21]. This signature scheme makes use of BLS12-381 pairing-friendly keys [22]. In a WoT-TD that contains a BBS+ signature, a subset of the affordances can be hidden by “framing” the original WoT-TD in a JSON-LD frame [23]. A JSON-LD frame can be seen as a filter that, when applied to a JSON-LD document (e.g., a W3C-compliant VC), it outputs a new JSON-LD document that contains only a subset of the fields of the original document.

Table 2. LDP generation and verification times when BBS+ is used.

Operation	Desktop	Raspberry Pi
LDP	174.6 ms	999.2 ms
LDP verification	74.3 ms	1004.0 ms

shows the time required to generate and verify an LDP proof, using the same endpoints as in Section 4.1, for a WoT-TD file that includes four affordances, three of which are hidden. For this purpose, we used node.js and the jsonld-bbs library, (https://github.com/mattrglobal/jsonld-signatures-bbs accessed on 5 August 2021), which handles JSON-LD objects and uses BLS12-381 keys to generate BBS+ ZKPs. The size of the corresponding base64-encoded LDP is 891 bytes.

As can be seen from this Table, LDP generation and verification in the Raspberry Pi requires approximately 1 s. Nevertheless, we are using an old device and an implementation written in node.js; therefore, there is significant space for improvement. Additionally, these signatures have to be calculated every time a new WoT description file is advertised; this process does not have to take place often—its frequency can be in the order of hours.

5. Related Research

Many research efforts provide solutions for protecting the confidentiality of IoT group communication messages, e.g., using group object security for constrained restful environments (OSCORE) [24], DTLS with pre-shared keys among group members [25,26], attribute-based encryption [27], or even by relying on the information-centric networking (ICN) paradigm [28]. These solutions are concerned with the establishment of a secret key that is used for encrypting data [24,28] or the communication channels [25,26]. Such a key can be derived by a pre-shared symmetric key, a public key, or by the attributes of the communicating endpoints. Our solution is orthogonal to these approaches since our goal is to make sure that a client receives CoAP responses only from authorized servers.

Our work considers an SDN-based underlay architecture used instead of IP multicast for implementing group communication. Many related efforts are considering other alternatives to IP multicast, including the use of bit index explicit replication (BIRE) [29], MPL [30], and ICN [31]. We see these efforts complementary to our approach since our solution is agnostic to the underlying mechanism; therefore, it could be used with any of them.

Some related solutions use identity-based signature (IBS) to achieve similar goals with our work (see, for example, [32]). Although IBS removes the need for public keys, it introduces computational overhead, and it suffers from the so-called key escrow problem, since there is a single entity (the key generator) that knows all private keys. Our solution uses Ed25519 keys, which are 32 bytes long; hence, the gains, in terms of communication overhead of using an identity rather than an Ed25519 key, are small.

Our solution is designed for IoT devices and gateways that support the WoT specification. However, in recent years, a number of related technologies have emerged. For example, under the umbrella of the European IoT Platform Initiative (https://iot-epi.eu/ accessed on 5 August 2021) a number of IoT gateway technologies were developed, by projects such as symbIoTe (https://iot-epi.eu/project/symbiote/ accessed on 5 August 2021), AGILE (https://iot-epi.eu/project/agile/ accessed on 5 August 2021), and Interiot (https://iot-epi.eu/project/inter-iot/ accessed on 5 August 2021). These efforts are now stalled. Since the only requirement of our solution is that device descriptions are encoded using JSON, we believe that it can be easily adapted for other gateway technologies.

Our system uses public keys for identifying IoT endpoints. A relevant technology that can be used instead is that of decentralized identifiers (DIDs) [33]. DIDs are closely related to LDPs. Additionally, when applied to the IoT, DIDs have some interesting security and privacy properties [34].

6. Conclusions

In this paper, we presented a security solution for managing group membership in IoT group communication. In particular, we leveraged linked-data proofs to assure that only valid group members can “advertise” their available resources. Our solution has intriguing security properties since it is a resilient event to private key breaches. Linked-data proofs allow the use of zero-knowledge proofs; our solution leverages this property in order to implement “selective disclosure” of available resources.

Future work in this area includes the integration of our solution with content confidentiality mechanisms (e.g., group OSCORE).