Using on-chip TEE implementation to secure Industrial IoT devices
TEE is a new standard for securing IoT and IIoT devices. The standard is a flagship product of Global Platform and full members of the organization include but not limited to Samsung, Cisco, AT&T, AMD, Ericsson, Qualcomm and a lot more.
I am just back from first TEE hackathon. At the hackathon we were given a demo Raspberry Pi 3 to try to build security for our own IoT projects.
As I have been looking and working with industrial strength protocols to establish security for legacy and new industrial installations, this hackathon proved to be a good starting point for understanding TEE and it’s implementation.
Code in a secure-hardware zone
TEE stands for “Trusted Execution Environment” and that is exactly as it says on the label. Most modern processors made by AMD, Intel, Qualcomm and others comes with TEE enabled by default and your modern day implementations of Apple Pay and Samsung Pay are running on TEE.
It’s basically a reserved space within the processing chip, where you can store confidential and important information.
Application within the Industrial IoT
My idea at the hackathon was to implement a demo application for TEE that would use public-private key pair to authenticate a Modbus Master and also to white-list the Modbus commands, so no unauthorized user or commands could go through to the SCADA or the PLC.
Attack Scenarios
So, let’s assume our manufacturing is connected to SCADA (or a cloud), and an attacker just came around, hacked the computer running SCADA, got a list of register entries that are expected or reported by the PLC through historian. Here are the two things that can happen:
- Industrial espionage can occur.
- A malicious command can be sent directly to the controller, breaking locks and starting/stoping a load, let’s say, a motor.
The Approach to safety
In my opinion and in this day and age, each connected industrial device should have TEE stack implementation. This implementation can be of just the basic authentication type through public-private key pairs.
So, let’s say we want to implement this security layer only at the controller level, that will look like this:
Ideally, the SCADA should also have the TEE implementation.
However, that is often not the case as legacy deployments and device manufacturers does not have latest processors that are running TEE.
This leaves us to the scenario where we build a device that acts as a sort-of firewall between two connected OT and/or IIoT devices and provides hand-shake facility through public-private key pairs plus, for added protection, keeps a white-list of allowed and expected Modbus and OPC-UA traffic.
This way we can cater to all existing installations and can go on with our OT and IIoT implementations until all OEMs start doing TEE implementations in their devices.
Potential pitfall: Latency rate
Samsung Pay’s whole round-trip from the tap of the phone to completing the transaction takes 300ms, that includes https roundtrip to the payment servers. The use of TEE in the time-sensitive industry deployment will need to be checked. Latency is a big issue in industrial settings, so an initial handshake and then a period of decrypted traffic through identified devices (secure channel approach) can reduce latency with packet transfer.
Other use-cases
The example above was a typical OT scenario. However, when we talk about IIoT or M2M communication, similar approach can be used to identify devices. Also, other important use-case is of OTA OS and configuration updates.
Prototyping the IIoT security device
Although, we used Raspberry Pi 3 for the demo implementation of the TEE, it is not recommended for any serious deployment as the device is inherently insecure. The nearest device that can be used for a slightly serious implementation and prototype is the ARTIK module family by Samsung. They come with out-of-the-box TEE implementation. Here, you can find a good security write-up on how to use TEE implementation on ARTIK.
If you are interested in learning more about the security other prototype devices like Arduino, see this excellent presentation by Aaron Ardiri.
That’s all for now, should catch some of my missing sleep and will come back with more IIoT examples, findings and security related thoughts!
