DDSSEC11 — Denial of Service Attack to DDS Security Participants by Injecting Participant Discovery Unregister&Dispose

An attacker could do an easy Denial of Service attack by just injecting Participant Discovery Unregister&Dispose messages.

Current DDS Security spec does not consider any mechanism to prevent this.

Proposal

This proposal allows for checking the authenticity of unregister&dispose messages at the same time that provides a secure way for changing local participant properties after authentication. The proposal is based in adding a new inline qos "PARTICIPANT_SESSION_SIGNATURE" to the Participant Discovery messages from secure participants.

• The content of the inline qos will be:
  • Two fields for avoiding replay attacks:
    • A NONCE (c.nonce) set to a value generated upon local participant creation.
    • An epoch (c.epoch) incremented each time there is a change in the announced participant discovery information.
  • A signature generated using the private key of the participant. The signature is generated from the following input:
    • c.nonce
    • c.epoch
    • The info state for the sample.
    • (if the sample contains data) md5(c.pData)

Upon reception of a Participant Discovery Message, and only if the remote participant is authenticated with us, the local participant will check if the received message would trigger a change in the properties or liveliness state of the remote participant. If the received message would trigger a change, the local participant will verify the signature using the certificate of the remote participant. If the verification fails, the message will be ignored. If the verification succeeds, the message will be parsed. In order to make this verification possible, the auth.plugin will expose three new APIs:

• get_max_private_signature_size: get the max. size of a private signature.
• private_sign: signs a set of bytes using the local participant private key.
• verify_private_signature: verifies a set of bytes against a signature using the remote participant public certificate.

Note: An operation private_sign is a bit too powerful. Would allow the application to sign anything it wants so it is not good practice. The operation should control what kind of data is signed so arbitrary bytes cannot be signed.

Note that if the remote Participant is not authenticated, no additional checks are done and messages are just parsed as usual.

Add a DCPSParticipantsSecure buitin Topic

To address this issue the specification shall add a new builtin Topic to send the ParticipantBuiltinTopicData to authenticated applications. This shall be called the "DCPSParticipantsSecure" builtin Topic.

After they authenticate the DomainParticipants will ignore data on the (unsecure) "DCPSParticipants" builtin Topic and only process ParticipantBuiltinTopicData data on the "DCPSParticipantsSecure" builtin Topic.

This topic will be secured the same way as the other secure "discovery" topics.