## 2 Materials and Methods
### Mfa_R State Machines View  
In this section, state diagrams for the MFA_R processes are presented. The processes discussed here are fundamental for the description of the behavior of the mechanism in question and serve to better understand the way in which the states evolve separately between the different components of the system. Such state modeling is fundamental since state machines express the dynamics of the internal states of software [86] processes and components. Thus, this modeling allowed us to trace the evolution of processes and components during authentication in its different factors. Furthermore, it allowed the expression of restrictions (guards) for the evolution of states within the authentication process, which would otherwise be very complex to explain. Moreover, this section presents the behavior of software components participating in the mechanism. Therefore, four STMs are presented: **(i)** the registration process; **(ii)** the three-factor authentication and reputation system; **(iii)** the sensor life-cycle; and **(iv)** the evolution of authentication levels. By following the evolution of these STMs, it was possible to visualize the evolution of each process and of the software component within the mechanism. Consequently, this fact allowed us to refine state modeling and MFA_R. It begins with the **(i)** registration process (Figure 4), where the system represents the device through three states: not registered (\(n\)), in registration (\(r0\)), and registered (\(r1\)). The evolution between the states occurs through the registration request sent by the device (_reg_), which can be accepted (_reg_ok_) or not (_reg_fail_). If accepted, the device becomes registered and leaves this state only when the unregister process (_unreg_) is requested. Consequently, once registered in the mechanism, the device can perform the authentication process and the subsequent publication of the data described later in this document. Presented in **diagram (ii)** (Figure 5) is a unified overview of all processes involved in authentication. It describes the processes of one-factor authentication, two-factor authentication, data publication, three-factor authentication, reputation system, and possible cases of failure in the process, which are further detailed below. **First factor** authentication begins with a message sent to **AuthServ** containing the device credentials (_step1_). Then, validation is performed by **AuthServ**, generating the event of a valid password (_step1_ok_) in the case of success. If there is an authentication failure, the mechanism will evolve the device representation to a critical failure state (\(q8\)  
Figure 4: Process of registering a device in the proposed mechanism. The diagram is composed of three states and four transitions, and its function is to model the evolution of device states against RegServ. Figure 5: State machine for three-factor authentication, enforcement, and data publishing. The diagram is made up of 13 states and more than 25 transitions. It is the most complex state diagram of this work and the heart of the MFA_R operation. It represents the main processes and points for exploiting the listed vulnerabilities. If the first-factor authentication is successful, the device can evolve to an authenticated state in compatibility mode (\(q4\)), or the mechanism can generate the query, sending it to the device (\(q2\mapsto q9\mapsto q2\)). As for the next steps, once the query is sent along with the _auth_code_, the authentication mechanism will wait to receive the response from query to continue evolving. As for **factor two**, after receiving the response from query (_step2_), the mechanism evolves to its validation state of query (\(q3\)). If the query answer is wrong, the STM goes into a critical failure state (\(q8\)). If it is correct, the mechanism can wait for the publication of data (\(q5\)), which must occur through **DataServ** using the _auth_code_ obtained by the device.