信息安全手册：密码学指南

文摘 2024-12-18 00:01 河南

密码学基础知识

密码学的目的

加密的目的是提供数据的机密性、完整性、身份验证和不可否认性。机密性通过使数据对除授权实体以外的所有实体都不可读来保护数据，完整性可防止实体意外或故意操纵数据，身份验证可确保实体是其声称的身份，而不可否认性可证明实体执行了特定操作。

使用加密

静态数据加密可用于保护存储在信息技术 (IT) 设备和媒体上的敏感或机密数据。此外，传输中数据加密可用于保护通过公共网络基础设施传输的敏感或机密数据。但是，当组织对静态数据或传输中数据进行加密时，它们并没有降低数据的敏感度或机密性，它们只是减少了数据被恶意行为者访问的直接后果。

密码模块的国际标准

国际标准化组织 (ISO)/国际电工委员会 (IEC) 19790:2012《信息技术 – 安全技术 – 加密模块安全要求》和 ISO/IEC 24759:2017《信息技术 – 安全技术 – 加密模块测试要求》是硬件和软件加密模块设计和验证的国际标准。

联邦信息处理标准 (FIPS) 140-3、加密模块安全要求和国家标准与技术研究所 (NIST) 特别出版物 (SP) 180-140、FIPS 140-3 衍生测试要求 (DTR)：CMVP 验证机构对 ISO/IEC 24759 的更新是基于 ISO/IEC 19790:2012 和 ISO/IEC 24759:2017 的美国标准。

通信安全原则

澳大利亚信号局 (ASD) 在《澳大利亚通信安全指令》中规定了操作高可靠性加密设备 (HACE) 时必须遵守的额外通信安全要求。这些要求是对上述准则的补充，如果发生冲突，则优先适用。

遵守 ASD 为 HACE 的管理和运营制定的通信安全原则。

经批准的高可靠性加密设备

为了确保互操作性并保持信任，所有 HACE 都必须获得 ASD 的使用批准，并按照相关澳大利亚通信安全指令的最新版本进行操作。

HACE 获得了 ASD 的使用批准，并按照其相关澳大利亚通信安全指令的最新版本进行操作。

加密密钥管理流程和程序

记录良好的加密密钥管理流程和程序有助于安全使用和管理加密密钥及相关硬件和软件。在此过程中，加密密钥管理流程和程序应涵盖加密密钥的生成、注册、分发、安装、使用、保护、存储、访问、恢复和销毁。

加密密钥管理流程以及支持加密密钥管理程序均已开发、实施和维护。

加密静态数据

对静态数据进行加密可以增加一层防御，防止恶意行为者未经授权访问。为此，使用全盘加密非常重要，因为它比基于文件的加密提供更高级别的保护。这是因为，虽然基于文件的加密可以加密单个文件，但未加密的文件副本可能会留在操作系统使用的临时位置。为此目的选择加密设备或软件时，所需的保证级别将取决于数据的敏感性或分类。

加密媒体时使用 ASD 认可的加密算法 (AACA) 或高保证加密算法。

在加密包含官方：敏感或受保护数据的媒体时，使用已完成针对保护配置文件的通用标准评估的加密设备或软件。

在加密包含 SECRET 或 TOP SECRET 数据的媒体时使用 HACE。

在加密静态数据时实施全盘加密或部分加密，其中访问控制仅允许写入加密分区。

加密传输中的数据

当数据通过网络基础设施进行传输时，应使用加密技术来保护数据免遭未经授权的访问或操纵。为此目的选择加密设备或软件时，所需的保证级别将取决于数据的敏感度或分类以及应用环境。

ASD 认可的加密协议 (AACP) 或高保证加密协议用于在通过网络基础设施传输时保护数据。

已完成针对保护配置文件的通用标准评估的加密设备或软件用于保护官方：敏感或受保护的数据在通过不够安全的网络、适当安全区域之外或通过公共网络基础设施进行通信时。

HACE 用于在安全性不够高的网络上、在适当安全区域之外或通过公共网络基础设施传输时保护机密和绝密数据。

数据恢复

为了确保不会由于加密密钥的丢失、损坏或故障而无法访问加密数据，实用的加密设备和软件提供数据恢复手段非常重要。

在实际情况下，加密设备和软件提供一种数据恢复方法，以应对由于丢失、损坏或故障而导致加密密钥不可用的情况。

处理加密的 IT 设备和媒体

当用户通过 IT 设备或媒体的加密功能进行身份验证时，加密数据即可使用。此时，应根据 IT 设备或媒体的原始敏感度或分类进行处理。一旦用户取消对加密功能的身份验证（例如关闭设备或激活锁定屏幕），则可以认为 IT 设备或媒体再次受到加密功能的保护。

当用户对 IT 设备或媒体的加密功能进行身份验证时，将根据其原始敏感度或分类进行处理，直到用户从加密功能中取消身份验证。

运输加密设备

在密钥状态下运输加密设备可能会使其密钥材料面临潜在的泄露风险。因此，如果在密钥状态下运输加密设备，应根据其密钥材料的敏感度或分类进行运输。

密钥加密设备的运输基于其密钥材料的敏感度或分类。

报告与密码相关的网络安全事件

如果加密设备或相关密钥材料被泄露或疑似被泄露，那么之前和未来通信的机密性和完整性也可能受到损害。在这种情况下，网络安全事件发生后应尽快向首席信息安全官或其代表报告，并应更改所有密钥材料。

加密设备或相关密钥材料的泄露或疑似泄露应在发生后尽快报告给首席信息安全官或其代表之一。

当密钥材料受到损害或怀疑受到损害时，就会更改。

ASD 认可的加密算法

高可信度加密算法

本节未涉及的高保证加密算法，如果在 HACE 中适当实施，则可用于保护机密和绝密数据。有关高保证加密算法的更多信息，可从 ASD 获取。

ASD 认可的加密算法

算法无法保证能够抵抗目前未知的攻击。但是，本节列出的算法已在实践和理论环境中得到了行业和学术界的广泛审查。本节列出的算法的使用批准仅限于根据这些准则实施的情况。

已批准的非对称/公钥算法包括：

Diffie-Hellman (DH) 用于协商加密会话密钥
用于密钥交换的椭圆曲线 Diffie-Hellman (ECDH)
用于数字签名的椭圆曲线数字签名算法 (ECDSA)
Rivest-Shamir-Adleman (RSA) 用于数字签名和传递加密会话密钥或类似密钥。

唯一获得批准的散列算法是安全散列算法 2 (SHA-2)。

唯一获得批准的对称加密算法是高级加密标准 (AES)。

当算法的密钥大小有一定范围时，一些较小的密钥大小不会被批准，因为它们无法提供足够的安全余量来抵御未来可能的攻击。例如，整数分解方法的进步可能会使较小的 RSA 模数变得脆弱。

本节所列算法的有效安全强度目标为：受保护及以下数据为 112 位，机密数据为 128 位，绝密数据为 192 位。但是，为了确保与美国最初的商业国家安全算法套件（现称为 CNSA 1.0）的互操作性，某些密钥大小和曲线是首选。

使用 ASD 认可的加密算法

如果加密设备或软件实施了未经批准的算法，则这些算法可能会在用户不知情的情况下被使用。结合假定的安全信心水平，这可能代表安全风险。因此，组织可以通过禁用所有未经批准的算法（首选）或通过使用政策建议用户不要使用未经批准的算法来确保只能使用 AACA 或高保证加密算法。

加密设备和软件仅使用 AACA 或高保证加密算法。

非对称/公钥算法

与 ECDH 相比，DH 容易受到不同类型的攻击，但每增加一位都能提供更有效的安全性。这导致数据要求更小，反过来意味着椭圆曲线变体已成为事实上的全球标准。为了降低数据成本并促进互操作性，应尽可能优先使用 ECDH 而不是 DH。

ECDH 优先于 DH 使用。

使用 Diffie-Hellman

正确实施的 DH 的 2048 位模数可提供 112 位有效安全强度。考虑到预计的技术进步，据评估，112 位有效安全强度在 2030 年之前仍将保持安全。

当在素数域中使用 DH 时，素数模数会影响算法的安全性。创建此类素数模数时的安全注意事项可在 NIST SP 800-56A Rev. 3 中找到，同时还可找到一组常用的安全模数。

当使用 DH 来协商加密会话密钥时，使用至少 2048 位的模数，最好是 3072 位。

当使用 DH 来协商加密会话密钥时，使用至少 3072 位的模数，最好是 3072 位。

在使用 DH 协商加密会话密钥时，根据 NIST SP 800-56A Rev. 3 选择模数和相关参数。

使用椭圆曲线密码术

椭圆曲线算法中使用的曲线会影响算法的安全性。因此，应仅使用 NIST SP 800-186 中合适的曲线。

使用椭圆曲线密码术时，使用 NIST SP 800-186 中的合适曲线。

使用椭圆曲线 Diffie-Hellman

从 NIST SP 800-186 中识别合适的曲线时，正确实施的 ECDH 的基点顺序和至少 224 位的密钥大小可提供 112 位的有效安全强度。不能假设从其他来源选择的曲线的安全性仅使用基点顺序和密钥大小就具有相同的安全性。

在使用 ECDH 就加密会话密钥达成一致时，应使用至少 224 位的基点顺序和密钥大小，最好是 NIST P-384 曲线。

当使用 ECDH 协商加密会话密钥时，使用 NIST P-256、P-384 或 P-521 曲线，最好使用 NIST P-384 曲线。

当使用 ECDH 协商加密会话密钥时，使用 NIST P-384 或 P-521 曲线，最好是 NIST P-384 曲线。

使用椭圆曲线数字签名算法

从 NIST SP 800-186 中识别合适的曲线时，正确实施的 ECDSA 的基点顺序和 224 位密钥大小可提供 112 位的有效安全强度。不能假设从其他来源选择的曲线的安全性仅使用基点顺序和密钥大小就具有相同的安全性。

在使用 ECDSA 进行数字签名时，应使用至少 224 位的基点顺序和密钥大小，最好使用 P-384 曲线。

使用 ECDSA 进行数字签名时，使用 NIST P-256、P-384 或 P-521 曲线，最好使用 NIST P-384 曲线。

使用 ECDSA 进行数字签名时，使用 NIST P-384 或 P-521 曲线，最好是 NIST P-384 曲线。

使用 Rivest-Shamir-Adleman

正确实施的 RSA 的 2048 位模数可提供 112 位有效安全强度。考虑到预计的技术进步，据评估，到 2030 年，112 位有效安全强度仍将保持安全。

在使用 RSA 进行数字签名并传递加密会话密钥或类似密钥时，应使用至少 2048 位的模数，最好是 3072 位。

当使用 RSA 进行数字签名并传递加密会话密钥或类似密钥时，使用至少 3072 位的模数，最好是 3072 位。

当使用 RSA 进行数字签名以及传递加密会话密钥或类似密钥时，用于数字签名和传递加密会话密钥的是不同的密钥对。

使用哈希算法

对于大多数用途，输出大小为 224 位的哈希算法可提供 112 位的有效安全强度。同样，输出大小为 256 位的哈希算法可提供 128 位的有效安全强度，而输出大小为 384 位的哈希算法可提供 192 位的有效安全强度。只有 SHA-2 系列的哈希算法才被批准使用。

使用 SHA-2 进行散列时，使用的输出大小至少为 224 位，最好是 SHA-384。

使用 SHA-2 进行散列时，使用的输出大小至少为 256 位，最好是 SHA-384。

使用 SHA-2 进行散列时，使用至少 384 位的输出大小，最好是 SHA-384。

使用对称加密算法

电子密码本模式与分组密码结合使用，可使明文中的重复模式在密文中显示为重复模式。大多数明文（包括书面语言和格式化文件）都包含大量重复模式。因此，恶意行为者可借此推断密文的可能含义。使用其他模式（例如密码分组链接、密码反馈、伽罗瓦/计数器模式或输出反馈）可防止此类攻击，尽管每种模式都有不同的属性，可能不适合某些用例。AES 是唯一获批的对称加密算法。

使用 AES 进行加密时，使用 AES-128、AES-192 或 AES-256，最好使用 AES-256。

使用 AES 进行加密时，使用 AES-192 或 AES-256，最好是 AES-256。

电子密码本模式中不使用对称加密算法。

规划后量子密码标准

加密相关的量子计算机将使大多数当代公钥加密变得不安全，从而使基于当前公钥加密技术的无处不在的安全通信变得不可行。由于创建加密相关的量子计算机会带来新的安全风险，因此鼓励各组织在过渡到后量子加密标准期间考虑预测易受攻击系统的未来需求和依赖关系。

在向后量子密码标准过渡期间，会考虑未来的密码要求和依赖关系。

ASD 批准的加密协议

高可信度加密协议

本节未涉及的高保证加密协议，如果在 HACE 中适当实施，则可用于保护机密和绝密数据。有关高保证加密协议的更多信息，可从 ASD 获取。

ASD 批准的加密协议

协议无法保证能够抵抗目前未知的攻击。但是，本节列出的协议已在实践和理论环境中得到了行业和学术界的广泛审查。本节列出的协议的使用批准仅限于按照这些准则实施的情况。

AACP 包括：

传输层安全性 (TLS)
安全外壳 (SSH)
安全/多用途互联网邮件扩展 (S/MIME)
OpenPGP 消息格式
互联网协议安全 (IPsec)
Wi-Fi 保护访问 2
Wi-Fi 保护访问 3.

使用 ASD 认可的加密协议

如果加密设备或软件实施了未经批准的协议，则这些协议可能会在用户不知情的情况下被使用。结合假定的安全信心水平，这可能代表安全风险。因此，组织可以通过禁用未经批准的协议（首选）或通过使用政策建议用户不要使用未经批准的协议来确保只能使用 AACP 或高保证加密协议。

加密设备和软件仅使用 AACP 或高保证加密协议。

传输层安全性

使用传输层安全性

在使用实施 TLS 的 IT 设备或软件时，还需要查阅本指南中 ASD 批准的加密算法和 ASD 批准的加密协议部分中关于使用 AACA 和 AACP 的控制。

配置传输层安全性

传统上，“安全套接字层”和“TLS”这两个术语可以互换使用。但是，安全套接字层和 TLS 1.2 版及更早版本不再被视为适合用作 AACP。因此，实施 TLS 的组织应仅使用最新版本的 TLS（即 TLS 1.3 版）。此外，如果以不安全的方式配置 TLS，则存在许多安全风险。为了减轻这些安全风险，应将 TLS 客户端和服务器配置为在 TLS 握手时强制执行安全设置。在无法做到这一点的情况下，例如对于某些多租户环境（例如内容交付网络），则需要实施额外的控制。例如，通过进一步限制第 7 层授权逻辑中允许的 TLS 配置。

仅最新版本的 TLS 用于 TLS 连接。

AES-GCM 用于 TLS 连接的加密。

仅服务器发起的安全重新协商用于 TLS 连接。

DH 或 ECDH 用于 TLS 连接的密钥建立。

当使用 DH 或 ECDH 建立 TLS 连接的密钥时，使用临时变体。

匿名 DH 不用于 TLS 连接。

基于 SHA-2 的证书用于 TLS 连接。

SHA-2 用于 TLS 连接的基于哈希的消息认证码 (HMAC) 和伪随机函数 (PRF)。

TLS 连接禁用 TLS 压缩。

完美前向保密 (PFS) 用于 TLS 连接。

安全外壳

使用安全外壳

在使用实施 SSH 的 IT 设备或软件时，还需要查阅本指南中 ASD 批准的加密算法和 ASD 批准的加密协议部分中关于使用 AACA 和 AACP 的控制。

配置安全外壳

SSH 版本 1 被发现存在许多漏洞，随后被 SSH 版本 2 取代。因此，实施 SSH 的组织应禁用 SSH 版本 1。此外，如果以不安全的方式配置 SSH，则存在许多安全风险。为了减轻这些安全风险，应按照以下设置配置 SSH。

以下设置基于 OpenSSH。使用其他 SSH 实现的组织应调整这些设置以适应其 SSH 实现。

SSH 连接禁止使用 SSH 版本 1。

SSH 守护程序配置为：

仅监听所需的接口（ListenAddress xxx.xxx.xxx.xxx）
有合适的登录横幅（横幅 x）
登录认证超时时间不超过 60 秒（LoginGraceTime 60）
禁用基于主机的身份验证（HostbasedAuthentication no）
禁用基于 rhosts 的身份验证（IgnoreRhosts yes）
禁用直接以 root 身份登录的能力 (PermitRootLogin no)
禁用空密码（PermitEmptyPasswords no）
禁用连接转发（AllowTCPForwarding no）
禁用网关端口（GatewayPorts no）
禁用 X11 转发（X11Forwarding no）。

身份验证机制

由于基于公钥的身份验证方案比基于密码的身份验证方案提供更强的身份验证，并且更不容易受到暴力攻击，因此应将其用于 SSH 连接。此外，为了保护 SSH 私钥，应通过使用密码或密钥加密密钥来保护对此类密钥的访问。

基于公钥的身份验证用于 SSH 连接。

SSH 私钥受密码或密钥加密密钥保护。

自动远程访问

如果出于自动化目的而使用没有密码的登录，可能会出现许多安全风险，具体来说：

如果不限制来自未知互联网协议 (IP) 地址的访问，恶意行为者可以自动对系统进行身份验证，而无需知道任何密码
如果未禁用端口转发，或者未安全配置，则可能会获得对转发端口的访问权限，从而在恶意行为者和主机之间创建通信通道
如果启用了代理凭据转发，恶意行为者可以连接到存储的身份验证凭据，并使用它们连接到其他受信任的主机，如果允许端口转发，甚至可以连接到内联网主机
如果未禁用 X11 显示远程控制，恶意行为者可能会控制显示器以及键盘和鼠标控制功能
如果允许控制台访问，则登录控制台的每个用户都可以运行通常仅限于经过身份验证的用户运行的程序。

为了帮助减轻这些安全风险，必须使用“强制命令”选项来指定执行的命令并启用参数检查。

当使用无密码登录进行 SSH 连接时，以下内容将被禁用：

从不需要访问权限的 IP 地址进行访问
端口转发
代理凭证转发
X11 显示远程
控制台访问。

如果使用远程访问而不使用 SSH 连接的密码，则使用“强制命令”选项来指定执行什么命令并启用参数检查。

SSH 代理

SSH 代理和类似的密钥缓存程序管理存储在工作站和服务器上的私钥。具体来说，当 SSH 代理启动时，它会请求用户的密码来解锁用户的私钥。随后对远程系统的访问由 SSH 代理执行，不需要用户重新输入密码。可以使用屏幕锁定和过期密钥缓存来确保用户的私钥不会长时间处于解锁状态。

当使用 SSH 代理或类似的密钥缓存程序时，它仅限于具有屏幕锁和密钥缓存的工作站和服务器，这些缓存设置为在四小时不活动后过期。

安全/多用途互联网邮件扩展

使用安全/多用途互联网邮件扩展

在使用实施 S/MIME 的 IT 设备或软件时，还需要查阅本指南中 ASD 批准的加密算法和 ASD 批准的加密协议部分中关于使用 AACA 和 AACP 的控制。

配置安全/多用途互联网邮件扩展

S/MIME 2.0 版要求使用比本指南批准使用的加密技术更弱的加密技术。因此，S/MIME 3.0 版是第一个获准用作 AACP 的版本。

早于 S/MIME 3.0 版的 S/MIME 版本不用于 S/MIME 连接。

互联网协议安全

使用 Internet 协议安全

在使用实施 IPsec 的 IT 设备或软件时，还需要查阅本指南中 ASD 批准的加密算法和 ASD 批准的加密协议部分中关于使用 AACA 和 AACP 的控制。

操作方式

IPsec 可以在隧道模式或传输模式下运行。隧道模式是首选，因为它提供 IP 数据包的完整封装，而传输模式仅封装 IP 数据包的有效负载。

隧道模式用于 IPsec 连接；但是，如果使用传输模式，则使用 IP 隧道。

协议选择

IPsec 包含两个主要协议，即身份验证标头 (AH) 协议和封装安全有效负载 (ESP) 协议。为了提供安全的虚拟专用网络式连接，需要身份验证和加密。虽然 AH 和 ESP 协议可以分别为 IP 数据包和有效负载提供身份验证，但只有 ESP 协议可以提供加密。

由于互联网密钥交换（IKE）版本 2 不支持 AH 协议和 ESP 协议的组合使用，因此应使用 ESP 协议对 IPsec 连接进行身份验证和加密。

ESP 协议用于 IPsec 连接的身份验证和加密。

密钥交换

有多种方法可以为 IPsec 连接建立共享密钥材料，包括手动密钥和 IKE 协议。由于 IKE 协议解决了与手动密钥相关的许多安全风险，因此它是建立密钥的首选方法。请注意，由于 IKE 版本 1 已被弃用，因此应使用 IKE 版本 2。

IKE 版本 2 用于建立 IPsec 连接时进行密钥交换。

加密算法

唯一获准用于 IPsec 连接的加密算法是 AES。IKE 版本 2 支持使用带密码块链接的 AES、计数器模式、带密码块链接消息认证码的计数器以及 Galois/计数器模式。但请注意，不同的加密设备和软件支持的模式可能有所不同。

AES 用于加密 IPsec 连接，最好是 ENCR_AES_GCM_16。

伪随机函数算法

IKE 版本 2 需要使用 PRF 来生成用于加密操作的随机数据。可用于 PRF 的已批准算法是 HMAC-SHA256、HMAC-SHA384 和 HMAC-SHA512。PRF_HMAC_SHA2_256、PRF_HMAC_SHA2_384或PRF_HMAC_SHA2_512用于IPsec连接，最好是PRF_HMAC_SHA2_512。