[openstack-dev] Secure RPC

Eric Windisch eric at cloudscaling.com
Wed Oct 24 13:54:52 UTC 2012


> 
> None of us can compare to Bruce I'm sure (all praise Schneier!) and I'm

Everything I know is from his book. This palliwan has not surpassed his master. 
> 
> regularly guilty of running off down crypto rabbit holes - allow me to bring 
> this back up to the high level momentarily. Is it likely that signing and 
> encryption would both be predicated on a-symmetric cryptography? If that's the 
> case then the primitives in use will likely be the same and perhaps we should 
> come to a point where signing/encryption are both options that pivot on the 
> same extension? Or perhaps look a little more closely at the work Eric has 
> already done on extending RPC so that we can come up with something flexible 
> enough to support both.
> 
> 
> 


I hope nobody questions if we need signing. Even with encryption, we'd want signing. This is what will allow us to bring in RBAC.  Additionally, if we're going to sign, the signature should be inside of the encrypted message.

The locations of the hooks will be the same. The key management and crypto bits will be largely the same. We're also going to use this from several modules (impl_kombu, _qpid, and _zmq), so the goal is to make these bits reusable as possible.

Adding crypto should "just" be another change to the wire format. We'd encrypt the whole message, signature and all, and possibly sign the cryptotext as well to verify that the encryption was performed by the trusted party. (more about S/E/S patterns: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html)

Also, signing is something that when enabled, must be vetted on the receiver end. Receivers will not accept any unsigned messages in a trusted environment. However, encryption enforcement is sender-end. Receivers will still be able to opt into trusting signed messages that aren't encrypted, it will be the responsibility of the sender to encrypt before sending. (We might want to put a receiver restriction here too for additional security, but it wouldn't be strictly necessary -- S/E/S would make it really difficult for someone to launch a MITM, but signing-only does a decent job on its own)

Regards,
Eric Windisch


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121024/0dde774f/attachment-0001.html>


More information about the OpenStack-dev mailing list