Authentication and communication security in federated execution

[hokeun]

Motivation

The current implementation of federated execution lacks authentication and encryption mechanisms to prevent adversarial federates from joining the federation or sending malicious messages (e.g., bad tags or bad sensor readings) to RTI or other federates.

• Use case:
  • Simple threat model: an adversarial federate on the same network.
• Non-goal:
  • We're not targeting applications running on the cloud (e.g., containerized execution environment) where we can use existing security infrastructure.
  • Inventing our own protocol or crypto - we will use standard protocols and cryptos already available.

Goals

1. Authentication: To authenticate a federate properly when the federate joins a federation.
2. Communication security: To ensure confidentiality and integrity (+ message authenticity) of the network messages between RTI and federates as well as among federates.

Approach

Target property for configuring authentication

• We can use the target properties to configure authentication mechanism, which will include the necessary libraries (e.g., OpenSSL for C federates) and generate code for performing authentication.

target C {
    auth: Hmac
};

• To begin with, we can have following target property options:

  • No auth property: This is default, using hex string matching for authentication - current approach.
  • auth: Hmac: This option uses the Key-hashed MAC (HMAC) using the shared secret = federation ID = hex string. Instead of sending this federation ID in plain text, we will use this for a challenge-response using randomly generated nonce for each federate. We may need a longer string, though, for example, 32 bytes for SHA 256.

• In the future, we will be able to use full-fledged authentication, for example, using different keys for each federate or using public-key cryptography for authentication.

  • auth: SST: This option uses SST, an open-source toolkit providing authentication and authorization services for the IoT. An API in C lanagues is under development at @hokeun's research group.

Target property for configuring communication security for network messages

• Target properties can also be used to configure communication security

target C {
    communication-security: {
        key-distribution: FederationID,
        encryption: AES-128-CBC,
        message-authentication: HmacSHA256
    }
};

• Here are target property options to begin with

  • No communication-security property: By default, we do not provide any encryption or message authentication
  • key: FederationID: This option uses the federation ID as a shared secret (cryptographic key). The required length of the federation ID may differ depending on the encryption and message authentication algorithms to be used. For example, if we use AES-128 for encryption and SHA 256 for HMAC, we will need a federation ID of 16 + 32 = 48 bytes as AES-128 requires a 128-bit key and HMAC SHA 256 requires a 256-bit key.
  • encryption: AES-128-CBC: This property specifies the encryption algorithm to be used for confidentiality guarantees.
  • message-authentication: HmacSHA256: This property specifies the HMAC algorithm to be used for message authenticity & integrity guarantees.

• Once the SST's C API is ready in the future, we will be able to leverage that in LF federated execution for key distribution.

  • key-distribution: SST: This option configures the LF federation to use SST for key distribution.

• As future work, we can try to apply different encryption and message authentication algorithms for each federate in the same federation, to support a federation with federates running on heterogeneous platforms where some of platforms have limited resources or capabilities.

RTI Command-line Arguments

• Because RTI is compiled separately, RTI should be able to support authentication & security by default.

  • (If we really want to exclude security libraries such as OpeenSSL from RTI, we can use #ifdef to make the security optional. However, I think it should be rasonable to include OpenSSL in RTI by default.)

• Because RTI includes the authentication & security support by default, we will need additional command-line arguments for configuring authentication & security. Here are some examples where each option takes a string configuration (for example, --auth Hmac):

-a, --auth <string>

-s, --security <string>
-e, --encryption  <string>
-m, --message-authentication  <string>

Future Work

How can we handle a scenario where some federates join without a security mechanism while other federates have to use secure authentication? For example, some bare-iron federates like sensor nodes for which we can filter the bogus sensor nodes even if they join a federation without secure authentication, and other federates like controllers which require secure authentication in the same federation.

[hokeun]

During a discussion, @soyerefsane suggested having TLS as an option as well. So we will try to get to that as well.

[Jakio815]

This is worked on https://github.com/lf-lang/lingua-franca/tree/auth. I linked a branch on this issue.

My branch currently uses target C { auth: true } option to include OpenSSL libraries, and use HMAC authentications between the RTI and the federate. It randomly creates nonce and creates a HMAC tag, and they process a 3 step handshake starting from the RTI.

For test, First build the RTI.

// org.lflang\src\lib\c\reactor-c\core\federated\RTI\
mkdir build && cd build
cmake -DAUTH=ON ../
make
sudo make install

Next, I made a simple test .lf file for test.

./gradlew runlfc --args test/C/src/federated/SimpleFederatedAuth.lf
./test/C/bin/SimpleFederatedAuth 

RTI does not include OpenSSL libraries when -DAUTH=ON is not commanded. It is set OFF on default. runlfc command also does not include OpenSSL libraries if target C { auth: true } is not coded.

[hokeun]

Relevant branches that are currently being worked on to add HMAC-based simple authentication of federates:

Lingua-Franca: https://github.com/lf-lang/lingua-franca/tree/auth Reactor-c: https://github.com/lf-lang/reactor-c/tree/security