# Privacy-Preserving Solution for European Union Digital Vaccine Certificates
## 8 Experimental Results
### Overall Performance Including BLE Communication Overhead  
The second part of the performed experiments focused on testing all components of our privacy-preserving digital vaccine certificate application. Within the testing infrastructure, test certificates with a different number of attributes were created by the I/RA. These certificates were downloaded to the smartphone application using a secured web service. Then, the system performance was measured during user authentication to the VER's terminal. To run the application, we used a Raspberry Pi 4B single-board computer and a lower-performance Raspberry Pi Zero 2 W. Both of these devices have a built-in Bluetooth 5 interface which supports communication via the energy-efficient BLE protocol. The results show that the time duration of each protocol phase (i.e., Scanning, Nonce, Verify) is nearly identical for both computers. For representative results, all measurements were performed on a Raspberry Pi Zero 2 W: see Figure 10. Note that the Scanning protocol phase is responsible for finding and connecting the smartphone application to the BLE server, the Nonce phase performs the sending of an authentication challenge from the Verifier and the computation of the cryptographic proof of the user, and the Verify phase then checks the correctness of the cryptographic proof on the VER's side. \begin{table}
\begin{tabular}{c c c c c c c c c c c c} \hline \hline
**Device** & **Attributes** & **2** & **10** & **20** & **30** & **40** & **60** & **80** & **100** & **200** & **500** \\ \hline \multirow{3}{*}{Google Pixel 4a} & Setup [ms] & 1 & 4 & 7 & 10 & 12 & 18 & 25 & 31 & 68 & 162 \\  & Issue [ms] & 1 & 2 & 4 & 5 & 7 & 10 & 14 & 17 & 22 & 55 \\  & Verify [ms] & 5 & 11 & 16 & 20 & 25 & 34 & 41 & 50 & 103 & 262 \\ \hline \multirow{3}{*}{Samsung S21 FE} & Setup [ms] & 1 & 2 & 4 & 6 & 8 & 12 & 16 & 19 & 42 & 106 \\  & Issue [ms] & 1 & 2 & 3 & 5 & 6 & 9 & 11 & 14 & 32 & 82 \\  & Verify [ms] & 3 & 7 & 10 & 13 & 16 & 22 & 26 & 32 & 65 & 163 \\ \hline \multirow{3}{*}{Honor 8X} & Setup [ms] & 1 & 6 & 11 & 16 & 21 & 31 & 41 & 51 & 110 & 275 \\  & Issue [ms] & 1 & 3 & 6 & 9 & 12 & 17 & 24 & 28 & 58 & 150 \\  & Verify [ms] & 8 & 19 & 27 & 34 & 42 & 57 & 69 & 84 & 165 & 410 \\ \hline \multirow{3}{*}{Average} & Setup [ms] & 1.0 & 4.0 & 7.3 & 10.7 & 13.7 & 20.3 & 27.3 & 33.7 & 73.3 & 181.0 \\  & Issue [ms] & 1.0 & 2.3 & 4.3 & 6.3 & 8.3 & 12.0 & 16.3 & 19.7 & 37.3 & 95.7 \\ \cline{1-1}  & Verify [ms] & 5.3 & 12.3 & 17.7 & 22.3 & 27.7 & 37.7 & 45.3 & 55.3 & 110.0 & 278.3 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: The time consumed to perform each phase of the cryptographic core on various devices. Figure 10: Performance of the implemented application when verifying a sample privacy-preserving digital vaccine certificate according to Table 2. The measurement results are the average of the elapsed time for 5 measurements. Each certificate issued under the Issue algorithm contains one or more attributes and the appropriate attribute signature for each attribute. In the data structure representing the certificate, the attributes are stored as pairs containing a key and a value. The user application generates a VerifyRequest containing the revealed certificate entries and the digital signatures of the attributes. This request is serialized to the JSON format, and images, such as user photos, are converted to text using Base64 encoding. For testing purposes, a certificate containing attributes representing a possible certificate proving vaccination was used. The specific details included in the certificate are listed in Table 2. In total, there were 19 attributes. Additional attributes added for performance measurement purposes were added to the end of the certificate and contained 32-byte values for simplicity.