Defeating IIoT Imposters With Device Identity Authentication

Fractal Realms series. Backdrop of fractal elements, grids and symbols on the subject of education, science and technology

Best practice integration of IIoT with corporate IT security can be difficult, but less expensive and risky over the long term. IIoT security and trust depend on authentication.  The foundation of IIoT security includes authentication of device identities, authentication and authorization of software updates and management commands, and possibly authentication and authorization of end users.  All of the systems management technologies rely on an assumption of a foundation of bulletproof device authentication; sadly, this is often lacking.

by Richard Fetik, Data Confidential


 “The times, they are a changin’” – IIoT edition

IIoT integration with IT management systems can be done ‘quick and dirty’, with many problems later. Done right, there are fewer security vulnerabilities, but more expense up front and somewhat more complexity issues to be dealt with in the integration design. The right way is to do IIoT integration to meet real world needs is for both device and server authentication, to defeat man-in-the-middle and other imposter / spoofing attacks.  This authentication is necessary in order to maintain control over remotely managed devices as well as the communication channel to them.

These are confusing times for designers and managers of industrial and medical systems, with competing goals, mixed objectives for the integration of industrial control systems into larger corporate management systems. What is clear in the field of systems control is that connectivity permits better management visibility, easier software and configuration updates, and reduced operational costs.  The risks include adding security vulnerabilities, since the same connectivity can open systems to remote attack, penetration, and compromise. And thus we have both the promise and pitfall of IIoT (Industrial Internet of Things).

The IT folks want to refer to non-IT industrial control and management as ‘OT’ or some such term or acronym, to extend their well proven IT management tool sets to manage the non-IT assets.  Nomenclature can indicate the mental framework being used to make proposals and decisions. IT integration should be resisted until basic decisions are made, at such time there will be solutions for device identity, authentication, and operational authorization somewhat better than the IT systems that have been shown to have security vulnerabilities that are just unacceptable for managing systems whose reliability is a life and death concern.

So what is the problem with the IT management systems?  Too many to list here, but high on this list has to do with device authentication technologies.  The IT nodes such as PCs, routers, etc., often have hardware authentication built-in (such as Intel’s TPM, Trusted Platform Module, and other “crypto-chips”), but not all have functionality.  As a result, the IT management systems are (have to be) designed around the lowest common denominator idea that some nodes will use various provably spoofable device authentication technologies, such as software identity and authentication values set by the same or another management tool.  This would be funny if it weren’t tragic.  It’s one of the reasons why it is so hard to secure complex IT operations.

So, if you have responsibility for the reliability, operational integrity, and security of IIoT systems, and someone tries to convince you to rely for device authentication on Certificates (as in Certificates published and attested to by a CA, Certificate Authority, as a trusted third party) for authentication of various parts of your system, with the argument that this will permit ease of integration with the current IT management system, I suggest that you reply that you want to look for a different integration approach that can rely on, integrate the use of, hardware crypto-chips such as TPMs for the device authentication  portion of the system.  And this means the authentication of all of the servers to the endpoints, as well as the endpoints to the servers. And, if you are designing a control system or network interface for an industrial system, medical system, etc., please put in the right tech, so the system ops folks can use strict rules for device (node to node) interactions, to support the integrity of the management operations.

One way to do server (and network appliance) authentication is through the use of crypto-chips such as the TPM (Trusted Platform Module) which is often already present in the server.  Another way is to employ a smartSD card strategy [read more at] – these SD card and microSD card form factors contain cryptochip functionality; this approach probably requires the addition of an SD card slot -bearing daughter board and corresponding firmware – ask the product vendor.  A third approach, suitable for some equipment, is to use the device identity and authentication functionality of a wireless carrier SIM card (which contains a crytpo chip), depending on whether wireless carrier communication is necessary for this equipment.

About the author:

Richard, CISSP, a recognized security expert, is CEO/CTO of Data Confidential, a consulting, services, and technology licensing firm for the embedded, IoT, and cloud spaces. Richard is the inventor of Data Confidential’s innovative technologies such as the Storage Firewall, secure container objects for cloud computing and secure IoT-to-cloud interactions, and a customizable storage controller architecture, built on a security framework, that accelerates application performance 100x to 1000x.