2018 13th IEEE International Conference on Industry Applications Mo7TrackC.

Implementation of Secure Communication With

Modbus and Transport Layer Security protocols
Matheus K. Ferst, Hugo F. M. de Figueiredo,
Gustavo Denardin and Juliano Lopes
Postgraduate Program in Electrical Engineering (PPGEE)
Federal University of Technology - Paraná (UTFPR)
Pato Branco, Brazil
Email: matheus.ferst@gmail.com, hugoffigueiredo1@gmail.com
gustavo@utfpr.edu.br, julianolopes@utfpr.edu.br

Abstract—Industrial Control Systems (ICS) and Supervisory in industry [3]. It was initially created for asynchronous serial
Control systems and Data Acquisition (SCADA) networks imple- transmissions and posteriorly extended to packages networks,
ment industrial communication protocols to enable their opera- such as TCP/IP. However, this modification also enabled a
tions. Unfortunately, wide used protocols, such as Modbus and
DNP3, lack basic security mechanisms that lead to multiple vul- new avenue for attacks and introduced a whole new level
nerabilities. The exploitation of such flaws may greatly impact of vulnerabilities to the protocol. The original Modbus serial
companies and the general population, especially for attacks transmission has an intrinsic isolation between the enterprise
targeting critical infrastructural assets such as power plants, level and the control level of a industry network, which
water distribution, and railway transportation systems. Such requires attackers to have physical access to serial buses
problem gets worse in the context of photovoltaic Distributed
Energy Resources (DER), where devices are commonly located or compromises a device already connected to the network.
in customers facilities, making difficult to enforce appropriate Unfortunately, the TCP version of the protocol makes feasible
security policies. This paper addresses the security problems a remote exploitation.
of the Modbus protocol, proposing a new secure version based According to the Industrial Control System Cyber Emer-
on the Transport Layer Security protocol. Experimental results
gency Response Team (ICS-CERT), part of the US De-
shows that the proposed solution achieves request/response times
way below the 16.67 ms period of the power grid 60 Hz cycle, partment of Homeland Security, in the last four years the
revealing a negligible impact in power grids applications. prevalent category of weakness found in their assessments
Index Terms—Modbus, TLS, SCADA, Security was in the boundary protection. Also, at the timing of writing
this document, the Shodan1 search engine reports2 16,210
I. I NTRODUCTION host connected to the Internet with port 502 open, which is
the port reserved for the Modbus TCP protocol.
Supervisory Control and Data Acquisition (SCADA) sys-
tems are used in a great variety of fields, like power plants, The security in Industrial Control Systems (ICS) has been
water and wastewater collection, treatment and distribution, addressed for more than 18 years. In 2000 IEEE published
oil and gas pipelines, and industrial discrete manufacturing a security guide for electric power substations [4]. In 2004
[1]. Some applications, especially those related to infrastruc- the American Petroleum Institute (API) Standard 1164 was
ture assets, have a critical nature and a fault in these systems released, targeting SCADA pipeline security issues.
may lead to unrecoverable damages and losses, affecting In 2011, the US National Institute of Standards and Tech-
general population [2]. nology (NIST) issued the Special Publication 802-82 [1], a
These systems rely on communication networks and pro- security guide for ICS and DCS. This document presents an
tocols to enable their operations. Commonly used protocols, overview of those systems, their topologies and architectures
such as DNP3 or Modbus, lacks any inherent security mech- and itemizes threats and countermeasures.
anisms, and the exposure of the system to a public network, One of the emerging DCS applications is the power grid
either by the incorrect deployment of the system or by the management, also known as smart grid. The increase in
exploitation of some vulnerability, may lead unauthorized energy consumption, the rising costs and the growth of
agents to control the asset. renewable energy sources revel the need for modernization
An intentional exposure could also be used to enable of the power grid [5], [6]. This kind of system carries a
new functionalities, such as in Distributed Control Systems critical aspect and bring a series of challenges, such as high
(DCS), or to reduce operational costs to manage geograph- availability, wide area distribution, integration with alternative
ically dispersed assets, such as power grids and railway energy sources and security concerns. [5].
transportation systems. The SunSpec Alliance3 is a solar energy and distributed
The Modbus protocol was developed by Modicon in 1979 storage industry association that target the standardization
and has become a de facto standard for serial communications and interoperability of photovoltaic (PV) systems [7]. PV sys-

1 https://www.shodan.io/
This work was funded by the Research and Development project PD 2866-
2 https://www.shodan.io/report/M4rgHZpA
0468/2017, granted by the Brazilian Electricity Regulatory Agency (ANEEL)
and Companhia Paranaense de Energia (COPEL). 3 www.sunspec.org

978-1-5386-7995-1/18/$31.00 ©2018 IEEE 155 ISBN 978-1-5386-7995-1

Authorized licensed use limited to: Shenyang Institute of Automation. Downloaded on April 14,2024 at 03:38:44 UTC from IEEE Xplore. Restrictions apply.
tems are commonly located at the customer facilities, which Modbus TCP/IP ADU

characterize them as distributed energy resources (DER), 2-bytes 2-bytes 2-bytes 1-byte 1-byte Up to 256 bytes
Transaction Identifier Protocol Identifier Length Unit Identifier Function Code Data
where security polices cannot be enforced.
MBAP Header Modbus PDU
Security concerns with that fact led to the foundation of the
SunSpec DER Cybersecurity Workgroup, which published in Fig. 2. Modbus TCP Frame
2013 its security recommendations guide [8]. This document
lists the main security requirements for PV plant operations,
such as availability, safety, client sensible data confidentially, Identifier field is added to enable communications through
non-repudiation and accountability. Additionally, such doc- devices such as bridges, proxies, gateways and routers that
ument presents Modbus as a “weak link” in the control use a single IP address. The checksum is also omitted from
architecture and suggest a transport layer mitigation with the application frame, since it is already handled by the TCP
Transport Layer Security and mutual authentication. protocol [15].
Transport Security Layer (TLS) is a protocol that provides The Transaction Identifier field is used for transaction
communications security over the Internet [9]. It was created pairing. A Modbus response contains the same transaction
by Netscape Communications in 1993 aiming specially the number of its request. The Protocol Identifier permits intra-
security of the World Wide Web (WWW) [10]. However, system multiplexing and is always zero for Modbus/TCP
with its evolution, the protocol has started to effectively [15]. The Length field is used to delimit the end of the frame,
describe a framework for the development and deployment beacuse TCP is a stream protocol and does not preserve
of cryptographic protocols [11]. message boundaries. The 502 TCP port is reserved for the
This paper describes the implementation of a secure ver- Modbus/TCP [16].
sion of the Modbus TCP protocol which uses the TLS The Modbus Application Protocol specify the application
protocol as transport layer, creating a Modbus/TLS protocol. layer for any of the transmission modes of Modbus devices.
Additionally, multiple cipher suites are tested experimentally It defines a request-reply protocol, where slave devices offer
to check the achieved performance, latency and applicability. services identified by function codes in the range of 1-127.
The protocol Data Model is defined by four tables with
II. M ODBUS P ROTOCOL different properties that is summarised in Table I. For each
The Modbus protocol was developed by Modicon in 1979 table, the protocol allows up to 65535 elements. A Modbus
and defines a messaging structure for master-slave communi- Master Terminal Unit (MTU) may request operations over
cations between intelligent devices [12]. It is an open protocol this elements by informing the respective function code in
whose specification is freely distributed4 and there are no the Modbus PDU field. Some examples of function codes
licensing fees. After some owner changes, Modicon was are shown in Table II
finally acquired by Schneider Electric by means of a merger
of the companies AEG and Groupe Schneider. In April 2004 III. T RANSPORT L AYER S ECURITY P ROTOCOL
the protocol was transferred to the Modbus Organization, Transport Security Layer (TLS) is a protocol that provides
an independent, member-based, non-profit organization that communications security over the Internet [9]. It was created
currently drives the evolution of the protocol [13]. by Netscape Communications in 1993, initially called Secure
The protocol was originally designed for asynchronous Socket Layer (SSL), and aiming specially the security of the
serial lines (e.g. RS-232, RS-485) with two transmission World Wide Web (WWW) [10]. The protocol was submitted
modes, RTU and ASCII, in which only the first one have as an Internet-Draft in 1995 and the Internet Engineering Task
mandatory implementation [14]. A Modbus frame for serial Force (IETF) created the TLS Work Group5 to standardize the
lines consists in a single Modbus Protocol Data Unit (PDU) protocol in 1996. The protocol was finally released in 1999,
within a Modbus Application Data Unit (ADU). This con-
5 https://datatracker.ietf.org/wg/tls/about/
struction is shown in Figure 1 for RTU mode.
Aiming the advantages of the Ethernet standard, such as
scalability, data transmission at speed of 10/100 Mbps and the
TABLE I
easy integration with other systems, a TCP/IP specification M ODBUS DATA M ODEL PRIMARY TABLES
of the protocol was developed in 1999 [12].
Figure 2 shows a Modbus/TCP (i.e. Modbus over TCP/IP) Table Data Length Access Type
frame. The slave address is omitted since the Internet Protocol Discretes Input Single bit Read-Only
(IP) already addresses the nodes. Instead, a single-byte Unit Coils Single Bit Read-Write
Input Registers 16-bit word Read-Only
4 http://www.modbus.org/specs.php Holding Registers 16-bit word Read-Write

TABLE II
Modbus ADU M ODBUS F UNCTION C ODES

1-bytes 1-byte Up to 252 bytes 2-bytes

Slave Address Function Code Data CRC 0x01 Read Coils 0x07 Read Exception Status
0x02 Read Discrete Inputs 0x0F Write Multiple Coils
Modbus PDU 0x03 Read Holding Register 0x10 Write Multiple Registers
0x04 Read Input Register 0x11 Report Slave ID
Fig. 1. Modbus Frame for Serial Line transmissions in RTU mode 0x05 Write Coil 0x17 Read/Write Multiple Registers

156

Authorized licensed use limited to: Shenyang Institute of Automation. Downloaded on April 14,2024 at 03:38:44 UTC from IEEE Xplore. Restrictions apply.
renamed as Transport Layer Security, with few differences Application Data
from the latest SSL version, the SSL 3.0 [10].
Such protocol can be placed in the sixth layer of the OSI Fragment
Model [11] or between the Application Layer and Transport
Layer [10] of the Internet Model. It is subdivided in two
TLSPlaintext
layers and five subprotocols, as shown in Figure 3.
An association between two communicating peers is rep-
resented by a TLS Session [10], which defines a set of Compress
cryptography security parameters that can be shared across
connections [9]. Such parameters are described as follows:
Seq.
• The Session Identifier, an arbitrary value generated by Number Header TLSCompressed
the server to identify the session;
• The Peer Certificate, if required;
Authenticate
• The Compress Method, or in other words, the algorithm
used to compress data before encryption;
• The Cipher Spec, comprised by a pseudorandom func- TLSCompressed MAC Padding
tion (PRF), a bulk data encryption algorithm, a Message
Authentication Code (MAC) algorithm and its crypto-
Encrypt
graphic attributes, such as the MAC length;
• The Master Secret, a 48-byte secret shared between the
communicating peers; Header TLSCiphertext
• And if the session is resumable or not.

A. TLS Record Protocol Transmit

The TLS Record Protocol is stacked on top of TCP [10].

TCP
The structure of a record is shown in Figure 4. This protocol
is used to fragment and transmit higher-layer data, and Fig. 5. TLS Record Protocol overview
optionally compress, authenticate and encrypt the fragment
before the transmission [10], [11].
In the other hand, the Record Protocol reassembles mes- The information about which algorithms and methods
sages received from the lower-layers and delivers them to should be employed are represented by the cipher suite in
the higher-layer client, decrypting, checking their authenticity use. Currently there are 339 suites officially supported [17]
and decompressing if needed [9], [11]. Each TLS record may that target different applications and security levels. Some
have multiple messages of the higher-layer, as long as all examples are presented in Table III.
messages belong to the same TLS subprotocol. The flexibility introduced by cipher suites effectively turns
Figure 5 shows an overview of this operation. Encryption, the TLS protocol in a framework for cryptographic protocols
authentication and compression steps are optional, being the deployment [11]. The suite name generally express the key
last one usually avoided, because it may induce side-channel exchange, the authentication method, the encryption algo-
vulnerabilities [10], [11]. rithm and the MAC construction.
For instance, TLS_ECDH_RSA_WITH_RC4_128_SHA
(0xC00C) states that the Elliptic-curve Diffie-Hellman
(ECDH) will be used as key exchange, RC4 will be the
Application Protocol
encryption algorithm and the MAC construction will be based
on the SHA hash function.
Additional informations, such as the encryption key
TLS TLS Change Application
Handshake Cipher Spec TLS Alert
Protocol Protocol
Protocol
data
Protocol
size, cipher mode and alternatives PRF may also be
Application Layer present when applicable [11]. Some suites, such as
TLS Record Protocol
TLS_ECDH_anon_WITH_AES_128_CBC_SHA (0xC018),
lacks peers authentication in order to provide a better privacy
Transport Layer TCP of the communicating entities [10].
Other suites, such as TLS_RSA_WITH_NULL_MD5
Network Layer IP (0x0001) may authenticate the communicating peers and
Link Layer .. messages, but do not encrypt the communication channel [9].
. Here, RSA is used to key exchange and peer authentication.
Thus, an identity function is used for encryption and the
Fig. 3. TLS subprotocols and layers
messages authentication is done by a MD5-based MAC.
1-bytes 2-bytes 2-bytes Up to 256 bytes
This kind of cipher suite is particularly required in some
Type Version Length Data environments, such as when messages are audited by third
entities who do not participate in the communication and,
Fig. 4. TLS Record therefore, do not have the necessary keys to decrypt the
157

Authorized licensed use limited to: Shenyang Institute of Automation. Downloaded on April 14,2024 at 03:38:44 UTC from IEEE Xplore. Restrictions apply.
 TABLE III and compression method is returned, representing the server
E XAMPLE OF CIPHER SUITES choice [10].
Cipher Suite Number
A Certificate message is used to transport the X.509
certificate chain from server or client to the other peer
TLS-NULL-WITH-NULL-NULL 0x0000
TLS-RSA-WITH-NULL-MD5 0x0001 [11]. The certificates are encoded as ASN.1 DER, with the
TLS-ECDHE-RSA-WITH-NULL-SHA 0xC010 main certificate being sent first, followed by all intermediary
TLS-RSA-WITH-NULL-SHA256 0x003B certificates up to, but not including, the root certificate, in the
TLS-RSA-WITH-AES-128-CCM-8 0xC0A0
TLS-RSA-WITH-AES-256-CCM-8 0xC0A1 correct order [9].
TLS-RSA-WITH-AES-128-CBC-SHA 0x002F Not all cipher suites require a certificate, either by do not
TLS-RSA-WITH-AES-256-CBC-SHA 0x0035 use authentication or due to the authentication method does
TLS-RSA-WITH-AES-128-CBC-SHA256 0x003C
TLS-RSA-WITH-AES-256-CBC-SHA256 0x003D not rely on certificates [10]. If the agreed cipher suite does
TLS-RSA-WITH-AES-128-GCM-SHA256 0x009C require, the server will continue the handshake sending a
TLS-RSA-WITH-AES-256-GCM-SHA384 0x009D Certificate message.
TLS-ECDH-RSA-WITH-RC4-128-SHA 0xC00C
TLS-ECDH-anon-WITH-AES-128-CBC-SHA 0xC018 If the key exchange in use by the selected cipher suite
requires more information than the provided by the cer-
tificates, the server proceed the handshake process with a
messages. Another example is the case when confidentiality ServerKeyExchange message, whose contents may vary
is not required and the additional computational cost for according to the key exchange method in use [10].
encryption would be prohibitive. When the server requires the client authentication, a
Lastly, the TLS_NULL_WITH_NULL_NULL (0x0000) is a CertificateRequest message is sent [9]. It is com-
remarkable suite that do not authenticate the communicants prised by a list of acceptable certificate types, supported
and states an identity function for encryption and no MAC signature algorithms and certification authorities, identified
construction [9]. This suite clearly provides no additional by their distinguished names [11].
security to the communication channel, but in fact is used The server then signals that all intended handshake mes-
at the beginning of the TLS connection, where client and sages were sent with a ServerHelloDone message [9].
server have not yet exchanged enough information to stablish If a CertificateRequest is sent, the client reply a
the secure communication [10], [11]. Certificate message with the required certificate. If
This information exchange is actually done by the TLS the key exchange needs more client information, it sends a
Handshake protocol, as explained in the next section. ClientKeyExchange [10].
If the client sent a Certificate message, it will sent
B. TLS Handshake Protocol a CertificateVerify message to prove the possession
of the corresponding private key, with a signature of all
The TLS Handshake Protocol is in the top of TLS Record exchanged handshake messages until this point. Finally, client
Protocol and is responsible for handling the handshake pro- sends a ChangeCipherSpec message, signaling that it
cess, which enables peers to agree upon security parameters have sufficient information to generate the connection pa-
of a TLS session [9]. The handshaking is realized by the rameters and encryption keys and is now able to switch to an
exchange of six to thirteen messages, depending on client encrypted communication [9]. The ChangeCipherSpec is
and server configurations [11], and is illustrated by Figure 6. not part of the TLS Handshake Protocol, but the only message
The emphasized messages represent optional messages, while of the TLS Change Cipher Spec Protocol [10].
messages under brackets belongs to TLS Change Cipher Spec
Protocol.
The first message in the handshake process is a
Client Server
ClientHello. It is sent by the client to the server to
communicate its capabilities and preferences [11]. Its content ClientHello
is comprised of: ServerHello
• The best Protocol Version supported by the client; Certificate
• A 32-bytes random value, which is the random data ServerKeyExchange
contribution of the client to the handshake; CertificateRequest
• The Session Identifier of a previous session, if the
ServerHelloDone
client wishes to resume an already negotiated resumable
Certificate
session;
ClientKeyExchange
• A list of supported Cipher Suites, ordered by preference;
• A list os supported Compression Methods, also ordered CertificateVerify

by preference; [ChangeCipherSpec]
• And a list of Extensions, that carry additional data. Finished

The second handshake message is a ServerHello re- [ChangeCipherSpec]

sponse from the server to the client. It is very similar to the Finished
ClientHello, except that instead of a list of supported
cipher suites or compression methods, a single cipher suite Fig. 6. TLS Handshake Process

158

Authorized licensed use limited to: Shenyang Institute of Automation. Downloaded on April 14,2024 at 03:38:44 UTC from IEEE Xplore. Restrictions apply.
 The client then sends his last handshake message, of other peer that it will not send any other message and the
Finished type. It is the first encrypted message exchanged connection will be closed. This shutdown process is necessary
between client and server with the new agreed session pa- to avoid truncation attacks, and if an attack abruptly end the
rameters and signals the end of the handshake process [11]. connection, the lack of this alert shows that the connection
Its content is a hash of all communicated TLS Handshake was not ended gracefully [10], [11].
Protocol messages between the peers combined with the
negotiated master secret by a PRF function [9]. IV. R ELATED W ORK
The PRF may vary according to the protocol version [10]. Many other authors have addressed the security SCADA
For TLS 1.2, it is defined as (1) shows [9], where + denotes threats. [1] presents a guide to industrial control systems
concatenation. The Phash expansion function, shown in (2), security and [18] defines a methodology for risk assessment
is a iterative function that can produce an arbitrary amount in industrial automation systems, which identifies possible
of data and is defined in terms of A(i), that is showed in (3). security threats and the respective countermeasures.
P RF (secret, label, seed) = Phash (secret, label + seed) [19] analyse the Modbus protocol specification in order
(1) to distinguish the possible attacks. Their work identifies
Phash (secret, seed) = HM AChash (secret, A(1) + seed) 33 taxonomies, being five of them particular of the serial
+HM AChash (secret, A(2) + seed) transmission mode and 13 of the Modbus TCP protocol. All
of them consider the existence of a Modbus sniffer or a packet
+... injector.
(2)
( [20] investigate the impact of malware attacks in Modbus
seed, if i = 0
A (i) = based SCADA networks, such as Code Red, Nimda, Slammer
HM AChash (secret, A (i − 1)) , if i < 0 and Scalper. The authors also developed specialized malware
(3) to attack Modbus TCP devices. One of them performs DoS
For Finished message content, the PRF function is invoked attacks to the SCADA system by injecting valid but malicious
with master secret as secret, the ASCII bytes that represents Modbus packages, consuming bandwidth without alarm a
the string ‘client finished’ for the client message or the string possible IDS system that monitors the network.
‘server finished’ for the server message as label and the hash The authors also developed a worm that scan the network
of exchanged handshake messages as seed [9]. of infected devices in search of Modbus TCP devices and
The server then responds with his ChangeCipherSpec then applies several heuristics to harm the SCADA operation,
and the following Finished message [9]. Since PRF is a such as force all coils to a single state, write random values
deterministic function and both sides have the needed param- in holding registers and invert all coils state.
eters to calculate its output in this context, and considering
[2], [21] and [22] addressed the Modbus security flaws
that the message is encrypted and authenticated with the
by modifying the protocol. [2] uses a digital signature with
agreed session parameters, its content can be used to verify
appendix scheme based in RSA and SHA2 to improve
the success of the key exchange and authentication process
Modbus with integrity and authenticity. A NTP timestamp is
[10], [11].
also added to the protocol frames before the signature process
After that, the client and server can exchange application
in order to prevent replay attacks.
data through a secure channel. The client can sent a new
[21] presents a solution based in SCTP and HMAC named
ClientHello message at any time to renegotiate the
ModbusSec. The SCTP is a transport layer protocol that
session parameters or the server can request this renegotiation
provides a reliable message-oriented communication channel,
by issuing a HelloRequest message [9].
with features such as congestion control and multi-homing
C. TLS Alert Protocol [23]. This protocol introduces a cookie-based four-way-
The TLS Alert Protocol is used to notify the other peer handshake that mitigates some flood attacks, such as TCP
about abnormal situations [10]. A TLS Alert message is SYN Flood. The HMAC utilization addresses the integrity
composed by two single-byte fields. The first one identify and authenticity aspects, being so efficient as the hash func-
the severity level of the alert, being the constant value 1 for tion chosen as basis for the MAC construction.
warning and the value 2 for fatal [9].
V. D EVELOPMENT
A peer that sends or receives a fatal alert must immediately
terminate the connection and invalidate the TLS session. Since all attacks presented by [19] rely on packet injectors
Other connection may continue, but new connection could and sniffers, a solution that address them would effectively
not be established with that TLS session. When a warning mitigate all described taxonomies. In that context, protecting
alert is issued, it is up to the receiver to treat the event as a the transport layer with TLS appears as a robust and flexible
fatal error or take other actions [9]. solution.
The second byte carries a description code, such as 20 The TLS protocol has a wide variety of cipher suites
for bad_record_mac when the received TLS Record have that could meet different security levels and computational
a invalid MAC or 40 for handshake_failure when complexity constraints. If a cipher becomes unsafe, the ap-
it is impossible to negotiate an acceptable set of security plication may use another one, without changing anything in
parameters [9], [10]. the application layer.
One important alert is the close_notify, represented The proposed solutions were implemented in two already
by the description code 0. Such alert is used to notifies the existent Modbus implementations. The first one is the lib-
159

Authorized licensed use limited to: Shenyang Institute of Automation. Downloaded on April 14,2024 at 03:38:44 UTC from IEEE Xplore. Restrictions apply.
 DHCP 0.91 Read
DNS
Etc. TCP 1 Register
1.07 Read
1.08 Coil
MTU: RTU: 0x0001 1.17 Write/Read
Raspberry STM32F7
1.26 Register
Switch

1.13
Fig. 7. Network environment employed for the tests 0xC010 1.22
1.31
1.38
modbus6 , a LGPL library that aim general purpose systems, 0x003B 1.47
1.64
such as Microsoft Windows and GNU/Linux. The second one
is the FreeModbus implementation, that is also free and aims 1.4
0xC0A0 1.49
mainly embedded platforms. 1.88
The TLS protocol implementation was provided by the
1.43
mbedTLS7 library, that is available for general purpose 0x002F 1.53
and embedded systems. Both Modbus implementations were 1.74
modified to call the TLS methods instead of the standard 1.48
socket API to receive and send data. 0x0035 1.57
The resulting solutions were then deployed on two plat- 1.82
forms: a Raspberry Pi 3B with Raspbian GNU/Linux distribu- 1.51
tion and a STM32F749 microcontroller running a FreeRTOS 0xC0A1 1.6
2.07
based firmware. The libmodbus test suite was then issued
to implement a Modbus MTU on the Raspberry, while the 1.51
0x009C 1.61
FreeModbus port was employed on the STM32F749 to create 2.07
a Modbus RTU.
1.57
Figure 7 shows the network environment employed for the 0x009D 1.66
tests. 2.16
1.66
VI. R ESULTS 0x003C 1.75
2.04
The applied test is based on the PI-MBUS-300 reference
1.7
guide [24] and consists of operating the Read Coils (0x01), 0x003D 1.8
Read Holding Registers (0x03) and Read/Write Multiple Reg- 2.13
ister (0x17) functions 100,000 times each, over the maximum
number of coil or register allowed by the protocol. Fig. 8. Observed average latency (ms)

The time of each Modbus transaction is recorded, and

the obtained data is used to calculate the achieved goodput
TCP based applications, such as packet filtering and SYN
and latency of a particular implementation. The size of the
cookies usage [25].
transactions is then observed using a sniffer to determine
the overhead of the solution. The tests were repeated for 43 Otherwise, when confidentially are not provided by the
cipher suites that can be divided between those that provide chosen cipher suite, only packet injectors will be mitigated
confidentiality and those that provide just authenticity and and taxonomies related to packet sniffing, such as passive
integrity. SCADA network reconnaissance, remain feasible. As stated
If confidentially and authenticity is guaranteed, the ex- above, suites without confidentially could be required in some
istence of a package injector and a sniffer is mitigated, environments and also provide a computationally cheaper
addressing the premises of the taxonomies described by [19]. solution.
In that way, all 15 taxonomies that are common to serial and This advantage becomes more apparent when comparing
TCP transmission modes are attended. the observed latency for the two groups of cipher suites, as
For the 13 TCP specific taxonomies, however, only the shown in Figure 8. The fastest tested null-encryption suite is
attacks that explore the application layer of the protocol are 0.3 to 0.6 ms faster than the lower latency encrypted option.
prevented. This is because TLS is stacked on top of TCP Also, the null-encryption suite with the most secure
and, thus, does not have the scope to address some TCP hash function tested, TLS-RSA-WITH-NULL-SHA256
vulnerabilities. (0x003B), is 47% slower than the insecure Modbus. On the
Therefore, attacks such TCP Pool Exhaustion are ad- other hand the TLS-RSA-WITH-AES-256-GCM-SHA384
dressed, but other like TCP SYN Flood or TCP RST Flood (0x009D) suite, that is the preferred one in default config-
are not. Those unresolved problems should be prevented by urations of mbedTLS, results in a 66% greater latency than
employing other solutions that are commonly used in other Modbus TCP.
This difference is not only due to the additional compu-
6 http://libmodbus.org/ tational cost for encryption, but also a consequence of the
7 https://tls.mbed.org/ packet size overhead, which is presented in Figure 9. In that
160

Authorized licensed use limited to: Shenyang Institute of Automation. Downloaded on April 14,2024 at 03:38:44 UTC from IEEE Xplore. Restrictions apply.
 31.82 Read 83.96
0x0001 31.82 Register 0x0001 85.25
6.71 Read 85.45
Coil
31.82 80.23
0xC0A0 31.82 Write/Read 0xC010 81.97
6.71 Register 81.82
31.82 65.67
0xC0A1 31.82 0x003B 68.03
6.71 65.45
37.88 64.55
0xC010 37.88 0xC0A0 67.21
7.99 56.82
43.94 63.43
0x009C 43.94 0x002F 65.16
9.26 61.36
43.94 61.19
0x009D 43.94 0x0035 63.52
9.26 59.09
56.05 60.07
0x003B 56.05 0x009C 61.88
11.82 51.82
68.17 60.07
0x002F 68.17 0xC0A1 62.29
17.25 51.82
68.17 57.84
0x0035 68.17 0x009D 60.25
17.25 49.54
Read
86.36 54.48 Register
0x003C 86.36 0x003C 56.97 Read
21.09 52.27 Coil
86.36 53.36 Write/Read
0x003D 86.36 0x003D 55.33 Register
21.09 50

Fig. 9. Resulting overhead for request operations (%) Fig. 10. Achieved goodput (%)

case, between confidentially capable suites, the CCM-8 based Comparing with the insecure Modbus TCP, the obtained
ones take advantage, since they had a smaller authentication results shows a 12.78% goodput reduce for null-encryption
tag [26]. suites and 35.11% for suites that provide confidentially. In
Similarly, CBC based solutions have the great disadvantage addition, it was possible to verify a significant overhead when
of padding, which significantly increases its overhead. The the chosen suite is based in block cipher operation modes,
overall performance is presented in Figure 10, where the such as AES-128-CBC.
useful data transfer rate (goodput) is shown. Despite the additional computational complexity, even the
slowest cipher suite achieves transaction times below the
VII. C ONCLUSION 16.67 ms period of the power grid 60 Hz cycle, thus
revealing a negligible impact in power grids applications.
Applications that use SCADA systems rely on protocols Anyhow, encryption algorithms with block cipher oper-
such as DNP3 and Modbus to enable their operations. Many ation, such as AES-128-CBC, shows the worst perfor-
protocols widely deployed lack basic security mechanisms, mance. Therefore, stream operated ones should be preferred,
such as confidentially and authenticity of transmitted data. such as AES-256-GCM, for high parallelizable devices or
When deployed in critical infrastructure assets, like the AES-128-CCM for network restricted environments.
power grid, these applications enable advanced control pos- If the computational constraints make the use of suites that
sibilities, such as in the case of smart grid. The exposition provide confidentially prohibitive, the use of null-encryption
of those systems by incorrect deployment or existent vulner- suites still offer a better security option than the original
abilities create a new avenue for attacks. Modbus TCP, leaving just passive reconnaissance attacks un-
This paper has addressed the security problems of Modbus addressed and significantly increasing the achieved goodput.
protocol applied to industrial control systems and SCADA
networks. Based on previous works about this protocol se- VIII. ACKNOWLEDGMENT
curity, such as the ones of [19] and [20], other proposed
solutions and the SunSpec security recommendations, a TLS The authors thank to FINEP, CAPES, SETI, CNPq,
based solution was proposed, implemented and experimen- Fundação Araucária and UTFPR for scholarships and fund-
tally tested for 43 cipher suites. ing.
161

Authorized licensed use limited to: Shenyang Institute of Automation. Downloaded on April 14,2024 at 03:38:44 UTC from IEEE Xplore. Restrictions apply.
 R EFERENCES [26] D. McGrew and D. Bailey, “Aes-ccm cipher suites for transport layer
security (tls),” Internet Requests for Comments, RFC Editor, RFC
6655, July 2012.
[1] K. Stouffer, J. Falco, and K. Scarfone, “Guide to industrial control
systems (ics) security,” NIST special publication, vol. 800, no. 82, pp.
16–16, 2011.
[2] I. N. Fovino, A. Carcano, M. Masera, and A. Trombetaa, “Design and
implementation of a secure modbus protocol,” Critical Infrastructure
Protection, vol. 3, pp. 83–96, 2009.
[3] I. Modbus, “Modbus application protocol specification v1.1b,” North
Grafton, Massachusetts (www.modbus.org/specs.php), 2006.
[4] IEEE, “IEEE guide for electric power substation physical and elec-
tronic security,” IEEE Std 1402-2000, pp. i–, 2000.
[5] V. C. Gungor, D. Sahin, T. Kocak, S. Ergut, C. Buccella, C. Cecati, and
G. P. Hancke, “Smart grid technologies: Communication technologies
and standards,” IEEE Transactions on Industrial Informatics, vol. 7,
no. 4, pp. 529–539, Nov 2011.
[6] A. R. Metke and R. L. Ekl, “Security technology for smart grid
networks,” IEEE Transactions on Smart Grid, vol. 1, no. 1, pp. 99–107,
June 2010.
[7] S. Alliance, “About the sunspec alliance,” SunSpec Alliance,
2017, acesso em: 18 out. 2017. [Online]. Available: https:
//sunspec.org/sunspec-about/
[8] J. Blair, J. Nunneley, R. Kaisler, B. Fox, F. Nagy, B. Randle, L. Linse,
and T. Tansy, “Security recommendations,” Best Practices, SunSpec
DER Cybersecurity Workgroup, Best Practices, June 2013.
[9] T. Dierks and E. Rescorla, “The transport layer security (tls) protocol
version 1.2,” Internet Requests for Comments, RFC Editor, RFC
5246, August 2008, http://www.rfc-editor.org/rfc/rfc5246.txt. [Online].
Available: http://www.rfc-editor.org/rfc/rfc5246.txt
[10] R. Oppliger, SSL and TLS: Theory and Practice. Artech House, 2016.
[11] I. Ristic, Bulletproof SSL and TLS: Understanding and Deploying
SSL/TLS and PKI to Secure Servers and Web Applications. Feisty
Duck, 2014.
[12] Modbus FAQ, “About the protocol,” FAQ. Modbus Organization inc.,
2017.
[13] ——, “About the modbus organization,” FAQ. Modbus Organization
inc., 2017.
[14] Modbus Org, “Modbus over serial line specification & implementation
guide v1.02.”
[15] Schneider Automation, “Modbus messaging on tcp/ip implementation
guide v1. 0b,” MODBUS Organization, last accessed June, p. 46, 2006.
[16] J. Touch, E. Lear, A. Mankin, M. Kojo, K. Ono, M. Stiemerling,
L. Eggert, A. Melnikov, W. Eddy, A. Zimmermann, B. Trammell,
J. Iyengar, M. Tuexen, E. Kohler, and Y. Nishida, “Service name
and transport protocol port number registry,” The Internet Assigned
Numbers Authority (IANA), 2018.
[17] Y. Nir, R. Salz, and N. Sullivan, “Tls cipher suite registry,” The Internet
Assigned Numbers Authority (IANA), May 2018. [Online]. Available:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
[18] A. Creery and E. Byres, “Industrial cybersecurity for power system
and scada networks,” in Petroleum and Chemical Industry Conference,
2005. Industry Applications Society 52nd Annual. IEEE, 2005, pp.
303–309.
[19] P. Huitsing, R. Chandia, M. Papa, and S. Shenoi, “Attack taxonomies
for the modbus protocols,” International Journal of Critical
Infrastructure Protection, vol. 1, pp. 37 – 44, 2008. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S187454820800005X
[20] I. N. Fovino, A. Carcano, M. Masera, and A. Trombetta, “An exper-
imental investigation of malware attacks on scada systems,” Interna-
tional Journal of Critical Infrastructure Protection, vol. 2, no. 4, pp.
139–145, 2009.
[21] G. Hayes and K. El-Khatib, “Securing modbus transactions using hash-
based message authentication codes and stream transmission control
protocol,” in Communications and Information Technology (ICCIT),
2013 Third International Conference on. IEEE, 2013, pp. 179–184.
[22] A. Shahzad, M. Lee, Y.-K. Lee, S. Kim, N. Xiong, J.-Y. Choi, and
Y. Cho, “Real time modbus transmissions and cryptography security
designs and enhancements of protocol sensitive information,” Symme-
try, vol. 7, no. 3, pp. 1176–1210, 2015.
[23] R. Stewart, “Stream control transmission protocol,” Internet Requests
for Comments, RFC Editor, RFC 4960, September 2007, http:
//www.rfc-editor.org/rfc/rfc4960.txt. [Online]. Available: http://www.
rfc-editor.org/rfc/rfc4960.txt
[24] I. Modicon, “Modicon modbus protocol reference guide,” PI–MBUS–
300 Rev. J, Tech. Rep., 1996.
[25] W. Eddy, “Tcp syn flooding attacks and common mitigations,” Internet
Requests for Comments, RFC Editor, RFC 4987, August 2007.

162

Authorized licensed use limited to: Shenyang Institute of Automation. Downloaded on April 14,2024 at 03:38:44 UTC from IEEE Xplore. Restrictions apply.