# A Low-Complexity Security Scheme for Drone Communication Based on PUF and LDPC
## 3 Security Architecture
### Error Correction Schemes
#### 3.4.3 Decoding Algorithm Selection
## 5 Cost Analysis

### Computation Overhead

In this paper's protocol, the computational overheads involved in the drone include five 256-bit hash computations \(T_{H}\), two 256-bit random noise generations \(T_{R}\), six 256-bit \"XOR\" operations \(T_{SK}\), one 256-bit decoding \(T_{ECC}\), and two 256-bit PUF responses \(T_{P}\). The purpose of this study is to ensure security while minimizing the cost of drones. According to the microcontroller with a main frequency of 168 MHz, as used in this study, by placing breakpoints around the called functions using online simulation tools, the average time difference is calculated. Based on the ECC time consumption for different numbers of iterations, a single iteration takes 30 msec. Considering the maximum possible number of errors, as shown in Figure 6, the average iteration is 2.25 times, which amounts to 65 msec. As calculating each parity bit requires indexing the symbol bit each time, the decoding time cost is relatively high. However, this saves RAM space of \(256\times 32\) bytes, which is acceptable. The other operation time overheads are shown in Table 7. In this paper, it is assumed that the GS resources are not constrained; therefore, only the drone overheads are given. Since matrix storage consumes a lot of resources and authentication is performed only when the drone takes off, this paper adopts a time-for-space scheme. In addition, the decoding is implemented in this paper in a way that follows the theoretical steps, but if a parallelized decoding scheme is used on a high-performance platform, the time overhead significantly reduces. ### Storage Overhead

The static storage overhead on the drone side consists mainly of a 32-byte static secret key, and the dynamic storage consists mainly of the secret key of the n-1 drones and GS, as well as the broadcast secret key; the registration information in the database is related to the extraction threshold, which is required to be approximately in the range of \(\left\{4+32+64+4+1+39+32+22\right\}=198\) bytes (according to the registration information \(\left\{IP,key_{i},P_{fp},start,len,S_{us},ID,S_{pus}\right\}\)) for each drone according to the threshold in this study. ### Communication Overhead

The communication overhead mainly occurs in the GS authentication phase. According to the communication steps in Table 3 the authentication overhead can be calculated as

\[\left\{4+4\right\}+\left\{32+4\right\}+\left\{4+1+39+4\right\}+\left\{32+32+4 +32\right\}+\left\{32+32+4+32\right\}+\left\{32+4\right\}=328\text{ bytes}.\]

The keys in the communication phase are distributed by the GS and do not need to be negotiated. The secret key set for broadcasting new authentication is related to the number of drones, and in 0 only the GS-drone authentication overhead is compared. Zero shows the comparison of drone overheads, taking into account the different simulation platforms. The time overhead is used instead of the formula, where \(T_{MAP}\) is the time to compute the authentication code. The storage overhead is only analyzed for the drone. For the communication overhead, it should be noted that protocols [22; 23] use 32-bit sequences and protocols [24; 35] only count the overhead of drone-GS authentication, while they still need about 4000 bits of communication overhead. The overhead comparison of this paper's protocol with other protocols is summarized in Table 8. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Operation** & \(T_{H}\) & \(T_{R}\) & \(T_{SK}\) & \(T_{P}\) & \(T_{ECC}\) & **Total** \\ \hline Time (msec) & 0.51 & 0.27 & 0.32 & 0.37 & 65 & 70.75 \\ \hline \hline \end{tabular}
\end{table} 
Table 7: Running time of related operations. ## 6 Conclusions

In this paper, the protocol is proposed for the PUF extraction scheme, the ECC-based authentication scheme, and the drone communication scheme, respectively. In addition, this paper provides a detailed analysis of the coding matrix of the ECC module based on the protocol characteristics and offers the requirements of the matrix structure.