Comment from Nathan Boeger
Time: September 20, 2008, 9:46 pm

I agree on the relevance of using PKI from a security perspective. I’m not sure on how I feel about requiring that as the only connection method, especially since many systems will run on a closed network and never be connected to the Internet. I suppose your solution of the OPC foundation issuing signed certificates would work. This could also provide a productive layer of QA. But imagine if the OPC Foundation ceases to exist in 10 years. Ugh oh - big problems.

Another thing to consider is the enormous amount backward compatibility. Legacy systems will expect to connect to the OPC-UA server via an OPC-DA wrapper. While this app can certainly authenticate via a secure X.509 certificate exchange, think about the weak link. The legacy OPC client (probably 90% of cases for some time to come) will be communicating via DCOM calls that don’t even have so much as a password. Think about where the weak link really is and where it’s reasonable to stand on the usability versus security balance as we migrate into the future.

Comment from Ralph Langner
Time: September 21, 2008, 5:32 am

“So what is the problem with this? Well any new OPC UA client would not be able to immediately be able to connect to an OPC UA server.”

Here’s the problem. OPC UA users (who might never have heard about certificates) will run into problems when installing clients. The client won’t be able to access the server. The users will contact their vendors and complain that the software doesn’t work. Vendors will tell them how to disable security and everything works fine (?). Sooner or later vendors will disable security during installation in order to minimize customer complaints and help desk time. We have seen all this happen with DCOM based OPC.

I share Nathan’s concern about too much backward compatibility. UA appears to me like the old Windows versions where DOS still was running as the underlying OS. The main reason for OPC as of 1996 — supporting numerous peripherals with incompatible media — has vanished. When everything is connected to Ethernet, OPC is becoming the problem that it promised to solve.

Comment from Nathan Boeger
Time: September 23, 2008, 12:00 am

Ralph - great points. And the DCOM thing will likely haunt us for some time to come.

New clients will be able to access UA servers *provided that* they are distributed with a signed certificate from the certificate authority (CA), OPC foundation in this case. That works similarly to IE and other popular browsers shipping with trusted root certificates. The problem is that there is a dependence on a robust (and available) certificate authority, which works best on the Internet (often not available for SCADA systems). After dealing with this industry, I agree with you that end users will have ZERO TOLERANCE with connections failing due to certificate errors. Their priorities are too heavily shifted toward availability and not integrity. You’re right - vendors will be strong armed into bypassing the secure method.

I disagree with Ralph on the relevance of OPC. Even with everything migrating to Ethernet, there’s still good reason to have a common API for client applications to communicate with devices. In the absense of such standards vendors are free to strong arm their users into exclusively requiring their hardware/software.

Comment from Ronaldo Duarte
Time: September 24, 2008, 9:50 am

Ralph, I can’t agree with you on the “Windows/DOS analogy”. UA isn’t running on top of DCOM, and it’s a real possibility to build an UA product from scratch without DCOM dependencies. There are wrappers, which were a demand from users for a migration path, but providing a migration path does not mean that DCOM is to UA what DOS was to Windows 3.1.
To me, the main reason for OPC is providing a common API for client applications to work with several protocols several devices from several vendors. Moving everything to Ethernet is not a replacement for OPC.

Comment from Ralph Langner
Time: September 25, 2008, 10:45 am

Nathan, a common API makes less sense if you have to deal only with TCP/IP and a hand full of application level protocols. For example, if you write an email application, you could use MS MAPI, or you could directly interface SMTP and IMAP4, given that you are familiar with the socket API. With few protocols to support, a standard API with a very high complexity is a mixed blessing. And standard or not, vendors always have the possibility to force customers into their proprietary world. Possibility 1: For some funny reason, the OPC functionality only works with the vendor’s own client (or server, or both) software. Strange… but then, why not just use the “standard” product that really works. Possibility 2: The vendor raises strong concerns that if the customer choses to use third party OPC software, there will be no warranty. (Don Corleone used to call that “an offer they can’t refuse”.)

I believe that we would be much better off if only a tenth of the effort that went into OPC UA would have been dedicated to developing a modern protocol for interfacing peripherals, including features such as authentication, which is being discussed right around the corner — see IPsec blog post. For some reason beyond my knowledge, people seem to view protocols as rocket science. Therefore we are stuck with dinosaurs like Modbus/TCP, and have to deal with license issues for Ethernet/IP. No matter how good any API or middleware will be, we will continue to have security problems as long as communication with peripherals remains as it is. IF we get something better, however, technologies such as OPC might no longer be needed.

Ronaldo, I am aware that UA doesn’t run on top of DCOM. My impression is that backward compatibility had a huge influence on the design process of UA (for obvious reasons), and I predict that a significant portion of UA installations will have old-style DCOM-based software running behind the scenes. If this happens, it will hardly make us more secure.

Comment from Randy Armstrong
Time: September 30, 2008, 2:33 am

1) The need to review and accept new certificates places a user interface design requirement on all UA applications. Vendors that design a UI that works well for end-users will be rewarded. Those that don’t won’t be able to get IOP certification from the OPC Foundation.

The UA SDK already includes a primitive configuration tool that makes this process as easy as copying a file from one folder to another - I use it all the time during testing. On Vista, UAC prevents non-administrators from updating the trust lists even if they have access to the tool. I will post something more on this on the OPC Foundation blogs.

2) DCOM security concerns can be minimized if a UA server wraps DCOM servers on the same machine and external DCOM access is disabled for that machine. If a system is not able to do that they can still turn on DCOM security between the UA server and the DCOM server. Smart UA servers could even map UA user credentials onto Windows user names and impersonate that user before connecting to the DCOM server.