Hi Everybody! These are very rough, high-level notes of areas I believe we need to do work in with some rough estimates for timing, which include coming up to speed, unit testing & debugging by me, but for the most part does not include process such as PSARC, etc. Time estimates do not constitute any contract or promise to deliver in any sort of time frame (<insert disclaimer here> :)
Please let me know if I've missed anything, or if you believe I have unrequired work on here. I will use this to help come up with a 1-pager, PSARC cases, full fledged design, etc. Most of these design decisions are based off of discussions with crypto framework i-team members, but I wanted to open this up to a larger audience for discussion. (Special thanks to Darren M., Tony & Krishna for all their early feedback) Work for this will be done as much as possible on this alias, and the website is here: http://opensolaris.org/os/project/crypto/inprogress/fips/ Thanks! Valerie Solaris Cryptographic Framework FIPS-140-2 Rough Design ======================================================= Date: 22 August 2007 We are seeking FIPS 140-2 Level 2 Certification, but first need to make several changes to the Solaris Cryptographic Framework to meet all of the requirements of this governmental standard. We are seeking certification for FIPS 140-2, rather than FIPS 140-3, since FIPS 140-3 is not officially adopted yet and has different requirements on underlying operating systems that seems to require more testing. The changes are currently being targeted for OpenSolaris and Nevada, and we will do our best to do changes in a manner that other distros can leverage them to seek their own certification. The cryptographic boundary includes: libpkcs11, pkcs11_softtoken, pkcs11_kernel, drv/crypto, kcf, and the kernel software modules. Currently we believe that cryptoadm (1M), libcryptoutil, and drv/crypotoadm are outside of the cryptographic boundary. uCF == userland Cryptographic Framework kCF == kernel Cryptographic Framework 1. User Interface ================= 1.1 cryptoadm command ===================== 1.1.1 Need to add a "FIPS mode" that an administrator can use to tell the framework (both uCF & kCF) to set the FIPS policy. - This will leverage existing cryptoadm policy functionality. - All non FIPS approved algorithms will be disabled. - All non Sun standard plugins and hardware providers will be disabled, since there is no way to programmatically tell if a plugin has FIPS certification or not. That is, by default, only pkcs11_softtoken will be left enabled. (see 1.1.2 for exceptions). - if possible unload nonapproved algorithms, else, inform admin that they need to reboot approx 3 weeks 1.1.2 Administrator needs method to add in FIPS 140-2 approved hw provider That is, by default, only pkcs11_softtoken will be left enabled. (see 1.1.2 for exceptions). That is, by default, only pkcs11_softtoken will be left enabled. (see 1.1.2 for exceptions). That is, by default, only pkcs11_softtoken will be left enabled. (see 1.1.2 for exceptions).s, overriding default FIPS policy mode. - may require a different mode, or modification to existing mode - it is up to admin to verify they are FIPS approved. There is no kcf API entry point for this (and can't really be, due to the fact that only specific versions of the sw are certified - changing this would invalidate certification and you can't "anticipate" certification either) approx 3 weeks 1.1.3 Once in FIPS mode, cryptoadm is probably the correct place to set the policy in pkcs11.conf (and kcf.conf) approx 3 weeks. 2. Software Random Number Generation ==================================== We need to bring the RNG into compliance with one of the following: * FIPS 186 * ANSI X9.62 * ANSI X9.31 Krishna recommends going with FIPS 186, as n2rng complies with this standard. Our code, though, was not based on any of these standards, so at least 2 months of work are required to bring this into compliance. Depending on performance, we may want to put this in it's own module that is only used when we are in FIPS mode. approx 2 months 3. Userland Cryptographic Framework =================================== 3.1 pkcs11_softtoken ==================== 3.1.1 Power on self test: - Random number generation (that is, check the results of two subsequent calls to RNG, see section 4.9.1 of FIPS 140-2 for details). This may be better suited for a different location? Perhaps libpkcs11/kcfd? - Algorithm known answer testing 3.1.2 Conditional self tests needed for: - Pair-wise consistency test (for public & private keys) (FIPS 140-2, 4.9.2) approx 5 weeks 3.2 pkcs11_kernel ================= Disabled if no approved FIPS 140-2 certified providers plugged in, otherwise will need the same checks as pkcs11_softtoken (see section 1.1.2 for discussion on how other plugins may be allowed) approx 2 weeks 3.3 metaslot ============ Will be disabled in FIPS mode. (note: This decision to disable was based on essentially only having pkcs11_softtoken plugged into the uCF, but since this decision was made we decided it will be configurable to possibly have other modules available, perhaps we should reconsider? Additional reason to reconsider disabling metaslot: METASLOT_AUTO_KEY_MIGRATE was added at the request of crypto card folks for use with their HW accelerators that are FIPS 140 approved. As this stands now, I plan on changing this section to "will be left enabled in FIPS mode", unless someone has a good reason to disable it?) approx 3 days 3.4 libpkcs11 ============= 3.4.1 Query pkcs11.conf for mode, enforce policy as appropriate. - It's probably simpler to have "fips mode" policy set by cryptoadm in pkcs11.conf, and simply have libpkcs11 just enforce (as this code is already written and tested). 3.4.2 Ensure power-on tests are called for all initialized libraries. approx 3 weeks 4. Kernel Cryptographic Framework ================================= 4.1 Conditional self tests needed for: Random number generation key pair generation approx 5 weeks 4.2 kCF API This API is currently a private interface, so there is no way for anyone not at Sun to write tests for this. we need to: - Document the API accurately so that tests can be written for this, most likely need to publish the API for the certification folks to be able to write tests for it. Darren has done the first step of this by including the kCF header files in SUNWhea. approx 4 weeks (includes running process) (note: harder to predict due to doc work - VAF would need assistance from the likes of Mark Powers and Krishna on insuring accuracy of manpages.) 5. All FIPS approved algorithms =============================== Power on self tests need to be added to each algorithm. We don't want to run these all the time, due to performance impact. Need to know when we are in FIPS mode & perform these tests only at that time. The trick will be doing this check in such a way as to not impact our general performance. approx 6 weeks 6. Module Verification ====================== This, or something like it, needs to remain as part of the framework to meet the FIPS certification requirements. That is, we have to be able to verify the modules have not been tampered with. We currently have this with elfsign & friends, but that is not open source. There is another project in the works, Validated Execution, that we may also be able to leverage. 7. Open Questions: ================== 7.1 Could we cache power-on-self-test results? That is, so we wouldn't have to rerun them everytime someone uses ssh, libsasl, etc. That would be extra work, but the performance gains will be significant. Will need to check with the certification lab to see if this is okay.
