On Mon, Nov 2, 2009 at 8:09 PM, Bob Foss <bob.e.f...@gmail.com> wrote:
> I have an application that includes an implementation of SSH in Java.
> It currently uses the Sun JCE and I'm trying to make use of the
> SunPKCS11 provider which wraps calls to NSS (3.12.4) to take advantage
> of NSS's FIPS compliance. (We won't be shipping this until after 3.12.4
> has completed the process.)
>
> I'm stuck at the point where the SSH key exchange creates the first
> session key and attempts to encrypt with it. After a couple days of
> digging I found the following seems to prevent me from using any key
> that wasn't randomly generated by NSS.
>
> in fipstokn.c:
> /* FIPS can't create keys from raw key material */
> if (SFTK_IS_NONPUBLIC_KEY_OBJECT(*classptr)) {
> rv = CKR_ATTRIBUTE_VALUE_INVALID;
> } else {
>
[...]
>
> Is it possible to do this with NSS without commenting out the if
> statement above?
Yes, it's posssible. By the way, you can't modify the source code
in the NSS softoken because that code is in the FIPS boundary.
To work around this NSS limitation, you need to
1. generate a temporary symmetric key in the NSS softoken
2. use that key to encrypt the SSH session key as data.
3. use that key to unwrap the encrypted SSH session key.
In step 2, the SSH session key is considered data. In step 3,
it's considered a key.
I have an example in the PKM_SecretKey function in our
pk11mode.c test program:
http://mxr.mozilla.org/security/source/security/nss/cmd/pk11mode/pk11mode.c#2700
NOTE: recent FIPS validations show that NIST now allows
a software crypto module to import and export secret/private keys
unencrypted. The limitation imposed by the NSS softoken
used to be required for FIPS validation and was considered
good key management practice. Its value is that it eliminates
a key management issue for applications as the crypto module
doesn't give applications a chance to mishandle unencrypted
secret/private keys. So I recommend that you not work around
this limitation, if possible.
> I'm not yet wedded to using the SunPKCS11 wrapper, so if there's
> something that's feasible with JSS I can look at that too.
JSS imposes the same limitation because the limitation comes
from the underlying NSS softoken.
Wan-Teh
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
