Information security in DLMS/COSEM(Green-Book)—认证机制

9.2.1 概述

本小节9.2.1描述并规定了：

• DLMS/COSEM安全概念，见9.2.2；
• 选定的加密算法，见9.2.3；
• 安全密钥，见9.2.4、9.2.5和9.2.6；
• 使用加密算法进行实体认证、xDLMS APDU保护和COSEM数据保护，见9.2.7。

9.2.2 DLMS/COSEM安全概念

9.2.2.1 概述

9.2.2.1 概述

在DLMS/COSEM体系架构中，信息安全是一个关键组成部分，用于确保数据交换的安全性和完整性。9.2.2.1小节提供了DLMS/COSEM安全概念的高级概述。

翻译：

在DLMS/COSEM中，服务器的COSEM对象属性和方法可以被客户端在应用关联（Application Associations, AAs）的上下文中访问。建立AA时，客户端和服务器需要进行身份验证。服务器可能还会要求客户端用户进行身份验证。此外，服务器可能要求客户端进行身份验证，而客户端也可能要求服务器进行身份验证。身份识别和认证机制在9.2.2.2节中具体规定。

一旦AA建立，就可以使用xDLMS服务来访问COSEM对象的属性和方法，但需遵守安全上下文和访问权限。关于安全上下文和访问权限的详细信息，请参阅9.2.2.3和9.2.2.4节。

xDLMS APDUs（应用协议数据单元）携带服务原语，可以进行加密保护。所需的保护级别由安全上下文和访问权限决定。为了支持服务器与第三方之间的端到端安全性，这些第三方也可以使用客户端作为中介来访问服务器的资源。消息保护的概念在9.2.2.5节中进一步解释。

此外，由xDLMS APDUs传输的COSEM数据也可以进行加密保护，详见9.2.2.6节。

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

注释：

• 较低层可能提供额外的安全保护。
• DLMS/COSEM AEs指的是DLMS/COSEM应用实体，它们绑定到支持应用层（AL）的协议层中的服务访问点（SAPs）。
• AA指的是应用关联，它是客户端和服务器之间建立的一种上下文，用于交换数据和服务。
• xDLMS服务是一系列应用层服务，用于访问和管理COSEM对象。

解释：
这一小节强调了在DLMS/COSEM通信中，安全是一个多层次的概念，包括身份验证、数据保护和密钥管理。它概述了在建立通信会话时，客户端和服务器如何通过一系列机制来确保数据交换的安全性。这些机制包括但不限于：

• 身份验证：确保通信双方的身份得到确认。
• 加密保护：对传输的数据进行加密，以防止未授权访问。
• 安全上下文和访问权限：定义了数据访问的规则和限制。
• 端到端安全性：确保数据在整个传输过程中的安全性，即使在第三方介入的情况下。

这些概念为DLMS/COSEM通信提供了一个安全的框架，确保了数据的保密性、完整性和可用性。

9.2.2.2 身份识别和认证

9.2.2.2.1 身份识别

身份识别机制允许服务器区分客户端不同用户，以记录他们访问设备的活动。身份识别是认证过程的第一步，其中涉及用户向系统证明其身份。

在DLMS/COSEM AEs中，身份识别机制使服务器能够识别客户端上的不同用户，以便记录他们访问设备的行为。正如在4.3.3节中所指定的，DLMS/COSEM AEs绑定到支持应用层（AL）的协议层中的服务访问点（SAPs）。这些SAPs存在于应用关联（AA）内承载xDLMS APDUs的数据包中。

9.2.2.2.2 认证机制

认证机制决定了通信实体在应用关联（AA）建立期间使用的协议，以相互认证。

认证机制定义了在应用关联（AA）建立期间，通信实体用于相互认证的协议。这些机制确保了参与通信的各方能够验证对方的身份，并根据需要建立安全通信。

9.2.2.2.2.1 概述

在DLMS/COSEM体系中，身份验证机制是建立应用关联（Application Associations, AAs）过程中的一个关键步骤。以下是对9.2.2.2.2.1小节“概述”的详细翻译和解释：

在DLMS/COSEM中，认证机制决定了通信实体在应用关联（AA）建立期间使用的协议，以便它们相互认证。以下是三种不同的认证机制，它们提供不同级别的安全保障：

1. 无安全认证（Lowest Level Security）：这种机制不需要任何认证，允许客户端访问服务器上的COSEM对象属性和方法，但安全性最低。
2. 低级别安全认证（Low Level Security, LLS）：在这种情况下，服务器要求客户端通过提供密码来进行身份验证。如果密码被接受，则可以建立AA；否则，AA建立请求将被拒绝。
3. 高级别安全认证（High Level Security, HLS）：在这种情况下，客户端和服务器都必须成功进行身份验证才能建立AA。HLS认证是一个四步过程，支持通过COSEM-OPEN服务和回复HLS认证机制。

• 认证机制的作用：认证机制确保了只有经过验证的实体才能参与通信，从而保护数据不被未授权的第三方访问或篡改。
• 无安全认证：这种机制提供了最低级别的安全保障，适用于对安全性要求不高的场景。然而，它不提供任何形式的身份验证，因此存在安全风险。
• 低级别安全认证（LLS）：LLS通过密码验证提供了基础的安全保障。如果密码匹配，客户端被认证并允许建立AA，否则认证失败。
• 高级别安全认证（HLS）：HLS提供了更高级的安全保障，要求客户端和服务器双方进行身份验证。这个四步过程通常包括：
  • 客户端向服务器发起认证请求。
  • 服务器向客户端发送一个质询（challenge），这通常是一个随机生成的值。
  • 客户端使用其私钥对质询进行加密或签名，并将响应发送回服务器。
  • 服务器验证客户端的响应，如果验证成功，则双方身份得到确认，可以建立安全的通信通道。

这些认证机制的选择取决于系统对安全性的需求。在需要高度安全的环境中，如金融或关键基础设施，HLS认证是首选。而在对安全性要求不高或成本敏感的应用中，可能会选择LLS或无安全认证。每种机制都有其适用场景和限制，系统设计者需要根据具体需求选择合适的认证机制。

图 Authentication mechanisms

在DLMS/COSEM体系结构中，图89 “认证机制”（Authentication mechanisms）详细描述了用于确保通信双方身份的三种不同级别的认证方法。以下是对这些认证机制的更丰富和详细的解释：

无安全认证（Lowest Level Security）：

• 目的：允许客户端获取服务器上的基本信息，无需进行任何形式的身份验证。
• 过程：客户端可以直接访问COSEM对象的属性和方法，但没有任何安全检查。
• 安全性：最低，因为没有身份验证，所以容易受到未授权访问和篡改。

低级别安全认证（Low Level Security, LLS）：

• 目的：提供基本的安全性，要求客户端通过密码进行身份验证。
• 过程：
  • 客户端向服务器发送带有密码的认证请求。
  • 服务器接收密码后，与已知的密码进行比对。
  • 如果密码匹配，服务器接受客户端的请求并建立应用关联（AA）；如果不匹配，则拒绝请求。
• 安全性：比无安全认证高，但仍然容易受到某些类型的攻击，例如密码猜测或重放攻击。

高级别安全认证（High Level Security, HLS）：

• 目的：提供高安全性的身份验证，确保通信双方的身份都经过严格验证。
• 过程：通常涉及以下步骤：
  • Pass 1：客户端向服务器发送一个质询请求，可能包括随机数或其他挑战信息。
  • Pass 2：服务器接收请求后，生成一个质询（challenge），并将其发送给客户端。
  • Pass 3：客户端接收到质询后，使用私钥对其进行加密或签名，然后将响应发送回服务器。
  • Pass 4：服务器使用客户端的公钥验证响应的有效性。如果验证成功，双方的身份得到确认，可以建立安全的通信通道。
• 安全性：最高，使用公钥/私钥对进行身份验证，可以有效防止未授权访问和篡改。

额外细节可能包括：

• 质询的生成：质询通常是随机生成的，以确保每次认证过程的唯一性。
• 加密和签名：客户端对质询的响应可能涉及加密或使用数字签名，这取决于所使用的具体HLS认证机制。
• 密钥交换：在某些HLS认证机制中，双方可能还会交换密钥，以便用于后续通信的加密。
• 认证失败的处理：如果认证过程中的任何步骤失败，如质询响应验证不通过，认证过程将终止，并且不会建立应用关联。

9.2.2.2.2.2 无安全认证(Lowest Level Security)（最低安全级别）

无安全认证的目的是允许客户端从服务器检索一些基本信息。这种认证机制不要求任何认证；客户端可以在给定AA的安全上下文和访问权限下访问COSEM对象属性和方法。

在无安全认证机制下，客户端可以访问服务器以获取一些基本信息。这种机制不需要进行任何形式的认证。客户端可以在应用关联（AA）的安全上下文和访问权限范围内，访问COSEM对象的属性和方法。

9.2.2.2.2.3 低级别安全（Low Level Security，LLS）认证

在这种情况下，服务器要求客户端通过提供密码进行身份验证。如果提供的密码被接受，则可以建立AA；否则，将被拒绝。

在低级别安全（LLS）认证中，服务器要求客户端提供密码以验证其身份。如果密码被接受，那么可以建立应用关联（Application Association，AA）。如果密码验证失败，则AA建立请求将被拒绝。LLS认证由COSEM-OPEN服务支持，具体过程如下：

• OPEN.request服务原语：客户端发送OPEN.request服务原语以开始LLS认证过程。
• 认证结果：如果密码验证成功，客户端将被认证，并且可以建立AA。从这一刻起，协商的上下文将有效；
• OPEN.response服务原语：如果密码验证失败，AA将被拒绝，并且服务器将使用COSEM-OPEN.response服务原语将结果和诊断信息发送回客户端。

• LLS认证的目的：LLS认证的主要目的是在建立应用关联之前，通过密码验证确保客户端的身份。这种认证方式提供了基本的安全保障，适用于安全要求不是特别高的场景。
• 密码验证过程：
  • 客户端在发送OPEN.request服务原语时，需要包含密码信息。
  • 服务器接收到请求后，会根据预设的密码或通过其他安全方式存储的密码进行比对。
  • 如果密码匹配，服务器认为客户端身份有效，可以继续建立AA；如果不匹配，服务器将拒绝客户端的请求。
• COSEM-OPEN服务：COSEM-OPEN服务是DLMS/COSEM协议中用于建立和管理应用关联的服务。在LLS认证过程中，COSEM-OPEN服务的OPEN.request和OPEN.response服务原语被用来交换认证信息和认证结果。
• 认证结果的处理：认证成功后，客户端和服务器可以继续进行数据交换和通信。如果认证失败，客户端可能需要重新发送带有正确密码的OPEN.request服务原语，或者根据OPEN.response服务原语中提供的诊断信息进行故障排查。
• 安全性考虑：尽管LLS认证提供了基本的安全保障，但它仍然容易受到密码猜测攻击或如果密码在传输过程中未加密，还可能受到窃听攻击。因此，在对安全性要求更高的场景中，可能需要采用更高级别的认证机制，如HLS认证。

LLS认证是一种简单的身份验证方法，适用于那些不需要复杂安全措施的场合。然而，系统设计者应当意识到，LLS认证提供的保护是有限的，并且在设计系统时需要考虑这些限制。

9.2.2.2.2.4 高级别安全（High Level Security，HLS）认证

在这种情况下，客户端和服务器都必须成功进行身份验证才能建立AA。HLS认证是一个四步过程，由COSEM-OPEN服务和reply_to_HLS_authentication支持。

高级别安全（HLS）认证要求客户端和服务器双方都必须成功进行身份验证才能建立应用关联（AA）。HLS认证是一个四步过程，涉及COSEM-OPEN服务和回复HLS认证的机制。具体步骤如下：

1. 第一步（Pass 1）：客户端向服务器发送质询（Challenge）和根据HLS认证机制规则的其他信息。
2. 第二步（Pass 2）：服务器接收到质询后，生成自己的质询并将其发送给客户端，可能还包括系统标题（System-Title）等其他信息。
3. 第三步（Pass 3）：客户端处理来自服务器的质询，根据HLS认证机制的规则和客户端的私钥，计算出一个结果并将其发送给服务器。
4. 第四步（Pass 4）：服务器接收客户端的响应，验证计算结果。如果结果正确，服务器接受客户端的身份验证。

如果步骤3和4成功执行，AA将使用协商的应用上下文和xDLMS上下文建立。如果传输了专用密钥，则从这一刻起可以使用。否则，要么客户端或服务器中止过程。

• HLS认证的目的：HLS认证提供了一种更为安全的认证机制，确保通信双方的身份都经过验证，适用于对安全性要求较高的环境。
• 四步认证流程：
  • 第一步：客户端发起认证请求，可能包括一个随机生成的质询或其它用于开始认证过程的信息。
  • 第二步：服务器响应客户端的请求，发送自己的质询，这个过程可能还会涉及到服务器的身份信息，如系统标题。
  • 第三步：客户端使用其私钥对服务器的质询进行处理，常见的处理方式包括对质询进行签名，然后将结果返回给服务器。
  • 第四步：服务器验证客户端返回的结果，如果结果表明客户端拥有正确的私钥，服务器则确认客户端的身份。
• COSEM-OPEN服务：COSEM-OPEN服务是DLMS/COSEM协议中用于建立和管理应用关联的服务。在HLS认证过程中，COSEM-OPEN服务的OPEN.request和OPEN.response服务原语被用来交换认证信息和认证结果。
• 安全性：HLS认证使用公钥/私钥对进行身份验证，这提供了比LLS认证更高的安全性。即使攻击者截获了通信内容，没有正确的私钥也无法伪造有效的认证响应。
• 应用场景：HLS认证适用于需要严格安全控制的环境，如金融交易、关键基础设施管理等。它确保了通信双方的身份得到充分验证，从而保护了数据的机密性和完整性。

HLS认证是一种强大的认证机制，通过多步骤的挑战和响应过程，提供了高度的安全保障。然而，这种机制也需要更多的计算资源和更复杂的协议交互。在设计系统时，需要根据系统的具体安全需求和性能要求来选择适当的认证机制。

---

身份识别和认证是确保通信安全的基础。在DLMS/COSEM中，这些过程确保只有经过验证的参与者才能访问敏感数据和资源。身份识别允许服务器识别访问的用户，而认证则通过密码或更高级的机制（如HLS认证）来验证用户或系统的身份。这些机制的目的是防止未授权访问，并确保数据交换的安全性和完整性。

9.2.2.3 安全上下文

安全上下文定义了与加密转换相关的安全属性，包括以下几个元素：

• 安全套件：确定可用的安全算法，见9.2.3.7；
• 安全策略：决定对所有在应用关联（AA）内交换的xDLMS APDUs普遍应用的保护类型。可能的安全策略在9.2.7.2.2中规定；
• 安全材料：与给定安全算法相关的材料，包括安全密钥、初始化向量、公钥证书等。由于安全材料特定于每种安全算法，相关子句中详细指定了元素。

• 安全上下文的作用：安全上下文在DLMS/COSEM安全架构中扮演着核心角色，它确保了数据传输的安全性和完整性。通过定义一系列的安全参数和规则，安全上下文为通信双方提供了一个安全的通信环境。

• 安全套件：安全套件是一组预定义的安全算法和相关的参数，它们用于加密、解密、认证和其他安全服务。安全套件的选择取决于具体的安全需求和策略。

• 安全策略：安全策略定义了在应用关联期间对数据交换所采取的安全措施，包括数据的加密、认证和完整性保护等。这些策略可能包括必须使用的安全算法、密钥管理和数据保护的具体要求。

• 安全材料：

  • 安全密钥：用于加密和解密数据的密钥，或者是用于认证和数字签名的密钥。
  • 初始化向量：在加密过程中用于确保加密数据的随机性的值，特别是在使用块加密算法时。
  • 公钥证书：包含了公钥及其相关信息的数字证书，通常由可信的第三方颁发，用于公钥的验证和身份确认。

• 管理：安全上下文的管理涉及到密钥的生成、分发、存储、更新和废弃等环节。这些过程需要严格的安全控制，以防止密钥泄露或被滥用。

• 应用：在实际的通信过程中，安全上下文的参数会被用于构建加密的通信会话，确保数据在传输过程中的安全性。例如，使用安全套件中的算法对数据进行加密，或者使用安全材料中的密钥进行数据的认证。

安全上下文是DLMS/COSEM安全模型的一个关键组成部分，它为不同安全级别的通信提供了必要的支持。通过细致地定义和管理安全上下文，可以确保在复杂的通信环境中数据的安全性和可靠性。

9.2.2.4 访问权限

访问权限定义了对COSEM对象属性和方法的访问控制，它们可以是以下几种类型：

• 无访问（no_access）：表示没有权限访问特定的属性或方法。
• 只读（read_only）：允许读取属性的值，但不允许修改。
• 只写（write_only）：允许修改属性的值，但获取当前值是不允许的。
• 读写（read_and_write）：允许读取和修改属性的值。

此外，访问权限还可能规定应用于携带服务原语的xDLMS APDUs的加密保护。请求和响应上的保护可以独立配置。

• 访问权限的作用：在DLMS/COSEM体系中，访问权限是确保数据安全和完整性的重要机制。它们控制着不同用户或系统对COSEM对象属性和方法的访问级别。

• 属性访问：

  • 无访问：用户或系统不能访问属性，无论是读取还是写入。
  • 只读：用户或系统可以读取属性的值，但不允许对属性进行任何修改。
  • 只写：用户或系统可以修改属性的值，但不能查看当前的属性值。这种权限类型在某些特定场景下使用，例如配置写入时不希望读取当前状态。

• 方法访问：

  • 无访问：用户或系统不能调用方法。
  • 访问：用户或系统可以调用方法并可能接收返回参数。

• 加密保护：访问权限还可能涉及到对通信过程中的数据进行加密保护。根据安全策略和访问权限的要求，可以独立地为请求和响应消息配置加密保护。这确保了数据在传输过程中的安全性，防止未授权的监听或篡改。

• 独立配置：请求和响应的保护可以独立配置，这意味着可以根据不同的安全需求和上下文来定制保护措施。例如，可能对请求进行加密，而对响应只进行认证，或者两者都进行加密和认证。

• 应用：在实际应用中，访问权限由系统管理员或通过安全策略进行设置，确保只有授权的用户或系统能够访问敏感数据或执行特定的操作。

访问权限是DLMS/COSEM安全框架中的关键组成部分，它们与安全上下文和认证机制相结合，为智能电网和其他自动化系统提供了必要的安全保障。通过精确控制访问权限，可以有效地防止未授权访问和潜在的安全风险。

9.2.2.5 应用层消息安全

DLMS/COSEM通过在应用层提供加密保护xDLMS APDUs（应用协议数据单元）的手段来确保通信的安全性。这种保护可以是认证、加密和数字签名的任意组合，并且可以由多个参与方以多层方式应用。保护由消息的发送方应用，并由接收方验证和移除。

当接收到请求或响应时，只有当携带请求或响应的消息上的保护能够成功验证并移除时，才会对其进行处理。项目特定的配套规范可能会指定接受和处理消息的额外标准。

客户端和服务器之间的消息保护概念如图90所示。为了确保端到端的消息安全，第三方需要能够与DLMS服务器交换受保护的xDLMS服务请求。在这种情况下，客户端充当代理，意味着第三方是客户端和服务器之间一个应用关联的用户，第三方想要到达的是服务器。

图90展示了客户端和服务器之间消息安全的概念。在DLMS/COSEM体系中，消息安全是通过在应用层对消息进行加密保护来实现的。这种保护可以包括认证、加密和数字签名的任意组合，并且可以由多个参与方以多层方式应用。

• 消息安全的重要性：在客户端和服务器的通信中，确保消息的安全性是至关重要的。这不仅保护了数据的机密性，防止了未授权的访问，还确保了数据的完整性和来源的可验证性。

• 加密保护：应用层的加密保护意味着在数据传输过程中，消息内容会被加密，只有拥有正确密钥的参与方才能解密和理解消息内容。

• 多层面保护：消息可以被多个参与方应用多层保护。例如，客户端可能对消息进行加密，然后服务器在接收到消息后再次应用一层保护，如数字签名。

• 认证、加密和数字签名：

  • 认证：确保消息是由可信的发送方发送的。
  • 加密：保护消息内容不被未授权的第三方读取。
  • 数字签名：确保消息在传输过程中未被篡改，并且可以验证发送方的身份。

• 保护的应用和验证：保护由消息的发送方应用，并由接收方验证和移除。这意味着发送方负责根据安全策略和访问权限对消息进行加密和签名，而接收方则负责验证这些保护措施的有效性。

• 端到端安全：图90可能还强调了端到端安全的概念，即从消息的发送方到接收方的整个传输过程中，消息都保持安全状态。

• 第三方的参与：在某些情况下，第三方可能需要参与到客户端和服务器之间的通信中。例如，第三方可能作为代理或中继，转发或处理消息。在这种情况下，第三方也需要能够理解和处理加密的消息。

• 安全策略和访问权限：应用层消息安全的实施遵循特定的安全策略和访问权限。这些策略和权限定义了哪些类型的保护是必需的，以及哪些参与方有权访问特定消息。

图90所展示的客户端-服务器消息安全概念是DLMS/COSEM安全架构的重要组成部分，它确保了在复杂的通信环境中数据交换的安全性和可靠性。通过这种方式，即使在面对潜在的安全威胁时，也能保护关键信息不受损害。

第三方和服务器之间的消息保护概念如图91所示。

图91展示了端到端消息安全的概念。在DLMS/COSEM体系中，端到端安全确保了从消息的发送方到接收方的整个传输过程中，消息的安全性得到保护。这种安全机制不仅适用于直接的客户端和服务器之间的通信，也适用于涉及第三方的通信场景。

• 端到端安全的重要性：端到端消息安全确保了数据在传输过程中的安全性，防止了在客户端、服务器以及任何可能的第三方之间的传输过程中数据被截获或篡改。

• 第三方的参与：在某些通信场景中，第三方可能需要参与到客户端和服务器之间的通信中。例如，第三方可能是一个代理或中介，负责转发或处理客户端和服务器之间的消息。

• DLMS/COSEM客户端的角色：

  • 作为第三方和服务器之间的代理；
  • 根据第三方客户端消息中包含的信息，为第三方提供合适的应用关联（AA）；
  • 验证第三方是否有权使用该AA；
  • 可能对第三方应用的保护进行验证；
  • 将第三方客户端消息封装到一般受保护的xDLMS APDU中；
  • 可能对服务器应用的保护进行验证，并可能对发送给第三方的受保护xDLMS APDUs应用自己的保护。

• DLMS/COSEM服务器的角色：

  • 与客户端建立（预先建立）AA，第三方使用该AA与服务器通信；
  • 可能检查第三方的身份；
  • 一旦客户端和/或第三方应用的保护被成功验证，根据安全策略和访问权限提供对COSEM对象属性和方法的访问；
  • 准备响应或在推送操作中准备未经请求的服务请求，并应用由传入请求、访问权限和安全策略确定的保护。

• 保护的应用：在端到端消息安全中，保护可以包括加密、认证和数字签名。这些保护措施确保了消息的机密性、完整性和来源的可验证性。

• 保护的验证和移除：当消息到达接收方时，必须首先验证并移除保护层。这一过程确保了只有拥有正确密钥和权限的参与方才能访问消息内容。

• 安全策略和访问权限：端到端消息安全的实施遵循特定的安全策略和访问权限。这些策略和权限定义了哪些类型的保护是必需的，以及哪些参与方有权访问特定消息。

图91所展示的端到端消息安全概念是DLMS/COSEM安全架构的关键组成部分，它为涉及直接和间接通信的复杂系统提供了必要的安全保障。通过实现端到端的安全措施，DLMS/COSEM确保了数据在整个传输过程中的安全性和可靠性。

• 应用层消息安全的重要性：在DLMS/COSEM体系结构中，应用层消息安全是确保数据交换安全的关键机制。通过在应用层对消息进行加密保护，可以防止数据在传输过程中被未授权访问或篡改。

• 保护的组合：应用层消息安全不仅限于单一的保护措施，如仅加密或仅认证。实际上，它可以结合多种保护措施，如同时应用加密和认证，以提供更高级别的安全性。

• 多层保护：在复杂的通信环境中，可能需要多个参与方对同一消息应用不同的保护层。例如，消息在发送过程中可能首先被客户端加密，然后被第三方再次加密，最后由服务器解密和验证。

• 保护的验证和移除：当消息到达接收方时，必须首先验证并移除保护层。这一过程确保了只有拥有正确密钥和权限的参与方才能访问消息内容。

• 端到端安全：端到端消息安全意味着从消息的发送方到接收方的整个传输过程中，消息都受到保护。这要求所有参与通信的第三方也必须遵循相同的安全标准。

• 代理的角色：在涉及第三方的通信中，客户端可能充当代理，负责在第三方和服务器之间转发消息。这要求客户端能够理解和处理来自第三方的受保护消息，并将它们正确地传递给服务器。

• 安全机制的灵活性：DLMS/COSEM的应用层消息安全机制具有很高的灵活性，允许根据不同的安全需求和通信场景定制保护措施。

• 安全政策和访问权限：应用层消息安全的实施还受到安全政策和访问权限的约束。这些政策和权限定义了哪些类型的保护是必需的，以及哪些参与方有权访问特定消息。

应用层消息安全是DLMS/COSEM安全框架的核心组成部分，它为智能电网和其他自动化系统提供了必要的安全保障，确保了数据的机密性、完整性和可用性。

9.2.2.6 COSEM数据安全

COSEM数据，即COSEM对象属性的值、方法调用的参数以及返回参数，也可以进行加密保护。当需要时，相关的属性和方法被间接访问，以便应用和验证/移除保护；具体做法见DLMS UA 1000-1第2部分Ed.15:2021，4.4.9。同时，也请参见9.2.7.5节。

• COSEM数据安全的重要性：COSEM（Common Information Model for Utilities COMponent and
  SERvices）数据包含了智能电网和其他自动化系统中的关键信息。保护这些数据的安全性是防止未授权访问和确保数据完整性的重要措施。

• 加密保护：COSEM数据可以通过加密技术进行保护，以确保只有授权的用户或系统能够访问和理解这些数据。这种保护可以包括数据的传输和存储过程。

• 间接访问：间接访问意味着在访问COSEM数据时，可能会应用额外的安全层，例如通过安全代理或使用特定的访问控制机制。

• 应用和验证/移除保护：在数据传输过程中，发送方需要对数据应用加密保护，而接收方则需要验证、解密并移除这些保护措施。这个过程确保了数据在传输过程中的安全性，并且只有拥有正确密钥的参与方才能访问原始数据。

• 相关标准和文档：提到的DLMS UA 1000-1第2部分Ed.15:2021，4.4.9是DLMS用户协会（DLMS User Association）发布的标准文档，其中详细描述了COSEM数据安全的具体实现方法和要求。

• 补充信息：9.2.7.5节可能包含了关于COSEM数据保护的更多细节，例如加密算法的选择、密钥管理、数据完整性验证等。

• 实施层面：在实际应用中，COSEM数据安全需要通过软件和硬件的结合来实现。智能电表、控制系统和其他相关设备需要具备相应的安全功能，以支持加密和解密操作。

• 安全策略：组织需要制定明确的安全策略，以确定哪些COSEM数据需要保护，以及如何平衡安全性和性能的需求。

COSEM数据安全是智能电网和自动化系统中不可或缺的一部分，它确保了关键数据的保密性、完整性和可用性。通过实施强有力的数据保护措施，可以提高系统的安全性，防止数据泄露和篡改，从而保护消费者和企业的权益。