Security feature between NetworkChannel and implementation

[hokeun]

TODO (@Jakio815)

[Jakio815]

We plan to add communication security between federates.

Secure Communication

We plan to encrypt messages after serializing the message using protobufs.

So, in the send() process, after wrapping up the message using protobufs, we will

1. Encrypt the message.
2. MAC the encrypted message.
3. Send the encrypted + HMAC.

In the receive() process,

1. Receive the encrypted + HMAC.
2. Verify the HMAC.
3. Decrypt the encrypted message.

and this will return the serialized protobuf.

Key management

Before the secure communication, we need to set up a secure connection, which is exchanging the keys to encrypt and decrypt messages.

This setting up secure connection includes

1. Initial key setup.
2. Authentication between two nodes.
3. Key exchange between nodes.

There are two ways to do this.

1. Assume that all nodes have already pre-shared keys (PSK).
   This may be possible if we compile the federated program in one machine, give a key to each federate in compile time, and copy the compiled program to other machines. However, I don't think we're planning to do this, also we want to support different types of CPUs. But we should keep in mind that this is used a lot in real life IoT devices, such as using QR codes as keys.

2. Use Public Key Infrastructure (PKI).
   Major operating systems come with the root Certificate Authority (CA). Each node can generate its own public/private key pair, get it signed by the CA, and exchange the certificate between nodes, authenticating each other. Now, the nodes can exchange keys using key exchange algorithms such as Diffie-Hellman (DH). This is a standard way; however, it may not be useful for devices with resource constraints. However, let's first start by using this standard.

Actual implementation for LF using SST

I am planning to use a toolkit named Secure Swarm Toolkit (SST). This framework helps handling all the setups I explained above, and also provides C API functions for the message encryption and decryption.

In SST, there is a local authentication and authorization entity, Auth. It provides authentication and authorization for its locally registered entities or devices.

For more details, if a federateA wants to communicate with federateB, federateA first requests a key from the Auth, securely gets a key from the Auth (by doing a handshake), federateA requests federateB for connection, federateB requests the same key from the Auth, and then federateA and federateB has a secure channel (by also doing a handshake).

However, this introduces a third-party entity, `Auth, ' and we need to discuss whether we want this.

Further discussion

We need to make sure what devices do we target. SST uses PKI in the initial phase, and PKI needs some relatively strong computation power. For example, temperature sensors, motions sensors, smart light bulbs are designed to operate on a small battery for months or years without consuming too much energy. It will be inappropriate to use PKI and RSA for these devices.

If we are targeting these devices, we would need further discussion.

[hokeun]

SST uses PKI in the initial phase

This is not always the case. SST provides a mode where we can only use symmetric keys from the initial phase. @Jakio815 please check the concept of "permanent distribution key" from the IoTDI'17 paper.

[hokeun]

What other alternatives exist?

SST supports a mode for devices that cannot afford asymmetric crypto used in PKI - e.g., RSA. So the use of PKI-like crypto is not required.

As long as the device can peform basic symmetric key crypto and H-MAC, for example, AES-128 and SHA256, we're good to go.

[Jakio815]

SST has options to use only symmetric keys, which does not require that much computational power.
If the devices can get set up before, we do not asymmetric crypto such as RSA. For example, when we are generating the code, we can put the keys into it.

However, does the code generator work to cross compile on different federates with different devices?

[virtualirfan]

Makes sense. In the real-world deployments, there is often a provisioning step in which a device accepts an owner. For example, in home networking. In such cases, an exchange of symmetric keys is doable and once done, the devices are effectively permanently paired up. In the home networking example, the unpairing then requires physical access to the device to reset it, etc.

[virtualirfan]

Suggest to add an [Edit] section under Further discussion in the OP explaining / accepting the clarifications.

[erlingrj]

Hi Dongha and Hoekun.

This seems like a very cool project. I want to mention two important details that might be important for you:

1. Federates can only talk to their neighbors
So far we have tried to avoid making any assumptions about the network fabric. This includes the ability to address federates that we do not have an LF connection to. If federates are always communicating over TCP, this is a silly limitation, but we are also thinking about serial connections and wireless. This means that e.g. the startup tag is distributed using "gossip" and we are also designing clock sync in a peer-to-peer fashion. It also means that we cannot have a single RTI that everyone talks to (currently we only do decentralized coordination).

This seems like a critical point if we are to use PKI.

2. NetworkChannels perform the serialization.
In the current API, the NetworkChannels handle unserialized data. To send data, you pass it a pointer to a FederateMessage struct which holds unserialized data. The NetworkChannel then performs serialization before outputting it on whatever network fabric it is using.

The security layer you are thinking about should likely exist between the runtime and the network channel. Thus I think we might want to rethink this and have the NetworkChannel send and receive arbitrary buffers, and perform serialization outside it. Any thoughts on this @tanneberger ?

[virtualirfan]

peer-to-peer fashion … only do decentralized coordination … This seems like a critical point if we are to use PKI.

See above for clarifications that PKI is not a hard requirement.

Also, note that if the gossip is p2p, there in no fundamental reason why other operations (e.g. initial device provisioning using PKI for symmetric key installation) can't happen over gossip as well. This needs to be considered as a pretty important operation.