system:inmation consists of several distinct components (Core, Connector, DataStudio etc.) that use different techniques and security mechanisms to communicate with one another.
For a full picture regarding the secure communication between components it is necessary to not only look at the internal component’s data flow, but also at the interfaces to 3rd party data sources and 3rd party data consumers.
Figure 81:Overview of inmation Component Secure Communication Types
Because of the different (partly 3rd party) components involved, system:inmation uses four different types of internal communication:
- inmation Intercomponent Communication Backend communication between inmation Service processes that spin off of inmation.exe or inmation32.exe
- MongoDB Communication Bidirectional data communication of inmation Core and one or more MongoDB instances
- SDK Communication Simplified communication protocol for applications based on the inmation SDK
- DataStudio Communication Custom internal communication specialized for thick client needs
In addition, system:inmation communicates with data sources and data sinks using various well defined interfaces (for example, OPC) as well as allowing for custom connections using the embedded scripting technology (Lua).
|Mode||Authentication||Data Privacy||Data Integrity||Overall Strength|
|TLS-SRP||SRP||TLS (AES-256)||TLS (SHA-1)||Strong|
|TLS-SRP||Supported||Not Supported||Not Applicable||Not Supported||Not Supported|
|None||Supported||Not Applicable||Not Applicable||Not Applicable||Not Applicable|
|Passphrase||Not Applicable||Not Applicable||Not Applicable||Not Applicable||Not Applicable|
|TLS-SRP||Supported||Not Applicable||Not Applicable||Not Applicable||Not Applicable|
system:inmation connects with a MongoDB instance using a configurable authentication mechanism. The currently supported authentication types are:
- No authentication: No client authentication takes place.
- MongoDB Challenge and Response (MONGODB-CR): Verifies supplied user credentials against the user’s name, password and authentication database. In MongoDB version 3.0 and higher, this mode is no longer the default and SCRAH-SHA-1 should be used instead.
- SCRAM-SHA-1: This mode is an IETF standard, RFC 5802, that defines best practice methods for implementation of challenge-response mechanisms for authenticating users with passwords. SCRAM-SHA-1 verifies the supplied user credentials against the user’s name, password and authentication database. This is the default mode since MongoDB 3.0.
The core service does not yet provide a way to configure transport encryption, therefore the network connection between the core service and the MongoDB instance must be fully trusted.
The system:inmation SDK supports a username and password authorization mechanism. Each individual call carries credentials which are verified against the core security model. An authentication and transport encryption configuration is currently unavailable.
The inmation WebAPI component uses the inmation SDK and its authorization mechanism (based on user credentials) to communicate with the Core service. Clients of the WebAPI service are not authenticated or authorized separately. Client connections are unencrypted currently.
DataStudio uses credentials to authorize a user against the core security model. Transport encryption is currently unavailable.
system:inmation provides both an OPC Classic client to connect to external data sources, and an OPC Classic server to expose its data model via an OPC Classic interface to external clients.
In a distributed setting based on DCOM, the standard DCOM security model applies which is not specific to system:inmation. The system:inmation OPC Classic server does not implement the OPC security interfaces.
The communication between the system:inmation Core service and the Server service components is authorized using a passphrase and client credentials. An authentication and transport encryption configuration is currently unavailable.
The system:inmation OPC UA client and server support different communication security policies, user token policies, and application authentication methods as specified in the OPC UA standard.
The supported security policies are:
- Sign and Encrypt
These come with different supported key lengths and cryptographic algorithms.
A security policy different from *None* ensures data integrity and privacy based on strong cryptographic algorithms.
Configurable user token policies are:
- User Name
The *User Name* policy in the system:inmation UA server is used to authorize UA clients against the Core security model.
As in the OPC Classic case, communication between the system:inmation Core service and the Server service components is authorized using a passphrase and client credentials. An authentication and transport encryption configuration between the two service components is currently unavailable.
It is also possible to act as your own Certificate Authority and create a root certificate which can be used to sign UA application instance certificates. This section will focus on UA client certificate creation and how such a custom certificate can be used with an inmation UA datasource (the UA client).
opensslcommand line utility which can be built manually from source code or downloaded as a binary.
First, a local directoy structure is set-up to manage key pairs, certificate signing requests, signed certificates, etc. The instructions will be brief and mostly for reference, see the Appendix for links to more detailed instructions.
Note: command lines presented below may contain path specifications which may have to be adapted to your command shell conventions.
First, create the directory structure:
> d: > mkdir root_ca > cd root_ca > mkdir certs crl csr newcerts private > echo 1000 > serial
If you have the
touch command available, create an empty
index.txt file, otherwise create an empty file with e.g. the Windows File Explorer.
> touch index.txt
The OpenSSL configuration file will be used later to create and sign certificates using the correct X.509 extensions as required by the OPC UA specifications.
Copy the example OpenSSL configuration file here to root_ca/openssl.cnf and change the marked lines.
The OPC UA application URI is a globally unique identifier for the instance of the Application. The
application URI as configured in the UA client or server must match the URL option in the
certificates subjectAltName extension (some clients or servers may allow this validation check to be
disabled via configuration options).
The application URI as used by the inmation UA datasource (client) is constructed using the following scheme:
urn:<domain names>:<organization name>:<application name>
where the domain names, organization name, and application name are fetched from the Own Certificate Details properties of the Connector object the datasource belongs to. For example:
Figure 82:Connector Own Certificate Settings
This is a read-only property and defaults to __system:inmation__.
This should be the name of the organization running the inmation UA datasource. Can be empty.
A list of domain names. If empty, a reverse domain name look-up is attempted using the `127.0.0.1` IP address. If the look-up fails, the computer host name is used. If the list is not empty, all entries are used in the application URI.
It is recommended to add a single domain name entry in the __Domain Names__ property to avoid possibly different results of the reverse domain name look-up.
With the property values as shown in the screenshot above, the OPC UA application URI used by the UA datasource is
and the same value needs to be put into the `openssl.conf` file.
First create a root key `inmation_test_ca.key.pem` with a AES 256-bit encryption and a strong password:
> openssl genrsa -aes256 -out private/ca.key.pem 4096 Enter pass phrase for ca.key.pem: secretpassword Verifying - Enter pass phrase for ca.key.pem: secretpassword
Next create a root certificate `inmation_test_ca.cert.der` using the root key:
> cd /root/ca > openssl req -config openssl.cnf -key private/inmation_test_ca.key.pem -new -x509 -days 7300 -sha256 -extensions v3_ca -outform der -out certs/inmation_test_ca.cert.der Enter pass phrase for ca.key.pem: secretpassword You are about to be asked to enter information that will be incorporated into your certificate request. Country Name (2 letter code) [DE]: State or Province Name : Locality Name : Organization Name :MYCOMPANY Organizational Unit Name :MYCOMPANY Certificate Authority Common Name :MYCOMPANY Root CA Email Address :
Verify the root certificate using the following command:
> openssl x509 -noout -text -inform der -in certs/inmation_test_ca.cert.der
We will be signing UA client certificates with the previously created root certificate. Note that in production environments, creating an intermediate CA for signing UA certificates might be preferable due to security considerations. See here for more details.
Create a private key `inmation_ua_client.key.pem` for the UA client certificate:
> openssl genrsa -out private/inmation_ua_client.key.pem 2048
Next, create a certificate signing request (CSR). The __Organization Name__ in the CSR should be the name of the company running the inmation connector service with the UA datasource. the __Common Name__ should be the product name `system:inmaton`:
> openssl req -config openssl.cnf -key private/inmation_ua_client.key.pem -new -sha256 -out csr/inmation_ua_client.csr.pem Enter pass phrase for inmation_ua_client.key.pem: secretpassword You are about to be asked to enter information that will be incorporated into your certificate request. Country Name (2 letter code) [DE]: State or Province Name : Locality Name : Organization Name :MYCOMPANY Organizational Unit Name : Common Name :system:inmation Email Address :
The root certificate is now used to sign UA client certificate, using the `ua_app_inst_client_cert` extension as configured in the `openssl.cnf` configuration file:
> openssl ca -config openssl.cnf -extensions ua_app_inst_client_cert -days 375 -notext -md sha256 -in csr/inmation_ua_client.csr.pem -outform der -out certs/inmation_ua_client.cert.der
Verify the UA client certificate using the following command:
> openssl x509 -noout -text -inform der -in certs/inmation_ua_client.cert.der
and check the right __Issuer__ and __X509v3 extensions__.
The UA client certificate needs to be deployed to the machine running the inmation connector service and the root certificate needs to be known to the UA server if automatic client certificate validation should take place.
As of today, a UA datasource cannot be configured with an external client certificate via DataStudio or some API calls. Instead, the certificate and the private key need to be copied manually to the host machine running the connector service.
First, make sure that the connector is configured to not create its own certificate by disabling the __Create Certificate__ property:
Figure 83:Connector Certificate Settings - Disable Create Certificate Setting
Then copy the DER encoded UA client certificate to the `inmation.root/certificates/public` folder and ensure that its name starts with `"[conn] "` (without quotation marks, but including the white space after the closing square bracket).
The private key is required to be stored in `PFX` format, so you need to convert the DER encoded certificate to PEM and then export the PEM encoded key file and certificate to a PFX file:
> openssl x509 -inform der -in certs/inmation_ua_client.cert.der -out certs/inmation_ua_client.cert.pem > openssl pkcs12 -inkey private/inmation_ua_client.key.pem -in certs/inmation_ua_client.cert.pem -export -out private/inmation_ua_client.key.pfx
Now copy the PFX key file to the `inmation.root/certificates/private` folder and also prefix it with `"[conn] "`. The final directory layout should look like this (there may exist additional folder and files, but only a single `"[conn] "` prefixed file should exist in each sub-folder):
certificates |- private | `- [conn] inmation_ua_client.key.pfx `- public `- [conn] inmation_ua_client.cert.der
If the UA server should be able to automatically validate the UA client certificate, the root certificate needs to be installed in its certificate store. How this is done depends on the actual type of certificate store used by the UA server. A local directory store typically has a `certs` sub-folder where trusted certificates can be copied to. If the Windows certificate store is used, the root certificate can be installed by double-clicking on it.
Using Lua script a variety of connection types can be established to data sources and sinks. This basically depends on the included Lua script libraries. The Core service provides the LuaSec library to enable secure socket communication.
Not currently available. Planned for release in 2018.
During service installation, the connection mode, default security mode, and default security passphrase can be specified using the following command line options:
|--connect||n/a||0 (passive)||1 (active)||0 (passive)|
|--passphrase-clear||<empty> (default passphrase)||<empty> (default passphrase)||<empty>||<empty>|
See Changing the Security Configuration section to learn how to change the configuration later. Also note that the `passphrase-clear` option denotes a passphrase used by either the TLS-SRP or the Passphrase security mode, depending on which mode is selected (explicitly or by default).Using the `--connect` option typically requires the usage of the `--corehost` and / or`--coreport` options as well, such that the connector knows the address of the hostrunning the inmation Core service.
Use the command:
for a list of supported command line options.
D:\inmation.root\bin\inmation.exe -i OPC.COM --passphrase-clear "my passphrase"
Multiple security modes are currently only supported by the Connector component. Changing the configuration has different effects depending on the current state of the connection between the involved inmation components.
If a connection is successfully established, a security mode change is communicated to the remote component which then disconnects and re-configures itself. In case of a passive remote component, the Core will re-connect using the new security mode. An active remote component will try to establish a new connection to the Core service after it re-configured itself.
A passphrase change is communicated to the remote component only if the security mode did not change at the same time. In this case, the remote component stores the new passphrase and disconnects the current connection.
- Unreachable network address (link down, host down, firewall issues, etc.)
- Name resolution errors
- inmation Service not running
- Mismatched security modes
- Wrong passphrase
- From the machine running the Core service, try to ping the host running a passive inmation component
- For active components, try to ping the host running the inmation Core service from the machine running the component service
- Make sure that the Communication properties of the remote component object match its current security configuration (security mode and passphrase)
An example of an OpenSSL configuration file with v3 extension settings suitable for OPC UA client and server certificate creation. The section names and default values should be renamed accordingly.
# OpenSSL root CA configuration file. # Copy to `/root/ca/openssl.cnf`. [ ca ] # `man ca` default_ca = CA_inmation_test // <1> [ CA_inmation_test ] // <1> # Directory and file locations. dir = d:/root_ca // <1> certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/newcerts database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/private/.rand # The root key and root certificate. private_key = $dir/private/inmation_test_ca.key.pem // <1> certificate = $dir/certs/inmation_test_ca.cert.pem // <1> # For certificate revocation lists. crlnumber = $dir/crlnumber crl = $dir/crl/ca.crl.pem crl_extensions = crl_ext default_crl_days = 30 # SHA-1 is deprecated, so use SHA-2 instead. default_md = sha256 name_opt = ca_default cert_opt = ca_default default_days = 375 preserve = no # use policy_strict in real world use cases, with an intermediate CA policy = policy_loose // <1> [ policy_strict ] # The root CA should only sign intermediate certificates that match. # See the POLICY FORMAT section of `man ca`. countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ policy_loose ] # Allow the intermediate CA to sign a more diverse range of certificates. # See the POLICY FORMAT section of the `ca` man page. countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] # Options for the `req` tool (`man req`). default_bits = 2048 distinguished_name = req_distinguished_name string_mask = utf8only # SHA-1 is deprecated, so use SHA-2 instead. default_md = sha256 # Extension to add when the -x509 option is used. x509_extensions = v3_ca [ req_distinguished_name ] # See <https://en.wikipedia.org/wiki/Certificate_signing_request>. countryName = Country Name (2 letter code) stateOrProvinceName = State or Province Name localityName = Locality Name 0.organizationName = Organization Name organizationalUnitName = Organizational Unit Name commonName = Common Name emailAddress = Email Address
# Optionally, specify some defaults. // <1> countryName_default = DE stateOrProvinceName_default = localityName_default = 0.organizationName_default = inmation Software GmbH organizationalUnitName_default = emailAddress_default = [ v3_ca ] # Extensions for a typical CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign [ v3_intermediate_ca ] # Extensions for a typical intermediate CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign [ ua_app_inst_client_cert ] # Extensions for UA client certificates (`man x509v3_config`). basicConstraints = CA:FALSE nsCertType = client nsComment = "OpenSSL Generated Client Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = clientAuth subjectAltName = URI:urn:MYHOST:MYCOMPANY:system:inmation // <2> [ ua_app_inst_server_cert ] # Extensions for server certificates (`man x509v3_config`). basicConstraints = CA:FALSE nsCertType = server nsComment = "OpenSSL Generated Server Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth subjectAltName = URI:urn:uuid:<component-guid> // <2> [ crl_ext ] # Extension for CRLs (`man x509v3_config`). authorityKeyIdentifier=keyid:always [ ocsp ] # Extension for OCSP signing certificates (`man ocsp`). basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, digitalSignature extendedKeyUsage = critical, OCSPSigning
<1> Change for your own CA
<2>See the The UA application URI for more details