## 2 Materials and Methods
### Additional Information about the Mra_R  
Before detailing the components, this section discusses the theoretical complementation of some concepts necessary for a broader understanding of how the authentication mechanism works. The add-ons that require clarification are the **compatibility mode**, the **reputation concept**, **expected values**, **query API**, **authentication levels**, and _auth code_. These concepts are not as apparent in component modeling as they are dissolved into different components. Firstly, concerning **compatibility mode**, this authentication mechanism aims to guarantee compatibility with legacy devices. For that, it allows the registration of old devices with a flag of \"device in compatibility mode\". This tag allows the logging of device data without their reputation level. As a result, if the data consumer uses it, they will know that the mechanism does not secure the data. Second, the **concept of reputation** in this work differs from the classical concept of distributed systems. Reputation within the context of this mechanism expresses a score that grows when publications are not identified as violations, that is, within the expected standard of publications. For example, when there is an attempt to publish random or invalid data, the attempting device suffers a penalty of its reputation score (decrease); however, when it has a normal operation, its score increases, and as a result, the device gains more reliability (addition). Third, the **default value** algorithm (Algorithm 7) can vary according to the problem domain. There are several ways to implement data validity analysis, and they vary according to the scope of the problem. For example, let us examine three different cases: temperature in a greenhouse (I), rain in a field (portion of land used for cultivation) (II), and complex data in a plant/factory (III). * In cases like temperature, for example, limits can be used if the temperature in a greenhouse (I) exceeds 1000 degrees Celsius; this is outside a normal standard. * Another case involves the use of statistical analysis. It may be compromised if a rain gauge (II) indicates 100 mm of rain in a field that others indicate an average of 3 mm. * Also, as in the last case (III), we can use machine learning and submit the received measurements to its sieve. This case allows us to identify which correlated variables are deviating from the pattern that was learned as normal. Next, the **query API** serves as a challenge-response (CR) authentication factor. Therefore, the challenge is established from the sensor registration data and the data resulting from this registration process. The query API is a set of tools for slicing, rotating, flipping, or masking, causing the data not to be fully transmitted on the network during the CR factor response process. Additionally, the query API is a piece of software shared between the sensors and the AuthInspector. Due to the fact it is present in the sensor firmware, replicating API behavior by an adversary is very difficult. Also, using data from the moment of registration, the simple copy of the firmware from stolen equipment would cause the access to the IoT system to be invalidated. As a result, the pair {log data, query API} must be present in the sensor without any access changes. However, it is observed that the query API can be replaced according to the application's needs. Some studies present promising substitute factors for it, such as the use of secure hardware [77; 78], authentication via token [79; 80; 81], physically unclonable function (PUF) [82; 83], and smart contracts [50; 84]. Additionally, there are the **authentication levels**, which are AUTH1 (or compatibility), AUTH2, and AUTH3. As for AUTH1, only devices registered as a legacy can publish data; in AUTH2, devices log in with two steps, receive a reputation score, and can publish data; while in AUTH3, the devices are considered reliable and must periodically perform an enforcement to keep it that way.