# A Framework for Constructing a Secure Domain of Sensor Nodes
## 4 Procedures for Creating a Secure Domain of Sensor Nodes
### The Procedure for Node Status Confirmation  
After the R node data have been restored to RAM, this node initiates the confirmation of its status by sending the _status_confirm_req_ packet to the MAD address. The purpose of this procedure is to notify the M node of its readiness to work in the domain after the power off/power on cycle and confirm the correctness of the values of the MAD and GAD fields restored in the RAM. The implied M node (i.e., the one to which the _status_confirm_req_ packet was sent) will authenticate the querying node if the following conditions are jointly met:  
1. The M node is able to decrypt the sent frame using the R node NSK key, which is stored in the EEPROM of the M node in the description of the domain nodes;
2. The content of the NAD field from the frame is consistent with the contents of the NAD field in the description of the domain node;
3. The content of the NTAG field from the frame is consistent with the calculated value based on the data in the M node resources;
4. If the status of the N_ID node in the domain is _Active_ or _ActiveNonConfirmed_, then the RN field from the frame must match the RN field in the description of this domain node;
5. If the status of the N_ID node in the domain is _NonActive_, then the RN field from the frame may have _REPLICA_ or _REPLICA_ + _GATEWAY_ content, and the RN field in the description of this domain node must have _REPLICA_ content. If it turns out that the M node being queried no longer fulfills this role, it sends a response that currently this role is being played by another node and gives the current MAD address. Then, the querying node should direct its query to the node with the MAD address. If the M node does not confirm these data (because, for example, the M node does not work or has crashed or the querying node has not been authenticated), the querying node will not get a response, which consequently, means that this node needs to re-register in the security domain. The RN field of node R is restored based on the record in its EEPROM and also needs to be confirmed by node M. If, in the meantime, this role has changed (i.e., from _REPLICA_ + _GATEWAY_ to _REPLICA_), then the M node sends a reply informing that, currently, the Gateway role is being played by a different node, and additionally, will give the current GAD address and the current contents of the RN field. The sequence diagram of the procedure for refreshing the node status is shown in Figure 19  
Figure 18: Response frame for node status refresh request. The most important steps of the procedure are as follows:  
**(1) Prepare a request to confirm the status of the R node**. Do the following:  
* Prepare the _status_confirm_req_ packet (Figure 20) containing the following data: N_ID, RN, NAD, NTAG, and SQ of R node. The packet is encrypted using the NSK of the R node;
* Send a _status_confirm_req_ packet from the R node using the MAD as the target address of the M node. **(3) Authenticate R node and update its status**. Do the following:  
* On the M node, decrypt the received _status_confirm_req_ packet using the NSK and IV vector of the N_ID node. Authenticate the N_ID node in the domain according to the rules described at the beginning of the section:
* If the authentication procedure did not succeed, ignore the packet and terminate the procedure;
* If the authentication procedure was successful and the node being requested acted as a Master, set the status of the node N_ID in the domain to _Active_ and prepare the package _status_confirm_ans_ (Figure 21) as follows: N_ID = N_ID gathered from the _status_confirm_req_ packet; Ans = STATUS_OK; RN = current role of the N_ID node; ADR = GAD--address of the current G node; Time = current time of M node; SQ = the SQ from _status_confirm_req_ increased by 1.