HAL remote component protocol: firm up security aspects

[mhaberler]

The current HAL remote component protocol specification lacks a comprehensive security guideline beyond declaring this 'out of scope for now': https://github.com/mhaberler/asciidoc-sandbox/wiki/Remote-HAL-Components .

As the first implementation of HALrcomp is about to hit the repo, the 'Security Considerations' section needs firming up. Let's use this thread to come to a conclusion how to address this at the protocol/connection level (I assume standard firewalling techniques at the IP level are known and need not be discussed here).

I think we need to discuss several aspects:

• possible failure scenarios
• usage guidelines (like 'dont ever rely on remote estop')
• configurable usage restrictions
• goals and means at the protocol level, both covering authentication and encryption

Generally both protocol channels (status tracking and value updates) can actually be used independently and hence discussed here separately. So 'usage restrictions' could apply on either, both or none. Example restrictions which come to my mind are:

• 'no updates from unauthenticated clients'
• clients capable of sending updates are explicitly named/restricted
• the number of clients capable of sending updates can be restricted

My approach for the fourth item would be to study the curve encryption/authentication means in czmq/libsodium, and work out some viable examples (maybe even in Python) to act as blueprints. It would make sense to consider several scenarios, ranging from simple protection against accidential change - but cleartext transfers - to full PKI authentication and transfer encryptio.

Once these stand firm, let's backport those to C/C++.

References:

Using ZeroMQ Security: http://hintjens.com/blog:48
CurveZMQ - Security for zeroMQ: http://curvezmq.org/
Curve Python examples: https://github.com/zeromq/pyzmq/tree/master/examples/security

[luminize]

One thing that comes to mind is not only failure and ways to deal with that, but possibly exploit the remote hal functionality to add security by having redundancy (I'm not hindered by very specific knowledge or ways about how this is normally done :).

[luminize]

hmm, forgive me my rambling. Writing while thinking. Possibly (maybe) off topic. Very certain that the sentence does not cover the original thought :) .
I mean with this that as different machines can access the hal pins of their peers, (both ways), there is bound to come a machinekit type which does not drive axes, but issues bus commands to slaves. like some high level automation system. Then that master can be made redundant (security) by sharing pins like the remote ui's do. So when the master machinekit fails, the second in command takes over so ultimately the slaves can get commands.
btw, I've used sdedit in the past for sequence diagrams. Maybe a useful tool in communicating. I really liked your sequence diagram in the spec. Pictures say more than words.

[mhaberler]

John commented in #598 on this topic:

#204 neglects an important question: what is the infrastructure for
sharing the crypto data needed to establish trust? It's been a while
since I looked at CURVE, but talking in terms of other crypto systems,
there's a certificate authority pki like ssl, pubkeys like ssh, and
shared secrets like WPA personal, telnet, etc. IIRC CURVE supports at
least two of those.

this issue is really about role-based credentials - ideally we need to be able to distinguish server-side if a request comes from a client which may say change pins, or the client is just an observer. The way to do this is to figure how a ZAP handler can help here.

As for distribution of passwords (or curve keys which are technically passwords) I do not see any need to go beyond what is current practice - distribute the password over some secure channel like for instance a SSL-protected website. So suggestions to bring in PKI into the machinekit code base are out of scope IMO. Besides, PKI is hopelessly complex, and politically completely devalued given the events of the last few years.

IMO there's still a way to go before any kind of implementation can
start,..

I dont think that is the case - I think all we need somebody to dig into the workings of ZAP and come up with a way to distinguish clients at the request or socket levels.

If we ignore that distinction of clients for now - all clients treated equal with respect to injecting commands and changing values, we could use curve authentication and encryption right away. That is probably a good idea anyway as a stopgap measure.

[mhaberler]

this thread nicely summarizes the problem. It is actually unclear if a custom ZAP handler really helps.

One possible solution is to add an inband authentication token to the protobuf message proper, and derive that token from an originator's key. That should enable verification of origin on a per-message basis on the receiving side.

I'd see a few options:

• a particular key would be assoicated with a certain set of credentials when issued.
• different keys for read-only and read-write operations.

I guess it boils down to practicality. That is all we need AFAICT, since we can assume protobuf for granted. That would remove the need for having that credential feature at the zeromq/ZAP level.

There are related uses of this technique: WS-security and various schemes of adding signature tokens to XML. So nothing new.

[mhaberler]

there is a zeroMQ feature in the pipeline which will be very valuable to address the pub/sub side of the problem: selective subscription with token-based authentication

this will enable proper handling of group and rcomp status subscribers: the current subscribe function in libzmq gives no choice if a subscribe is actually honored or not (although an error message could be sent), meaning even on an authentication failure updates would be published to an unauthenticated subscriber

with this feature the subscription can be made to explicitly fail