On Thu, 2018-03-08 at 22:21 +1100, Chris Billington wrote: > Hi all, > > I want to secure software running on computers and other devices in > physics > labs, which all communicate over zeromq. They can execute arbitrary > code > and turn lasers on and off if you send them the right zmq packets, so > it's > important to make this secure even though it's on a mostly trusted > university network. University IT isn't perfect and occasionally let > botnets say hello to oven controllers, and we don't want to have to > trust > the whole physics department to be able to tell our computers what to > do > just because we share a network with them. > > So I'm implementing CurveZMQ security based on the "ironhouse" model, > since > we need to authenticate both clients and servers. However it is > cumbersome > to give every possible computer its own public key and private key, > and > distribute all these keys to all others. Whenever a new device gets > plugged > into the network, we would need to add the device's public key to > every > other device and computer. Given the variety of devices, it's hard to > come > up with a solution that isn't quite manual (like taking a SD card out > of > some custom microcontroller board and putting it into a computer just > to > add keys to it so the zmq server running on the microcontroller will > recognise a new client). I would ideally like a situation where even > if I > am on a computer that has never interacted with the lab network > before, I > could put "the lab master key" on this computer, and have it talk to > everything without having to also go do something to all other > devices. > > What would be the security consequence of having many servers all > using the > same CurveZMQ private/public keypair? > > What would be the security consequences of having many *clients* all > using > the same CurveZMQ private/public keypair? > > What about if all clients and all servers talking to each other had > identical keypairs? > > If this last possibility is safe then the "lab master key" can be > simply > one private key, from which the public key can be derived, and I only > need > to tell new lab users a 40 character z85 encoded ascii string to let > them > talk to everything in the lab as a client or a server. > > If this sounds like terrible security, it doesn't seem much different > to > the current case where all the lab computers have the same password, > which > we just change occasionally (or never). Or to giving a member of your > home > the wifi password. > > That is of course, so long as there isn't anything fundamental about > CurveZMQ that means using keys for multiple peers is insecure. > > There's a comment on curvecp.org: > > Nonce separation > > > > An administrator can set up several CurveCP servers sharing a long- > > term > > > secret key. The servers then have to support nonce separation: > > > for example, > > > the first of four servers is configured to use counters with > > > bottom bits > > > 00, the second is configured to use counters with bottom bits 01, > > > the third > > > is configured to use counters with bottom bits 10, and the fourth > > > is > > > configured to use counters with bottom bits 11. > > > > > > Which is maybe pointing to there being a problem. > > If I have to use different keys for every server and client, then > CurveZMQ > probably isn't tenable for my use. I'm really looking for a "give the > new > lab member or temperature-monitoring-raspberry-pi the wifi password" > type > of solution. > > Any suggestions appreciated, > > Chris
Hi, There was a discussion on this topic a few months ago: https://lists.zeromq.org/pipermail/zeromq-dev/2017-December/032134.html -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
