DDSSEC11 — Inconsistent Behavior for Secure Volatile Endpoints

Description:

Secure Volatile Endpoint’s Endpoint Security Attributes are not defined by the spec. According to 9.5.2.1 DDS:Crypto:AES-GCM-GMAC CryptoToken, the encryption of the Secure Volatile Endpoint’s payload (the key material) is done by calling to encode_serialized_payload operation as part of “create_local_xxx_crypto_tokens(cryptoTokens /* out /)”. *This is inconsistent with the rest of endpoints, which will do encryption for the payload or submessages depending on the value of Endpoint Security Attributes.

Additionally, current content is inconsistent with 8.8.8.1 Key generation for the BuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader, which details the key material needed for securing the channel. This is inconsistent, because current specification is not securing the channel, is just sending encrypted crypto tokens that have been encrypted in create_local_xxx_crypto_tokens, and decrypting them during the set_remote_xxx_crypto_tokens.

Proposal (see DDSSEC11-28):

• Change Secure Volatile endpoint definition to follow same encryption process than the rest of endpoints, being the only difference that the key material used is derived from the SharedSecret (as defined in 8.8.8.1 Key generation for the BuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader):
  • Secure Volatile endpoints will be consistent with the rest of endpoints.
  • Logic for create_local_xxx_crypto_tokens and set_remote_xxx_crypto_tokens will be simplified.
• Also protect the submessage metadata. Currently the specification only protects the CryptoToken this makes it vulnerable to someone attacking a participant by sending wrong hearbeats or NACKs on the Volatile Endpoint since the HB and NACKS are only protected if metadata is protected. For this reason Secure Volatile endpoint definition should specify metadata_protection_kind=ENCRYPT and data_protection_kind=NONE that way we protect both meta data and data with a single operation which is more efficient.

Define Secure Volatile Endpoint Attributes and Simplify create_local_xxx_crypto_tokens and set_remote_xxx_crypto_tokens

General proposal:

• Define Secure Volatile endpoint attributes to follow same encryption process than the rest of endpoints, being the only difference that the key material used is derived from the SharedSecret (as defined in 8.8.8.1 Key generation for the BuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader):
  • Secure Volatile endpoints will be consistent with the rest of endpoints.
  • Logic for create_local_xxx_crypto_tokens and set_remote_xxx_crypto_tokens will be simplified.
• Also protect the submessage metadata. Currently the specification only protects the CryptoToken this makes it vulnerable to someone attacking a participant by sending wrong hearbeats or NACKs on the Volatile Endpoint since the HB and NACKS are only protected if metadata is protected. For this reason Secure Volatile endpoint definition should specify metadata_protection_kind=ENCRYPT and data_protection_kind=NONE that way we protect both meta data and data with a single operation which is more efficient.