The presentation discusses the challenges of obtaining and decoding keys for industrial protocols such as WirelessHART and ISA100.11a, and the development of a firmware extension to enable channel hopping.
- There are a lot of different keys for industrial protocols, and they change frequently
- Obtaining keys can be done through documentation, sniffing, or buying old equipment
- The presentation focuses on WirelessHART and ISA100.11a protocols
- The development of a firmware extension was necessary to enable channel hopping
- The extension required deep diving into embedded development and implementing a bare-metal task scheduler
The presenters had to develop a firmware extension to enable channel hopping, which required deep diving into embedded development. They had to choose between using a real-time operating system or a bare-metal task scheduler, and ultimately chose the latter. They also had to ensure that their code didn't run for less than two milliseconds to avoid starving other tasks. The extension was necessary to keep up with the fast-paced channel hopping of the protocols.
Wireless sensor networks are commonly thought of as IoT devices communicating using familiar short-range wireless protocols like Zigbee, MiWi, Thread and OpenWSN. A lesser known fact is that about a decade ago, two industrial wireless protocols (WirelessHART and ISA100.11a) have been designed for industrial applications, which are based on the common IEEE 802.15.4 RF standard. These Wireless Industrial Sensor Networks (WISN) are used in process field device networks to monitor temperature, pressure, levels, flow or vibrations. The petrochemical industry uses WISN in oil and gas fields and plants around the world. Both IEC ratified standards have been commonly praised by the ICS industry for their security features, including strong encryption on multiple layers within the protocol stack, resistance to RF interference, and replay protection. While the standards in general look safe on paper, there are potential interesting attack vectors that require verification. However, security research so far has not yielded any significant results beyond basic attack vectors. Often these attacks have only been theorized, and not (publically) demonstrated. In addition, vendor implementations have not been thoroughly tested for security by independent third parties, due to protocol complexity and the lack of proper (hardware/software) tools. We strongly believe in Wright's principle,"Security does not improve until practical tools for exploration of the attack surface are made available."