Secure or Not Secure… That is the Question.

Let’s face it gang, the Internet of Things (IoT) has a completely horrible security track record. Companies want to push out the latest in buzz-worthy tech and make that dollar (or Yen or Euro) without a single thought given to securing their devices or their pathways to cloud services. Thanks to these guys, botnets like Methbot and Mirai were born in 2016 and continue to cause mischief around the Internet today.

Shifting focus to the industrial realm, it should come as no surprise that people became seriously concerned with any sort of IoT-related devices and their corresponding wireless connectivity. Even before the Industrial Internet of Things (IIoT) became a thing, the scrutiny of wireless networks’ security on the factory floor began.

So here we are today. With demand for various wireless services ever increasing, we have to ask ourselves, “Are the IIoT devices, sensor and WiFi access networks that are being deployed secure? Are we doing enough to protect these production assets?”

These are actually huge questions with no easy answers. What we can do, though, is find a starting point, grab a shovel, and dig in a little bit.

Let’s take a gander (that’s Southern for “take a look”) at some of the most popular wireless communication protocols on the plant floor today, and see what they have to offer in encryption and security options to protect their data transmissions. This will by no means be an exhaustive list as I do have a day job and a family I would like to see and spend time with.

Since pure WiFi access is by far the most common form of wireless access, we will start off this security extravaganza with it. The nice thing about 802.11 is that it is a pretty mature technology. We have seen the beginnings of encryption with the creation of WEP and watched it grow up and flower into the WPA2 that we all know and love. Not long ago, we were also witness to the birth of WPA3, the latest and greatest of WiFi Security! So, from an evolutionary standpoint it looks like this:

Encryption Types or Methods
WEP (64-256 bit)
WPA (256 bit) TKIP/AES
WPA2 (256 bit) TKIP/CCMP/AES
WPA3 (192-384 bit) AES/SAE/OWE

The other nice thing about being a more mature technology than its brethren is the multitude of other security measures in the upper layers of the OSI model to further protect the wireless network and its data. Things like Enterprise 802.1x Authentication, VLAN segmentation, Role Based Access and wIDS/wIPS top the list of literally hundreds of other options. Hooray for Defense in Depth strategies!

Next, we have the 802.15.4 family of protocols: 6LoWPAN, Bluetooth Low Energy (BLE), WirelessHART, ZigBee, and Z-Wave. One of the nice things about this standard is that it has built in end-to-end encryption on the physical link layers. All of these IoT/IIoT protocols use Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP) with 128-bit AES encryption. That’s good to know and all, but encryption isn’t everything. What else are these players doing to protect themselves?

6LoWPAN is all IPv6 by nature and that alone makes it a little more complex on the back end than many of us are used to. (To be honest, I have yet to professionally embrace IPv6. IPv4 is torturous enough as it is). However, complexity does not necessarily mean more secure. More often than not it means less secure. One of the things 6LoWPAN has done is to add a TLS layer compatibility to its uplink communications to the rest of the network. It has even gone so far as to develop a Datagram Transport Layer Security (DTLS) module as well for those networks that rely on UDP for their transport layer protocol.

Bluetooth Low Energy (BLE) in its 4.2 release has increased security to its device pairing. It added an Out-of-Band pairing option using Near-Field Communication (NFC) to prevent any pairing hijacks. How about that? Wireless helping wireless – that’s good stuff right there! Additionally, they added a Low Energy (LE) Secure Connections procedure that uses a single long-term key per network for encryption once connections have been made. If that was not enough, a Numeric Comparison feature was added to prevent duplicate keys from existing on the network and thus making it more resilient to Man in the Middle (MITM) attacks.

WirelessHART has long been a leader in secure IIoT connections and has been used not only in critical processes, but in wireless safety systems as well.  WirelessHART has Message Integrity Checks at both the Link and Session layers. It also has a secure authentication method for joining devices to help in mitigating MITM attacks. For each deployment there is a Security Manager. The Security Manager is responsible for managing the join keys and their authentication to the network. These keys use 128-bit encryption of their own to keep data private that is used in the joining process.

ZigBee, everyone’s favorite and fun to say IoT protocol, has a couple of additions as well. First, it creates a Trust Center, or TC, which is usually the network coordinator. The TC forms more of a centralized network as it configures and authenticates routers and devices to join a network. The TC creates a unique pair of link keys for each device which are 128-bit and encrypted. The ZigBee command structure includes a frame counting mechanism. This mechanism specifically stops replay attacks in which an attacker could record and replay command messages to disrupt network communications.

Z-Wave upgraded its S0 security to its newer S2 Framework. This framework moves to a key structure using the Elliptic Curve Diffie-Hellman system (like most of the others on this list). The ECDH systems uses secret separate keys whose encryption patterns cannot be detected or copied. Codes of authentication have also been added for safety.

LoRaWAN (or just LoRa) is one of the two long range IIoT protocols discussed here. LoRa is not an 802.15.4 standard. It is a standard all its own, known as the LoRaWAN Open Standard. It does share end-to-end encryption like its neighbors on this list, but it is 128-bit AES-CMAC/CTR not AES-CCM. LoRa uses proprietary AppKeys which are unique 128-bit AES encrypted keys with globally unique identifiers. All traffic is protected by additional session keys, payload encryption, and Message Integrity Codes.

The second of the long range IIoT protocols is WiFi-ah, better known as HaLow (pronounced hay-low).

HaLow is unique in that it is actually an 802.11 protocol. Thus, it is capable of using all of the latest and greatest security applications that standard WiFi uses. This probably makes it some of the most secure 900MHz IoT/IIoT traffic in the world, in my opinion. It has added compatibility with TLS for upper layer data transfers though.

After this brief run through of these more popular IoT/IIoT protocols, the question remains: Secure or not secure? From all of the reading and research I did for this piece, I have to say that they are fairly secure. Are they perfect bastions of digital strength and resiliency? Well… no. But we have to remember, there is no single magic bullet when it comes to network security of any kind. Be it application, data center, standard wired networks, or wireless, it is the various layers we build to protect our data for both integrity and privacy. This is the whole point behind a Defense in Depth strategy.

I think the developers of these protocols are doing the right thing and are ever looking for better ways to secure these wireless environments. They need to keep it up, though, because seeing that video on Youtube.com where these guys pop a Bluetooth Low Energy (BLE) lock from a quarter mile away makes me cringe.

Below is a quick reference sheet in PDF format of the material discussed here. Download it, share it, print it out and let your dog eat it. Or maybe keep it around as a tidbit of useful information.

If you have enjoyed what you have read, follow this blog as I share my experiences, blunders, how-to’s, tips, and opinions in all things OT Wireless from the wonderful world of industrial WiFi!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s