Avoiding Dependence on Default Security Mechanisms | Automation.com

Avoiding Dependence on Default Security Mechanisms

Avoiding Dependence on Default Security Mechanisms

By Kinichi Kitano, Senior Engineer, Yokogawa

The wireless device-level networks that have emerged to support wireless process instrumentation and field devices claim a high degree of security. This assures users that cyber attackers will not be able to break into networks for the purpose of stealing data, accessing larger networks or manipulating control settings to disrupt a process. For example, the ISA100.11a wireless protocol uses a two-level security strategy (Figure 1), including the 128-bit Advanced Encryption Standard (AES) block cypher, as does WirelessHART. This method has not been broken and there is no known technology available today to break it.

So, does that encryption method make wireless communication on an ISA100.11a or a WirelessHART network secure? Imagine a brief analogy: a burglar wants to break into a building and finds the only entrance is defended by a very strong and sophisticated padlock. The burglar realizes he has no tools able to break the lock, but he can cut away at the doorframe until the hasp breaks free. The door has been opened, but without breaking the lock, because the hasp supporting the lock is weaker.

The moral of the story: a cyber attacker may not have to break the AES-128 encryption to get into the network if some other defensive element is not as strong as it should be. Let’s examine a real possibility, unwittingly providing a burglar with the key to the padlock. The key in this case is the password, or for wireless networks, the join key to identify a specific device on a network. When an individual or device has the proper credentials, permission is given and the connection is made. The challenge is keeping the credentials out of the wrong hands.

Figure 1: ISA100.11a uses a two-level security strategy. Transport layer (TL) security protects data with end-to-end assurance that critical messages are authenticated and remain secret. Data-link layer (DL) security protects the network, so each message is transmitted with detailed performance and security diagnostics.


Danger by Default

One of the long-recognized but persistent threats to devices and networks is default passwords. For example, a given PLC model requires a password to put it into programming mode. When it leaves the vendor’s factory, it is loaded with the same password as every unit in the product family, and perhaps even other products within the vendor’s larger offering. The user is expected to login first with the default password and then change it to something specific for the unit. In earlier years some devices had a default password which was permanent, but fortunately those are gone. The real-world problem emerges when end users inadvertently retain the default password, as explained by the U.S. Department of Homeland Security

A hacker wanting to exploit some other vulnerability within this PLC model may use Shodan to find units exposed to the Internet, and then attempt to login using the default. If the password has not been changed, the hacker now has all the privileges of an authorized user and can exploit this specific vulnerability, plus, in all likelihood, read data, modify the programming, create data or simply “brick” the PLC by deleting its program and resetting the password. This kind of action has happened countless times with PLCs, and also with network routers, access points, switches, cameras, firewalls and other hardware commonly used in industrial plants and facilities. In many cases, these devices become loaded with malicious software and added to botnets. Even Stuxnet exploited a default password.

Some vendors require resetting the password the first time a device is used, and as long as the end user company has a procedure on how this should be done using a unique, strong new password, the problem can be avoided. But if the end user company has an internal default password and all new devices are changed to it, the new one is little better than the original. If a hacker knows enough about the company, perhaps as an ex-employee, to know the internal default password, the situation is just as dangerous.


Special Needs of Wireless Networks

As just discussed, a password is assigned to a given device, or an individual account assigned to a specific person such as someone signing in to an email account. When a new device needs to be added to an ISA100.11a wireless network, it is important to have a secure method to bring it into the group so only desired and authorized devices are included. A hacker should not be able to add a rogue node to an established network (Figure 2).

The security strategy of ISA100.11a assumes an authenticated gateway shares a secret key only with a valid device. Data encryption and tampering prevention depend on the assumption that only an authenticated gateway and devices share secret keys. If a hacker obtains the secret key and poses as a device using it, then a gateway cannot distinguish between data from a valid and a false device. This type of spoof is quite dangerous, and quite common in poorly protected networks.

Figure 2: With some wireless systems, a rogue node on a wireless device-level network can be inserted by a hacker taking advantage of a default join key. With the Yokogawa system depicted in this diagram, this is not possible because there are no default join keys.


Defensive Authentication

Device authentication is an effective countermeasure against spoofing. Device authentication with ISA100.11a is based on a provisioning and secure join mechanism. Provisioning is the process of providing a secret key, the join key, to a device and a gateway. A secure network-joining mechanism necessitates mutual authentication between a gateway and a device using the join key.

The join key from the device must be loaded into the gateway before the joining process, and it should be done using a mechanism other than the wireless network to prevent eavesdropping. For WirelessHART, this is done via serial communication to a transmitter and manual data entry to a gateway. For ISA100.11a, this is done via infrared communication from a PC or a terminal to a transmitter and downloading file to a gateway.

For ISA100.11a, authentication during the joining process uses a mechanism called challenge-response where one entity proves its identity to another entity by demonstrating knowledge of the join key without revealing it to an adversary. If a hacker is trying to eavesdrop on the exchange, the response from one execution of the identification protocol as a new device joins the network should not provide any useful information for a subsequent identification, as subsequent challenges will differ. The join key is unique and secret, or at least it can and should be.

The ISA100.11a and the WirelessHART protocols each specify all the details of join process, but neither specifies the management of join keys, which is left up to the vendor. Therefore, using a wireless network join key is not an assurance in itself that the vendor has chosen the most secure method for managing join keys. One critical element is creation of the join key itself. The join key should be a unique number assigned to the device, but the WirelessHART protocol does not require it. Some wireless device vendors choose to use a default join key, just as some use default passwords.

Such vendors often justify this practice to users by pointing out how it makes setup and network management easier in some respects. When adding a new device to the network, one only has to enter the join key on the gateway once because every device on the network has the identical join key. It sounds good but makes as much sense as Ford deciding to use the same ignition key for every F-150 pickup truck—convenient, yes, but security is sacrificed.

This presents obvious security risks since any hacker wanting to spoof the system only needs to know the default join key to add a rogue device on the network. Finding these specific join keys is not difficult as they are routinely published online by non-authorized sources.


Hidden Default Join Keys

The fact that a vendor is using a default join key may not be immediately recognizable, but the use of word “default” in the installation manual is a good indication. Here are some examples of installation manual instructions for various WirelessHART devices indicating the use of a default join key:

  • Determine the network key of the existing wireless HART network which is set in the gateway. The network key consists of 32 hexadecimal characters, {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f}.
    Valid network keys are, for example:
    - 44555354 - 4e455457 - 4f524b53 - 524f434b, - 195e0000 - 00000000 - 00000000 – 00000000
  • Typically, the factory ships wireless sensors and gateways with a default network ID and join key: Default network ID: 1229, Default join key: 44555354-4E455457-4F524B53-524F434B

If perusal of the installation manual doesn’t readily reveal the use of a default join key and the join key appears to be random, check to see if it is actually an ASCII string showing a name of a vendor or a development tool company.

In all cases, unless the documentation is clear that a join key is unique to the given instrument, it is probably some variation of a default.


Working with a Secure Vendor

Vendors using default join keys often offer a mechanism to create unique join keys on a wireless gateway, and to update the default join key to a unique join key, but this requires the end user to be aware of this capability and take advantage of it.

It can be much easier to work from the outset with a vendor to recognize the need for security and deliver appropriate hardware and software as a matter of course, including management of join keys. The security of wireless communication is critical to the successful deployment of field wireless systems. Achieving security requires proper planning, configuration and installation of a secure wireless protocol and associated wireless system devices, with correct concepts and practices included from the outset.

About the Author

Kinichi Kitano is a senior engineer in Yokogawa’s CX Strategy Department of Information Technology Center. He joined Yokogawa after completing a master’s in engineering from Kyoto University with a specialty in control theory. Kitano has had a variety of responsibilities with the company over his career including DCS design and implementation, fieldbus technologies and wireless networking.

Did you Enjoy this Article?

Check out our free e-newsletters
to read more great articles.

Subscribe Now