On 08/23/09 22:31, Sandeep Cavale wrote: > > Yes.. I did upgrade to firmware 1.1 update 2... And I also installed all > the patches that came with that update. > > This is what I get with "scadiag" > > # scadiag -V mca0 > scadiag (Sun Crypto Accelerator 6000) 1.1 > Copyright 2006 Sun Microsystems, Inc. > All rights reserved. > Use is subject to license terms. > > The board status as shown in scamgr show status is: > Board Status > ---------------------------------------------------------------- > Device Info: > * Hardware Version: 1.4.50 > * Bootrom Version : 1.0.4 > * Firmware Version: 1.1.0
You did not install the fw patch (the version would be 1.1.2). In the tar there's a directory /Sun_Crypto_Acc_6000-1_1-u2-Solaris/Solaris/firmware/Patches sr1-ubrm-31> ls 128364-02 128371-02 You need to install 128371-02 via patchadd. After install you must install the firmware on to the card - the patchadd just places the files on the files system and not the card. you can use scamgr to do the upgrade. > load firmware /usr/lib/crypto/firmware/sca/sca6000fw you must then reset the card. -gary > > > I have also attached the /var/adm/messages > > Again, we seem to have no problems running Tomcat web server (configured > to use the card via JSSE). We can see > that aesbytes, aesjobs, casubmit, cbsubmit, dhderive, dhkeygen, rsaprivate, > sha1bytes, sha1hmacbytes, sha1hmacjobs, sha1jobs > are the counters that increase in kstat indicating that all these > operations are being done on the card... > > Only Apache(with mod_ssl or mod_nss) cannot access the hashing algorithms :( > We would like the Apache web server to be able to make full use of the > card just like Tomcat.. > > Kindly let us know if there is anything wrong with the configuration or > if something is not properly initialised.. > > > On Fri, Aug 21, 2009 at 9:03 PM, <Gary.Morton at sun.com > <mailto:Gary.Morton at sun.com>> wrote: > > On 08/21/09 07:15, Sandeep Cavale wrote: > > Hi, > > I upgraded the firmware to 1.1.. > > > You pulled down 1.1 update 2, correct? Did you install all of the > patches included in that download as well? Can you send me the > output from scadiag -v mca0 > > > > The cryptoadm lists the HMAC algs: > mca/0: > > CKM_SHA_1,CKM_SHA512,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_SHA_1_HMAC,CKM_SHA512_HMAC,CKM_SHA_1_HMAC_GENERAL,CKM_SHA512_HMAC_GENERAL,CKM_RSA_X_509,CKM_RSA_PKCS,CKM_DSA,CKM_DH_PKCS_KEY_PAIR_GEN,CKM_DH_PKCS_DERIVE,CKM_ECDSA_KEY_PAIR_GEN,CKM_ECDH1_DERIVE,CKM_ECDSA,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 > > > But now we seem to have stranger problems :( > > I tried 2 things with Apache > > i) When I used mod_nss, something funny seems to be happening > with the card. Here's what the nss logs say: > > [Fri Aug 21 17:17:19 2009] [info] Configuring server for SSL > protocol > [Fri Aug 21 17:17:19 2009] [info] In FIPS mode, enabling TLSv1 > [Fri Aug 21 17:17:19 2009] [debug] nss_engine_init.c(765): FIPS > mode enabled, permitted SSL ciphers are: > [+rsa_3des_sha,+fips_3des_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] > [Fri Aug 21 17:17:19 2009] [debug] nss_engine_init.c(770): > Configuring permitted SSL ciphers > > [+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] > [Fri Aug 21 17:17:19 2009] [info] Using nickname ksfips:certfips. > [Fri Aug 21 17:17:19 2009] [error] Certificate not verified: > 'ksfips:certfips' > > -------------------------------------------------------------------------> > Note certificate is found but not verified > [Fri Aug 21 17:17:19 2009] [error] SSL Library Error: -8156 > Issuer certificate is invalid > [Fri Aug 21 17:17:23 2009] [info] Configuring server for SSL > protocol > [Fri Aug 21 17:17:23 2009] [info] In FIPS mode, enabling TLSv1 > [Fri Aug 21 17:17:23 2009] [debug] nss_engine_init.c(765): FIPS > mode enabled, permitted SSL ciphers are: > [+rsa_3des_sha,+fips_3des_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] > [Fri Aug 21 17:17:23 2009] [debug] nss_engine_init.c(770): > Configuring permitted SSL ciphers > > [+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] > [Fri Aug 21 17:17:23 2009] [info] Using nickname ksfips:certfips. > [Fri Aug 21 17:17:23 2009] [error] Certificate not found: > 'ksfips:certfips' > > -------------------------------------------------------------------------> > Cannot find it anymore!! > [Fri Aug 21 17:17:23 2009] [info] Configuring server for SSL > protocol > [Fri Aug 21 17:17:23 2009] [info] In FIPS mode, enabling TLSv1 > [Fri Aug 21 17:17:23 2009] [debug] nss_engine_init.c(765): FIPS > mode enabled, permitted SSL ciphers are: > [+rsa_3des_sha,+fips_3des_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] > [Fri Aug 21 17:17:23 2009] [debug] nss_engine_init.c(770): > Configuring permitted SSL ciphers > > [+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] > [Fri Aug 21 17:17:23 2009] [info] Using nickname ksfips:certfips. > [Fri Aug 21 17:17:23 2009] [error] Certificate not found: > 'ksfips:certfips' > [Fri Aug 21 17:17:23 2009] [info] Configuring server for SSL > protocol > > > If I try listing using "cryptoadm list -v", the hardware > providers which earlier listed mca/0 is now empty!!! > > > That would indicate the card has unregistered/crashed. Can you send > o/p from /var/adm/messages. There are some important bug fixes in > the patches in that update 2 download so lets make sure they are > installed. > > -gary > > > This seems to be similar to these bugs: > https://bugzilla.redhat.com/show_bug.cgi?id=446851 and > https://bugzilla.mozilla.org/show_bug.cgi?id=434043 though I use > the latest NSS 3.12.3 > > > ii) Secondly I replaced mod_nss with mod_ssl > > I still get the "same bad mac errror" but surprisingly if I > disable the HMAC algs (which I really do not want to do) Apache > starts working. This was pointed to me by this discussion: > > http://mail.opensolaris.org/pipermail/crypto-discuss/2007-December/000442.html > > <http://mail.opensolaris.org/pipermail/crypto-discuss/2007-December/000442.html> > > > Only that with kstat I observe except rsaprivate, all other > operations are not offloaded to the card at all (I'd like to > have all operations especially RSA, AES offloaded to the card) > > I have also verified that the case is the same with firmware 1.0 > for mod_ssl > > The above problem seems to be a bug > (http://bugs.opensolaris.org/view_bug.do?bug_id=6606361) and my > Solaris machine has the patch 127128-11 which is having this > correction. I am not sure why I still have to use the workaround > mentioned inspite of having the fix > > I know my posts are really getting lengthy , but any guidance > will be truly appreciated :) > > > > > On Fri, Aug 21, 2009 at 1:48 AM, <Gary.Morton at sun.com > <mailto:Gary.Morton at sun.com> <mailto:Gary.Morton at sun.com > <mailto:Gary.Morton at sun.com>>> wrote: > > > You should download the 1.1 code - the 1.0 code does not > support this. > > http://www.sun.com/products/networking/downloads.html > > > -gary > > > On 08/20/09 11:22, Sandeep Cavale wrote: > > Thanks Gary.. > The guide seems to be 1.1 but the firmware we have is 1.0.. > Anyway I shall give it a try, not sure if it would work > with 1.0 > Is there any other way to get the HMAC algorithms accessible > from NSS/mod_nss/cryptoadm without firmware upgrade to 1.1 ? > Because JSSE/JCE can access them with existing firmware.. > > > On Thu, Aug 20, 2009 at 8:29 PM, <Gary.Morton at sun.com > <mailto:Gary.Morton at sun.com> > <mailto:Gary.Morton at sun.com <mailto:Gary.Morton at sun.com>> > <mailto:Gary.Morton at sun.com <mailto:Gary.Morton at sun.com> > > <mailto:Gary.Morton at sun.com > <mailto:Gary.Morton at sun.com>>>> wrote: > > 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> > > <http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 > > <http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120>> > > <http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 > <http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120> > > <http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 > > <http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120>>> > > <http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 > <http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120> > > <http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 > > <http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120>> > > <http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 > <http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120> > > <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 > <mailto:crypto-discuss at opensolaris.org> > <mailto:crypto-discuss at opensolaris.org > <mailto:crypto-discuss at opensolaris.org>> > <mailto:crypto-discuss at opensolaris.org > <mailto:crypto-discuss at opensolaris.org> > <mailto:crypto-discuss at opensolaris.org > <mailto:crypto-discuss at opensolaris.org>>> > > > http://mail.opensolaris.org/mailman/listinfo/crypto-discuss > > > > > > >
