Embedded TLS 1.2 Implementation for Smart Metering & Smart Grid Applications

Atta Kofi Nsiah, Axel Sikora, Andreas Walz, and Artem Yushev

1. Introduction

The distribution and metering of energy is a domain which is expected to benefit significantly from the adoption of Internet-of-Things technology. It will accommodate the requirements imposed by a decentralized energy production but also bear the potential to increase the overall efficiency and the comfort for customers.

Naturally, the remote accessibility of sensitive data and controls in these systems poses a severe security threat and appropriate countermeasures need to be applied. One integral part of this is the mean to transfer data between involved parties and devices securely, i.e. in an authenticated, encrypted, and integrity-checked way. The transport layer security (TLS) protocol is a mature and well standardized solution to this problem[1]. However,deploying TLS and respective cryptographic operations in resource constrained systems like smart meters is a non-trivial task and requires dedicated efforts.

Currently, we are developing emBetterSSL, a TLS implementation that is addressing the specific challenges in embedded communication systems. Smart grid and smart metering systems constitute a prime example for its targeted applications.

This paper provides an introduction to emBetterSSL in the context of smart metering applications. It is structured as follows: Section 2 provides a brief overview of smart metering and smart grid applications as well as security requirements related to them. The TLS protocol is outlined in Section 3. Sections 4 and 5 present our TLS implementation and our test setup, respectively.Measurement results and performance characteristics of emBetterSSL are given in Section 6. Section 7 presents related work. Finally, Section 8 summarizes the paper and provides an outlook to future work.

2. Smart Grid Applications and Related Security Requirements

Smart grid systems represent a very large and distributed network of intelligent end nodes that are closely linked to energy distribution and metering[2]. In addition to a communication network of high complexity, these systems comprise a variety of different stakeholders. This comes with both an incentive and the potential for cyber attacks on these systems. Some conceivable threats include the manipulation of billing information to obtain free energy, taking unauthorized control of individual electrical units or global load distribution instruments, or compromising a customer’s privacy. An adequate security architecture must therefore ensure that control can only be taken by authorized entities and sensitive data is authentic and confidential.

A smart metering system is currently in commissioning phase in Germany and can act as an instructive show case for these kinds of systems.

2.1 Smart Metering in Germany

The architecture of the smart metering system in Germany is depicted in Fig. 1. Its central communication unit installed on the customers’ premises is the smart meter gateway (SMGW). It is acting as a communication and data processing agent bridging between the wide area network(WAN), the local metrological network (LMN), and the home area network (HAN).

Fig. 1. Architecture of smart metering system in Germany(adopted from [3]).

For a safe and secure operation of smart metering systems, the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI) has developed and published a protection profile[3]and a set of technical directives[4],[5]which define obligatory requirements for these systems.Among others, an integral requisite is the use of the TLS protocol in its current version 1.2 for wide areas and in some configurations for local (on-site) communications.For asymmetric cryptography algorithms based on elliptic curves need to be used, while for symmetric encryption the AES algorithm is mandated. Furthermore, the maximum lifetime of TLS sessions is restricted

Towards the WAN, the SMGW is acting as a TLS client and as a TLS server for meters in the LMN. Thus, a full-featured smart meter gateway needs to implement both the TLS server and TLS client functionalities.

3. Transport Layer Security (TLS)

The TLS protocol is able to provide a secure tunnel for confidential, authenticated, and integrity-checked data transfer. It has to be operated over a reliable, though potentially insecure, and connection-oriented communication channel. TLS itself is connection-oriented and follows a client/server model with well-defined roles.Taking advantage of a public key infrastructure (PKI), the secure connection can be established without the need for the communicating parties to share cryptographic secrets in advance. Datagram TLS (DTLS) is a variant of TLS suitable for unreliable transport protocols[6].

TLS has been subject to several revisions in the past,some of them were triggered by the discovery of vulnerabilities and potential attacks of varying exploitability[7]. To the best of our knowledge, TLS 1.2 can be considered secure unless legacy cryptographic primitives or configurations are used.

3.1 Structure of TLS

TLS is composed of five sub-protocols (see Fig. 2). The record protocol performs the fragmentation of messages as well as bulk data encryption/decryption and computation/verification of message authentication codes (MACs).Stacked on top of the record protocol are the handshake protocol, the change cipher specification protocol, the alert protocol, and the application data protocol. The first two are responsible for establishing and negotiating a TLS connection. The alert protocol delivers error messages and the application data protocol is used to transfer raw application-layer data.

TLS uses the concept of cipher suites to bundle cryptographic primitives to expedient combinations. Each cipher suite specifies a symmetric cipher for bulk data encryption (including the key size), an algorithm for the computation and verification of MACs, and a key exchange algorithm (including authentication).

Fig. 2. Overview and interrelation of the components of TLS.

3.2 Connection Establishment

Any TLS connection is commenced by a handshake which constitutes the most important and computationally most expensive phase. It is triggered by the client and initiated by the exchange of two “Hello” messages between the client and the server. These messages facilitate the negotiation of protocol parameters and the exchange of cryptographic nonces to prevent replay attacks.Authentication of the communication partners and the establishment of shared secrets are achieved by the exchange of dedicated certificate and key exchange messages. Finally, finish messages complete the handshake.

A full TLS handshake involves asymmetric cryptographic operations to authenticate the communication partners and to generate a shared master secret among them.Depending on the configuration and the type of PKI in place, different cryptographic algorithms such as RSA,Diffie-Hellman (DH), DH with ephemeral keys (DHE), or the digital signature algorithm (DSA) may be used. For DHE and DSA, also variants based on elliptic curve cryptography (ECC), called ECDH, ECDHE, and ECDSA,are specified. Each algorithm and its variants have specific performance and security characteristics with potentially different load impositions for the client and server[8].

TLS features the possibility to reuse a master secret from a previous connection between the same communication partners. Running this abbreviated handshake skips most cryptographic operations and significantly speeds up the process. The security of the new connection is preserved as long as the master secret has been kept undisclosed. This feature is of particular value in resource constrained systems regularly requiring short-time connections between the same devices.

3.3 Bulk Data Transmission

After the authenticity of the communication partners has been verified and the master secret has been established,application data can be encrypted/decrypted using a symmetric cipher and integrity-checked by adding/verifying MACs based on the keyed-hash MAC (HMAC)construction. For this, data is fragmented into TLS records of not more than 16 kilobytes application data and one MAC per record. If application data and MAC don’t make up an integer multiple of the cipher’s block size, at most 255 padding bytes are added, where the actual number is chosen on a random basis to obfuscate the true message length.

4. TLS Implementations for Embedded Communications

EmBetterSSL is a TLS implementation developed and maintained by the authors’ team. It is fully written in ANSIC and optimized for the use in small embedded microcontrollers. In addition to its modular architecture, its high efficiency on smaller microcontrollers, and its excellent portability, the use of an abstract interface to the provider of cryptographic services is one of its advantages.

Its main components are the implementation of the TLS protocol itself, a well-defined interface to a cryptography engine, and a certificate manager in charge of managing and validating certificates.

EmBetterSSL’s modular architecture allows switching easily between a software-only cryptography engine and a hardware-supported cryptography. For the current implementation, the LibTomCrypt[9]software library is used. Currently, work is ongoing to integrate support for a VaultIC from Inside Secure[10]and a hardware-based security module which kindly has been provided for testing purposes by Inside Secure. It allows outsourcing computationally expensive cryptographic operations from the main CPU to dedicated hardware and additionally features a safe key storage.

The key exchange algorithms supported by the current version of emBetterSSL are RSA and DHE, while for signatures of certificates, RSA is available.

The security of emBetterSSL has been evaluated using a comprehensive test suite composed of positive as well as negative test cases. In addition, we used the vulnerability assessment system OpenVAS[11]to ensure emBetterSSL is not affected by flaws known from other TLS implementations. Furthermore, we are working on an approach for pseudo-randomized protocol testing that is going to be applied to emBetterSSL in the near future.

5. Test Setup

The objective of our test setup is to provide a platform facilitating functional tests, the validation of security features, the analysis of software and hardware requirements, and finally the performance profiling of emBetterSSL.

The test setup consists of a Linux PC, an embedded platform hosting emBetterSSL, and the network equipment for Ethernet/TCP/IP-based communication between the former two. An overview of the setup is given in Fig. 3.

Fig. 3. Test setup for TLS implementation.

5.1 Embedded Platform

An STM32F4 Discovery Board is used as an embedded platform running the TLS implementation under test. Its MCU, an STM32F407, is clocked with 168 MHz. An Arduino Ethernet Shield based on the Wiznet W5100 chip is wired via SPI to the MCU to provide TCP/IP connectivity.Two UART-based serial channels between the embedded platform and the PC are used to control the system and to read timing information, respectively.

Timing information is obtained by means of a lightweight mechanism to record time stamps in relevant places of the execution path of the TLS implementation. It is based on an internal counter of the MCU and offers a time resolution of 10 μs. The uncertainty is thus correlated with the onboard clock source and is assumed to be small enough to be neglected.

For both server and client roles, the software running on the embedded system implements a loop-back functionality which is echoing any application data received via a TLS connection. For source code compilation “arm-none-eabi” toolchain version 4.8.4 is used with code size optimization.

5.2 Linux PC Environment

A standard office PC running Linux is used as a control and analysis platform. In addition to the two serial channels,it is connected to the embedded platform via a local Ethernet interface for network communication.

A Python-based tool is used to configure the parameters of emBetterSSL via the first serial interface, while a second Python-based tool is decoding the timing information read via the second serial interface. OpenSSL 1.0.1k in either server or client mode is acting as the counterpart for our TLS implementation under test and is invoked from a Python script. Finally, a super-ordinate macro is automatically calling the aforementioned tools to run the complete test suite.

6. Performance of Embedded TLS

Our test setup allows profiling the timing characteristics of our TLS implementation with high accuracy and—with respect to a breakdown of operations performed—with high granularity.

6.1 Test Cases and Performance Figures

The test configurations used and presented here have been chosen to comply with the requirements for smart metering systems in Germany as briefly outlined in Section 2 as much as possible. However, as previously indicated,ECC is still to be integrated in emBetterSSL, and thus an alternative setting has been used.

In order to evaluate emBetterSSL in view of use cases typical for smart metering systems and to provide a complete picture, the following performance figures have been derived: Time for booting, i.e. initialization of libraries and context data, time for establishing a new TLS connection with and without session resumption, time for handling a single block of application data (16 bytes), i.e.encryption/decryption and MAC computation/verification,and the average data transfer rate.

During the boot phase, the system is reading and initializing certificates from the certificate store as well as generating ephemeral key materials to be used in DHE-based key agreement algorithms. The boot or reboot of a system is assumed to be a rare event in smart metering systems.

Setting up a TLS connection from scratch involves executing a full TLS handshake including authentication and key exchange. It is expected to happen frequently in the context of smart metering, though many connections might reuse key materials from previous sessions. However,session resumption instead of another execution of the complete handshake is legally permitted only under certain circumstances[5].

The amount of data transmitted per connection is generally expected to be small, or even very small in the LMN. Thus, the time needed for handling the smallest possible amount of application data (block size of the AES block cipher) is measured together with the average data transfer rate derived from the transmission of 1024 bytes of application data within a single TLS record.

The following parameters have been selected and are fixed for all measurements:

· TLS protocol version 1.2;

· Certificate-based authentication of both client and server using RSA-based keys and signatures with the client’s and the server’s certificates;

· TLS key exchange using the DHE_RSA scheme with a DHE key size of 192 bytes;

· AES in CBC block cipher mode;

· SHA256 as a MAC algorithm.

Table 1: Arrangement of channels

Furthermore, the following parameters have been varied and measurements have been performed for different combinations (the complete test suite is summarized in Table 1):

· Size of public keys and signatures in X.509 certificates(RSA_SHA256): 1024 bit and 2048 bit;

· Negotiated TLS cypher suites: DHE_RSA_AES128_CBC_SHA256 and DHE_RSA_AES256_CBC_SHA256;

· Handshake types: Full handshake and session resumption.

It should be noted that in order to minimize the influence of OpenSSL and network communications, the numbers in the following section are derived from accumulated durations of operations performed by emBetterSSL and explicitly exclude time periods where emBetterSSL is in a waiting state. That is, the numbers do not necessarily resemble the absolute latencies and transmission rates observed by a user.

Furthermore, unless otherwise noted measured quantities from multiple repetitions of the same measurement exhibit a negligible variance and thus only the averaged result without standard deviation will be given in the following. The exception to this is the time for the encryption and decryption of small messages where the non-deterministic addition of padding bytes results in significantly varying timings.

6.2 Measurement Results

The system requires approximately 4.4 s for booting.Performing an initial handshake to establish a new TLS connection requires slightly less than 2 s and slightly more than 3.5 s processing time on the embedded system using 1024 bit and 2048 bit RSA keys, respectively. As expected,these numbers are independent of the key size of the symmetric cipher as well as whether emBetterSSL acts as a client or as a server. As seen in Fig. 4, the MCU spends a significant amount of time to compute the shared DH secret.The remaining time is mainly used for the authentication procedure, i.e. the verification of certificates and respective signatures.

Fig. 4. Comparison of processing costs for a TLS handshake in MCU cycles. For TC01, TC03, and TC09 emBetterSSL is acting as a server, whereas for TC02 and TC10 it is acting as a client.TC03 is using session resumption and the corresponding result is shown scaled by a factor of ten for the sake of visibility.

Fig. 5. Comparison of processing costs of 16 bytes of application data in MCU cycles. TC01 and TC04 have been measured using a message size of 16 bytes, whereas TC07 and TC08 give the amortized costs of processing 16 bytes determined using a message size of 1024 bytes.

Session resumption is independent of the previous authentication and key exchange scheme and takes slightly less than 20 ms. Again, this number is independent of the key size of the symmetric cipher and emBetterSSL’s role.

After a TLS connection has been set up, processing 16 bytes of application data (Fig. 5) for transmission or reception over the TLS tunnel (encryption/ decryption and computation or verification of the MAC) takes on average less than 0.8 ms and 0.07 ms for 16 bytes and 1024 bytes of data, respectively. The distinctive dependence on the message size is due to a large constant contribution whose effect is amortized for long messages. The difference between using AES with 128 bit or 256 bit keys is less than 10%. Detailed numbers are presented in Table 2.

Table 2: Performance results

On the embedded systems, a variation of the encryption time across multiple runs of the same measurement is observed which is not present for decryption (indicated as standard deviation σ in Table 2). The reason is the variable padding length which contributes a significant portion of the total data length for short messages. Interestingly, in contrast to our TLS implementation, OpenSSL seems to use the shortest possible padding in any case resulting in a negligible variation for decryption.

7. Related Work

Reference [12] presented a DTLS-based security architecture for embedded devices and found a handshake performance of the same order as our results. However, e most related work focused on absolute timing, in contrast to our measurements. Reference [8] evaluated the TLS handshake performance in embedded devices using relative timing and bandwidth metrics.

8. Summary and Outlook

We presented the performance results of the TLS implementation specifically optimized for use in deeply embedded systems, as they can be used in smart grid and smart metering applications.

For an initial handshake we found a processing time on the embedded system between 2 s and 3.5 s, depending on the key size used for authentication.

Resuming a previous session takes less than 20 ms and thus it constitutes a considerable speed-up of the handshake process. Our results clearly indicate that the bottleneck for those systems, which transmit only small amounts of data per connection, is the initial handshake. Processing time for application data does not seem to play a critical role and doubling the AES key size degrades the performance by less than 10%. The analysis shows that, if carefully implemented and configured, the deployment of TLS in resource-constrained smart metering systems is well possible with acceptable overhead.

Currently, our work is ongoing to implement support for key exchange and signature algorithms based on ECC and to integrate cryptographic hardware support into emBetterSSL. New features will be used to update our measurements accordingly in the near future. Furthermore,we are working on a framework enabling pseudo-random testing of the implementation’s robustness against adversarial input.

[1] The Transport Layer Security (TLS) Protocol Version 1.2,RFC5246, The Internet Engineering Task Force, 2008.

[2] E. D. Knapp and J. T. Langill, Industrial Network Security:Securing Critical Infrastructure Networks for Smart Grid,SCADA, and Other Industrial Control Systems, Syngress,2014.

[3] BSI TR-03109 Protection Profile for the Gateway of a Smart Metering System (Smart Meter Gateway PP), Bundesamt für Sicherheit in der Informationstechnik, 2014.

[4] BSI TR-03109 Technische Vorgaben für intelligente Messsysteme und deren sicherer Betrieb, Bundesamt für Sicherheit in der Informationstechnik, 2013.

[5] TR-03116-3 Kryptographische Vorgaben für Projekte der Bundesregierung, Bundesamt für Sicherheit in der Informationstechnik, 2015.

[6] Datagram Transport Layer Security Version 1.2, RFC6347,The Internet Engineering Task Force, 2012.

[7] C. Meyer and J. Schwenk. Lessons learned from previous SSL/TLS Attacks—A brief chronology of attacks and weaknesses. [Online]. Available: http://eprint.iacr.org/2013/049.pdf

[8] M. Koschuch, M. Hudler, and M. Kruger, “The price of security: A detailed comparison of the TLS handshake performance on embedded devices when using elliptic curve cryptography and RSA,” in Proc. of E-Business and Telecommunications, Springer, 2012, pp. 71-83.

[9] Cryptographic Software Library “LibTomCrypt”. [Online].Available: http://github.com/libtom/libtomcrypt

[10] Inside Secure, Hardware-Based Security Module“VaulticIC”, [Online]. Available: http://www.insidesecure.com/Products-Technologies/Secure-Solutions

[11] OpenVAS: Open Vulnerability Assessment System. [Online].Available: http://www.openvas.org/index.de.html

[12] T. Kothmayr, C. Schmitt, W. Hu, M. Brunig, and G. Carle,“A DTLS based end-to-end security architecture for the Internet of Things with two-way authentication,” in Proc. of the 37th Annual IEEE Conf. on Local Computer Networks,2012, pp. 956-963.