[zeromq-dev] EncryptedSocket added to pyzmq in branch

[Burak Arslan]

Hello,

I got one thing to reiterate: socket identity signing.

(X)REP/REQ sockets use message parts to store target nodes. If the
payload of the message is important enough to bother with complex
cryptography, its routing state also should be.

However, ZeroMQ currently does not support a way to alter the way
message identities are stored and transmitted.

The following is my thinking out loud, to expose my line of thought.

It doesn't make sense to encrypt routing state as it has to be readable
by intermediate nodes. It may make sense to expose only the NEXT node,
but it will prevent routers from making shortest path decisions (???)
and will also force a router to handle both the requests and the
responses of a message exchange. so it's not a good idea to enrypt
message identities. but they can be signed.

It'd make sense for zeromq api to provide customizable
push_identity/pop_identity methods on zmq::message_t. This will let core
ZeroMQ avoid cryptography elegantly, but it will introduce incompatible
changes to the message protocol, because modified/unmodified message
identities will have to be distinguished. As the result of this,
identities may be unintelligible to intermediate nodes who don't
understand custom identities.

Giving this much control over routing data to the user will cause
protocol fragmentation and will result in a non-standardisable ZeroMQ
protocol.

So one needs a way to separate identity data from its signature. (or
whatever custom data the user wants it to carry)

The solution I propose is to have "recursive" message parts. In the
current scheme, one message may be made of many message parts. But one
message part can't contain multiple message parts. If a zmq message part
could contain multiple message parts, one would be able to append any
sort of metadata to the message identity, (or to any kind of message) in
a way that will not confuse intermediate nodes.

But this means the metadata could be ignored. i don't know what to do in
case this is not desirable.

Having "recursive" message parts will also prevent req/rep sockets from
using empty message as a delimiter between the body and the payload
(which is an ugly hack, imo). Any req/rep message can have two parts,
header and body, which in turn can contain multiple message parts.

So, if security will be an integral part of ZeroMQ, and if we want a
clean separation between the core and the security code, we need to
extend the message format to be more flexible. i think recursive message
parts can be an answer.

so that's another point to consider for zeromq 3.0 :)

best regards,
burak


On 11/05/10 17:54, Martin Lucina wrote:
> Hi all,
>
> coming a bit late to this thread, thank you all for the many interesting
> points and discussion.
>
> "Security" is a very vague topic, and as others have pointed out different
> people have different needs in terms of trust and the risk factors they are
> trying to protect against.
>
> As I see it, there are two separate parts to "Security" in 0MQ.
>
> 1) Robustness. This is a work in progress, with the competition Pieter
> already mentioned, personally I would also like to spend time
> systematically hardening 0MQ to follow the well accepted principle of "Be
> liberal in what you receive, and conservative in what you send."
>
> 0MQ should be robust enough that it cannot simply be crashed remotely.
> Obviously if the *application* using 0MQ is not robust against invalid data
> then it may not survive an attack, but that is outside of our scope.
>
> Further, 0MQ should provide enough hooks and sensible defaults to minimise
> the chance of a remote DoS. For example, at the moment if you decide to
> send a 4GB message, the receiving peer will gobble it all up happily, and
> possibly go off and thrash for a while. So what is needed is a sane default
> for "maximum message size", and a mechanism for the application to
> manipulate this default, detect/block/unblock rogue clients for
> administrative purposes, and so on and so on.
>
> This is just an example; there are many cases like this in 0MQ. Some are
> easier to solve than others. So, it's a work in progress, and we'll get
> there, eventually, with the help of the community.
>
> 2) Encryption and/or authentication. Min's work here is a nice experiment,
> and it gives us excellent discussion points, so I'll react to those here:
>
>> 1.  Is the EncryptedSocket interface that Min has prototyped in his
>> branch a good plugin interface for users to add message based
>> encryption of their choice.
> It's a start. I take it you're explicitly not caring about key management,
> which is a complex problem all on its own.
>
>> I think that once everyone understood that Min's prototype leaves the
>> choice of cryptographic approach up the user, they became more
>> comfortable with the design.  It does not pick or enforce a particular
>> encryption approach.  But, one valid point made is that the interface
>> does not force users of pyzmq to handle encryption in a correct
>> manner.  They might do it well, or they might do something very
>> insecure.  This is important...
> Precisely, Burak has made good points about this. Naive users may use bad
> crypto, and rely on it. This is why we have TLS, IPSec, and so on. Just
> plugging a cipher on top of 0MQ doesn't constitute good design.
>
>> 2.  Is the idea of message based security worth pursuing?
>>
>> I think Min's recent email summarizes the differences between message
>> based and transport based security:
>>
>> Transport: encrypt/decrypt happen at each zmq hop
>> Message: only decrypt at endpoints (big deal for many relay hops)
>> Transport: always encrypt everything
>> Message: can encrypt only the sensitive subset of traffic
> In my opinion, and looking at it from the point of view of eventually
> arriving at a solution which we could implement as an (optional) part of
> the 0MQ core, message-based encryption is the only way that makes sense.
> It allows for sensible multihop topologies, and is the only sane way of
> dealing with encrypted multicast.
>
>> 3.  What type of cryptographic approach is appropriate for message
>> based security.
> I would look at prior art here. If we're dealing with message-based
> encryption, then the existing model that would make most sense is something
> like the IPSec ESP (provides encryption) and AH (provides authenticity)
> layers.
>
> Steve McCoy also mentioned DTLS at some stage; I have no experience with
> it, maybe someone here can say if it's worth looking at.
>
>> What vulnerabilities remain if message based HMAC + AES security is
>> used?  In my mind, the main issue become how to distribute/exchange
>> keys.
> Key management, definitely. However, that can be factored out as a separate
> protocol and an application, much the same way as IPSec does it with IKE.
>
> So the only functionality 0MQ core would provide would be per-message
> encryption and decryption, with a well-defined wire protocol to support
> this, and leave it up to the user to provide the keys.
>
> As a 2nd step, a scheme similar to IKE could be designed, which would run
> as an application on top of 0MQ.
>
> Cheers,
>
> -mato
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev