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

[Luca Boccassi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180308/70154c75/attachment.sig>