如何为 JavaTM 密码体系结构实现 Provider

 

上次修改时间： 1998 年 9月 21 日

简介
本文档适用的读者
相关文档

 
Engine 类及相应的 SPI 类

 

 

实现和集成 Provider 的步骤
步骤 1： 编写服务实现代码
步骤 2： 命名 Provider
步骤 3： 编写“主类”（Provider 的子类）
步骤 4： 编译代码
步骤 5： 准备测试：安装 Provider
步骤 6： 编写和编译测试程序
步骤 7： 运行测试程序
步骤 8： 编写 Provider 及其支持服务的文档
步骤 9： 向客户提供类文件和文档

 
更多的实现细节和要求
别名
服务间的依赖关系
缺省初始化
缺省密钥对生成器的参数要求
签名格式
DSA 接口及其所需的实现
RSA 接口及其所需的实现
其它算法类型的接口
算法参数规范接口和类
密钥工厂所需的密钥规范接口和类
添加新的对象标识符

 
附录 A：“SUN”Provider 的主类

 
附录 B：java.security 主属性文件

简介

   

JDK 1.1 引入了密码服务提供者 （简称为“提供者”）的概念。它是指一个（或一组）包，用于提供 JDK 安全 API 的密码子集的具体实现

例如，在 JDK 1.1 中，提供者可包含一个或多个数字签名算法、报文摘要算法及密钥生成算法的实现。JDK 1.2 添加了五类附加服务：密钥工厂、密钥仓库的创建与管理；算法参数管理；算法参数的生成和证书工厂。它还允许提供者提供随机数生成 (RNG) 算法。在以前的版本中，RNG 并不是基于提供者的；某一特定算法是硬编码在 JDK 中的。

要使用密码功能的程序，可以只请求一个实现特殊服务（例如 DSA 签名算法）的特殊类型对象（例如 Signature 对象），并从已安装的某个提供者那里获得该对象的实现方法。如果需要获得特定提供者的实现，则程序可以按名字请求该提供者及所需的服务。

每次安装 JDK 都将安装一个或多个提供者包。用户可能会使用不同的提供者配置自己的运行时环境，并为它们指定一个优先顺序。优先顺序是当没有请求特定提供者时，为获得请求算法而查找提供者的顺序。

Sun 版本的 Java 运行时环境都带有一个名为“SUN”的缺省标准提供者。其它的 Java 运行时环境可能不一定提供“SUN”提供者。“SUN”提供者包包括：

用户可以静态或动态地添加新的提供者。也可以查询当前所安装的提供者。

不同的实现可能有不同的特性。有些可能是基于软件的，而其它的可能是基于硬件的。有些可能是独立于平台的，而其它的可能是依赖于特定平台的。 可以得到一些提供者的源代码用于复审和评估，也有一些是无法得到的。

本文档适用的读者

本文档是针对有经验的程序员编写的，他们需要创建自己的提供者包以提供密码服务实现。本文档叙述了如何将你使用的提供者集成到 JDK Security 中，以便使 JDK 安全 API 客户请求算法和其它服务时能找到它们。仅使用 JDK 安全 API 访问已有密码算法和其它服务的程序员不必阅读该文档。

相关文档

本文档假定您已经阅读过 Java 加密体系结构 API 规范与参考。

本文档也讨论了 JDK 安全 API 中的各种类与接口。相关的安全 API 包的完整参考文档可在如下位置找到：

引擎 (Engine) 类及相应的服务提供者接口 (SPI) 类

“引擎类”以抽象的方式（没有具体的实现）来定义密码服务。

密码服务总是同特定的算法或类型密切相关。它提供密码操作（例如在数字签名或报文摘要中），产生或提供密码操作所需的密码材料（密钥或参数），或者以安全的方式产生封装密钥（可用于密码操作）的数据对象（密钥仓库或证书）。例如 Signature 和 KeyFactory 就是两个引擎类。Signature 类提供了对数字签名算法功能的访问。 DSA KeyFactory 则按某种可被 DSA Signature 对象的 initSign 或 initVerify 方法使用的格式提供 DSA 私钥或公钥（利用其编码或透明规范）。

Java 密码体系结构包括 JDK 1.2 Security 包中同密码有关的类，包括引擎类。该 API 的用户通过请求和利用引擎类的实例来执行相应的操作。下面是 JDK 1.2 中定义的引擎类：

注意： 生成器”使用新内容创建对象，而“工厂”利用现有的材料（例如编码）来创建对象。

引擎类提供了特定类型密码服务（与特殊的密码算法无关）功能的接口。它定义了允许应用程序访问其提供的特定类型密码服务的 “应用程序接口” (API) 方法。实际的实现（来自一个或多个提供者）是对指定算法的实现。例如，Signature 引擎类提供了对数字签名算法功能的访问。 在 SignatureSpi 子类（参见下文）中提供的实际实现将是针对特定种类算法的实现，例如 SHA1 with DSA、SHA1 with RSA 或 MD5 with RSA。

引擎类提供的 API 是按照“服务提供者接口”(SPI) 实现的。也就是说，对于每个引擎类，都有一个相应的抽象 SPI 类，它定义了密码服务提供者必须实现的服务提供者接口方法。

引擎类实例（即“API 对象”）封装（作为一个私有域）了相应的 SPI 类实例（即“SPI 对象”）。所有 API 对象的 API 方法都被声明为“终态”，并且它们的实现都调用相应被封装的 SPI 对象的 SPI 方法。引擎类的（及其相应 SPI 类的）实例是通过调用引擎类的 getInstance  fatory 方法而创建的。

SPI 类的名字与相应引擎类的名字相同，后缀为“Spi”。例如，同 Signature 引擎类相应的 SPI 类是 SignatureSpi 类。

每个 SPI 类都是抽象类。要为特定算法提供特殊类型服务的实现，提供者必须子类化相应的 SPI 类并提供所有抽象方法的实现。

另一个引擎类的示例就是 MessageDigest 类，它提供对报文摘要算法的访问。在 MessageDigestSpi 子类中，它的实现可能是各种报文摘要算法（例如 SHA-1、MD5 或 MD2）的实现。

最后一个例子，KeyFactory 引擎类支持从不透明密钥向透明密钥规范的转换，反之亦然（参见密钥工厂所需的密钥规范接口和类）。 在 KeyFactorySpi 子类中提供的实际实现将是特定类型密钥（例如 DSA 公钥和私钥）的实现。

实现和集成 Provider 的步骤

实现提供者并将它集成到 JDK Security 中的步骤如下所示：

步骤 1： 编写服务实现代码

首先要做的是编写代码，以对所要支持的密码服务提供特定于算法的实现。

在 JDK 1.2 中，用户可以提供签名、报文摘要、密钥对生成和（伪）随机数生成算法，也可以提供密钥、证书工厂和密钥仓库的创建与管理，算法参数管理及算法参数生成等服务。

对于每项密码服务，均必须创建相应 SPI 类的子类：SignatureSpi、MessageDigestSpi、KeyPairGeneratorSpi、SecureRandomSpi、AlgorithmParameterGeneratorSpi、AlgorithmParametersSpi、KeyFactorySpi、CertificateFactorySpi或KeyStoreSpi （参见“Engine 类及相应的 SPI 类”）。

在子类中，您需要：

  1. 提供抽象方法的实现，其名字通常以“engine”开头。详细信息，请参阅更多的实现细节和要求。
  2. 确保有不带任何参数的公用构造函数。原因如下：当某一服务被请求时，JDK Security 将查找实现该服务的子类，它是被“主类”中的属性指定的（参见步骤 3）。然后，JDK Security 即创建同子类相关的类对象，并通过调用该类对象中的 newInstance 方法来创建该子类的实例。newInstance 方法需要子类具有一个不带任何参数的公用构造函数。


    3. 如果子类没有任何构造函数，则将自动创建缺省不带参数的构造函数。但如果子类已定义了构造函数，则必须显式地定义不带参数的公用构造函数。

步骤 2： 命名 Provider

请为提供者命名。客户应用程序可利用该名字引用您的 provider。

步骤 3： 编写“主类”（Provider 的子类）

第三步需要创建 Provider 类的子类。

子类应该是 final 类，其构造函数应该

主类属性设置的其它示例，参见附录 A 以查看当前 JDK 1.2 Sun.java 源文件。它将说明 Sun 类构造函数如何设置“SUN”提供者的所有属性值。

注意：Provider 子类可以从任何地方获取自己的信息。因此，该信息可在程序中硬性编入，也可在运行时获得（例如从文件获得）。

步骤 4： 编译代码

创建完实现代码（步骤 1），为提供者命名（步骤 2），然后创建主类（步骤 3）之后，可以用编译器对文件进行编译。

步骤 5： 准备测试：安装 Provider

为了准备测试提供者，必须按照要使用它的客户所要采用的方式进行安装。当客户请求算法实现时，这种安装方式即可帮助 JDK Security 找到它们。

安装提供者分为两部分：provider 包类的安装和配置。

安装 Provider 类

首先要使类可用，以便需要时能找到它们。可以按 JAR (Java ARchive) 文件或 ZIP 文件的形式提供 provider 类。

有两种安装 provider 类的方法：

配置 Provider

下一步就是将该提供者添加到被认可的 providers 列表中。这可通过编辑 JDK 的 lib/security（在 Windows 中为 lib\security）目录下的 java.security 文件来静态完成。这样，如果 JDK 安装在 jdk1.2 目录下, 则文件为：
     
  • jdk1.2/lib/security/java.security (Solaris)
  • jdk1.2\lib\security\java.security (Windows)
对于每个提供者, 该文件都应有如下形式的声明： 
    security.provider.n=masterClassName
该语句声明了一个提供者并指定了它的优先顺序 n。优先顺序是当没有请求特定提供者时，为获得请求算法而查找提供者的顺序。优先顺序是从 1 开始的：1 享有最大优先权，紧接着是 2，依此类推。

masterClassName 必须指定提供者的“主类”的完整名，这是在步骤 3 中实现的。该“主类”始终是 Provider 类的子类。

安装 JDK 时，将包括一个内置（缺省）提供者，即“SUN”。java.security 文件仅提供如下提供者规范： 

    security.provider.1=sun.security.provider.Sun
（记住“SUN”提供者的主类是 sun.security.provider 包中的 Sun 类。）

假定主类是 COM.acme.provider 包中 Acme 类，并且您想使自己的提供者优先顺序为 2。为此，请在 java.security 文件中有关“SUN” 提供者的一行下添加如下行： 

    security.provider.2=COM.acme.provider.Acme
注意：也可动态注册提供者。为此，可以编写一个程序（例如步骤 7中编写的测试程序）调用 Security 类中的 addProvider 方法或 insertProviderAt 方法。这种类型的注册不是持久的且只能由“可信任”的程序完成。参见 Java 加密体系结构 API 规范与引用的 Security 类部分。

步骤 6： 编写和编译测试程序

用户可以编写和编译一个或多个测试程序来测试提供者与安全 API 的结合及算法的正确性。为此，需要创建所需的支持文件，例如用于测试将被散列或签名的数据的文件。

程序首先应进行的测试是确保能够发现提供者，并且最好能发现其名字、版本号和附加信息。为此，可以编写如下代码（用您的 provider 名来代替“MyPro”名）： 

    import java.security.*;

    Provider p = Security.getProvider("MyPro");

    System.out.println("MyPro provider name is " + p.getName());
    System.out.println("MyPro provider version # is " + p.getVersion());
    System.out.println("MyPro provider info is " + p.getInfo());
下一步应确保发现服务。例如，如果已实现 SHA-1 报文摘要算法，则使用如下代码（仍用您的 provider 名代替“MyPro”）即可确保服务在被请求时能被发现： 
    MessageDigest sha = MessageDigest.getInstance("SHA", "MyPro");

    System.out.println("My MessageDigest algorithm name is " +
        sha.getAlgorithm());
调用 getInstance 时，如果没有指定提供者名，则将按优先顺序（参见配置 Provider）查找所有注册的提供者，直到发现实现该算法的某个提供者。

步骤 7： 运行测试程序

现在可以运行测试程序。调试代码后可继续所需的测试。如果 JDK 安全 API 找不到您的算法，则检查上述步骤以确保它们的正确性。

步骤 8： 编写 Provider 及其支持服务的文档

现在为客户编写文档。至少，您必须指定： 此外，文档还应提供客户感兴趣的其它内容（例如所有缺省算法参数）。

报文摘要

对于每个报文摘要算法，请声明您的实现是否可复制。这在技术上是不必要的，但可使客户知道中间散列是否可复制，从而节省客户时间和代码。不知道报文摘要实现是否可复制的客户可试着复制“报文摘要”对象并捕获潜在的异常，从而知道哪些实现可复制。如下例所示： 
　
try {
   // try and clone it
    /* compute the hash for i1 */
    sha.update(i1);
    byte[] i1Hash = sha.clone().digest();

    /* compute the hash for i1 and i2 */
    sha.update(i2);
    byte[] i12Hash = sha.clone().digest();

    /* compute the hash for i1, i2 and i3 */
    sha.update(i3);
    byte[] i123Hash = sha.digest();
} catch (CloneNotSupportedException cnse) {
  // have to use an approach not involving cloning
}
其中

签名算法

要实现签名算法，应编写签名（由 sign 方法生成）编码格式的文档。例如，由“SUN”提供者提供的 SHA1withDSA 签名算法将签名编码为符合 ASN.1 SEQUENCE 标准的两个整数 r 和 s。

随机数生成 (SecureRandom) 算法

对于随机数生成算法，应当给出“随机”性的信息。当随机数生成器是自带种子时，还应给出种子的质量。同时应注意当 SecureRandom 对象（以及封装的 SecureRandomSpi 实现对象）序列化恢复时会出现什么现象：如果对恢复对象的 nextBytes 方法（它调用封装的 SecureRandomSpi 对象的 engineNextBytes 方法）的调用得到与原对象一样的（随机的）字节，就应通知用户：如果这不是所希望的结果的，就应调用其 setSeed 方法来播种随机恢复对象。

密钥对生成器

每个提供者都应为密钥对生成器算法提供一个缺省的初始值并写入文档，以防客户没有（通过调用 initialize 方法）明确初始化密钥对生成器。例如，“SUN”提供者采用 1024 位大小（长度）的缺省模数。

密钥工厂

提供者应将其密钥工厂支持的所有密钥规格写入文档。

证书工厂

提供者应将工厂能生成的证书类型（包括版本号，如果有关）写入文档。

密钥仓库

提供者应将所有有关密钥仓库实现的信息写入文档。

算法参数生成器

每个提供者都应该提供一个缺省的初始值并写入文档，以防客户没有（通过调用 AlgorithmParameterGenerator 引擎类的 init 方法）明确初始化算法参数生成器。 例如，对 DSA 参数的生成，“SUN”提供者采用 1024 位大小的缺省模数。

步骤 9：向客户提供类文件和文档

最后一步是采用适当的形式（类文件、zip 文件、JAR 文件等）和方法（web 下载、软盘、电子邮件等)向客户提供类文件和文档。

更多的实现细节和要求

别名

Java 加密体系结构 API 规范与参考中的附录 A 对许多密码算法和类型定义了唯一正式的“标准名称”。

例如，“MD5”是 RFC 1321 中的 RSA DSI 定义的报文摘要算法 RSA-MD5 的标准名称。

在 JDK 1.2 中有一套走样机制，可以使客户引用算法和类型时能用别名而不是标准名称。 例如，“SUN”提供者的主类 (Sun.java) 为标准名称为“SHA1withDSA”的算法定义了别名 "SHA1/DSA"。 因此，以下声明是等效的： 

    Signature sig = Signature.getInstance("SHA1withDSA", "SUN");

    Signature sig = Signature.getInstance("SHA1/DSA", "SUN");
别名可以在“主类”中定义（参见步骤 3 ）。要定义别名，请创建下列名称的属性： 
    Alg.Alias.engineClassName.aliasName
此处 engineClassName 是引擎类的名称（例如 Signature），而 aliasName 是别名。该属性的值必须是要取别名的算法（或类型）的标准算法（或类型）名。

例如，“SUN”提供者通过设置名为 Alg.Alias.Signature.SHA1/DSA 的属性为标准名称为 “SHA1withDSA” 的签名算法定义别名“SHA1/DSA”，以获得 SHA1withDSA 的值。如下所示： 

    put("Alg.Alias.Signature.SHA1/DSA", "SHA1withDSA");
目前，“SUN”提供者定义的别名对所有客户都可用，无论客户请求哪个提供者。 例如，如果要创建名为“MyPro”的提供者来实现 SHA1withDSA 算法，则即使没有为其定义任何别名，也可由“SUN”定义的别名“SHA1/DSA”引用该提供者对 SHA1withDSA 的实现，如下所示： 
    Signature sig = Signature.getInstance("SHA1/DSA", "MyPro");

警告： 该走样机制有可能在将来的版本中变化或取消。

服务间的依赖关系

某些算法需要调用其它类型的算法。例如，签名算法经常要调用报文摘要算法来签写或校验数据。

如果要实现一种类型算法调用另一种算法，可执行下列方案之一：

  1. 为两者都提供自己的实现。
  2. 在对一种算法的实现中使用另一种算法的实例，后者由每个 JDK 中都将安装的缺省“SUN”提供者提供。例如，如果要实现调用报文摘要算法的签名算法，则可以通过如下调用得到一个实现 MD5 报文摘要算法的类的实例：
    3.     MessageDigest.getInstance("MD5", "SUN")
  3. 在对一种算法的实现中使用另一种算法的实例，后者由另一个专门的提供者提供。只有确信使用您的提供者的全部客户也同时安装有其它提供者时才应使用本方案。
  4. 在对一种算法的实现中使用另一种算法的实例，后者由另一个（未指定的）提供者提供。也就是说，可以按名称请求一个算法而无需指定任何特定的提供者，如下所示；
    5.     MessageDigest.getInstance("MD5")
    只有确信即将使用提供者的 Java 平台中至少已安装一个所请求算法（上例中的 MD5）的实现，这样做才是合适的。
这里给出几个有相互依赖关系的算法的常用类型：

签名和报文摘要算法

签名算法经常要调用报文摘要算法。例如，SHA1withDSA 签名算法要调用 SHA-1 报文摘要算法。

签名和（伪）随机数生成算法

签名算法要经常调用（伪）随机数生成算法。例如，为了生成 DSA 签名，需要调用这样的算法。

密钥对生成和报文摘要算法

密钥对生成经常要调用报文摘要算法。例如，DSA 密钥就是用 SHA-1 报文摘要算法生成的。

算法参数生成和报文摘要算法

算法参数生成器经常要调用报文摘要算法。例如，DSA 参数就是用 SHA-1 报文摘要算法生成的。

密钥仓库和报文摘要算法

为校验密钥仓库的完整性和确保密钥仓库没有被篡改，密钥仓库经常利用报文摘要算法来计算加密散列（此处“密钥”是用户提供的口令）。

密钥对生成算法和算法参数生成器

密钥对生成算法有时需要生成一组新的算法参数，它既可直接生成，也可通过调用算法参数生成器生成。

密钥对生成、算法参数生成和（伪）随机数生成算法

为了生成新的密钥对和可能与密钥相关联的一组新参数，密钥对生成算法可能需要种子。种子由 SecureRandom 对象来描述。 密钥对生成算法的实现可以自己生成密钥参数，也可以用算法参数生成器生成，这时候可用也可不用种子来初始化算法参数生成器。

算法参数生成器和算法参数

算法参数生成器的 engineGenerateParameters 方法必须返回一个 AlgorithmParameters 实例。

签名和密钥对生成算法或密钥工厂

如果要实现签名算法，则实现的 engineInitSign 和 engineInitVerify 方法将需要传入对基本算法有效的密钥（如 DSS 算法的 DSA 密钥）。为此，可执行下列方案之一：
  1. 创建实现相应接口的类（如 java.security.interfaces 包中实现 DSAPrivateKey 和 DSAPublicKey 接口的类），同时创建自己的密钥对生成器和/或密钥工厂（它们返回这些类型的密钥）。要求传递给 engineInitSign 和 engineInitVerify 的密钥是所实现的密钥的类型, 也就是从密钥对生成器或密钥工厂中生成的密钥的类型。也可以
  2. 从其它密钥对生成器和其它的密钥工厂接收密钥，只要它们是能使签名实现获得所需信息（例如私钥和公钥及密钥参数）的相应接口的实例。例如，DSS 签名类中的 engineInitSign 方法就能接收 java.security.interfaces.DSAPrivateKey 的实例所有私钥。

密钥仓库及密钥和证书工厂

密钥仓库的实现通常利用密钥工厂来解析存储在密钥仓库中的密钥，而密钥仓库中所存证书的解析则通过证书工厂进行。

缺省初始化

每个提供者均应提供（并写进文档）一个缺省的初始化值，以防客户没有明确初始化密钥对生成器或算法参数生成器。例如，对 DSA 参数的生成，“SUN” 提供者采用 1024 位大小的缺省初始值。

缺省密钥对生成器的参数要求

如果要实现密钥对生成器，则当客户没有指定参数时该实现应提供缺省参数。提供的文档（步骤 8 ）应说明缺省参数是什么。

例如，对 512、768 和 1024 位的密钥对的生成，“SUN”提供者中 DSA 密钥对生成器提供了一系列预先计算的 p、q 和 g 缺省值。对 1024 位 的 DSA 密钥对的生成，以下是可用的 p、q 和 g 缺省值： 

p = fd7f5381 1d751229 52df4a9c 2eece4e7 f611b752 3cef4400 c31e3f80
    b6512669 455d4022 51fb593d 8d58fabf c5f5ba30 f6cb9b55 6cd7813b
    801d346f f26660b7 6b9950a5 a49f9fe8 047b1022 c24fbba9 d7feb7c6
    1bf83b57 e7c6a8a6 150f04fb 83f6d3c5 1ec30235 54135a16 9132f675
    f3ae2b61 d72aeff2 2203199d d14801c7

q = 9760508f 15230bcc b292b982 a2eb840b f0581cf5

g = f7e1a085 d69b3dde cbbcab5c 36b857b9 7994afbb fa3aea82 f9574c0b
    3d078267 5159578e bad4594f e6710710 8180b449 167123e8 4c281613
    b7cf0932 8cc8a6e1 3c167a8b 547c8d28 e0a3ae1e 2bb3a675 916ea37f
    0bfa2135 62f1fb62 7a01243b cca4f1be a8519089 a883dfe1 5ae59f06
    928b665e 807b5525 64014c3b fecf492a
（此处给出的 p 和 q 值是质数生成标准生成的，采用 160 位种子： 
SEED：  8d515589 4229d5e6 89ee01e6 018a237e 2cae64cd
利用该种子，当计数器为 92 时此算法即查到 p 和 q。）

签名格式

如果要实现签名算法，则提供的文档（步骤 8）中应指定签名（由 sign 方法生成）编码的格式。

例如，由“SUN”提供者提供的 SHA1withDSA 签名算法将签名编码为如下两个 ASN.1 INTEGER 值的标准 ASN.1 序列：r 和 s，顺序如下： 

        SEQUENCE ::= {
                r INTEGER,
                s INTEGER }

DSA 接口及其所需的实现

为了方便程序员实现 DSA 服务，JDK 安全 API 包含如下接口（在 java.security.interfaces 包中）： 下面一节将讨论实现这些接口的要求。

DSAKeyPairGenerator 的实现

该接口已废弃。它曾用于让客户提供特定于 DSA 的参数，而不是用由实现所提供的缺省参数值。但在 JDK 1.2 中已不再使用；新的带 AlgorithmParameterSpec 参数的 KeyPairGenerator initialize 方法能让客户指定特定于算法的参数。

DSAParams 的实现

如果要实现 DSA 密钥对生成器，则需实现 DSAParams 的类来保存和返回p、q 和 g 参数。

如果要实现 DSAPrivateKey 和 DSAPublicKey 接口，则也需要实现 DSAParams。 DSAPublicKey 和 DSAPrivateKey 都扩展 DSAKey 接口，它包含一个必须返回 DSAParams 对象的 getParams 方法。详细信息，参见 DSAPrivateKey 和 DSAPublicKey 实现。

注意：JDK 中嵌入了一个 DSAParams 实现： java.security.spec.DSAParameterSpec 类。

DSAPrivateKey 和 DSAPublicKey 的实现

如果要实现 DSA 密钥对生成器或密钥工厂，则应创建类来实现 DSAPrivateKey 和 DSAPublicKey 接口。

如果实现了 DSA 密钥对生成器，generateKeyPair 方法（在 KeyPairGeneratorSpi 子类中）就会返回那些接口实现的实例。

如果实现了 DSA 密钥工厂，engineGeneratePrivate 方法（在您的 KeyFactorySpi 子类中）就会返回 DSAPrivateKey 实现的实例，而 engineGeneratePublic 方法将返回 DSAPublicKey 实现的实例。

同时， engineGetKeySpec 和 engineTranslateKey 方法需要传入的密钥是 DSAPrivateKey 或 DSAPublicKey 实现的实例。 由接口实现提供的 getParams 方法对于从密钥中获得和抽取参数并使用该参数（例如作为传给 DSAParameterSpec 构造函数的参数）将十分有用。DSAParameterSpec 构造函数被调用是为了用可用于为 DSA 初始化 KeyPairGenerator 对象的参数值来创建一个参数规范。

如果要实现 DSA 签名算法，则 engineInitSign 方法（在 SignatureSpi 子类中）需要传入一个 DSAPrivateKey，而 engineInitVerify 方法需要传入一个 DSAPublicKey。

请注意：DSAPublicKey 和 DSAPrivateKey 接口分别为 DSA 公钥和私钥定义了一个十分通用、不依赖于提供者的接口。 engineGetKeySpec 和engineTranslateKey 方法（在 KeyFactorySpi 子类中）能校验传入的密钥是否为提供者自己的 DSAPrivateKey 或 DSAPublicKey 实现的真正实例，即充分利用特定于提供者的实现细节。DSA 签名算法中的 engineInitSign 和 engineInitVerify 方法 （在您的 SignatureSpi 子类中）也是如此。

要知道实现 DSAPublicKey 和 DSAPrivateKey 接口的类需要实现什么方法，应首先注意下面的接口签名： 

  In the java.security.interfaces package:

    public interface DSAPrivateKey extends DSAKey,
                                     java.security.PrivateKey

    public interface DSAPublicKey extends DSAKey,
                                    java.security.PublicKey

    public interface DSAKey

  In the java.security package:

    public interface PrivateKey extends Key

    public interface PublicKey extends Key

    public interface Key extends java.io.Serializable
为了实现 DSAPrivateKey 和 DSAPublicKey 接口，必须直接或间接实现它所定义及由它所扩展的接口所定义的方法。

对于私钥，需要提供类来实现

  • DSAPrivateKey 接口中的 getX 方法；
  • java.security.interfaces.DSAKey 接口中的 getParams 方法，因为 DSAPrivateKey 扩展了 DSAKey。注意：getParams 方法返回 DSAParams 对象，因此必须要有一个 DSAParams 的实现。
  • java.security.Key 接口中的 getAlgorithm、getEncoded 和 getFormat 方法，因为 DSAPrivateKey 扩展了 java.security.PrivateKey，而PrivateKey 扩展了 Key。同样，对DSA 公钥，则需要提供类来实现
    • DSAPublicKey 接口中的 getY 方法；
    • java.security.interfaces.DSAKey 接口中的 getParams 方法，因为 DSAPublicKey 扩展了 DSAKey。注意：getParams 方法返回一个 DSAParams 对象，因此也应有一个 DSAParams 的实现。
    • java.security.Key 接口中的getAlgorithm、getEncoded和getFormat 方法，因为 DSAPublicKey 扩展了 java.security.PublicKey，而 PublicKey 扩展了 Key。

RSA 接口及其所需的实现

为了方便程序员实现 RSA 服务，JDK 安全 API 包含以下接口（在 java.security.interfaces 包中）： 下面一部分将讨论实现这些接口的要求。

RSAPrivateKey、 RSAPrivateCrtKey 和 RSAPublicKey 实现

如果要实现 RSA 密钥对生成器或密钥工厂，需要创建类来实现 RSAPrivateKey（和/或 RSAPrivateCrtKey） 和 RSAPublicKey 接口 （RSAPrivateCrtKey 是用中国余数定理 (CRT) 描述的 RSA 私钥的接口）。

如果要实现 RSA 密钥对生成器，generateKeyPair 方法（在 KeyPairGeneratorSpi 子类中）就应返回那些接口实现的实例。

如果要实现 RSA 密钥工厂，则 engineGeneratePrivate 方法（在 KeyFactorySpi 子类中）应返回 RSAPrivateKey （或 RSAPrivateCrtKey）实现的一个实例，而 engineGeneratePublic 应返回 RSAPublicKey 实现的一个实例。

同时，engineGetKeySpec 和 engineTranslateKey 方法需要传入的密钥是 RSAPrivateKey、RSAPrivateCrtKey 或 RSAPublicKey 实现的一个实例。

如果要实现 RSA 签名算法，则 engineInitSign 方法（在 SignatureSpi 子类中）需要传入一个 RSAPrivateKey 或 RSAPrivateCrtKey，而engineInitVerify 方法需要传入一个 RSAPublicKey。

请注意：RSAPublicKey、RSAPrivateCrtKey 和 RSAPrivateKey 接口为 RSA 公钥和私钥定义了一个十分通用的、不依赖于提供者的接口。 engineGetKeySpec 和 engineTranslateKey 方法（在 KeyFactorySpi 子类中）能校验传入的密钥是否为提供者自己的 RSAPrivateKey、RSAPrivateCrtKey 或 RSAPublicKey 实现的真正实例，即为了充分利用特定于提供者的实现细节。RSA 签名算法中的 engineInitSign 和 engineInitVerify 方法（在 SignatureSpi 子类中）也是如此。

要知道实现 RSAPublicKey、RSAPrivateCrtKey 和 RSAPrivateKey 接口的类需要实现什么方法，应首先注意下面的接口签名： 

  In the java.security.interfaces package:

    public interface RSAPrivateKey extends java.security.PrivateKey

    public interface RSAPrivateCrtKey extends RSAPrivateKey

    public interface RSAPublicKey extends java.security.PublicKey


  In the java.security package:

    public interface PrivateKey extends Key

    public interface PublicKey extends Key

    public interface Key extends java.io.Serializable
为了实现 RSAPrivateKey、RSAPrivateCrtKey 和 RSAPublicKey 接口，必须直接或间接实现它所定义的及由它所扩展的接口所定义的方法。

对于 RSA 私钥，需要提供类来实现

  • RSAPrivateKey 接口中的 getModulus 和 getPrivateExponent 方法；
  • java.security.Key 接口中的 getAlgorithm、getEncoded 和 getFormat 方法，因为 RSAPrivateKey 扩展了 java.security.PrivateKey，而 PrivateKey 扩展了 Key 。


    • 同样，对用中国余数定理 (CRT) 来描述的 RSA 私钥，需要提供类来实现

    • 以上列出的所有 RSA 私钥的方法，因为 RSAPrivateCrtKey 扩展了 java.security.interfaces.RSAPrivateKey。
    • RSAPrivateCrtKey 接口中的 getPublicExponent、getPrimeP、getPrimeQ、getPrimeExponentP、getPrimeExponentQ 和getCrtCoefficient 方法。


      • 对于 RSA 公钥，需要提供类来实现

      • RSAPublicKey 接口中的 getModulus 和 getPublicExponent 方法。
      • java.security.Key 在接口中的 getAlgorithm、getEncoded 和 getFormat 方法，因为 RSAPublicKey 扩展了 java.security.PublicKey，而 PublicKey 扩展了 Key。

其它算法类型的接口

如上所述，JDK 安全 API 所包含的接口为程序员实现 DSA 和 RSA 服务提供了方便。现在，该 API 还不为其它类型算法提供类似的接口。因此，用户必须定义自己的接口。

如果正在为不同的算法实现密钥对生成器，则应当用一个或多个 initialize 方法创建接口。当客户要提供特定于算法的参数而不是您的实现所提供的缺省参数时，可调用该方法。KeyPairGeneratorSpi 子类可实现这种接口

对于非 DSA 和非 RSA 算法的私钥和公钥，目前还没有与 DSA 算法的 DSAPrivateKey 和 DSAPublicKey 及RSA 算法的 RSAPrivateKey、RSAPrivateCrtKe 和 RSAPublicKey 相对应的 java.security.interfaces 接口。建议创建类似的接口并提供实现类。公钥接口应当扩展 PublicKey 接口。同样，私钥接口也应当扩展 PrivateKey 接口。

算法参数规范接口和类

算法参数规范透明地提供算法所用的参数集。

透明的参数规范意味着可以通过相应的规范类（例如，DSAParameterSpec 定义的可分别访问 p、q 和 g 参数的 getP，getQ 和 getG 方法）中定义的“get”方法之一来分别访问每个值。

这与不透明表示正好相反。该规范由 AlgorithmParameters 引擎类提供，后者中不能直接访问密钥信息值；只能得到与该参数集（通过 getAlgorithm ）以及与某种参数集编码（通过 getEncoded ）有关的算法名。

如果要提供对 AlgorithmParametersSpi、AlgorithmParameterGeneratorSpi 或 KeyPairGeneratorSpi 的实现，则必须利用 AlgorithmParameterSpec 接口，因为这些类中的每一个都包含带有 AlgorithmParameterSpec 参数的方法。这些方法需要决定传入了该接口的哪个实现，然后采取相应的操作。

JDK 1.2 包含 AlgorithmParameterSpec 的实现，即 DSAParameterSpec 类。如果是使用 DSA 算法参数，则可使用此类。如果对本来属于另一种类型算法的算法参数进行操作，则应提供适用于该种类型算法的 AlgorithmParameterSpec 实现。

JDK 1.2 定义了下列 java.security.spec 包中的算法参数规范接口和类：

AlgorithmParameterSpec 接口

AlgorithmParameterSpec 是一个与密码参数透明规范的接口。

这个接口不包含方法和常量。它的唯一作用是对所有的参数规范进行分组（并提供类型安全）。所有的参数规范都必须实现该接口。

DSAParameterSpec 类

该类（实现 AlgorithmParameterSpec 和 DSAParams 接口）指定了 DSA 算法所运用的参数集。它有下列方法： 
     public BigInteger getP()

     public BigInteger getQ()

     public BigInteger getG()
这些方法返回 DSA 算法参数：质数 p、亚质数 q 和基数 g。

这个类对多种 DSA 服务均有用，例如 DSA 签名、密钥对生成器和“SUN”提供者实现的算法参数类就使用了它。作为特例，算法参数实现必须包括对 getParameterSpec 方法的实现，该方法返回 AlgorithmParameterSpec。由“SUN”提供的 DSA 算法参数实现返回 DSAParameterSpec 类的实例。

密钥工厂所需的密钥规范接口和类

密钥工厂提供了不透明密钥（Key 类型）和密钥规范之间的双向转换。如果要实现密钥工厂，则需理解和使用密钥规范。在某些情况下，还需实现自己的密钥规范。有关密钥规范、JDK 1.2 提供的接口和类以及规范中的密钥工厂要求的详细信息，如下所述。

密钥规范透明地表示构成密钥的密钥信息。如果密钥存储于硬件设备中，则它的规范可能包含有助于识别该设备中密钥的信息。

透明密钥表示意味着可以通过相应的规范类中定义的“get”方法中的来分别访问每个密钥信息的值。 例如，java.security.spec.DSAPrivateKeySpec 定义了 getX、getP、getQ 和 getG 方法，以访问私钥 x 和用于计算密钥的 DSA 算法参数：质数 p、亚质数 q 和基数 g。

这与密钥接口定义的不透明表示正好相反。在该接口中不能直接访问参数域。换句话说，“不透明”代表只允许有限地访问密钥 - 即密钥接口定义的三种方法：getAlgorithm、getFormat 和 getEncoded。

密钥可以用特定于算法的方式或独立于算法的编码格式（例如 ASN.1）来指定。例如，DSA 私钥可以通过它的组件 x、p、q 和 g（参见 DSAPrivateKeySpec）来指定，也可使用它的 DER 编码（参见 PKCS8EncodedKeySpec）来指定。

JDK1.2 在 java.security.spec 包中定义了下列密钥规范接口和类：

KeySpec 接口

这个接口不包含方法和常量。它的唯一作用是对所有的密钥规范进行分组（并提供类型安全）。所有的密钥规范都必须实现该接口。

JDK 1.2 提供了几个实现 KeySpec 接口的类：DSAPrivateKeySpec、DSAPublicKeySpec、RSAPrivateKeySpec、RSAPublicKeySpec、EncodedKeySpec、PKCS8EncodedKeySpec 和 X509EncodedKeySpec。

如果您的提供者使用了密钥类型（例如 Your_PublicKey_type 和 Your_PrivateKey_type），而对于该类型 JDK 尚未提供相应的 KeySpec 类，则可能出现两种情形：一种是要求实现自己的密钥规范：

  1. 如果用户不必访问密钥类型的特定密钥信息值，则不必为该密钥类型提供任何 KeySpec 类。


    2. 这种情况下，用户将总是通过相应的 KeyPairGenerator 创建 Your_PublicKey_type 和 Your_PrivateKey_type 密钥，而这种 KeyPairGenerato 是由提供者为该种密钥类型提供的。如果要保存已生成的密钥以便以后使用，则要恢复密钥的编码（使用密钥接口的 getEncoded 方法）。如果要通过编码创建 Your_PublicKey_type 或 Your_PrivateKey_type 密钥（例如，为了初始化签名对象以便签名或确认），则要通过编码创建一个 X509EncodedKeySpec 或 PKCS8EncodedKeySpec 的实例，并将其传入提供者为该算法提供的相应 KeyFactory 中。该 KeyFactory 的 generatePublic 和 generatePrivate 方法将分别返回所请求的 PublicKey（ Your_PublicKey_type 的实例）或 PrivateKey（Your_PrivateKey_type 的实例）对象。

  2. 如果期望用户访问密钥类型的特定密钥信息值，或从密钥信息和相关的参数值而不是从其编码（如上）来构造密钥类型的密钥，则须用适当的构造函数方法和“get”方法来指定新的 KeySpec 类（该类实现 KeySpec 接口），以返回密钥信息域及类型的相关参数值。 这些类须通过与 JDK 中提供的 DSAPrivateKeySpec 和 DSAPublicKeySpec 类相同的方式来指定。这些类必须与 provider 类一起提供（例如作为提供者 JAR 文件的一部分）。

DSAPrivateKeySpec 类

这个类（该类实现了 KeySpec 接口）用其相关参数指定 DSA 私钥。它有下列方法： 
    public BigInteger getX()

    public BigInteger getP()

    public BigInteger getQ()

    public BigInteger getG()
这些方法返回私钥 x 和用来计算该密钥的 DSA 算法参数：质数 p、亚质数 q 和基数 g。

DSAPublicKeySpec 类

这个类（该类实现了 KeySpec 接口）用其相关参数指定 DSA 公钥。 它有下列方法： 
    public BigInteger getY()

    public BigInteger getP()

    public BigInteger getQ()

    public BigInteger getG()
这些方法返回公钥 y 和用来计算该密钥的 DSA 算法参数：质数 p、亚质数 q 和基数 g。

RSAPrivateKeySpec 类

这个类（该类实现了 KeySpec 接口）指定 RSA 私钥。它有下列方法： 
    public BigInteger getModulus()

    public BigInteger getPrivateExponent()
这些方法返回 RSA 模数 n 和构成 RSA 私钥的私用指数 d 值。

RSAPrivateCrtKeySpec 类

这个类（该类扩展了 RSAPrivateKeySpec 类）指定 RSA 私钥，该密钥在 PKCS#1 标准中已用中国余数定理 (CRT) 信息值进行定义。它有下列方法（除了从其父类 RSAPrivateKeySpec 继承的方法之外）： 
    public BigInteger getPublicExponent()

    public BigInteger getPrimeP()

    public BigInteger getPrimeQ()

    public BigInteger getPrimeExponentP()

    public BigInteger getPrimeExponentQ()

    public BigInteger getCrtCoefficient()
这些方法返回了公用指数 e 和 CRT 信息整数：模数 n 的质数因子 p、n 的质数因子 q、指数 d 对 (p-1) 取模、 指数 d 对 (q-1) 取模以及“中国余数定理”系数 q 的倒数对 p 取模。

RSA 私钥在逻辑上只包含模数与私用指数。CRT 值的提出是为了提高效率。

RSAPublicKeySpec 类

这个类（该类实现了 KeySpec 接口）指定 RSA 公钥。它有下列方法： 
    public BigInteger getModulus()

    public BigInteger getPublicExponent()
这些方法返回 RSA 模数 n 和构成了该 RSA 公钥的公用指数 e 的值。

EncodedKeySpec 类

这个抽象类（该类实现了 KeySpec 接口）以代码格式表示公钥或私钥。 它的 getEncoded 方法返回被编码的密钥： 
     public abstract byte[] getEncoded();
其 getFormat 方法返回编码格式的名称： 
     public abstract String getFormat()；
JDK 1.2 提供了两个实现 EncodedKeySpec 接口的类：PKCS8EncodedKeySpec 和 X509EncodedKeySpec。如果必要，可为那些类型或其它类型的密钥编码提供自己的 EncodedKeySpec 实现。

PKCS8EncodedKeySpec 类

这个类是 EncodedKeySpec 的子类，它根据 PKCS #8 标准中指定的格式表示私钥的 DER 编码。

它的 getEncoded 方法返回根据 PKCS #8 标准编码的密钥字节。getFormat 方法返回字符串“PKCS#8”。

X509EncodedKeySpec 类

这个类是 EncodedKeySpec 的一个子类，它根据 X.509 标准中指定的格式表示公钥或私钥的 DER 编码。

它的 getEncoded 方法返回根据 X.509 标准编码的密钥字节。getFormat 方法返回字符串“X.509”。

添加新的对象标识符

下列信息适用于提供未列入附录 A 中 Java 加密体系结构 API 规范与引用的标准算法的算法提供者。

将 OID 映射到名字

有时，JCA 必须根据算法标识符（例如在证书中编码的算法标识符）实例化其密码算法的实现，该算法标识符从定义上讲包括该算法的对象标识符 (OID)。例如，为校验 X.509 证书上的签名，JCA 可以根据被编码到该证书中的签名算法标识符来确定签名算法，从而为该算法实例化一个 Signature 对象并进行初始化以供校验。

为此，必须在提供者主文件里提供算法的对象标识符作为算法的别名项，从而使 JCA 能找到您的算法。

例如，如果 provider 实现在“com.xyz”包中，同时您的算法名为“MyAlg”，具有对象标识符（用字符串表示）“1.2.3.4.5.6.7.8”，则提供者主文件中应含如下项： 

    put(".MyAlg"， "com.xyz.MyAlg");
    put("Alg.Alias..1.2.3.4.5.6.7.8"， "MyAlg");
如果不止一个对象标识符知道您的算法，则必须为每个知道该算法的对象标识符创建一个别名项。

当您的算法是签名算法且用户运行 keytool -genkey 命令并用 -sigalg 选项指定（签名）算法时，JCA 必须执行该类型映射。这种情况下，提供者主文件应含如下项： 

    put("Signature.MyAlg"， "com.xyz.MyAlg");
    put("Alg.Alias.Signature.1.2.3.4.5.6.7.8"， "MyAlg");
其它 JCA 执行这种类型映射的情况有：(1) 当您的算法是 keytype 算法，且程序要解析证书（使用 SUN 提供者对 X.509 的实现）并从该证书抽取公钥以初始化签名对象供校验时，(2) 当已产生相应密钥对后，keytool 用户试图访问 keytype（例如，要执行数字签名）的私钥时。 上述情况下，您的提供者主文件应含如下项： 
    put("KeyFactory.MyAlg"， "com.xyz.MyAlg");
    put("Alg.Alias.KeyFactory.1.2.3.4.5.6.7.8"， "MyAlg");

将名字映射到 OID

如果 JCA 必须执行反向映射（也就是，将算法名映射到与之相关的 OID），则须给应知道您的算法的某个 OID 提供如下形式的别名项： 
    put("Alg.Alias.Signature.OID.1.2.3.4.5.6.7.8"， "MySigAlg");
如果不止一个对象标识符知道您的算法，则给首选的算法添加“OID”前缀。

当用户在任何需要 -sigalg 选项的模式下运行 keytool 时，JCA 必须执行这种映射。例如，当 -genkey 和 -certreq 命令被调用时，用户可以使用 -sigalg 选项来指定您的（签名）算法。



 
 

附录 A：“SUN”Provider 的主类

下面是 Sun.java 文件的副本，它包括一个名为 Sun 的类，该类是名为“SUN”的提供者的主类(每个 JDK 都提供有提供者)。象所有主类一样，该类也是 Provider 的子类。它指定了所有 “SUN”提供者提供的密码服务实现的类名和包的位置。JDK Security 将使用该信息查找被请求的各种算法和其它服务。

该代码是作为一个主类的示例提供的。 

/*
* Copyright 1996-1998 by Sun Microsystems， Inc.，
* 901 San Antonio Road， Palo Alto， California， 94303， U.S.A.
* All rights reserved.
*
* This software is the confidential and proprietary information
* of Sun Microsystems， Inc. ("Confidential Information").  You
* shall not disclose such Confidential Information and shall use
* it only in accordance with the terms of the license agreement
* you entered into with Sun.
*/

package sun.security.provider;

import java.io.*;
import java.util.*;
import java.security.*;

/**
* The SUN Security Provider.
*/

/**
* Defines the SUN provider.
*
* Algorithms supported， and their names:
*
* - SHA is the message digest scheme described in FIPS 180-1.
*   Aliases for SHA are SHA-1 and SHA1.
*
* - SHA1withDSA is the signature scheme described in FIPS 186.
*   (SHA used in DSA is SHA-1: FIPS 186 with Change No 1.)
*   Aliases for SHA1withDSA are DSA， DSS， SHA/DSA， SHA-1/DSA， SHA1/DSA，
*   SHAwithDSA， DSAWithSHA1， and the object
*   identifier strings "OID.1.3.14.3.2.13"， "OID.1.3.14.3.2.27" and
*   "OID.1.2.840.10040.4.3".
*
* - DSA is the key generation scheme as described in FIPS 186.
*   Aliases for DSA include the OID strings "OID.1.3.14.3.2.12"
*   and "OID.1.2.840.10040.4.1".
*
* - MD5 is the message digest scheme described in RFC 1321.
*   There are no aliases for MD5.
*/

public final class Sun extends Provider {

    private static final String INFO = "SUN " +
    "(DSA key/parameter generation; DSA signing; " +
    "SHA-1， MD5 digests; SecureRandom; X.509 certificates; JKS keystore)";

    public Sun() {
        /* We are the SUN provider */
        super("SUN"， 1.2， INFO);

        AccessController.doPrivileged(new java.security.PrivilegedAction() {
            public Object run() {

                /*
                * Signature engines
                */
                put("Signature.SHA1withDSA"， "sun.security.provider.DSA");

                put("Alg.Alias.Signature.DSA"， "SHA1withDSA");
                put("Alg.Alias.Signature.DSS"， "SHA1withDSA");
                put("Alg.Alias.Signature.SHA/DSA"， "SHA1withDSA");
                put("Alg.Alias.Signature.SHA-1/DSA"， "SHA1withDSA");
                put("Alg.Alias.Signature.SHA1/DSA"， "SHA1withDSA");
                put("Alg.Alias.Signature.SHAwithDSA"， "SHA1withDSA");
                put("Alg.Alias.Signature.DSAWithSHA1"， "SHA1withDSA");
                put("Alg.Alias.Signature.OID.1.2.840.10040.4.3"，
                    "SHA1withDSA");
                put("Alg.Alias.Signature.1.2.840.10040.4.3"， "SHA1withDSA");
                put("Alg.Alias.Signature.1.3.14.3.2.13"， "SHA1withDSA");
                put("Alg.Alias.Signature.1.3.14.3.2.27"， "SHA1withDSA");

                /*
                *  Key Pair Generator engines
                */
                put("KeyPairGenerator.DSA"，
                    "sun.security.provider.DSAKeyPairGenerator");

                put("Alg.Alias.KeyPairGenerator.OID.1.2.840.10040.4.1"， "DSA");
                put("Alg.Alias.KeyPairGenerator.1.2.840.10040.4.1"， "DSA");
                put("Alg.Alias.KeyPairGenerator.1.3.14.3.2.12"， "DSA");

                /*
                * Digest engines
                */
                put("MessageDigest.MD5"， "sun.security.provider.MD5");
                put("MessageDigest.SHA"， "sun.security.provider.SHA");

                put("Alg.Alias.MessageDigest.SHA-1"， "SHA");
                put("Alg.Alias.MessageDigest.SHA1"， "SHA");

                /*
                * Algorithm Parameter Generator engines
                */
                put("AlgorithmParameterGenerator.DSA"，
                    "sun.security.provider.DSAParameterGenerator");

                /*
                * Algorithm Parameter engines
                */
                put("AlgorithmParameters.DSA"，
                    "sun.security.provider.DSAParameters");
                put("Alg.Alias.AlgorithmParameters.1.3.14.3.2.12"， "DSA");
                put("Alg.Alias.AlgorithmParameters.1.2.840.10040.4.1"， "DSA");

                /*
                * Key factories
                */
                put("KeyFactory.DSA"， "sun.security.provider.DSAKeyFactory");
                put("Alg.Alias.KeyFactory.1.3.14.3.2.12"， "DSA");
                put("Alg.Alias.KeyFactory.1.2.840.10040.4.1"， "DSA");

                /*
                * SecureRandom
                */
                put("SecureRandom.SHA1PRNG"，
                    "sun.security.provider.SecureRandom");

                /*
                * Certificates
                */
                put("CertificateFactory.X509"，
                    "sun.security.provider.X509Factory");
                put("Alg.Alias.CertificateFactory.X.509"， "X509");

                /*
                * KeyStore
                */
                put("KeyStore.JKS"， "sun.security.provider.JavaKeyStore");

                return null;
            }
        });
    }
}



 
 

附录 B：java.security 属性文件

下面是出现在每次 JDK 安装过程中的 java.security 文件的副本。该文件出现在 JDK 的 lib/security (在 Windows 中为 lib\security) 目录下。因此，如果 JDK 被安装在 jdk1.2 目录下，则文件将是： 有关将提供者信息添加到该文件中的示例，参见步骤 5 。 
#

#
# In this file， various security properties are set for use by
# java.security classes. This is where users can statically register
# Cryptographic Service Providers ("providers" for short). The term
# "provider" refers to a package or set of packages that supply a
# concrete implementation of a subset of the cryptography aspects of
# the Java Security API. A provider may， for example， implement one or
# more digital signature algorithms or message digest algorithms.
#
# Each provider must implement a subclass of the Provider class.
# To register a provider in this master security properties file，
# specify the Provider subclass name and priority in the format
#
#    security.provider.n=className
#
# This declares a provider， and specifies its preference
# order n. The preference order is the order in which providers are
# searched for requested algorithms (when no specific provider is
# requested). The order is 1-based; 1 is the most preferred， followed
# by 2， and so on.
#
# className must specify the subclass of the Provider class whose
# constructor sets the values of various properties that are required
# for the Java Security API to look up the algorithms or other
# facilities implemented by the provider.
#
# There must be at least one provider specification in java.security.
# There is a default provider that comes standard with the JDK. It
# is called the "SUN" provider， and its Provider subclass
# named Sun appears in the sun.security.provider package. Thus， the
# "SUN" provider is registered via the following:
#
#    security.provider.1=sun.security.provider.Sun
#
# (The number 1 is used for the default provider.)
#
# Note: Statically registered Provider subclasses are instantiated
# when the system is initialized. Providers can be dynamically
# registered instead by calls to either the addProvider or
# insertProviderAt method in the Security class.

#
# List of providers and their preference orders (see above):
#
security.provider.1=sun.security.provider.Sun

#
# Class to instantiate as the system Policy. This is the name of the class
# that will be used as the Policy object.
#
policy.provider=sun.security.provider.PolicyFile

# The default is to have a single system-wide policy file，
# and a policy file in the user's home directory.
policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy

# whether or not we expand properties in the policy file
# if this is set to false， properties (${...}) will not be expanded in policy
# files.
policy.expandProperties=true

# whether or not we allow an extra policy to be passed on the command line
# with -Djava.security.policy=somefile. Comment out this line to disable
# this feature.
policy.allowSystemProperty=true

# whether or not we look into the IdentityScope for trusted Identities
# when encountering a 1.1 signed JAR file. If the identity is found
# and is trusted， we grant it AllPermission.
policy.ignoreIdentityScope=false

#
# Default keystore type.
#
keystore.type=jks

#
# Class to instantiate as the system scope:
#
system.scope=sun.security.provider.IdentityDatabase

#
# List of comma-separated packages that start with or equal this string
# will cause a security exception to be thrown when
# passed to checkPackageAccess unless the
# corresponding RuntimePermission ("accessClassInPackage."+package) has
# been granted.
package.access=sun.

#
# List of comma-separated packages that start with or equal this string
# will cause a security exception to be thrown when
# passed to checkPackageDefinition unless the
# corresponding RuntimePermission ("defineClassInPackage."+package) has
# been granted.
#
# by default， no packages are restricted for definition， and none of
# the class loaders supplied with the JDK call checkPackageDefinition.
#
#package.definition=

版权所有 (C) 1996-98 Sun Microsystems， Inc. 保留所有权利。

如有意见，请发送到： java-security@java.sun.com。这不是订单。

 Sun
Java Software
�