Java 9中的SunPKCS11提供程序 [英] SunPKCS11 provider in Java 9

问题描述

在Java 8之前，SunPKCS11提供程序已加载如下：

Up to Java 8 the SunPKCS11 provider was loaded like this:

Provider provider = new sun.security.pkcs11.SunPKCS11 (new ByteArrayInputStream (configFile.getBytes ()));
Security.addProvider (provider);

configFile 是带有配置参数的String 。因此，如果应用程序需要使用多个连接的智能卡，它可以创建多个提供程序。要访问每个提供程序，使用的名称是SunPKCS11-，后跟我们在配置中指示的名称。

configFile is a String with the configuration parameters. So, if the application needed to work with several connected smart cards it could create multiple providers. To access each provider the name used was "SunPKCS11-" followed by the name we indicated in the configuration.

在Java 8中， sun。 security.pkcs11.SunPKCS11 类已在JDK中删除。所以，我不得不通过反射来编写前一个调用。

In Java 8, the sun.security.pkcs11.SunPKCS11 class was removed in the JDK. So, I had to program the previous call by reflection.

Java 9中PKCS＃11提供程序的操作看起来非常不同：

The operation of the PKCS#11 provider in Java 9 seems very different:

• SunPKCS11 构造函数已更改为空构造函数。配置是通过configure方法加载的，因此它必须位于磁盘上的文件中，我不能再通过流将其加载到字符串。

• The SunPKCS11 constructor has been changed to an empty one. The configuration is loaded by the "configure" method, so it is mandatory that it is in a file on disk and I can no longer load it through a stream to a string.

如果我们尝试使用反射，则会出现以下警告：

If we try to use the reflection the following warnings appear:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by PruebaTarjeta (file:/C:/temp/pkcs11java9/classes/) to constructor
sun.security.pkcs11.SunPKCS11()
WARNING: Please consider reporting this to the maintainers of PruebaTarjeta
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

• 在Java 9中，SunPKCS11提供程序是自动生成的，位于加密提供程序列表中。它可以从列表中获取并进行配置。问题是您只能在列表中加载一个PKCS＃11提供程序。 Java 9文档表明我们可以通过SunPKCS11-获得PKCS＃11提供程序，后跟我们在配置中指出的名称，但事实并非如此。如果我们查看提供商列表，唯一的一个是SunPKCS11，因此我不能为每个智能卡提供一个提供商。


• In Java 9, a SunPKCS11 provider is automatically generated and is in the list of cryptographic providers. It can be obtained from the list and configured. The problem is that you can only have one PKCS#11 provider loaded in the list. The Java 9 documentation indicates that we can get the PKCS#11 provider with "SunPKCS11-" followed by the name we indicated in the configuration, but it's not true. If we look at the list of providers the only one is "SunPKCS11" so I can not have one provider per smart card.

这也发生在别人身上？任何解决方案？

Do this also happen to someone else? Any solution?

推荐答案

我注意到了 configure ：

I noticed looking at the javadoc for configure:




将提供的配置参数应用于此提供程序实例并返回已配置的提供程序。请注意，如果无法就地配置此提供商，则将创建并返回新的提供商。因此，呼叫者应始终使用返回的提供者。

Apply the supplied configuration argument to this provider instance and return the configured provider. Note that if this provider cannot be configured in-place, a new provider will be created and returned. Therefore, callers should always use the returned provider.

这向我表明原型模式，并且用于创建多个提供者的新控制流程将类似于：

This indicates to me that the prototype pattern is being used here, and that the new control flow for creating multiple providers would be something like:

Provider prototype = Security.getProvider("SunPKCS11");
Provider provider1 = prototype.configure(...);
Provider provider2 = prototype.configure(...);
...





---





至于使用直接而不是文件名的参数，我做了一些挖掘源代码并在 sun.security.pkcs11.Config 中找到了这个：

Config(String fn) throws IOException {
    this.filename = fn;
    if (filename.startsWith("--")) {
        // inline config
        String config = filename.substring(2).replace("\\n", "\n");
        reader = new StringReader(config);

注意带有 filename.startsWith（ - ）的行，此文件名直接来自 configure 的参数。所以你应该能够将配置参数作为字符串传递，只要你用 - 启动字符串，然后分隔你的 key = value 与 \ n 配对。 （我目前无法对此进行测试）。

Note the line with filename.startsWith("--"), this filename comes directly from the argument to configure. So you should be able to pass in the configuration arguments as a string as long as you start the string with --, and then delimiting your key=value pairs with \n. (I am not currently able to test this though).

但是，我无法在任何地方公开记录这一事实，因此它可能会有所变化，因为它对不同的提供商的工作方式不同，即 自担风险使用！ 。

However, I can't find this fact publicly documented anywhere, so it might be subject to change, as well as it working differently for different providers, i.e. use at own risk!.

这篇关于Java 9中的SunPKCS11提供程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！