Security Framework in DLMS/COSEM:

Ensuring Data Protection and System Integrity

DLMS User Association

Baarerstrasse 38
CH-6300 Zug, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
1 Introduction
This white paper presents an in-depth overview of the advanced security concepts and
mechanisms of DLMS/COSEM, a globally recognized data model and format for energy data
exchange.

Focusing on the critical need to safeguard data in smart energy ecosystems, the paper
outlines the security principles and methods that ensure end-to-end, application-level
cryptographic protection of messages and data, regardless of the communication medium
used. DLMS employs cutting-edge cryptographic algorithms from the Commercial National
Security Algorithm Suite (CNSA). By decoupling these algorithms from the security suite, DLMS
offers a future-proof solution for evolving security needs.

As the global energy sector increasingly adopts digital technologies, securing smart metering
and grid infrastructures is essential to ensuring both operational integrity and regulatory
compliance. This paper highlights DLMS/COSEM’s role in addressing these challenges, offering
robust and adaptable security that meets the growing demands of modern energy systems.

DLMS User Association

Industriestrasse 53 Page 2
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
2 Security is essential for critical infrastructure
Smart meters play a pivotal role in modern utilities, serving not only devices for consumption
measurement and billing, but also as tools for controlling energy usage, managing contracts,
and facilitating payments. Additionally, they can provide sensitive data for monitoring and
managing customer premises, as well as for the transmission, distribution and supply network.
Given their central role, smart meters are indisputably part of critical infrastructure that
demands robust protection.

2.1 The DLMS Security Framework

DLMS is designed for application data exchange across a broad range of communication
media. To ensure the integrity of data transmission, it incorporates comprehensive, end-to-
end, application-level security mechanisms that protect messages and data, regardless of
the communication medium used for transporting the messages. These mechanisms are
generally enhanced by additional security measures provided by the underlying
communication protocol layers.
The DLMS security framework is supported by multiple mechanisms that work together to
ensure a high level of protection:
1. Entity Authentication: Verifies and authenticates entities, ensuring that only trusted
parties can exchange messages.
2. Role-Based Access: Restricts data access within COSEM objects based on the
client’s designated role.
3. Message Protection: Ensures that data held by the COSEM objects are only
accessed by adequately secured messages.
4. Data Protection: Adds an extra layer of security for sensitive or critical data,
particularly when multiple intermediaries are involved between application
endpoints.
5. Secure Image Transfer: Facilitates secure firmware updates throughout a device’s
operational life.
6. Communication Port Protection: Monitors for suspicious traffic and can temporarily
disable communication ports to prevent replay or brute-force attacks.
7. Security Logs: Provide a way to monitor, analyze, and respond to security-related
events during message exchanges.
Security has been an integral part of DLMS/COSEM from the outset, allowing it to continually
evolve to meet new requirements with ease.

2.2 Security Services

DLMS provides three core security services:
• Confidentiality ensures that access to and disclosure of information are restricted to
authorized parties. This is achieved through encryption mechanisms.
• Integrity protects against improper modification or destruction of data, while ensuring
non-repudiation and authenticity, assuring both sender and recipient of the data’s
origin. Integrity is enforced through authentication and digital signature mechanisms.

DLMS User Association

Industriestrasse 53 Page 3
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
 Digital signatures not only guarantee data integrity, but also confirm the sender’s
identity, preventing them from denying having sent the message.
• Availability guarantees timely and reliable access to information. It is ensured through
mechanisms such as firmware updates, traffic monitoring, logging and analysis, and
appropriate steps.
These security services can be applied in layers to meet each requirement.

3 Overview of DLMS UA & DLMS Specifications

To provide a clearer understanding of the security concepts, mechanisms and their
implementation, this section provides a brief introduction to DLMS UA. As a global leader in
interoperable and secure data exchange, DLMS supports strategic energy and water
management. The DLMS User Association (DLMS UA) focuses on developing and promoting
efficient, secure, and interoperable data exchange solutions. It is internationally recognized
under the IEC 62056, ANSI C12, and EN13757-1 standards.

DLMS, short for Device Language Message Specification, is an international data model and
data format used for data exchange in smart energy and water management, advanced
sensing and monitoring and innovative smart metering. It aims to establish a standardized
data exchange model for transmitting data between smart devices and head-end systems
or amongst smart devices, in the energy or water sector.

The DLMS UA specifications include an object-oriented data model, application layer

services and media-specific communication profiles, that standardize message types for
various operations, such as reading and writing data. It also includes rules for formatting and
transmitting these messages. It can be applied over multiple types of communication
technology.

3.1 Object-Oriented Data Model

The COSEM object model describes the semantics of the data exchange language. COSEM
interface classes and their instantiations (objects) are flexible enough to model various
energy and water management use cases, while being general enough to model other
applications.
Object modeling is a powerful tool that allows formal representation of both simple and
complex data, where each aspect of the data is modeled by attributes. Objects can have
multiple attributes and methods to perform operations on them. The objects can be
combined to model simple use cases such as register reading or more complex scenarios
such as tariff and billing schemes or load management. The specifications are capable of
handling up to 65 535 interface classes.

3.2 Application Layer Services

DLMS defines the syntax of its language through application services, which operate under a
client-server paradigm. Typically, end devices such as smart meters act as servers, while the
head-end systems or concentrators function as clients. The application layer transforms these
services into messages that can be transported over virtually any communication media.

DLMS User Association

Industriestrasse 53 Page 4
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
 3.3 Communication Profiles
DLMS is communication technology agnostic, meaning that the application messages can
be carried end-to-end, application-to-application between the entities hosting those
applications, over virtually any communication technology.
For each communication technology, a communication companion stack is specified and
defined by combining the flexibility and adaptability of the COSEM data and the DLMS
application layer to the specificity of the lower layer communication protocol.

3.4 Three-Step Approach to Data Exchange

DLMS uses a three-step approach to specifying data exchange with smart devices:
• Modeling (semantics) is defined by COSEM objects.
• Messaging (syntax) is established by DLMS application services.
• Transport is determined by communication profiles.

3.5 Modeling
DLMS operates on a client-server paradigm, where the Head End System (HES) acts as a
client that sends requests to the end devices, which function as servers that respond to these
requests. Additionally, DLMS supports a push operation, allowing servers to send unsolicited
messages to clients.
A Head End System may comprise several client applications, each representing different
roles. Each physical end device, such as a utility meter, may contain several Logical Devices,
with each acting as a server. These servers provide specific views of the device’s resources –
i.e. the COSEM objects - to each client. Both clients and servers are uniquely identified by
their system title and Service Access Point (SAP).
Client and server applications communicate with each other within Application Associations,
which determine the rules of the exchange. Furthermore, third party applications can access
the servers through a client acting as an agent. The client manages and controls the access
rights of third parties to the servers.

3.6 Semantics: COSEM Object Model

The semantics of the DLMS language are modelled using How COSEM Objects Work Together
COSEM interface objects. Each object defines the
Example 1: The multi tariff function of a
meaning of simple or complex data element, such as
meter is modelled using Register,
registers, data profiles, clock, schedules, calendars. Each
Register Activation, Clock, Schedule,
object is characterized by a specific set of attributes and
Activity Calendar and Script Objects.
methods, where attributes represent values and
methods perform operations on these attributes. Data Example 2: The payment function of a
held by COSEM objects can be accessed by reading or meter is modelled with Account, Credit,
writing their attributes and invoking their methods. Charge, Token Gateway and Register
Objects.

DLMS User Association

Industriestrasse 53 Page 5
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
The COSEM object model provides a library from which implementers can select a set of
functions. COSEM objects can collaborate to model various use cases effectively.

Security functions are supported by two specific objects:

• Security Setup Objects manage the security context.
• Data Protection Objects enable the application of cryptographic protection on
COSEM data including attribute values, method invocation and return parameters.

The naming convention for COSEM objects is established by the Object Identification System
(OBIS). Each OBIS code identifies the application domain (e.g. electricity, gas, water, heat
energy metering...), the physical or abstract quantity (e.g. voltage, current, energy, power,
flow, volume, pressure, temperature...) and the manner in which the quantity is processed,
classified and stored.
COSEM and OBIS currently encompass utility metering, monitoring, consumption and
demand, payment processing and control of physical quantities. They can also be readily
extended to Internet of Things (IoT) applications beyond traditional utility metering.
The COSEM objects provide several mechanisms, such as selective access, compact data
types and compact encoding to ensure high efficiency.

3.7 Syntactics: Messaging

The syntactics of the language, specifically the services available for accessing objects and
the formatting of messages, are defined by DLMS application layer. Data exchange occurs
within Application Associations (AAs)n which
determine the contexts or the rules governing the
data exchange: DLMS Application Layer Services
• Application Context defines how COSEM The GET and SET services are used to
object attributes and methods are read and write attributes respectively,
referenced, as well as the use of ciphering. while the ACTION service is utilized to
• Authentication Context specifies the invoke methods. The unified ACCESS
mechanism for entity authentication. services can perform all three
functions. These services operate on a
• xDLMS Context determines the COSEM client-server model where the client
object related services and capabilities to sends the request and server
be used. responds.
These contexts can be negotiated, allowing for The DataNotification Service is
the customization of data exchange parameters unsolicited, allowing the server to send
to align with the specific requirements and to a specified destination.
properties of the communication media.
General Protection Messages carry
An Application Association (AA) also defines the unprotected messages with
list of COSEM objects that are visible with a given protection applied, while General
AA, along with the access rights to their attributes Block Transfer Messages provide
and methods, as well as the necessary streaming with the capability of lost
cryptographic protection of the messages. block recovery.

DLMS User Association

Industriestrasse 53 Page 6
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
Additionally, the AA establishes the security context, which includes the security suite i.e. the
set of available security algorithms- the security material, and the security policy that dictates
the protection measures for each message.

The concept of AAs allows for selective application of protection, minimizing computation
and overhead. Critical data can be accessed in ciphered AAs whereas non-critical data
may be accessed in AAs that do not utilize ciphering. In ciphered AAs, the security policy
stipulates the protection to be applied on each message. Access rights to attributes and
methods may impose a stronger protection where necessary. Protection for requests and
responses may differ, for instance, authenticated encryption may be required for confidential
data been written to the server, while the result of that operation may not need the same
level of protection.

AAs can be either explicitly established or pre-established. Explicitly established AAs are
created and terminated using the services of the Association Control Service Element (ACSE).
In contrast, pre-established AAs, rely on a pre-agreed set of rules and capabilities.

Once an AA is (pre-)established, COSEM objects are accessed through the xDLMS services
provided by the xDLMS Application Service Element. These services can be request/response
types or unsolicited, supporting push operations and event/alarm notifications.
The xDLMS services offer various mechanisms, including the unified ACCESS service,
composable messages, and block transfer with streaming, to ensure high efficiency.

3.8 Transport
The transport of DLMS messages is defined by
communication profiles. A communication profile
specifies the set of protocol layers and the binding DLMS Communication Profile Stack
between the media-specific lower layers (e.g. PHY, Specifications
MAC, Link ) to the network and transport layers. The - 3-layer HDLC;
binding is often specified in an adaptation layer - TCP-UDP/IPv4/IPv6;
that may include routing and compression - S-SFK PLC, G3-PLC, PRIME PLC,
functionalities. The top layer is always the High speed PLC;
DLMS/COSEM application layer. - EN 13757 M-Bus wired and
Specific COSEM objects may also be defined to wireless;
facilitate the set-up, monitoring and diagnosis of the - Euridis twisted pair;
communication. The media-specific lower layers - Mesh network;
typically provide their own security mechanisms - Wi-SUN, LPWAN, LoRaWAN
which protect the messages across the link and that
complement the application-level security offered
by DLMS.

DLMS User Association

Industriestrasse 53 Page 7
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
 3.9 End-to-End, Application-to-Application security
DLMS is communication technology agnostic, meaning that the application messages can
be carried end-to-end, application-to-application between the entities hosting those
applications, over virtually any communication technology.

Data exchange may occur directly between a Head End System (HES) acting as a client,
and a smart device or meter, acting as a server (or set of servers). Alternatively, data
exchange can take place indirectly through gateways or concentrators located in between.

Additionally, third parties, such as back-office applications of market participants or utility

billing systems, are often involved. DLMS supports data exchange between third parties and
servers through the HES, using a client as an agent. A message transported and protected
between a third party and a server may also receive additional protection during its transport
between the client and the server.

DLMS User Association

Industriestrasse 53 Page 8
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
Intermediate entities may need to interpret messages for locally processing and to determine
how to forward them. As a result, the protection applied to the messages may need to be
removed and then re-applied. When a message contains critical data that should not be
disclosed to an interim entity, additional protection must be implemented using COSEM data
protection.

Different sections of the communication path may utilize different communication media,
and the protection provided by the lower layers typically extends only between the two
endpoints of a link. To address these concerns, DLMS offers end-to-end, application-to-
application security, applying protection at the source application and verifying and
removing it at the destination application.

DLMS User Association

Industriestrasse 53 Page 9
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
4 DLMS Security Mechanisms
4.1 Entity Authentication
Entity authentication is the process of verifying that an entity is indeed who it claims to be.
When a client seeks to establish an Application Association (AA) with a server, mutual
authentication between the two entities is required. This is accomplished through the
exchange of arbitrary challenges and the results of the cryptographic processing of those
challenges. If either the client or the server fails to authenticate successfully, the AA cannot
be established and data exchange cannot occur.

Entity authentication is available with explicitly established AAs. Once the message
exchange phase is complete, the AA is released.

4.2 Role-Based Access (RBAC)

Role-based access is a method of restricting access to data based on the role of the entity
seeking access.

DLMS User Association

Industriestrasse 53 Page 10
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
In DLMS, this is facilitated by Application Associations (AAs) between clients and servers. Each
AA provides a specific view of the COSEM objects implemented in the server, which varies
depending on the client’s role. This “view” includes a list of visible objects with the access
rights to their attributes and methods. The access rights specify the operations that can be
performed (e.g. read, write) and the required protection on the requests and responses.
A server can support several AAs with different clients, allowing each client to access data
according to its designated role.

4.3 Message Protection

As previously mentioned, COSEM object attributes and methods are accessed through
application layer services. The service primitives (.request, .indication, .response, .confirm) are
encoded by the application layer to construct messages, which are then transmitted through
the communication network.
Access rights for each COSEM object and method dictate the protection required for
granting access to messages:
• If confidentiality is required, encryption is applied.
• If integrity is required, authentication is applied.
• If non-repudiation is required, a digital signature is utilized.
Additionally, an AA defines the security policy, specifying the protection that must be applied
to each message.

Protection is applied and removed in a layered manner, with each layer defining the
involved parties and the type of protection required. This protection may include
authenticated encryption using symmetric key cryptography or digital signatures employing
public key cryptography.

DLMS User Association

Industriestrasse 53 Page 11
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
 4.4 Data Protection
As explained above, both the messages and the data they carry, such as COSEM object
attributes values and method invocation/response parameters, can be protected.

Data protection is achieved by accessing attributes and/or methods of target COSEM

objects indirectly through Data Protection objects. These objects provide the necessary
security context to apply, verify, or remove protection on COSEM data. The same protection
options available for message protection can also be applied to COSEM data.
When protected data needs to be written, it is first stored in the protected_buffer attribute of
the Data Protection object. This object holds the required protection parameters and the
security material. Once the protection is removed, the data is written to the target attributes.
Similarly, when protected data needs to be read, it is first retrieved into the protected_buffer,
where the stipulated protection is applied using the necessary security material. The client
then reads from this protected_buffer.
Methods are also available to read or write a list of target attributes with protected data ot to
invoke a target method with protected parameters.

Data Protection Use Cases:

Use case 1: A third party (TP) needs to write confidential data, such as contractual or
price information, to the server. The TP encrypts the data, ensuring it remains
inaccessible to any intermediate entities. Only the server can decrypt the data,
preserving the confidentiality end-to-end.
Use case 2: The server sends confidential data, such as consumption values or debt, to
a third party. The server encrypts the data, and the TP decrypts it on receipt.

DLMS User Association

Industriestrasse 53 Page 12
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
 4.5 Firmware Upgrade
DLMS provides an Image Transfer mechanism that enables the client to deploy new firmware
images to the server, verify them, and then activate them. When a firmware update is
needed, the manufacturer provides the meter operator with a new, securely protected
image, which may contain one or more images. The client transfers this image to the servers,
and during the verification process, the protection of the image is checked before it is
activated.

The mechanism is modelled using the Image Transfer COSEM object, which provides
attributes and methods for initiating the image transfer, transferring image blocks, filling any
gaps that may occur during the transfer, verifying the transferred image and activating it.

The initial image transfer and black transfer can occur via broadcast or multicast. However,
filling the gaps, verification and activation processes are performed using unicast.

4.6 Communication Port Protection

A key aspect of the DLMS security framework is safeguarding communication ports from
potential attacks. This is modelled using Communication Port Protection objects, which help
secure the server’s communication ports from malicious attempts. These objects are
particularly effective in mitigating replay and brute force attacks by limiting the number of
allowed communication attempts.

DLMS User Association

Industriestrasse 53 Page 13
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
 4.7 Security Logs
Security logs enable monitoring of protected messages and data exchanges. The logs are
stored by Profile Generic Objects and can include information such as the number of
correctly and erroneously ciphered messages received, invocation counter values,
timestamps of errors, and other relevant data. The client can retrieve and analyze the data
and take appropriate actions when necessary.

4.8 Security and Efficiency

The use of security mechanisms requires additional computation, leading to increased time
and power consumption. Moreover, protection adds overhead to the messages, as
protected messages contain a security header as well as an authentication tag or digital
signature. Security headers provide information about the parties involved, the applied
security measures and the key used.
To minimize the impact of overheads and optimize communication efficiency, DLMS uses
concepts such as aggregated services, composable messages, compression and block
transfer with streaming and lost block recovery. These features help reduce message size and
the number of exchanges, this optimizing the communication channel capacity.

For example, unified ACCESS services allow reading and writing multiple attributes and
invoking several methods in a single request/response exchange, aggregating numerous
operations into one. To protect the ACCESS service, security computations are performed
only once, and the overhead is transferred only once. If an aggregated message becomes
lengthy, compression and block transfer mechanisms can be applied.
For additional information, please refer to the DLMS UA Efficiency White Paper.

4.9 Security Algorithms, Security Suites, Security Policy, Security Keys and
Security Algorithms
DLMS uses a variety of security algorithms to provide security services:
• Confidentiality and Data Integrity: The AES-GCM algorithm is used to provide
encryption only, authentication only, or both, a method known as authenticated
encryption.
• Digital Signature: The ECDSA elliptic curve digital signature algorithm is utilized for
creating digital signatures.
• Key Transport: The Key Wrap algorithm for securely transporting keys.
• Key Agreement: The ECDH elliptic curve Diffie-Hellman Key Agreement algorithms
facilitate key agreement.
• Hash Algorithms: These are used as part of the digital signature and key
agreement algorithms.
The rationale behind selecting these algorithms is described in detail in the DLMS UA Green
Book.

DLMS User Association

Industriestrasse 53 Page 14
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
Additionally, compression techniques are employed to reduce the length of messages
transferred, thereby improving efficiency. Compression is also included in the DLMS security
suites, as indicated in the security header of the encrypted messages.

4.10 Security Suites

Security suites define the set of available security algorithms. Currently, DLMS provides three
security suites to address various requirements.

This set of the security algorithms is referred to as the NSA Suite B, which has evolved into the
Commercial National Security Algorithm (CNSA) Suite.
The concept of security suites ensures that the DLMS security specification remains future
proof: the security mechanisms can seamlessly integrate with new security suites that may
need to be introduced in the future, allowing them to keep pace with advancements in
cryptography.

4.11 Security Policy

The security policy outlines the protection measures to be applied to each request and
response within an Application Association (AA). The security policy is applied globally,
meaning it governs all exchanges within that AA.
If a device supports multiple AAs, each can have its own distinct security policy, enabling
selective application of protection and enhancing overall efficiency.
The Security Setup object provides attributes and methods for managing the security policy
effectively.

DLMS User Association

Industriestrasse 53 Page 15
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
 4.12 Security Keys
DLMS/COSEM supports several key types.

For authenticated encryption and key transfer, symmetric key algorithms are used,
necessitating that both parties share the same key. Symmetric keys can be categorized by
their purpose and lifespan. The purposes of symmetric keys include:
• Key Encryption Key, KEK, also known as master key, is used to encrypt and decrypt
other symmetric keys.
• Encryption Key is utilized to encrypt and decrypt DLMS messages or COSEM data.
The AES-GCM algorithm requires a single block cipher key to provide both
encryption and authentication.
• Authentication Key. In addition to the encryption key, an authentication key may
be used. This key, combined with the header of the ciphered message or data,
constitutes part of the Additional Authenticated Data.

Symmetric keys can be categorized based on their lifespan as follows:

• Global Key: Used across multiple instances of Application Associations (AAs)
established repeatedly between the same partners. This category includes unicast
encryption keys (GUEK), broadcast encryption keys (GBEK), and authentication
keys (AK).
• Dedicated Key: Utilized for a single instance of an AA established between the
same partners. Its lifespan coincides with that of the AA. A dedicated key can
only be a unicast encryption key.

DLMS User Association

Industriestrasse 53 Page 16
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
 • Ephemeral Key: Employed for a single exchange, providing temporary security for
that specific interaction.

4.13 Establishment of Symmetric Keys

Symmetric keys can be established in the following ways:
• Out-of-Band: Keys are securely deployed on the client(s) and server(s) without
transmitting them over the network.
• Via Key transfer during AA Establishment: This occurs during the establishment of
an AA, or through key wrapping using the key_transfer method of the Security
setup object, and as part of the exchange of the protected messages or data.
• Via Key agreement, using an appropriate Diffie-Hellman algorithm, using the
key_agreement method of the Security setup object, and as part of the
exchange of the protected messages or data.
The key utilized is specified in the header of the protected message or data and may be
classified as an identified key, wrapped key or agreed key:
• In the case of identified keys, clients must share a key with each server (logical
device). These keys can be updated using key transfer or key agreement.
• In the case of wrapped keys, the key to be used is newly generated and
transferred securely.
• In the case of agreed keys, the partners exchange necessary data to reach an
agreement on the key.
The advantage of key transfer and key agreement is that the partners do not need to share
the same keys. However, these methods require additional computational resources and
increase message overhead.
For digital signature and key agreements, public key cryptography is used, where one party
possesses a private key while its partner holds the corresponding public key. Public keys are
managed through Public Key Certificates, which link the public key to the entity. Public key
cryptography required a Public Key Infrastructure that includes at least a Root Certification
Authority and may involve a chain of Certification Authorities.

5 Conclusion
This White Paper has outlined the DLMS security framework, emphasizing its end-to-end,
application-to-application security concept, the rationale behind this approach, and the
various security mechanisms that support it.
For a deeper understanding of the implementation and operation of DLMS-based systems,
readers are encouraged to refer to the DLMS UA Books. These resources provide
comprehensive guidance on the security protocols, key management practices, and
practical considerations necessary for successfully deploying and maintaining secure DLMS
environments.
By adhering to the principles and best practices detailed in these references, organizations
can enhance their security posture and ensure the integrity and confidentiality of their data
exchanges within DLMS frameworks.

DLMS User Association

Industriestrasse 53 Page 17
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
6 References
• DLMS UA 1000-1 , Ed. 13, the “Blue Book”. It describes the COSEM object model
and OBIS.
• DLMS UA 1000-2 , Ed. 9, the “Green Book”. It describes the DLMS/COSEM
application layer and some lower layers and communication profiles.
• IEC / EN 62056-5-3, also available as ANSI C12 / IEC 62056-5-3: Electricity metering
data exchange -The DLMS/COSEM suite -Part 5-3: DLMS/COSEM application layer
• IEC / EN 62056-6-2, also available as ANSI C12 / IEC 62056-6-2: Electricity metering
data exchange -The DLMS/COSEM suite -Part 6-2: COSEM interface classes
• IEC / EN 62056-6-1, also available as ANSI C12/ IEC 62056-6-1: Electricity metering
data exchange -The DLMS/COSEM suite -Part 6-1: Object Identification System
(OBIS)
• EN 137571: Communication systems for meters NIST and FIPS security standards
• Commercial National Security Algorithm Suite:
https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm
• DLMS UA White Paper: Efficiency of DLMS/COSEM for large systems with
constrained resources

7 Definitions
• DLMS/COSEM: refers to the application layer providing xDLMS services to access
COSEM interface object attributes. Also refers to the DLMS/COSEM Application
layer and the COSEM data model together.
• Client: application process running in the data collection system
• Server: an application process running in a metering equipment
• Logical device: abstract entity within a physical device, representing a subset of
the functionality modelled with COSEM objects
• Mutual authentication: entity authentication which provides both entities with
assurance of each other's identity
• Application Association: cooperative relationship between two application
entities, formed by their exchange of application protocol control information
through their use of presentation services
• Access rights: they determine the rights of the client(s) to access COSEM object
attributes and methods within an AA
• Image: binary data of a specified size
• Security services: mechanisms used to provide confidentiality, data integrity,
authentication or non-repudiation of information
• Symmetric key algorithm: a cryptographic algorithm that uses the same secret
key for an operation and its complement (e.g., encryption and decryption)

DLMS User Association

Industriestrasse 53 Page 18
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
 • Public key (asymmetric) cryptographic algorithm: a cryptographic algorithm that
uses two related keys, a public key and a private key. The two keys have the
property that determining the private key from the public key is computationally
infeasible
• Authentication: a process that establishes the source of information, provides
assurance of an entity’s identity or provides assurance of the integrity of
communications sessions, messages, documents or stored data
• Encryption: a process of changing plaintext into ciphertext using a cryptographic
algorithm and key
• Digital signature: the result of a cryptographic transformation of data that, when
properly implemented with supporting infrastructure and policy, provides the
services of: 1) origin authentication, 2) data integrity, and 3) signer non
repudiation
• Cryptographic key: a parameter used in conjunction with a cryptographic
algorithm that determines its operation in such a way that an entity with
knowledge of the key can reproduce or reverse the operation, while an entity
without knowledge of the key cannot
• Security context: the security context is relevant when the application context
stipulates ciphering. It comprises the security suite, the security policy, the security
keys and other security material. It is managed by “Security setup” COSEM objects
• Security policy: determines the kind(s) of protection to be applied generally to all
xDLMS APDUs exchanged within an AA
• Key wrapping: a method of encrypting keying material (along with associated
integrity information) that provides both confidentiality and integrity protection
using a symmetric key
• Key-transport: a (pair-wise) key-establishment procedure whereby one party (the
sender) selects a value for the secret keying material and then securely distributes
that value to another party (the receiver). Contrast with key agreement.
• Key agreement: a (pair-wise) key-establishment procedure in which the resultant
secret keying material is a function of-information contributed by both
participants, so that neither party can predetermine the value of the secret keying
material independently from the contributions of the other party. Contrast with
key-transport.

DLMS User Association

Industriestrasse 53 Page 19
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
8 About DLMS UA
The DLMS User Association is a non-profit organization and a leading voice internationally in
interoperable and secure data exchange to support strategic energy and water
management.
Our mission is to foster member collaboration, drive innovation through standardization and
deliver world leading specifications and certification programs that support interchangeable
devices and secure data exchange.
Recognized by major international standardization bodies, over 300 members currently use
the DLMS specifications in the IoT, e-Mobility, Smart Grid and Smart Metering segments.

9 Disclaimer and Copyright Notice

The information within this document is intended for general informational purposes only. The
information herein may not be exhaustive and does not imply any element of a contractual
relationship. There is no assurance as to the accuracy or completeness of such information.
DLMS User Association, its members and their affiliates make no warranties or representations
whatsoever, and disclaims all warranties, express or implied, including any warranty of
merchantability, title, noninfringement, fitness for any particular purpose, that the contents of
this document is free from error or any warranty otherwise arising out of this document.
To the extent not prohibited by law, DLMS UA, its members, and their affiliates disclaim all
liability relating to use of this document and any information contained in it, including
business interruption, loss of revenue, profits, or data for special, indirect, consequential,
incidental or punitive damages, caused and regardless of the theory of liability, and even if
DLMS UA, its members or their affiliates have been advised of the possibility of such damages.
This document is proprietary to DLMS UA and may contain or cover subject matter this is DLMS
UA Intellectual Property and its Members’ Intellectual Property. The publication of this
document does not grant any license to any DLMS UA Intellectual Property or to its Members’
Intellectual Property. The DLMS UA trademark and logos are owned by DLMS UA. Other third-
party brands and names that may have been used in this document are the property of their
respective owners.
This document is subject to change without notice.

Copyright © 2024 DLMS User Association

DLMS User Association

Industriestrasse 53 Page 20
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
Index
1 Introduction ........................................................................................................ 2
2 Security is essential for critical infrastructure .................................................... 3
2.1 The DLMS Security Framework ............................................................................... 3
2.2 Security Services ..................................................................................................... 3
3 Overview of DLMS UA & DLMS Specifications ................................................. 4
3.1 Object-Oriented Data Model ............................................................................... 4
3.2 Application Layer Services .................................................................................... 4
3.3 Communication Profiles......................................................................................... 5
3.4 Three-Step Approach to Data Exchange ............................................................ 5
3.5 Modeling ................................................................................................................. 5
3.6 Semantics: COSEM Object Model ........................................................................ 5
3.7 Syntactics: Messaging............................................................................................ 6
3.8 Transport.................................................................................................................. 7
3.9 End-to-End, Application-to-Application security ................................................. 8
4 DLMS Security Mechanisms ............................................................................. 10
4.1 Entity Authentication ............................................................................................10
4.2 Role-Based Access (RBAC) ..................................................................................10
4.3 Message Protection ..............................................................................................11
4.4 Data Protection .....................................................................................................12
4.5 Firmware Upgrade ................................................................................................13
4.6 Communication Port Protection ..........................................................................13
4.7 Security Logs ..........................................................................................................14
4.8 Security and Efficiency .........................................................................................14
4.9 Security Algorithms, Security Suites, Security Policy, Security Keys and Security
Algorithms ........................................................................................................................14
4.10 Security Suites .....................................................................................................15
4.11 Security Policy ....................................................................................................15
4.12 Security Keys .......................................................................................................16
4.13 Establishment of Symmetric Keys ......................................................................17

DLMS User Association

Industriestrasse 53 Page 21
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com
5 Conclusion ........................................................................................................ 17
6 References ........................................................................................................ 18
7 Definitions .......................................................................................................... 18
8 About DLMS UA ................................................................................................ 20
9 Disclaimer and Copyright Notice ................................................................... 20

DLMS User Association

Industriestrasse 53 Page 22
CH-6312 Steinhausen, Switzerland
Tel: +41 41 539 1186
Email: DLMS@DLMS.com