DLMS协议——信息安全及应用层服务规范（三）

一、General block transfer (GBT) 总块传输

GBT机制可用于以块的形式传输任何-短或长的xDLMS APDU。使用GBT，块由通用块传输APDU携带，而不是特定于服务的“带数据锁”APDU。

GBT机制支持双向块传输、流传输和丢失块恢复：

• 双向块传输是指当一方发送块时，另一方不仅确认接收到的块，而且如果有块要发送，也可以在仍在接收块时发送；
  注：当需要向两个方向传输长服务参数时，双向块传输非常有用。
• 流媒体意味着一方可以发送多个区块，而不承认另一方的每个区块；
• 丢失块恢复意味着如果接收到未确认发送的块，则可以再次发送。如果使用流，则在每个流窗口的末尾发生丢失的块恢复。

GBT机制支持以下用例：
（1）客户端确认的短请求导致服务器的长响应：请求可以使用或不使用GBT发送。如果它是使用GBT发送的，那么客户端可能会在交换启动时发布其首选的GBT窗口大小。服务器使用GBT进行响应；

（2）客户端长期确认的请求：客户端使用GBT发送请求，服务器使用GBT发送响应，无论响应的长度是多少；

（3）客户端长期未确认的请求：客户端使用GBT发送请求；

（4）服务器长时间主动确认请求：服务器发送请求，客户端使用GBT发送响应；

（5）服务器长期未经请求的未经确认的请求：服务器使用GBT发送请求。

二、DLMS/COSEM中的信息安全

DLMS服务器的资源——COSEM对象属性和方法——可以由应用程序关联中的DLMS客户端访问。

在AA建立期间，客户端和服务器必须识别自己。服务器还可能要求客户机的用户标识自己。此外，服务器可能要求客户端对自己进行身份验证，而客户端也可能要求服务器对自己进行身份验证。

一旦建立了AA，xDLMS服务就可以用于访问COSEM对象的属性和方法，这取决于安全上下文和访问权限。

携带服务原语的xDLMS APDUs可以受到加密保护。所需的保护将由安全上下文和访问权限来决定。为了支持第三方和服务器之间的端到端安全性，这些第三方还可以使用客户端作为代理来访问服务器的资源。

此外，由xDLMS APDUs所携带的COSEM数据也可以被加密保护；

由于这些安全机制应用于应用程序进程/应用程序层级别，因此它们可以用于所有DLMS/COSEM通信配置文件中。

识别和认证

识别

DLMS/COSEM AEs被绑定到支持AL的协议层中的服务接入点（SAPs）上。这些SAP存在于AA中携带xDLMS APDUs的PDUs中。

客户端用户识别机制使服务器能够区分客户端上的不同用户，这些用户可能是操作员或第三方，以记录他们访问该设备的活动。

身份验证机制

认证机制确定了通信实体在AA建立期间用于验证自己的协议。

有三种不同的身份验证机制，具有不同的身份验证安全级别：

• 无安全性（最低级别安全性）身份验证；

无安全（最低级别安全）身份验证的目的是允许客户机从服务器检索一些基本信息。此身份验证机制不需要任何身份验证；客户端可以访问安全上下文中的COSEM对象属性和方法，以及给定AA中存在的访问权限。

• 低级安全（LLS）身份验证；

在这种情况下，服务器要求客户端通过提供服务器已知的密码进行身份验证。密码由当前建模要建立的SN的“关联SN/LN”对象持有。“关联SN/LN”对象提供了更改秘密的方法。

如果所提供的密码被接受，则可以建立AA，否则将被拒绝。

COSEM-OPEN服务支持LLS认证，如下所示：
（1）客户端使用COSEM-OPEN.request服务原语向服务器发送一个“密码”（一个密码）；
（2）服务器会检查这个“秘密”是否正确；
（3）如果是，则客户端将经过身份验证，并可以建立AA。从这一刻起，协商后的上下文就会是有效的；
（4）如果没有，AA将被拒绝；
（5）建立AA的结果应由服务器使用COSEM-OPEN.response服务原语和诊断信息发送回。

• 高级安全（HLS）身份验证。

在这种情况下，客户端和服务器都必须成功地验证自己才能建立AA。HLS身份验证是一个四遍进程（four-pass process），由COSEM-OPEN服务和“关联SN/LN”接口类的reply_to_HLS_authentication方法支持：

Pass 1:客户端向服务器发送一个“challenge”CtoS，并根据认证机制传输额外的信息；
Pass 2:服务器向客户端传输一个“challenge”StoC，并根据身份验证机制传输额外的信息；
如果StoC与CtoS相同，客户应拒绝它，并中止AA的建立流程。

Pass 3:客户端根据对给定AA有效的HLS认证机制的规则处理StoC和附加信息，并将结果发送给服务器。服务器将检查f（StoC）是否是正确处理的结果，如果是，它将接受客户端的身份验证；
Pass 4:然后，服务器根据对给定AA有效的HLS身份验证机制的规则，处理CtoS和附加信息，并将结果发送给客户端。客户端将检查f（CtoS）是否是正确处理的结果，如果是，它将接受服务器的身份验证。

COSEM Pass 1和Pass 2由COSEM-OPEN服务支持。

在Pass 2之后，如果提议的应用上下文和xDLMS上下文是可接受的，服务器使用协商的应用上下文授予对当前“关联SN/LN”对象的方法reply_to_HLS_authentication的访问权限。

Pass 3和Pass 4由“关联SN/LN”对象(s)的方法reply_to_HLS_authentication支持。如果Pass 3和4都成功执行，那么通过应用程序上下文和xDLMS上下文协商建立AA。

消息认证码

消息认证码（MAC）提供了真实性和完整性的保证。MAC是数据上的加密校验和，用于保证数据没有更改或被更改，并且MAC是由预期的方（发送方）计算出来的。通常，MAC在共享密钥的双方之间使用，以验证双方之间交换的信息。

消息身份验证代码(MACs)图
Figure 94 – Message Authentication Codes (MACs)

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

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

对于DLMS/COSEM，应使用GMAC算法。

GCM功能

组成GCM的两个功能称为验证加密和验证解密；参见下图。
Figure 95 – GCM functions

经过身份验证的加密功能会对机密数据进行加密，并在机密数据和任何额外的非机密数据上计算一个身份验证标签。经过验证的解密功能根据标签的验证情况对机密数据进行解密。

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

最后，如果不需要身份验证，则经过身份验证的加密功能会对机密数据进行加密，但不会计算身份验证标签。认证解密功能对机密数据进行解密，但不计算和验证认证标签。

a)认证加密功能-给定选择一个块密码密钥EK-有三个输入字符串：

• 明文，记为P；
• 附加身份验证数据（AAD），记为A；
• 一个初始化向量（IV）表示为IV。

明文和AAD是GCM保护的两类数据。GCM保护明文和AAD的真实性；GCM还保护明文的机密性，而AAD则保持清晰。
IV本质上是一个nonce，即在指定的（安全）上下文中唯一的值，它决定了对要保护的输入数据调用经过身份验证的加密函数。

经过认证的加密功能的输入字符串的位长应满足以下要求：

P、A和IV的位长度均为8的倍数，因此这些值是字节字符串。

有两个输出：

• 一个密文，表示为C，其位长与明文P相同；
• 身份验证标签，简称T。

b)经过认证的解密功能-给定选择一个块密码密钥EK-有四个输入字符串：

• 初始化向量，记为IV；
• 密码文本，用C表示；
• 附加的身份验证数据（AAD），记为A；
• 认证标签，标记为T。

输出的是以下内容之一：

• 对应于密文C的明文P，或者
• 一个特殊的错误代码表示为失败。

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

保护xDLMS APDUs

当AP调用与COSEM对象属性或方法相关的xDLMS服务原语时，服务参数将包括“
（ Security_Options ）安全选项”参数。该参数通知AL要