HMAC signing of nodewatcher data

[kostko]

Currently all monitoring reports by nodes are unsigned and can be spoofed by anyone. This represents a security problem and a possible solution is that every node would be assigned its own nodewatcher signing key. The node would then sign the monitoring output using a hash function in HMAC mode. Every request from nodewatcher would also contain a random nonce that would be used in signature computation to prevent replay attacks.

Such HMAC-based signing should not be too expensive in terms of CPU usage as it is a simple SHA-256 computation that can be performed via the OpenSSL library.

Signature verification failure would then generate an event and a warning within the nodewatcher monitoring system.

Student should have experience or be willing to learn Python and Django, shell scripting and maybe C, and development of OpenWrt packages and integration. Understanding of basic cryptography is needed, too.

[mitar]

Another problem is that the firmware image is currently transferred over the network unencrypted when performing upgrades. This could expose the private signing key, so another way of doing upgrades should be found (like using SSH).

[kostko]

True, we could use SCP for doing upgrades.

[mitar]

Yes, we could store the node's public SSH key in the nodewatcher system, so all nodes could be authenticated. We must also take care of automatic firmware upgrades.

[kostko]

For a secure channel between nodes and the nodewatcher system see ticket #839. That ticket differs from this one in the way that it is used for data that needs to be private where this HMAC signing would still enable the data to be public (but verification would only be possible by the nodewatcher monitoring system - to enable everyone to verify such data, we would need to use public key cryptography and performance of such a solution would need to be evaluated).

[kostko]

Instead of OpenSSL we could also use a simpler C application to perform the hash computation as the OpenSSL library uses a lot of flash space.

[kostko]

Small crypto library called libcyassl could be used for HMAC computation as it requires 10x less flash space compared to libopenssl. It supports Base64 encoding/decoding and HMAC-SHA256 computation. We can create a small C utility that can sign arbitrary input passed via stdin where the signing key is passed in as an environmental variable.

The signing key should be configurable via UCI in /etc/config/nodewatcher like:

config signing
        option key 'UPAtINtTeRjdIEAzRsLojR5s/mqK+ePP'

Nonces would be specified via the request URL in the form of ?n=GGvSW3rNNnCLzdLW and would be included in the output as a special variable (as would the Base64 encoded signature and the algorithm used):

META.nonce: GGvSW3rNNnCLzdLW
META.signature.algo: HMAC-SHA256
META.signature.data: LCa0a2j/xo/5m0U8HTBBNBNCLXBkg7+g+YpeiGJm564=

The signature would always be present on the last line and would sign all lines before the last one.

[mitar]

What library does uhttpd use?

[mitar]

What we will use for padding? Be sure to clean nonce before just outputing it back. :-)

Should the singing key be directly specified in the configuration, or should there just be a filename with the key?

Dropbear uses libtom. We could try to make Dropbear use it as an external dependency and then we could use it as well?

[mitar]

It seems ​uhttpd can use different libraries.

So I see that we need crypto for:

• HTTPS client (optionally, we could use SSH SCP as well)
• SSH
• HMAC signing

It would be great if we would have only one crypto library installed. :-)

If we will have any services on nodes themselves (like #846) we might need HTTPS server as well.

[kostko]

What we will use for padding?

What padding? Cryptographic hash functions like SHA256 can already handle variable-length messages by using the ​Merkle-Damgård construction (actually I see that there are also some more attack resistant variants) which takes care of the padding in a secure way.

By default uhttpd does not provide SSL, but when enabled it can use libcyassl as well – which is really small, so no big dependencies.

Should the singing key be directly specified in the configuration, or should there just be a filename with the key?

Directly in UCI, as this then limits all node configuration strictly to /etc/config. This is how I would like it to stay – so no external file dependencies, everything configured via UCI.

[mitar]

SSH keys are not in UCI. Why we are not simply using them as a key?

[kostko]

​Actually, they are. (This is for authorized public keys, but you get the point.) Using UCI for everything is a very good thing as everything is configured in exactly the same way without needing to rely on any other files or other file formats – any external files are generated by packages from the UCI configuration. This is also the way we (and OpenWrt) configures olsrd for example, we don't generate olsrd.conf anymore.

Are you concerned that having key material in UCI configuration is somehow more vulnerable? Why would that be?

Can you elaborate on your idea – using SSH keys for signing nodewatcher data? Because the complete SSH handshake is very expensive and I don't want to use it for fetching nodewatcher data.

[mitar]

No, you just take content of private SSH key as key for HMAC. :-)

[mitar]

So the code you have is for adding to authorized keys. I am talking about private/public SSH keys. Those are currently not configured through UCI.

[kostko]

Hm, but nodewatcher does not generate the private SSH keypair for the node, so it can't know the symmetric key used for HMAC signing and so can't verify the signature? Are you saying that nodewatcher should generate the private SSH key for nodes? In this case, these keys must also be configured – and nodewatcher CGMs for OpenWrt platform should only output UCI configs.

[mitar]

We might want at some point that we can upgrade remotely the node, no? How we will know that we are connecting to the right node? OK. We could fetch public key over this HMAC channel we are doing now. Maybe this is better.

I do not like idea of having UCI for HMAC key or SSH keys. The reason is that if somebody installs web interface they might get exposed. I know it is easier to do everything through UCI, but those two things, in my opinion, should not be done through it. Does UCI support write-only fields through its interface? (And then cgi-bin script would read the value manually directly from the filesystem.)