On 02/03/2014 09:30 AM, Leon Brits wrote: > Steve, > > Thanks for your help so far. > > Q: How is this certification of the algorithms done? Our device only > has a USB interface acting like a smartcard so will the lab (or OSF) > use our cryptoki/CSP interface(s) to validate the algorithms or > should we make a development board, which has a serial interface, > available. Note that we are aiming for FIPS 140-2 level 3 > certification so the device is potted (not the devboard).
The algorithm testing consists of a set of data files, the "request" file supplied by the test lab and the "response" files generated from the input request files on the test device (IUT Implement Under Test). Collectively those algorithm test files are often called "test vectors". The structure of the test vectors and the typical processing process is documented in Appendix B of the FIPS module User Guide: https://www.openssl.org/docs/fips/UserGuide-2.0.pdf Actual test vectors generated in the course of formal testing can be found at: http://opensslfoundation.com/testing/validation-2.0/testvectors/ Note the complete set takes nearly a quarter GB of writable disk space. We use NFS or CIFS when we can, and sometimes need to use mountable storage devices. That typical processing assumes an environment with POSIX support and an interactive command shell. A more creative approach is required for some unusual or limited platforms. Fortunately the goal of the algorithm testing is just the generation of the response files, and the means by which those are generated isn't tightly constrained. In many cases the vendor can generate those in an internal setting, in which case the vendor is asked to sign a form attesting that the response files were generated on the appropriate target device using the appropriate FIPS module. When the canned test suite software supplied with the OpenSSL FIPS Object Module ("fips_algvs" generated from the "build_algvs" Makefile target) cannot be used directly, it is permissible to use custom test software to read data from the request files, feed it to the FIPS module on the target device, and collect the output in response files. In the most extreme cases of very limited embedded devices we've had to do that one line at a time. Usually it's sufficient to hack the original test suite code to accommodate specific limitations of the thetarget device. In many cases the target device in a production configuration lacks any means to exchange test vector data between the target device and the outside world, and/or any sort of shell access. In such cases it is permissible to enable or install normally absent diagnostic/maintenance/development access and/or hardware interfaces such as serial ports. In your specific case either option should be acceptable. You could either write test software to utilize the cryptoki/CSP interface, or you could use a development board. That's assuming the development board has the same OS and processor as the production device of interest. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct [email protected] [email protected] gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
