Hi
The problem I see is that any shared/copied private key is not private
anymore.
Why not set up a key lookup service which knows and offers the public
keys of all known devices? Every device could get the list of known
public keys when starting up, feed them into a ZAP authenticator [1],
and be ready to accept connections from all known devices.
Feasible steps to follow when a new device is added to the network:
(1) add look up service's public key to the new device (copy its cert file)
(2) generate a new keypair on the new device (simply create and save a
new one [2] unless there is already a cert)
(3) copy new device's public key to the lookup service
CZMQ's zcertstore [3] makes it very simple to allow all keys from a
designated directory, including live reloading whenever the ZAP handler
looks up a public key.
Of course it could be automated more. For example, instead of manually
entering a new device's public key in the lookup service's file system,
the lookup service could simply save new device's public keys
("candidate keys") into another directory. Then you simply copy the
right file (most likely the newest, but be careful) to the directory of
allowed public keys. I actually used to run a similar system, where new
candidate keys could be allowed via a web interface. It worked great.
On the non-central devices, you could reload all known public keys if a
ZAP authentication fails (or for simplicity's sake, just before every
authentication request). Or maybe even more elegant: Simply make the ZAP
handler a proxy to the ZAP handler on the central lookup service.
Of course this assumes you're okay with running a central service.
Otherwise, I guess you could use etcd [4] or zgossip [5] to share all
public keys in a completely decentralized way. I have no personal
experience with those though.
Regards,
Patrik
[1] http://czmq.zeromq.org/czmq-master:zauth => zauth (pipe, certstore)
[2] http://czmq.zeromq.org/czmq-master:zcert => zcert_new (), zcert_save
(self, filename)
[3] http://czmq.zeromq.org/czmq-master:zcertstore => zcertstore_new
(location)
[4] https://github.com/coreos/etcd
[5] http://czmq.zeromq.org/czmq-master:zgossip
On 09.03.2018 08:30, Chris Billington wrote:
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.bocca...@gmail.com <mailto:luca.bocca...@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 <http://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
<https://lists.zeromq.org/pipermail/zeromq-dev/2017-December/032134.html>
--
Kind regards,
Luca Boccassi
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org>
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
<https://lists.zeromq.org/mailman/listinfo/zeromq-dev>
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
