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.
High Security Tier – This would be like a hotel that often has high-profile guests or offers different amenities to different guests. The room key may also grant access to restricted elevator floors, the pool at special times or access to the hospitality suite. In the High-Security tier, OPC applications would use a combination of local trust lists and Certification Authorities. Each application's trust list would have to be managed centrally, but administrators would have fine-grain control over who has access to what. OPC Security Gateway servers could be used to provide access to other servers using lower security tiers or to provide users with easy management of security settings.
Anonymous Web Client Tier – The final tier is much like the person who shows up off the street looking for a room, but does not have a reservation. The desk clerk must use some means of proving him trustworthy. The OPC UA application would ensure privacy and integrity by authenticating username/passwords after a secure connection is created. After proper authentication, each application would be issued a certificate with a Private key, but no advance trust relationship is required.
Thank You for Choosing OPC UA
The OPC UA specifications, profiles and certification process provide users with the comfort that OPC applications are being built on strong security foundations that incorporate the use of encryption for confidentiality and signatures for source authentication and integrity. This allows asset owners to secure OPC UA client/server communication using the protocol itself rather than add-on security. But just like hotels, not all applications will be created equal. Users who are serious about the security of their system communications will look to compliant, trusted OPC vendors who have made security a priority in their applications. Knowledgeable vendors can help users access their security needs and explain how concepts of certificate handling and key storage apply to the various security tiers. The nature of OPC UA specifications mean that layered products like Security Gateways can provide integrated security at the protocol level that augment OPC UA products of lower security implementations. The OPC UA specifications provide the building blocks for secure applications to be built.
Thank you for choosing OPC UA. Have a safe and pleasant stay.
Eric Murphy, BSc, PEng (Alberta), is a chemical engineer with a process control specialization and an OPC expert. Eric has been a part of the OPC community since its early beginnings in the mid-1990s. He is heavily involved with the OPC Foundation and is a member of the OPC Foundation Technical Advisory Council (TAC). Eric is also a co-editor for the OPC Unified Architecture (UA) specifications as well as the chair of the OPC Historical Data Access (HDA) working group. Visit Eric at his Blog, the OPC Exchange, to follow the latest trends and discussions about OPC technology, or click here for free downloads.
