Open Stack

Hi Simo,
Nice writeup. A couple of comments I have just in case:
1) Regardless public key or shared key based solution, there's always a need to store the secret key. The difference is with public key based, only the owner has the private key.
2) You mentioned that PKI is slow and complex, which is true comparatively but should be ok in this use case. For example, I can do 1034 sign/s and 22829 verify/s on my shabby macbook pro of 2010 and the CPU usage does not seem to be an issue. Compared to the 2 lookups per message in your proposal as you mentioned, it's much much more efficient.
3) It looks like your key server is like Kerberos.  There's probably no point to reinvent the wheel. It should easily adapt to this 1:1 use case as you proposal supported.
4) Arguably, your proposal supports confidentiality, authorization control (via the shared secret)  and integrity and anti-replay (via timestamp), but it falls short on non-repudiation due to the nature of shared secret. 
5) The 2 lookups to Key Server per message is way too much with regard to efficiency.
6) As mentioned, failure to support 1:m, m:n messaging imposes too much restriction to the overall system.
That said, the following is what I would suggest, which supports 1:1, 1:m and m:n messaging with confidentiality, integrity, authorization, non-repudiation and anti-reply:
a) In keystone, for each user add an entry for its public key - only the user itself knows its own private key.
b) To support 1:m and m:n, each "group/role" of users is provisioned with its group public key - all users of this "group/role" is provisioned with the "group/role" private key. 
c) All public keys (via x.509 or bare key) are cacheable. Cautious senders and recipients should check regularly but it's an overkill to check once per message.
d) On sending the message, the sender does the following:
d.a) looks up (if not cached or to be cautious - assuming there's no revocation in place) for the recipient's or recipients' public key. 
d.b) generate a encryption key (EK) and a signing key (SK) (not necessary if public key signing is used) and decide its lifetime (expiration and) 
d.c) generate a random # of at least 128 bit long, start/current time (e.g. via gettimeofday), EK and SK signature, expiration and and sender-id, concatenate and sign them using its private key
d.d) Encrypt the message (together necessary meta data, e.g. recipient list and lifetime left, sequence counter) using EK, as BodyE and sign the encrypted BodyE using the sign key as SIGN.
d.e) For each recipient, use its public key to encrypt EK, the encryption algo,  signing key SK (if needed), signing algo,  and EK/SK expiration), then prepend it with the recipient's public key identifier - e.g. uid.
d.f) Send the the outcome of d.c), BodyE and SIGN from d.d) and d.e) over the all recipients.
Note: d.b), d.c) and d.e) are only done once for the duration of the EK/SK lifetime, so the # of public key calculations (RSA/EC etc) are minimized. The algos are there for extensibility and the recipient can reject if it's weak.
e) On receiving the message, the recipient doe the following:
e.a) looks up )if not cached or to be cautious - assuming there's no revocation in place)  for the sender's public key.
e.b) verify sender signature and time window etc if not previously verified for this "session" (a while ago - time window == expiration).
e.c) decrypt the block prepared by d.e), gets the EK, SK, expiration and verify the expiration. 
e.d) Using SK to verify signature
e.e) Decrypt the message using EK, check against replay via verifying the expiration and counter/sequence etc.
If more detailes are needed, please let me know. Note that there may be loose ends given the limited time I have spent on this. 
Regards,JZ
On 4/25/13 5:37 AM, "Simo Sorce" <simo at redhat.com> wrote:


Hello list,
at the Summit we had a very interesting and productive discussion about
Message Signing/Encryption for RPC Messages sent via the Message Queue.


I would like to present a proposal that uses symmetric keys and a
central key server to address the problem:


https://wiki.openstack.org/wiki/MessageSecurity


I would really like to get feedback on the proposal, especially if there
are corner cases I have not considered.


Simo.


--
Simo Sorce * Red Hat, Inc * New York




_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130426/9cac2b61/attachment.html>