Gerlinde

The fourth revolution aka Internet 4.0 will drive what was a big “no-no” up until now. Operational and infrastructure processes will be connected with regular IT. This brings a whole new challenge of up until now unresolved security problems.

One of the ideas currently debated is to mandate unique IDs for sensors. Here is my take on that suggestion:

In itself it is a neat idea to have unique IDs, although one has to accept cultural differences and differing opinions when it comes to the idea of IDs in general. So a unique ID for sensors that cannot be tampered with, might be an interesting security approach that needs further investigation.

There are sensors out there that are more than 10 or 20 years old and they cannot be communicated with via HTTP/S protocol. So how do we get the ID onto those sensors or how do we exchange these sensors to modern sensors is not solved yet and has to be thought through.

Also one has to weigh in that there are definitely more sensors than people on this planet. Maybe we even have more sensors than atoms in the universe. The sooner we start to roll out the unique IDs to the sensors, the sooner… It’s definitely time for big data now.

Next question is, which standardized unique IDs are we going to use. X.509 certificates might come in handy, and I predict that the major sensor manufacturers will offer “secure” sensors that will be delivered with a pre-installed certificate or other form of security token and accompanying administrative software.

But does it make sense to use unique IDs? In some scenarios it definitely makes sense, but not for all. The problem lies in the rich security protocols requiring requests and responses and trusted identity providers. Sensors are there to exchange important operational and process data at fast speed to control whole plants. Let us assume we have sensor A talking to sensor B. Sensor A wants to send temperature data from a unit in its plant to sensor B. There is a problem. The temperature is rising potentially harming the process. So sensor A sends a communication request to sensor B. Sensor B gets back to sensor A: “That is all very well. But are you really who you claim you are? Identify yourself!” So sensor A sends his ID potentially in form of an X.509 certificate to sensor B. Sensor B now takes this certificate and verifies it via an Identity Provider or a Certificate Authority (CA). In the mean-time sensor A gets nervous, because the temperature has risen again and requests from sensor B to accept his information. Sensor B answers sensor A that it will soon be ready for A’s data. It only needs the answer of the Identity Provider/CA. At the Identity Provider a check routine climbs up the ladder of verifying the issuing CA’s chain. Sensor A gets desperate now and mandates that sensor B take the data, because the temperature has reached a critical point… If the verification process runs smoothly, A and B might soon be ready to exchange data. If not…

We could play this example in a different way with SAML or other authentication tokens. They all require quite a rich protocol of requesting and responding with information, which is absolutely impossible for certain processes and their control, where immediate information exchange is required.

Lastly, think about yourself. Are you going to buy and install a sensor for your home (in the fridge or controlling your lights or radiators) with a unique identifier so that all traffic might be clearly identified and used by the various big businesses or intelligence agencies?