Ticket #545 (assigned)

Opened 9 years ago

Last modified 5 years ago

HMAC signing of nodewatcher data

Reported by: kostko Owned by:
Priority: major Milestone: Next milestone
Component: nodewatcher/agent Version:
Keywords: projectideas, biggerproject, gsoc Cc:
Related nodes: Realization state:
Blocking: Effort: normal
Blocked by: Security sensitive: no

Description (last modified by mitar) (diff)

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.

Change History

comment:1 Changed 9 years ago by 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).

Last edited 8 years ago by kostko (previous) (diff)

comment:2 Changed 9 years ago by kostko

True, we could use SCP for doing upgrades.

Last edited 8 years ago by kostko (previous) (diff)

comment:3 Changed 9 years ago by 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.

Last edited 8 years ago by kostko (previous) (diff)

comment:6 Changed 9 years ago by mitar

  • Description modified (diff)

comment:7 Changed 8 years ago by 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).

comment:8 Changed 8 years ago by kostko

  • Keywords projectideas, biggerproject, gsoc added
  • Security sensitive unset
  • Description modified (diff)
  • Summary changed from HMAC podpisovanje nodewatcher podatkov to HMAC signing of nodewatcher data

comment:9 Changed 8 years ago by mitar

  • Description modified (diff)

comment:10 Changed 8 years ago by 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.

comment:11 Changed 7 years ago by mitar

  • Effort changed from normal to low

comment:12 Changed 5 years ago by 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.

comment:13 Changed 5 years ago by kostko

  • Component changed from firmware to firmware/nodewatcher

comment:14 Changed 5 years ago by mitar

What library does uhttpd use?

comment:15 Changed 5 years ago by 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?

comment:16 Changed 5 years ago by 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.

comment:17 Changed 5 years ago by 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.

Last edited 5 years ago by kostko (previous) (diff)

comment:18 Changed 5 years ago by mitar

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

comment:19 Changed 5 years ago by 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.

Last edited 5 years ago by kostko (previous) (diff)

comment:20 Changed 5 years ago by mitar

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

comment:21 Changed 5 years ago by 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.

comment:22 Changed 5 years ago by 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.

comment:23 Changed 5 years ago by 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.)

comment:24 Changed 5 years ago by mitar

  • Description modified (diff)

comment:25 Changed 5 years ago by mitar

  • Status changed from new to assigned
  • Owner kostko deleted
  • Effort changed from low to normal
  • Milestone changed from 3.0b to Next milestone
Note: See TracTickets for help on using tickets.