mil_std_3071

Implementation of the MIL-STD-3071 standard for Tactical Microgrid architecture and communication.

@library("mil_std_3071", "0.0.0");

Quick Start

Initialization

var securityConfig = TMSConfigSecurity{
    identity_ca: "file://identity_ca_cert.pem",
    identity_certificate: "file://user_cert.pem",
    identity_crl: "file://crl.pem",
    private_key: "file://user_key.pem",
    password: "user_key_password",
    permissions_ca: "file://permissions_ca_cert.pem",
    governance: "file://security/domain_governance.smime",
    permissions: "file://security/participant_permissions.smime"
};
if (!TMS::initialize(TMSConfig{participantName:"mil_std_3071 user", security:securityConfig})) {
    println("Unable to initialize TMS");
}

Subscribing

fn onMessageReceived(topic: TMSTopic, message:TMSMessage) {
    println("received ${message} on topic ${topic}");
}

TMS::subscribe(TMSTopic::Heartbeat, onMessageReceived);

Publishing

TMS::publish(TMSTopic::Heartbeat, 
    TMSMessageHeartbeat{
        deviceId: "sample_device", 
        sequenceNumber: 1}, 
    "sample_device", 
    0, 
    true);

API Reference

lib/mil_std_3071.gcl contains the main entry point for DDS operations First call must be TMS::initialize. TMSConfig contains the following configuration parameters:

Then you can subscribe and publish to all required TMSTopic. When using DDS Secure, TMSConfigSecurity must be set in the call to TMS::initialize (cf Security below) tms_types.gcl contains all TMSTopic, TMSMessage and TMSType. Generated by resources/gen_tms_types_gcl.sh. tms_participants.gcl contains tools to manage topics and device roles.

Security

DDS Security is enabled if TMSConfig.security is not null. In this case, Authentication, Access control and Cryptography are activated on DDS level.

Authentication

All DDS participants must provide a X.509 v3 identity certificate and they all must share a common Certificate Authority. The following fields of TMSConfigSecurity are used for Authentication :

Access control

Domain and Topics access control are set using signed configuration files. The following fields of TMSConfigSecurity are used for Access control :

Sample governance document:

<?xml version="1.0" encoding="UTF-8"?>
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="https://www.omg.org/spec/DDS-SECURITY/20170901/omg_shared_ca_governance.xsd">
    <domain_access_rules>
        <domain_rule>
            <domains>
                <id>0</id>
            </domains>
            <allow_unauthenticated_participants>false</allow_unauthenticated_participants>
            <enable_join_access_control>true</enable_join_access_control>
            <discovery_protection_kind>ENCRYPT</discovery_protection_kind>
            <liveliness_protection_kind>ENCRYPT</liveliness_protection_kind>
            <rtps_protection_kind>ENCRYPT</rtps_protection_kind>
            <topic_access_rules>
                <topic_rule>
                    <topic_expression>*</topic_expression>
                    <enable_discovery_protection>true</enable_discovery_protection>
                    <enable_liveliness_protection>true</enable_liveliness_protection>
                    <enable_read_access_control>true</enable_read_access_control>
                    <enable_write_access_control>true</enable_write_access_control>
                    <metadata_protection_kind>ENCRYPT</metadata_protection_kind>
                    <data_protection_kind>ENCRYPT</data_protection_kind>
                </topic_rule>
            </topic_access_rules>
        </domain_rule>
    </domain_access_rules>
</dds>

Sample participant permissions document:

<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="https://www.omg.org/spec/DDS-Security/20170901/omg_shared_ca_permissions.xsd">
    <permissions>
        <grant name="ParticipantPermissions">
            <subject_name>C=LU, ST=LU, O=DataThings, CN=user, emailAddress=user@sample.com</subject_name>
            <validity>
                <not_before>2013-06-01T13:00:00</not_before>
                <not_after>2038-06-01T13:00:00</not_after>
            </validity>
            <allow_rule>
                <domains>
                    <id>0</id>
                </domains>
                <publish>
                    <topics>
                        <topic>*</topic>
                    </topics>
                </publish>
                <subscribe>
                    <topics>
                        <topic>*</topic>
                    </topics>
                </subscribe>
            </allow_rule>
            <default>DENY</default>
        </grant>
    </permissions>
</dds>

Remarks

• In case of “Participant is not allowed with its own permissions file” error message : make sure the subject_name in the grant in the permissions configuration file matches the Subject of the participant certificate. Beware: the syntax is not the same in both case. The Subject may be like “CN=participant/emailAddress=adress@xxx.com” while the subject_name is “CN=participant, emailAddress=address@xxx.com”. This error may also show up when a participant certificate or a signed configuration does not match the CA.
• RTI Connext DDS Framework allows an alternative Certification Authority which makes it possible to allow participants certificated from 2 different authorities. This is not possible with FastDDS which doesn’t have this option.

Reference documentation for DDS Security:

• https://www.omg.org/spec/DDS-SECURITY/1.1/PDF
• https://fast-dds.docs.eprosima.com/en/latest/fastdds/security/security.html
• https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_secure/users_manual/p2_core/elements_dds_secure_system.html