Issues with strategy used by org.mozilla.jss.CryptoManager#findPrivKeyByCert to find matching Private Key

[Jaime Hablutzel Egoavil]

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

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:

/*
* 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?


--
Jaime Hablutzel - RPC 987608463

[helpcrypto helpcrypto]

On Thu, Apr 11, 2013 at 11:59 PM, Jaime Hablutzel Egoavil <
hablu...@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".

> 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.

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)) {
...

[Jaime Hablutzel Egoavil]

Thanks for your answer, but does the Keystore implementation support
hardware tokens like smart 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.

>
>



On Fri, Apr 12, 2013 at 4:54 AM, helpcrypto helpcrypto <helpc...@gmail.com
> wrote:

> On Thu, Apr 11, 2013 at 11:59 PM, Jaime Hablutzel Egoavil <
> hablu...@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.

> --
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto

[helpcrypto helpcrypto]

On Fri, Apr 12, 2013 at 7:33 PM, Jaime Hablutzel Egoavil <
hablu...@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.

Yes, we have smartcards and use them with Java.
A little example: http://stackoverflow.com/a/8429162

Nice day!

[Jaime Hablutzel Egoavil]

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 <

[helpcrypto helpcrypto]

On Tue, Apr 16, 2013 at 7:27 PM, Jaime Hablutzel Egoavil <
hablu...@gmail.com> wrote:

> 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
>

When you register an smartcard on Mozilla products, modules are written in
secmod.db
If you use SunPkcs11 provider you can get those modules and use the
certificates whitin a card.
You can use "installed" certificates too.

dll locations will be the minor problem you will find when working with
this...lovely world!

Dont hesitate to contact me if needed.

[Jaime Hablutzel Egoavil]

Then, this documentation is wrong, isn't it?

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.

[helpcrypto helpcrypto]

Maybe im wrong, but probably it is.

Anyhow, i suggested "another approach" to use smartcardst, no matter if JSS
documentation is up to date or not.


On Fri, Apr 19, 2013 at 6:48 PM, Jaime Hablutzel Egoavil <