-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement encryption for 0MQ communication channel #146
Comments
dmgav
changed the title
Security features (encryption) for ZMQ communication channel
Implement encryption for 0MQ communication channel
Mar 28, 2021
Addressed in PR #147 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Implement security features that would protect RE Manager controlling real hardware from requests from unauthorized clients. It is assumed that both ZMQ Server (RE Manager) and the client (HTTP Server or GUI client) are located on a secure network within the lab (where it is relatively easy to get physical access to the computers running the server and the client). The intention is to protect RE Manager from accidental interference due to errors in configuration (network may contain multiple server/client pairs, including systems used for development and testing and may be running without encryption), not from malicious hacking attacks.
The proposed security feature may be fully implemented by activating and configuring built-in ZMQ Curve-based encryption and providing convenient configuration options for each component of the system. The encryption scheme is using two public/private key pairs, one for the server and one for the client. The key pairs are generated using
zmq.curve_keypair()
function (there is alsozmq.curve_public()
function that generates public key from the private key). In the first version, the clients will be assigned permanent key pair (it can be changed to a configurable or randomly generated key pair later if needed). The server and the client should be configured with private and public keys from the server key pair before the client can communicate with the server. If the keys don't match or the client has encryption disabled, the ZMQ requests will time out.The proposed approach was tested in the existing Queue Server code by hard-coding the key pairs and running the server in multiple modes. In RE Manager code ZMQ socket was set as a Curve server and a private key (long term secret key) was set:
The client ZMQ socket is operating in the default Curve client mode. The SERVERKEY is the server public key, which will be made configurable. The PUBLICKEY/SECRETKEY is the key pair of the client, which is used for encrypting message set from server to client. This key pair may remain hard coded for now, since it does not play essential role in the security scheme.
Encryption will be disabled by default, since it is not needed for most of the demo/development. The options to configure RE Manager (as a server), HTTP Server (as a client) and
qserver
CLI tool (as a client) will be implemented. RE Manager will accept private (secret) key as a value of a CLI parameter or an environment variable. HTTP Server will accept public key as a value of an environment variable.qserver
CLI tool will accept public key as a value of CLI parameter or environment variable.The text was updated successfully, but these errors were encountered: