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

[Chris Billington]

Thanks for the link to the previous discussion.

OK, so I can't find any confirmation that it *is* safe for a client and a
server to have the same long term keys as each other, so I'll go ahead and
assume its not, even though it may be.

But I find it hard to fathom that many clients all with the same client
keys talking to many servers all with the same server keys could be any
less secure than a single client that makes many connections over time to a
single server. After all, the authentication code isn't storing any
information on disk, and is forgetting everything in memory about a
conversation as soon as it is over (and if not, definitely at process
restart), so how could the case of two connections A <--> B and A <--> C
where B and C share keys be any different to the case of the same
connection A <--> B  being made on two separate occasions?

So what I'll do is have a single server keypair, and a single client
keypair, and distribute both private keys to all peers as a shared secret
(they can derive the public keys with zmq_curve_public). Peers will use
either the server or client keypair in any given connection depending on
whether they are acting as the server or the client, which I can by
convention determine by saying whoever calls bind() is the server.

Of course if any peer leaks the shared secret (comprising the two private
keys) everyone is compromised, but that's no different to someone getting
the lab computer password so this is totally satisfactory to me.

Here is my implementation for anyone who is interested:

https://bitbucket.org/cbillington/zprocess/src/default/zprocess/security.py

Cheers,

Chris

On Fri, Mar 9, 2018 at 12:30 AM, Luca Boccassi <luca.boccassi at gmail.com>
wrote:

> 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
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180309/529e162e/attachment.htm>