Design and Development of Layered Security: Future Enhancements and Directions in Transmission

Today, security is a prominent issue when any type of communication is being undertaken. Like traditional networks, supervisory control and data acquisition (SCADA) systems suffer from a number of vulnerabilities. Numerous end-to-end security mechanisms have been proposed for the resolution of SCADA-system security issues, but due to insecure real-time protocol use and the reliance upon open protocols during Internet-based communication, these SCADA systems can still be compromised by security challenges. This study reviews the security challenges and issues that are commonly raised during SCADA/protocol transmissions and proposes a secure distributed-network protocol version 3 (DNP3) design, and the implementation of the security solution using a cryptography mechanism. Due to the insecurities found within SCADA protocols, the new development consists of a DNP3 protocol that has been designed as a part of the SCADA system, and the cryptographically derived security is deployed within the application layer as a part of the DNP3 stack.


Introduction
Supervisory control and data acquisition (SCADA) systems have been accorded a prestigious status and play important roles within the real-time industrial processing and automation fields [1,2]. Along with the massive changes in the field of information technology (IT) and the increasing use of IT by humans throughout their daily lives, SCADA systems have also changed from simple stand-alone systems, or "relay logic", to network-based systems like a traditional computer network [2,3].
Typically, a SCADA system is governed by a central controller or main controller that is a part of its hierarchical network structure that is designed and configured to comprise several remote stations or remote terminal units (RTUs); these remote devices collect information from physical devices and transfer the information back to the main controller for scrutiny and control purposes [3,4]. SCADA systems; however, these solutions have several limitations due to the protocol dependency, an end-to-end-security focus, and a reliance upon the other cryptography protocols for security [5,14,49,50]. An actual security enhancement was made to conquer the security issues that usually reside in the transmissions of the SCADA system; in this enhancement, the DNP3 protocol is considered, and encryption and authentication mechanisms that modify the original frame of the DNP3 protocol are employed. The cyclic-redundancy-check (CRC) bytes are replaced with new security fields that are designated to compute the security via the cryptography mechanism. The scope of the development, however, is limited to a data-link layer, and the security development is also limited to only the provision of a stronger authentication and non-repudiation security parameters for the DNP3 protocol [59].
In conclusion, an inclusive security solution is required rather than end-to-end security to resolve these limitations and enhance the security of SCADA/DNP3-protocol communications [5,14,25,30,32,45,51]. A security solution or model has therefore been proposed to supplant end-to-end deployment and to enhance the security of the DNP3 protocol as part of a critical, infrastructural communication (or SCADA)-system-using, protocol-embedded security.

Scope of Study
In this study, a DNP3 protocol stack was designed and an inclusive security solution that uses cryptography algorithms such as AES, RSA, and SHA-2 is solely deployed at the DNP3-protocol-application layer; however, end users were allowed to deploy and test the other cryptography algorithms. The application layer is considered the most sensitive layer in the DNP3 protocol because the protocol message is generated at the application-layer level when a message is designated as sent or received, and the message is then passed to a lower level for further execution [8,10,58]. This study therefore shows the deployment of security at the application level, or the deployment of application protocol data unit (APDU) security as a part of the application layer, before the APDU bytes are transmitted to the lower layers of the DNP3 protocol as a part of the SCADA system (security) and/or open protocols. Further details are shown in Figure 1, as follows.

Research Objectives
The main objectives of this study are as follows: 1. The bytes of the application layer or the APDU bytes are fixed at the application level; the dynamic cryptography buffer (DCB) is used for the remaining bytes after the fixing process is complete. The APDU bytes are therefore readily aligned with the pseudo-transport-layer bytes or the TPDU bytes during the transmission of the message or the bytes.

Research Objectives
The main objectives of this study are as follows: 1.
The bytes of the application layer or the APDU bytes are fixed at the application level; the dynamic cryptography buffer (DCB) is used for the remaining bytes after the fixing process is complete. The APDU bytes are therefore readily aligned with the pseudo-transport-layer bytes or the TPDU bytes during the transmission of the message or the bytes. 2.
The assemblage of the protocol bytes from the lower layer to the upper layer, whereby security is implemented and tested in terms of integrity, authentication, confidentiality, and non-repudiation at the application layer of the DNP3 protocol. 3.
The proposed security development is validated using formal proofs and the performance results are evaluated with security tools. The security results are also measured during the SCADA/DNP3-protocol end-to-end communication for the purposes of a performance comparison.

Research Contribution
The contribution of this study is three-fold, as follows: a new security mechanism was designed and implemented within the original SCADA/DNP3-protocol stack; the bytes are constructed at each layer, flowed within the stack, and transmitted to/from the TCP/IP protocols at both sides or on the send/receive side.
The application-layer bytes are aligned with the pseudo-transport-layer bytes within the DNP3 stack; the remaining 56 bytes are used for the DCB. The DCB was designed and deployed to keep track of the bytes during message construction and security implementation. The new security mechanism was implemented and tested using cryptography to enhance the security of the SCADA/DNP3-protocol communications, and it also provides a platform to test and implement other cryptography approaches (or algorithms).
The security mechanism was designed and implemented according to the requirements of SCADA/DNP3 unicasting communication. Formal methods and tools have been used to validate the proposed security development and to evaluate its performance. The overall performance results were measured and evaluated after the verification of formal proofs.

Development of the Application Layer
The application layer is the highest or top layer of the DNP3-protocol stack that interacts directly with user-application programs or takes data/messages from the user-application interface/program. The application layer interacts with the user-application program and accepts user-requested data/messages depending on the requirements of the user. Data may be in any form such as digital, analog, events (or the actions performed for an event), alarms, reports, and data files. Data size is not limited in the DNP3 protocol; the DNP3-application layer takes random data from a user-application program and manipulates this data. The application layer converts the data from the user-application program into manageably sized blocks. These blocks are also referred to as application service data units (ASDUs), and each ASDU size is limited to 2046/2044 bytes in the case of a request/response [2,9].
The application layer creates APDUs by combining or adding an application header that is called "application protocol control information" (APCI). The APCI fields consist of two or four bytes depending on whether the data requests a reply back. In the proposed implementation, the APDU size is limited to 1992 bytes; if the requested/response data is larger than 1992 bytes, then more than one APDU will be created, depending on the size of the user data. In the original DNP3 documentation, the numbers of ASDU blocks are not limited but each APDU's size is limited to 2048 bytes. The APDU-buffer size is sufficient to process the entirety of the information in the data requested/received and, after processing, the buffer is discarded for the next APDU bytes [9].
The total number of user blocks in the ASDU is eight. Each block has 249 bytes of information that have been accepted from the last block because the last block has 247 bytes in the case of a request and 245 bytes in the case of a response. These blocks readily fit into the transport-protocol data units (TPDUs) of the pseudo-transport layer. A DCB is created based on the remaining 56 bytes from each ASDU and is used for storage information that is related to cryptography deployment and other service information for the development of the testbed. The fixing process for the ASDU bytes is two-fold, as follows: the APDU bytes are aligned with the TPDU bytes and the remaining 56 bytes could be used for cryptography deployment within the application layer of the DNP3 protocol. When the APDU is constructed in the application layer, the control is passed to the cryptography solution for security deployment. In Figure 2, the master terminal unit (MTU) generates the request message and sends it to the remote terminal unit (RTU) that then generates the application-level response to the MTU after it receives the request. In the case of a command execution between the MTU and RTU, the header is only transmitted without any ASDU bytes. The following two types of message headers are in the application layer of the DNP3 protocol: request and response headers. The response header has an additional two-byte field called the internal indication (IIN) that indicates the difference between the request and the response headers in the APCI. terminal unit (MTU) generates the request message and sends it to the remote terminal unit (RTU) that then generates the application-level response to the MTU after it receives the request. In the case of a command execution between the MTU and RTU, the header is only transmitted without any ASDU bytes. The following two types of message headers are in the application layer of the DNP3 protocol: request and response headers. The response header has an additional two-byte field called the internal indication (IIN) that indicates the difference between the request and the response headers in the APCI. In the application layer, the MTU is responsible for sending request messages to the RTU and the RTU is responsible for sending the response according to the MTU request; however, the DNP3-application layer has a special class of response that is used by the RTU for the purpose of sending information to its predefined master station. This special class of response is also called an "unsolicited response" and is typically based on the critical events or process changes that are detected within a communication.
In Figure 2, the highlighted part shows the confirmation set (bit) that is transmitted between the master terminal unit (MTU) and remote terminal unit (RTU) and/or vice versa. The application control (AC) is accounted as a main field of application layer header which used to control the communication between the nodes. AC contained four subfields, such as first fragment (FIR), final fragment (FIN), confirmation (CON), and sequence number and in the below communications 1 and 2 these subfields are represented in the form of [A0, A1, A2, A3] and [B0, B1, B2, B3], with distinguished set bit (i.e., CON or A2/B2 = 0 or 1). More detail is provided in the subsequent part of this paper, as follows:  In the application layer, the MTU is responsible for sending request messages to the RTU and the RTU is responsible for sending the response according to the MTU request; however, the DNP3-application layer has a special class of response that is used by the RTU for the purpose of sending information to its predefined master station. This special class of response is also called an "unsolicited response" and is typically based on the critical events or process changes that are detected within a communication.
In Figure 2, the highlighted part shows the confirmation set (bit) that is transmitted between the master terminal unit (MTU) and remote terminal unit (RTU) and/or vice versa. The application control (AC) is accounted as a main field of application layer header which used to control the communication between the nodes. AC contained four subfields, such as first fragment (FIR), final fragment (FIN), confirmation (CON), and sequence number and in the below communications 1 and 2 these subfields are represented in the form of [A0, A1, A2, A3] and [B0, B1, B2, B3], with distinguished set bit (i.e., CON or A2/B2 = 0 or 1). More detail is provided in the subsequent part of this paper, as follows: Then Confirmation: MTU_AC [B0, B1, B2 = 0, B3] } // Master station initialized the request with the confirmation set (bit) and the RTU also sends the confirmation message. Afterward, the RTU will send a response with a confirmation set (bit) upon receipt and the MTU also sends the confirmation to the RTU.
When the MTU sends a request message to the RTU with a confirmation bit, upon the receipt of the message, the RTU also sends an acknowledgment (message) to the MTU. The RTU assembles the necessary information related to the requested message; once the message is ready, then it is sent to the MTU. The MTU also sends a confirmation (message) if the confirmation bit is set in the response (message). In a SCADA system, communication between field devices is either in the form of commands or data. Usually, the RTU will generate the data response according to the MTU commands. The message or data always contains specific data objects and function codes that are added at the start of a communication-message request or response. The SCADA/DNP3 protocol provides reliable communication between different vendor's devices and makes data meaningful across several platforms. The following sections are the core application-layer functions that have been used during message construction, and the types of information such as the function code and data objects that are involved in communication.

Application Protocol Control Information
The application header is also called the application protocol control information (APCI). APCI has two-byte fields for a request header and a four-byte length field for a response header, whereby the request and response headers differ by two bytes in the application layer. The response header has an additional two-byte field, designated as the IIN, which distinguishes between the request and response headers in the APCI. Figure 3 shows the APCI or the case of APCI bytes being sent, while Figure 4 shows the APCI or the case of an APCI-byte response. } // Master station initialized the request with the confirmation set (bit) and the RTU also sends the confirmation message. Afterward, the RTU will send a response with a confirmation set (bit) upon receipt and the MTU also sends the confirmation to the RTU.
When the MTU sends a request message to the RTU with a confirmation bit, upon the receipt of the message, the RTU also sends an acknowledgment (message) to the MTU. The RTU assembles the necessary information related to the requested message; once the message is ready, then it is sent to the MTU. The MTU also sends a confirmation (message) if the confirmation bit is set in the response (message). In a SCADA system, communication between field devices is either in the form of commands or data. Usually, the RTU will generate the data response according to the MTU commands. The message or data always contains specific data objects and function codes that are added at the start of a communication-message request or response. The SCADA/DNP3 protocol provides reliable communication between different vendor's devices and makes data meaningful across several platforms. The following sections are the core application-layer functions that have been used during message construction, and the types of information such as the function code and data objects that are involved in communication.

Application Protocol Control Information
The application header is also called the application protocol control information (APCI). APCI has two-byte fields for a request header and a four-byte length field for a response header, whereby the request and response headers differ by two bytes in the application layer. The response header has an additional two-byte field, designated as the IIN, which distinguishes between the request and response headers in the APCI. Figure 3 shows the APCI or the case of APCI bytes being sent, while Figure 4 shows the APCI or the case of an APCI-byte response.  The first byte of the APCI request or response is designated as the application control (AC). The communication between the MTU and RTU is controlled by the AC field. The AC field carries one byte of information, having three bits or flags, such as FIR, FIN, and CON, and a five-bit sequence number that is used to move fragments (or APDUs) in a sequential order.
In MTU/RTU communication, if the MTU sets the confirmation bit as CON = 1 within the requested message, then the RTU will also be responsible for sending a confirmation within the response message with the same sequence as the MTU-requested sequence number. In a case where multiple messages are received by the MTU/RTU with the same sequence number, then the second number will be ignored and the first one will be accepted; if nothing is received by the MTU/RTU, } // Master station initialized the request with the confirmation set (bit) and the RTU also sends the confirmation message. Afterward, the RTU will send a response with a confirmation set (bit) upon receipt and the MTU also sends the confirmation to the RTU.
When the MTU sends a request message to the RTU with a confirmation bit, upon the receipt of the message, the RTU also sends an acknowledgment (message) to the MTU. The RTU assembles the necessary information related to the requested message; once the message is ready, then it is sent to the MTU. The MTU also sends a confirmation (message) if the confirmation bit is set in the response (message). In a SCADA system, communication between field devices is either in the form of commands or data. Usually, the RTU will generate the data response according to the MTU commands. The message or data always contains specific data objects and function codes that are added at the start of a communication-message request or response. The SCADA/DNP3 protocol provides reliable communication between different vendor's devices and makes data meaningful across several platforms. The following sections are the core application-layer functions that have been used during message construction, and the types of information such as the function code and data objects that are involved in communication.

Application Protocol Control Information
The application header is also called the application protocol control information (APCI). APCI has two-byte fields for a request header and a four-byte length field for a response header, whereby the request and response headers differ by two bytes in the application layer. The response header has an additional two-byte field, designated as the IIN, which distinguishes between the request and response headers in the APCI. Figure 3 shows the APCI or the case of APCI bytes being sent, while Figure 4 shows the APCI or the case of an APCI-byte response.  The first byte of the APCI request or response is designated as the application control (AC). The communication between the MTU and RTU is controlled by the AC field. The AC field carries one byte of information, having three bits or flags, such as FIR, FIN, and CON, and a five-bit sequence number that is used to move fragments (or APDUs) in a sequential order.
In MTU/RTU communication, if the MTU sets the confirmation bit as CON = 1 within the requested message, then the RTU will also be responsible for sending a confirmation within the response message with the same sequence as the MTU-requested sequence number. In a case where multiple messages are received by the MTU/RTU with the same sequence number, then the second number will be ignored and the first one will be accepted; if nothing is received by the MTU/RTU, The first byte of the APCI request or response is designated as the application control (AC). The communication between the MTU and RTU is controlled by the AC field. The AC field carries one byte of information, having three bits or flags, such as FIR, FIN, and CON, and a five-bit sequence number that is used to move fragments (or APDUs) in a sequential order.
In MTU/RTU communication, if the MTU sets the confirmation bit as CON = 1 within the requested message, then the RTU will also be responsible for sending a confirmation within the response message with the same sequence as the MTU-requested sequence number. In a case where multiple messages are received by the MTU/RTU with the same sequence number, then the second number will be ignored and the first one will be accepted; if nothing is received by the MTU/RTU, then the request will be transmitted again. The sequence number is incremented with the APDU increments, and the response-APDU sequence number is the same as the requested-APDU sequence number.
The first APCI field is used to manage the communication flow and the second field is designated a function code (FC); the FC carrys one byte of information that is used to define the actual meaning of the message/data to be sent/received between the MTU and RTU. Data is the most important part of SCADA/DNP3 communication. As previously mentioned, the DNP3 protocol is designed to manipulate different types of data, such as digital, analog, event or an action performed for an event, alarms, reports, and data files. The DNP3 protocol not only provides reliable communication between field devices that are connected in a SCADA network, but it also makes the data meaningful across different networks to understand the meaning and purpose of the message.
In the second APCI field, the function codes are used to define or identify specific functions for the data that are being operated or the function that is used to perform with the data. Some function codes are limited to the specific data on which they operate; therefore, data-object references are also included within the ASDU.
The IIN field that is used in the response header (or APCI) contains two bytes of information followed by a function code, and it is used for sending a response to a desired station. Each bit inside the IIN field has a specific meaning for the purposes of response-message generation, usually from the RTU to the MTU. The RTU-response message defines the flags that correspond to the IIN field that are copied in the message each time the message is sent from the substation to the master station. Using the IIN field in the response header, the substation will then report to the master station. In a SCADA system, the sent/received message carries commands and sometimes data as a response from the RTU, whereby the data is composed of function codes and data objects. The FC defines the meaning and uses of the bytes (or message) in the DNP3 protocol and the data objects define the structure and the data interpretation process.

Application Service Data Unit
As discussed, there are two types of data/message communications within a SCADA system such as a request from the MTU, a response from the RTU, and/or an unsolicited response. Each time, one or more APDUs are created, depending on the size of the user data that is being requested/responded to. If more than 1992 bytes with a header are sent from the MTU, then multiple APDUs are generated and transmitted in a sequential order. Each APDU is represented as a fragment with fields such as APCI and ASDU. The ASDU is made up of data objects and each data object is followed by an object header. In the ASDU field, the proposed research logically fixed the number of data blocks at 8 and each block is 249 bytes, with the exception of the last block; furthermore, the proposed research logically fixed the ASDU size up to 1990 bytes in the case of a request and 1988 bytes in the case of a response.
Here, each data block (or block) of an ASDU contains an object header and data objects. Through logical fixing of the ASDU, the data blocks easily fit into (or align with) the transport protocol data units (TPDUs) in the pseudo-transport layer of the DNP3 protocol; for example, the 1992 bytes of APDU are transmitted and are treated as user bytes in the pseudo-transport layer. The bytes of the transport service data unit (TSDU) are assembled and then converted into 8 data blocks, and 1 byte of header information is added to each data block resulting in the formation of 8 TPDUs. Because the lower layer (or data-link layer) only carries up to 250 bytes from the pseudo-transport layer, the logical fixing process of the ASDU is two-fold, as follows: 1) The APDU bytes (or 1992 APDU bytes) are aligned with the TPDU bytes in the pseudo-transport layer. 2) The remaining 56 bytes (from the total of 2048 APDU) are used for the DCB. In the original DNP3 documentation, the user-data blocks are not fixed.
In the ASDU, each data block is composed of the following two subfields: object header and data object. Each ASDU field is composed of one or more data blocks, but the blocks are logically limited to 8 (blocks) and the maximum ASDU size is up to 1990 bytes/1988 bytes in the case of a request/response. Figure 5 shows the request/response ASDU structure (or new, fixed ASDU blocks) with subfields such as "object header" and "data object".
The object header specifies the data-object type and the instance of data that is being referenced by the message. The object header is made up of the object, qualifier, and range fields between 3 bytes and 11 bytes of length. request/response. Figure 5 shows the request/response ASDU structure (or new, fixed ASDU blocks) with subfields such as "object header" and "data object". The object header specifies the data-object type and the instance of data that is being referenced by the message. The object header is made up of the object, qualifier, and range fields between 3 bytes and 11 bytes of length. In the ASDU, "object header", "qualifier", and "range" fields are used to identify the specific data points of each object group, and the variations that are being referred to as data are used on both the sender and receiver sides. In a request message, only the data identification will be required and data objects are included in response messages from the substation. The qualifier field is composed of the qualifier code or "Q-code", the index size or "I-size", and provides the qualifier-code value. The qualifier field with the range field works to fully identify the data objects that follow each object header in the ASDU. In the object header, the object field is subdivided into two fields such as the object group that defines the general type of data and the object variation that defines a particular variation of data and up to 2 bytes of length.

System Model: Application Layer Development
This study used the open library of the DNP3 protocol and the explicit codes were deployed, thereby finalizing the proposed system's design and development. To validate the proposed application-layer (message) design and development, Postulate 1 to Postulate 4 were employed, and these are further used for the verification of the algorithm and during the security-development phase. The basic notations that are used in this section are summarized in Table 1.   In the ASDU, "object header", "qualifier", and "range" fields are used to identify the specific data points of each object group, and the variations that are being referred to as data are used on both the sender and receiver sides. In a request message, only the data identification will be required and data objects are included in response messages from the substation. The qualifier field is composed of the qualifier code or "Q-code", the index size or "I-size", and provides the qualifier-code value. The qualifier field with the range field works to fully identify the data objects that follow each object header in the ASDU. In the object header, the object field is subdivided into two fields such as the object group that defines the general type of data and the object variation that defines a particular variation of data and up to 2 bytes of length.

System Model: Application Layer Development
This study used the open library of the DNP3 protocol and the explicit codes were deployed, thereby finalizing the proposed system's design and development. To validate the proposed application-layer (message) design and development, Postulate 1 to Postulate 4 were employed, and these are further used for the verification of the algorithm and during the security-development phase. The basic notations that are used in this section are summarized in Table 1. p f OH , f OD q f ASDU pXq or ASDU bytes that are computed by the following functions: p f OH , f OD q, in the case of sending(S)/responding(R). px 5 , x 6 , x 7 , x 8 q Parameters of function f ASDU pXq, such that f OH , f OD P f ASDU .
px 5.1 , x 5.2 q , px 6.1 , x 6.2 q px 5.1 , x 5.2 q are implied for object function(of) and px 6.1 , x 6.2 q are implied for object qualifier ( oq ) f L pX d q Function that logically fixed the ASDU bytes into data blocks (DB). Postulate 1. The number of bytes X is defined and received from the user-application layer through the use of function f µ . The function f APDU P f µ exists and is performed at both sides of the transmission with the usage of the distinct identifiers α P pS; Rq, and simultaneously interacts with and is updated in the dynamic storage as a part of the protocol stack. The random bytes X are retrieved from the user-application layer by performing the function f µ that is designated to check the bytes X that are limited by the proposed development. In the case of the sending (S)/responding (R) APDU bytes, the functions f ASDU and f APCI are employed to compute the ASDU bytes (X d ), the APCI bytes (X h ), and p f ASDU , f APCI q P f APDU . In the case where a number of fragments are required in the transmission, then f APDU P f APDU n and n = 1, 2, 3, . . . , k, where k is the limited integer. Moreover, the computed bytes are simultaneously updated by the employment of function f dy and the designation of X dy . The computed fragment pFragq with the concatenation ( ||q of dynamic bytes can be demonstrated as where limit is a maximum value depending on the size of the bytes that are specified for a fragment. In the case of sending fragment, In the case of a response fragment, To compute the header (h) bytes, the AC function f AC and its parameters are as follows: rx 1 , x 2 , x 3 x 4 s "" rSequenceNumber, Confirmation, FIN, FIRs. The function f FC with its parameter-request code (im) and/or response code (ex) are performed in the case of sending (S) a fragment, while the difference of the two-byte I I N is counted via the function f I I N during the responding (R) fragment. Postulate 3. The protocol-data bytes are computed using the employment of the functions f OH and f OD P f ASDU , if, and only if, the parameters px 5 , x 6 , x 7 , andx 8 q are satisfied; a difference of two bytes exists in the response case.
For the ASDU bytes, the object header ( OHq function f OH with its parametersrx 5 , x 6 , x 7 s "" rObjectFunction pof q , ObjectQualifier poqq , ObjectRange porqs, and the data object (DO) function f DO with its parameter [x 8 ] == [user bytes (ub)] are computed in the case of sending (S)/responding (R), but a two-byte difference is accounted for in the responding (R) case that ensures the total size. Here, rx 5.1 , x 5.2 s "" rObjectGroup pogq , ObjectVariation povqs are implied for the object function (o f ) and rx 6.1 , x 6.2 s "" rQualifiercode pqcq , IndexSize pisqs are implied for the object qualifier (oq). Postulate 4. The function f L is an explicit, dual logical-distribution function if it is operated on bytes X, and X are retrieved from function f µ , as follows: f µ ñ @X αPpS;Rq ñ f ASDU pXq ñ X d ñ f L pX d q ñ f L pX d q « ÿ r i"1 pDBq i , i " 1, 2, 3, . . . r here, the ASDU bytes are logically pLq fixed into the data blocks (DB) but the bytes vary in the cases of sending and responding, and r is represented for the logical 8 blocks in the case of a full fragment (i.e., 1992 bytes and f ASDU P f APDU ).

1.
Define and manage the number of user layer bytes , X, X α , α P pS; Rq ;
While there is application protocol data unit (APDU) computed bytes ( X h , X d q,α P pS; Rq ; 6. Security is computed by employing of cryptography functions, Symmetric (Symqfunction, Asymmetric (Aymq function, Hashing (H) function; 7.
If Eny pAPDUq bytes are received at target side. Then 9.
If Dny rMs is performed. Then 12.
( X h , X d q are reassemble to bytes X; 13.
End while

Implementation
The aim of this work is to design the DNP3 stack and to deploy the security algorithm(s) within the protocol; therefore, the DNP3 stack has been designed by the deployment of explicit (or real) functions in the C# programming platform, while the historian (or database) was deployed by using the MySQL tool. Several approaches [1,3,[5][6][7]14,15] were analyzed against the SCADA/DNP3 in terms of security but they are based on end-to-end developments. DNP3 is a proprietary protocol and is situated at the top of the TCP/IP protocols for Internet-based communication [5,8,9,14,15,[57][58][59][60]. Security is a major issue that has been faced by the DNP3 protocol since Internet-based communication has occurred through open protocol(s). This work therefore proposes a new approach that deploys the security within the DNP3 protocol before the transmission of bytes to non-proprietary protocols such as TCP/IP and UDP.
In the implementation phase, the design of the DNP3 stack is also a major challenge, and the deployment of security using a strong mechanism that has the potential to secure the SCADA/DNP3 transmission against attacks is required. The first challenge was resolved by the design of the DNP3 stack and its relevant functions in C# using implicit/explicit libraries and functions. Prior to the security-implementation phase, another major challenge is the storage, updating, and maintenance of the security tracks with the corresponding stack information during the real-time delivery of bytes. To resolve this challenge, the DCB is deployed and employed during the entire development stage. The DCB contains the numbers of the dynamic functional fields that successfully control the security operations and stack relevant information.

Dynamic Cryptograph Buffer
During the security-development phase, the DCB was employed to store the corresponding information of the security implementation and the flow of bytes within the stack. In Figure 6, the original DCB size is 56 bytes but this is likely to be dynamic due to the APDU-manipulated bytes. The DCB contains the number of functional fields with a variety of storage sizes that have been employed to keep the security tracks of the implementation and other related stack information. The performance results evaluated that the original DCB space (56 bytes) is sufficient for overall information storage, even in a case where the application stack is full or corresponds to the maximum number of bytes.

Dynamic Cryptograph Buffer
During the security-development phase, the DCB was employed to store the corresponding information of the security implementation and the flow of bytes within the stack. In Figure 6, the original DCB size is 56 bytes but this is likely to be dynamic due to the APDU-manipulated bytes. The DCB contains the number of functional fields with a variety of storage sizes that have been employed to keep the security tracks of the implementation and other related stack information. The performance results evaluated that the original DCB space (56 bytes) is sufficient for overall information storage, even in a case where the application stack is full or corresponds to the maximum number of bytes. The bytes have been encrypted and the corresponding information is updated within the DCB. The "user bytes field" in the DCB is a dynamic storage field that specifies the byte sizes (or the APDU bytes) that are being employed after the development of the security process. The additional space is dynamically allocated to the "cryptography: dynamic storage" field in the DCB by the operation of the "byte-shifting function". The initial size of the "cryptography: dynamic storage" is 16__56 in DCB, but this would be increased by the indication from the "user bytes field"; subsequently, if these bytes are not required by the DCB, then these are treated as padding bytes (or shifted to "padding field").
This operation also indicates that the overall message is constructed and prepared for transmission while the message contents are verified by an operational field called "Optional". A two-byte (unassigned) acknowledgment field has been employed to monitor the delivery of a message during transmission. This field contains two flags such as ACK: flag (0): bytes delivery without acknowledgment, and ACK: flag (1): bytes delivery with acknowledgment. The bytes have been encrypted and the corresponding information is updated within the DCB. The "user bytes field" in the DCB is a dynamic storage field that specifies the byte sizes (or the APDU bytes) that are being employed after the development of the security process. The additional space is dynamically allocated to the "cryptography: dynamic storage" field in the DCB by the operation of the "byte-shifting function". The initial size of the "cryptography: dynamic storage" is 16__56 in DCB, but this would be increased by the indication from the "user bytes field"; subsequently, if these bytes are not required by the DCB, then these are treated as padding bytes (or shifted to "padding field").
This operation also indicates that the overall message is constructed and prepared for transmission while the message contents are verified by an operational field called "Optional". A two-byte (unassigned) acknowledgment field has been employed to monitor the delivery of a message during transmission. This field contains two flags such as ACK: flag (0): bytes delivery without acknowledgment, and ACK: flag (1): bytes delivery with acknowledgment.
During security implementation, the following three types of algorithms were employed: symmetric AES algorithm, asymmetric RSA algorithm, and SHA-2 hashing algorithm. The corresponding keys are generated, deployed, and added in distinct sequence numbers. Each time that a message has been encrypted/decrypted, the counter is incremented and the value is added in the "Cryptography Key Sequence" field. Two explicit flags such as flag (0): Security__Fail and flag (1): Security__Pass were also employed to monitor the status of the security development. Two especial fields are used in the DCB and are designated as Critical (bytes) and Non-Critical (bytes), these are observed to report the transmission status during abnormal/normal scenarios.
The request and response headers are distinct and are defined at the application layer, and the corresponding addresses, such as the source and destination addresses, are defined in the link header or link-protocol-control information (LPCI) at the data-link layer as a part of the DNP3 protocol. In this study, security is deployed on the APDU bytes in a case where the APCI is not encrypted, so there are many chances of attacks, such as header modification and alters, header reply, header deletion, and/or other integrity and authentication attacks [56,57,59].
To resolve this issue, four bytes are used from "cryptography: dynamic storage" as a part of the DCB; in cases where the request or response APCI is not readable at the lower layers and/or at the target side due to encryption, the designated four bytes are employed to define the external application-layer header (or APCI) that travels along with the encrypted message (or APDU). This approach is significant when the adversary successfully modifies and/or alters the APCI information (or external APCI information) because, at the target side, the external APCI information will be verified after a comparison with the encrypted APCI as a part of APDU encryption process. This approach would also be significant and provides the future security directions for the data-link layer of the DNP3 protocol [5,59]; in this case, the LPCI will be encrypted and required to define the external addresses, and the allocated four bytes of the source address and destination address (fields) in the DCB would be used for that purpose.
According to the SCADA/DNP3 transmission requirements, a variety of cryptography methods that do not interfere with the communication process have been analyzed to achieve enhanced security results. A cryptography key method has been deployed to save the session during the encryption/decryption process. In this method, the user bytes (or APDU bytes) are not encrypted, and only the key is appended with the desired bytes that minimize the computation time during a security development. The following function shows the encryption/decryption of protocol bytes by using the key-appended method (AP): where the symmetric pSymq function ( f Sym ) is employed, and the secret key SC k S is appended (AP) with the fragment (Frag).
A field designated "Solution: Select Method" has been employed within the DCB and reports the security method(s) and the relevant algorithms being used for the secure communication process. Based on SCADA/DNP3 communications including unicasting, multicasting, and broadcasting and their requirements, the security is best designed, deployed, and reported by the "Solution: Select Method" field. This functional field dynamically selects the security solution(s) according to the requirements of a SCADA/DNP3 communication; for example, in multicasting and broadcasting, the asymmetric algorithms are not appropriated because of the number of keys that are required with heavy session(s) during security deployments; therefore, symmetry-based cryptography solutions are convenient for these kinds of transmissions.

Cryptograph
In the SCADA/DNP3 testbed, the historian shares among the configured nodes (or MTU/RTU) via the secure channels that are established between them. The historian has a number of fields including the "MTU public key", "RTU public key", "shared secret key", "MTU/RTU IP addresses", and "logical port numbers". Cryptography keys are generated and employed in the desired fields with identifiers so that K Ñ 0x0001, 0x0002, . . . .., k´1 and, further, would be deployed during encryption/decryption processes.
The SCADA/DNP3 protocol contains the relevant functions including "read", write", select", and "operate" with the specified codes [8,9,52]. The security implementation (using a cryptography mechanism) is two-fold: the security has been deployed in correspondence to each protocol function, and computed bytes are transmitted from the application layer of the DNP3 protocol. The security was deployed and reacted as an additional layer that is designated as a security layer for testing the APDU bytes; that is, the APDU bytes are constructed and encrypted at the security layer and upon the receipt of the bytes, a decryption process can be performed at that layer. This security layer acts as a safeguard for APDU bytes, and this implementation has been selected as a strong security development against the application layer attacks as a part of the DNP3 protocol. The details are related to the following of the encryption and decryption processes and, to be convenient, the basic notations that were used during the encryption/decryption processes are summarized in Table 2.  f Ass Assemble (Ass) function f Ass is used to assemble the constructed application-layer bytes pX h , X d qto the lower-layer bytes pYq.
f Rss Reassemble (Rss) function f Rss is used to reassemble the protocol bytes (X h , X d q with the user-layer bytes X. Encryption 1: MTU uses a secret key from the historian that is generated by using the AES algorithm and also encrypts the APDU bytes using this key « W 1 . The APDU bytes or pAPDUq n are then subjected to the SHA-2 hashing algorithm for an integrity value check; therefore, pAPDUq n uses the input for the SHA-2 hashing algorithm to generate a hash value; it is also represented as pAPDUq n digest or pAPDUq n _DIGEST. When the hashing process is complete, the SHA-2 hashing algorithm followed by the pAPDUq n _DIGEST is encrypted with the private key « W 2 that was generated from the RSA algorithm. This process produces a digital signature to verify the non-repudiation security (service). After this, the functions W1 and W2 are concatenated with each other and are then encrypted again with a public key of RTU, using the RSA algorithm. The completion of this process produces the new function "Total_Payload". The encryption information is updated in the DCB and Figure 7 shows the cryptography implementation during the encryption process.  The symmetric encryption function is deployed on the APDU bytes including the number of fragments ( ) that have been received and manipulated with encryption. To distinguish a successful encryption operation from the others, ≈ is initialized and shows the successful work that is completed after an encryption process. The digital signature is formed by the encryption of the hash-digest bytes, and W2 ≈ is designated for the work done after the completion of the encryption process via the asymmetric ( ) function and the hashing ( ) function . The hashing function is deployed first and the digital signature is then produced after the deployment of the sender ( )′s private key on hash value, as follows: The message ( ) is computed by the employment of the target ( ) public key on and via the asymmetric-encryption function . so that ( , , ) ∈ , ( , , ) ∈ , and ≈ == Total Decryption 1: The RTU receives a Total_Payload from the lower layer of the DNP3 protocol and before a conversion to the application-layer fragment or APDU bytes, Total_Payload is treated first with the cryptography solution for the purposes of the decryption process. The RTU uses a private key that is generated by the RSA algorithm and decrypts the Total_Payload. Here, the generated function W1 is subjected to decryption by using the AES algorithm. The MTU and RTU have been sharing the secret key via a secure channel that has been established between them; therefore, the function W1 is decrypted successfully before the APDU bytes are reformed. When the whole decryption process has been completed successfully and the APDU bytes are reformed, the APDU bytes are then subjected to the SHA-2 algorithm for an integrity value check;  The symmetric encryption function f Sym is deployed on the APDU bytes including the number of fragments pAPDUq n that have been received and manipulated with encryption. To distinguish a successful encryption operation from the others, W 1 « M 1 is initialized and shows the successful work that is completed after an encryption process.
ô Eny`f Aym ; f H˘ñ Eny pAym;Hq The digital signature is formed by the encryption of the hash-digest bytes, and W 2 « M 2 is designated for the work done after the completion of the encryption process via the asymmetric pAymq function f Aym and the hashing pHq function f H . The hashing function f H is deployed first and the digital signature is then produced after the deployment of the sender pSq's private key Pr k S on hash value, as follows: The message pM 3 q is computed by the employment of the target pTq public key Pu k T on M 1 and M 2 via the asymmetric-encryption function f Aym , so that (M 1 ,M 2 , M 3 ) P M, (W 1 , W 2 , W 3 q P W, and M « W "" Total PayloadpT pyq "" Eny pAymq " Pu k T pW 2 ||W 1 q ‰ , and the payload iscomplete after the encryption process.
Decryption 1: The RTU receives a Total_Payload from the lower layer of the DNP3 protocol and before a conversion to the application-layer fragment or APDU bytes, Total_Payload is treated first with the cryptography solution for the purposes of the decryption process. The RTU uses a private key that is generated by the RSA algorithm and decrypts the Total_Payload. Here, the generated function W1 is subjected to decryption by using the AES algorithm. The MTU and RTU have been sharing the secret key via a secure channel that has been established between them; therefore, the function W1 is decrypted successfully before the APDU bytes are reformed.
When the whole decryption process has been completed successfully and the APDU bytes are reformed, the APDU bytes are then subjected to the SHA-2 algorithm for an integrity value check; therefore, the APDU bytes are used as an input for the SHA-2 hash algorithm and generate a hash digest.
When the MTU/RTU hash-digest values have been matched successfully, the APDU bytes are then accepted and the integrity of the APDU bytes is also verified. Otherwise, the APDU bytes are rejected in the application layer on the RTU side and an acknowledgment will be sent from the RTU to the MTU to correct the APDU bytes, or to raise an alert regarding an attack. Figure 8 illustrates the cryptography implementation during the byte-decryption process.
Sensors 2016, 16, 37 15 of 22 therefore, the APDU bytes are used as an input for the SHA-2 hash algorithm and generate a hash digest.
When the MTU/RTU hash-digest values have been matched successfully, the APDU bytes are then accepted and the integrity of the APDU bytes is also verified. Otherwise, the APDU bytes are rejected in the application layer on the RTU side and an acknowledgment will be sent from the RTU to the MTU to correct the APDU bytes, or to raise an alert regarding an attack. Figure 8 illustrates the cryptography implementation during the byte-decryption process. public key and the target ( ) private key , via an asymmetric algorithm. As a consequence, we get the sender (S) hash value ( _ ) of the fragment and the encrypted value via a shared secret key (i.e., == ). ⟹ ( ) { } ⟹ Frag is the decryption process that is performed using the target ( ) secret key ( ) from the symmetric algorithm. As a consequence, the following fragment is obtained:  ñ Dny pAymq "`P u k S ; Pr k T˘t T pyu ı is the decryption process that is performed using the SenderpSq public key Pu k S and the target pTqprivate key Pr k T , via an asymmetric algorithm. As a consequence, we get the sender (S) hash value pH_Digestq S of the fragment and the encrypted value W 1 via a shared secret key (i.e., SC k S "" SC k T q.
ñ Dny pSymq " SC k T tW 1 u ı ñ Frag is the decryption process that is performed using the target pTqsecret key pSC k T qfrom the symmetric algorithm. As a consequence, the following fragment is obtained: The hash value is calculated at the target pTqside by byt.H T rpFragq S s Ñ pH_Digestq T , and the value is then compared with the sender pSq hash value pH_Digestq S , using a comparison of the pCPq function f CP . Such is the f CP pValq that if the computed hash values (val) are equal then the bytes are accepted; otherwise, these are rejected with the reply message "unauthorized bytes".
After the decryption process, the APDU bytes that would be (further) used by the user-application layer are reassembled. To validate the APDU reassembling process at the receiver side, Postulate 7 is employed, while Postulate 8 validates the overall proposed security design and development. To be convenient, the basic notations of Postulate 7 are summarized in Table 2, while the notations used for Postulate 8 are summarized in Table 1 to Table 2.
Postulate 7. Suppose the protocol bytes are assembled according to the use of the assembled function f Ass : f Ass Ñ Y, then the reassemble function f Rss : f Rss Ñ X reassembles the protocol bytes (X h , X d q with user-layer bytes X.
The mapping function is represented by f pMPq 3 : After the decryption process of Postulate 6, the function f Rss is employed to reassemble the protocol bytes (X h , X d q with the user-application layer bytes X, as follows: Then, the function f Rss reassembles with the interaction of the bytes X ph,dq and f Rss´Xph,dq¯: X h " f Rss´Xph,dq¯ı X d . Here, the header bytes pX h q are split from the ASDU bytes ( X d q and the user-application-layer bytes are reformed; however, the assemble function f Ass : f Ass Ñ Y, is used to assemble the constructed application-layer bytes pX h , X d q with the lower-layer bytes pYq. Postulate 8. The function f µ defines the number of bytes X from the user layer, and these bytes are constructed (X h , X d , dynmaicbytesX dy , identifier α) and manipulated using the security function f Hy : f Eny{Dny Ñ ( f Sym ; f Aym ; f H q. @X αPpS;Rq are "n" bytes of information (with the appropriate function code and data object) that are passed from the user-application layer, such that: @X αPpS;Rq ñ Frag " f APDU pXq " f APCI pXq`f ASDU pXqˇˇˇˇX dy . . . . . . Postulate 1 ô p f AC , f FC , f I I N q P f APCI ñ f APCI pXq ñ X h^p f OH , f OD q P f ASDU ñ f ASDU pXq ñ X d . . . . . . Postulates 2 and 3.
The bytes X are retrieved from the user-application layer, and the further function f APDU pXq is deployed to compute the application-layer fragment pFragq with the concatenation (||q of the dynamic bytes X dy . Moreover, the function f APCI pXq is employed for the APCI bytes (X h ) and interrupted or detected during the transmission of APDU bytes in the absence of the proposed security development [8,61]. As a consequence, 5 percent of security has been computed from the total of 100 percent (i.e., 95 percent attack detection and 5 percent security), which shows that a security mechanism that secures the SCADA/DNP3 system against potential attacks is required. tools such as sniffer/dsniff, cracking tools, ethereal, ettercap, aircrack, airsnort, dinject/reinject, injection/jamming tools, and/or attack-detection mechanisms [54][55][56][57][60][61][62][63][64][65][66][67][68][69][70][71]; this resulted in an abnormal transmission (or attack transmission) for the SCADA/DNP3 system and the system performances were also measured in the absence of security development. Some attack tools are designated, however, and can be used for wireless transmissions, and we also employed and tested the testbed under the wireless-connectivity condition [72][73][74]. As far as the performances of Figure  11 show, 95 percent of attacks are successfully interrupted or detected during the transmission of APDU bytes in the absence of the proposed security development [8,61]. As a consequence, 5 percent of security has been computed from the total of 100 percent (i.e., 95 percent attack detection and 5 percent security), which shows that a security mechanism that secures the SCADA/DNP3 system against potential attacks is required. Figure 9. Security test using embedded DNP3 security. Figure 9. Security test using embedded DNP3 security. Under the second consideration, the proposed security development is used and the APDU bytes were successfully transmitted between the participant nodes on 300 occasions, and the security operations were computed at sides such as the encryption operation and the decryption operation. Each time that the APDU bytes were sent and received between the participant nodes, the encryption and decryption operations were verified by the examination that was conducted by the security development. Among the successful experiments, 200 were selected as the most favorable performance tests; further, attack scenarios were launched and 200 selected experiments were again performed with the measurements of the security [5,56,57]. Figure 9 shows the number of attacks that were observed in the testbed according to the marker indications of the byte flow that is represented by the green lines. The green lines show the flow of traffic that corresponds to the random size fragments, but each fragment is limited to 1992 bytes. As a consequence, one authentication attack and one confidentiality attack were detected and observed for a computation of the total security percentage (99 percent in the case of the embedded DNP3 security). Figure 10. Security test using end-to-end DNP3 security. Figure 10. Security test using end-to-end DNP3 security.
Under the second consideration, the proposed security development is used and the APDU bytes were successfully transmitted between the participant nodes on 300 occasions, and the security operations were computed at sides such as the encryption operation and the decryption operation. Each time that the APDU bytes were sent and received between the participant nodes, the encryption and decryption operations were verified by the examination that was conducted by the security development. Among the successful experiments, 200 were selected as the most favorable performance tests; further, attack scenarios were launched and 200 selected experiments were again performed with the measurements of the security [5,56,57]. Figure 9 shows the number of attacks that were observed in the testbed according to the marker indications of the byte flow that is represented by the green lines. The green lines show the flow of traffic that corresponds to the random size fragments, but each fragment is limited to 1992 bytes. As a consequence, one authentication attack and one confidentiality attack were detected and observed for a computation of the total security percentage (99 percent in the case of the embedded DNP3 security). Figure 10. Security test using end-to-end DNP3 security. Figure 11. Approximate security comparison. Figure 11. Approximate security comparison.
Under the third consideration, the security development was employed and treated as an external security development (or end-to-end security development), meaning that the proposed security development had not been a part of the DNP3 protocol, and the end-to-end system security was tested. Similar to the second consideration, the protocol bytes were successfully transmitted between the participant nodes and encryption/decryption operations were performed and verified. Subsequently, attacks such as authentication, confidentiality, integrity, and non-repudiation were launched between the transmissions, which changed the normal flow of the SCADA/DNP3 system and made the traffic abnormal [5,56,57]. Figure 10 shows the number of attacks that were observed during the end-to-end communication of the testbed. Based on the level (or number) of attacks that were detected, the security was computed as 78 percent, which is inadequate compared with the previously mentioned security percentage of 99 percent ( Figure 9). Further, these results have also been compared with the existing studies [7,10,11,14,15,[49][50][51]53,54] (and designated as a security review) in terms of the security level and, based on our compiled analysis, the security comparison is visualized in Figure 11.

Conclusions and Future Work
This study seeks to address the SCADA/DNP3 application-layer security challenges and issues via a cryptography mechanism, which is typically used in transmission. A secure DNP3 application-layer stack was therefore designed and the performances were measured, while formal proofs were used to evaluate the overall security implementation. The proposed security design and deployment provide new generic directions to enhance the security of the SCADA/DNP3 application layer together with future research directions. In future works, security enhancements will be made for the lower layers of the DNP3 protocol and abnormal scenarios will be developed; moreover, several attacks including authentication, integrity, non-repudiation, and confidentiality will also be tested, and the related performances will be measured to validate the proposed design and security implementation.