DLMS/COSEM中公开密钥算法的使用_密钥协商

        密钥协商允许两个实体共同计算共享密钥并从中获得密钥材料。在DLMS/COSEM中，三个椭圆曲线密钥协商方案已经被NIST SP 800- 56A Rev. 2: 2013选中。

        • the Ephemeral Unified Model C(2e, 0s, ECC CDH) scheme;

        • the One-Pass Diffie-Hellman C(1e,1s, ECC CDH) scheme;

        • the Static Unified Model C(0e, 2s, ECC CDH) scheme.

         注：对于NSA Suite B，已选择前两个方案

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

        此方案用于DLMS/COSEM客户端和服务器之间就主密钥、全局加密密钥和/或认证密钥达成一致。客户端扮演U方角色，服务器扮演v方角色，过程由“安全设置”接口类的方法支持; 

        双方根据域参数d生成临时密钥对，交换临时公钥，然后利用域参数、各自的临时私钥和对方的临时公钥计算共享密钥Z。密钥材料是使用9.2.3.4.6.5中指定的密钥推导函数从共享密钥Z和其他输入中推导出来的。 

        NIST SP 800-56A Rev. 2: 2013, 6.1.2.2和NSA2, 3.1中详细描述了该过程，如下图72和表14所示。

        U方： 

        1. U使用自己的临时私钥d e, U和V的临时公钥Q e, V组成共享秘密。 

        2. U使用共享密钥调用密钥派生函数。 

        V方：

        1. V使用自己的临时私钥d e, V和U的临时公钥Q e, U组成共享秘密。 

        2. V使用共享密钥调用密钥派生函数。

        先决条件： 

        a)双方均拥有同一套域参数的真实副本，D. D应从两套域参数中选择一套，见附件a;

        b)双方同意使用NIST级联KDF;查看9.2.3.4.6.5。SHA-256是用于P-256域参数的散列函数，SHA-384是用于P-384域参数的散列函数。 

        c)在密钥协商过程之前或过程中，双方获得与另一方在密钥协商方案中关联的标识符。 

        表14 -临时统一模型密钥协议方案摘要 

         选择C(2e, 0s)方案的基本原理在NIST SP 800-56A Rev. 2: 2013, 8.2中有详细说明。
在C.1中进一步解释了该方案在DLMS/COSEM中的使用。

2.一遍Diffie-Hellman C(1e, 1s, ECC CDH)方案 

        该方案用于DLMS/COSEM服务器和另一方就临时加密密钥达成协议，以保护xDLMS apdu或COSEM数据。发送方(发送方)扮演U方，另一方(接收方)扮演V方。 

        在该方案中，U方生成一个临时密钥对;V方只有一个静态密钥对。甲方以可信的方式(例如，从经可信CA签名的证书中)获得V的静态公钥，并将其临时公钥发送给V。双方使用自己的私钥和对方的公钥派生共享秘密Z。各方使用9.2.3.4.6.5中规定的密钥派生方法从共享密钥Z和其他输入派生密钥材料。

        NIST SP 800-56A Rev. 2: 2013, 6.2.2.2和NSA2, 3.2详细描述了该过程，如图73和表15所示。        

图73 - C(1e, 15)方案:U方提供一个临时密钥对，V方提供一个静态密钥对

         先决条件：

        a)双方均拥有同一套域名参数的真实副本，D. D应从两套域名参数中选择一套，见附件a; 

        b) V应被指定为9.2.6.2使用域参数集D生成的静态密钥对的所有者;

        c)双方已同意使用NIST级联KDF，参见9.2.3.4.6.5。SHA-256是用于P-256域参数的散列函数，SHA-384是用于P-384域参数的散列函数。 

        d)在密钥协商过程之前或过程中，双方获得密钥协商过程中与对方关联的标识符。U方获取与V方标识符绑定的静态公钥。静态公钥应该以可信的方式获得(例如，从由可信CA签名的证书中)。 

         注2:请参见NIST SP 800-56A Rev. 2: 2013和NSA2关于域参数的有效性保证、私钥和公钥的有效性以及私钥持有的保证的附加信息。

表15 -一遍Diffie-Hellman密钥协商方案总结 

        选择这种方案的基本原理在NIST SP 800-56A Rev. 2: 2013, 8.4中有详细说明。本方案在DLMS/COSEM中的使用在C.2中有进一步的解释。

3.静态统一Model C(0e, 2s, ECC CDH)方案 

        该方案用于DLMS/COSEM服务器与另一方协商临时加密密钥，以保护xDLMS APDUs或COSEM数据。发送方(发信人)扮演U方角色，对方(接收方)扮演V方角色。 

        注1:术语发送方和接收方是指通用加密APDU的字段。

        在这种情况下，双方只使用静态密钥对。每一方获得对方的静态公钥。由U向V发送一个nonce，即NonceU，以确保每个密钥建立交易的派生密钥材料是不同的。 

        流程如图74和表16所示。

图74 - C(0e, 2s)方案:各方只提供一个静态密钥对 

         先决条件：

         a)双方均拥有同一套域参数的真实副本，D. D必须从两套域参数中选择一套，见附件a;

         b)每一方都被指定为9.2.6.2中使用域参数集D生成的静态密钥对的所有者; 

         c)双方已同意使用NIST级联KDF，参见9.2.3.4.6.5。SHA-256是用于P-256域参数的散列函数，SHA-384是用于P-384域参数的散列函数。          

         d)在密钥协商过程之前或过程中，各方应获得与之相关的标识符密钥协商方案中的另一方;

         e)双方均获得与标识符绑定的对方静态公钥。这些静态公钥必须以可信的方式获得(例如，从由可信CA签名的证书中获得。 

        选择这种方案的基本原理在NIST SP 800-56A Rev. 2: 2013, 8.5中有详细说明。本方案在DLMS/COSEM中的使用在C.3中有进一步的解释。 

4.密钥派生函数- NIST级联KDF 

        NIST级连KDF符合NIST SP 800-56A Rev. 2: 2013, 5.8.1.1和NSA2，条款5应使用。具体如下:

        函数调用:kdf(Z, OtherInput)

        其中OtherInput由keydatalen和OtherInfo组成。 

        具体实现相关的参数: 

         a) hashlen:一个整数，表示散列函数hash输出的长度(以比特为单位)，用于派生密钥材料的块。在安全套件1中是256(对于SHA-256)，在安全套件2中是384(对于SHA-384);

         b) max_hash_inputlen:一个整数，表示输入到哈希函数的比特串的最大长度(以位为单位)。 

        SHA-256长度不超过位，SHA-384长度不超过位。

         Function: H:散列函数:在安全套件1中是SHA-256，在安全套件2中是SHA-384。

         输入:

        a) Z:表示共享密钥Z的字节串;

        b) keydatalen:一个整数，表示要生成的密钥材料的长度(以位为单位):安全套件1为128位，安全套件2为256位; 

        c) OtherInfo:等于以下拼接的位字符串: 

AlgorithmID || PartyUInfo || PartyVInfo {||SuppPubInfo}{||SuppPrivInfo} 

         其中的子字段定义如下:

        i) AlgorithmID:一个比特串，表示如何解析派生密钥材料，以及将使用派生密钥材料的算法。见表18; 

        ii) PartyUInfo:包含使用该KDF的应用程序所需的、由U方贡献给密钥派生过程的公开信息的位串; 

        iii) PartyVInfo:一个比特串，包含使用该KDF的应用程序所需的公开信息，由五方贡献给密钥派生过程;

        iv)(可选)SuppPubInfo:一个位串，包含额外的、相互知道的公共信息。未用DLMS/COSEM; 

         v)(可选)supprivinfo:一个位串，包含额外的、相互知道的私有信息(例如，通过单独的信道通信的共享秘密对称密钥)。不用于DLMS/COSEM。

         每个子字段和子字符串的格式和内容如表17所示。

表17 - OtherInfo子字段和子字符串 

        在DLMS/COSEM中，密钥派生为给定目的提供单个密钥。长度由安全套件决定。AlgorithmId如表18所示。参见9.4.2.2.4。 

 表18 -加密算法ID