Do You Really Know Where Your Crypto is Executing? (S31c)
Let’s face it, most of us make use of OpenSSL in one form or another. If we don’t use it directly, it’s highly probable that some of the processes which are running in our module make use of it as their crypto provider. Some vendors have even worked together with the OpenSSL Software Foundation to create private label versions of OpenSSL to suit their own specific purposes whereas other have undertaken similar exercises with 3rd party organizations. We at Cisco have developed our own variant of OpenSSL (referred to as CiscoSSL) which includes numerous enhancements specifically designed to accommodate our own internal requirements.
Using OpenSSL (or some variant), along with a FIPS Object Module, is an excellent method for providing cryptographic services to a module which will satisfy the requirements of FIPS 140-2, Common Criteria, DoD UC APL and potentially several other non-US international cryptographic validation schemes.
Having just extolled the virtues of employing OpenSSL (and its variants), there is a warning to be attached to the use of this amazing library and that would be CAUTION. Although this library provides great flexibility to a development team wishing to implement cryptographic services, it is this very flexibility which can be its own worst enemy. Depending on the configuration of a number of build time and run time parameters, and the unique characteristics of the platform upon which it is being executed, this crypto library can make use of its own default crypto, or can delegate that crypto to external devices (e.g. H/W crypto ICs). The source of entropy may also come from the default library software, an external routine which the calling application has selected as a replacement, or it may be directed to some hardware entropy source. Unless your development team is well versed in the proper use of the options which are available to them, it is quite possible that what they build might operate in a very different fashion than what the design intended. This can pose a number of problems for the certification engineers.
This presentation will look at a number of the more common configuration options in OpenSSL and discuss ways of setting them properly so that the module operates as expected. We shall also look at techniques for certification engineers to understand how a module has been configured so that they may have certainty that it was constructed properly and meets all the requirements of whatever certification program’s criteria against which it is being validated.