# Securing SDN-Based IoT Group Communication
## 3 Overview
### IoT Device Ontboarding  
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 \(Endpoint_{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).  
```
1{
2\"context\": \"[[https://www.w3.org/.../v1](https://www.w3.org/.../v1)]([https://www.w3.org/.../v1](https://www.w3.org/.../v1))\",
3...
4\"id\": \(Endpoint_{ID}\),
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.  
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 \(Network_{ID}\), and the NAP to verify that the IoT device is the owner of \(Endpoint_{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 \(Endpoint_{ID}\) used during the handshake, as well as that the \(Endpoint_{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 \(Network_{ID}\); line 5 includes thepurpose 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.  
```
1{
2\"type\": \"Ed25519 Signature2020\",
3\"created\": \"2021-17-06T11:01:24Z\",
4\"verificationMethod\": \(Network_{ID}\),
5\"proofPurpose\": \"assertionMethod\",
6\"proofValue\": \"VqPLMweBrSxMY2x...aqA3Q1 geV6\"
7}
```  
Listing 2: A linked-data proof used in our system.  
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.