CODEWITHSUNDEEP
javacryptography
marcelo-ferraz
marcelo-ferraz

Reputation: 3257

PKCS11Exception: CKR_KEY_FUNCTION_NOT_PERMITTED

You see, I have an applet that decrypts some info based on the RSA private key that is found in a pkcs11 token.
In Brazil, there are now, some new certificates that contains a 2048 bit privatekey. There are old models with regular 1024 bit, as well.
Until now, my app was working fine. I was using 1024bit certificates, so no bother. But now that I have some new certificates to test, it crashes with the title error:

PKCS11Exception: CKR_KEY_FUNCTION_NOT_PERMITTED

btw: it is still working for the 1024 bits.

at sun.applet.AppletPanel.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_KEY_FUNCTION_NOT_PERMITTED at sun.security.pkcs11.wrapper.PKCS11.C_DecryptInit(Native Method) at sun.security.pkcs11.P11RSACipher.initialize(P11RSACipher.java:260) at sun.security.pkcs11.P11RSACipher.implInit(P11RSACipher.java:193)

I use the standart java security namespace. I've read somewhere that Java comes with a limitation, on the policies, something related to how US treat security, I don't know...
Is there any relation?
I am aware that I must use the bouncyCastle provider, but I am just wondering...

For all that matters, BC cannot use a P11PrivateKey, as it uses the hardware to sign or encrypt.

Conclusion:

As I`ve found out, thanks to owlstead, in the etoken properties, the key was not made for that porpouse... god...

The one that does not work:

Serial number: (...)
Issued to: (...)
Issued by: (...)
Valid from: (...)
Valid until: (...)
Intended purposes: Client Authentication,Secure Email
Key size: 2048 bits
Container name: (...)
Modulus: (...)
Key specification: AT_KEYSIGNATURE

The other one, the one that works:

Serial number: (...)
Issued to: (...)
Issued by: (...)
Valid from: (...)
Valid until: (...)
Intended purposes: Secure Email,Client Authentication,Smart Card Logon
Key size: 1024 bits
Container name: (...)
Modulus: (...)
Key specification: AT_KEYEXCHANGE
Default Key Container: Yes
Auxiliary Key Container: Yes

I know that AT_KEYEXCHANGE by itself does not mean that can decrypt, but having AT_KEYSIGNATURE means that can only be used for that porpouse. And as i've tested that one works for signatures...

Upvotes: 1

Views: 9694

Answers (2)

Martin Paljak
Martin Paljak

Reputation: 4142

You are mixing PKCS#11 (CKR_XXX) and CryptoAPI (AT_XXX). You can use pkcs11-tool or pkcs11-dump (google) to list the properties of objects you have.

Upvotes: 3

Maarten Bodewes
Maarten Bodewes

Reputation: 93948

It has nothing to do with Java key length. For all that's worth, Java may not even know the key size as the key remains on the hardware token. It's much more likely that the attribute CKA_ENCRYPT is set to the CK_BBOOL value of CK_FALSE.

From PKCS#11 v2.20 (cryptoki)

CKR_KEY_FUNCTION_NOT_PERMITTED: An attempt has been made to use a key for a cryptographic purpose that the key’s attributes are not set to allow it to do. For example, to use a key for performing encryption, that key must have its CKA_ENCRYPT attribute set to CK_TRUE (the fact that the key must have a CKA_ENCRYPT attribute implies that the key cannot be a private key). This return value has lower priority than CKR_KEY_TYPE_INCONSISTENT.

Upvotes: 5

Related Questions