Open Stack

I have to admit, I like the idea of pulling crypto operations into one
place for easy identification of deviation from policy.


-Rob



On 06/06/2014 19:44, "Jeffrey Walton" <noloader at gmail.com> wrote:

>On Fri, Jun 6, 2014 at 9:34 AM, Darren J Moffat
><Darren.Moffat at oracle.com> wrote:
>> ...
>>> One of the first problems seems to be the lack of a single OpenStack
>>> crypto wrapper. That is, there should be an OpenStack.Crypto that
>>> provides all the primitives. All source code should call through
>>> OpenStack.Crypto. Instead, code sometimes calls into other libraries
>>> and sometimes rolls its own stuff.
>>>
>>> What OpenStack.Crypto wraps or implements is a different issue. But
>>> its a good first step to ensure calls are being funneled into audited
>>> code.
>>
>> Providing that OpenStack.Crypto does no crypto algorithm implementation
>>and
>> does not directly do key management or key generation then it should be
>> possible to depend on a FIPS 140 validation of the underlying provider
>>(all
>> the way back to something like OpenSSL's libcrypto if possible).
>Yes, agreed. Here, I was more interested in funneling all calls into a
>single set of controlled interfaces to make it easy to use correctly
>(and hard to use incorrectly) and easy to audit.
>
>Having, for example, OpenStack.Crypto.Random call into OpenSSL's DRBG
>is fine with me (not that I'm anyone special). Others crypto providers
>should be OK, too. For example, I've never looked at BouncyCastle, but
>I imagine in PRNG is satisfactory or acceptable.
>
>The audit would then be fairly easy:
>
>    cd openstack
>    grep -R -i Random.random *
>
>There should be no hits (or maybe one if OpenStack.Crypto is using it).
>
>> The other advantage of using something like OpenSSL as the actual
>> cryptographic algorithm implementation is that it provides CPU optimised
>> versions of the common ciphers eg using AES-NI or the SPARC T4
>>instructions
>> for AES, SHA256 etc.
>Some might call that a detriment ;) (But all-in-all, I agree).
>
>I know there's some concern over RDRAND due to the lack of
>audit-ability. I think there's some concern over AES-NI and timing
>attacks. I believe most in US Federal, US Financial and other
>Enterprises will be satisfied, though. I guess it depends on the
>threat model. Document the risk and move on or use something other
>than a multi-tenant environment...
>
>> It may also be useful if OpenStack.Crypto code be a thin layer on top of
>> PKCS#11 - though I'd hope that most of the cases where OpenStack needs
>>key
>> management can be dealt with via projects like Barbican providing it as
>>a
>> service.
>Yes, good idea.
>
>Jeff
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security