5 +1 things driving IIoT and 4.0: Part 3, SecurityFollow article
If you are interested in industrial security concepts, you could start by reading this series of articles we’ve published in DesignSpark. You will find explanations for many important technical terms and concepts. I will not repeat these explanations but instead, focus on one problem that makes the difference of IIoT security compared to ICT security concepts.
If a central shop server exchanges information with millions of customers over the internet, the customers need to be sure to communicate with an authentic server. The asymmetric key infrastructure used in the HTTPS protocol allows customers to perform fast authentification procedures. On the other hand, the shop server also needs to ensure to talk to an authentic customer. The server verifies the authenticity by using login procedures, best practice with a multiple factor authentication.
But can we simply copy these concepts into the IIoT world? Not really! Public key infrastructure lives from the ability to connect to the internet and retrieve the trust chain, starting with the trust anchor built-in your browser. If you install that trust anchor into a “things” firmware, it gets hard to update any compromised trust anchors (root CA certificates). Updating millions of browsers installed on millions of PCs is a possible task because millions of users take care of it (if they don’t, they will take a high risk to no longer talk to the server they want to talk to). But updating hundred of things without graphical UI is a trouble maker for their owner. The fact that a “thing” is typically talking only with one server makes things easier. You do not need a trust chain. They only need to onboard the single server certificate in their firmware. This server can implement procedures for revoking and distributing new certificates when communicating with its “things”. The implementation of such processes does need, of course, a certain degree of security know-how. Common server platforms like AWS do offer such procedures.
A thing will not be able to use standard login procedures. There could never be multiple factor authentications because all the information (credentials) would always be kept in a single piece of hardware. Copying this hardware would enable “fake things” to compromise the IoT communication.
A common way to authenticate things is to generate individual certificates for each thing on the server-side and transfer the certificate. This process is typically done during the deployment process, which is often called “provisioning”. And besides that fact that you could still copy things to compromise the communication, this provisioning process is a weak point of security.
Please keep in mind: Security in IIoT is not only about the protection of data! You surely do not want your production data read by other companies. But IIoT is also about new business models. And your clients could not benefit from the services you offer if half of the data the cloud is analysing is fake data generated by an intruder who wants to compromise your service. This is why reliable device authentication is so important.
Installing individual certificates on devices (things) when manufacturing them could result in a logistic challenge. Because at the end of the day, you want to know which device you are talking to and who is in charge of that device (who owns that device and its data). This is why the device’s owner initiates the provisioning. The owner needs to start the server process by using his credentials or any type of token-based identification. This way, the server can assign the device authenticity (its individual certificate) to the device’s owner account.
Using AWS, e.g., the device certificates can be provided by the AWS server during a time-limited initial session with such a device and registered owner. But the owner can also pre-install individual device certificates on a bunch of devices. In both cases, these concepts imply a high degree of trust in the users (owners) to keep credentials or keys secret. The implementation of such processes into the firmware does demand a high degree of security knowledge. But with platforms like AWS, you get their support and libraries to realise such projects.
Suppose you have read the series “industrial security” you already know: There are easier ways to implement security and individual certificates into devices. Crypto chips on the market with standard bus interfaces (I2C, etc.) can securely provide individual certificates and cryptographic calculations. These inexpensive chips do the work for you and leave the rest of the implementation to the server programming team.
Another significant advantage of hardware-based security is that such systems provide complete protection of the certificate. The underlying private key can be hidden inside the so-called chip DNA, making it impossible to copy the device’s key. With a challenge-response-request from the server, the server can prove the authenticity of the device. Encrypting the certificate by ECC and using a high key length (512 bit would have the same security as 15360 bit RSA keys) will provide a high chance of life-long security for a device. So there is no need for remote updates of the device certificate.
Security is a driving force for IIoT. The educational system needs to put more emphasis on teaching the basic concepts to our young engineers. This will be the only way to get more security and realistic provisioning procedures into IIoT quickly.
Further articles in this series are available: