## 3 Approach
### FrequencyTable Generation  
If there is lost data, more than 2 steps of message exchange are required in a synchronous communication to generate the same encryption key between devices. A method is required in which the Devicegateway requests the lost data and Devicesenor transmits the lost data as a response. However, this cannot be applied in an asynchronous low-power wireless communication environment. To solve this problem with at least one-time asynchronous communication, there is a method of transmitting TransactionPool\({}_{\text{sensor}}\) when generating a key by considering a message loss in advance in the Device\({}_{\text{sensor}}\). However, if TransactionPool\({}_{\text{sensor}}\) is stolen maliciously, the generated information can be exposed. To prevent this, a frequency table is used. Figure 8 shows frequency table generation. The frequency table is the result of counting the modular operation results from 0 to F of each transaction pool. The Device\({}_{\text{sensor}}\) generate the following frequency table (Frequency\(>\)Table\({}_{\text{sensor}}\)) by obtaining the frequency of TransactionPool\({}_{\text{sensor}}\) where the modular result of transmitted data is stored.  
The Device\({}_{\text{gateway}}\) also creates FrequencyTablegateway from TransactionPool\({}_{\text{gateway}}\). If there was no data loss, FrequencyTable\({}_{\text{sensor}}\) and FrequencyTablegateway would be the same. If there were two lost data entries, i.e., data having ModResult of 2 and 3, the frequency of 2 and 3 of FrequencyTablegateway would be stored less by 1 each. Additionally, the sum of frequencies will be \(64-2=62\). If the FrequencyTable created in Device\({}_{\text{sensor}}\) is transmitted as it is, a malicious attacker can know the frequency of modular result in the transaction pool, thus the order is changed. To change the order, the result place of frequency is changed by using the hash value of Block\({}_{n-1}\). They are changed in the order of hash values, and further, padding is performed in order if there is no ModResult. If the hash  
Figure 8: FrequencyTable.  
value of Blockn-1 is 9f86d081884c7d659a2 feaa0c55 ad015a3 bf4f1b2b0b82 cd15d6c15b0f00a08, the order of frequency table is changed in the order of 9 f 8 6 d 0 1 4 c 7 d 5 a 2 e 3 b d. If a malicious attacker intends to obtain the original FrequencyTable by stealing a frequency table, 16! = 20,922,789,888,000 number of cases should be computed for the acquisition. Because the Devicegateway has the same hash value of Blockn-1, its order is changed in the same way as the frequency table. The pseudo code is as Algorithm 2.  
```
1:procedureFrequencyTable
2:DeviceSensor executes:
3:list = transactionPool
4:while i < F do:
5:FrequencyCount(i,list) -> result
6:FrequencyTable(i, result)
7:increment i
8:TransformFrequencyTable(Devicekeyn-1(Hash),FrequencyTable) -> FrequencyTablesensor
9:Devicegateway executes:
10:list = transactionPool
11:while i < F do:
12:FrequencyCount(i,list) -> result
13:FrequencyTable(i,result)
14:increment i
15:TransformFrequencyTable(Devicekeyn-1(Hash),FrequencyTable) -> FrequencyTablegateway
16:endprocedure
```  
**Algorithm 2** FrequencyTable