## 4 Results  
Considering the proposed approach shown in Figure 3, and assuming that \(N_{b}\) is the number of bits per key \(K_{i}\), then the number of available keys is \(2^{N_{b}}\). The probability of correctly detecting one key used for a single transaction is:  
\[P_{d},Key=\frac{1}{2^{N_{b}}} \tag{1}\]  
When \(M\) transactions are encrypted, each with a different key, then the probability of detecting all of the keys to decrypt the whole chain is:  
\[P_{d},Chain=\left(\begin{array}{c}1\\ 2^{N_{b}}\end{array}\right)^{M} \tag{2}\]  
It should be noted that the probability in (2) does not take into account the difficulty of detecting the initialization vector.  
For example, using \(N_{b}\) = 128 and \(M\) = 10, then (1) leads to \(P_{d,Key}\) = 2.94 \(\times\) 10\({}^{-39}\) and (2) leads to \(P_{d,Chain}=4.8\)\(\times\) 10\({}^{-386}\). This makes it impossible to recover the data without access to the private key of the Control Center, which is safely stored away from the UAV.  
Figure 4: (a) Encryption at the UAV; (b) Decryption at the Control Center.  
In Equation (1), we considered the probability of guessing one key. This can allow decoding one transaction, say transaction \(i\), given that the encrypted previous transaction (\(i-1\)) is accessible, in order to reverse the XOR process shown in Figure 3. However, the proposed approach can be amended to make this previous transaction inaccessible, especially in areas covered several times a day with DTN connectivity by multiple UAVs. The details can be explained as follows:  
* The UAV that performed the delivery (let us denote it by UAV \(j\)) does not store the encrypted transaction (although it performs the encryption process). It stores only the symmetric keys, encrypted with the Control Center's public key. It needs only to store the encrypted version of the last transaction to use it with the next XOR operation, and then it can discard it. For example, it stores encrypted transaction \(i\) to use it for encrypting transaction \((i+1)\), then discards it, keeping encrypted transaction \((i+1)\) only to use it for encrypting transaction \((i+2)\), and so on.
* However, the encrypted block of each transaction is stored at that transaction's location (the actual location where the delivery happened, e.g., BS, AP, or CPE at a house, etc.), to be \"picked up\" later.
* The next UAV \((j+1)\) that will be hovering over the area provides DTN connectivity and collects the odd-numbered transactions of UAV \(j\).
* The one after it, UAV \((j+2)\), provides DTN connectivity and collects the even-numbered transactions of UAV \(j\).
* It should be noted that each of UAVs \((j+1)\) and \((j+2)\) could also perform delivery operations, encrypt the corresponding transactions, and store them at the corresponding locations to be picked up by subsequent UAVs, similar to what they did for UAV \(j\).
* Thus, in fact, UAV \((j+2)\) would be collecting the even-numbered transactions of UAV \(j\) and the odd-numbered transactions of UAV \((j+1)\).  
This approach would completely confuse any attacker: Even if the attacker maliciously accesses a drone and guesses one of the keys (which would happen with an extremely low probability as shown by (1)), they will not be able to obtain the initial transaction data. In fact, to do so, they would have to perform the reverse XOR process with the previous transaction; however, this previous transaction is carried by a completely different drone. Hence, to decrypt a single transaction, the malicious attacker needs to (i) be aware of the encryption/collection scheme described above to conceal the encrypted data, (ii) take down two consecutive drones and access their data successfully, and (iii) guess the key used for encrypting the transaction.