您看，我有一个applet，它根据RSApkcs11令牌中找到的私钥解密一些信息。
在巴西，现在有一些包含2048位私钥的新证书。也有带有常规1024位的旧型号。
到目前为止，我的应用程序运行良好。我使用的是1024位证书，因此无需理会。但是，现在我要测试一些新证书，它会因标题错误而崩溃：
PKCS11Exception：CKR_KEY_FUNCTION_NOT_PERMITTED
顺便说一句：它仍然适用于1024位。
在sun.applet.AppletPanel.run（未知源）处，在java.lang.Thread.run（未知源）处，原因：sun.security.pkcs11.wrapper.PKCS11异常：在sun.security.pkcs11.wrapper.PKCS11.C_DecryptInit处CKR_KEY_FUNCTION_NOT_PERMITTED （本机方法）在sun.security.pkcs11.P11RSACipher.implInit（P11RSACipher.java:193）处的sun.security.pkcs11.P11RSACipher.initialize（P11RSACipher.java:260）
我使用标准的Java安全名称空间。我在某个地方读到Java在政策上有局限性，这与美国如何对待安全性有关，我不知道...
有什么关系吗？
我知道我必须使用bouncyCastle提供程序，但是我只是想知道...
对于所有问题，BC无法使用P11PrivateKey，因为它使用硬件来签名或加密。
结论：
正如我发现的那样，多亏了owlstead，在ekenken属性中，关键不是那个海豚的钥匙...天哪...
一个不起作用的：
序列号：（...）
颁发给：（...）
颁发者：（...）
有效期自：（...）
有效期至：（...）
预期用途：客户端身份验证，安全电子邮件
密钥大小：2048位
容器名称：（...）
模量：（...）
密钥规范：AT_KEYSIGNATURE
另一个有效的方法是：
序列号：（...）
颁发给：（...）
颁发者：（...）
有效期自：（...）
有效期至：（...）
预期用途：安全电子邮件，客户端身份验证，智能卡登录
密钥大小：1024位
容器名称：（...）
模数：（...）
密钥规格：AT_KEYEXCHANGE
默认密钥容器：是
辅助密钥容器：是
我知道AT_KEYEXCHANGE本身并不意味着可以解密，但是拥有AT_KEYSIGNATURE意味着只能用于该海豚。正如我已经测试过的那样，它可以用于签名...
它与Java密钥长度无关。尽一切可能，Java可能甚至不知道密钥大小，因为密钥保留在硬件令牌上。将属性CKA_ENCRYPT设置为CK_FALSE的CK_BBOOL值的可能性更大。
从PKCS＃11 v2.20（cryptoki）
CKR_KEY_FUNCTION_NOT_PERMITTED：试图将密钥用于加密目的，即密钥属性未设置为允许这样做。例如，要使用密钥执行加密，该密钥必须将其CKA_ENCRYPT属性设置为CK_TRUE（该密钥必须具有CKA_ENCRYPT属性这一事实意味着该密钥不能为私钥）。此返回值的优先级低于CKR_KEY_TYPE_INCONSISTENT。