If you are going to use the sca 6000 for hmac you will need to enable some options in the mca.conf driver config file:
take a look at the user's guide for details - you will need to add entries for enable-hmac=1; and then assuming you are running the card in FIPS mode (only sha1 is available in FIPS mode) enable-multipart-sha1=1; You need to reboot for the config changes to take effect. -gary On 08/20/09 07:38, Sandeep Cavale wrote: > Hi, > > We have a problem with running Apache mod_nss with SCA6000 in FIPS mode.. > When we disable the "Sun Metaslot", so that nss can use only the > Hardware token completely, we get the following error when we try to > connect to our server from openssl: > > # openssl s_client -connect localhost:443 -tls1 -state > CONNECTED(00000005) > SSL_connect:before/connect initialization > SSL_connect:SSLv3 write client hello A > SSL_connect:SSLv3 read server hello A > depth=0 /C=US/ST=California/L=Santa Clara/O=Sun/OU=Org/CN=nobody > verify error:num=18:self signed certificate > verify return:1 > depth=0 /C=US/ST=California/L=Santa Clara/O=Sun/OU=Org/CN=nobody > verify return:1 > SSL_connect:SSLv3 read server certificate A > SSL_connect:SSLv3 read server done A > SSL_connect:SSLv3 write client key exchange A > SSL_connect:SSLv3 write change cipher spec A > SSL_connect:SSLv3 write finished A > SSL_connect:SSLv3 flush data > *SSL3 alert read:fatal:bad record mac > ---------------------------------------------------------------*> The > fatal error!! > SSL_connect:failed in SSLv3 read finished A > 1723:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record > mac:../../../../common/openssl/ssl/s3_pkt.c:1052:SSL alert number 20 > 1723:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake > failure:../../../../common/openssl/ssl/s3_pkt.c:529: > > > According to a thread on Opensolaris forum > (http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 > <http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120>) > "By default, the SCA 6000 does not export any hash algorithm to user > space apps because the hw can not support multi-part operations" > > Output of cryptoadm confirms this: > bash-3.00# cryptoadm list -m provider=mca/0 > *mca/0*: > *---------------------------------------------------------------*> our > Sun Crypto > Accelerator > CKM_SHA_1,CKM_DES_CBC,CKM_DES3_CBC,CKM_AES_CBC,CKM_AES_CTR,CKM_DES_CBC_PAD,CKM_DES3_CBC_PAD,CKM_AES_CBC_PAD,CKM_RSA_X_509,CKM_RSA_PKCS,CKM_DSA,CKM_DH_PKCS_KEY_PAIR_GEN,CKM_DH_PKCS_DERIVE,CKM_RSA_PKCS_KEY_PAIR_GEN,CKM_DSA_KEY_PAIR_GEN,CKM_DES_KEY_GEN,CKM_DES2_KEY_GEN,CKM_DES3_KEY_GEN,CKM_AES_KEY_GEN,CKM_DES_CBC_PAD,CKM_DES3_CBC_PAD,CKM_AES_CBC_PAD,CKM_DES_CBC,CKM_DES3_CBC,CKM_AES_CBC,CKM_AES_CTR,CKM_RSA_X_509,CKM_RSA_PKCS,0x80004653 > > (CKM_SHA_1 is the only hashing algorithm we see) > This probably means that since I am forcing the NSS to use only hardware > token (by disabling Sun Metaslot), even the HMAC hashing algorithm is > being looked for in the SCA6000 card. But since it does not expose any > hashing algorithm it fails to decode the hash client sends after change > cipher spec msg, right? > > However if using JCE I list out all the supported algorithms of SCA6000, > I see even these hashing algs amongst them: > Mac.HmacSHA384 > Mac.HmacSHA512 > Mac.HmacMD5 > Mac.SslMacMD5 > Mac.HmacSHA1 > Mac.SslMacSHA1 > Mac.HmacSHA256 > > So, I tried configuring Tomcat to use the SCA6000 as its JSSE provider, > and as I had guessed this worked without a glitch (by this I mean > connecting with openssl) !!! I believe that's because for JSSE the above > hashing algs are visible. To confirm this, I disabled these hashing > algorithms in the sca6000.cfg file used by the JSSE provider and trying > with openssl I get an error similar to Apache web server: > > # openssl s_client -connect localhost:443 -tls1 -state > CONNECTED(00000005) > SSL_connect:before/connect initialization > SSL_connect:SSLv3 write client hello A > SSL_connect:SSLv3 read server hello A > depth=0 /C=US/ST=California/L=Santa Clara/O=Sun/OU=Org/CN=nobody > verify error:num=18:self signed certificate > verify return:1 > depth=0 /C=US/ST=California/L=Santa Clara/O=Sun/OU=Org/CN=nobody > verify return:1 > SSL_connect:SSLv3 read server certificate A > SSL_connect:SSLv3 read server key exchange A > SSL_connect:SSLv3 read server done A > SSL_connect:SSLv3 write client key exchange A > SSL_connect:SSLv3 write change cipher spec A > SSL_connect:SSLv3 write finished A > SSL_connect:SSLv3 flush data > *SSL3 alert read:fatal:unexpected_message* > > ----------------------------------------------------------------------------------------> > > Again after client's change cipher spec > SSL_connect:failed in SSLv3 read finished A > 2089:error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected > message:../../../../common/openssl/ssl/s3_pkt.c:1052:SSL alert number 10 > 2089:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake > failure:../../../../common/openssl/ssl/s3_pkt.c:529: > > > So the question is, how is JSSE able to access the hashing algorithms > while NSS cannot?? Our SCA card and web servers have to be running in > FIPS mode too... > Any help is greatly appreciated.. > > > ------------------------------------------------------------------------ > > _______________________________________________ > crypto-discuss mailing list > crypto-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crypto-discuss
