Practical applications of Lightweight Block Ciphers to ... · with an unvarying transformation that is specified by a symmetric key. Feistel cipher - a symmetric structure used in

2015 ODVA Industry Conference 1 ©2015 ODVA, Inc.

Practical applications of Lightweight Block Ciphers to Secure EtherNet/IP Networks

Jordon Woods Chief Technical Officer

Innovasic, Inc.

Patricia Muoio Director of Research and Development

G2, Inc.

Presented at the ODVA 2015 Industry Conference & 17th Annual Meeting

October 13-15, 2015 Frisco, Texas, USA

Abstract The relatively new field of lightweight cryptography provides significant advantages over existing cryptographic algorithms when addressing security issues for highly constrained devices. Existing cryptographic algorithms were, for the most part, designed to meet the needs of the desktop computing era and thus require significant resources to implement. By contrast, lightweight cryptography lends itself to implementation as a block cipher providing a scalable, pipelined architecture. These techniques require a small HW footprint compared to similar AES implementations and can therefore be realized by small circuits with minimal power requirements. Perhaps most importantly, lightweight block cyphers can be implemented with very low latency making them ideal for applications in which deterministic performance is critical. Effectively, point to point EtherNet/IP links can be encrypted without interfering with the functional performance of the protocol. Because EtherNet/IP utilizes standard Ethernet technologies, it can easily leverage the advantages of lightweight block cyphers. Incoming and outgoing packets can be easily monitored to ensure layer 2 and layer 3 routing information remains unencrypted while the payload is encrypted. While several families of lightweight block cyphers exist, most are targeted to a specific platform. By contrast, SIMON and SPECK implementations are highly flexible. The SIMON algorithm is tuned for optimal performance in hardware while the SPECK algorithm targets software implementations. As a proof of concept, Innovasic has implemented the SIMON and SPECK family of lightweight block cyphers in its Real-Time Ethernet Multi-Protocol (REM) switch. Using an existing demonstration platform running EtherNet/IP and a beacon-based device-level ring (DLR), a single link was secured using the SIMON algorithm. A network tap was installed on the encrypted link and on the unencrypted link. A network analyzer was attached to demonstrate the secure link is operational and transparent to operation. It is important to note that no changes were made to the applications or programs in any of the ring nodes, including the PLC. From this proof of concept demonstration, it is clear that the SIMON algorithm is transparent to both the EtherNet/IP and DLR protocols and provides a promising new tool when securing Industrial networks.


Keywords SIMON, SPECK, Lightweight Block Cipher, Security, Cryptography, Encryption, Decryption, CIP, EtherNet/IP, Device Level Ring, DLR, IoT, iIoT, Industry 4.0

Definition of terms

Block Cipher - a deterministic algorithm operating on fixed-length groups of bits, called blocks, with an unvarying transformation that is specified by a symmetric key.

Feistel cipher - a symmetric structure used in the design of block ciphers. The Feistel structure has the advantage that encryption and decryption operations are very similar, even identical in some cases, requiring only a reversal of the key schedule. Therefore the size of the code or circuitry required to implement such a cipher is nearly halved.

Key - a piece of information (a parameter) that determines the functional output of a cryptographic algorithm or cipher. Without a key, the algorithm would produce no useful result. In encryption, a key specifies the particular transformation of plaintext into ciphertext, or vice versa during decryption.

Round – an individual iteration of the block cipher

Key Schedule - an algorithm that, given the key, calculates the subkeys for each round.

n – the word size, in bits, for a given member of the SIMON and SPECK family of ciphers

m – the number of words comprising the key for a given member of the SIMON and SPECK family of ciphers

Block Size – the input block size for a given member of the SIMON and SPECK family of ciphers (calculated as 2n).

Key Size – the key size for a given member of the SIMON and SPECK family of ciphers (calculated as mn)

Application of Lightweight Block Ciphers Today’s headlines abound with the promised explosion of the “Internet of Things” (IoT). Some estimates claim that as many as 50 billion Internet-connected devices will exist by 2025. Further, it is estimated that as many as 40% of those devices will be used in industrial applications. Whether one believes these lofty estimates or not, the discussion regarding the “industrial Internet of Things” (iIoT) and the European Industry 4.0 initiative clearly demonstrate that Ethernet-based communications will continue to push into applications traditionally serviced by field bus and even discrete signaling technologies. For this vision to realize, cost-sensitive devices such as sensors, actuators, push buttons and other field devices will need to enable secure Ethernet communication at minimal cost. According to Edith Ramirez, chair of the US Federal Trade Commission, “The small size and limited processing power of many connected devices could inhibit encryption and other robust security measures”. Cryptographic solutions must be easy to implement and have high performance on a wide range of severely constrained devices. Cryptography should be an aid, not a hindrance, to achieving security. Lightweight cryptography promises to address at least some of these concerns. Algorithms like PRESENT, KATAN and Piccolo have existed for some time. These algorithms have a small hardware footprint but limited options for key size, block size and performance. In addition, as these algorithms were optimized for hardware implementation, they are non-optimal for constrained software-based devices using 8-bit or 16-bit microprocessors.


Table 1 - SIMON and SPECK Parameters

Block size Key sizes

32 64

48 72, 96

64 96, 128

96 96, 144

128 128, 192, 259

Published in 2013, the SIMON and SPECK family of block cyphers address these shortcomings. As shown in Table 1, these algorithms provide a variety of block and key sizes. Further, implementation of SIMON and SPECK require a relatively short list of simple functions:

Modular addition and subtraction, + and -

Bitwise XOR, ⊕,

Bitwise AND, &,

Circular left shift, 𝑆𝑗, by j bits and

Circular right shit, 𝑆−𝑗, by j bits Efficiency and security are frequently diametric trade-offs in the design of cryptography. Often, algorithms rely upon highly secure cryptographic components such as 8-bit S-boxes. In contrast, SIMON and SPECK utilize the relatively simple functions listed and iterate to achieve the appropriate level of security. These iterations are known as rounds. The round functions for SIMON 2n and SPECK 2n each take as input an n-bit round key k, together with two n-bit intermediate cipher-text words. To clarify further discussion, a particular member of the SIMON and SPECK family will be referred to as SIMON 2n/mn or SPECK 2n/mn. For instance, SIMON 2n/mn indicates the SIMON block cipher with a 2n-bit block and m-word (mn-bit) key. So, SIMON 64/128 indicates a 32-bit word size (n), a 64 bit block size (2n) and a 4 word (m) key totaling 128-bits (mn). The analogous notation is used for SPECK. For SIMON, each round consists of a two-stage Feistel map. The Feistel map for the SIMON algorithm is given by:

𝑅𝑘(𝑥, 𝑦) = (𝑦 ⊕ 𝑓(𝑥) ⊕ 𝑘, 𝑥)

Where 𝑘 is the round key and 𝑓(𝑥) = (𝑆𝑥 & 𝑆8𝑥) ⊕ 𝑆2𝑥. The inverse of the round function is used for decryption:

𝑅𝑘−1(𝑥, 𝑦) = (𝑦, 𝑥 ⊕ 𝑓(𝑦) ⊕ 𝑘)

Or, shown pictorially:


Figure 1 - Diagram of SIMON Feistel function

Note the use of logical operators; this implementation is ideally suited for hardware. Apart from the round key, all rounds of SIMON are exactly the same, and the operations are perfectly symmetric with respect to the circular shift-map on n-bit words. Consider the case in Figure 2. A SIMON 32/64 encryption engine with a 32-bit block size and a 64 bit key is depicted. The design consists of 11 pipeline stages. The first three stages build the 8-bit data input into a 32 bit block. Each subsequent stage provides 4 rounds of key expansion followed by a single pipelines stage for a total of 32 rounds.


Figure 2 – Implementation of a 32/64 SIMON Encryption Engine.

Note, that each round of SIMON requires a key schedule. A key schedule is an algorithm that, given the key, calculates the sub-keys for each round. In the case of SIMON and SPECK, the key expansion algorithm is dependent only upon the block size and the key size. Therefore, given the block size and key size, and assuming a key which doesn’t change frequently, it is possible to pre-calculate the sub-keys for each round. Further, because the round function is iterative, the design lends itself to pipelining and HDL implementations can be designed with parameters to support varying key and bock sizes with common code (see figure 3). Further optimization is possible. Static timing analysis shows that all 44 rounds of SIMON 64/128 can be performed in a single pipeline stage clocked at 300 MHz for a 130nm process node. Assuming 8-bit input data form the MAC, 7 pipeline states would be required to build a 64-bit word. Together with the single stage required for the algorithm these 8 stages would represent less than 27 nS of total latency at 300 MHz.


Figure 3 - Optimized SIMON Implementation

The SPECK algorithm also utilizes a Feistel-based map:

𝑅𝑘(𝑥, 𝑦) = ((𝑆−𝛼𝑥 + 𝑦) ⊕ 𝑘, 𝑆𝛽𝑦 ⊕ (𝑆−𝛼𝑥 + 𝑦) ⊕ 𝑘),

with rotation amounts α = 7 and β = 2, if n = 16 (block size = 32) and α = 8 and β = 3 otherwise. The inverse of the round function uses modular subtraction for decryption:

𝑅𝑘(𝑥, 𝑦) = (𝑆𝛼((𝑥 ⊕ 𝑘) − 𝑆−𝛽(𝑥 ⊕ 𝑦)), 𝑆−𝛽(𝑥 ⊕ 𝑦)).

Or, shown pictorially:


Figure 4 - Diagram of SPECK Feistel function

SPECK achieves non-linearity by utilizing the modular addition operation, as opposed to the bitwise XOR used by SIMON. The SPECK algorithm is therefore more efficient than SIMON in software implementations.

SIMON and SPECK versus AES In 1997, the US National Institute of Standards and Technology (NIST) announced a competition for a new block based cipher which can be provided in an unclassified environment but still be able to secure sensitive government data well into the next century. The competition ended in 2000 and a version of AES was chosen which consisted of a 128 bit block cipher with support for key lengths of 128, 192, and 256 bit. AES was designed specifically for environments that support a standard PC architecture where power, memory and size are not constrained. As the need for security starts moving more into embedded systems which are physically constrained in terms of power and size, it becomes increasingly difficult to implement AES in those systems. Over the last 15 years, a lot of effort has gone into reshaping the AES into a solution which will work in physically constrained systems. ASIC implementations of AES- 128 have been developed with an area of just 2400 gate equivalents (GE) and software implementations are available for 8-bit and 16-bit microcontrollers. There efforts tend to fall short of what is required for today’s most constrained environments and are unlikely to meet tomorrow’s needs. For example, RFID tags can only budget 2000 GE of chip area for security, this is well out of reach of current AES implementations. On microcontrollers, AES implementations are very fast but they also tend to be large and complicated. Efforts to reduce the size of implementations tend to be complex (and slow), while efforts to simplify the code produces implementations that tend to be large (and slow). Further, not every application requires the same level of security that AES was designed to provide. When resources are scarce, it doesn’t always make sense to implement an algorithm providing 128 bits of security when 96 might be sufficient. In addition, the AES block size of 128 bits is not always optimal. For these reasons, the industry has developed lightweight block ciphers. AES limitations are more apparent in hardware than in software so most of the best efforts to date have focused on hardware solutions. This work has led to the development of ciphers such as PRESENT, KATAN, and Piccolo. All of


which have a very small hardware footprint. But they cannot provide high performance on constrained software devices, such as 8- and 16-bit microcontrollers. SIMON and SPECK was designed as a lightweight block cipher that can be implemented in a wide range of hardware- and software based devices, including ASICs, FPGAs, and 4-, 8-, 16-, and 32-bit microcontrollers. And since many of these devices interact with a backend server, the lightweight block cipher should also perform well on 64-bit processors. First, let us look at the security of SIMON and SPECK versus AES, Table 2 is based on the analysis done in over 30 Crypto-analytics papers which show that SIMON and SPECK have better security when compared to AES. Crypto-analysis results usually depict the maximum number of rounds at which an algorithm remains vulnerable. For example in a 64 block/ 128 key version of SIMON, successful attacks have been found at 29 rounds or. However, since SIMON requires 44 rounds of operation and since the addition of each round adds to the strength of the algorithm, SIMON has 44-29 or 15 rounds of additional buffer. In contrast, AES-128 only has 3 rounds of additional buffer and so might be considered less secure.

Table 2 - Security of SIMON and SPECK

However as seen in Table 3, SIMON and SPECK is also roughly half the size of AES given the same block and key size. Dropping the block size would improve the area by 300 GE. This means you get more security per silicon area with SIMON.

Table 3 - ASIC Implementation of SIMON and SPECK

Size Algorithm Area (GE)

128/128 SIMON 1234

SPECK 1280

AES 2400

Application to CIP Security CIP Security makes extensive use of proven-in-use open security technologies such as:

X.509v3 Digital Certificates used to provide cryptographically secure identities to users and devices

TLS (Transport Layer Security) and DTLS (Datagram Transport Layer Security) cryptographic protocols used to provide secure transport of EtherNet/IP traffic

Hashes or HMAC (keyed-Hash Message Authentication Code) as a cryptographic method of providing data integrity and message authentication to EtherNet/IP traffic


Encryption as a means of encoding messages or information in such a way as to prevent reading or viewing of EtherNet/IP data by unauthorized parties

More specifically, EtherNet/IP uses TLS and DTLS in order to provide the following security attributes:

Authentication of the endpoints – ensuring that the target and originator are both trusted entities. End point authentication is accomplished using X.509 certificates or pre-shared keys.

Message integrity and authentication – ensuring that the message was sent by the trusted endpoint and was not modified in transit. Message integrity and authentication is accomplished via TLS message authentication code (HMAC).

Message encryption – optional capability to encrypt the communications, provided by the encryption algorithm that is negotiated via the TLS handshake.

The following diagram shows the protocol layering:

Figure 5 - EtherNet/IP over TLS and DTLS Layering

Internet Protocol (IP)

TCP

Transport Layer Security (TLS)

EtherNet/IP Encapsulation

UCMM / Class 3

CIP Application(including objects)

UDP

Datagram Transport Layer Security (DTLS)

EtherNet/IP Common Packet Format

Class 0/1

CIP I/O Application


The obvious application of the SIMON and SPECK family of ciphers is the message encryption attribute. The EtherNet/IP specification leaves the choice of message encryption as optional and refers the reader to the IANA registry. Because SIMON and SPECK are relatively new algorithms, they have not yet been adopted by any standards organizations. However, SIMON and SPECK have been submitted for inclusion in ISO 29192-2, the standard for lightweight block ciphers. This standard currently includes PRESENT and CLEFIA. This proposal is currently in review.

Clearly, ODVA use of this technology will depend upon its acceptance by a reputable standards body and by the Security community in general. Nonetheless, significant analysis of this technology has already been performed and shows great promise for robust security in constrained applications.

Alternative Security Architectures to Provide Authentication Although this paper addresses the use of lightweight ciphers to provide message encryption, CIP Security is mostly focused on message authentication provided by certificate exchange from the device to the certificate authority (CA) and on the delivery and management of certificate revocation lists or (CRL). The issue with today’s RSA based certificate exchange is very similar to the issues of using AES in physically constrained system. An architecture which supports a more lightweight authentication scheme may be an attractive alternative in these constrained cases. NIST Special Publication 800-38B describes the Cipher-based Message Authentication Code (CMAC) algorithm based on a symmetric key block cipher. This algorithm has been implemented using AES as the block cipher and indeed has been recommended for use in IPSec in IETF RFC 4494. However, the NIST special publication does not mandate the use of AES, and states the required characteristics of a block cipher that make it suitable for use in a CMAC implementation. SIMON and SPECK satisfy these characteristics. The CMAC algorithm takes a message (M), of bit length Mlen, to produce a Message Authentication Code (T), of bit length Tlen, which is appended to the outgoing message. To accomplish this end, the CMAC algorithm simply chains the block cypher by acting on a single block (Mi) and using a bitwise exclusive-OR to sum the output of each stage in the chain. On ingress, the process is repeated and the resulting MAC is compare to the MAC appended to the message. Note that the CMAC algorithm also makes use of sub-keys. These keys are distinct from the sub-keys generated for each SIMON/SPECK round, but like those keys, the CMAC sub-keys can be pre-calculated and therefore do not add an additional processing burden to constrained devices.

Figure 6 - CMAC Generation Algorithm


This enables the implementer to take advantage of the cipher already in place for encryption purposes to provide message authentication in the CIP stack. All the efficiency arguments above in favor of SIMON and SPECK as encryption engines apply equally to their use as authentication engines. One could develop a robust SIMON and SPECK based CMAC protocol as an alternative to HMAC in the TLS layer of the CIP stack thereby gaining computational efficiencies. In extremely constrained environments, the symmetric keys can be pre-shared which would eliminate the complexities introduced by X509-based key exchange.

A Practical Demonstration of SIMON in an EtherNet/IP Network Perhaps the most important aspect of SIMON is its ability to encrypt/decrypt data at line speed. SIMON introduces a minimal and fixed latency to the network. To illustrate this concept, an existing demonstration platform, running EtherNet/IP with the Device Level Ring protocol, was modified to include a link encrypted with the SIMON Algorithm. As shown in Figure 7, the demonstration consists of a Linear Sensor to provide position information to the PLC. The PLC, in turn, provides simple ladder logic to route linear sensor data to the LED display matrix. The control software on the LED matrix tracks the position of the linear sensor. The demonstration utilizes EtherNet/IP for class 1 I/O communication and DLR provides ring resiliency.

Figure 7 - Practical Demonstration of SIMON Encryption/Decryption

To incorporate SIMON, one-port of the embedded switch connected to the linear sensor (the block dot on Module “A”), and one port of the switch connected to the LED matrix (the block dot on Module “B”) were modified to include SIMON encryption and decryption engines. The encrypted link is colored red in Figure 6. A network tap is installed on the encrypted link and on the unencrypted link. A network analyzer is connected to the tap in order to demonstrate the secure link is operational and transparent to operation. The modifications to the switch IP are shown in Figures 8 and 9.


Figure 8 = Transmit (Encryption)

Figure 9 - Receive (Decryption)

The state machine monitors the packet and controls which portions of the packet are encrypted. To simplify the implementation, layer 2 routing information remains intact. All other information, including packet payload and the IP header are encrypted. As shown in Table 4, the design utilized a minimum block and round size (32-bit block, 32 rounds). The key is 64 bits. As shown in Figure 2, the implementation utilized 11 pipeline stages clocked at 125 MHz for a total of 88 nS latency for ingress and egress. As shown in figure 3, key Expansion is pre-Computed to minimize area and latency. Therefore, changing the key requires the Pipeline be stalled and flushed. The secure link proved to be completely transparent to operations. While encrypted traffic was present, no modifications to upper layer software, including the stack and application, were required. The DLR redundancy protocol was also unaffected. The ring could be broken at any point, including at the encrypted link and fault detection and ring recovery was unaffected.


Table 4 - Simon Demonstration Parameters


Conclusions It seems inevitable that Ethernet will continue to proliferate into more and more application spaces. If one thinks in terms of MAC addresses: how many MAC Addresses did the average person use in 1998? Typically less than 5: Work computer, home computer, a laptop. Fast forward to today and the average person consumes 10 to 15: Cell phone, IP phone, laptop (1 for wired, 1 for wireless), laser printer (1 for wired, 1 for wireless), set top box (2), TV, BluRay player, tablet, computer at home (2), wireless AP, etc. Ethernet has enjoyed success as a communication medium unprecedented by even radio or television. As technology becomes more cost effective this trend will continue and associated security solutions must likewise scale to address these emerging application. Lightweight block cyphers offer great promise as at least a part of a cost effective security solution for highly-constrained applications. In particular, the SIMON and SPECK family of lightweight block cyphers offer:

– A small HW footprint compared to comparable AES implementations; – A scalable, pipelined architecture; – In-line encryption/decryption; – Comparatively low latency; – Implementations in small circuits with minimal power requirements; – Comparable security to AES for a given key size.

Ethernet’s meteoric success has often left users of Ethernet technologies struggling to address security concerns associated with its application. The promised explosions of IoT, iIoT and Industry 4.0 threaten to dwarf this success and give rise to a host of new applications with extremely limited resources. It is incumbent upon users of these technologies to address security in these applications sooner rather than later.


References (optional)

Beaulieu, Ray, Douglas Shors, Jason Smith, Stefan Treatman-Clark, Bryan WeeksWeeks, and

Louis Wingers. "The SIMON and SPECK Families of Lightweight Block Ciphers."

Cryptology EPrint Archive. International Association for Cryptologic Research, 19

June 2013. Web. 11 Mar. 2015. <http://eprint.iacr.org/>.

Beaulieu, Ray, Douglas Shors, Jason Smith, Stefan Treatman-Clark, Bryan WeeksWeeks, and

Louis Wingers. "SIMON and SPECK: Block Ciphers for the Internet of Things."

Cryptology EPrint Archive. International Association for Cryptologic Research, 12

June 2015. Web. 15 June 2015. <http://eprint.iacr.org/>.

Dworkin, Morris. "NIST SP 800-38B, Recommendation for Block Cipher Modes of Operation:

The CMAC Mode for Authentication." NIST Computer Security Resource Center.

National Institute of Standards and Technology, Spring 2005.

<http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf>.

Pannell, Don. "The Looming Ethernet MAC Address Crisis." (2014):

<http://standards.ieee.org/events/automotive/2014/18_Looming_Ethernet_MAC_Address

_Crisis.pdf>.

****************************************************************************************************************************************************** The ideas, opinions, and recommendations expressed herein are intended to describe concepts of the author(s) for the possible use of ODVA technologies and do not reflect the ideas, opinions, and recommendation of ODVA per se. Because ODVA technologies may be applied in many diverse situations and in conjunction with products and systems from multiple vendors, the reader and those responsible for specifying ODVA networks must determine for themselves the suitability and the suitability of ideas, opinions, and recommendations expressed herein for intended use. Copyright ©2015 ODVA, Inc. All rights reserved. For permission to reproduce excerpts of this material, with appropriate attribution to the author(s), please contact ODVA on: TEL +1 734-975-8840 FAX +1 734-922-0027 EMAIL [email protected] WEB www.odva.org. CIP, Common Industrial Protocol, CIP Energy, CIP Motion, CIP Safety, CIP Sync, CompoNet, ControlNet, DeviceNet, and EtherNet/IP are trademarks of ODVA, Inc. All other trademarks are property of their respective owners.

http://www.odva.org/

Documents

Practical applications of Lightweight Block Ciphers to ... · with an unvarying transformation that is specified by a symmetric key. Feistel cipher - a symmetric structure used in