RTI Secure Wan Transport  Version 6.1.0
Secure Transport

Modules

 Configure Secure Transport with Property QoS Policy
 Predefined strings that can be used to configure the Secure Transport plugin through the Property QoS Policy of the DomainParticipant.
 
 Secure Transport C API Reference
 Basic types and macros provided by RTI Connext for use in the Secure Transport plugin interface.
 
 Version
 Version utilities.
 

Detailed Description

Data security is provided by wrapping all DDS network traffic with the Datagram Transport Layer Security (DTLS) protocol (IETF RFC 4347). DTLS is a relatively recent variant of the mature SSL/TLS family of protocols which adds the capability to secure communication over a connectionless network-layer transport such as UDP. UDP is the preferred network layer transport for the DDS wire protocol RTPS, as well as for NAT traversal. Like SSL/TLS, the DTLS protocol provides capabilities for certificate-based authentication, data encryption, and message integrity. The protocol specifies a number of standard cryptographic algorithms that must be available; the base set is listed in the TLS 1.1 specification (IETF RFC 4346).

Secure protocol support is provided by the open source OpenSSL library, which has supported the DTLS protocol since the release of OpenSSL 0.9.8. Note however that many critical issues in DTLS were resolved by the OpenSSL 0.9.8f release. For more detailed information about available ciphers, certificate support, etc. please refer to the OpenSSL documentation.

The DTLS protocol securely authenticates with each individual peer; as such, multicast communication is not supported by the Secure Transport.

Security Model

In order to communicate securely, an instance of the secure plugin requires: 1) a certificate authority (shared with all peers), 2) an identifying certificate which has been signed by the authority, 3) the private key associated with the public key contained in the certificate.

The Certificate Authority (CA) is specified by using a PEM format file containing its public key (NDDS_Transport_TLS_Verification::ca_file) or by using a directory of PEM files following standard OpenSSL naming conventions (NDDS_Transport_TLS_Verification::ca_path). If a single CA file is used, it may contain multiple CA keys. In order to successfully communicate with a peer, the CA keys that are supplied must include the CA that has signed that peer's identifying certificate.

The identifying certificate is specified by using a PEM format file containing the chain of CAs used to authenticate the certificate. The identifying certificate must be signed by a CA. It will either be directly signed by a root CA (one of the CAs supplied above), by an authority whose certificate has been signed by the root CA, or by a longer chain of CA. The file must be sorted starting with the certificate to the highest level (root CA). If the certificate is directly signed by a root CA, then this file will only contain the root CA certificate followed by the identity certificate.

Finally, a private key is required. In order to avoid impersonation of an identity, this should be kept private. It can be stored in its own PEM file specified in one of the private key properties, or it can be appended to the certificate chain file.

One complication in the use of DTLS for communication by DDS is that even though DTLS is a connectionless protocol, it still has client/server semantics. The RTI Secure Transport maps a bidirectional communication channel between two peer applications into a pair of unidirectional encrypted channels. Both peers are playing the part of a client (when sending data) and a server (when receiving).

Certificate Support

Certificates can be generated using the supplied OpenSSL tool.

Initialize the Certificate Authority:

For each identifying certificate:

Parameters

To use the Secure Transport, the following parameters must be set:

These additional parameters may be needed: