The Chicken-or-Egg Problem around OPC UA Security

If you read any of the OPC UA literature, or study the books I’ve written on OPC UA you’ll find that security is one of the prime features of the OPC UA architecture. It’s one of the differences between OPC UA and many other Ethernet and IoT (Internet of Things) technologies.

OPC UA provides both authentication and authorization. Authentication operates at the device level. Using the authentication services, an OPC UA Server can verify the identity of the Client device which requested the connection. Authentication prevents rogue devices from spoofing a server’s controller.
Once the client is authenticated, authorization verifies that the user for that device is authorized to access the resources of the server. This makes more sense for Client devices that have an application that is used by different users than it would for a programmable controller client.
For a PC client, one user may be authorized to retrieve a limited set of data, while other users may have the authorization to modify configuration settings on the device. For a programmable controller client, it still might be best to limit the data that a controller can access to limit the damage if the controller is hacked.

The authorization and authentication services provided by the OPC UA architecture are far more sophisticated than anything offered by other technologies. It’s one of the reasons that many trade associations are using OPC UA to implement their data models and provide messaging services.

Who determines the request for connection
There is a hidden secret to all this – actually it’s not so hidden, people just kind of ignore it. OPC UA devices implement the authorization and authentication services I’ve just discussed, but the final actual adjudication of request rests with the OPC UA Server application itself. Let’s take a look at it in a little more specific detail.

When a request is received to connect to a server, the server validates the request, decrypts it and validates the certificate. Once a valid request for authentication or authorization is received and decoded, the next step is to determine if the server should accept the connection from that device or allow access to that user. It’s very important to realize that the OPC UA software stack does not do that. It passes that to the application to make the final determination of the request.

The OPC UA specification says nothing about how an application validates an authentication or authorization request. It is entirely up to the application as to how it should determine what devices can connect to it and what users can access what resources.

Can OPC UA be used to maintain that list of valid devices and users? Yes, but until you have the list, how can you authorize a user to build the list? It’s a chicken and the egg problem.

You certainly won’t want a default user like “admin” with unlimited authority to build and modify the access list – that’s inviting trouble. And if you have store certificates of valid devices and users, who creates and manages those certificates. What is the certificate authority for those certificates? How do they get into all your servers? How do you secure that process?

OPC UA provides a very good security infrastructure but it doesn’t solve all your problems.