[zeromq-dev] Proposal for ZeroMQ certificate storage

[Pieter Hintjens]

You're right. No reason to store the key in clear even if it's
broadcast in clear.

On Tue, Oct 22, 2013 at 6:02 PM, Laurent Alebarde <l.alebarde at free.fr> wrote:
> I was considering only storage here, not broadcast. But what I propose
> requires one additional operation to decrypt the key before broadcasting it.
> I was not precise enough thought, sorry.
>
> The idea is that if some attacker gain control on the server, the public
> keys stored are crypted. Catching plain text keys on the wire certainly
> under TLS, or catching them in memory, makes the attacker work far harder.
>
> As a comparison, IMO, it is like storing clients personal data.  The server
> designer just crypt them because he wants to protect his customer's personal
> data, whatever it is really useful or not. That's not  the server designer's
> role to judge that. His customer just expect he takes care of his data.
>
>
> Le 22/10/2013 16:21, Pieter Hintjens a écrit :
>
> When you broadcast a public key for anonymous users to pick up, you
> cannot encrypt it.
>
>
> On Tue, Oct 22, 2013 at 2:25 PM, Laurent Alebarde <l.alebarde at free.fr>
> wrote:
>
> Hi Pieter,
>
> I have only one small comment inside "Use Cases": Why storing the public key
> in plain text when it does not hurt to crypt it ? It is a question of
> philosophy. One of my design principle for everything is to not degrade
> performance, even when it looks not hurting, as far as it is cheap.
>
> Otherwise, what is below do not overlap and represents mainly some possible
> answers to "What's missing here is some proposal for standard filenames and
> certificate locations on disk. This should be part of a standard
> specification, I think."
>
> Cheers,
>
>
> Laurent
>
>
> Le 22/10/2013 12:55, Pieter Hintjens a écrit :
>
> Did you have any comments on http://hintjens.com/blog:62?
>
> There's some overlap with your suggestions.
>
> On Tue, Oct 22, 2013 at 11:47 AM, Laurent Alebarde <l.alebarde at free.fr>
> wrote:
>
> Hi everybody,
>
> In addition to the format, a discussion about the storage of the
> certificates may be usefull.
>
> I propose the following (I am very verbose so that I can understand myself
> in one week ;-) ):
>
> Requirements:
>
> The certificates SHALL be able to be accessed in an efficient way using a
> hash table or even an array.
> For huge client base, a choice of databases, relational or nosql, SHOULD be
> possible
> The key that permit to retrieve the certificate SHALL be able to be
> transmitted in plain text, without compromising security. Thus, the public
> key SHALL not be considered as a valid key, even if many people consider the
> public key can be public. Let's call it the "server's certificate storage
> key"
> The client key pair SHALL be able to be generated in the client or in the
> server, at designer's choice.
> The certificate on the server side SHALL contain at least the client public
> key, but SHALL be able also to contain a server key pair dedicated to this
> client.
> The certificate on the client side shall contain the server's certificate
> storage key.
>
> Rationals :
>
> Efficiency on the first step of the hand-check is a key against DDOS
> attacks.
> Database enables a good memory management and offers replications /
> synchronisation.
> The server's certificate storage key cab be sent in plain text by the client
> in the HELLO message. When the server generates the certificate, its
> server's certificate storage key can be a hash of a function of the
> registration data of the client, or simply the client number, or whatever
> appropriate to the designer. Then, the server's certificate storage key is
> completely decorrelated from the cryptographic keys. The server's
> certificate storage key is transmitted to the client along with the
> certificate which contains the server public key.
> The most secure is probably in the client ?
> Having dedicated server keys per client is not so expensive, so let it be
> possible for every one who wish it.
> to enable the server to retrieve the appropriate certificate from its
> storage
>
> Here is a possible scenario in the frame of a client registration under TLS
> or equivalent:
>
> Both server and client generate a key pair.
> The client transmit its public certificate to the server (only its public
> key).
> The server creates a certificate which contains its own key pair dedicated
> to this client, and aggregates the client public certificate received.
> The server generates an arbitrary key for this certificate, say a hash of
> the two public keys, the clients organisation name and client number, and
> checks it is unique - if not, add one until it is. This is the server's
> certificate storage key.
> The server transmit this key and its own public certificate to the client
> which aggregates the information in a final certificate that contains the
> client key pair, the server public key, and the certificate key.
>
> When the client sends HELLO to the server, it sends a modified HELLO that
> contain the certificate key. With this key, the server retrieve the
> appropriate certificate from an array, a map, or a database, and proceed
> with the hand-check.
>
> It is important to recall of course that I am not a security expert, nor a
> cryptography expert. It is just the expression of a system designer with
> performance, security and simplicity in mind.
>
> I may put that in a RFC if it is desirable.
>
> Cheers,
>
> Laurent
>
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
-
Pieter Hintjens
CEO of iMatix.com
Founder of ZeroMQ community
blog: http://hintjens.com