.. include:: ../../../03-exports/aliases.include .. include:: ../../../03-exports/aliases-api.include .. include:: ../../../03-exports/roles.include .. _auth-pki-dh: Authentication plugin: DDS:\Auth\:PKI-DH ---------------------------------------- This is the starting point for all the security mechanisms. The authentication plugin provides the mechanisms and operations required for |DomainParticipants| authentication at discovery. If the security module was activated at Fast DDS compilation, when a DomainParticipant is either locally created or discovered, it needs to be authenticated in order to be able to communicate in a DDS Domain. Therefore, when a DomainParticipant detects a remote DomainParticipant, both try to authenticate themselves using the activated authentication plugin. If the authentication process finishes successfully both DomainParticipant match and the discovery mechanism continues. On failure, the remote DomainParticipant is rejected. The authentication plugin implemented in Fast DDS is referred to as "DDS:\Auth\:PKI-DH", in compliance with the `DDS Security `_ specification. The DDS:\Auth\:PKI-DH plugin uses a trusted *Certificate Authority* (CA) and the ECDSA Digital Signature Algorithms to perform the mutual authentication. It also establishes a shared secret using either Elliptic Curve Diffie-Hellman (ECDH) or MODP-2048 Diffie-Hellman (DH) as Key Agreement protocol. This shared secret can be used by other security plugins as :ref:`crypto-aes-gcm-gmac`. The DDS:\Auth\:PKI-DH authentication plugin, can be activated setting the |DomainParticipantQos| |DomainParticipantQos::properties-api| ``dds.sec.auth.plugin`` with the value ``builtin.PKI-DH``. The following table outlines the properties used for the DDS:\Auth\:PKI-DH plugin configuration. .. list-table:: :header-rows: 1 :align: left * - Property name - Property value * - identity_ca - URI to the X.509 v3 certificate of the Identity CA in PEM format. |br| Supported URI schemes: file. |br| * - identity_certificate - URI to an X.509 v3 certificate signed by the Identity CA in PEM format |br| containing the signed public key for the Participant. |br| Supported URI schemes: file. * - identity_crl *(optional)* - URI to a X.509 Certificate Revocation List (CRL). |br| Supported URI schemes: file. * - private_key - URI to access the private Private Key for the Participant. |br| Supported URI schemes: file, :ref:`PKCS#11 `. * - password *(optional)* - A password used to decrypt the *private_key*. |br| If the *password* property is not present, then the value supplied in the |br| *private_key* property must contain the decrypted private key. |br| The *password* property is ignored if the *private_key* is given in PKCS#11 scheme. * - preferred_key_agreement *(optional)* - The preferred algorithm to use for generating the session's shared secret |br| at the end of the authentication phase. Supported values are: |br| a) ``DH``, ``DH+MODP-2048-256`` for Diffie-Hellman Ephemeral with 2048-bit MODP Group parameters. |br| b) ``ECDH``, ``ECDH+prime256v1-CEUM`` for Elliptic Curve Diffie-Hellman Ephemeral with the NIST P-256 curve. |br| c) ``AUTO`` for selecting the key agreement based on the signature algorithm in the Identity CA's certificate. |br| Will default to ``DH`` if the property is not present. * - transmit_algorithms_as_legacy *(optional)* - Whether to transmit algorithm identifiers in non-standard legacy format. |br| Will default to ``false`` if the property is not present. .. note:: All listed properties have "dds.sec.auth.builtin.PKI-DH." prefix. For example: ``dds.sec.auth.builtin.PKI-DH.identity_ca``. The following is an example of how to set the properties of DomainParticipantQoS for the DDS:\Auth\:PKI-DH plugin configuration. +----------------------------------------------------------------------------------------------------------------------+ | **C++** | +----------------------------------------------------------------------------------------------------------------------+ | .. literalinclude:: /../code/DDSCodeTester.cpp | | :language: c++ | | :start-after: // DDS_SECURITY_AUTH_PLUGIN | | :end-before: //!-- | | :dedent: 8 | +----------------------------------------------------------------------------------------------------------------------+ | **XML** | +----------------------------------------------------------------------------------------------------------------------+ | .. literalinclude:: /../code/XMLTester.xml | | :language: xml | | :start-after: DDS_SECURITY_AUTH_PLUGIN<--> | | :end-before: <--> | +----------------------------------------------------------------------------------------------------------------------+ .. _generate_x509: Generation of X.509 certificates ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ An X.509 digital certificate is a document that has been encrypted and/or digitally signed according to `RFC 5280 `_. The X.509 certificate refers to the Public Key Infrastructure (PKI) certificate of the `IETF `_ , and specifies the standard formats for public-key certificates and a certification route validation algorithm. A simple way to generate these certificates for a proprietary PKI structure is through the `OpenSSL `_ toolkit. This section explains how to build a certificate infrastructure from the trusted CA certificate to the end-entity certificate, i.e. the DomainParticipant. Generating the CA certificate for self-signing """""""""""""""""""""""""""""""""""""""""""""" First, since multiple certificates will need to be issued, one for each of the DomainParticipants, a dedicated CA is set up, and the CA's certificate is installed as the root key of all DomainParticipants. Thus, the DomainParticipants will accept all certificates issued by our own CA. To create a proprietary CA certificate, a configuration file must first be written with the CA information. An example of the CA configuration file is shown below. The OpenSSL commands shown in this example are compatible with both Linux and Windows Operating Systems (OS). However, all other commands are only compatible with Linux OS. .. code-block:: ini # File: maincaconf.cnf # OpenSSL example Certificate Authority configuration file #################################################################### [ ca ] default_ca = CA_default # The default ca section #################################################################### [ CA_default ] dir = . # Where everything is kept certs = $dir/certs # Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database = $dir/index.txt # database index file. unique_subject = no # Set to 'no' to allow creation of # several ctificates with same subject. new_certs_dir = $dir certificate = $dir/maincacert.pem # The CA certificate serial = $dir/serial # The current serial number crlnumber = $dir/crlnumber # the current crl number # must be commented out to leave a V1 CRL crl = $dir/crl.pem # The current CRL private_key = $dir/maincakey.pem # The private key RANDFILE = $dir/private/.rand # private random number file name_opt = ca_default # Subject Name options cert_opt = ca_default # Certificate field options default_days= 1825 # how long to certify for default_crl_days = 30 # how long before next CRL default_md = sha256 # which md to use. preserve = no # keep passed DN ordering policy = policy_match # For the CA policy [ policy_match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional # For the 'anything' policy # At this point in time, you must list all acceptable 'object' # types. [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] prompt = no #default_bits = 1024 #default_keyfile = privkey.pem distinguished_name= req_distinguished_name #attributes = req_attributes x509_extensions = root_ca_extensions # The extensions to add to the self signed cert string_mask = utf8only [ req_distinguished_name ] countryName = ES stateOrProvinceName = MA localityName = Tres Cantos 0.organizationName = eProsima commonName = eProsima Main Test CA emailAddress = mainca@eprosima.com [root_ca_extensions] basicConstraints = critical, CA:true .. note:: For a self-signed **root CA**, the X.509 extension ``basicConstraints = CA:true`` is **required**. Without it, stacks might not recognize the certificate as a CA. After writing the configuration file, next commands generate the certificate using the Elliptic Curve Digital Signature Algorithm (ECDSA). .. code-block:: bash openssl ecparam -name prime256v1 > ecdsaparam openssl req -nodes -x509 \ -days 3650 \ -newkey ec:ecdsaparam \ -keyout maincakey.pem \ -out maincacert.pem \ -config maincaconf.cnf Generating the DomainParticipant certificate """""""""""""""""""""""""""""""""""""""""""" As was done for the CA, a DomainParticipant certificate configuration file needs to be created first. .. code-block:: ini # File: partconf.cnf prompt = no string_mask = utf8only distinguished_name = req_distinguished_name [ req_distinguished_name ] countryName = ES stateOrProvinceName = MA localityName = Tres Cantos organizationName = eProsima emailAddress = example@eprosima.com commonName = DomainParticipantName After writing the DomainParticipant certificate configuration file, next commands generate the X.509 certificate, using ECDSA, for a DomainParticipant. .. code-block:: bash openssl ecparam -name prime256v1 > ecdsaparam openssl req -nodes -new \ -newkey ec:ecdsaparam \ -config partconf.cnf \ -keyout partkey.pem \ -out partreq.pem openssl ca -batch -create_serial \ -config maincaconf.cnf \ -days 3650 \ -in partreq.pem \ -out partcert.pem Generating the Certificate Revocation List (CRL) """""""""""""""""""""""""""""""""""""""""""""""" Finally, the CRL is created. This is a list of the X.509 certificates revoked by the certificate issuing CA before they reach their expiration date. Any certificate that is on this list will no longer be trusted. To create a CRL using OpenSSL just run the following commands. .. code-block:: bash echo -ne '00' > crlnumber openssl ca -gencrl \ -config maincaconf.cnf \ -cert maincacert.pem \ -keyfile maincakey.pem \ -out crl.pem As an example, below is shown how to add the X.509 certificate of a DomainParticipant to the CRL. .. code-block:: bash openssl ca \ -config maincaconf.cnf \ -cert maincacert.pem \ -keyfile maincakey.pem \ -revoke partcert.pem openssl ca -gencrl \ -config maincaconf.cnf \ -cert maincacert.pem \ -keyfile maincakey.pem \ -out crl.pem