在 Oracle® Solaris 11.2 中确保网络安全

退出打印视图

更新时间: 2014 年 9 月
 
 

IKE 的工作原理

系统正在运行 IKE 守护进程时,可以协商在它与另一个正在运行 IKE 守护进程的系统之间创建安全关联 (security association, SA) 所需的参数。用于协商此 SA 和后续 IPsec SA 的协议称为 IKE。此版本 Oracle Solaris 支持 IKE 协议的版本 1 (IKEv1) 和版本 2 (IKEv2)。

IKE 安全关联(在 IKEv1 中也称为 ISAKMP 或阶段 1 SA)会保护这两个 IKE 系统之间的进一步协议交换。这些交换会协商加密算法、IPsec 策略以及创建 IPsec SA 所需的其他参数。

正在运行 IKE 守护进程的系统也可以配置为代表其他系统协商 IPsec SA。按这种方式配置时,系统被称为安全网关。如果 IKE 协商成功,IPsec SA 可以用于保护网络包。


注 -  在 Oracle Solaris 11.2 中,IKEv2 使用加密框架中的加密算法,这些算法通过了第 1级 FIPS 140-2 验证,但 IKEv1 未使用这些算法。缺省情况下 FIPS 140 未启用。要比较这两个版本的功能,请参见比较 IKEv2 和 IKEv1。要启用 FIPS 140-2 模式,请参见在 Oracle Solaris 11.2 中管理加密和证书 中的如何创建启用了 FIPS 140 的引导环境

如果有严格的要求,只能使用 FIPS 140-2 验证的加密,则必须运行 Oracle Solaris 11.1 SRU 5.5 发行版或 Oracle Solaris 11.1 SRU 3 发行版。Oracle 已在这两个特定发行版中针对加密框架完成了 FIPS 140-2 验证。Oracle Solaris 11.2 基于此验证的基础而构建并在性能、功能和可靠性方面进行了软件改进。应当尽可能在 FIPS 140-2 模式下配置 Oracle Solaris 11.2,以利用这些改进。


为创建 IKE SA 而协商的参数包括保护 IKE 交换和某些验证材料的加密算法。验证材料用于确定包含 IKE 协议交换的包是否可信。可信意味着包来自可信的系统,而不是伪装成可信系统的系统。

Oracle Solaris 支持两种类型的 IKE 验证材料,即预先共享的密钥和公钥证书。

使用预先共享的密钥验证的 IKE

预先共享的密钥是十六进制或 ASCII 字符串,只有两个 IKE 系统知悉。这些密钥被称为预先共享的密钥,因为两个端点必须在 IKE 交换之前知道密钥值。此密钥必须是两个系统上的 IKE 配置的一部分。预先共享的密钥用于生成 IKE 有效负荷,而这些有效负荷构成了实现 IKE 协议的包。处理这些 IKE 有效负荷的系统使用同一密钥验证它收到的有效负荷。

预先共享的密钥不能使用 IKE 协议在 IKE 端点之间交换。通常,此密钥通过不同的媒介(例如,打电话)与对等方系统共享。

使用此验证方法的对等方系统上的预先共享密钥必须相同。密钥存储在每个系统上的某个文件中。

IKE,使用公钥证书

公钥证书及其信任链会提供一个以数字方式标识系统的机制,无需手动交换任何机密信息。因此,公钥证书比预先共享的密钥更加安全。

公钥证书是一个对公钥值进行编码的数据 blob,含有关于生成证书的信息,例如名称和签名人、证书的散列或校验和以及散列的数字签名。这些值共同构成了证书。数字签名可以确保证书不被修改。

公钥是以数学方式从另一个称为私钥的值派生出的值。由于采用了从私钥派生公钥的数学算法,这就使得根据公钥检索私钥变得不现实。因此,公钥证书可以自由共享。用于派生公钥的算法示例包括 RSA 和椭圆曲线算法。

数字签名是通过 RSA、DSAECDSA 等数字签名算法传递证书内容的结果。这些算法使用私有签名密钥(不是证书的一部分)生成数字签名。签名会附加到证书上。同样,根据证书内容和签名计算签名密钥也不现实。更确切的说,证书签名以及证书内容可以使用派生自签名密钥的公钥值轻松验证。

证书可以自签名,在这种情况下,证书签名可由证书的公钥验证,或者它可以由另一个实体签名。当另一个实体对证书签名时,用于验证证书的公钥值也作为公钥证书分发。第二个证书将由可信的 certificate authority, CA(证书颁发机构)或中间方签名。中间方最终为签名实体(即根 CA 或 trust anchor(信任锚))所信任。

这些公钥证书组件以及实现它们的过程和结构通常称为公钥基础结构 (public key infrastructure, PKI)。组织的 PKI 范围可能各不相同。简单的 PKI 可能由对本地使用的几个证书加以签名的 CA 构成。更加广泛的 PKI 可能使用全球公认的信任锚作为权威 CA。

在 IKE 中使用公钥证书

本节介绍在 IKE 中创建和使用公钥证书的总体步骤。有关具体过程,请参见使用预先共享的密钥配置 IKEv2使用预先共享的密钥配置 IKEv1

  1. 要使用自签名证书或证书颁发机构 (certificate authority, CA) 颁发的证书,您首先要生成一个公钥/私钥对。

    • 对于自签名证书,IKE 对等方接着可以交换这些证书,在带外验证证书的真伪,然后将对等方的证书导入本地密钥库。接下来,密钥库包含原始自签名证书和导入的证书。

    • 对于 CA 颁发的证书,您可以执行更多步骤。生成公钥/私钥对时,您也可以生成证书签名请求 (certificate signing request, CSR)。CSR 包含公钥和标识符。典型的标识符是一个 distinguished name, DN(标识名),例如:

      DN=”O=Example\, Inc, OU=qa, L=Silicon Valley, ST=CA, CN=enigma”

      提示  -  创建一个 DN 或其他尽可能具体的标识符,降低与另一个证书的标识符匹配的可能性。
  2. 将 CSR 发送到 CA 以获得签名。

    在典型的流程中,您可以将 CSR 粘贴到 Web 表单中,然后将表单提交给 CA。CA 可能会向您发送多个已签名证书。

  3. 获得 CA 提供的已签名证书,然后将它们导入 IKEv2 密钥库或 IKEv1 数据库。

    您必须导入 CA 发送的全部证书。这些证书由一个从可信锚或根 CA 到您单独识别的已签名证书的“信任链”构成。

  4. 在 IKE 对等方上重复此流程。

  5. 使用 IKE 规则中的证书。

    您可以通过标识符指定证书,例如 DN。对于 CA 签名的证书,您可以配置 IKE,使其接受由特定 CA 签名的证书。

处理已撤销的证书

已签名证书被视为可信的有效证书,因为签名机构可以保证其有效性。如果证书受已泄密或者被确定为无效,CA 将撤销此证书。

CA 负责维护一个已撤销证书列表,通常称作 certificate revocation list, CRL(证书撤销列表)。您可以使用联机证书状态协议 (Online Certificate Status Protocol, OCSP) 动态查看证书状态。有些公钥证书中嵌入了 URI。它们会标识可以检查 CRL 的 Web 位置或者 OCSP 服务器的 Web 位置。

有关更多信息,请参见 RFC 2459: Certificate and CRL Profile(RFC 2459:证书和 CRL 配置文件)和 RFC 2560: Online Certificate Status Protocol - OCSP(RFC 2560:联机证书状态协议-OCSP)。

在使用公共证书的系统上协调时间

公钥证书包含证书的颁发日期和时间以及有效期。因此,生成和使用证书的系统上的时钟必须精准。网络时间协议 (Network Time Protocol, NTP) 软件可以用于同步系统上的时钟。Oracle Solaris 发行版中包括了由美国特拉华大学开发的 NTP 公共域软件。相关文档可从 NTP Documentation(NTP 文档)网站获取。您也可以安装 service/network/ptp 软件包,配置精确时间协议 (Precision Time Protocol, PTP) 服务。请参见 IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems(IEEE 1588 网络测量和控制系统的精密时钟同步协议标准)。