# Integrating Elliptic Curve Cryptography with the Modbus TCP SCADA Communication Protocol
## 5 Experiments, Results and Discussion
### Results
After the communication starts, the shared key is created and from this point on, every Modbus message is encrypted using only this key, with no additional information exchange being necessary. During each session, the client can send any number of encrypted messages to the server. Thus, the small overhead imposed by our modification on the standard Modbus library depends only on the number of new session establishments between a client and a server and not on the duration of their subsequent interaction. \begin{table}
\begin{tabular}{c c} \hline \hline
**Equivalent EC Key/Conventional** & **Overhead (Bytes) for Storing Numbers for** \\
**Cryptography Key Sizes** & **the EC Key Size** \\ \hline
175/1044 & 22 \\
192/1293 & 24 \\
224/1853 & 29 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: EC-based vs. conventional crypto key sizes and resulting overhead. \begin{table}
\begin{tabular}{c c} \hline \hline
**Library Name** & **Size (in Kilobytes)** \\ \hline libecc-lib.so & 293.7 \\ libgmp.so & 512.5 \\ libmodbus.so & 68.8 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Sizes of compiled libraries. As for the additional execution time induced by the modified key exchange algorithm, it was measured as a function of the key size, for every Modbus function affected by our modifications. To calculate the average execution time of Elliptic Curve Diffie Hellman for each key size, we measured the time needed for the key establishment, for 100 consecutive sessions. The result for each key size was the average value of these measurements. The results are shown in Table 5 and Figure 6.  
We observe that the performance degrades as the size of the finite field is increased. However, the degradation is not significant. Considering that a size of 192 bits (24 bytes) is, usually, adequate in several practical cases, this choice could offer the best solution in terms of performance and security. In addition, the execution times of the encryption and decryption functions were measured. We present the time measurements in Figures 7 and 8. Our goal was to observe the delay that the encryption and decryption operations added to a specific Modbus function and assess the impact of our modifications on the communication efficiency between client and server. The function that was tested was the \"modbus_write_bit\" function (for a detailed description of the function, see the Modbus library documentation available at [36]). \begin{table}
\begin{tabular}{c c} \hline \hline
**Key Size (Bytes)** & **ECDH Time (s)** \\ \hline
22 & 0.004486 \\
24 & 0.004715 \\
28 & 0.008835 \\
48 & 0.009598 \\
64 & 0.010705 \\
128 & 0.010904 \\ \hline \hline \end{tabular}
\end{table} 
Table 5: ECDH times in relation to key size. Figure 6: Execution times for corresponding key lengths. It is apparent that for both functions, i.e., encryption and decryption, the performance is not very sensitive to the size of the finite field. The cause of this similarity in the execution times is that both encryption and decryption use the one-time pad with bitwise XOR to produce the ciphertext and plaintext, respectively. XOR, as a bit-wise operation, is very fast to compute on the hardware level almost independently of the size of the operands (unless they are very large, requiring repeating the operation several times sequentially). Consequently, selecting the finite field size is of concern only in relation with the other requirements (mainly overhead and performance) for the key establishment phase. To provide a more accurate, comparative, assessment of the new version of the library, the execution time for all Modbus functions was measured for, both, the original Modbus library, and the secure version. The results are shown in Figure 9.  
Figure 8: Execution times for decryption. Figure 7: Execution times for encryption. It is evident that the overhead induced by our library on the original Modbus is very small and can be tolerated in exchange of the important security benefits offered by EC-based cryptography.