# Integrating Elliptic Curve Cryptography with the Modbus TCP SCADA Communication Protocol
## 4 Architecture and Implementation  
As stated in the introduction, for our implementation we used an open-source Modbus library. We chose Modbus because it is one of the most common protocols used in industrial networks and is supported by a variety of devices in those networks. Modbus is an application-layer protocol and has a client/server architecture. It enforces communication between devices connected on different types of communication channels. For example, a few devices might be connected using serial buses to the network and others may have TCP connections to connect to the network. The TCP version of the protocol enables Modbus devices to be accessed through the Internet using the reserved 502 port. Modbus uses several function codes for its services. Each function code can result in a different action by a PLC or an actuator. It supports request/reply communication during which the client sends a request to the server and the server send a reply with a data or a confirmation. To modify the library, the first consideration was the level of the library where our new security mechanisms would be placed. It was deemed appropriate that the mechanisms should be placed on a relatively low level. This served the purpose of keeping the same functionality on the higher level of Modbus functions, thus achieving interoperability with existing installations (our Modbus variant is a \"plug-in\" replacement of the initial Modbus variant). Thus, the general architecture of a SCADA application based on the modified Modbus architecture is shown in Figure 2.  
The shaded parts are the ones which we have modified: the lighter shaded part represents the modifications related to the handshake protocols so as to deploy the incorporated security mechanisms while the darker shaded part represents the implemented security mechanisms. We should emphasize that we have not altered the upper layers, i.e., The application and the core function layers, so that our modified libraries can be incorporated directly, as a \"plug-in\", in existing Modbus implementations without and changes in the way that applications interact with the libraries. Figure 1: Comparison of key sizes for attaining equivalent security level for EC-based (key size \(n\)) and conventional cryptosystems (key size \(N\)). The operations that were added to the Modbus protocol are the following: key generation, key distribution, message encryption and message decryption. Key generation and key distribution were implemented as separate functions of the Modbus protocol as opposed to encryption and decryption, which were included in the send and receive functions. The encryption used in the Modbus  
In our implementation, we encrypt the whole Modbus ADU. The size of the ADU is typically 260 bytes. When a request/response is, at first, created, it is stored in a uint8 array, however, to process it, it has to be converted to a multiple precision integer. The resulting number must be encrypted using the ECCLIB. To make that possible, we increased the size of the field on which the elliptic curve is defined. Consequently, larger messages could be processed by the library. The implementation of the entire mechanism was based on ECCLIB, a C library for Elliptic Curve Cryptography. A dependency graph is provided in Figure 3, to give a more detailed explanation of the structure. Again, the shaded parts are the ones which we have modified. The colored functions were either implemented or modified. The encryption function (appearing in the bottom layer) is not colored since it is used, unchanged, as implemented in the original ECCLIB. A brief description of the library's functionality and operations is provided below. We describe the additional operations that are taking place in a typical Modbus transaction. All  
Figure 3: The proposed library and its place within the Modbus protocol. Figure 2: Modified Modbus Architecture. operations, except the initial phase of parameter generation, are executed at the initiation of every new Modbus session [4; 6; 7; 9; 10; 11; 12; 14].