[zeromq-dev] Consequences of using same keys on multiple servers or clients in CurveZMQ

[Chris Billington]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180308/73e6aeb6/attachment.htm>