Authentication

If security is enabled with jks authentication, creation of Participant loads a certificate from keystore to be used in authenticating with remote participants. During authentication, a shared secret is exchanged with the participants. This allows the two participants to exchange encrypted messages with each other. If the authentication fails for any reason, udds Participant will not exchange other than discovery data with failing participant.

DDS security relies on both authenticating parties having signed by the same certificate authority. DDS Security specification defines also some other security related operations, like protecting messages and permissions.

Here is an example how one can create a self signed certificate authority (jrtpsCA), and one test user (jrtps01), whose certificate is signed by CA.

# Create CA
keytool -alias jrtpsCA -dname CN=jrtpsCA -genkey -keyalg rsa -keystore jrtps.jks

# Create jrtps01
keytool -alias jrtps01 -dname CN=jrtps01 -genkey -keyalg rsa -keystore jrtps.jks

# Create certificate request
keytool -alias jrtps01 -certreq -keystore jrtps.jks > jrtps01.csr

# Sign CSR with CA
keytool -alias jrtpsCA -gencert -ext san=dns:jrtps01 -infile jrtps01.csr -keystore jrtps.jks > jrtps01.cert

# Import signed certificate back to keystore
keytool -importcert -alias jrtps01 -file jrtps01.cert -keystore jrtps.jks

See configuration section on how to enable authentication with keystore created above.

Protecting messages

Currently, uDDS CryptoPlugin is not compatible with the one specified in DDS security specification (1.0-Beta1). Main difference is that CryptoPlugin in specification uses a concept of cryptographic session, which is not implemented at this time. For this reason, transformationIDs used on wire are set to be different as specified in specification, even though transformation is the same. Future versions of udds will implement this feature, but we will wait for the final version of the specification.

Specification also allows protection to be applied at very fine level; At message level, at sub-message level, at data payload level. Each of these can be individually protected. uDDS implements only protection at message level. Currently, each of the builtin entities are marked as not being secure. User defined entities are marked as being secure, if rtps-protection is something other than none.

CryptoPlugin is used to encode/decode messages. uDDS CryptoPlugin delegates actual encoding or decoding to Transformers. Three predefined Transformers are available: MacTransformer, CipherTransformer and CompositeTransformer. MacTransformer uses javax.crypto.Mac to append a message authentication code (MAC) at the end of payload. Two MacTransformers are registered during startup: HmacSHA1, HmacSHA256. CipherTransformer uses javax.crypto.Cipher to encrypt/decrypt messages. During startup, a CipherTransformer with name AES is registered to CryptoPlugin. CompositeTransformer joins two Transformers together. Payload is encoded by encoding it with first Transformer, followed by encoding with second Transformer. Decoding is done in reverse order. The name of the CompositeTranformer is obtained by concatenating names of the contained Transformers. Two CompositeTranformers are registered on startup: AESHmacSHA1, AESHmacSHA256