R: Problems with encrypted CMS with Luna HSM and JBOSS
Emiliano Latini <[email protected]> Tue, 28 May 2019 10:12:15 +0000
| Newsgroups | gmane.comp.encryption.bouncy-castle.devel |
|---|---|
| Message-ID | <PR1PR01MB4795F5516496114C3949B140981E0@PR1PR01MB4795.eurprd01.prod.exchangelabs.com> |
It seems it was my fault since I was missing to set the key as extractable on java.security now it’s working fine. Still I’m missing a thing, in my singleton I use slotmanager and after login I set the key as extractable but it seems Luna isn’t taking this into account. R: [dev-crypto] Problems with encrypted CMS with Luna HSM and JBOSS Yes I understand the problem, but I’ve checked this and I’m using the virtual slots with these schema: JBOSS1-->client 1-->slot 10 (virtual slot) -->links to slot x and y with serial 1111 and serial 2222 JBOSS2-->client 2-->slot 9 (vritual slot)-->links to slot k and z with serial 1111 and serial 2222 So we created the two virtual slots taking care partitions serial numbers so each client points to a virtual slot which points to the corretct (same) partions which share the same serial. The weird thing is this happens only in JBOSS if I use two tmcats on differents servers all works ok. This is disappointing since I can’t understand what are the differences. Da: Massimiliano Ziccardi [mailto:[email protected]] Inviato: lunedì 27 maggio 2019 15:15 A: Emiliano Latini Cc: [email protected] Oggetto: Re: [dev-crypto] Problems with encrypted CMS with Luna HSM and JBOSS I worked with LunaSA some years ago and I remember that when working with virtual slots, the order of the slots is not guaranteed (slot 3 on machine 1 could be different than slot 3 on machine 2). So, unless you are accessing the slot by name instead then by number, I would suggest to double check that they are really using the same slot. Moreover, the fact that the 'virtual HA slot' has the same name/number, doesn't imply they are really pointing to the same slots: that is something that should be checked as well (LUNASA Virtual HA slots are 'software slots' managed by the LunaSA driver on the client, so they can be different on any client). Finally, you could try running this command: · vtl haAdmin -synchronize -group <group-label> on both server to ensure that the slots in the HA group are synchronised. Il giorno lun 27 mag 2019 alle ore 14:56 Emiliano Latini <[email protected]<mailto:[email protected]>> ha scritto: Consider we’re using an HA slot on the HSM wich is a virtual slot on two partions, so yes we access the same HSM on two different virtual slots (one per client) which link to the same slots. Da: Massimiliano Ziccardi [mailto:[email protected]<mailto:[email protected]>] Inviato: lunedì 27 maggio 2019 14:53 A: Emiliano Latini Cc: [email protected]<mailto:[email protected]> Oggetto: Re: [dev-crypto] Problems with encrypted CMS with Luna HSM and JBOSS The question could sound stupid, but have you ensured that both servers are accessing the same HSM and the same slots? Il giorno lun 27 mag 2019 alle ore 12:59 Emiliano Latini <[email protected]<mailto:[email protected]>> ha scritto: Hi there. I’m trying to decrypt an encrypted p7m using BC along with HSM. The code works well on a standalone machine i.e tomcat, if I run it in a Jboss Domain mode I get only one node to work. The other gets this exception: function 'C_UnwrapKey' returns 0x110 on key=xxxxxxx note this key doesn’t exist on the HSM so I suppose it’s trying to put the extracted key This is part of the stack : Caused by: com.safenetinc.luna.exception.LunaException: Unable to inject key at com.safenetinc.luna.provider.key.LunaKey.injectKey(LunaKey.java:801) at com.safenetinc.luna.provider.key.LunaSecretKey.InjectSecretKey(LunaSecretKey.java:139) at com.safenetinc.luna.provider.key.LunaSecretKey.InjectSecretKey(LunaSecretKey.java:121) at com.safenetinc.luna.provider.keyfactory.LunaSecretKeyFactoryDES3.engineTranslateKey(LunaSecretKeyFactoryDES3.java:91) at javax.crypto.SecretKeyFactory.translateKey(SecretKeyFactory.java:409) at com.safenetinc.luna.provider.cipher.LunaCipher.engineInit(LunaCipher.java:336) at com.safenetinc.luna.provider.cipher.LunaCipherIv.engineInit(LunaCipherIv.java:64) at javax.crypto.Cipher.init(Cipher.java:1393) at javax.crypto.Cipher.init(Cipher.java:1326) at org.bouncycastle.cms.jcajce.EnvelopedDataHelper$1.doInJCE(Unknown Source) at org.bouncycastle.cms.jcajce.EnvelopedDataHelper.execute(Unknown Source) at org.bouncycastle.cms.jcajce.EnvelopedDataHelper.createContentCipher(Unknown Source) at org.bouncycastle.cms.jcajce.JceKeyTransEnvelopedRecipient.getRecipientOperator(Unknown Source) at org.bouncycastle.cms.KeyTransRecipientInformation.getRecipientOperator(Unknown Source) at org.bouncycastle.cms.RecipientInformation.getContentStream(Unknown Source) And this is the code I use for it: RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias))); if (recipient != null) { log.info<http://log.info>("recipient!=null getting trans"); JceKeyTransEnvelopedRecipient trans=new JceKeyTransEnvelopedRecipient((PrivateKey)jcaProvider.getKeystore().getKey(alias,jcaProvider.getPwd().toCharArray())); trans.setMustProduceEncodableUnwrappedKey(true); trans.setProvider(provider); log.info<http://log.info>("returning content!"); CMSTypedStream cmsTs= recipient.getContentStream(trans); return cmsTs.getContentStream(); } Still don’t understand why it works only on a node since it seems a problem with keys…any ideas? Thank you