19. Support for RTI Infrastructure Services
19.1. RTI Persistence Service
RTI Persistence Service is compatible with the RTI Security Plugins. To store persisted data protected, Persistence Service must use a configuration whose domain_participant_qos
includes security properties for:
Dynamically loading the security libraries (see Dynamic Linking), and
Using a Governance Document that sets
data_protection_kind
to a value other thanNONE
for the desired topics (see Governance Document).
Hint
To run Persistence Service with the Security Plugins, the %PATH%
or $LD_LIBRARY_PATH
environment variable must include RTI and OpenSSL DLLs or libraries.
When Persistence Service discovers a Topic, it creates a PRSTDataReader and a PRSTDataWriter. When security is enabled, these Endpoints will use Serialized Data Protection, at the level specified by the data_protection_kind
Governance Rule (see data_protection_kind (topic_rule)).
The PRSTDataReader receives data from the Connext Databus and verifies (and potentially decrypts) it. The PRSTDataWriter then applies Serialized Data Protection to the data with its own Sender Key before inserting it into the database. The stored encoded data includes the payload and the metadata necessary to verify (and potentially decrypt) it, such as the Crypto Header and Crypto Footer.
When Persistence Service reads the database’s data, the PRSTDataWriter does NOT verify the MAC stored with the data before sending it on the wire. It is up to the user DataReaders to verify the MAC. Consequently, if an attacker alters the database’s data, the PRSTDataWriter will resend the tampered data many times over the wire until the reliability protocol causes the data to be lost.
Persistence Service encrypts and stores the PRSTDataWriter’s Sender Key in the database row containing information about the writer. The encryption key is the output of a derivation function whose input is the dds.data_writer.history.key_material_key
property (see Table 19.1), and the cryptography plugin implementation determines both the key derivation function and the encryption algorithm. For details on the Security Plugins’ key derivation function and encryption algorithms, see Interactions with Persistence Service.
In the Security Plugins, the Key Derivation Function involves PBKDF2 (Password-Based Key Derivation Function) with SHA-512 (Secure Hash Algorithm with a 512-bit hash value) and a random salt, and the encryption algorithm involves AES-256-GCM. The Key Derivation Function derives both the key and the IV (Initialization Vector) used in the encryption. Persistence Service stores the random salt along with the PRSTDataWriter’s encrypted key.
When Persistence Service restarts, the new PRSTDataWriter uses the Sender Key from the previous PRSTDataWriter, which it securely exchanges with user DataReaders to allow them to decrypt the data correctly. For this reason, to read the data from the database, Persistence Service needs to load the same configuration it previously used to write data into the database. If Persistence Service restarts with a different configuration (for example, wrong value for dds.data_writer.history.key_material_key
), Persistence Service creation will fail.
Property Name |
Property Value Description |
---|---|
|
Required The basis of the cryptographic material used to derive the key to encrypt the PRSTDataWriter’s Key Material. This property may be specified in either the DomainParticipantQos or the DataWriterQos. Attempting to restore encrypted data using a nonexistent or incorrect
You may specify either the file name or the document contents:
The length of the String. When this key is provided as a String, it is recommended that you take the appropriate measures to protect any configuration XML file containing this key, or alternatively to securely retrieve and set up this property programmatically. Similarly, when this key is provided as a path to a file, it is recommended that you take the appropriate measures to protect the file containing the pre-shared key. Default: |
19.2. RTI Routing Service
RTI Routing Service is compatible with the RTI Security Plugins. When secure data reaches a Routing Service DataReader the RTI Security Plugins will decrypt the data into cleartext (non-secure), and the service will move it through the corresponding Route into the output, where it can be secured again if necessary. For further reference, see Routing Service User’s Manual - Support for RTI Security Plugins.
19.3. RTI Recording Service
RTI Recording Service is compatible with the RTI Security Plugins. When secure data reaches a Recording Service DataReader the RTI Security Plugins will decrypt the data into cleartext (non-secure) and store it into the configured storage. The sample is passed to the storage layer without any security or encryption. Custom storage implementations may encrypt the data again before storing it. For further reference, see Recording Service User’s Manual - Support for RTI Security Plugins in Recording Service.
RTI Replay Service is compatible with the RTI Security Plugins. When Replay is configured with security, the data will be read in cleartext format from storage and secured by the RTI Security Plugins once the output endpoint is reached. For further reference, see Recording Service User’s Manual - Support for RTI Security Plugins in Replay Service.
19.4. RTI Web Integration Service
RTI Web Integration Service is compatible with the RTI Security Plugins. When secure data reaches a Web Integration Service DataReader the RTI Security Plugins will decrypt the data into cleartext (non-secure), and the service will transform it into the web-enabled representation to be sent over the web protocol. For further reference, see Web Integration Service User’s Manual - Support for RTI Security Plugins.