Cryptographic algorithms—(Green-Book)加密算法

Cryptographic algorithms---加密算法

- - [9.2.3 加密算法](#9.2.3 加密算法)
  - [9.2.3.1 概述](#9.2.3.1 概述)
  - - [9.2.3.2 哈希函数](#9.2.3.2 哈希函数)
    - [9.2.3.3 对称密钥算法](#9.2.3.3 对称密钥算法)
    - - [9.2.3.3.1 概述](#9.2.3.3.1 概述)
      - [9.2.3.3.2 加密和解密](#9.2.3.3.2 加密和解密)
      - [9.2.3.3.3 高级加密标准](#9.2.3.3.3 高级加密标准)
      - [9.2.3.3.4 加密操作模式](#9.2.3.3.4 加密操作模式)
      - [9.2.3.3.5 消息认证码](#9.2.3.3.5 消息认证码)
      - [9.2.3.3.6 密钥包装](#9.2.3.3.6 密钥包装)
      - [9.2.3.3.7 Galois/Counter Mode](#9.2.3.3.7 Galois/Counter Mode)
      - [9.2.3.3.7.1 概述](#9.2.3.3.7.1 概述)
        
        [9.2.3.3.7.2 GCM函数](#9.2.3.3.7.2 GCM函数)
        
        [9.2.3.3.7.3 初始化向量 IV](#9.2.3.3.7.3 初始化向量 IV)
        
        [9.2.3.3.7.4 密钥，EK](#9.2.3.3.7.4 密钥，EK)
        
        [9.2.3.3.7.5 认证密钥，AK](#9.2.3.3.7.5 认证密钥，AK)
        
        [9.2.3.3.7.6 认证标签的长度](#9.2.3.3.7.6 认证标签的长度)
      - [9.2.3.3.8 AES 密钥包装](#9.2.3.3.8 AES 密钥包装)
    - [9.2.3.4 公钥算法](#9.2.3.4 公钥算法)
    - - [9.2.3.4.1 概述](#9.2.3.4.1 概述)
      - [9.2.3.4.2 椭圆曲线密码学](#9.2.3.4.2 椭圆曲线密码学)
      - [9.2.3.4.2.1 概述](#9.2.3.4.2.1 概述)
        
        [9.2.3.4.2.2 NIST推荐的椭圆曲线](#9.2.3.4.2.2 NIST推荐的椭圆曲线)
      - [9.2.3.4.3 数据转换](#9.2.3.4.3 数据转换)
      - [9.2.3.4.3.1 概述](#9.2.3.4.3.1 概述)
        
        [9.2.3.4.3.2 位字符串和八位字节字符串之间的转换 (BS2OS)](#9.2.3.4.3.2 位字符串和八位字节字符串之间的转换 (BS2OS))
        
        [9.2.3.4.3.3 八位字节字符串和位字符串之间的转换 (OS2BS)](#9.2.3.4.3.3 八位字节字符串和位字符串之间的转换 (OS2BS))
        
        [9.2.3.4.3.4 整数和八位字节字符串之间的转换 (I2OS)](#9.2.3.4.3.4 整数和八位字节字符串之间的转换 (I2OS))
        
        [9.2.3.4.3.5 八位字节字符串和整数之间的转换 (OS2I)](#9.2.3.4.3.5 八位字节字符串和整数之间的转换 (OS2I))
        
        [9.2.3.4.3.6 字段元素和八位字节字符串之间的转换 (FE2OS)](#9.2.3.4.3.6 字段元素和八位字节字符串之间的转换 (FE2OS))
        
        [9.2.3.4.3.7 八位字节字符串和字段元素之间的转换 (OS2FE)](#9.2.3.4.3.7 八位字节字符串和字段元素之间的转换 (OS2FE))
      - [9.2.3.4.4 数字签名](#9.2.3.4.4 数字签名)
      - [9.2.3.4.5 椭圆曲线数字签名 (ECDSA)](#9.2.3.4.5 椭圆曲线数字签名 (ECDSA))
      - [9.2.3.4.6 密钥协商](#9.2.3.4.6 密钥协商)
      - [9.2.3.4.6.1 概述](#9.2.3.4.6.1 概述)
        
        [9.2.3.4.6.2 临时统一模型 C(2e, 0s, ECC CDH) 方案](#9.2.3.4.6.2 临时统一模型 C(2e, 0s, ECC CDH) 方案)
        
        [9.2.3.4.6.3 一次性Diffie-Hellman C(1e, 1s, ECC CDH) 方案](#9.2.3.4.6.3 一次性Diffie-Hellman C(1e, 1s, ECC CDH) 方案)
        
        [9.2.3.4.6.4 静态统一模型 C(0e, 2s, ECC CDH) 方案](#9.2.3.4.6.4 静态统一模型 C(0e, 2s, ECC CDH) 方案)
        
        [9.2.3.4.6.5 NIST串联KDF](#9.2.3.4.6.5 NIST串联KDF)
    - [9.2.3.5 随机数生成](#9.2.3.5 随机数生成)
    - [9.2.3.6 压缩](#9.2.3.6 压缩)
    - [9.2.3.7 安全套件](#9.2.3.7 安全套件)
  - [9.2.4 密码密钥概述](#9.2.4 密码密钥概述)
  - [9.2.5 与对称密钥算法一起使用的密钥](#9.2.5 与对称密钥算法一起使用的密钥)
  - - [9.2.5.1 对称密钥类型](#9.2.5.1 对称密钥类型)
    - [9.2.5.2 通用密码APDU和数据保护中的密钥信息](#9.2.5.2 通用密码APDU和数据保护中的密钥信息)
    - [9.2.5.3 密钥识别](#9.2.5.3 密钥识别)
    - [9.2.5.4 密钥包装](#9.2.5.4 密钥包装)
    - [9.2.5.5 密钥协商](#9.2.5.5 密钥协商)
    - [9.2.5.6 对称密钥密码周期](#9.2.5.6 对称密钥密码周期)

9.2.3 加密算法

9.2.3.1 概述

密码学是数学的一个分支，基于数据的转换，并且可以用来提供多种安全服务：保密性、数据完整性、认证、授权和不可否认性。密码学依赖于两个基本组成部分：算法（或密码学方法）和密钥。算法是一个数学函数，而密钥是在转换过程中使用的参数。

密码算法和密钥用于对数据应用密码保护（例如，加密数据或生成数字签名），以及移除或检查保护（例如，解密加密的数据或验证数字签名）。有三种基本类型的经过批准的密码算法：

密码哈希函数：这类函数不需要密钥（尽管它们可以以使用密钥的模式使用）。哈希函数通常用作算法的一个组成部分，以提供安全服务。见9.2.3.2节。
对称密钥算法（通常称为秘密密钥算法）：这类算法使用单一密钥，由发送者和接收者共享，用于应用保护和移除或检查保护。对称密钥算法相对容易实现，并提供高吞吐量。见9.2.3.3节。
非对称密钥算法（通常称为公钥算法）：这类算法使用两把密钥（即，一把密钥对）：公钥和私钥，它们在数学上是相互关联的。与对称密钥算法相比，非对称密钥算法的实现更为复杂，需要更多的计算。见9.2.3.4节。

对于使用密码学算法的各方来说，重要的是要理解这些算法的基本概念和应用，以便在保护数据和确保通信安全方面做出明智的决策。

9.2.3.2 哈希函数

哈希函数可以生成一个较长消息的短表示形式。一个好的哈希函数是一个单向函数：从特定输入计算哈希值是容易的；然而，从哈希值反推回输入则极其困难。使用一个好的哈希函数，找到两个特定的输入产生相同哈希值也同样极其困难。因为这些特性，哈希函数经常用来确定数据是否发生了变化。

哈希函数接受任意长度的输入，并输出固定长度的值。哈希函数输出的常见名称包括哈希值和消息摘要。图 92 描述了哈希函数的使用。

在数据（M1）上计算一个哈希值（H1）。然后保存或传输 M1 和 H1。在稍后的时间，通过将检索到或接收到的数据标记为 M2（而不是 M1）并计算接收值的新哈希值（H2）来检查检索或接收数据的正确性。如果新计算的哈希值（H2）与检索或接收到的哈希值（H1）相等，那么可以假定检索或接收到的数据（M2）与原始数据（M1）相同（即 M1 = M2）。

在 DLMS/COSEM 中，哈希算法用于以下目的：

数字签名，见 9.2.3.4.4；
密钥协商，见 9.2.3.4.6；
高级安全级别（HLS）认证。使用的算法取决于认证机制，见 9.2.7.4。

请注意，这段翻译是根据您提供的标题内容进行的，可能缺少一些上下文中的细节。如果需要更全面的翻译或对特定段落的详细解释，请提供更具体的段落或内容。

9.2.3.3 对称密钥算法

9.2.3.3.1 概述

对称密钥算法在DLMS/COSEM中用于以下目的：

使用HLS认证机制对通信伙伴进行认证，见9.2.7.4；
对xDLMS消息进行认证和加密，见9.2.7.2；
对COSEM数据进行认证和加密，见9.2.7.5。

注意：以下文本摘自NIST SP 800-21:2005，3.3。

对称密钥算法（通常称为秘密密钥算法）使用单一密钥对数据进行保护，既可以应用保护措施，也可以移除或检查保护。例如，用于加密数据的密钥也用于解密加密后的数据。如果数据要保持其加密保护，则必须保密该密钥。对称密钥算法用于通过加密提供数据的保密性，或通过认证提供数据的真实性或完整性保证，或在密钥建立过程中使用。

用于一个目的的密钥不应用于其他目的。（见NIST SP 800-57:2012）。

9.2.3.3.2 加密和解密

注意：以下文本摘自NIST SP 800-21:2005，3.3.1。

加密用于为数据提供保密性。要保护的数据称为明文。加密将数据转换为密文。使用解密可以将密文转换回明文。

只有使用加密数据时所使用的相同密钥，才能从密文中恢复明文。知道加密算法但不具备正确密钥的未授权接收者不应能够解密密文。然而，任何拥有密钥和加密算法的人都能够轻松解密密文并获得原始的明文数据。

图93描述了加密和解密过程。使用密钥（K）通过加密过程将明文（P）转换为密文（C）。解密时，使用相同的密钥（K）通过解密过程将密文（C）恢复为明文（P）。

在使用对称密钥块加密算法时，相同的明文块和密钥总是会产生相同的密文块。这种属性没有提供可接受的安全性。因此，已经定义了加密操作模式来解决这个问题（见9.2.3.3.4）。

9.2.3.3.3 高级加密标准

对于DLMS/COSEM的目的，应使用FIPS PUB 197:2001中指定的高级加密标准（AES）。AES在加密或解密操作期间对数据块（块）进行操作。因此，AES被称为块密码算法。

注意：以下文本摘自NIST SP 800-21:2005，3.3.1.3。

AES使用128、192或256位密钥加密和解密128位数据块。所有三种密钥大小都是足够的。

AES提供了安全性、性能、效率、易于实现和灵活性的组合。具体来说，该算法在硬件和软件中表现良好，适用于各种计算环境。此外，该算法的内存需求非常低，使其非常适合空间受限的环境。

9.2.3.3.4 加密操作模式

注意：以下文本摘自NIST SP 800-21:2005，3.3.1.4。

使用对称密钥块密码算法时，相同的明文块使用相同的对称密钥总是会加密成相同的密文块。如果消息（数据流）中的多个块被单独加密，攻击者可以轻易地替换单个块，可能不会被检测到。此外，明文中的某些数据模式，如重复的块，在密文中会很明显。

已经定义了加密操作模式来解决这个问题，通过将基本加密算法与可变的初始化值（通常称为初始化向量）和来自加密操作的信息的反馈规则结合起来。

NIST SP 800-38D:2007指定了Galois/Counter Mode (GCM)，这是一种用于带关联数据的认证加密的算法，以及其专门化形式GMAC，用于在不加密的数据上生成消息认证码（MAC）。GCM和GMAC是基础批准的对称密钥块密码的运作模式。见9.2.3.3.3。

9.2.3.3.5 消息认证码

注意：以下文本摘自NIST SP 800-21:2005，3.3.2。

消息认证码（MACs）提供数据的真实性和完整性保证。MAC是数据上的加密校验和，用于确保数据未被更改或篡改，并且MAC是由预期方（发送方）计算的。通常，MAC在两个共享密钥的方之间用于认证交换的信息。

图94描述了消息认证码（MACs）的使用。

使用密钥（K）对数据（M1）计算一个MAC（MAC1）。然后保存或传输M1和MAC1。在稍后的时间，通过将检索或接收到的数据标记为M2，并使用相同的密钥（K）计算一个新的MAC（MAC2），来检查检索或接收数据的真实性。如果检索或接收到的MAC（MAC1）与新计算的MAC（MAC2）相同，那么可以假定检索或接收到的数据（M2）与原始数据（M1）相同（即 M1 = M2）。验证方还知道发送方是谁，因为没有人知道密钥。

通常，MAC用于检测在最初生成MAC和验证接收到的MAC之间发生的数据显示修改。它们不检测在最初生成MAC之前发生的错误。

使用非密码技术，如错误检测码，经常提供消息完整性，但密码技术，如MAC，解决了这个问题。也就是说，MAC提供的完整性基于这样的假设：如果没有知道密码密钥，就不可能生成MAC。不知道密钥的攻击者将无法修改数据，然后生成修改后数据的有效MAC。因此，保持MAC密钥的秘密至关重要。

对于DLMS/COSEM的目的，应使用9.2.3.3.7.2中指定的GMAC算法。

9.2.3.3.6 密钥包装

注意：以下文本摘自NIST SP 800-21:2005，3.3.3。

对称密钥算法可能用于使用密钥包装密钥（也称为密钥加密密钥）加密密钥材料。然后，包装后的密钥材料可以安全地存储或传输。使用与原始包装过程中使用的相同密钥包装密钥来解开密钥材料。

密钥包装与简单加密不同，因为包装过程包括一个完整性特性。在解开过程中，这个完整性特性可以检测到包装密钥材料的意外或故意修改。对于DLMS/COSEM的目的，应使用AES密钥包装算法；见9.2.3.3.8。

9.2.3.3.7 Galois/Counter Mode

9.2.3.3.7.1 概述

注意：以下文本取自NIST SP 800-38D:2007，第3条。

Galois/Counter Mode (GCM) 是一种带关联数据的认证加密算法。GCM由一个128位块大小的批准对称密钥块密码构成，例如高级加密标准（AES）算法，见FIPS PUB 197。因此，GCM是AES算法的一种操作模式。

GCM使用Counter模式的变化为数据的保密性提供保证。

GCM使用定义在二元Galois（即有限）域上的通用哈希函数（GHASH），为保密数据的真实性提供保证（每次调用最多约64千兆字节）。GCM还可以为未加密的附加数据（每次调用的实际长度几乎不受限制）提供认证保证。

如果GCM的输入被限制为不需要加密的数据，则GCM的变体，称为GMAC，只是在输入数据上的认证模式。

GCM提供了比（非密码学的）校验和或错误检测代码更强的认证保证；特别是，GCM可以检测到1）数据的意外修改和2）故意的、未经授权的修改。

在DLMS/COSEM中，也可以使用GCM仅提供保密性：在这种情况下，不计算和检查认证标签。

9.2.3.3.7.2 GCM函数

注意：以下基于NIST SP 800-38D:2007，5.2。

GCM由两个功能组成，称为认证加密和认证解密；见图95。

图95 GCM函数

认证加密函数对保密数据进行加密，并在保密数据和任何附加的非保密数据上计算认证标签。认证解密函数在验证标签的基础上对保密数据进行解密。

当输入被限制为非保密数据时，GCM的变体称为GMAC。对于GMAC，认证加密和解密函数成为在非保密数据上生成和验证认证标签的函数。

最后，如果不需要认证，认证加密函数对保密数据进行加密，但不计算认证标签。认证解密函数对保密数据进行解密，但不计算和验证认证标签。

在DLMS/COSEM中，使用认证和加密由安全控制字节的第4位和第5位指示，见9.2.7.2.4。

a) 给定块密码密钥 EK 的认证加密函数有三个输入字符串：

明文，表示为 P；
附加认证数据 (AAD)，表示为 A；
初始化向量 (IV)，表示为 IV。

明文和 AAD 是 GCM 保护的两类数据。GCM 保护明文和 AAD 的真实性；GCM 还保护明文的保密性，而 AAD 则保持明文形式。

IV 本质上是一个随机数，即在指定（安全）上下文中唯一的值，它决定了对要保护的输入数据调用认证加密函数的实例。见 9.2.3.3.7.3。

输入字符串到认证加密函数的比特长度应满足以下要求：

len§ < 2^39 - 256；
len(A) < 2^64 - 1；
1 < len(IV) < 2^64 - 1。

P、A 和 IV 的比特长度都应是8的倍数，以便这些值为字节字符串。

有两个输出：

密文，表示为 C，其比特长度与明文 P 相同；
认证标签，或简称为标签，表示为 T。

b) 给定块密码密钥 EK 的认证解密函数有四个输入字符串：

初始化向量，表示为 IV；
密文，表示为 C；
附加认证数据 (AAD)，表示为 A；
认证标签，表示为 T。

输出是以下之一：

对应于密文 C 的明文 P，
或者在这个技术报告中表示为 FAIL 的特殊错误代码。

输出 P 表示 T 是 IV、A 和 C 的正确认证标签；否则，输出为 FAIL。

9.2.3.3.7.3 初始化向量 IV

在 DLMS/COSEM 中，用于构造初始化向量 IV 的确定性构造，如 NIST SP 800-38D:2007，8.2.1 所指定：IV 是两个字段的串联，称为固定字段和调用字段。固定字段应识别物理设备，或更一般地，该实例的认证加密函数的（安全）上下文。调用字段应识别特定设备中认证加密函数的输入集。

对于任何给定的密钥，没有两个不同的物理设备应共享相同的固定字段，并且任何单个设备中没有两个不同的输入集应共享相同的调用字段。

IV 的长度应为 96 位（12 个八位字节）：len(IV) = 96。在这个长度内：

最前面的（即最左边的）64 位（8 个八位字节）应包含固定字段。它应包含系统标题，见 4.3.4；
后面的（即最右边的）32 位应包含调用字段。调用字段应是一个整型计数器。

每个加密密钥 (EK) 有两个与之关联的调用计数器 (IC)，一个用于认证加密函数，另一个用于认证解密函数。EK 用于块密码。以下规则适用：

当密钥建立时，相应的 IC 被重置为 0；
当使用认证加密函数时，使用相应的 IC，然后将其增加 1。如果 IC 的最大值已被达到，任何进一步的认证加密函数调用应返回错误，并且 IC 不应被增加。

当使用认证解密函数时，将验证 IC 的值。该值必须等于或大于最低可接受值。

如果正在验证的值满足此要求，则在认证解密函数使用后，将最低可接受值设置为验证的 IC 值加 1。如果正在验证的值小于最低可接受值，则验证失败，认证解密函数也失败。如果正在验证的值等于最大值，则认证解密函数应返回错误。

注意：最大调用次数为 2^32 - 1。

固定字段的比特长度限制了可以为给定密钥实现认证加密函数的不同物理设备的数量为 2^64。调用字段的比特长度限制了在不违反唯一性要求的情况下，对任何给定输入集的认证加密函数的调用次数为 2^32。

9.2.3.3.7.4 密钥，EK

GCM 使用单一密钥，即块密码密钥。在 DLMS/COSEM 中，这被称为加密密钥，表示为 EK。其大小取决于安全套件，见 9.2.3.7，应为：

对于安全套件 0 和 1，128 位（16 个八位字节）：len(EK) = 128；
对于安全套件 2，256 位（32 个八位字节）：len(EK) = 256。

密钥应随机生成，或接近随机生成，即每个可能的密钥都有可能被生成。因此，密钥将是新鲜的，即与任何以前的密钥都不相等，可能性很高。密钥应保密，并且仅用于使用所选的 AES 块密码的 GCM。关于密钥的建立和管理的额外要求在 NIST SP 800-38D:2007，8.1 中进行了讨论。

9.2.3.3.7.5 认证密钥，AK

在 DLMS/COSEM 中，为了额外的安全性，还指定了一个认证密钥，表示为 AK。当存在时，它应是附加认证数据，AAD 的一部分。其长度和生成规则与加密密钥相同。

9.2.3.3.7.6 认证标签的长度

认证标签的比特长度，表示为 t，是一个安全参数。在安全套件 0、1 和 2 中，其值应为 96 位。

9.2.3.3.8 AES 密钥包装

对于密钥数据的包装，DLMS/COSEM 选择了 RFC 3394 中指定的 AES 密钥包装算法。该算法旨在包装或加密密钥数据。它以 64 位的块操作。在包装之前，将密钥数据解析为 n 个 64 位的块。密钥包装算法对 n 的唯一限制是 n 至少为 2。

AES 密钥包装可以配置为使用 AES 密码本支持的任何三种密钥大小：128、192、256。

有两种算法：密钥包装和密钥解包。

密钥包装过程的输入是密钥加密密钥 KEK 和要包装的明文。明文由 n 个 64 位块组成，包含要包装的密钥数据。输出是密文，(n+1) 个 64 位值。

解包过程的输入是 KEK 和之前包装的 (n+1) 个 64 位块的密文。它返回 n 个块的明文，包含解密后的 n 个 64 位块的密钥数据。

在 DLMS/COSEM 中，KEK 的大小取决于安全套件，见 9.2.3.7，应为：

对于安全套件 0 和 1，128 位（16 个八位字节）：len(KEK) = 128；
对于安全套件 2，256 位（32 个八位字节）：len(KEK) = 256。

请注意，这是对文档中 "9.2.3.3 对称密钥算法" 部分的详细翻译。由于篇幅限制，这里只提供了部分翻译。如果您需要更多内容的翻译，请告知。

9.2.3.4 公钥算法

9.2.3.4.1 概述

通常，公钥密码系统使用难以解决的问题作为算法的基础。RSA算法基于大整数的质因数分解。椭圆曲线密码学（ECC）基于椭圆曲线离散对数问题（ECDLP）的难度。ECC在提供类似安全级别的情况下，与RSA相比具有显著减少的密钥尺寸。ECC特别适合于嵌入式设备，因此它已被选为DLMS/COSEM的使用。

公钥算法在DLMS/COSEM中用于以下目的：

通信伙伴的身份认证；
xDLMS APDUs和COSEM数据的数字签名；
密钥协商。

注意：以下文本摘自NIST SP 800-21:2005，3.4。

非对称密钥算法（通常称为公钥算法）使用两个密钥：一个公钥和一个私钥，它们在数学上是相关的。公钥可以公开；私钥必须保密，以保持数据的加密保护。尽管两个密钥之间存在关系，但私钥不能从公钥中确定。使用哪个密钥来应用与移除或检查保护取决于要提供的服务。例如，数字签名是使用私钥计算的，签名是使用相应的公钥进行验证的；对于那些也能加密的算法，加密是使用公钥执行的，解密是使用私钥执行的。

注意：并非所有的公钥算法都能执行多个功能，例如生成数字签名和加密。在DLMS/COSEM中，非对称密钥算法不用于加密。

非对称密钥算法主要用于数据完整性、身份认证和不可否认性机制（即数字签名）以及密钥建立。一些非对称密钥算法使用域参数，这些是密码算法运行所必需的附加值。这些值在数学上是相互关联的。域参数通常是公共的，并且被一群用户长期使用。

安全使用非对称密钥算法需要用户获得以下保证：

域参数有效性的保证提供了对域参数在数学上正确性的信心；
公钥有效性的保证提供了公钥看起来是一个合适的密钥的信心；
私钥拥有性的保证提供了对被认为是私钥所有者的当事方确实拥有密钥的信心。

一些非对称密钥算法可能用于多个目的（例如，用于数字签名和密钥建立）。用于一个目的的密钥不应用于其他目的。

9.2.3.4.2 椭圆曲线密码学

9.2.3.4.2.1 概述

椭圆曲线密码学涉及在有限域上的椭圆曲线上的算术运算。椭圆曲线可以定义在任何数字字段上（即实数、整数、复数），尽管它们最常用于有限素数域上的密码学应用。

一个素数域上的椭圆曲线由满足以下方程的实数对 (x, y) 组成：

[ y^2 = x^3 + ax + b \mod p ]

其中，( p ) 是一个素数，( a ) 和 ( b ) 是常数。改变 ( a ) 和 ( b ) 会改变曲线的形状，这些参数的微小变化可能导致 ( (x, y) ) 解决方案集发生重大变化。

9.2.3.4.2.2 NIST推荐的椭圆曲线

FIPS PUB 186-4:2013推荐了五个素数域GF§上的椭圆曲线。其中，P-256和P-384曲线已被选为DLMS/COSEM使用，如表21所示。

表21 DLMS/COSEM安全套件中的椭圆曲线

安全套件	曲线名称在FIPS PUB 186-4:2013中	ASN.1对象标识符
套件0	NIST曲线P-256	1.2.840.10045.3.1.7
套件1	NIST曲线P-256	1.2.840.10045.3.1.7
套件2	NIST曲线P-384	1.3.132.0.34

注意：ASN.1对象标识符出现在证书下的AlgorithmIdentifier: Parameters中。见9.2.6.4.2。

9.2.3.4.3 数据转换

9.2.3.4.3.1 概述

本条款描述了用于在公钥算法中指定的不同数据类型之间进行转换的数据转换原语：八位字节字符串(OS)、位字符串(BS)、整数(I)、字段元素(FE)和椭圆曲线点(ECP)。DLMS/COSEM使用八位字节字符串表示公钥算法中的元素，并使用这些数据类型与八位字节字符串之间的转换原语。八位字节字符串Md1 Md2 0的长度为d，被编码为A-XDR OCTET STRING，其中最左边的八位字节Md1对应编码的OCTET STRING的第一个八位字节。

9.2.3.4.3.2 位字符串和八位字节字符串之间的转换 (BS2OS)

将位字符串转换为八位字节字符串的数据转换原语称为位字符串到八位字节字符串转换原语，或BS2OS。它以位字符串为输入，输出八位字节字符串。长度为l的位字符串bl1 bl2 0应转换为长度为d = l/8的八位字节字符串Md1 Md2 0。

转换通过在左侧填充足够的零，使位数为八的倍数，然后将其分解为八位字节。

更准确地说，转换应如下进行：

对于1，八位字节M = b8i+7 b8i+6 ... b8i;
最左边的八位字节Md1应将其最左边的8d-l位设置为零；
其最右边的8(8d-l)位应为bl1 bl2 8d-8。

9.2.3.4.3.3 八位字节字符串和位字符串之间的转换 (OS2BS)

将八位字节字符串转换为位字符串的数据转换原语称为八位字节字符串到位字符串转换原语，或OS2BS。它以八位字节字符串为输入，输出位字符串。长度为d的八位字节字符串Md1 Md2 0应转换为所需长度l的位字符串bl1 bl2 0，其中d = l/8，最左边的8d-l位最左边的八位字节为零。

更准确地说，转换应如下进行：

对于1，位b8i+7 b8i+6 ... b8i = Mi;
最左边的八位字节的最左边(8d-l)位应为零。

9.2.3.4.3.4 整数和八位字节字符串之间的转换 (I2OS)

将整数转换为八位字节字符串的数据转换原语称为整数到八位字节字符串转换原语，或I2OS。它以非负整数x和所需的八位字节字符串长度d作为输入。长度d必须满足256^d > x的条件，相应的八位字节字符串。

整数x应以唯一的l位表示法以256为基数表示：

[ x = x_{d-1} \cdot 256^{d-1} + x_{d-2} \cdot 256^{d-2} + \ldots + x_1 \cdot 256 + x_0 ]

其中，对于0 ≤ i < 256；Mi = xi，对于i = -1。

输出的八位字节字符串应为Md-1 Md-2 0。

9.2.3.4.3.5 八位字节字符串和整数之间的转换 (OS2I)

将八位字节字符串转换为整数的数据转换原语称为八位字节字符串到整数转换原语，或OS2I。它以长度为d的八位字节字符串Md1 Md2 0作为输入，并输出相应的整数x。在八位字节字符串长度为零的情况下，转换输出整数0。

每个八位字节被解释为256进制的非负整数。更准确地说，转换应如下进行：

xi = Mi，对于0 ≤ i < 256；
x = x_{d-1} \cdot 256^{d-1} + x_{d-2} \cdot 256^{d-2} + \ldots + x_1 \cdot 256 + x_0。

9.2.3.4.3.6 字段元素和八位字节字符串之间的转换 (FE2OS)

将字段元素转换为八位字节字符串的数据转换原语称为字段元素到八位字节字符串转换原语，或FE2OS。它以字段元素为输入，输出相应的八位字节字符串，字段元素到八位字节字符串转换原语（FE2OS）将字段元素作为输入，并输出相应的八位字节字符串。字段元素 ( x ) 在有限域 ( F_p ) 上转换为长度为 ( \lceil \log_2{p} \rceil ) 的八位字节字符串 ( M_1 M_2 \ldots M_d )，方法是应用整数到八位字节字符串转换原语（I2OS），参数 ( l ) 为：

[ \text{FE2OS}(x) = \text{I2OS}(x, l) ]

9.2.3.4.3.7 八位字节字符串和字段元素之间的转换 (OS2FE)

八位字节字符串到字段元素转换原语（OS2FE）将八位字节字符串作为输入，并输出相应的字段元素。长度为 ( d ) 的八位字节字符串 ( M_1 M_2 \ldots M_d ) 转换为有限域 ( F_p ) 上的字段元素 ( x )，方法是应用八位字节字符串到整数转换原语（OS2I），然后取模 ( p )：

[ \text{OS2FE}(x) = \text{OS2I}(x) \mod p ]

9.2.3.4.4 数字签名

数字签名是电子形式的签名，可用于向接收者或第三方证明消息是由发起者签名的（这被称为不可否认性）。数字签名还可以为存储的数据和程序生成，以便在以后验证数据和程序的完整性。

数字签名验证签名数据的完整性以及签名者的身份。在计算机中，数字签名表示为一串比特，并且使用提供生成和验证签名功能的数字签名算法来计算。签名生成使用私钥来生成数字签名。签名验证使用与私钥相对应的公钥进行，但不是私钥。每个签名者都有一对私钥和公钥。签名生成只能由签名者的私钥持有者执行。然而，任何人都可以通过使用签名者的公钥来验证签名。

数字签名系统的安全性取决于保持签名者私钥的秘密性。因此，用户必须防范他们的私钥被未经授权的获取。

9.2.3.4.5 椭圆曲线数字签名 (ECDSA)

对于DLMS/COSEM，选择了FIPS PUB 186-4:2013中指定的椭圆曲线数字签名（ECDSA）算法。NSA1提供了一个实施指南。

在DLMS/COSEM中，使用的椭圆曲线和算法为：

在安全套件1中，使用椭圆曲线P-256和SHA-256哈希算法；
在安全套件2中，使用椭圆曲线P-384和SHA-384哈希算法。

ECDSA数字签名生成的输入包括：

要签名的消息 ( M )；
签名者的私钥 ( d )。

输出是在消息 ( M ) 上的ECDSA签名 ( (r, s) )。

在DLMS/COSEM中，使用明文格式：签名 ( (r, s) ) 被编码为八位字节字符串 ( R | S )，即 ( R = I2OS(r, l) ) 和 ( S = I2OS(s, l) ) 的串联，其中 ( l = \lceil \log_{256} n \rceil )。因此，签名的长度固定为2 ( l ) 个八位字节。

注意：这里，( n ) 是椭圆曲线基点 ( G ) 的阶数。I2OS是整数到八位字节字符串转换原语。见9.2.3.4.3。

ECDSA数字签名验证生成的输入包括：

已签名的消息；
接收到的ECDSA签名 ( (r, s) )；
签名者的公钥 ( Q )。

生成和验证签名的过程应按照NSA1，3.4的规定。

9.2.3.4.6 密钥协商

9.2.3.4.6.1 概述

密钥协商允许两个实体共同计算一个共享密钥，并从中派生出密钥材料。见NIST SP 800-56A Rev. 2: 2013。

9.2.3.4.6.2 临时统一模型 C(2e, 0s, ECC CDH) 方案

此方案用于DLMS客户端和服务器之间，以就主密钥、全局加密密钥和/或认证密钥达成一致。客户端扮演党U的角色，服务器扮演党V的角色。

注意：a) 每方都有相同一组域参数D的可靠副本。D应从附录A中的两组域参数中选择；b) 双方已同意使用NIST串联KDF；c) 在密钥协商过程中或之前，双方获得与对方关联的标识符。

9.2.3.4.6.3 一次性Diffie-Hellman C(1e, 1s, ECC CDH) 方案

此方案由DLMS服务器和另一方使用，以就用于保护xDLMS APDUs或COSEM数据的临时加密密钥达成一致。发送消息的一方（发起方）扮演党U的角色，另一方（接收方）扮演党V的角色。

9.2.3.4.6.4 静态统一模型 C(0e, 2s, ECC CDH) 方案

9.2.3.4.6.5 NIST串联KDF

在DLMS/COSEM中，应使用NIST SP 800-56A Rev. 2: 2013和NSA2，第5条中指定的NIST串联密钥派生函数（KDF）。其如下：

函数调用：kdf(Z, OtherInput)

其中OtherInput由keydatalen和OtherInfo组成。

9.2.3.5 随机数生成

应提供强大的随机数生成器（RNG），以生成DLMS/COSEM中使用的算法所需的随机数。RNG应首选非确定性的。如果非确定性RBG不可用，则系统应使用足够的熵来为确定性RNG创建良好的种子。

9.2.3.6 压缩

压缩不涉及密码学，但它是对xDLMS APDU的转换。因此，它与对称密钥密码学一起被控制，并在此处指定。

9.2.3.7 安全套件

安全套件确定了各种密码原语可用的密码算法集和密钥尺寸。

DLMS/COSEM安全套件见表27基于NSA套件B，并包括用于身份验证、加密、密钥协商、数字签名和哈希的密码算法：

身份验证和加密：高级加密标准（AES），如FIPS PUB 197中指定，密钥尺寸为128和256位。AES应与NIST SP 800-38D:2007中指定的Galois/Counter Mode (GCM)操作模式一起使用；
数字签名：椭圆曲线数字签名算法（ECDSA），如FIPS PUB 186-4:2013和NSA1中指定，使用P-256或P-384曲线；
密钥协商：使用椭圆曲线P-256或P-384的Ephemeral Unified Model C(2e, 0s, ECC CDH)方案、One-Pass Diffie-Hellman C(1e, 1s, ECC CDH)方案和Static Unified Model C(0e, 2s, ECC CDH)方案；
哈希：安全哈希算法（SHA）SHA-256和SHA-384，如FIPS PUB 180-4:2012中指定。

此外，还有密钥包装和压缩算法可用。

9.2.4 密码密钥概述

密码密钥是与密码算法一起使用的参数，它以这样的方式确定算法的操作，即知道密钥的实体可以重现或逆转操作，而不知道密钥的实体则不能。在DLMS/COSEM中，操作的例子包括：

将明文转换为密文；
将密文转换为明文；
计算和验证认证码（MAC）；
密钥包装；
应用和验证数字签名；
密钥协商。

与对称密钥算法一起使用的密钥在9.2.5中指定。与公钥算法一起使用的密钥在9.2.6中指定。

9.2.5 与对称密钥算法一起使用的密钥

9.2.5.1 对称密钥类型

对称密钥根据以下分类：

a) 它们的用途：

密钥加密密钥（KEK）用于加密/解密其他对称密钥；见9.2.5.4。在DLMS/COSEM中，这是主密钥；
加密密钥用作AES-GCM算法的块密码密钥，见9.2.3.3.7.4；
认证密钥用作AES-GCM算法中的附加认证数据（AAD），见9.2.3.3.7.5。

b) 它们的生命周期：

静态密钥，预期在相对较长的时间内使用。在DLMS/COSEM中，这些可能是：
- 全局密钥，可在相同伙伴之间反复建立的多个应用关联（AAs）上使用。全局密钥可以是单播加密密钥（GUEK）、广播加密密钥（GBEK）或认证密钥（GAK）；
- 专用密钥，可在两个伙伴之间建立的单个AA中反复使用。因此，它的生命周期与AA的生命周期相同。专用密钥只能是单播加密密钥。
临时密钥，通常在AA内的一次交换中使用。

对于生成和分发对称密钥，见NIST SP 800-57:2012，8.1.5.2。

主密钥和全局密钥是在每对DLMS客户端服务器之间使用表28中显示的方法之一建立的。它们应该在适当的间隔内更新，见9.2.3.3.7.3和9.2.5.6。

专用密钥由DLMS客户端生成，并通过xDLMS InitiateRequest APDU中的专用密钥字段传输到服务器，该字段由AARQ APDU的用户信息字段携带。当存在专用密钥时，xDLMS InitiateRequest APDU必须使用AES-GCM-128/256算法、全局单播加密密钥以及如果使用的话，见9.2.3.3.7.5的认证密钥进行认证和加密。由AARE APDU的用户信息字段携带的xDLMS InitiateResponse APDU也应以相同的方式加密和认证。当使用专用密钥时，安全控制字节的密钥集位，见表45不相关，应设置为零。

注意 AARQ和AARE APDUs本身不受保护。

表28总结了对称密钥类型、它们的用途、建立它们的方法以及它们在不同APDUs和不同实体之间的使用。

9.2.5.2 通用密码APDU和数据保护中的密钥信息

当使用通用密码APDU保护xDLMS APDUs或保护COSEM数据时，发送方将发送有关已使用/将要使用的密钥的必要信息，以及加密的xDLMS APDU/COSEM数据。

所需的密钥信息总结在表29中，并在9.2.5.3、9.2.5.4和9.2.5.5中进一步指定。

9.2.5.3 密钥识别

识别的密钥可能是全局单播加密密钥（GUEK）或全局广播加密密钥（GBEK）。在这种情况下，安全控制字节的密钥集位，见表45不相关，应设置为零。

9.2.5.4 密钥包装

密钥包装可用于建立静态或临时对称密钥。

使用的算法是9.2.3.3.8中指定的AES密钥包装算法。KEK是主密钥。因此，这种方法只能在共享主密钥的方之间使用，即在客户端和服务器之间。

可以使用密钥包装建立的静态密钥可能是：

主密钥，KEK；
全局单播加密密钥，GUEK；
全局广播加密密钥，GBEK；
（全局）认证密钥，GAK。

为了使用密钥包装建立这些静态密钥，密钥应首先由客户端生成，然后通过调用key_transfer方法传输到服务器，见DLMS UA 1000-1第2部分Ed.15:2021，4.4.7。方法调用参数应携带key_id(s)和wrapped key(s)。携带调用该方法的服务以及方法调用参数的APDU应根据安全策略和访问权限受到保护。

注意项目特定的配套规范中可以指定所需的保护级别。

为了使用密钥包装建立临时密钥，xDLMS APDU或COSEM数据的发起方随机生成一个临时密钥。这个密钥应使用AES密钥包装算法和KEK进行包装，并与已使用临时密钥加密的xDLMS APDU或COSEM数据一起发送给接收方。接收方应解开密钥，然后使用它来解密接收到的xDLMS APDU/COSEM数据。

9.2.5.5 密钥协商

密钥协商可用于在服务器和客户端之间建立静态密钥或临时密钥。可用不同的密钥协商方案建立不同的密钥。

Ephemeral Unified Model C(2e,0s, ECC CDH)方案可由客户端和服务器用于就以下内容达成一致：

主密钥，KEK；
全局单播加密密钥，GUEK；
全局广播加密密钥，GBEK；
（全局）认证密钥，GAK。

此方案由key_agreement方法支持，见DLMS UA 1000-1第2部分Ed.15:2021，4.4.7。方法调用参数携带9.2.3.4.6.2中指定的必要的参数。携带调用该方法的服务以及方法调用参数的APDUs应根据安全策略和访问权限受到保护。另见附录C。

注意项目特定的配套规范中可以指定所需的保护级别。

为了使用密钥协商建立用作块密码密钥的临时加密密钥，有两种方案可用：

一次性Diffie-Hellman C(1e, 1s, ECC CDH)方案，见9.2.3.4.6.3；
静态统一模型C(0e, 2s, ECC CDH)方案，见9.2.3.4.6.4。

除非项目特定的配套规范另有规定，否则应使用C(1e, 1s ECC CDH)方案。

9.2.5.6 对称密钥密码周期

对称密钥密码周期应在项目特定的配套规范中确定。NIST SP 800-57:2012第1部分，5.3.5对称密钥使用周期和密码周期和5.3.6特定密钥类型的密码周期建议中给出了建议。