密钥协商允许两个实体共同计算共享密钥并从中获得密钥材料。在DLMS/COSEM中,三个椭圆曲线密钥协商方案已经被NIST SP 800- 56A Rev. 2: 2013选中。
注:对于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方贡献给密钥派生过程的公开信息的位串;
iv)(可选)SuppPubInfo:一个位串,包含额外的、相互知道的公共信息。未用DLMS/COSEM;
v)(可选)supprivinfo:一个位串,包含额外的、相互知道的私有信息(例如,通过单独的信道通信的共享秘密对称密钥)。不用于DLMS/COSEM。
每个子字段和子字符串的格式和内容如表17所示。
表17 - OtherInfo子字段和子字符串
在DLMS/COSEM中,密钥派生为给定目的提供单个密钥。长度由安全套件决定。AlgorithmId如表18所示。参见9.4.2.2.4。
表18 -加密算法ID