{"action":"created","issue":{"url":"https://api.github.com/repos/machinekit/machinekit/issues/204","labels_url":"https://api.github.com/repos/machinekit/machinekit/issues/204/labels{/name}","comments_url":"https://api.github.com/repos/machinekit/machinekit/issues/204/comments","events_url":"https://api.github.com/repos/machinekit/machinekit/issues/204/events","html_url":"https://github.com/machinekit/machinekit/issues/204","id":34547498,"number":204,"title":"HAL remote component protocol: firm up security aspects","user":{"login":"mhaberler","id":901479,"avatar_url":"https://avatars.githubusercontent.com/u/901479?v=3","gravatar_id":"","url":"https://api.github.com/users/mhaberler","html_url":"https://github.com/mhaberler","followers_url":"https://api.github.com/users/mhaberler/followers","following_url":"https://api.github.com/users/mhaberler/following{/other_user}","gists_url":"https://api.github.com/users/mhaberler/gists{/gist_id}","starred_url":"https://api.github.com/users/mhaberler/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mhaberler/subscriptions","organizations_url":"https://api.github.com/users/mhaberler/orgs","repos_url":"https://api.github.com/users/mhaberler/repos","events_url":"https://api.github.com/users/mhaberler/events{/privacy}","received_events_url":"https://api.github.com/users/mhaberler/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/machinekit/machinekit/labels/problem","name":"problem","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2014-05-29T11:29:58Z","updated_at":"2015-04-30T07:26:28Z","closed_at":null,"body":"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 .\r\n\r\nAs 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).\r\n\r\nI think we need to discuss several aspects:\r\n\r\n- possible failure scenarios\r\n- usage guidelines (like 'dont ever rely on remote estop')\r\n- configurable usage restrictions\r\n- goals and means at the protocol level, both covering authentication and encryption\r\n\r\nGenerally  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:\r\n\r\n- 'no updates from unauthenticated clients'\r\n- clients capable of sending updates are explicitly named/restricted\r\n- the number of clients capable of sending updates can be restricted\r\n\r\nMy 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.\r\n\r\nOnce these stand firm, let's backport those to C/C++.\r\n\r\nReferences:\r\n\r\nUsing ZeroMQ Security: http://hintjens.com/blog:48\r\nCurveZMQ - Security for zeroMQ:  http://curvezmq.org/\r\nCurve Python examples: https://github.com/zeromq/pyzmq/tree/master/examples/security\r\n"},"comment":{"url":"https://api.github.com/repos/machinekit/machinekit/issues/comments/97692677","html_url":"https://github.com/machinekit/machinekit/issues/204#issuecomment-97692677","issue_url":"https://api.github.com/repos/machinekit/machinekit/issues/204","id":97692677,"user":{"login":"mhaberler","id":901479,"avatar_url":"https://avatars.githubusercontent.com/u/901479?v=3","gravatar_id":"","url":"https://api.github.com/users/mhaberler","html_url":"https://github.com/mhaberler","followers_url":"https://api.github.com/users/mhaberler/followers","following_url":"https://api.github.com/users/mhaberler/following{/other_user}","gists_url":"https://api.github.com/users/mhaberler/gists{/gist_id}","starred_url":"https://api.github.com/users/mhaberler/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mhaberler/subscriptions","organizations_url":"https://api.github.com/users/mhaberler/orgs","repos_url":"https://api.github.com/users/mhaberler/repos","events_url":"https://api.github.com/users/mhaberler/events{/privacy}","received_events_url":"https://api.github.com/users/mhaberler/received_events","type":"User","site_admin":false},"created_at":"2015-04-30T07:26:28Z","updated_at":"2015-04-30T07:26:28Z","body":"[this thread] ( http://lists.zeromq.org/pipermail/zeromq-dev/2013-December/024421.html) nicely summarizes the problem.\r\n\r\nOne possible solution is to add an authentication token to the protobuf message proper, and derive that token from the client's key. That should enable verification of origin on a per-message basis on the server side. A particular key would then be assoicated with a certain set of credentials when issued.\r\n\r\nThat is all we need AFAICT, since we can assume protobuf for granted."}}