Walt Boyes is Spitzer & Boyes's editor in chief.
Wally Pratt is chief engineer of the HART Communication Foundation.
Several wireless sensor network protocols had been designed when the WirelessHART team began to specify its capabilities, so it had the advantage of being able to look at what had been done. Because of the team's analysis of older protocols, such as Zigbee, WirelessHART was designed with a very high level of security built in and designed to be "always on."
An analysis of the WirelessHART protocol serves to illustrate the good decisions the WirelessHART design team made by concentrating on and designing in security. The achieved design goal of the WirelessHART team was to make the network's security robust, always on and secure right out of the box.
In this article we will show you some (but not all) of the security features that are built into the WirelessHART protocol.
Protocol Issues
While developing WirelessHART, strong security was a critical requirement due to the demanding nature of users in the process automation industry. The WirelessHART Working Group early on adopted a defense in-depth strategy using multiple layers of security. This strategy focuses on how to trust a new device joining the network, ensuring the packets are trusted at each hop along the mesh network and protecting the confidentiality of all communications between endpoints in the mesh network.
Key Distribution
The designers in the WirelessHART Working Group paid a lot of attention to how keys were managed. In WirelessHART a user may pick a different initial join key for every device in the network. WirelessHART has standardized means to enter this key manually, or the key entry may be automated by connecting the field device to the gateway/security manager. In either case, the key is communicated to the field device via a wired connection to the maintenance port. Keys are write-only: There are no HART commands to read the key from the field device.
All WirelessHART field devices must allow the join key to be written as part of device commissioning. The join key is only one of many keys in the field device. All other keys are transferred in encrypted packets. The join key is only used for the first packet from the field device and the reply from the network manager. Because a human may have entered the join key, WirelessHART recommends the metwork manager immediately change the join key once the field device joins the network.
Shared Keys
In WirelessHART keys are used for authentication and for encryption. Since WirelessHART is fundamentally a mesh network, one key is shared at the data-link layer. This is used to authenticate packets as they hop node to node. This "network key" is written via an encrypted packet early in the join process.
To enable packet routing, some fields in the packets are only authenticated. However all payloads are encrypted with a different key for each pair of devices. In other words, there are two layers of keys. In a typical WirelessHART installation, every WirelessHART Field device has six keys in use. Five of the six keys should be different for every device in the network. WirelessHART key management (aside from possibly entering the first join key) is automated and invisible to the user.
Encryption of Payloads
While developing WirelessHART, it was quickly concluded that (1) encryption was necessary, and (2) unique session keys must be supported. In other words, WirelessHART is designed so that each pair of endpoints in communication must be allowed to have a separate key. For example, if there are 20 field devices in the network, then the gateway has 20 sets of keys (1 set for each field device). The separate keys are used to perform the encryption.
WirelessHART security is designed to isolate devices; i.e., one device cannot snoop on another device. Encrypted payloads are part of the design objective to reduce the possibility of one device bringing the plant down. The WirelessHART team believes plants SHOULD ALWAYS be designed so one malfunctioning device cannot jeopardize the whole operation. This is one reason why WirelessHART is fundamentally a mesh. Consequently, the failure, whether intentional or not, of one device will not bring down the network.
Rogue Field Devices
[pullquote]Early on the WirelessHART Working Group (WG) assumed any attacker would go at great lengths with infinate resources to intrude into a network. The WG concluded that "firmware reverse engineering", cloning of devices, insertion of rogue devices into a network and other nefarious deeds would occur. This realization drove several design decisions. Including the use of the unique session keys discussed above was one of them.
Ultimately, the first line of defense against rogue devices hinges on determining which device is trusted to be in the network. WirelessHART has three trust items that can be checked: 1) join key; 2) manufacturer and 3) product name (what device is it) and tag (user's name for the device).
The join key encrypts the data in the join packet. The join key is associated with one and only one device with a given serial number (HART "Unique ID"). Devices possessing a good join key can be put into "quarantine." This allows the operator to see the name of the manufacturer and the device type name (product name) of the device. The tag of the device also can be inspected. Therefore if the operator is not expecting the device, he can veto it from joining.
That being said, even if rogue devices get into the network, they are effectively isolated and can do limited damage. If they purposely drop out of the network, they don't crash it. The WirelessHART mesh is resilient. If rogue devices start producing bad data, they should not disrupt the plant anymore than any failing device would.
Also, the rogue device cannot spoof the other device's data. The data from other devices are encrypted with a different set of keys.
Implementation Issues
The WirelessHART Working Group, consisting of many of the best engineers and technical advisors from the top manufacturing companies in the industry, made carefully considered choices about what and what not to include in the specifications.. These choices were tested and presented to the HART Communication Foundation (HCF) membership, who further reviewed and approved these specifications prior to their release.
WirelessHART Gateways
WirelessHART has extensive requirements for gateways. These gateways standardize access to the network field devices, caching of device data, access to key performance indicators (KPI) and extensive detailed network statistics. The HART Protocol also standardized communications of HART data over Internet Protocol-based networks (i.e., HART-IP). Client access to the gateways is standardized and interoperable.
That being said, client-side security was chosen not to be standardized, since it was recognized that (especially for IP-based networks) security was an ongoing evolution, and that the client-side security (and testing that security) need to be openly left to experts in that domain. In fact, WirelessHART gateways today have extensive security certifications themselves.
HART Quality Assurance Program
The HART Quality Assurance (QA) Program specifically tries to break HART-enabled devices. As part of this program, testers intentionally attempt to make devices fail and then assess the device's behavior under these conditions. This tests a critical characteristic of failure, that being the measure of a device's behavior when the protocol tries to break it.
WirelessHART field devices undergo extensive testing before they are considered compliant and become registered devices. During this testing, all communication traffic is captured using the HCF's unique WiAnalys tool (U.S. Patent #8,441,947). This tool captures all 16 2.4-GHz IEEE 802.15.4 communications channels simultaneously. Over 500 MBytes of data are captured, and the data is then analyzed to confirm compliance.
Two sets of tests are performed. In the first tests (using the WirelessHART test system) all WirelessHART commands are sent to the devices and their responses evaluated. Both good and bad packets and commands are sent. The device must behave per specifications whether the packets it receives are good or bad.
For example, the protocol specifies the minimum number of keys a field device must support. The device may store more and, in any case, has commands that indicate its capacity. The test suite confirms that devices handle the number of keys they state they can store. The tests also attempt to write more keys than a device can store and confirms that the field device returns the appropriate error messages.
A field device must not malfunction under these or any other configuration error conditions.
The second test suite consists of system-level tests. The HCF has networks running continuously on-site using different commercial off-the-shelf WirelessHART gateways. Field devices are integrated into each of these networks. Their compliance and interoperability along with long-term operation are also assessed.
The HART QA Program helps ensure WirelessHART device implementations comply with the specifications, making them more attack resistant.
Security Manager
WirelessHART requires a security manager, but how keys are selected is not specified. The methods of key selection are a well-known issue and re-invention by WirelessHART was not necessary. The WirelessHART Working Group does not believe in the viability of identifying the pattern used by the security manager for exploitation.
First, in a 20-node network, there would be (1+20 x 5), about 101 keys. WirelessHART recommends the keys be automatically changed regularly. Recognizing the pattern would be challenging unless a hacker had all of the keys.
However, assuming this were possible, and the number of possibilities could be reduced to the 156 million combinations indicated in the paper, WirelessHART devices are battery operated and only periodically wake up.. Assuming they wake up once every 30 seconds (or 1 second) it would take 54,000 (or 1,800) days or so to try all of patterns.
An attack using many keys could be tried, but once again, the WirelessHART Working Group provided a solution. WirelessHART reports all unsuccessful communications. More specifically, it counts every message where the keys don't succeed. This count is reported periodically to the gateway and on to the end user. Lots of illicit attempts to access the network can be easily detected.
In addition, a WirelessHART network typically covers a couple hundred meters. Therefore the attacker (or rogue device) would need to be physically close by and accept the additional risk that entails.
WirelessHART was designed from the ground up to have integrated security meeting today's stringent needs for a cyber-secure network. With these design feature built in to the product, security is maximized within the WirelessHART sensor mesh, and it is likely that intrusions in other areas are more apt to be the target. This has held true in the thousands of devices safely operating in plants today, as WirelessHART offers a safe and secure option to capture intellegent data every day to help operations and enterprises improve their performance.
Leaders relevant to this article: