Are you talking about PKCS11 bridge for a standard PKCS#11 module?. I was thinking in accesing smartcards configured in NSS database, so I don't have to deal with the location of the dll module. I'm sorry I'm a little confused
On Tue, Apr 16, 2013 at 11:42 AM, helpcrypto helpcrypto < helpcry...@gmail.com> wrote: > On Fri, Apr 12, 2013 at 7:33 PM, Jaime Hablutzel Egoavil < > hablutz...@gmail.com> wrote: > > > Thanks for your answer, but does the Keystore implementation support > > hardware tokens like smart card??, > > > > It does, if you have a pkcs#11 library for your card. > > > > https://developer.mozilla.org/en-US/docs/JSS > > > > Java provides a JCE provider called SunPKCS11, see Java PKCS#11 Reference > > > Guide< > > > http://download.java.net/jdk7/docs/technotes/guides/security/p11guide.html > > >, > > > SunPKCS11 can be configured to use NSS module as the crytographic > > provider. > > > If you are planning to just use JSS JCE provider as a bridge to NSS's > > FIPS > > > validated PKCS#11 module, then the SunPKCS11 JCE provider may do all > that > > > you need. Note that Java 1.5 claimed no FIPS compliance, and Java 1.6< > > > http://java.sun.com/javase/6/docs/technotes/guides/security/enhancements.html > > > > or > > > higher needs to be used. *A current limitation to the configured > > > SunPKCS11-NSS bridge configuration is if you add a PKCS#11 module to > the > > > NSS database such as for a smartcard, you won't be able to access that > > > smartcard through the SunPKCS11-NSS bridge. * If you use JSS, you can > > > easily get lists of modules and tokens that are configured in the NSS > DB > > > and freely access all of it. > > > > furthermore, check this: > > 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. > > > > Yes, we have smartcards and use them with Java. > A little example: http://stackoverflow.com/a/8429162 > > Nice day! > > > > On Fri, Apr 12, 2013 at 4:54 AM, helpcrypto helpcrypto < > > helpcry...@gmail.com > > > wrote: > > > > > On Thu, Apr 11, 2013 at 11:59 PM, Jaime Hablutzel Egoavil < > > > hablutz...@gmail.com> wrote: > > > > > > > Hi, I have a hardware token accesible via PKCS#11 which is storing > > > private > > > > keys and certificate like this : > > > > > > > > certificate A, CKA_ID: 1234 > > > > certificate B, CKA_ID: 1234 > > > > > > > > > > Hi Jaime. > > > In our case CKA_ID=hash(public key)...i think sha1. > > > This way its much more "friendly". > > > > > > > > Yes, that would be a wise choose for CKA_ID but as I told you our > provider > > is doing that and the PKCS#11 spec doesn't push him to do otherwise. > > > > > > > > > > > > > priv key for certificate A, CKA_ID: 1234 > > > > priv key for certificate B, CKA_ID: 1234 > > > > > > > > Well, then I get 'certificate A' and > > > > call org.mozilla.jss.CryptoManager#findPrivKeyByCert passing it as a > > > > parameter and I can get 'priv key for certificate B' instead of 'priv > > key > > > > for certificate A' because of the way findPrivKeyByCert is > implemented > > > > depending on 'PK11_MatchItem' method from NSS which in its > > documentation > > > > states: > > > > > > > > > > We move from jss to KeyStore and we are happier since then. > > > > > > > > > > > > > > /* > > > > * given a PKCS #11 object, match it's peer based on the KeyID. > > searchID > > > > * is typically a privateKey or a certificate while the peer is the > > > > opposite > > > > */ > > > > > > > > As long as now it could seem a problem with the hardware token > > > > manufacturer, repeating CKA_IDs for objects, but then if you see > > > > PKCS#11v2.20 spec, in *10.6.3 X.509 public key certificate objects*: > > > > > > > > *The CKA_ID attribute is intended as a means of distinguishing > multiple > > > > > publickey/ > > > > > **private-key pairs held by the same subject (whether stored in the > > > same > > > > > token or not). > > > > > **(Since the keys are distinguished by subject name as well as > > > > identifier, > > > > > it is possible that keys for different subjects may have the same > > > > CKA_IDvalue without introducing any ambiguity.) > > > > > ** > > > > > **It is intended in the interests of interoperability that the > > subject > > > > > name and key identifier > > > > > **for a certificate will be the same as those for the corresponding > > > > > public and private keys > > > > > **(though it is not required that all be stored in the same token). > > > > > However, Cryptoki does > > > > > **not enforce this association, or even the uniqueness of the key > > > > > identifier for a given > > > > > **subject; in particular, an application may leave the key > identifier > > > > > empty.* > > > > > > > > > > > > So NSS should not depend only on CKA_ID, but it should use > CKA_Subject > > > too, > > > > but if you see the last bold section these attributes are not 100% > > > > trustable. > > > > > > > > I see this as a implementation problem, maybe after finding a > 'matching > > > > item' NSS should check if it actually matches, and if it isn't it > > should > > > > resort to another strategy for finding the matching item. > > > > > > > > What do you think? > > > > > > > > > > Just an opinion, but forget JSS and use Java Provider and Java > Keystore;) > > > > > > entries = ks.aliases(); > > > while (entries.hasMoreElements()) { > > > alias = entries.nextElement(); > > > //Check if its a cert with a private key > > > if (ks.isKeyEntry(alias)) { > > > ... > > > -- > > > dev-tech-crypto mailing list > > > dev-tech-crypto@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/dev-tech-crypto > > > > > > > > > > > -- > > Jaime Hablutzel - RPC 987608463 > > -- > > 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 > -- Jaime Hablutzel - RPC 987608463 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
