[zeromq-dev] Proposal for ZeroMQ certificate storage

Laurent Alebarde l.alebarde at free.fr
Tue Oct 22 18:02:40 CEST 2013


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
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131022/b301e01a/attachment.htm>


More information about the zeromq-dev mailing list