## 2 Materials and Methods
### Mfa_R Processes
#### 2.3.1 Registration Process  
Registration is the first step in using the proposal and can be performed when unpacking to use the device. It must occur through a network with greater traffic capacity or even through a secure channel (using SSL), reducing the chance of copying the transferred registration data. This is a process that demands the transmission of a larger number of data; therefore, it is recommended not to use a network charged by packets or with daily data traffic quotas [69; 70], which can significantly increase costs when activating multiple devices in a batch. Three pieces of equipment and two different devices are required for the registration process. The two devices are the device to be registered (\(dev_{\text{reg}}\)) and the gateway (\(gw\)). The three components are the device client firmware (\(dev_{\text{reg}}\)), the registration server (\(regServ\)), and the gateway database (\(db_{\text{gw}}\)). Note: the registry service does not need to be located in \(gw\). However, in our proposal, we use this architecture to reduce implementation costs in real situations. The process starts after connection to the registration service (\(regServ\)) by the unregistered client (\(dev_{\text{unreg}}\)). O \(dev_{\text{unreg}}\) sends a message (there are several formats used to exchange messages, and in our study, we used JSON, due to the low overhead generated) for the \(regServ\) of \(gw\). Upon receiving the message, \(regServ\) consults its database (\(db_{\text{gw}}\)) to check if the device has already been previously registered. If so, the registration is denied and a message with \(-1\) is returned to \(dev_{\text{unreg}}\). This is done to avoid device cloning and threats related to this aspect. The query is executed by generating a hash of the sent data. If it is already registered in the database, this means that the device in question has already been registered. This solution does not have a recommendation for device re-enrollment situations, this being a procedure to be resolved for each situation in the future. If \(dev_{\text{unreg}}\) has not been previously registered, a random password and username based on its hash is generated. Data \begin{table}
\begin{tabular}{c c} \hline \hline
**Code** & **Description** \\ \hline \(dev_{\text{reg}}\) & registered device \\ \(dev_{\text{unreg}}\) & device not registered \\ \(gw\) & gateway, device where services are published \\ \(db_{\text{gw}}\) & database located at gateway \\ \(regServ\) & registry service \\ \(authServ\) & authentication service \\ \(authInspector\) & authentication inspector \\ \(dataServ\) & data service \\ \(auth\_code\) & authentication code \\ \(authetication\_query\) & query used as second authentication factor \\ \hline \hline \end{tabular}
\end{table} 
Table 7: Symbol table. encapsulated in a record object, along with data coming from the device Equation (1), is sent to the database (\(db_{\text{gw}}\)). \[obj\_reg<user,passwd,reg\_data> \tag{1}\]  
At the end, the timestamp, user, and password are returned to \(dev_{\text{unreg}}\). These data are encapsulated in a registration confirmation message Equation (2), and, from that moment on, the device is considered registered (\(dev_{\text{reg}}\)). \[reg\_confirm<timestamp,user,passwd> \tag{2}\]  
This is a process that should, at most, happen once. With devices in compatibility mode, registration must be carried out through a user interface. The service that will provide the registration capability is the same; however, a web layer must be built to allow the IoT system administrator to register participating legacy devices. As such, regarding the service, the difference should not be noticed, and if the registration is carried out by a web layer or a RESTful API, this should be transparent for the service. For a better understanding, the two registration algorithms are presented here (Algorithms 1 and 2), which are client-side (firmware) and server-side (server), respectively.