Attention

You are viewing an older version of the documentation. The latest version is v3.3.

OPC UA Key Generation

The following section is applicable to:

About OPC UA Client/Server Security

To establish a secure connection and encrypted communication OPC UA client/server uses mutual trust TLS authentication and encryption. Both the server needs a signed certificate that includes its public key. Likewise, the client needs to have signed certificate that includes its public key.

The client initiates a request to the server that they connect. The server responds with its certificate containing the public key. To continue, the client needs to have the server certificate in its trust list. On some systems, the client application will prompt the user to accept the certificate and add it to the trust list. For ECI, the plug-in will have the server certificate already copied into the file system. This requires that the server certificate be obtained and copied prior to starting the plug-in. It is done this way so that a device using the client plug-in can be pre-configured and not require user action. For ECI, the client plug-in will have a configuration parameter for the server endpoint and the location of the server certificate that is to be trusted.

If the client determines that the server is in its trust list, the client responds to the server with its certificate containing its public key. For ECI, the client plug-in will have a configuration parameter for the location of the client certificate and the client private key. The plug-in needs the client private key so it can decrypt messages that come from the server. Additionally, there is a parameter for the client application URI that was set when the certificate was created. The plug-in checks that the parameter and the certificate URI match.

Upon receiving the response, the server checks if the client is in its trust list or adds the certificate if it wants to trust. The server application defines how the client is added to the trust list. It may be pre-installed or prompt the user.

If the client trusts the server and the server trusts the client, a secure connection is established, and they communicate over an encrypted channel.

Creating Server Certificate and Private Key

For OPC UA, the certificate needs to have a URI, which is an X509 v3 extension. Create a file, server-certificate.conf with the following contents:

1. Modify as desired but keep note of the value for URI.1

   [req]
   distinguished_name = req_distinguished_name
   x509_extensions        = v3_req        # The extensions to add to the self signed cert
   prompt = no
   
   [req_distinguished_name]
   C = US
   ST = Arizona
   L = Chandler
   O = My Company
   OU = IOT
   CN = www.mycompany.com
   
   [v3_req]
   basicConstraints = CA:FALSE
   #keyUsage = nonRepudiation, digitalSignature, keyEncipherment
   #extendedKeyUsage = serverAuth
   
   
   subjectKeyIdentifier=hash
   authorityKeyIdentifier=keyid:always,issuer
   keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment, keyCertSign
   extendedKeyUsage = TLS Web Server Authentication, TLS Web Client Authentication
   subjectAltName = @alt_names
   
   [alt_names]
   DNS.1 = localhost
   IP.1 = 127.0.0.1
   URI.1=urn:open62541.server.application
   #URI.2=eci.iot.mycompany.com
   

   

2. Run this command that uses server-certificate.conf to create a self-signed certificate and a key

   $ openssl req -newkey rsa:2048 -x509 -sha256 -days 365 -nodes -out server-certificate.crt -keyout server-private-key.pem -config server-certificate.conf
   

   

   Two files will be created: server-certificate.crt and server-private-key.pem

   Attention

   Certificates for production use should adhere to a security policy, which specifies the maximum validity period and enforces the use of a certificate authority to verify the authenticity of the certificate. The certificate used in this example is intended for testing purposes only since it uses a validity period of 365 days and is self-signed (does not use a certificate authority).

3. View the certificate to see the contents

   $ openssl x509 -in server-certificate.crt -text -noout
   

   

4. Convert the certificate crt to der

   $ openssl x509 -outform der -in server-certificate.crt -out server-certificate.der
   

   

5. Convert the private key key to der

   $ openssl rsa -outform der -in server-private-key.pem -out server-private-key.der
   

   

6. The OPC UA server needs server-certificate.der and server-private-key.der when loading the configuration before starting the server.

Creating Client Certificate and Private Key

For OPC UA, the certificate needs to have a URI, which is an X509 v3 extension. Create a file, client-certificate.conf with the following contents:

1. Modify as desired but keep note of the value for URI.1

   [req]
   distinguished_name = req_distinguished_name
   x509_extensions        = v3_req        # The extensions to add to the self signed cert
   prompt = no
   
   [req_distinguished_name]
   C = US
   ST = Arizona
   L = Chandler
   O = My Company
   OU = IOT
   CN = www.mycompany.com
   
   [v3_req]
   basicConstraints = CA:FALSE
   #keyUsage = nonRepudiation, digitalSignature, keyEncipherment
   #extendedKeyUsage = serverAuth
   
   
   subjectKeyIdentifier=hash
   authorityKeyIdentifier=keyid:always,issuer
   keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment, keyCertSign
   extendedKeyUsage = TLS Web Server Authentication, TLS Web Client Authentication
   subjectAltName = @alt_names
   
   [alt_names]
   DNS.1 = localhost
   IP.1 = 127.0.0.1
   URI.1=urn:open62541.client1.application
   #URI.2=eci.iot.mycompany.com
   

   

2. Run this command that uses client-certificate.conf to create a self-signed certificate and a key

   $ openssl req -newkey rsa:2048 -x509 -sha256 -days 365 -nodes -out client-certificate.crt -keyout client-private-key.pem -config client-certificate.conf
   

   

   Two files will be created: client-certificate.crt and client-private-key.pem

   Attention

   Certificates for production use should adhere to a security policy, which specifies maximum validity period and enforces the use of a certificate authority to verify the authenticity of the certificate. The certificate used in this example is intended for testing purposes only since it uses a validity period of 365 days and is self-signed (does not use a certificate authority).

   Attention

   Always keep the private key client-private-key.pem secure. If an adversary were to obtain the private key, they would have the ability to connect a rogue client to the OPC UA server and monitor or modify data!

3. View the certificate to see the contents

   $ openssl x509 -in client-certificate.crt -text -noout
   

   

4. Convert the certificate crt to der

   $ openssl x509 -outform der -in client-certificate.crt -out client-certificate.der
   

   

5. Convert the private key key to der

   $ openssl rsa -outform der -in client-private-key.pem -out client-private-key.der
   

   

6. The OPC UA client of the protocol bridge needs client-certificate.der and client-private-key.der when loading the configuration before starting the protocol bridge.

Encrypting Private Key

There are two primary methods of achieving private key encryption:

Private Key Encryption via TEP

When using TEP (Intel® Trusted Edge Platform) as a secure key store, the OPC UA client private key needs to be encrypted using the AES key from the secure key store. A utility application is provided for encryption. The key must be encrypted using the utility application so that the decryption portion of the OPC UA plug-in can properly decrypt.

$ cd /opt/ec-protocol-bridge/plg-opcua-rt/examples/sign_and_encrypt/certificates
$ ./encrypt -s1 -p123456 -lopcua_key -fclient-private-key.der -oclient-private-key.enc

Private Key Encryption via Full Disk Encryption

Full disk encryption can provide the best protection against data loss if implemented correctly. For a complete guide on implementing full disk encryption, refer to section: Full Disk Encryption.