1. Introduction
The predominant client–server communication paradigm of the current internet, although it works, impedes the exploitation of the full potentials of emerging architectures, such as the internet of things.
The internet of things (IoT) promises to interconnect users, software, and devices, enabling novel, innovating applications. Nevertheless, many of the envisioned IoT systems require advanced communication paradigms, such as multicast and anycast. Many IoT scenarios can benefit from group communication toward devices that share some properties (e.g., all smart lamps of a building). Most legacy IoT systems provide this functionality by relying on a centralized entity, which acts as an indirection layer that maps application-layer semantic-rich identifiers (e.g., building1.floor5.lamps) to the corresponding network addresses (e.g., CoAP and CoAP group communication relies on DNS, and MQTT relies on a MQTT “broker”). Nevertheless, these systems cannot efficiently handle dynamic networks (i.e., network with IoT devices that experience churn or move around), neither can they easily support multiple administrative domains.
Information-centric networking (ICN) [
1] in a next-generation internet architecture that can overcome many of the limitations of IP-based networks and provide the desired functionality without requiring a centralized indirection point. ICN architectures allow endpoints to “advertise” content identifiers, extending, at the same time, network routers to operate using content identifiers (rather than network identifiers). ICN facilitates caching, and it supports advanced communication paradigms (such as multicast). For these reasons, ICN architectures are considered by many research efforts to be underlays for IoT systems (see, for example, the survey of Nour et al. [
2]). However, ICN-based systems not only require modifications to the networking infrastructure, but they also introduce new security threats, such as “pollution” attacks that require new security solutions. Content pollution attacks are a kind of denial-of-service attack, where an attacker injects fake content into the network [
3]. Fake content can be cached, amplifying, in this way, the impact of the attack [
4]. One root cause of a content pollution attack is that any entity is allowed to advertise and provide any content item.
This paper considers an architecture that abides by the principles of ICN; it has the same advantages as ICN but, at the same time, it does not require modifications to the networking architecture. Then, it proposes an efficient solution to prevent content pollution attacks. The considered architecture leverages software-defined networking (SDN), and it was originally proposed in [
5]. That architecture allows stateless broadcast and multicast by using content identifier advertisements and Bloom-filters-based network communication. In particular, in this architecture, Bloom filters are used for “encoding” the network path that a packet must follow [
6]; additionally, edge nodes advertise content identifiers, and these advertisements are used for creating lookup tables that map a content identifier to the Bloom filter that should be used in order to reach the nodes that have advertised it. In order to solve the problem of content pollution, a solution is proposed that enables edge nodes to validate that an identifier is advertised by an
authorized entity: this is achieved using decentralized identifiers (DIDs) [
7].
A DID is a URI-like identifier which resolves to a “DID document” that includes “information” about the DID owner. DIDs are a standardized self-sovereign identity (SSI) mechanism. SSIs have received increased attention in the context of the IoT [
8]. The proposed system allows DIDs to be used as content identifiers and a DID document includes information that can be used for validating that an identifier advertisement has originated from an
authorized entity. Our paper makes the following contributions:
It proposes a solution that integrates DIDs with a registration system allowing ordinary, human readable URLs to be used as DIDs. These URLs can then be used for identifying and/or grou** IoT devices.
It defines methods that allow DID owners to securely bind a DID to IoT devices, enabling, in this way, IoT devices to generate “proofs of ownership”, which are used as the main building block of our security solution.
It defines protocols that allow DID owners to perform identifier delegation to a third party in a secure and controlled way.
It designs the solution to be lightweight since the only operation that an IoT device should perform is the generation of a digital signature and the only operation that an edge node should perform is the validation of that signature.
The remainder of this paper is organized as follows.
Section 2 presents background information, and it introduces DIDs and the SDN-based underlay architecture.
Section 3 discusses related work in this area.
Section 4 details the design of the proposed solution. The implementation and evaluation of the proposed solution are presented in
Section 5.
Section 6 discusses alternative DID methods and ICN underlays as well as the impact of the proposed solution in lightweight devices. Finally, we present our conclusions in
Section 7.
2. Background
2.1. Decentralized Identifiers
Decentralized identifiers (DIDs) are a new type of globally unique identifier, recently standardized by W3C. DIDs are designed to enable individuals and organizations to generate their own identifiers using systems they trust [
9]. Due to their intriguing security and privacy properties, DIDs have been investigated as a security solution for many types of systems, including IoT-based ones (see, for example, [
10,
11,
12]).
A DID systems is akin to a key–value lookup architecture, where the key is the decentralized identifier (DID) and the value is a DID document. The actual contents of a DID document, as well as how it is resolved, depend on the implementation of the specific DID method.
A DID is a string consisting of three parts: (1) the “did” URI scheme identifier, (2) the identifier for the DID method, and (3) the DID method-specific identifier [
9]. An example of a DID for the “example” DID method follows.
A DID document may include, among other things, public keys (or “pointers” to public keys) that can be used as verification methods, e.g., an “authentication” key used for authenticating the DID “owner”, or an “assertion” key used for verifying digital signatures generated by the DID owner. A DID document is usually maintained by a DID registry. A registry implements proper security and access control mechanisms. Registries allow the DID document owner to manage their corresponding DID documents, as well as third parties to look up DID documents. Additionally, registries provide proofs of correctness (e.g., a proof can be a digital signature generated by the registry). In a typical DID system, any entity can verify that a digital signature has been generated by the owner of a DID by following a two-step process: (a) retrieve the corresponding DID document, and (b) check if the digital signature can be verified with (one of) the assertion key(s) included in the DID document.
In this work, a new DID method is defined, and it is used to protect routing advertisements. The proposed DID method relies on ICN for managing the corresponding DID documents.
2.2. SDN and Bloom-Filter-Based Forwarding
Software-defined networking (SDN) [
13] is a technology that enables the use of programmable network switches, which can be configured by a centralized entity, known as the “network controller” (or simply controller). A controller can use a protocol, such as OpenFlow [
14], to configure switches with “rules” that are used for making switching decisions.
Reed et al. [
6] leverage this property of SDN and implement source-routing using Bloom filters [
15]. From a high-level perspective, this solution is implemented as follows. Firstly, it assumes that each outgoing interface of an SDN switch is identified by a bitstring identifier. Then, each sender can create a “forwarding identifier” using a Bloom filter constructed by ORing, the identifier of all interfaces through which a packet should be forwarded; this forwarding identifier is stored in the IPv6 address field of the transmitted packet. SDN switches are pre-configured with rules that allow them to forward these packets through the interfaces whose identifier is included in the forwarding identifier. An interesting property of this solution is that it can implement stateless multicast since a forwarding identifier may include a complete multicast delivery tree. Another useful property of this system is that given a forwarding identifier
X for a path from a node
A to a node
B, and another forwarding identifier
Y from the same node
A to a node
C, by ORing
X and
Y, we obtain a forwarding identifier that corresponds to a multicast delivery tree from
A to
B and
C.
3. Related Work
Many related systems are trying to secure (inter-)networks by using cryptographic constructions (such as public keys) at the network layer (see, for example, [
16,
17,
18]). These systems have broader goals than our approach; therefore, even though they can be used to achieve similar properties to our solution, they require significant changes to the networking infrastructure. Our solution is an overlay approach that can be used on top of any networking technology. Similarly, our constructions are applied in the edge devices, and they are transparent to the core network.
DIDs as a mechanism for securing routing messages have been investigated in the context of next-generation internet architectures. For example, the solution in [
19] uses DIDs to protect the routing layer of information-centric architectures from poison attacks. These approaches use public keys as the corresponding DID, whereas our solution uses a registrar service to support URLs as DIDs. Additionally, our solution leverages an ICN-based DID registry to implement DID document management. Similarly, recent solutions investigate the use of DIDs for providing access control in the IoT (e.g., [
20,
21,
22]). Although the goal of these solutions is different compared to our system, they follow the same principle: they use DIDs to derive a key, which is then used for signing and verifying a digital signature. Nevertheless, these solutions use blockchain to manage trust. Our system uses as a root of trust a centralized entity. Although our approach introduces a single point of failure, it is more lightweight, and more realistic to deploy. Furthermore, given that IoT devices do not have the processing power to interact with the blockchain directly, all these solutions rely on a “proxy” that mediates the communication between the IoT devices and the blockchain: this proxy is also a single point of failure. The solution of Enge et al. [
23] uses DIDs for establishing secure communication channels between IoT devices. This solution uses DIDs only for deriving public keys, whereas our system includes “constraints” that control how a key can be used. Furthermore, our solutions supports secure and controlled delegation.
Related technologies, such as Verifiable Credentials [
24] Macaroons [
25], Authorization capabilities for linked data (ZCAP-LD) [
26] and capabilities as defined by the WAVE framework [
27] can also be used for expressing “assignments” and “capabilities”. The system proposed in this paper uses DIDs because are simpler to implement and use, and easier to verify. Nevertheless, if more complex trust relationships are required, these technologies can be used instead.
In the context of the IoT, related efforts try to provide security properties at the application layer, supporting, at the same time, advanced communication paradigms, such as publish–subscribe, and group communication (see, for example, group OSCORE [
28]).These efforts are complementary to our approach: with our solution, we are securing the routing layer, but the used cryptographic material can be provided as an input to application-layer-security solutions.
5. Implementation and Evaluation
In order to validate the proposed solution, we emulated an SDN network using the mininet network emulator [
33]. We used open vSwitch programmable switches [
34], which we configured with the appropriate rules for performing Bloom-filter-based switching using the POX network controller [
35]. We implemented
did:domain using the jwcrypto (
https://jwcrypto.readthedocs.io/en/latest/) (accessed on 6 October 2022) to generate the required JSON objects as well as to generate and verify the required JWS signatures.
5.1. Evaluation Scenario
The proposed solution was evaluated through a smart city emulation scenario. In this scenario, the owner of the domain “smart-city.iot” delegates to 100 building owners the “smart-city.iot/building-X”, where X is a number between 1 and 100. Then, each building owner can configure the IoT devices of each smart building to advertise resources using the delegated URL, e.g., the owner of “building-1” could configure a light controller to advertise the URL “smart-city.iot/building-1/lights”.
In our evaluation scenario, we consider the topology depicted in
Figure 3. In particular, each building is attached to a different edge node, and each edge node is attached to a different SDN switch. We group SDN switches in two groups, and we connect all SDN switches of the same group to another SDN switch. Finally, the latter two SDN switches are connected using a
backbone link. In our evaluation scenario, each building advertises 50 different
s every 10 s and a DID document every 1 min. Advertisements take place almost simultaneously.
Table 1 summarizes the parameters used in our evaluation scenario.
As a baseline for comparison of our system, we consider the trust schema defined in [
36]. This trust schema is used by a popular ICN architecture known as named data networking (NDN) [
37], and it resembles WebPKI. In particular, this schema defines “trust anchors”, which are public keys used to sign digital certificates. Additionally, each (edge) router is configured with rules that map prefixes of
to identifiers which are resolved to a digital certificate: this certificate includes a public key that can be used for validating the digital signature included in the corresponding
advertisement. Therefore, compared to our solution, a trust anchor has the same role as the registrar, the identifier of a digital certificate is equivalent to a DID, and a digital certificate is equivalent to a DID document. Similarly to our solution, the solution of [
36] can be used for creating “trust chains”. In the considered use case, a trust anchor would sign a digital certificate for the domain “smart-city.iot”, and the private key that corresponds to the key included in the latter certificate would be used to sign the digital certificates of each building.
5.2. Routing State Storage and Computational Overhead
Each edge node maintains a routing table that maps a to either an edge node identifier or to an IP address: in the former case, the IoT device that has advertised the corresponding is attached to another edge node, whereas in the latter case, the device that has advertised the is attached to the local node. In order to decrease the storage overhead, entries that share the same prefix and have the same destination edge node are aggregated. For example, the entries [“smart-city.iot/building-1/lights”, “edge-10”] and [“smart-city.iot/building-1/power”, “edge-10”] will be aggregated to [“smart-city.iot/building-1/”, “edge-10”]. Using this approach, each edge node in the considered evaluation scenario maintains 149 entries: 99 entries that correspond to the smart buildings attached to other edge nodes, and an additional 50 entries for the URLs of the smart building attached to that edge node. These entries are due to the ICN functionality of our system. In addition, the edge router should maintain routing entries used for locating DID documents. In particular, each building is associated with a different did:domain DID, and hence, each router should maintain another 100 records. This state is due to the ICN registry functionality of our system.
In a system built using the solution defined in [
36] a routing entry per digital certificate should be used. Therefore, such a system requires the same routing entries as in our solution. However, in addition to the routing entries, the solution of [
36] requires each router to be configured with rules that map prefixes to digital certificate identifiers. Since in the considered use case there are 100 buildings and each building uses its own key to sign advertisements, each router should be configured with 100 additional rules. It should be highlighted that in addition to the extra routing state, the solution defined in [
36] creates additional administrative overhead since every time a digital certificate changes (which means its identifier also changes), the corresponding rules in the routers must be updated.
Routing in our system is implemented using
longest prefix match at the edge routers and Bloom-filter-based forwarding in the core network. Using a solution such as the one proposed in [
38], an ordinary PC can perform a few millions lookups per second in a routing table that contains 3,000,000 entries. Similarly, the solution presented in [
6], which is used in the core of our architecture for implementing Bloom-filter-based forwarding, requires switches from SDN to perform just an OR operation per outgoing link.
5.3. Communication Overhead
Our solution introduces the communication overhead for retrieving DID documents. In the considered scenario, every time an edge node receives an advertisement, it requests the network to retrieve two DID documents: the DID document that corresponds to “smart-city.iot”, and the DID document that corresponds to the building owner. It is reminded, however, that the underlying ICN architecture allows edge nodes to construct multicast delivery trees; hence, multiple requests concerning the same item can be satisfied using a single multicast delivery. However, this requires that the requests arrive almost simultaneously to the edge node. Since we know that an advertisement will trigger requests for DID documents, we evaluate a strategy based on which an edge node adds some delay before responding to a DID document request, ho** that during that period, more requests concerning the same DID will arrive. In order to evaluate the impact of this strategy, we consider that only two buildings, one in each side of the backbone link, advertise
s (every 10 s), and we measure the number of DID documents that are transferred through the backbone link in one minute. We consider three strategies: edge nodes add no delay, edge nodes add 2 ms delay, and edge nodes add 4 ms delay. The obtained results can be seen in
Figure 4. As it can be observed, by adding 4 ms delay, all requests for DID documents arrive at edge nodes; therefore, they can all be satisfied by a single multicast transmission. As a result, only two DID documents are transferred over the backbone link.
Similarly, in a system that uses the solution of [
36], an advertisement triggers two requests: a request for retrieving the certificate that corresponds to “smart-city.iot” and a request for retrieving the certificate of the building. Therefore, both solutions result in the same communication overhead. Additionally, the delay-based mechanism can also be applied for the solution of [
36].
5.4. DID Document Storage Overhead
The DID document that corresponds to “smart-city.iot” includes 100 entries in the assertion list, one for each building, and each entry is of the URL type. An example of such an entry can be seen in Listing 2. The size of this document is 17,452 bytes.
Listing 2. An assertion entry for the DID “did:domain:smart-city.iot”. |
![Futureinternet 14 00322 i002]() |
Each building owner maintains also a DID document that includes 50 entries in the assertion list, one for each advertised URL. Each entry is of the JsonWebKey type. The size of each such document is 13,900 bytes.
A digital certificate in a system that uses the solution of [
36] includes only a public key; hence, its size is smaller compared to a DID document (in our use case
bytes). This happens because the information included in a DID document in our system is distributed as rules configured in routers in the solution of [
36]. On the other hand, an entity authorized for multiple prefixes should store a certificate per prefix in the solution of [
36], whereas in our solution, the same DID document may include a key that can be used for many prefixes.
5.5. Computational Overhead
The only operation that each IoT device has to perform is signing an advertisement message. In a RaspberryPi 2 Model B Rev 1.1 with a 900 MHz quad-core ARM Cortex-A7 CPU and 1 GB RAM, the generation of a signature using EdDSA requires 10.1 ms. Similarly, signature generation in an Espressif ESP32 WROOM-32 IoT device (240 MHz dual-core Xtensa LX7 CPU) requires 160 ms. EdDSA signatures are used in our system for providing authentication of the advertisement messages. In any case, our solution is not tightly bound to a particular authentication mechanism: other authentication mechanisms that may be more suitable for constrained devices may be considered and integrated in our approach. For example, many systems rely on MACs and pre-shared keys for providing authentication: such an approach could also be used in our system, e.g., by including a ‘hint’ of the used pre-shared key in the DID document. However, such approaches are left as future work.
Similarly, an edge node in our system has only to verify a digital signature. Using an Ubuntu 22.04 machine equipped with an intel i7-3770 CPU, 3.40 GHz and 8 GB of RAM, digital signature verification requires less than 1 ms.
The solution of [
36] uses the same signing procedure; hence, its computational overhead is the same as that in our system.
5.6. Security Evaluation
Providing that the registrar service is secure, our solution has the following security properties:
The integrity and the authenticity of advertisements are protected. advertisements are digitally signed by the IoT devices. The public key of the IoT device is included in the DID document, whose integrity is protected by the document proof generated by the DID controller. Therefore, any entity can verify the advertisement signatures. Additionally, through the authorization proof, any entity can verify that a particular IoT device is authorized to advertise this specific .
Our solution is resilient to IoT devices’ key breaches. A breached IoT device key can be used for generating fake advertisements for the for which the IoT device has been authorized, until the corresponding DID document expires. The impact of this attack is further decreased by including in the document the identifier of the edge node in which the IoT device is attached (it is reminded that only the DID owner can modify a DID document). Then, each edge device can check whether the included identifier matches its own identifier. With this approach, fake advertisements can only be sent from the same location where the legitimate IoT device is located, limiting, in this way, the impact of this attack to a few more valid advertisement messages.
Dependence on the trusted registrar service is minimal. Domain owners rely on the registrar service in order to receive the authorization proof. When this step is completed, domain owners can manage, assign and delegate without relying on the registrars. For example, a domain owner can freely modify the assertion key of a DID document, as opposed, for example, to a solution based on WebPKI, where an owner would require a new “digital certificate”.
5.7. Performance–Security Trade-Offs
As discussed in
Section 4.4, whenever an edge node retrieves an advertisement, it has to request the ICN network to retrieve the corresponding DID documents. In order to decrease the number of such requests, as well decreasing the advertisement verification time, these documents can be cached. Nevertheless, this means that an edge node may not have the current version of a DID document. A DID document is updated whenever a new entry is added in the assertion list or whenever an existing entry is removed. In the former case, the edge node will not be able to locate the key used for signing the advertisement in the cached documents; hence, it may refresh its cache. However, in the latter case, the edge node will consider a signature generated with a
revoked key to be valid. Therefore, there is a time window between the moment that a key is revoked and the moment that a cache entry expires during which a revoked key can be used. A solution to this problem that can be explored in future work is to leverage the ICN functionality and each edge node to “subscribe” for all future versions of a DID document; this way, every time a DID document is created, it will be pushed to the edge nodes that have subscribed to its updates.
7. Conclusions
In this paper, a solution that leverages decentralized identifiers for secure application-layer routing is proposed. The proposed solution can be easily integrated into existing approaches since it does not require any modification to the SDN infrastructure. The proposed solution allows URLs to be used as DIDs by adding a trusted name registration service; the use of URLs as DIDs enables more user-friendly application-layer solutions, as well as greater interoperability with legacy systems. The proposed solution is lightweight since it requires only few ms to perform the necessary cryptographic operations even in IoT devices; it adds only a few bytes to the routing advertisement messages; it creates minimal additional routing states; it does not need auxiliary information to be stored per verifying entity; and it can be easily managed. Finally, the proposed solution has intriguing security properties: it protects the integrity and authenticity of advertisements, it is resilient to key breaches, and its dependence on a trust registrar is minimal.
Future work in this area includes solutions for fast revocation so that key breaches can be handled in a secure and fast manner, as well as tools for automating the process of domain registration. Furthermore, the use of verifiable credentials as well as the application of different DID methods and ICN underlays will be further investigated.