## 2 Materials and Methods
### Mfa_R Processes
#### 2.3.2 Authentication Process  
Authentication starts with a registered device (\(dev_{\text{reg}}\)) sending authentication data to the related service (\(authServ\)). Three distinct flows can occur from that moment on: (i) failed authentication; (ii) successful authentication--compatibility mode; and (iii) successful authentication--reputation mode. When authentication fails (i), \(authServ\) should store an audit log (this log should be in a textual format to be processed by an IDS, which works together with the authentication mechanism to prevent DDoS, among other attacks). Upon successful authentication in compatibility mode (ii), \(authServ\) returns a message confirming the authentication and communicates with the authentication inspector (\(authInspector\)) and records the \(auth\_code\) (the authentication code is stored in the \(authInspector\) software component, and this code acts as the device's authenticated) device credential in compatibility mode. \(authServ\) generates an \(authetication\_query\) for \(dev_{\text{reg}}\) from the data exchanged at the time of registration. Upon receiving it, \(dev_{\text{reg}}\) must generate a response to the query and send it to \(authServ\), which will then compare it with the expected result, previously calculated. If the values are equal, \(authInspector\) is informed that \(dev_{\text{reg}}\) has risen to the AUTH2 level. It is important to highlight that when accessing AUTH2, the device becomes eligible for AUTH3, according to its behavior when sending data. In the case of a negative result during authentication, \(-1\) is returned as an error code (we note that the value \(-1\) as the authentication error pattern prevents the identification of the access level that the device has because the errors are the same for the different levels; someone listening to the network will not be able to obtain the access level information based on the capture of the failed returns). During the publication of data, the **third factor** is validated. After reaching the AUTH2 level, the sensor receives a reputation score. As posts are made and the data stay within the standard deviation, \(dev_{\text{reg}}\) gains more reputation, and when it reaches the required upper threshold (Equation (3)) it becomes eligible for the AUTH3 level. \[upper\_threshold\leq score-salt \tag{3}\]  
There is also the possibility of a device going down from the AUTH3 level to the AUTH2 level, which will occur if the sensor fails and sends anomalous measurements, causing the sensor to lose reputation. If this is recurrent, the sensor may reach the lower threshold (Equation (4)) and drop to the AUTH2 level. Such level changes should generate an audit log. \[lower\_threshold\geq score+salt \tag{4}\]In this way, the general aspects of the authentication process in its three stages are contemplated. Also, the thresholds and their functioning were brought together with the reputation score during the device authentication process. For further clarification and formalization of the process, three algorithms are presented below to clarify the authentication process: client-side authentication (Algorithm 3), the first step of server-side authentication (Algorithm 4), and the second step of server-side authentication (Algorithm 5).