Yevgeniy Gubenko wrote:
The main reason not to work with JSS is the following paragraph written in
http://www.mozilla.org/projects/security/pki/jss/provider_notes.html
The following classes don't work very well:
KeyStore: There are many serious problems mapping the JCA keystore interface
onto NSS's model of PKCS #11 modules. The current implementation is almost
useless. Since these problems lie deep in the NSS design and implementation,
there is no clear timeframe for fixing them. Meanwhile, the
org.mozilla.jss.crypto.CryptoStore class can be used for some of this
functionality.
We have a lot of use of keystore in our application.
I didn't understand your observation:
As long as you're using using NSS to store your certs and keys you
should have no problem using JSS.
The Mozilla-JSS provider's keystore implementation is almost useless,
but you can use CryptoStore as the documentation states.
Using JDK6 SunPKCS11 you may manage to access both the Java keystore and
NSS's but I have
not tried this so I do not know what your issues will be.
http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html#KeyStoreRestrictions
yes NSS supports x509 but does
What did you mean saying "but does"?
it was a typo that I didn't edit correctly when I sent the email, as I
looked at the time, and realized I had to catch my commuter train.
do disregard the "but does".
So if NSS supports X509, why do I get the below exception without adding
another 2 providers?
sometimes error messages are not clear.
As well, I wasn't able to run my class with the only dynamically added crypto
provider, until I enabled both of the following providers in
jre/lib/security/java.security configuration:
1. security.provider.1=sun.security.pkcs11.SunPKCS11
${java.home}/lib/security/sunpkcs11-solaris.cfg
2. security.provider.2=sun.security.provider.Sun
These are default providers, you may be able to disable #2, but you
cannot disable #1 SunPKCS11 if you want
the JDK to talk with NSS's PKCS11.
ie. from your own code:
String configFileName = "/opt/nss/pkcs11.cfg";
java.security.Provider nss = new sun.security.pkcs11.SunPKCS11(configFileName);
If you have an actual issue with JSS or an actual bug with NSS's pkcs11
implementation you should use this forum.
If you want to get your program working with the JDK's SunPKCS11 then I
would ask further questions in
http://forum.java.sun.com/index.jspa
have a good day,
glen
Otherwise I got an exception:
Exception in thread "main" java.lang.ExceptionInInitializerError
at javax.crypto.Cipher.getInstance(DashoA13*..)
at decryptPass.main(decryptPass.java:43)
Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
at javax.crypto.SunJCE_b.<clinit>(DashoA13*..)
... 2 more
Caused by: java.security.PrivilegedActionException:
java.security.cert.CertificateException: X.509 not found
at java.security.AccessController.doPrivileged(Native Method)
... 3 more
Caused by: java.security.cert.CertificateException: X.509 not found
at
java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:153)
at javax.crypto.SunJCE_b$1.run(DashoA13*..)
... 4 more
Caused by: java.security.NoSuchAlgorithmException: X.509 CertificateFactory not
available
at sun.security.jca.GetInstance.getInstance(GetInstance.java:142)
at
java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:148)
Doesn't NSS3.11.4 crypto API support all X.509 stuff?
yes NSS supports x509 but does
Best Regards,
Yevgeniy
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glen Beasley
Sent: Wednesday, June 04, 2008 18:15
To: mozilla's crypto code discussion list
Subject: Re: Cannot encrypt cipher via pkcs11 in nss fips mode
hello,
Your chosen set of operations to be performed is: "DESede/CBC/NoPadding"
DESede is a block cipher and operates on 8-byte blocks. Thus, input to
DESede Cipher with CBC mode and "NoPadding"
scheme should be in multiple of 8 bytes for the encryption/decryption to
succeed.
I was able to get your program working by adding two bytes to the
following line.
String password = "passwordString!!"; //16 bytes
If you need to have variable lengths of input you need to first pad your
data, then encrypt.
After you decrypt you need to remove the pad.
some links for your review:
http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html
http://tools.ietf.org/html/rfc2898
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/tests/JCASymKeyGen.java
have a good day,
glen
Yevgeniy Gubenko wrote:
Hi,
I'm a new incomer trying to handle keying material for NSS fips mode.
This is the case:
I am working with pkcs11 provider on Solaris 10, which is configured
to work with mozilla NSS provider.
This is my configuration file for pkcs11 provider :
name = NSScrypto
nssLibraryDirectory = /opt/nss/lib
nssSecmodDirectory = /opt/nss/fipsdb
nssModule = fips
I've created NSS Database and modified it to work in fips module:
certutil -N -d /opt/nss/fipsdb
modutil -fips true -dbdir /opt/nss/fipsdb
Then I created a key in the DB:
symkeyutil -K -n test1 -t des3 -d /opt/nss/fipsdb
Now let's get to my Java code which should retrieve the key from the
DB and use it as a SecretKey to encrypt/decrypt passwords.
This is a class which encrypts password:
import javax.crypto.SecretKeyFactory;
import javax.crypto.spec.DESedeKeySpec;
import javax.crypto.spec.DESKeySpec;
import javax.crypto.SecretKey;
import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import java.security.*;
public class encryptPass
{
public static void main(String[] args)
{
try
{
String configFileName = "/opt/nss/pkcs11.cfg";
java.security.Provider nss = new
sun.security.pkcs11.SunPKCS11(configFileName);
java.security.Security.insertProviderAt(nss,1);
java.security.KeyStore ks =
java.security.KeyStore.getInstance("PKCS11", nss);
char[] nssDBPassword = {'f','i','p','s','1','4','0','-','2'};
ks.load(null, nssDBPassword);
SecretKey key = (SecretKey) ks.getKey("test1", nssDBPassword);
//iv for CBC mode - note, in practice you don't generate a
random iv for decryption :)
byte[] iv = new byte[8]; //64-bit block size for 3DES
SecureRandom sr = SecureRandom.getInstance("PKCS11", nss);
sr.nextBytes(iv);
IvParameterSpec params = new IvParameterSpec(iv);
Cipher encryptCipher =
Cipher.getInstance("DESede/CBC/NoPadding", nss);
encryptCipher.init(Cipher.ENCRYPT_MODE, key, params);
System.out.println("encryptCipher provider: " +
encryptCipher.getProvider().getName());
String password = "passwordString";
byte[] passBytes = password.getBytes();
byte[] passBytesEncrypt = encryptCipher.doFinal(passBytes);
}
catch (Exception ex)
{
ex.printStackTrace();
}
}
}
The output from the class execution is:
encryptCipher provider: SunPKCS11-NSScrypto
java.security.ProviderException: update() failed
at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:460)
at sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:391)
at
sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:422)
at
sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:409)
at javax.crypto.Cipher.doFinal(DashoA13*..)
at encryptPass.main(encryptPass.java:48)
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DEVICE_ERROR
at sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native
Method)
at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:450)
... 5 more
From the other hand I have a symmetric class which decrypts the
passwords with the same doFinal method (the difference is that the
cipher is initialized in DECRYPT_MODE) and it succeeds to run.
Any suggestions will be appreciated.
This email and any files transmitted with it are confidential
material. They are intended solely for the use of the designated
individual or entity to whom they are addressed. If the reader of this
message is not the intended recipient, you are hereby notified that
any dissemination, use, distribution or copying of this communication
is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the
sender and delete or destroy any copy of this message
------------------------------------------------------------------------
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
This email and any files transmitted with it are confidential material. They
are intended solely for the use of the designated individual or entity to whom
they are addressed. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, use, distribution or
copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender
and delete or destroy any copy of this message
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
This email and any files transmitted with it are confidential material. They
are intended solely for the use of the designated individual or entity to whom
they are addressed. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, use, distribution or
copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender
and delete or destroy any copy of this message
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
