In the past OPC specifications were silent on security and application developers were expected to use the operating system infrastructure to secure their applications. What this meant in practice is most OPC systems were insecure by default. The industry has moved on and such policies are no longer an option. For that reason, security in UA is mandatory and UA application developers have to write code that implements the UA security model.
That said, UA still leverages the operating system services as much as possible so implementing the UA security model in environments like WCF is largely a matter of specifying the correct security settings in code and/or the configuration file.
The UA security model has two key elements: application certificates and secure channels. Application certificates are used to identify specific instances of UA applications and are no different from the ubiquitous SSL certificates which are used to provide security for Internet commerce applications. The difference is the UA security model is not limited to SSL as an implementation technology so UA uses a more general term.
Secure channels are logical connections between applications that are used ensure that the messages exchanged cannot be intercepted or altered during transmission. HTTPS and WS-Secure Conversation are examples of technologies that can be used to implement a UA secure channel.
UA application certificates are X509 certificates which rely on a secret (called a private key) only known to the legitimate holder of the certificate. A UA application can prove it knows the secret by creating digital signatures which can be verified with the public key contained in the certificate. These certificates can be issued by anyone but UA applications use the issuer to determine whether a certificate can be trusted. UA applications must never communicate with an application that they do not trust.
What this all means is a developer must always start by creating a certificate for their UA applications. This can be done by making calls to the appropriate Windows APIs or by using an existing tool such as "makecert" which is distributed with Visual Studio.
The following command will create a self-signed certificate with makecert:
makecert -n "CN=MyApp, DC=MyMachine, O=MyCompany" -a sha1 -sky exchange -m 120 -r -ss My
The -n option specifies the SubjectName for the certificate which is a sequence of name/value pairs separated by commas (note: order is significant). The -ss option specifies where the certificate should be placed. In this example it is placed the "Personal" store for the current user. The -sr LocalMachine option can be used to place the certificate in the machine wide store.
A self-signed certificate is a certificate where the information contained within the certificate has not been verified by any third party. For that reason, self-signed certificates are not trusted by default, however, administrators can verify the information and configure applications to trust individual certificates. Applications must automatically create a self-signed certificate for themselves when they are installed on a machine.
The following code can be used to load the certificate from the certificate store:
X509Certificate2 certificate = null;
// look for the the private key in the personal store.
X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadWrite);
try
{
X509Certificate2Collection hits = store.Certificates.Find(
X509FindType.FindBySubjectName,
"MyApp",
false);
if (hits.Count == 0)
{
return null;
}
certificate = hits[0];
}
finally
{
store.Close();
}
Note that the SubjectName is not guaranteed to be unique and the code simply takes the first one found. Applications should use the Thumbprint property of the certificate if they need to distinguish between certificates with the same SubjectName.
Windows provides an MMC plug-in which can be used to manage certificates in the certificate stores. This plug-in can be accessed as follows:
1) Run mmc.exe
2) Click Files | Add/Remove Snap In
3) Click Add...
4) Select Certificates and click Add
5) Select Computer account and click Next.
6) Select Local computer and click Next
7) Click Close
8) Click OK
Although dealing with certificates does appear to be more work at first it really is no worse than DCOM where security was controlled by the Windows user account instead of the application certificate. The main difference is the UA security model is cross platform and independent of the communication technology .