java密码学架构指南（一）

最新推荐文章于 2023-08-09 13:35:01 发布

willliam_llllll

最新推荐文章于 2023-08-09 13:35:01 发布

阅读量2.1k

点赞数

分类专栏： java 密码学文章标签：密码学 java 加密

java 同时被 2 个专栏收录

3 篇文章 0 订阅

订阅专栏

密码学

1 篇文章 0 订阅

订阅专栏

介绍

java平台非常强调安全，包括语言安全，密码学，公钥基础设施，授权，安全传输和访问控制。

JCA（Java Cryptography Architecture）是java平台安全性的主要部分，它包括了一个“provider”架构和一系列API，这些api支持数字签名，消息摘要，证书和证书验证，（对称/非对称加密，块机密和流加密），密钥生成和管理，随机数生成。这些API可以让开发者轻松的把安全集成到他们的应用代码里面。安全架构是按照一下原则设计的：

实现的独立性：应用系统不需要实现这些安全算法。他们可以请求java平台的安全服务。这些安全服务是按照providers（下面有介绍）方式实现，他们通过标准的接口嵌入到java平台中。一个应用可能需要依赖多个不同的提供者来提供安全功能。
实现的互操作性：提供者在多个应用的或操作。具体的来说，一个应该用并不是绑定到某个提供者，某个提供者也没有绑定到某个应用。
算法的扩张性:java平台包括了一许多内置的提供者来实现一系列现在广泛使用的安全服务。然而，一些应用需要依赖一些尚未实现的新兴标准或者专有的服务。java平台支持安装定制的提供者来实现这些服务。

JDK中其他的密码通信库如果使用JCA provider模式，会在其他地方描述。如 Java Secure Socket Extension (JSSE) 提供 Secure Socket Layer (SSL) 和Transport Layer Security (TLS) 的实现。Java Generic Security Services (JGSS) (Kerberos实现) API, 和 Simple Authentication and Security Layer (SASL) 也可以实现系统间的安全通信。

术语说明

JDK1.4之前JCE并不是一个捆绑的产品，那时JCA和JCE是指独立的不同的组件。因为JCE现在绑定在JDK中，两者的区别就不明显了。因为JCE和JCA使用了相同的架构，JCE被看做是JCA的一部分更合适。
JDK中的JCA包含两个软件组件：

1 定义密码服务让提供者实现的框架。这个框架在例如java.security,javax.crypto, javax.crypto.spec, 和javax.crypto.interface这些包中。

2 实际的提供者，例如：Sun，SunRsaSign，SunJCE，这些包括密码学的真正实现

只要提到JCA的提供者，就是指提供者的名称。

设计原则

JCA是按照以下原则设计的：

实现独立性和互操作性
算法独立性和可扩展性

实现独立和算法独立和相互补充的；你可以使用像数字签名和消息摘要之类的安全服务而不用担心具体的实现细节，甚至构成这些概念基础的算法。然而完全的算法独立是不可能的，JCA提供标准的指定算法的API。如果不希望实现独立的实现，JCA允许开发者指定某个具体的实现。

算法的独立性是通过定义密码引擎（服务）和定义类来实现这些引擎的功能来实现的。这些类叫做引擎类（engine class），例如： MessageDigest， Signature， KeyFactory， KeyPairGenerator，和 Cipher 等类。

实现的独立性是通过使用“提供者”为基础的架构来实现的。术语 Cryptographic Service Provider (CSP) 密码服务提供者（在本文档中和提供者可以互换）指实现一个和多个密码服务的一个或一组包，例如数字签名算法，消息摘要算法，密码转化算法等密码服务。程序可能仅仅请求某个类型的对象（例如签名对象）实现某个特定的服务（例如DSA签名算法）并获取安装的提供者中的一个实现。如果愿意，程序可以仅仅从某个特定的提供者来请求实现。当一个更快和更安全的版本出现的时候，提供者可能透明的更新到应用中。

实现的互操作性意味着不同的实现可以再一起相互工作，使用对方的密钥，验证对方的签名。举个例子，这就意味着，对于同一个算法，一个提供者产生的密钥可以被另一个提供者使用，一个提供者产生的签名可以被另一个提供者验证。

算法的扩展性意味着时候某个支持的引擎类的新的算法能方便的添加进去。

架构

密码服务提供者

java.security.Provider是所有的安全提供者的基类。每一个密码安全提供者都包含这个类的实例，这个实例提供了提供者的名称和实现的安全算法列表。当需要某个算法的实例的时候，JCA框架会查询提供者的数据库，如果找到合适的算法，就会创建实例。

提供者保包含了实现了声明的密码算法的一个包（一系列包）。每个jdk的安装包都会安装一个或者多个提供者并按照默认的方式来排序。额外的提供者可以动态或者静态的添加（参见Provider和Security类）。客户可以配置运行环境为自己偏好的顺序。也就是指请求提供的服务却没有指定具体的提供者的，JCA框架查找提供者的顺序。

为了使用JCA，应用程序仅需要某个类型的对象（例如MessageDigest）和一个算法或者服务（例如“MD5”算法）来获取一个已经安装的实现。或者程序可以从某个具体的提供者来请求对象。每个提供者都有一个名字来标示它。

 md = MessageDigest.getInstance("MD5");
  md = MessageDigest.getInstance("MD5", "ProviderC");

下面图解阐述了请求MD5消息摘要服务的过程。图解展示实现了不同消息摘要算法（SHA-1，MD5 SHA-256，SHA-512）的的三个不同提供者。提供者按照从左到右的方式排序。第一张图展示了应用程序在请求MD5算法的时候没有指定提供者名称，框架会按照顺序找到第一个提供这个算法的提供者，所以找到了提供者B。第二张图向提供者C请求

MD5算法，即使提供者B有更高的优先排序号并提供了MD5的实现，仍然会返回提供者C.

由于历史原因，JDK中的密码实现是按照不同的提供者（Sun，SunJSSE，SunJCE，SunRsaSign）分布的，很少按照他们提供的功能类型和算法分布。其他的java运行环境可能没有sun提供者，应用程序如果不能确定某个提供者是可用的，就不应该指定某个具体的提供者。

JCA提供了一套API供用户查询已经安装的提供者和他们提供的服务。

这样的架构使得最终用户很容易添加其他的提供者。现在又许多第三方的提供者都可以使用。想了解更多的关于如何编写，安装，注册提供者的信息，请参看Provider 类。

提供者是如何实现的

正如之前提到的，算法独立是通过第一套抽象的高级别的API供所有的应用程序使用来访问某个服务类型。实现独立式通过让所有的提供者实现定义好的接口。引擎类的实例对象是通过和其方法签名一样的实现类来支持的。应用程序的调用会通过引擎类路由并转发到真正内部的实现，实现方处理请求并返回合适的结果。

引擎类中的API方法被路由到提供者的实现中去是通过某个实现了相应的SPI（Service Provider Interface）接口的类来实现。也就是说，对每一个引擎类，都有一个对应的抽象的SPI类来定义每个安全服务提供者的算法必须实现的方法。每个SPI类的名称是相应的引擎类的名称在加上Spi。例如：Signature引擎提供了访问数字签名算法的功能，他具体的实现是由一个SignatureSpi的子类来提供的。应用程序调用引擎类中的API方法时，会调用具体实现类中的SPI方法。

每个SPI类都是抽象的。为了实现某一类型服务的某个算法，提供者必须编写相应SPI类的子类，并实现所有的抽象方法。