[nanomsg] Re: How is security going to be implemented in nanomsg?
- From: Alex Elsayed <eternaleye@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sat, 14 Jun 2014 15:28:32 -0700
Andrew Starks wrote:
<snip>
> In that spirit:
>
> What mechanisms are missing from nanomsg that make it difficult to
> integrate it into an existing security layer?
>
> If none, or those could be addressed, then I believe that you'd be a
> tutorial away from something valuable.
>
> -Andrew
In my opinion, it's less an issue of "What is missing from nanomsg" and more
about how nanomsg has very different semantics from what most security
layers assume.
Hop-by-hop, at the transport level (TCP, etc), you really do want to use
existing mechanisms like TLS - they layer well. However, they _don't_
provide some of the guarantees people want. While you can use, say, TLS with
certificates signed by a common CA in order to ensure that only permitted
nodes join (and join in the correct places, via subjectAltName or similar),
that gives zero protection against a malicious node hearing things it
shouldn't if it DOES somehow join.
Meanwhile, end-to-end measures - like ensuring that your REQ is only
readable by an appropriate REP - fit with existing systems very poorly
indeed because each pattern's semantics demand a different form of
protection entirely.
A security layer over PUB/SUB would require something along the lines of
broadcast encryption (Blu-ray's AACS is an example of such; cable and
satellite TV as well), and can't assume bidirectional communication.
PIPELINE has similar restrictions.
Something over REQ/REP can't assume that any two REQs go to the same
destination, and SURVEY similarly has sessions that only last one exchange.
On BUS patterns, any multi-message exchange between two nodes to set up
keying would be incredibly noisy and inefficient.
PAIR, of course, has similar semantics to what TLS and DTLS need - but it's
message-based (ruling out TLS) and supports messages far larger than DTLS
can handle.
Broadcast encryption _might_ be able to be made into a general solution, but
that would take some real thought by cryptography experts far more skilled
than myself. Broadcast encryption systems frequently have the ability to
subset which valid receivers can decrypt - that could be used for things
like PUB/SUB topics, etc.
However, broadcast encryption tends to be pretty focused on cases where keys
are _allocated_ from some central point, rather than _generated_ by
participants, which may be an administrative complication. It'd also pretty
much _require_ hop-to-hop security _in addition_ to such a broadcast-
encryption-based end-to-end system, to prevent such per-node keys from being
snarfed off the link.
Other related posts:
