EPIC: Encrypted communications support

Story

{As a} federation administrator on shared infrastructure or in a shared federation, {I want} my federation communications to be encrypted, {So that I can} share data only with those federates that I have cleared to do so

Context

All communications within a Portico federation are currently carried out in an un-encrypted, open format. Any application that can gain access to the communications channels that are used can also gain access to the data that federates exchange.

For several reasons, within larger federations there may be a requirement to hide or restrict access to certain pieces of data based on the authentication and role of a federate. This also allows subsets of federations to participate in a larger activity while keeping the bulk of their communications private.

This epic focuses on the implementation of an encryption scheme within Portico, with two primary focuses:

Encrypt all data and control messages between the RTI and all federates using PKI
Include access tokens within encrypted messages to later support role-based authentication

Implementation

The implementation of encryption within Portico will see configurable support added through the RID file. When enabled, we will implement a handshake process with the RTI so that all communications are encrypted from the time that a federate joins a federation.

All control messages exchanged between a Federate and the rtiexec will be encrypted with PKI. During connection we will establish a handshake and key exchange to pass public keys back and forth.

As all data messages are inherently group-based (rather than limited to two parties). As such, PKI will not work and we need to make use of symmetric session keys. These will be randomly generated and established during federate join, with a key defined for each federate. Federates receiving data will need to request from the RTI access to the session key for the sending federate. Something they may or may not be granted.

To support this, a federate needs some basic information about a message that is un-encrypted, such as the handle of the originator. Further complicating encryption support is the work being completed as part of #218, which will see support for a routing component called the "Forwarder". To perform its work, the Forwarder must be able to inspect critical metadata about updates.

As such, the encryption will only apply to the payload of a message. Headers that include source and target federates, message type and any contains object/attribute/interaction/parameter handles will all be included in an un-encrypted header section. This will keep the data encrypted allowing for the Forwarder to access the necessary metadata to perform its function.

Task List

This work is broken down into four steps:

Step 1: (#241) Configuration and RID options, and infrastructure to pass messages through encrypter (dummy initially)
Step 2: (#242) Implement encryption handshake support for connect() and join()
Step 3: (#243) Implement encryption for all control messages in RTI<>Federate exchange
Step 4: (#244) Implement session-key encryption support for all group-based data messages

openlvc / portico