Abstract

Industrial control systems are ubiquitous and integral to social infrastructures such as our electric and water utilities, and our oil/gas, chemical, pipeline, and transportation systems. Not surprisingly given the violence and destruction reported somewhere in the world every day, the security of these distributed control systems (DCS) or supervisory control and data acquisition (SCADA) systems has become increasingly critical. An attack on these DCS would be potentially more disastrous than an attack on computer systems simply because DCS and physical plants have a direct and immediate impact on our well-being and day-to-day lives. Most recent security measures have only aimed at protecting the confidentiality, integrity, and availability of a system and its related networks. A critical area has been overlooked for too long: the sensor card or field IO module.

Since the discovery of the Stuxnet worm just a few years ago,¹ we have become more concerned and more vigilant about the security of our critical infrastructures and the DCS systems which control them. While there are a lot of moving parts to the Stuxnet story, it is known that the worm spreads via a USB thumb drive.² Consequentially, architects of industrial systems must now take deeper security measures to protect their systems. All good...however, most recent security measures have only aimed at protecting the confidentiality, integrity, and availability of a system and its related networks. A critical area has been overlooked for too long: the sensor card or field IO module.

This application note discusses the security of a DCS at its bottom layer, the sensor card. There are ways to secure the sensor card using secure authenticators like the DeepCover^® DS28E35 and DS2475 ECDSA-based ICs used as examples here. Finally, while we will speak generally of DCS systems in this application note, readers should know that SCADA systems are always implied too. Further, the term "sensor card" refers to all field devices, IO modules, and smart sensors.

The Role of the Sensor Card

The sensor card is essential for monitoring and controlling a DCS and SCADA system. Figure 1 shows the architecture of a typical DCS/SCADA system. At the bottom layer of the system is the sensor card that monitors and issues alarms to system operators. Among the typical functions monitored are temperature, humidity, motion, liquid level, water flow, smoke, door activity, power failure, current, and propane tank status.

Most of us agree that a wide-scale exploitation of these DCS systems through the sensor card is only a matter of time. Although not usually considered a potential attack platform, many believe that the sensor card should be. The sensor card is upgraded or replaced by the service technician more often than other system units. One advantage of using a standard communication interface protocol is that a service technician can use sensor replacement cards from multiple vendors on their DCS system. Here is where the benefit of multiple sources can become the liability, the vulnerability.

Unfortunately, in most cases there is no effective way to ensure that the replacement sensor card has not been spoofed, cloned, or counterfeited. But there is a way to correct this problem: add a secure authentication IC to the sensor card. This additional component completes an effective secure system which authenticates each sensor card to the highest controlling level of the DCS/SCADA network. An asymmetric signature scheme like an elliptic curve digital signature algorithm (ECDSA) is beneficial for such an authentication purpose.

ECDSA Cryptography Secures a Sensor Card

It is common for consumer disposables to be attacked by a variety of sophisticated die-level methods attempting to extract secure data, reverse device settings, or disrupt the operation to compromise system security or just to clone it. The industrial sensor card is a similar, often vulnerable target, accessible to certain unauthorized and ill-intentioned people. To provide the highest affordable protection against an inevitable malicious attack, the secure system's secure IC, like the DS28E35 here, must employ proprietary die-level physical techniques, circuits, and crypto methods to protect the private (Pr) key, control signals, and other sensitive data.

Elliptic curve digital signature algorithm (ECDSA) is an efficient and secure crypto-algorithm technology. Elliptic curves allow mathematical constructions from number theory and algebraic geometry. The curves have a rich structure that can be used for cryptography.

An optimal ECDSA implementation will use public key-based security³ and a certificate infrastructure along with a digital signature for authentication. In this scenario, the programmable logic controller (PLC) first verifies the certificate of the sensor card to ensure that it is a legitimate member of that particular ecosystem. The PLC then performs a digital signature exchange to confirm that the sensor card is authorized for this system.

ECDSA public, key-based cryptography authenticators perform these security procedures very effectively and with little effort. Not every secure authenticator, however, can perform this task. The application needs an ECDSA secure IC like the DS28E35 DeepCover authenticator which implements a FIPS 186-based ECDSA public-key crypto-authentication method. This secure authenticator has a 1Kb user-programmable EEPROM array and storage space for the public key and certificate. It also has a decrement-only counter, a private-public key-pair generator, a hardware random number generator (RNG), and memory that can be partitioned into areas with open access (e.g., unprotected) and areas where the EEPROM is read or write protected.

ECDSA involves elliptic curve operations over finite fields, which is a mathematically intensive operation to implement. While the authenticator IC resides on the sensor card, the PLC must also be able to compute a digital signature. This capability comes at the cost of much greater computational complexity for the PLC's host microcontroller, for which computation time is often a scarce resource. A companion coprocessor IC, the DS2475, is placed adjacent to the host microcontroller on the PLC module to offload the ECDSA computation. The coprocessor does not need any secret data. The functional block diagrams of both the DS28E35 secure authenticator and DS2475 coprocessor are show in Figure 2.

In this configuration the coprocessor implements a high-speed ECDSA engine for public-key signature verification that is also based on NIST FIPS 186. The authenticator and coprocessor implement their public-key signature using both Curve P-192 and a NIST FIPS 180 SHA-256 engine for setting up the input data to their respective ECDSA computation engine. On power up, the PLC can now verify the authenticator's certificate and, thus, positively identify the sensor card as part of the ecosystem. The PLC then confirms that the public key stored inside the authenticator is valid. Figure 3 shows this PLC-to-sensor module interconnection. The IO-Link^® communication protocol connects the two subsystems, but the protocol can be any of the many that exist today.

ECDSA Challenge-and-Response Authentication

In its simplest form, the ECDSA challenge-and-response authentication principle is a secure hand-shaking scheme in which the PLC presents a question (i.e., the challenge), to which the sensor card must provide a valid answer (i.e., the response) in order to be authenticated. To begin, the PLC module must first check to ensure that the sensor card is part of the ecosystem by verifying its certificate. (We will omit this step in this application note.) Having received the PLC's challenge, the sensor card's response is a valid digital signature. If the PLC cannot verify the returned signature, meaning that the sensor card gets the answer wrong, then the PLC will reject the sensor card as unauthorized (inauthentic) to the system. This rejection could simply mean that data provided by this particular sensor card (e.g., its system alarm points) will all be rejected and perhaps not sent up the chain to the system operators to ensure that the questionable data do not affect future system-control decisions.

The major components of this ECDSA authentication scheme include the 256bit random challenge, the sensor card's authenticator (i.e., the DS28E35), ROM ID, an RNG, the private key, and some other data elements. The key pair (public/private) can be generated externally outside the DS28E35 and loaded, or it can be computed inside the IC. When the key pair is generated inside the DS28E35, the private key can never be read or be removed from the device. However when an outside key pair generator is used, a strong key-management scheme is required to keep the private key from ever being compromised.

Immediately after the sensor card has been installed and powered up, the following sequences of events take place between the PLC and the sensor card. The ECDSA challenge-and-response authentication transaction sequence is illustrated in Figure 4 as follows:

1. The PLC reads out the sensor card's ROM ID, public (Pu) key, page data, etc.
2. The sensor card sends the requested data
3. The PLC generates and sends a random challenge to the sensor card.
4. The sensor card's authenticator (DS28E35) computes an ECDSA signature of the challenge provided by the PLC. The challenge, page data, ROM ID, and some other data elements are hashed to get a message authentication code (MAC). The MAC is then fed into the ECDSA engine along with the private key (Pr) and a random number to create the ECDSA signature.
5. The PLC reads the digital signature and verifies it using the public key. The PLC's secure coprocessor (DS2475) uses the same items, including the same memory data, ROM ID, and data elements to compute the same MAC. Verification is done by feeding (a portion of) the received signature, the MAC, and the public key.
6. If there is a signature–match–which there will be if the private and public keys are truly related–the sensor card is authenticated. This essentially means that the sensor card is genuine and the PLC will then accept all measurement data from it. If, however, the signature cannot be verified, the sensor is deemed fake, a knockoff, clone, or a counterfeit.

Conclusion

A DCS or SCADA is a highly complex system that needs to be secured. Simply validating that the DCS/SCADA system's servers, storage, and communications are secured is just not good enough today. The endpoints, the sensor card discussed in this application note, must also be secured so it is not vulnerable or makes the entire system vulnerable. Essentially, the security architecture design and implementation should treat the sensor cards as a threat until they have all been authenticated through the network. Here enters the ECDSA challenge-and-response authentication, which has been a very effective method for protecting intellectual property (IP) from counterfeiting and illegal copying, for protecting R&D investments, and for securing system components.

Today there is a straightforward ECDSA implementation that uses public key-based crypto-authenticators. The example devices in this application note are the DS28E35 secure authenticator and DS2475 coprocessor. Proven ECDSA security will ensure that no cloned, unauthorized sensor card can get into a system nor send false information to control system operators. Secure authenticators and coprocessors thus protect against disruption to system operation, loss of productivity, and all those related costs. Depending on the application of the DCS/SCADA, secure authenticators and coprocessors with a strong ECDSA cryptography might even save lives.