respondd: sign responses

[lemoer]

In order to provide the ability authenticate data provided by respondd, this pr introduces ed25519 signatures into the responses.

secure_nodeid

This commit introduces the concept of a secure_nodeid:

• A secure_nodeid is technically an ed25519 public key.
• A node is uniquely identified by its secure_nodeid.
• Comparison to the established nodeid in gluon:
  • This new field is cryptographically secure and can not be "stolen" easily.
  • While the nodeid does not change, when users reflash their device, the secure_nodeid will be different.

All data returned by respondd is signed using that secure_nodeid.

Calculation of Signature

The signature is built in the following way:

• The json is encoded as string.
• A sha256 is calculated from that string.
• An ed25519 signature is calculated for the hash.
• A structure containing the public key (called "secure_node_id") and the signature is added into the json. (see example below)

Verification of Signature

To verify the signature, the following steps have to be done:

• Remove the auth, signature and secure_nodeid keys from the json.
• Encode it as a string without changing key order in the json.
• Calculate the sha256 of that string.
• Verify the signature of this hash using the public key (a.k.a. secure_node_id).

Policies for Data Collection Services

• Data collection services (like yanic) MUST verify respondd responses containing the "auth" json key.
  • If the signature is invalid, they have to drop those responses without using any data from those packets.
  • Response packets not containing the "auth" key, can be processed without checking any signature.
• The "secure_nodeid" MUST be forwarded to the nodes.json.
  • The public key can then be used by applications, which use the nodes.json if they would like to authenticate information.
  • Users/applications can rely on the fact, that if a node has a secure_nodeid in the nodes.json that the data has been validated using that secure_nodeid.
• Data collection services (like yanic) MUST NOT drop any packet, because a node has changed its secure_nodeid.
  • This way, the applications using the nodes.json can decide about their trust-on-first-use policy as they like.
  • Especially because the secure_nodeid changes its value if the user flashes its device without keeping the config, this policy makes sense.

Example Output

The json result looks like this:

router # gluon-neighbour-info -r statistics -c 1
{
   "auth": {
     "signature": "16f72b5186723549377abcb3427c39512786ba9cf7648aa9978791d24b82290bbe4b87061cdb3b9e7672e6052248f0c2fbf25b34b7bd296c7d963ca4fbf3f90e",
     "secure_nodeid": "278d4c96e8acb0234a82b6f77542302c2cfa58ef939b94137dc629d06e11a1a5"
   },
   "uptime": 7927.2799999999997,
   "traffic": {
     "tx": {
       "bytes": 271465,
       "dropped": 63,
       "packets": 1818
     },
     "rx": {
       "packets": 4124,
       "bytes": 517766
     },
     "forward": {
       "packets": 0,
       "bytes": 0
     },
     "mgmt_tx": {
       "packets": 50452,
       "bytes": 5632696
     },
     "mgmt_rx": {
       "packets": 36106,
       "bytes": 2995108
     }
   },
   "loadavg": 0
   ...
 }

[mkg20001]

@NeoRaider anything against merging this?

[neocturne]

I haven't looked at the implementation much, but I see a number of conceptual issues. My overall feeling is that this isn't a feature that I'd like to see in respondd.

• This introduces a dependency on UCI. We'd like to reduce the usage of UCI in Gluon.
• respondd is badly designed and should be replaced entirely rather than being extended.
• The size of a respondd reply should be kept as small as possible (I'd actually like to look into removing unnecessary information from Gluon's respondd providers at some point). I don't think the level of authentication added by these signatures justifies the additional data size.
• JSON isn't a good format for signing; if we decide that we do want to sign respondd replies after all, I'd like to see a binary format that signs the compressed reply as an opaque byte string.