EN 13757-1:2021

SLOVENSKI STANDARD
01-februar-2022
Nadomešča:
SIST EN 13757-1:2015
Komunikacijski sistemi za merilnike - 1. del: Izmenjava podatkov
Communication systems for meters - Part 1: Data exchange
Kommunikationssysteme für Zähler - Teil 1: Datenaustausch
Systèmes de communication pour compteurs - Partie 1 : Échange de données
Ta slovenski standard je istoveten z: EN 13757-1:2021
ICS:
33.200 Daljinsko krmiljenje, daljinske Telecontrol. Telemetering
meritve (telemetrija)
35.100.70 Uporabniški sloj Application layer
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 13757-1
EUROPEAN STANDARD
NORME EUROPÉENNE
December 2021
EUROPÄISCHE NORM
ICS 33.200; 35.100.70; 35.240.99; 91.140.50 Supersedes EN 13757-1:2014
English Version
Communication systems for meters - Part 1: Data exchange
Systèmes de communication pour compteurs - Partie 1 Kommunikationssysteme für Zähler - Teil 1:
: Échange de données Datenaustausch
This European Standard was approved by CEN on 16 August 2021.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2021 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 13757-1:2021 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 6
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 8
4 General description and security . 10
4.1 Basic vocabulary . 10
4.2 Layered protocols . 10
4.3 Security . 13
5 Network Architecture . 17
5.1 M/441 Mandate . 17
5.2 General. 18
5.3 Basic architecture . 18
5.4 Metering Architecture . 19
5.5 Singular access point . 21
5.6 Self-configurable network . 21
5.7 Hand Held Unit for local access . 21
5.8 Network layers . 21
5.9 Multiple access . 21
6 Application Layers for Metering . 22
6.1 General. 22
6.2 COSEM Application Layer for Metering . 22
6.3 Companion Specification . 22
6.4 COSEM Basic Principles . 23
6.5 Management of a COSEM Device . 24
6.6 Lower layers . 25
7 Data Exchange . 26
7.1 General. 26
7.2 Data exchange using direct local connection . 26
7.3 Data exchange using wired local area network (LAN) . 27
7.4 Data exchange using wide area network (WAN) . 28
7.5 Data exchange using M-Bus radio communication . 34
7.6 Data Exchange using HDLC . 34
8 Upper Layer Protocols . 35
8.1 Introduction . 35
8.2 Transport sub-layer . 35
8.3 Application sub-layer . 38
9 Cross-application data handling. 39
9.1 General. 39
9.2 Data tunnelling . 40
9.3 Data translation . 42
10 Extensions to COSEM . 42
10.1 Introduction . 42
10.2 M-Bus tunnelling . 42
10.3 Specific object type – Error Reporting Object . 43
11 Object Identification System (OBIS) . 44
11.1 Object Identification System (Variable naming rules) . 44
11.2 Abstract Objects (A = 0) . 48
11.3 Media specific value groups . 49
Annex A (normative) Basic class meters . 99
Annex B (informative) DLMS Glossary . 102
European foreword
This document (EN 13757-1:2021) has been prepared by Technical Committee CEN/TC 294
“Communication systems for meters”, the secretariat of which is held by DIN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by June 2022, and conflicting national standards shall be
withdrawn at the latest by June 2022.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 13757-1:2014.
Significant technical changes between this document and EN 13757-1:2014 are:
• The text has been updated to reflect increased use of IPv6 in 4.2.3;
• Figure 4 has been replaced with Table 3;
• Key wrapping has been added in 4.3.3.1;
• A description of pre-established Application Associations has been added in 4.3.4;
• Figure 11 has been replaced with a table and enhanced;
• A reference to GSM CSD has been added in 7.4.2;
• A security clause has been added in 7.5.4;
• 8.2.1 has been updated in line with 8.2.2 and 8.2.3, and now references EN 62056-4-7;
• Previous subclause 9.2.2.3 has been removed;
• New content has been added in 9.3 to align with EN 13757-3:2018, Annex H;
• Interface classes now refer to EN IEC 62056-6-1 and EN IEC 62056-6-2 to remove duplication;
• Clause 11 has had minor updates and been aligned with DLMS/COSEM object model;
• Mandatory COSEM Objects have been added in A.2;
• Annex B has been updated in line with EN 62056-6-1 and EN 62056-6-2;
• Annex D now references EN62056-6-1;
• The bibliography has been updated.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
The OBIS and COSEM Clause 6 to Clause 11 of this document are prepared in liaison with the DLMS User
Association based in Zug, Switzerland, and more information about DLMS/COSEM can be obtained from
www.dlms.com.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the
United Kingdom.
Introduction
This document is referred to in the CEN/CLC/ETSI TR 50572:2011, Functional Reference Architecture
for Communications in Smart Metering Systems, as a standard for communications between elements in
the Smart Metering Architecture. The M/441 Mandate, which led to the CEN/CLC/ETSI TR 50572, is
driving significant development of standards in smart metering.
This document has been amended to reflect significant updates in Security practices, and updates to the
OBIS model to reflect the state of the art. COSEM Classes have been removed from this document, as
they are published in the EN IEC 62056-6-2 standard and there is a risk of contradiction.
For an overview of activities, see M/490, the mandate for standardization for smart grid, available from
https://ec.europa.eu/energy/sites/ener/files/documents/2011_03_01_mandate_m490_en.pdf, and
more generally https://ec.europa.eu/energy/en/topics/markets-and-consumers/smart-grids-and-
meters/smart-grids-task-force.
This document describes the data exchange and communications for meters and remote reading of
meters in a generic way. It is Part 1 of EN 13757.
The main use of EN 13757-1 is to provide an overview of the protocols at the different levels and to
provide a specification for the DLMS/COSEM application Layer for meters.
Additional parts to the series of standard EN 13757 are:
— Part 2: Wired M-Bus communication;
— Part 3: Application protocols;
— Part 4: Wireless M-Bus communication;
— Part 5: Wireless M-Bus relaying;
— Part 6: Local Bus;
— Part 7: Transport and security services.
The world of metering is going through a period of rapid change, and it is anticipated that this and other
parts of the standard will require amending in a short period of time.
NOTE 1 This document makes repeated reference to EN 62056 standards. While the list of references is helpful,
an essential companion to this document is the EN IEC 62056-6-2 standard.
NOTE 2 Some of the ISO/IEC documents listed under Clause 2 could be available only from ISO or IEC directly.
If the document you require is not available from your national standards organization, ISO or IEC can be
contacted to establish the status of the document and its availability. ISO can be contacted via www.iso.org.
NOTE 3 Clause 3 contains the terms and definitions special to remote reading of meters. Annex B is used to
explain terms related to the object oriented model used in COSEM, detailed in EN IEC 62056-6-2 and OBIS,
detailed in EN 62056-6-1.
1 Scope
This document specifies data exchange and communications for meters in a generic way.
This document establishes a protocol specification for the Application Layer for meters and establishes
several protocols for meter communications which can be applied depending on the application being
fulfilled.
This document also specifies the overall structure of the Object Identification System (OBIS) and the
mapping of all commonly used data items in metering equipment to their identification codes.
NOTE Electricity meters are not covered by this document, as the standardization of remote readout of
electricity meters is a task for CENELEC/IEC.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 13757-2:2018, Communication systems for meters - Part 2: Wired M-Bus communication
EN 13757-3:2018, Communication systems for meters - Part 3: Application protocols
EN 13757-4:2019, Communication systems for meters - Part 4: Wireless M-Bus communication
EN 13757-5:2015, Communication systems for meters - Part 5: Wireless M-Bus relaying
EN 13757-6, Communication systems for meters - Part 6: Local Bus
EN 13757-7:2018, Communication systems for meters - Part 7: Transport and security services
EN 60870-5-2, Telecontrol equipment and systems - Part 5: Transmission protocols - Section 2: Link
transmission procedures (IEC 60870-5-2)
EN 62056-3-1, Electricity metering data exchange - The DLMS/COSEM suite - Part 3-1: Use of local area
networks on twisted pair with carrier signalling (IEC 62056-3-1)
EN 62056-4-7:2016, Electricity metering data exchange - The DLMS/COSEM suite - Part 4-7:
DLMS/COSEM transport layer for IP networks (IEC 62056-4-7)
EN 62056-5-3, Electricity metering data exchange - The DLMS/COSEM suite - Part 5-3: DLMS/COSEM
application layer (IEC 62056-5-3)
EN 62056-6-1:2017, Electricity metering data exchange - The DLMS/COSEM suite - Part 6-1: Object
Identification System (OBIS) (IEC 62056-6-1:2017)
EN 62056-6-2:2018, Electricity metering data exchange - The DLMS/COSEM suite - Part 6-2: COSEM
interface classes (IEC 62056-6-2:2017)
EN 62056-9-7, Electricity metering data exchange - The DLMS/COSEM suite - Part 9-7: Communication
profile for TCP-UDP/IP networks (IEC 62056-9-7)

1) The EN 62056 series of standards are in the process of revision/renumbering.
EN 62056-21:2002, Electricity metering - Data exchange for meter reading, tariff and load control - Part
21: Direct local data exchange (IEC 62056-21:2002)
EN 62056-42, Electricity metering - Data exchange for meter reading, tariff and load control - Part 42:
Physical layer services and procedures for connection-oriented asynchronous data exchange (IEC 62056-
42)
EN 62056-46:2002, Electricity metering - Data exchange for meter reading, tariff and load control - Part
46: Data link layer using HDLC protocol (IEC 62056-46:2002)
ITU-T V.250, Serial asynchronous automatic dialling and control
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at https://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
3.1
authorized party
utility, energy retailer, network operator, meter operator or data collection company authorized to
access the information stored in the meter that is accessible to them according to the application
association they can use
3.2
base conditions
fixed conditions used to express the volume of gas independently of the measurement conditions
EXAMPLE: temperature of 273,15 K and absolute pressure of 1,013 25 bar or temperature of 288,15 K and
absolute pressure of 1,013 25 bar
3.3
billing period
period over which a consumer bill is calculated
Note 1 to entry: See also B.7.
3.4
calendar
mechanism to program changes to active registers for Time-of-Use Tariffs
Note 1 to entry: See Activity Calendar B.3.
3.5
concentrator
intelligent station in a hierarchical communications network where incoming data (generated by
multiple meters) is processed as appropriate and then repackaged, relayed, retransmitted, discarded,
responded to, consolidated, prioritized and/or increased to multiple messages
3.6
disturbance
influence quantity having a value within the limits specified, but outside the specified rated operating
conditions of the measurement instrument
3.7
gas-volume conversion device
device that computes, integrates and indicates the volume increments measured by a gas meter as if it
were operating at base conditions, using as inputs the volume at measurement conditions as measured
by the gas meter, and other characteristics such as gas temperature and gas pressure
Note 1 to entry: The conversion device can also include the error curve of the gas meter and associated
measuring transformers.
Note 2 to entry: The deviation from the ideal gas law can be compensated by the compressibility factor.
3.8
hand held terminal
portable device for reading and programming metering equipment at the customer’s premises or at the
access point
3.9
index
current reading of the total volume (mass) passed through the meter
3.10
index difference
difference between the index at the end of a measurement or billing period
and the index at the start of the same measurement or billing period
Note 1 to entry: Index difference over a certain measurement or billing period is also known as consumption. For
consumption, thresholds can be specified.
3.11
IPsec
end-to-end security scheme operating in the Internet Layer
Note 1 to entry: It works on IPv4 and IPv6 Networks.
Note 2 to entry: It is described in IETF RFC 4301.
3.12
measurement conditions
conditions of the gas whose volume is measured, at the point of measurement
EXAMPLE: the temperature and the pressure of the gas
3.13
scaler
exponent (to the base of 10) of the multiplication factor
Note 1 to entry: If the value is not numerical, then the scaler will be set to 0.
Note 2 to entry: See also B.49
3.14
specified measuring range
set of values of measurements (the pressure for the pressure transducer or temperature for the
temperature transducer) for which the error of the conversion device is intended to lie within the limits
specified in the standard
Note 1 to entry: The upper and lower limits of the specified measuring range are called maximum value and
minimum value respectively.
3.15
specified field of measurement of a conversion device
set of values at measurement conditions for which the error of the conversion device is within specified
limits
Note 1 to entry: A conversion device has a measuring range for every quantity that it processes.
Note 2 to entry: The specified field of measurement applies to the characteristic quantities of the gas that are
used to determine the conversion factor.
3.16
unit
enumeration defining the physical unit
Note to entry: See also B.69.
4 General description and security
4.1 Basic vocabulary
All communications involve two sets of equipment represented by the terms Caller system and Called
system. The Caller is the system that decides to initiate a communication with a remote system known
as the Called party; these denominations remain valid throughout the duration of the communication.
A communication is broken down into a certain number of transactions. Each transaction is represented
by a transmission from the Transmitter to the Receiver. During the sequence of transactions, the
Caller and Called systems take turns to act as Transmitter and Receiver.
The terms Client and Server have the same meanings as in the DLMS model EN 61334-4-41. The
Server is the system (meter) that acts as a receiver for service requests. The Client is the system
(usually a data collecting system) that uses the Server for a specific purpose by means of one or more
service requests.
The situation involving a Caller Client and a Called Server is undoubtedly the most frequent case, but
a communication based on a Caller Server and a Called Client is also possible, in particular to report
the occurrence of an urgent alarm and can offer savings in terms of data volumes in mass metering
applications.
While the terms Caller and Called can imply a session, sessionless communications using, for example
UDP over IP, are also a valid approach to communications for smart meters depending on the type of
network.
4.2 Layered protocols
4.2.1 General
The purpose of this subclause is to explain, in a summarized way, the layered approaches and to explain
the development since the initial issue of this document.
In order to perform automatic reading of meters, this document assumes a protocol stack approach. A
protocol stack is divided into layers in order to reduce the complexity of the communicating system.
Each layer provides services to the layer above on the basis of the layer below.
4.2.2 7 Layer Protocol
The architecture of data communication in this document is modelled using the ISO – OSI 7-layer
reference model ISO/IEC 7498-1. The model is shown in Figure 1.

Key
A physical media 4 transport
B relay entity 5 session
1 physical 6 presentation
2 data link 7 application
3 network
Figure 1 — The OSI 7-layer model
All layers have a corresponding layer at the other end of the communications link. The three upper
layers are application related. The three lower layers are communications related. The Transport Layer
creates the link between them. There may be multiple instances of the three lower layers if a relay is
inserted between the communicating partners.
It shall be kept in mind that this is a model and not an implementation guide, i.e. not all
implementations follow this model. An example of this is the Internet series of standards. They follow
the model for the four lower layers, but do not specify the application related part as independent
layers. Layers not necessary and thus not implemented in a specific protocol may be handled as null
layers.
4.2.3 IP Protocol
IPv4 and IPv6 are widely used protocols for transport of all kinds of data, including metering data. Its
principal advantages are that it can be used to carry a wide variety of applications over a wide range of
communications media.
Table 1 — Connection method independent Application Layers
Application Common, method
Layer independent layer
TCP/UDP IP Wrapper
Transport UDP TCP
Network IP
Data Link Any Any
Physical Any Any
The architecture shown in Table 1 allows for multiple different communications media, while at the
same time keeping a common connection method independent Application Layer. This is important as
different connection methods are suited for different operating environments. The use of common
layers lowers the overall cost and complexity of a remote readout metering system.
Users of the TCP/IP or UDP/IP protocol shall follow the standard EN 62056-4-7.
4.2.4 3 Layer Protocol
A very common model for simple meter readout without any relays is a collapsed three layer model as
depicted in Table 2.
This is the IEC 3-layer model EN 61334-4-1, which is derived from OSI 7-layer model documented in
ISO/IEC 7498-1.
The three layers of the IEC model are shown in Table 2.
Table 2 — IEC 3-layer model
Layer 7 Application
Layer 2 Data link
Layer 1 Physical
NOTE 1 The layer numbers refers to the numbering in the ISO-OSI 7_layer model.
This model ensures that the original concept of a model where the Application Layer is independent of
communication transport method used, is maintained.
This division makes it possible to achieve an Application Layer that is independent of the
communication connection method used, and the possibility of using the same communication method
transport mechanism for different Application Layers. An example of this is shown in Table 3. The
Physical Layer and in some cases the Data Link Layer are closely related and highly dependent on the
Layers 1 and 2 depend on the connection method used (Optical interface, Power Line Carrier-Low
Voltage (PLC – LV), Public Switched Telephone Network (PSTN), VHF/UHF radio, Twisted Pair cable
(TP)). This document requires Application Layers that are independent of the connection method used.
Table 3 — Link and Physical layers in the 3 layer model
Application
Common, method independent layer: this document/EN 13757-3/EN 16836-3
Layer
Transport/Link
EN 62056-46 EN 13757-7/EN 13757-4 EN 16836-2 ?
Layer
EN 13757-2/ EN 13757-4/
Physical Layer EN 62056-21 EN 62056-42 EN 16836-2 ?
EN 13757-6 EN 13757-5
Future
Wired M-Bus
Connection Optical Wireless M- methods
PSTN (twisted pair ZigBee®
Method (Local) Port Bus (to be
baseband)
defined)
NOTE 2 The EN IEC 62056 series of standards provides a set of communications profiles for use with DLMS.
These standards, are enumerated as 62056-7-x for Local Network technologies, 62056-8-x for Neighbourhood
Network technologies, and 62056-9-x for Wide Area Network technologies.
4.3 Security
4.3.1 General
The data transferred between meters and head end systems is, in many cases, be regarded as the
private data of the energy user, and therefore is subject to EU and national rules for the protection of
said data. If communications to the meter can influence demand, then the meter can form part of critical
national infrastructure. If data transferred from the head end to the meter can control the meter, then
the integrity of the data can be a safety issue as well.
A mandate for standardization for security, M/487, is in place, and this is driving further
standardization efforts in this area. A copy of the mandate can be obtained at
ftp://ftp.cencenelec.eu/CENELEC/EuropeanMandates/M_487.pdf.
Security, therefore, is a much higher priority than in the earlier version of this document.
There are four key security aspects required for smart metering:
a) Ensuring that only those who should have access to information are granted access;
b) Ensuring that information is not changed accidentally or deliberately;
c) Ensuring that the source of the information cannot be falsified;
d) Ensuring that the source of information cannot be denied.
Item a) is normally named Confidentiality. This can be achieved by limiting the physical access, or by
using cryptographic methods. Both methods shall be considered depending on the application and
communications methods being used. It should be noted that data encrypted cannot be retrieved again
if the ‘key’ is lost. The normal method for ensuring privacy is by encrypting information. With the
cryptographic methods available this is very safe and reasonably easy to perform. The real issue is not
the encryption and decryption, but the handling and distribution of the encryption/decryption key(s) –
see 4.3.3.
Item b) is normally named Integrity. Integrity in communication is normally achieved by generating a
compressed signature over the message, referred to as a message digest. If the message digest cannot
be recalculated on the data received, then it is possible that the data are damaged. A method that is
falling out of favour is Cyclic Redundancy Check. CRC has been in use for a long time to generate
message digests. The strength of CRC is that is very simple to implement efficiently in hardware and
that it is reasonably good at detecting random/accidental errors. The weakness is that it is unable to
detect deliberate changes to the information. Protection against deliberate changes to information can
be achieved by using cryptographic methods in the generation of the message digest. A message digest
is calculated using a secure hashing method or a key based method. The result of this is a 'signature' or
Message Authentication Code added to the end of the message. The MAC is recalculated when data are
received. The strength of the MAC is that it is impossible to modify the message in such a way that the
MAC is correct unless the ’key’ is known.
Item c) is named Authentication. Authentication ensures that the source of the message is the one
stated. It can be combined with Integrity. Authentication is not encryption but uses cryptographic
methods. It is not possible to distinguish between sources of information if they use the same key, and
therefore keys need to be dedicated to both ends of the data flow. Authentication will often ensure the
integrity of the data as well.
Item d) is an extension to item c) and named Non-repudiation. This requires that unique keys are used,
and that the sender and receives are using a cryptographic method with asymmetric keys. This ensures
that the receiver cannot generate a message that appears as if it came from the sender. This is often
achieved using a public key system.
NOTE 1 References for security specifications are extensive. NSA Suite B is in the process of being replaced by
the USA National Security Agency’s Commercial National Security Algorithm Suite (CNSA). This has many of the
same elements as the previous NSA Suite B, but requires AES-256, the P-384 curve, SHA-256 and SHA-384 and
required that RSA and DH with a 2048-bit modulus. There are a number of IETF RFCs and NIST documents that
document the application of these methodologies.
NOTE 2 EN 62056-5-3, in particular, details the tools that are available in DLMS/COSEM to deliver
confidentiality, authenticity and integrity to messaging.
4.3.2 Security Requirement Analysis/Threat Analysis
There are a number of items that need to be considered with respect to security. It is clear that a simple
AMR system that grabs meter index values infrequently is likely to require significantly lower levels of
security than more sophisticated meter management systems, especially where the network is used to
control devices in the home, or the meter is used for prepayment. Selection of key management and
encryption strategies is driven by the threat analysis. Such a threat analysis shall as well take man-in-
the middle and replay attacks into account.
An assessment of the risks and alternatives shall be carried out using a recognized method; for example
ISO/IEC 27033 (all parts) or ISO/IEC 15408 (all parts).
The financial world has had a focus on cost efficient data security for many years, and processes,
procedures and methods used there should be taken into account.
4.3.3 Key Management
4.3.3.1 General
Correct key management is essential to meet the security requirements of the smart metering system.
Correct handling of secure information like encryption keys is not straightforward. The keys require a
high level of protection. The principle of “need to know” shall be applied. In some situations there could
be a need for dual control, i.e. that one person alone cannot handle the whole key. Part of the threat
analysis should address the following concepts:
1) how many entities need access to the keys in order to be able to encrypt and decrypt data passed
from/to the meter;
2) how often keys will need changing;
3) how often some of the entities will change;
4) how key information is going to be distributed.
A meter is expected to have a lifetime in the order of 10 years. Therefore it is expected that keys will
need to be changed several times within that time span. Given the prohibitive cost of site visits it is
necessary that there is a method to distribute key information through the network in a secure manner.
The general concept is that there should at least be three levels of keys:
a) there is a master key used for distribution of a key encryption key, KEK;
b) there is a key-encryption-key, KEK, used for the distribution or generation of the normal key;
c) there are ‘normal’ keys for encryption and signing the data.
Depending on the level of security required, there could be a need for at least two keys, one for
encrypting the data and one for generating the message digest (secure hash), and these shall be
different keys. Different clients for the meter data should necessitate different sets of keys. It should
also be considered that meters with tariff functions, prepayment, and/or valves will need to be
confident in the instructions being received them and could need further keys to ensure non-
repudiation of these instructions.
Where a meter is supplied with a master key, care shall be taken to ensure that the key cannot be
derived from other data (for example serial number), and suitable methods shall be used to store and
distribute such master keys.
When keys are being supplied or updated, consideration should be given to using the three pass
protocol exchange method.
NOTE IETF RFC 4107 provides standardized best current practice on Cryptographic Key Management.
Key wrapping can be used in place of key encryption in certain circumstances.
4.3.3.2 Symmetrical or Asymmetrical Encryption
The classical concept is the use of a secret key, used for encryption as well as decryption, and hence is
known as symmetrical.
Asymmetric encryption dates back to around 1970. It uses two keys, a public and a private key.
Messages encrypted with a private key can only be decrypted with the public key and vice versa.
Public/private key are easier to handle as the public part can be distributed as plain text but they are
much larger than symmetrical keys take much more computing power to use. Public/private keys are
traditionally used for the distribution of secret keys and the generation of certificates with secret keys
being used for the data transactions.
A strategy often used is a hybrid approach, where a secret symmetrical key is created and shared using
asymmetrical encryption. This minimizes the risk of decryption of data, as long as the key is replaced in
less time than the expected time to use an attack to identify the key. This is because the data that could
be accessed is limited, and the key will have changed before simulated data can be effectively inserted
into the network. In practice, the use of this approach will depend on a reliable threat analysis and
monitoring, to ensure that keys are changed promptly. Asymmetrical encryption does not by itself
provide authentication. Authentication is provided by letting trusted third party sign the public
key/information from the sender. The receiver can then verify the authenticity of the sender by
verifying the signature.
NOTE EN 62056-5-3 and EN IEC 62056-6-2 support asymmetric and symmetric key algorithms.
4.3.4 COSEM Application Layer Security
COSEM has a system of clients with access to data in the meter governed by application associations.
The public client and management client shall be implemented. This requires that users create
application associations when initiating a session with the meter. When this session is established, the
Meter will limit data and configuration options to that permitted by configuration of the meter. The
exception is the management client, which generally has complete access to all aspects of the meter.
Establishment of this session can be done in an insecure way or a number of secure ways. Typical client
associations are listed in Table 4.
Table 4 — Typical Client Access Levels
Name Description
Public Client This client is usually configured to provide very little access, except to prove that
communications to the meter exist.
Data Collection Allows reading of ID’s, Alarm, Date/Time, Load Profile, TOU’s, MD’s, Blocks,
Client Cumulative Registers, measurement parameters
Extended Data Correction of time and Date, Resetting of MD’s
Collection Client
Management Allows Programming of Displays, setting of measurement, setting of ‘secret’ for
Client Data Collection and Extended Data Collection Clients
Manufacturer Allows specialized access for manufacturing operations
Client
Application associations can be associated with the properties and methods of OBIS objects directly,
either as a configurable object accessed via the management client or manufacturer client or specified
in a companion specification.
When an application association has been created using an appropriate level of security for the
application, the client messages can be expected to be encrypted and/or signed depending on the level
of privacy and authentication that are required. Application Associations can be pre-established, and
the security for pre-established associations permits a high level of security, while saving data.
Authentication, encryption and signature can be achieved by use of keys and certificates shared
between the meter and the client.
DLMS/COSEM also supports the concept of pre-established Application Associations, where the AA is
established before the device is installed. Pre-established AAs reduce communications use, and rely on
the use of high level security within each message to ensure secure communications.
4.3.5 Transport Layer Security
Lower layer security can be applied in addition to the upper layer security discussed above. The types
of lower layer security that can be used depend on the lower layers being employed, and therefore
these are discussed further within the relevant subclauses of Clause 7, Data Exchange. ISO 7498-2
recommends that encryption is performed end-to-end and not at the Data Link Layer.
In the IP context, there are a few effective tools for protecting messages in the Transport Layer. If TCP is
in use, then TLS is recommended but has significant overhead. If UDP is in use, then DTLS provides
reasonable protection with lower overhead.
5 Network Architecture
5.1 M/441 Mandate
Key
1 items required by MID 7 meter communication functions
2 metrology 8 HA communication functions
3 display 9 Local Network Access Point (LNAP)
4 additional functions 10 Neighbourhood Network Access Point (NNAP)
5 simple external consumer display 11 AMI Head End System
6 home automation functions
Figure 2 — Network Architecture — The architecture diagram in CEN/CLC/ETSI TR 50572
This document (in whole or part) is referred to in CEN/CLC/ETSI TR 50572 as a relevant standard for
the interfaces noted as M, C, G1, and G2 in Figure 2.
The actual network architecture is dependent on the operating environment, meter functionality and
the connection method used. It varies between basic readout networks to full Local Area Networks. The
latter has turned applicable due to the low cost and high performance of such network components.
It is generally assumed that the communications interface is an integral part of the meter within this
document, but this could not be the case in the physical world. The communications interface may
therefore be an add-on device to the meter.
EN 13757-1:2
...