Open Stack

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