By Eric Murphy, columnist
Whenever someone is looking at adopting a new technology, it is not unusual to have reservations or feelings of doubt. No doubt there are people out there with questions and possibly reservations about OPC UA security. Another kind of “reservation” people have are the ones one makes at a restaurant or hotel. Oddly enough, hotel reservations are good way of explaining some of the concepts of OPC UA Security.
The Bellagio or the Bates Motel…
Consider the wide range of security you may have encountered in hotels. In some places security is a sleepy desk clerk, a brass key on a chunk of time-worn wood and a flimsy door lock. At high-end establishments, room access is controlled by a modern time-specific, area-restricted electronic pass card. In terms of hotel security, many classic OPC implementations are like a low-end youth hostel. If you can get past the desk clerk, a.k.a. the DCOM configuration, you have access to every room and every thing. It could be tightly configured, but more commonly it is disabled all together. Hotels with a higher focus on security add additional layers of security, such as restricting elevator access to specific key holders, or requiring a key to access amenities like the pool or weight room. This sort of layered security would be akin to OPC products that implement the OPC Security specification.
Key for Room 509 Please…
OPC UA provides the infrastructure for multiple tiers of security implementation. OPC UA Security consists of authentication and authorization, encryption and data integrity via digital X.509 certificates. X.509 is a standard for PKI (Public Key Infrastructure) in cryptography, which defines specific formats for PKC (Public Key Certificates) and the algorithm that verifies a given certificate path is valid under a given PKI. While all that sounds very impressive, it is not hard to understand how some people have reservations about the user-friendliness of OPC UA security. However PKI is really not as complicated to understand as it may seem.
When you check into a modern hotel anywhere in the world, there is a well-known process in order to get the room key. Before you arrive at the hotel, presumably you have a reservation under your name. At check-in time, you request your key; the desk clerk asks for some trusted form of identification and then gives you a key card that provides access the room or rooms of the hotel’s choosing. When your stay is up, the key card access expires, and you no longer have access to the rooms, even if you keep the card.
The process for making a secure connection between OPC UA clients and servers is really not that different. OPC UA security uses PKI, which ensures that people are who they say they are and also proves that data hasn't been tampered with. This is achieved through the use of large prime numbers called keys. Two keys are involved—a Private key, which only the OPC UA client has access to, and a Public key, which can be accessed by anyone. The two keys work together, so a message scrambled with the Private key can only be unscrambled with the Public key and vice versa. The OPC UA client’s Private key would be like the room-specific coding on a person’s hotel key. It will only open the door to their room, and the user must keep the key secure to ensure the security of their room. The Public key could be thought of as the programmed door slots. Anyone can walk up to a door and try their key, including other guests or anyone with a key card from any other hotel. Only the matching key and slot will grant access.
Of course, this raises the question of how to verify that the correct signature is being used with the correct keys. This is where the concept of trust enters the system, creating the need for a Certificate Authority to verify identity. In the hotel analogy, this is the role of the desk clerk. He or she is responsible for handling the issues such as:
- How do you check credentials when issuing the key card?
- What process is used to detect lost or stolen cards?
Who maintains the lists of who has access to what doors?
Rooms to Fit Any Need
Just as there are differences between the duties and responsibility of hotel desk clerks, OPC UA servers from different vendors will provide different tiers of security which balance security versus convenience. The OPC UA specifications provide a consistent foundation that allows vendors to develop applications that meet any tier's requirements without having to re-architect the application. This foundation also allows users to choose a lower tier if that is all their application requires.
Small Ad-hoc Network Tier – This is akin to the small town bed-and-breakfast. If the owner has met you and had a nice chat, he or she will give you a room key. The OPC UA client applications would be issued a self-signed certificate. The OPC network administrator would manually add the certificates to a trust list the OPC UA server references. Only OPC UA applications in the trust list would be granted access. This installation step would be much simpler than the DCOM configuration process of classic OPC implementations today.
Normal Corporate Network Tier – Most hotels require the users to present a credit card. The implication is that they trust you because someone they trust says you are trustworthy. This is the role of an external Certification Authority. The OPC UA application would be issued certifications which are issued by a company controlled or corporate Certification Authority. At installation time, each OPC UA application would be issued the certificate and be configured to trust all certificates from the company CA.