I don't think auto-key-migrate being turned on or off affects SCA 6000's FIPS 140-2 mode of operation. Regardless of whether the keys move out of the card or not, they cross the crypto boundary of the card encrypted when the device is running in FIPS mode, which meets the requirement for level 3. I had always thought auto-key-migrate was there to provide a software fall-back for the case when a crypto device of any kind was saturated.
Also there was some mention of ncp and n2cp being inside the crypto framework "cryptographic boundary". It might be better to not have those hardware implementations be tied to the Solaris Crypto Framework's cert, since that cert is going to be evaluated on a single OS in a specific configuration (unless you plan to do S10 and S11). Also you'd want the T1 and T2 procs to be OS independent in their certification as a single-chip module. This way, they could possibly retain FIPS certification should you decide to do a non-Solaris OS (I think there's a flavor or two of Linux out there and a BSD variant that can work with the T1 though I don't know if they use the chip's crypto functions). SPARC isn't a good example, but were x86 processors to be used on Sun systems that had on-board crypto functionality, the chances of those customers running Linux or other OSes becomes much higher. So maybe this is more of an "in-principle" kind of thing at this point. --Jamil Anthony Scarpino wrote: > Darren J Moffat wrote: > >>Anthony Scarpino wrote: >> >>>Sort of on this topic, can providers like ncp and n2cp be made FIPS >>>certified some day.. Does a hardware provider require a keystore on >>>board (like a SCA-6000) to be FIPS? >> >>I don't see any reason why not. They should at least be able to get a >>FIPS algorithm certification. >> >> >>>If so, there are some interesting scenarios one can have with ncp and >>>the recently integrated hardware keygen project.. >> >>Where "interesting" depends on where you draw the crypto boundary! >> >>For things like ncp and n2cp that have no keystore of their own, >>personally I'd class them the same as the kernel software providers (ie >>"inside" the crypto framework). In some ways they are just platform >>specific "softishware" providers (ncp is pretty much this because the >>hardware doesn't do RSA it does modexp, n2cp is different though). >> >>The other thing to consider for the future is when we get around to >>adding support in the framework for building complex/newer/combi >>mechanism out of older/simpler ones (eg AES_CCM in "software" using what >>ever of ECB/CBC the hardware has, RSA_SHA1_PKCS by combining in software >> the hardware RSA and software SHA1) the boundary will need to be >>different as well. >> > > > Yes, the crypto boundary is the heart of the "interesting"... When the > auto-key-migration flag was put in for the SCA-4000/6000 to protect them > from metaslot moving keys off of them because of FIPS compliant > providers.. If the framework is FIPS compliant, how important is that > flag? and if it's useful still, who does it affect.. > > If we establish a FIPS certified ncp as inside the crypto boundary, the > generating an RSA key from ncp and creating a token object from that key > value in softtoken would be considered inside the crypto boundary.. but > today's design that would not happen given the auto-key-migration flag. > > It would seem to me that we could remove auto-key-migration from the > framework, or at least not have it disabled in FIPS.. If the user is > so concerned about moving keys off a SCA-6000, they can use > non-extractable.. > _______________________________________________ > crypto-discuss mailing list > crypto-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crypto-discuss
