2

I make software for physics labs, and computers in the labs are exchanging all sorts of information with each other and with researcher's laptops, usually on a university network. I use ZeroMQ for most communication.

I'm working on using ZeroMQ's built in encryption to secure this communication in an upcoming version of my software.

ZMQ's security model is public key crypto based on CurveCP, and I'm following their "ironhouse" example with both clients and servers verifying each other's identity via each other's pubic keys.

The thing is though, that I don't really have well defined "clients" and "servers", the computers involved are more like 'peers'. And they can come and go at short notice, and it is not practical to distribute a new public key to every computer that a new person's laptop might want to talk to, or to distribute a new public key whenever a new raspberry pi that is set up to monitor some piece of equipment. Automating key distribution via some server and ssh is also something I can't really expect of the average physics lab.

But I think "here, copy this base64 string to your config file on every computer you want to be able to talk to each other, and treat it like the lab computer password" is a reasonable expectation.

To that end, can I give all peers the same private/public keypair, and treat that keypair (or at least the private key) as a preshared secret? Everyone having the same keys doesn't seem much different to everyone having the login password to the lab computers (which are also all the same usually), so long as the crypto doesn't require that two peers have different keys. Of course it's broken if someone leaks the keys, but that's no different to the lab computer passwords being compromised given that that gives everyone on the network RDP access - you have to change the keys and tell everyone in either case.

I don't have to have a single keypair - it's just slightly simpler. I could have two keypairs, and have each peer decide which to use based on which calls bind()in zeromq and which calls connect() - the difference is arbitrary in zeromq but is an already broken symmetry that could allow me to define by convention which peer uses the 'client' keypair and which uses the 'server' keypair. In either case I'd be distributing the same private keys to everyone, the only question is whether I distribute one or two.

I would have used symmetric crypto with a preshared key if it were an option in ZeroMQ, but it's not, and inserting symmetric crypto at the application level means some of the info ZeroMQ sends would not be encrypted (it prepends routing information and that sort of thing) and would also leave the applications vulnerable to replay attacks, since some ZeroMQ sockets are one-way and it doesn't give you access to the underlying TCP socket, so you can't do any sort of handshake to make the symmetric crypto use a per-session salt or whatever.

So, tl;dr is ot OK for peers to use identical keypairs in CurveZMQ?

| improve this question | |
1

The question you should ask yourself is: what are you trying to protect?

If you distribute your key between all peers and if proper key distribution is "too complex" for your use case, then you might as well disable encryption altogether: your keys ain't safe and so your messages ain't either. Even if you enable FS, you will not protect your system against MITM attacks.

Perhaps a better direction to look into would be implementing a key distribution system: have a central CA server allow for automatic client enrollment using whatever authentication mechanism you deem sufficient for your needs and simply have everyone trust keys issued by this CA. That would keep peer-to-peer communication secure while allowing you to scale it pretty much indefinitely.

| improve this answer | |
  • If the private key remains safe (even though it's the same on all computers), how would I be vulnerable to a MITM attack? I mean, I have to get the keys onto the computers securely, but there are lots of ways to do that. Once I've done it, peers can authenticate each other (which is what they're doing anyway with CurveZMQ, I'm not writing my own crypto here, I just want to know if the algorithm relies on peers not having the same private key). – Chris Billington Mar 8 '18 at 10:05
  • A central server isn't practical. For one, why should the users trust me? For two, some devices are not really amenable to contacting a central server. Some are random microcontrollers or FPGAs and might need to be reflashed to get a new key onto them. Yet we can't just let any microcontroller connect to some computer because the computer turns lasers on and off based on what the microcontroller says, which could be a safety hazard and ruin the data. Yet new users will want to talk to the microcontroller from their laptop, meaning if it's to authenticate them, they all must have the same key. – Chris Billington Mar 8 '18 at 10:23
  • @ChrisBillington I really think your security model is messed up. Please start with asking yourself that question: what are you trying to protect and against what? – Stephane Mar 8 '18 at 11:52
  • If you distribute your private keys the way you describe them, they aren't secure any more: sooner or later, they will leak: it's security by obscurity, not by design. That's why you can assume that you're vulnerable to MITM – Stephane Mar 8 '18 at 11:53
  • 1
    I know exactly what I'm talking about: you come here with the question "can I get away with suggesting a lousy security practice to my users" and expect a green light but aren't prepared to think about the consequences of what you're doing. That's fine: it's your choice. – Stephane Mar 9 '18 at 9:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.