【译者按】作为软件研发项目的项目经理，只懂项目管理知识是不够的，需要对软件技术本身有基本的了解。Java 是一种主流的系统开发语言，其安全设计对于构建安全的信息系统有至关重要的意义。项目经理了解 Java安全知识的好处在于：

• 能与研发工程师有效沟通
• 指导或提醒研发工程师善用 Java安全体系
• 理解技术边界，平衡需求和实现

目录

1、引言
2、Java 语言安全和字节编码验证
3、基本安全框架
4、密码学
5、公钥基础设施
6、认证
7、安全通讯
8、访问控制
9、XML签名
10、更多信息

1、引言

Java 平台的设计着重关注了安全。在其核心，Java 语言自身是类型安全的，提供自动垃圾回收，以增强应用代码的健壮性。安全的类加载和验证机制保证只有合法的 Java 代码被执行。

Java 平台早期版本为潜在不可信的代码创建了一个安全的环境，如从公网上下载Java applet。随着平台的发展，以及其部署范围的扩展，Java 安全架构也响应的进行了升级进化，以支撑增长的服务需求。今天该框架包含了大量应用程序开发接口、工具和通用安全算法的实现、机制和协议。它为开发者编写应用，提供给了一套综合的安全框架，同时提供给用户或管理员一套安全管理应用的工具。

Java 安全 API 涉及非常广泛的领域。密码和公钥基础设施（PKI）接口为开发安全的应用提供了基础。认证和访问控制的接口使应用系统可以防护来自非授权的访问受保护的资源。

这些API允许算法和其他安全服务之间有多样的相互协作操作。提供服务都在 provider 中执行，后者基于一种标准接口可以插入 Java 平台，这种设计让应用可以方便的获取安全服务，同时又不必了解它们的实现细节。这使得开发者聚焦于如何将安全集成到他们的应用，而不用实际实现复杂的安全机制。

Java 平台包括了很多 Provider，它们实现了一组核心安全服务。它允许安装用户自定义的 Provider。这使得开发者可以扩展平台，支持新的安全机制。

本文提供了 Java 平台安全一览，包括安全语言特性到安全 API、工具、内置的 Priovider 服务、实用的备受瞩目的关键包和类。注意：本文是基于 Java SE v8。

2、Java 语言安全和字节编码验证

Java 语言从设计上就是类型安全和易于使用。它支持自动内存管理、垃圾回收、数组边界检测。这些降低了开发者的负担，编码进而更不易出错，也更安全、更健壮。

另外，Java 语言定义了不同的访问修饰符，可以用于限制 Java 类、方法、字段，使开发者严格限制他们的类的恰当的执行。尤其是语言定义了四种清晰的访问级别：private，保护，公共，包（缺省值）。最开放的访问指示符是public ，它允许任何人访问。最严格的修饰符是 private，它不允许外界访问特定内的内部成员（如方法）。protected 修饰符允许子类或在同一包的其他类访问。包级访问仅允许同一包的类间访问。

编译器将 Java 程序翻译成机器无关的字节码形式。字节码校验器用于保证只有合法的字节码在 Java 运行时中执行。它检查字节码是否符合 Java 语言规范，是否与语言规则、命名空间限制冲突。校验器还检查内存管理违例、栈溢出或下溢、非法的数据类型转换。一旦字节码验证通过，Java 运行时将准备运行它。

3、基本安全框架

Java 平台定义了一组横跨主要安全领域的 API，包括密码、公钥基础设施、安全通讯、访问控制。这些 API 允许开发者很容易的将安全集成到他们的应用代码中。它们的设计遵循以下原则：

• 运行独立性：应用不需要实现安全本身。应用可以从 Java 平台请求安全服务。安全服务运行在 Provider 中（见下），它们通过标准接口插入 Java 平台。一个应用可以使用多个独立的 Provider 以实现不同的安全功能。
• 实现互操作性：跨应用时 Provider 是可以互操作的。特别是，应用不会限定在特定的 Provider，Provider 也不会绑定在特定的应用。
• 算法扩展性：Java 平台提供了大量的内置的 Provider，它们实现了一套广泛使用的基础安全服务。然而，仍有一些应用需要的新兴的标准或专有服务没有支持。Java 平台支持安装用户自定义的此类服务的 Provider。

安全 Provider

在 Java 平台，类java.security.Provider封装了安全 Provider 的概念。它规定了 Provider 的名字，列出了它实现的安全服务。多个 Provider 可以同时配置，并列出优先级。当请求安全服务时，高优先级的 Provider 所实现的服务会被执行。

应用依靠相关的 getInstance 方法以从下层的 Provider 获取安全服务。例如，消息摘要生成代表 Provider 对外可用的一类服务。（第4节讨论信息摘要和其他加密服务）。应用触发 getInstance 方法（在 java.security.MessageDigest 类中）以获取特定消息摘要算法的执行，如 SHA-256。

MessageDigest md = MessageDigest.getInstance(“SHA-256”);

程序可通过指定 Provider 的名字，来选择请求执行特定的 Provider，如下：

MessageDigest md = MessageDigest.getInstance(“SHA-256”,”Provider”);

图1和图2说明了请求 SHA-256消息摘要执行的这些选项。这两张图展示了三个 Provider 执行消息摘要算法。Provider 按优先级从左到右排列。图1中，应用请求执行 SHA-256算法而没有指定 Provider 的名字，此时按优先级搜索Provider，能提供指定算法的 第一个Provider 将会执行，所以 ProviderB 将会返回。图2中，应用请求执行 SHA-256算法，并指定了Provider 即 ProviderC。此时，这个 Provider 的执行将返回，即使更高优先级的 ProviderB 也提供了 SHA-256的实现。

下面的小节涉及很多安全领域（密码，认证等），每个都包含了缺省 Provider 所提供的相关服务的描述。附件 C 中的表 A 总结了所有的缺省的 Provider。

文件位置

本文提到的关于 Java 安全的一些内容（包括配置 Provider）可以通过设置安全属性来定制化。你可以静态的在安全属性文件中设置安全属性，它缺省的是 java.security，在目录 lib/security 中（在安装 Java 运行环境 JRE 的路径下）。安全属性也可以动态设置，即调用适当类 Security 中的方法（在 java.security 包中）。

本文提到的工具及命令均在目录_{jre/bin，此处}jre 代表 JRE 的安装目录。第5节提到的cacert 文件在~jre/lib/security。

4、密码学

Java 密码学架构是一套面向 Java 平台的框架，提供访问和开发密码应用功能。它包括密码应用服务所用的 API，如下：

• 消息摘要算法
• 数字签名算法
• 对称分组加密算法
• 对称流式加密算法
• 非对称加密算法
• 基于口令的加密
• 椭圆曲线加密算法
• 秘钥协商算法
• 秘钥生成算器
• 消息认证码（MAC）
• （伪）随机数生成器

由于历史的原因（出口控制），密码 API 组织成两个独立的包。java.security 包包含不受出口限制的类（如签名、消息摘要）。javax.crypto包包含受出口限制的类（如加密、秘钥协商）。

密码接口是基于 Provider，允许多个、可相互操作的加密技术实现。一些 Provider 可以在软件中执行加密操作，另一些Provider 的运行则是依靠硬件令牌（例如，基于智能加卡设备，硬件加密加速器）。Provider如涉及出口管制的服务，则必须数字签名。

Java 平台为最通用的密码算法提供了内置的 Provider，包括 RSA、DSA、ECDSA 签名算法，DES、AES、ARCFOUR 加密算法，MD5、SHA-1、SHA-256消息摘要算，Diffie-Hellman、ECDH 秘钥协商算法。这些缺省的 Provider 均以 Java 代码来实现密码算法。

Java 平台还提供了一个特殊的内置 Provider，它充当与本地 PKCS#11（v2.x）令牌的桥梁。这个 Provider 的名字是 SunPKS11，它允许Java 应用无缝的访问由兼容 PKCS#11的令牌所提供的密码服务。

在Windows 上，Java 平台也提供了一个内置 Provider，用于桥接本地的微软CryptoAPI。这个 Provider 的名字是 SunMSCAPI，它允许 Java 应用在 Windows 上，通过 CryptoAPI无缝的访问密码服务。

5、公钥基础设施

公钥基础设施（PKI）是一个框架的术语，用来保证基于公钥秘密码技术实现安全的信息交换。它允许实体（人、组织等）与数字证书绑定，提供了一套验证证书认证的方法。PKI包括秘钥、认证、公钥加密、可信证书认证（CA），CA 负责生成和签署数字证书。

Java 平台所包含的 API 和 Provider 支持 X.509 数字证书和证书吊销列表（CRL），以及 兼容PKIX的证书目录建立与验证。与 PKI 相关的类位于 java.security和java.security.cert包。

秘钥和证书存储

Java平台使用秘钥和证书存储来支持长期持久的加密秘钥和证书的存储需求。特别的是，类java.security.KeyStore代表秘钥存储、安全密码秘钥仓库、可信证书（如在证书路径验证使用）。类java.security.cert.CertStore代表证书存储、面向无关和典型不可信证书的公共潜在的大型仓库。CertStore可能会存储 CRL。

KeyStore 和 CertStore 实现按类型区分。Java 平台支持标准的 PKCS11和 PKCS12的秘钥存储类型，它们的实现兼容相应的 PKCS 规格（RSA 安全）。它还包括了一个基于专有文件的秘钥存储类型，JKS（Java Key Store）和 DKS（Domain Key Store），后者是一个秘钥存储集合，代表了一个独立的逻辑秘钥存储。

Java 平台提供了一个特殊的内置 JKS 秘钥存储 cacerts，其包含了很多公认的可信的 CA 的证书。工具keytool可以列出 cacerts 中的证书（见第10节安全特性文档链接）。

第4节提到的SunPKCS11 Provider 实现了 PKCS11 KeyStore。这意味着借助 KeyStore API Java 应用可以访问属于安全硬件（如智能卡）的秘钥和证书。需要提醒的是，智能卡的秘钥可能不允许离开设备。在这种情况下，KeyStore API 可能简单返回 java.security.Key 对象应用，即只是秘钥的引用，而不是包含实际秘钥本身。这样的Key 对象只能在设备上执行加密运算，实际的秘钥驻留在设备上。

Java 平台还支持 LDAP 证书存储类型（访问存在 LDAP 目录中的证书）和内存Collection证书存储类型（访问由java.util.Collection对象管理的证书）。

PKI工具

有两种内置工具可配合秘钥、证书、秘钥存储工作：
keytool 用于创建和管理秘钥存储，它支持：

• 创建公钥私钥对
• 显示、导入、导出 X.509 v1,v2,v3 证书并存为文件
• 创建自签名证书
• 发布可发送给 CA 的证书（PKCS#10）
• 基于证书请求只做证书
• 导入证书副本（从 CA 获得）
• 指定可信的公钥证书
• 接收口令并以秘钥形式安全存储

jarsinger 工具用于对 JAR 文件进行签名，也可以验证JAR 文件的签名。Java ARchive（JAR)文件格式将多个文件打包成一个文件。典型的 JAR 文件包含类文件、applet和应用需要的附加的资源文件。当你需要数字签名码时，你手下要用 keytool 生成或导入对应的秘钥和证书到你的秘钥存储（如果它们之前不在那里），之后使用 jar 工具将码放入到 JAR 文件中，最后使用 jarsigner 工具去签名 JAR 文件。jarsigner 工具访问秘钥存储，可以查找任意秘钥和证书，以便于对 JAR 文件签名或验证其签名的有效性。注意：jarsigner 可以选择生成签名并包含时间戳。验证 JAR 文件签名的系统（如 Java Plug-in）可以检查时间戳，接受签名曾经有效的 JAR 文件，而不是要求证书现在有效。（证书通常每年都会过期，没有理由期望 JAR 文件创建者每年重新签名并部署 JAR 文件）。

6、认证

认证是检测用户身份的过程。在 Java 运行环境中，它是指确认执行的 Java 程序的用户。在一些特定的情况下，这个过程依赖于第4节所介绍的密码服务。

Java 平台提供 API 使应用可用借助可插拔的模块显示用户认证。应用调用 LoginContext 类（在包 javax.security.auth.login），它将返回配置的引用。这个配置指定哪个登录模块（接口javax.security.auth.spi.LoginModule的一个实现）会被用于执行实际的认证。

由于应用是独立访问标准的 LoginContext 接口，所以他们保持与下层可插拔模块的独立性。新的或更新的模块可以根据应用需要插入，而不必修改应用本身。图3说明了应用与下层登录模块的的独立性。

有一点很重要，虽然登录模块是可插拔的组件，可以通过配置接入 Java 平台，但他们并不是通过安全 Provider 接入的。因此，它们不遵循第3节所描述的 Provider 搜索模型（上图），登录模型由各自的唯一的配置来管理。

Java 平台提供了以下内置的登录模块，它们都在包 com.sun.security.auth.module中：

• Krb5LoginModule 使用 Kerberos 协议认证
• JndiLoginModule 使用 LDAP、NIS 数据库进行用户/密码认证
• KeyStoreLoginModule 登入任意类型的秘钥存储，包括 PKCS#11令牌秘钥存储

在两个节点间建立安全通讯时，认证也可完成。Java 平台提供了很多标准通讯协议的实现，这将在下一节讨论。

7、安全通讯

数据通过网络传输，有可能被不是预期的接收者获取。当这些数据包含私有信息（如密码、信用卡号），必须采取措施让未授权的其他方不能了解这些数据。同样重要的是，确保在你发送数据给相应的接收者时，这些数据在传输过程中，不会被有意或无意的修改。

加密是安全通讯的基本要求，见第4节。针对很多标准的安全通讯协议，Java 平台也提供了 API 支持和 Priovider 实现。

SSL/TLS

Java平台提供了 SSL、TLS 协议的 API 及实现，包括数据加密功能、消息完整性、服务器认证、可选的客户端认证。应用可以使用 SSL/TLS来为通讯双方提供安全的数据通道，可支持任意的应用协议，如 基于 TCP/IP 的HTTP。

类javax.net.ssl.SSLSocekt在常规流式套接字（java.net.Socket）上封装了 SSL/TLS的支持。一些应用可能想使用交替的数据传输抽象（如 New-I/O)，类 javax.net.ssl.SSLEngine 可用用来生产和消费 SSL/TLS 包。

Java 平台提供了 API 来支持可插拔的秘钥管理器和信任管理器，这些是基于 Provider 的。一个秘钥管理器是由 javax.net.ssl.KeyManager 封装，管理用于认证的秘钥。信任管理器就是由 类TrustManager（相同的包）封装，根据其管理的秘钥存储中的证书来决定谁被信任。

Java 平台提供的内置 Provider 实现 SSL/TLS协议：

• SSLv3
• TLSv1
• TLSv1.1
• TLSv1.2

SASL

简单认证与安全层 Simple Authentication and Security Layer (SASL)是一个互联网标准，它详细规范了客户端与服务应用间的认证和可选的安全层的建立。SASL 定义了如何交互认证数据，并没有限定数据内容。它是一套规范认证机制的框架，这些机制规定了内容及认证数据可以支持的语义。标准 SASL 机制众多，它们由互联网社区根据不同的安全级别和部署场景而制定。

Java SASL API 为使用 SASL 机制的应用，定义了类、接口。它们是机制中立的，使用这些 API 的应用不必绑定使用任何特定的 SASL 机制。应用可以根据需要的安全特色来选择合适的机制。API 即支持客户端应用，也支持服务器端应用。类javax.security.sasl.Sasl可用来创建 SaslClient 和SaslServer对象。

SASL 机制在 Provider 包中实现。每个 Provider 可以支持一个或多个 SASL 机制，每个 Provider 可以通过标准的 Provider 架构来注册和触发。

Java 平台提供了支持以下 SASL 机制的内置 Provider。

• CRAM-MD5，DIGEST-MD5，EXTERNAL，GSSAPI，NTLM，PLAIN 客户端机制
• CRAM-MD5，DIGEST-MD5，GSSAPI，NTLM 服务端机制

GSS-API 与 Kerberos

Java平台提供了API 以便于 Java 语言方便访问通用安全服务应用开发接口（GSS-API）。GSS-API 提供给应用开发人员统一的方法访问基于安全机制构建的安全服务。Java GSS-API 目前需要使用 Keberos v5 机制，Java 平台提供了该机制的内置实现。现在，还不能插入附加的机制。注意：第6节提到的Krb5LoginModule与 GSS Kerberos 机制一起使用。

Java 平台内置实现了 Simple and Protected GSSAPI Negotiation Mechanism（SPNEGO） GSS-API 机制。

两个应用要使用 Java GSS-API 安全交换信息，必须建立公共的安全上下文。这个上下文包含了共享的正式信息，例如可能包括加密秘钥。应用都创建和试用org.ietf.jgss.GSSContext对象来建立和维护组成安全上下文的共享信息。一旦安全上下文建立，它可以用来准备要交换的安全信息。

Java GSS API 位于org.ietf.jgss包中。Java 平台还定义了基础的 Kerberos 类，如 KerberosPrincipal，KerberosTicket，KerberosKey，KeyTab，这些都位于包javax.security.auth.kerberos 中。

8、访问控制

Java 平台的访问控制框架保护对敏感资源（如本地文件）、敏感应用代码（如类中的方法）的访问。所有访问控制的决定都是有安全管理器裁决的，它就是累java.lang.SecurityManager。为了激活访问控制检查，SecurityManager 必须安装在 Java 运行时中。

Java applet 和 Java Web Start 应用与 安装的SecurityManager一起自动运行。然而，通过 java 命令运行本地应用缺省是不与安装的 SecurityManager 一起运行。为了让本地应用与 SecurityManager 一起运行，有两种方法，或者应用自身通过 setSecurityManager 方法（在类java.lang.System中）来设定，或者 java 触发时在命令行中增加参数 -Djava.security.manager。

许可

类加载器将 Java 代码加载Java 运行时，同时会自动将此代码与以下信息建立关联：

• 代码从哪里加载的
• 谁签名该代码（如果有）
• 该代码的缺省许可

无论代码是从不可信网络下载的（如 applet）还是从文件系统加载（如本地应用），这些信息都会与代码关联起来。代码被加载的路径用 URL 表示，代码签名用签名者证书链表示，缺省许可用java.security.Permission 对象来表示。

下载的代码的缺省许可会自动的增加访问其下载源的网络连接权限。从本地文件加载的代码的缺省许可会自动赋予读取器所在路径其他文件的能力，也包括子文件夹。

注意：在类加载阶段，不能确认执行代码的用户身份。如果需要，应用代码要自己认证最终用户（如见第6节）。一旦用户通过认证，应用会通过调用 doAS 方法（java.security.auth.Subject类）将执行代码的用户与其关联。

策略

如之前提到的，类加载器会授予代码一组有限的缺省许可集合。管理者需要能借助安全策略，灵活的管理附加的代码许可。

Java 平台将安全策略的概念封装在类java.security.Policy中。在任何时间，它都是java 运行时中唯一的 Policy 对象。Policy 对象基本的职责是，检测是否允许代码访问受保护的资源（这由其被加载的位置、谁签名及谁执行决定）。Policy 对象如何做决定是与实现无关的。例如，它可以查询包括授权代码的数据库，也可以联系另一个服务。

Java 平台的缺省 Policy 实现是从一个或多个 ASCII（UTF-8）文件中读取认证数据，这些文件是配置在安全属性文件中的。这些策略文件包括赋予代码的精确许可集合：特别的是，当代码从特别的位置加载，由特别的实体签名，由特别的用户执行，都会赋予准确的许可集合。每个文件中的策略实体必须遵循成文的专用语法，也可以使用纯文本便器或者图形化工具 policytool 来编写。

访问控制增强

Java 运行时跟踪程序执行产生的 Java 调用序列。当访问受保护资源时，缺省的整个调用栈会被评估是否允许该访问申请。
如之前提到的，资源由 SecurityManager 来保护。以下是Java 平台和应用的安全敏感代码保护访问资源的代码示例：
SecurityManager sm = System.getSecurityManager(); if ( sm != null ) { sm.checkPermission( perm); }
perm 是对应访问请求的许可对象。例如，如果尝试读取文件/temp/abc，许可可能如下构造：
Permission perm = new java.io.FilePermission( “/tmp/abc”, “read" );
缺省的 SecurityManager 实现授权java.security.AccessController 实现来完成决定。AccessController遍历调用栈，将安装的安全 Policy 和访问的许可，传递给栈中的每个代码元素（如，上面例子中的 FilePermission）。Policy 根据管理员配置的许可决定请求的访问是否被授权。如果访问没有被授权，AccessController 会抛出java.lang.SecurityExcepion。

图4 展示了访问控制增强。在这个具体的例子中，在调用堆栈中有两个初始元素，ClassA 和 ClassB。ClassA调用ClassB 的方法，该方法创建java.io.FileInputStream 的实例，尝试访问文件/tmp/abc。

FileInputStream 构造器创建了上面的 FilePermission，perm，然后将 perm 传给 SecurityManager的 checkPermission方法。在这个具体的示例中，只需要检查ClassA 和 ClassB的许可，这是因为所有系统代码，包括 FileInputStream、SecurityManager和 AccessController，会自动获得所有许可。

在这个例子中，ClassA 和 ClassB 代码特征不同，他们来自不同的位置和不同的签名者。每个都被赋予不同的许可集合。如果 Policy 指出两个类都被赋予需要 FilePermission，AccessController 只会授权访问需要的文件。

9、XML 签名

Java XML 数字签名 API 是用于生成和验证 XML 签名的标准 Java API。

XML 签名可以用于任意数据类型，包括 XML 和二进制（见* http://www.w3.org/TR/xmldsig-core/ *)。签名的结果也是 XML 形式的。XML 签名可用于保证数据安全，提供数据完整性保护、消息认证、签名认证。

该API 设计支持 W3C 关于 XML 签名语法及处理的推荐中所有必须的和推荐的特性。这套 API 也可扩展和可插拔的，是基于 Java 密码服务 Provider 框架。

Java XML数字签名 API 由以下包组成：

• javax.xml.crypto
• javax.xml.crypto.dsig
• javax.xml.crypto.dsig.keyinfo
• javax.xml.crypto.dsig.spec
• javax.xml.crypto.dom
• javax.xml.crypto.dsig.dom

10、更多信息

更多的 Java安全文档可以在线的查看 Java SE Security 和 书《Inside Java 2 Platform Security, Second Edition：Architecture , API Design and Implementation》。

注意：历史上，新类型的安全服务被加入到 Java 平台（有时开始只是扩展），不同的首字母缩写词被用于指代他们。由于这些缩写词仍然会被使用在 Java 安全文档中，所以这里有一份他们的含义清单：JSSE（Java Secure Socket Extension）指 SSL 相关的服务（第7节），JCE（Java 加密扩展）指加密服务（第4节），JAAS（Java Authentication and Authorization Service）指认证和基于用户的访问控制服务（第6、8节）。

附 A、 类汇总

表1 总结了本文提到的安全类和接口的名称、包和用途。
表1 关键 Java 安全包和类

附 B、工具汇总

表2汇总本文提到的工具。
表2 Java 安全工具

还有3个用于 Windows 系统的 Java 平台的 Kerberos 相关工具。相应功能的同名工具也是 Solaris 和 Linux 操作环境的组成部分。表3汇总了 Kerberos 工具。

附 C、内置 Provider

Oracle 版Java 平台提供大量的内置的 Provider 包。更多细节，见Java Cryptography Architecture Oracle Provider Documentation。

原文:Java Security Overview