## 2 Materials and Methods
### Authentication Mechanism Explained, Components View
This process happens when a device has discrepancies in published data or meets established criteria (such as time or number of messages sent), which are de  
Figure 3: Component diagram with main components of the multi-factor authentication mechanism with reputation—on the left is the node representing the IoT restricted device, and on the right is the LPWAN gateway with the authentication mechanism components. termined through configuration. The enforcement requests that the device performs the second authentication step again and the sensor responds again to the query generated and sent by **AuthServ**. Upon completion, the device can send data again. If the device fails enforcement, it will be removed from the system, returning only after re-completing the entire authentication flow and gaining a new _auth_code_. ```
Result: data
1 Function enforcement(device: Device, auth_code: string) : boolean is
2 result = FALSE;
3 query, response = generate_query(device);
4 send(device, query);
5 dresp = receive(device);
6 ifdresp = responsethen
7 result = TRUE;
8
9 else
10 decrease(device.score);
11 device.alveel = AUTH2;
12 ifdevice.score \(\leq min\)then
13 expire(device.auth_code);
14
15 end if
16
17 end if
18 return result;
19
20 end for
```  
**Algorithm 8**Enforcement process  
Thirdly, **DataServ** is responsible for publishing data. The present mechanism focuses on data quality and sensor reputation, and, subsequently, authentication was implemented and proposed to guarantee security in authentication during data publication. Accordingly, to publish the data, the device must be authenticated with two factors or in compatibility mode. More specifically, when the service receives data from a device, it queries together with **AuthInspector** whether the authentication code(_auth_code_) sent is valid. Then, the **AuthInspector** can respond with three distinct values: ok (data can be received), enforcement (access needs to be renewed), and auth_code_ invalid. In the latter case, an audit log will be generated, recording the attempt to publish data improperly. Continuing with the **data service**, it is also responsible for evaluating (Algorithm 9) whether the published data are within valid values. Once a random or invalid pattern is identified in the data reception, the device is penalized with a reputation decreasing for the device that sent the data. If the device reaches a minimum reputation level, the data service requests an enforcement to **AuthServ**. Similarly, the more values there are within the expected pattern of a device sending data, the more its reputation in the system will increase. More specifically, **DataServ** will evaluate the data pattern and increment the device reputation up to the configured upper limit. Upon passing it, the device will ascend to AUTH3; it will be authenticated with the third factor. If the device in AUTH3 behaves inappropriately, it will suffer reputation penalties and eventually drop to the AUTH2 level. Ultimately, if it does not successfully pass enforcement, the device's access will be removed (_auth_code_ expires). To access the AUTH3 level, a new type of factor is used. We call this factor **PART-WHOLE** because it is not based on something exchanged with the device but on its functioning as part of the whole IoT system--as part of this mechanism. This innovative authentication factor was proposed to identify a real part of the whole, a real part of the system. The factors in this proposal identify the knowledge of a secret, the possession of an artifact (software--API artifact), and the appropriate behavior for a real part of the array where it is inserted.