Add command signature to prevent agent retargeting

[jvehent]

The action signature scheme MIG uses protects the most important fields of the Action JSON file. Agents verify those fields to make sure that a trusted investigator has issued the action.

In particular, the signature covers the action.target fields that contains the target string used to sent the action to selected agents. The target fields is expanded into a list of agents by the scheduler, then each agent receives a Command JSON file which includes the signed action and some other fields.

The signature does not cover the command JSON file because commands are created later in the process and agent-specific.

Moreover, agents themselves do not verify that action.target and cannot verify that an action was truly targeted at them or not. That decision is made by the scheduler.

Put together, these two issue allow for an attacker to take a signed action and craft a command file targeted at an agent that was not originally meant to be.

This is currently mitigated using RabbitMQ's access controls which:

• authenticate the scheduler with a username and password
• implement ACLs to limit publication to agents queues to an authentication scheduler user

But rabbitmq is fragile and directly exposed to the internet. We should provide an additional layer of security to prevent a rabbitmq compromise from putting agents at risk.

The proposed solution is to add a second signature, this time on the Command envelope, that contains:

• Command ID
• Agent ID and Queueloc
• Action ID and Signature
  The fields above would be signed by the scheduler itself using its own scheduler key.

Upon reception of a command, an agent:

1. verifies the command signature using the scheduler's public key
2. verifies that the agent.queueloc field of the command equals its own queueloc field (ensure that command it targeted to itself)
3. verifies the action signature and ACLs

This protocol would prevent a command reuse and add an extra layer of security behind RabbitMQ's ACLs.