[Openstack-security] Python Crypto libs Trustability

Jeffrey Walton noloader at gmail.com
Thu Jun 5 22:32:07 UTC 2014


On Thu, Jun 5, 2014 at 3:58 PM, Travis McPeak
<Travis_McPeak at symantec.com> wrote:
> Hi all,
>
> I¹ve been thinking about some of the crypto libraries that are being used
> in OpenStack projects, specifically how much confidence should we have in
> them.
Yes, this is a governance issue. If the third-party library does not
meet standards, then it should not be used in OpenStack.

Cloud providers also have a governance issue: OpenStack must meet the
provider's standards, else the provider cannot use OpenStack.

However, there's a transitive property in their that's not readily
apparent. Namely, how the risk flows from third-party libraries
through OpenStack to the providers. Third-party libraries used to
cause me a lot of problems when I was doing risk and security
architecture work in the financial sector.

> It has occurred to me that we don¹t really know if they have been
> audited, or even if anybody has taken a hard look at them.  We know that
> security of a system is only as good as the weakest link, but what about
> these backbones of security that we are relying on?  Have they been
> vetted?
I've looked at pycrypto in the past, and I have a number of open
questions. For example, Rob Clark and I were talking about the PRNG in
pycrypto before CVE-2013-1445 and CVE-2012-2417 were published.

And I seem to recall (but I could be wrong) that an *insecure*
fallback is performed by pycrypto's Crypto.Random *if* /dev/urandom is
not available.

> I have started an etherpad:
> https://etherpad.openstack.org/p/CryptoLibraryInventory to track this very
> issue.  Please contribute if you know anything about any of the libraries
> listed.  If there are libraries that I haven¹t listed, please add them.
That's a good idea.

> I think with the collective knowledge of the community, we can begin to
> build some clarity around which libraries are more ³trustworthy² than
> others, and how much we can trust them.
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.

Jeff




More information about the Openstack-security mailing list