En 13757 7 2018 04 [PDF]

Zitiervorschau

EN 13757-7

EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM

April 2018

ICS 33.200; 35.100.10; 35.100.20

Supersedes EN 13757-3:2013

English Version

Communication systems for meters - Part 7: Transport and security services Systèmes de communication pour compteurs - Partie 7 : Services de transport et de sécurité

Kommunikationssysteme für Zähler - Teil 7: Transport- und Sicherheitsdienste

This European Standard was approved by CEN on 8 February 2018. 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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, 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 © 2018 CEN

All rights of exploitation in any form and by any means reserved worldwide for CEN national Members.

Ref. No. EN 13757-7:2018 E

EN 13757-7:2018 (E)

Contents

Page

European foreword....................................................................................................................................................... 5 Introduction .................................................................................................................................................................... 7 1

Scope .................................................................................................................................................................... 9

2

Normative references .................................................................................................................................... 9

3

Terms and definitions ................................................................................................................................ 10

4 4.1 4.2

Abbreviations and symbols ...................................................................................................................... 12 Abbreviations ................................................................................................................................................ 12 Symbols ............................................................................................................................................................ 14

5 5.1 5.2

Layer model.................................................................................................................................................... 14 M-Bus Layers.................................................................................................................................................. 14 The CI-field principle .................................................................................................................................. 15

6 6.1 6.2 6.3 6.3.1 6.3.2 6.3.3 6.3.4 6.3.5 6.3.6 6.3.7

Authentication and Fragmentation Sublayer (AFL) ........................................................................ 19 Introduction ................................................................................................................................................... 19 Overview of the AFL-Structure ................................................................................................................ 20 Components of the AFL............................................................................................................................... 21 AFL Length Field (AFL.AFLL) .................................................................................................................... 21 AFL Fragmentation Control Field (AFL.FCL)....................................................................................... 21 AFL Message Control Field (AFL.MCL) .................................................................................................. 22 AFL Key Information-Field (AFL.KI) ...................................................................................................... 23 AFL Message counter field (AFL.MCR) .................................................................................................. 23 AFL MAC-field (AFL.MAC) .......................................................................................................................... 24 AFL Message Length Field (AFL.ML) ...................................................................................................... 24

7 7.1 7.2 7.3 7.4 7.5 7.5.1 7.5.2 7.5.3 7.5.4 7.5.5 7.5.6 7.5.7 7.5.8 7.6 7.6.1 7.6.2 7.6.3 7.6.4 7.6.5

Transport Layer (TPL) ............................................................................................................................... 24 Introduction ................................................................................................................................................... 24 Structure of none TPL header.................................................................................................................. 25 Structure of short TPL header ................................................................................................................. 25 Structure of long TPL header ................................................................................................................... 25 CI-field dependent elements .................................................................................................................... 25 Identification number ................................................................................................................................ 25 Manufacturer identification ..................................................................................................................... 26 Version identification ................................................................................................................................. 26 Device type identification ......................................................................................................................... 26 Access number .............................................................................................................................................. 28 Status byte in meter messages ................................................................................................................ 30 Status byte in partner messages ............................................................................................................. 31 Configuration field ....................................................................................................................................... 32 Configuration field dependent structure............................................................................................. 33 General ............................................................................................................................................................. 33 Configuration field extension .................................................................................................................. 34 Optional TPL-header fields ....................................................................................................................... 34 Optional TPL Trailer fields ....................................................................................................................... 34 Partial encryption ........................................................................................................................................ 34

2

EN 13757-7:2018 (E)

7.7 7.7.1 7.7.2 7.7.3 7.7.4 7.7.5 7.7.6 7.7.7 7.7.8

Security mode specific TPL-fields ........................................................................................................... 34 Shared subfields of configuration field and configuration field extension ............................. 34 Configuration field of Security mode 0 ................................................................................................. 37 Configuration field of Security modes 2 and 3 ................................................................................... 38 Configuration field of Security mode 5 ................................................................................................. 39 Configuration field of Security mode 7 ................................................................................................. 40 Configuration field of Security mode 8 ................................................................................................. 41 Configuration field of Security mode 9 ................................................................................................. 44 Configuration field of Security mode 10 ............................................................................................... 46

8 8.1 8.2 8.3 8.4 8.5 8.6 8.6.1 8.6.2 8.6.3

Management of lower layers .................................................................................................................... 48 General ............................................................................................................................................................. 48 Switching baud rate for M-Bus Link Layer according to EN 13757-2 ........................................ 48 Address structure if used together with the wireless Data Link Layer according to EN 13757-4 ...................................................................................................................................................... 48 Selection and secondary addressing ..................................................................................................... 48 Generalized selection procedure ............................................................................................................ 49 Searching for installed slaves................................................................................................................... 50 Primary addresses ....................................................................................................................................... 50 Secondary addresses ................................................................................................................................... 50 Wildcard searching procedure ................................................................................................................ 50

9 9.1 9.2 9.2.1 9.2.2 9.2.3 9.2.4 9.2.5 9.3 9.3.1 9.3.2 9.3.3 9.4 9.4.1 9.4.2 9.4.3 9.4.4 9.4.5 9.4.6 9.4.7 9.4.8 9.5 9.6 9.6.1 9.6.2 9.7

Security Services ........................................................................................................................................... 51 General ............................................................................................................................................................. 51 Message counter............................................................................................................................................ 52 Overview .......................................................................................................................................................... 52 Message counter CM transmitted by the meter .................................................................................. 52 Message counter CCP transmitted by the communication partner.............................................. 53 Message counter C’CP received by the meter ....................................................................................... 53 Message counter C’M and C”M received by the communication partner .................................... 53 Authentication methods in the AFL........................................................................................................ 54 Overview .......................................................................................................................................................... 54 Authentication method AES-CMAC-128 ................................................................................................ 54 Authentication method AES-GMAC-128 ............................................................................................... 54 Encryption and Authentication methods in the TPL ........................................................................ 55 Overview about TPL-Security mechanisms......................................................................................... 55 Manufacturer specific Security mechanism (Security mode 1) ................................................... 57 Security mechanism DES-CBC (Security mode 2 and 3).................................................................. 57 Security mechanism AES-CBC-128 (Security mode 5)..................................................................... 58 Security mechanism AES-CBC-128 (Security mode 7)..................................................................... 59 Security mechanism AES-CTR-128 (Security mode 8) .................................................................... 59 Security mechanism AES-GCM-128 (Security mode 9) ................................................................... 61 Security mechanism AES-CCM-128 (Security mode 10) ................................................................. 64 Reaction to security failure ....................................................................................................................... 66 Key derivation................................................................................................................................................ 67 General ............................................................................................................................................................. 67 Key derivation function A .......................................................................................................................... 67 Key Exchange.................................................................................................................................................. 68

Annex A (normative) Security Information Transfer Protocol ................................................................. 69 A.1

Introduction.................................................................................................................................................... 69

A.2

SITP Services .................................................................................................................................................. 69

A.2.1 Transfer security information ................................................................................................................. 69

3

EN 13757-7:2018 (E)

A.2.2 Activate security information .................................................................................................................. 70 A.2.3 Deactivate security information ............................................................................................................. 70 A.2.4 Destroy security information .................................................................................................................. 70 A.2.5 Combined activation/deactivation of security information......................................................... 70 A.2.6 Generate security information ................................................................................................................ 70 A.2.7 Get security information ........................................................................................................................... 70 A.2.8 Get list of all key information .................................................................................................................. 70 A.2.9 Get list of active key information ........................................................................................................... 70 A.2.10 Transfer end to end secured application data................................................................................... 70 A.3

CI-Fields ........................................................................................................................................................... 71

A.4

SITP structure................................................................................................................................................ 71

A.5

Block Control Field ...................................................................................................................................... 71

A.6

Block parameters ......................................................................................................................................... 72

A.7

Overview about Data Structures / Mechanisms................................................................................ 73

A.8

Data structures for Security Information ............................................................................................ 74

A.8.1 General ............................................................................................................................................................. 74 A.8.2 Data Structure 00h....................................................................................................................................... 75 A.8.3 Data Structure 01h....................................................................................................................................... 75 A.8.4 Data Structure 02h....................................................................................................................................... 75 A.8.5 Data Structure 03h ....................................................................................................................................... 76 A.8.6 Data Structure 20h ....................................................................................................................................... 77 A.8.7 Data Structure 21h ....................................................................................................................................... 77 A.8.8 Data Structure 22h ....................................................................................................................................... 78 A.9

Data structures for secured application data .................................................................................... 79

A.9.1 General ............................................................................................................................................................. 79 A.9.2 Data Structure 30h — AES Key-Wrap .................................................................................................... 80 A.9.3 Data Structure 31h — HMAC-SHA256.................................................................................................... 81 A.9.4 Data Structure 32h and 33h — CMAC ..................................................................................................... 82 A.9.5 Data Structure 34h — AES-GCM ............................................................................................................... 82 A.9.6 Data Structure 35h — AES-GMAC ............................................................................................................ 84 A.9.7 Data Structure 36h and 37h — AES-CCM ............................................................................................... 85 Annex B (informative) Message counter example......................................................................................... 87 Bibliography ................................................................................................................................................................. 91

4

EN 13757-7:2018 (E)

European foreword This document (EN 13757-7:2018) 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 October 2018, and conflicting national standards shall be withdrawn at the latest by October 2018.

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 EN 13757-3:2013.

together

with

EN 13757-3:2018

and

CEN/TR 17167:2018

supersedes

This document has been prepared under a mandate given to CEN by the European Commission and the European Free Trade Association.

The following significant technical changes have been incorporated in the new edition of this European Standard:

— new security modes (formerly “encryption mode”) 7, 8, 9 and 10 supporting encrypted and authenticated messages have been added; — support of Key Derivation Function for the generation of ephemeral keys;

— new Authentication and Fragmentation Layer has been introduced. EN 13757 is currently composed with the following parts:

— Communication systems for meters — Part 1: Data exchange;

— Communication systems for meters — Part 2: Wired M-Bus communication; — Communication systems for meters — Part 3: Application protocols;

— Communication systems for meters and remote reading of meters — Part 4: Wireless meter readout (Radio meter reading for operation in SRD bands);

— Communication systems for meters — Part 5: Wireless M-Bus relaying;

— Communication systems for meters — Part 6: Local Bus;

— Communication systems for meters — Part 7: Transport and security services;

— CEN/TR 17167:2018, Communication systems for meters — Accompanying TR to EN 13757-2, −3 and −7, Examples and supplementary information. This document falls under the Mandate EU M/441 “Standardisation mandate to CEN, CENELEC and ETSI in the field of measuring instruments for the development of an open architecture for utility meters involving communication protocols enabling interoperability” by providing the relevant definitions and

5

EN 13757-7:2018 (E)

methods for meter data transmission on application layer level. The M/441 Mandate is driving significant development of standards in smart metering. This document is in accordance with CEN/CLC/ETSI/TR 50572 [4].

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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.

6

EN 13757-7:2018 (E)

Introduction This European Standard belongs to the EN 13757 series, which covers communication systems for meters. EN 13757-1 contains generic descriptions and a communication protocol. EN 13757-2 contains a physical and a Link Layer for twisted pair based Meter-Bus (M-Bus). EN 13757-3 contains detailed description of the application protocols especially the M-Bus Protocol. EN 13757-4 describes wireless communication (often called wireless M-Bus or wM-Bus). EN 13757-5 describes the wireless network used for repeating, relaying and routing for the different modes of EN 13757-4. EN 13757-6 describes a twisted pair local bus for short distance (Lo-Bus). EN 13757-7 describes transport mechanism and security methods for data. The Technical Report CEN/TR 17167 contains informative annexes from EN 13757-2, EN 13757-3 and EN 13757-7.

These upper M-Bus protocol layers can be used with various Physical Layers and with Data Link Layers and Network Layers, which support the transmission of variable length binary transparent messages. Frequently, the Physical and Link Layers of EN 13757-2 (twisted pair) and EN 13757-4 (wireless) as well as EN 13757-5 (wireless with routing function) or the alternatives described in EN 13757-1 are used. These upper M-Bus protocol layers have been optimized for minimum battery consumption of meters, especially for the case of wireless communication, to ensure long battery lifetimes of the meters. Secondly, it is optimized for minimum message length to minimize the wireless channel occupancy and hence the collision rate. Thirdly, it is optimized for minimum requirements towards the meter processor regarding requirements of RAM size, code length and computational power. An overview of communication systems for meters is given in EN 13757-1, which also contains further definitions.

This standard concentrates on the meter communication. The meter communicates with one (or occasionally several) fixed or mobile communication partners which again might be part of a private or public network. These further communication systems might use the same or other application layer protocols, security, privacy, authentication, and management methods.

To facilitate common communication systems for CEN-meters (e.g. gas, water, thermal energy and heat cost allocators) and for electricity meters, in this standard occasionally electricity meters are mentioned. All these references are for information only and are not standard requirements. The definition of communication standards for electricity meters (possibly by a reference to CEN standards) remains solely in the responsibility of CENELEC. NOTE 1 CEN/TR 17167:2018, Annex C specifies how parts of this standard and of EN 13757–2 and EN 13757– 4 can be used to implement smart meter functionalities. Similar functionalities could also be implemented using other Physical and Link Layers.

NOTE 2 For information on installation procedures and their integration in meter management systems, see CEN/TR 17167:2018, Annex D.

The operator of a smart metering network needs to secure the network to ensure the data protection and data privacy of the consumer (see EC-Recommendation C1342 (2012)). Securing a system requires a security policy, which should address in general all constraints on functions, information flow between functions, access by external systems and threats, including software and access to data by third persons from an organizational viewpoint.

The security policy is under the responsibility of organizations according to their business processes. The major elements of a security policy, in combination with rules, will determine the overall security that is achieved. The security policy defines goals and elements of the system to be supported by organizational policy and technical implementations of security services. Establishing and executing security policies are outside the scope of this standard; however the standard provides security services supporting those policies when implemented.

7

EN 13757-7:2018 (E)

A security concept refers mainly to an architectural model, which represents data flows between rolebased data processing functions. Requirements for the security concept result from the overall security objectives in combination with the derived security services and best practice. This standard provides a set of security services allowing the design of a secure system, which is likely to resist attacks within the lifetime of the meter.

The limitation to symmetrical cipher methods for data transmission allow energy and memory efficient solutions. This is advantageous for long-term battery operated meters. It enables as well integration of unidirectional meter communication. Services like key derivation and key distribution solves the conflict between short key lifetime and long lifetime of a meter.

8

EN 13757-7:2018 (E)

1 Scope This European Standard specifies Transport and Security Services for communication systems for meters.

This European Standard specifies secure communication capabilities by design and supports the building of a secure system architecture. This European standard is applicable to the protection of consumer data to ensure privacy.

This draft European Standard is intended to be used with the lower layer specifications determined in EN 13757-2, EN 13757-3, EN 13757-4, EN 13757-5 and EN 13757-6.

2 Normative references

The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. EN 13757-1, Communication systems for meters - Part 1: Data exchange

EN 13757-2, 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:2013, Communication systems for meters and remote reading of meters - Part 4: Wireless meter readout (Radio meter reading for operation in SRD bands) EN 13757-5, Communication systems for meters - Part 5: Wireless M-Bus relaying

EN 62056-5-3:2014, Electricity metering data exchange - The DLMS/COSEM suite - Part 5-3: DLMS/COSEM application layer

EN 62056-21, Electricity metering - Data exchange for meter reading, tariff and load control - Part 21: Direct local data exchange ISO/IEC 18033-3, Information technology — Security techniques — Encryption algorithms — Part 3: Block ciphers

NIST/SP 800-38A:2001-12, Recommendation for Block Cipher Modes of Operation: Methods and Techniques

NIST/SP 800-38B:2005-05, Recommendation for Block Cipher Modes of Operation: CMAC Mode for Authentication

NIST/SP 800-38C:2004-05, Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality NIST/SP 800-38D:2007-11, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC

NIST/SP 800-38F:2012-12, Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping

9

EN 13757-7:2018 (E)

3 Terms and definitions For the purposes of this document, the following terms and definitions apply.

3.1 application data data used and/or generated by the metering process such as register values, tariffs, conversion factors or data used to control the metering process respectively the output or additional information 3.2 application protocol protocol for the coding of application data Note 1 to entry:

Application protocols are specified in EN 13757–3.

3.3 authenticity property that data originated from its purported source

[SOURCE: NIST/SP 800-38F:2012-12, NIST/SP 800-38C:2004-05]

3.4 byte octet of bits

3.5 confidentiality property that information is not made available or disclosed to unauthorized individuals, entities, or processes [SOURCE: ISO 7498-2:1989]

3.6 integrity data integrity property that data has not been altered or destroyed in an unauthorized manner [SOURCE: ISO 7498-2:1989]

3.7 datagram unit of data transferred from source to destination Note 1 to entry:

In previous versions of prEN 13757–3 datagram was called telegram.

3.8 ephemeral key key used to encrypt or decrypt a single message or for a limited time or a limited amount of data 3.9 fragment datagram of a fragmented message

10

EN 13757-7:2018 (E)

3.10 hex-ASCII base-16 numbers encoded as ASCII characters (‘0’−‘9’, ‘A’−‘F’) [SOURCE: ANSI X9 TR-31:2010]

3.11 initialization vector number used as starting point for the encryption of data sequences in order to increase the security by introducing additional cryptographic variance and to synchronize cryptographic equipment

3.12 key counter unique counter used in the Security Information Transfer Protocol to identify a secured end to end transferred command and response

3.13 key derivation technique by which a (potentially large) number of keys are generated (“derived”) from a single initial key and non-secret variable data with each resulting key using a non-reversible process 3.14 message functional set of data transferred from source to destination

Note 1 to entry:

A message may consist of one or more datagrams.

3.15 message counter unique counter used in AFL or TPL to identify a secured message 3.16 persistent key cryptographic key which,needs to be kept a prolonged period 3.17 security mechanism mode of operation of a (symmetric) cryptographic algorithm Note 1 to entry:

The Security mechanism is identified by the Security mode.

3.18 security mode mode number in configuration field identifying a set of applied security mechanisms 3.19 security service authenticity, confidentiality and data integrity Note 1 to entry:

Security services are provided by security mechanisms.

11

EN 13757-7:2018 (E)

3.20 sublayer subdivision of a layer

[SOURCE: EN ISO/IEC 7498-1:1995]

3.21 TPL-padding fill bytes added in TPL to fill up application data to the requested size for a block cipher

3.22 wrapper key (symmetric) key that determines the wrapping and unwrapping functions of a wrapping mechanism

3.23 wrapping mechanism (symmetric) key authenticated encryption mechanism that is intended for the protection of cryptographic keys and other specialized data

4 Abbreviations and symbols 4.1 Abbreviations ACC-DMD

Access Demand

ACK

Acknowledge [EN 13757–2/EN 13757–4]

ACC-NR AES AFL

APDU APL

ASCII BCD BCF BID BL

CBC

CCM CF

CFE CI

CMAC

CNF-IR CTR

12

Access – No Reply

Advanced Encryption Standard

Authentication and Fragmentation Sublayer Application Protocol Data Unit Application Layer

American Standard Code for Information Interchange Binary Coded Decimal numbers

Block control field of SITP structure, coding the usage of command or response Block identification number of SITP structure Block length of SITP structure

Cipher Block Chaining; (AES mode of operation)

Counter mode encryption algorithm with CBC-MAC (AES mode of operation) Configuration Field

Configuration Field Extension Control Information field

Cipher-based MAC [NIST/SP 800–38B] Confirm Installation Request

Counter Mode encryption algorithm (AES mode of operation)

EN 13757-7:2018 (E)

DES

Data Encryption Standard

DLL

Data Link Layer

DIF

DLMS DSI

DSH

DSH1 DSH2 ELL

GCM

GMAC ICV IV

LSB

LSBit MAC MK

MLI

MSB

MSBit NWL OBIS PID

REQ-UD RSP-UD RSSI

SITP

SND-IR

SND-NKE SND-NR

SND-UD

SND-UD2

SND-UD3

Data Information Field

Device Language Message Specification

Data structure identifier, part of block parameter structure inside SITP Data structure header, part of block parameter structure inside SITP Byte one of DSH

Byte two of DSH

Extended Link Layer

Galois/Counter Mode, an algorithm for authenticated encryption with associated data (AES mode of operation) a specialization of GCM for generating a message authentication code (MAC) on data that is not encrypted Integrity check value, part of a wrapped data structure in SITP Initialization Vector

Least Significant Byte Least Significant Bit

Message Authentication Code

NOTE MAC is in other standards also used as an acronym for Media Access Control for data communication at the Physical Layer. Message Key (persistent)

Message Length Indicator, part of a wrapped data structure in SITP Most Significant Byte Most Significant Bit Network Layer

Object Identification System (EN 62056–61)

Protocol identifier field, part of wrapped data structure in SITP Request User Data (class 1 or 2) [EN 13757–2/EN 13757–4] Respond User Data [EN 13757–2/EN 13757–4] Received Signal Strength Indicator

Security Information Transfer Protocol

Send Installation Request [EN 13757–4]

Send Link Reset [EN 13757–2/EN 13757–4] Send – No Reply [EN 13757–4]

Send User Data [EN 13757–2/EN 13757–4]

Send User Data 2 [EN 13757–2/EN 13757–4] Send User Data 3 [EN 13757–4]

13

EN 13757-7:2018 (E)

TPDU

Transport Protocol Data Unit

VIF

Value Information Field

TPL

VIFE

4.2 Symbols

Transport Layer

Value Information Field Extensions

Hexadecimal numbers are designated by a following “h”. Binary numbers are designated by a following “b”. Decimal numbers have no suffix.

The concatenation of fields is indicated by the symbol “||”. E. g. 12h || 34h results in 1234h.

5 Layer model 5.1 M-Bus Layers

The M-Bus covers several communication layers. The Physical Layer and the Data Link Layer are mandatory for all type of communications. The structure of these two layers depends on the communication media (wired M-Bus (EN 13757-2) and Local Bus (EN 13757-6) or wireless M-Bus (EN 13757-4 and EN 13757-5)).

The presence of the other layers depends on:

— communication media (wired/wireless M-Bus, Radio mode), — message type (e.g. REQ-UD2 or RSP-UD),

— message length (fragmentation required), — selected type of Security mode.

Table 1 shows the applicable layers, their order and the related part of this standard series in which they are described. The upper protocol layers AFL, TPL and APL are specified in this standard.

14

EN 13757-7:2018 (E)

Table 1 — Order of M-Bus Layer Abbreviation APL

Application Layer

AFL

Authentication Fragmentation Sublayer

TPL

Transport Layer

NWL ELL

DLL

PHY a

b

Declared by CI-field

Layer

Network Layer

a and

Extended Link Layer Data Link Layer Physical Layer

yes yes yes yes no no

Related part of this standard series

Colour codesb

EN 13757–1/ EN 13757–3/EN 13757

Orange

EN 13757–7

Purple

EN 13757–7/EN 13757

EN 13757–5 EN 13757–4

EN 13757–2/EN 13757/ EN 13757–5 EN 13757–2/EN 13757/ EN 13757–5/EN 13757

Green

Pink

Blue

Light blue

Light yellow

The APL is not introduced by a dedicated-CI-field, but declared by CI-field of the TPL.

OSI model Layer Application Presentation Session Transport Network

Data Link Physical

These colour codes are applied in examples given in CEN/TR 17167.

NOTE The relation between the M-Bus Layers and the OSI Layers is not a one-to-one relation. The OSI Data Link Layer is provided by two M-Bus Layers (DLL and ELL). The functionality of the OSI Layers 4 and 5 are represented by the M-Bus Layers AFL and TPL. The functionality of the OSI Layers 6 and 7 are represented by the M-Bus Layers APL.

5.2 The CI-field principle

All layers between the DLL and the APL are introduced by a CI-field (control information field). These CI-fields declares the structure of the following layers.

The layers ELL and NWL do not provide a dedicated length information. Therefore the structure of these layers has to be derived from the CI-field. Refer to EN 13757-4 or EN 13757-5 for specification of the length of the corresponding layers and the start position of the next layer. The AFL has a variable structure. It declares the length of this layer by a dedicated length field.

The Transport Layer and the Application Layer uses a shared CI-field. For that reason, a Transport Layer shall be present whenever the Application Layer is used in a message. The shortest Transport Layer (no header) consists of this CI-field only. The CI-field of the Transport Layer declares the used application protocol (like M-Bus Data, DLMS-Data or Alarm protocol), the origin of message (Command of Master or Slave-Response) and the fixed header structure of the TPL header. Behind this CI-field, no other CI-field follows. The length of the APL is given by the message length reduced by the length of the other existing layers.

15

EN 13757-7:2018 (E)

Table 2 — CI-field codes used by the master or the slave CI-field

Direction

Layer

Higher layer protocol

00h to 1Fh

Reserved for applications

APL

None

DLMS (see EN 13757–1)

50h

Application reset or select to APL device

None

Application Selection; according to EN 13757–3:2018, Clause 7

Selection of device

None

Management, see 8.4

20h to 4Fh 51h 52h 53h 54h 55h

56h to 59h 5Ah 5Bh 5Ch

Reserved

DLMS-based

TPLHeader

Command to (full M-Bus frame)

device

APL

Application reset or select to APL device Request of selected APL application to device Request of selected APL application to device Reserved

Command to (full M-Bus frame) Command to (full M-Bus frame)

Synchronize action

5Dh to 5Eh Reserved

device device

None Long

None Long

M-Bus (not for wireless); according to EN 13757–3:2018, Clause 6 Application Selection; according to EN 13757–3:2018, Clause 7 Application Selection; according to EN 13757–3:2018, Clause 7 Application Selection; according to EN 13757–3:2018, Clause 7

APL

Short

M-Bus; according to EN 13757–3:2018, Clause 6

APL

None

according to EN 13757–3:2018, Clause 12

APL

Long

M-Bus; according to EN 13757–3:2018, Clause 6

5Fh

Specific usageb

TPL

Long

NOTE

61h

Command to device

APL

Short

DLMS/COSEM with OBIS-Identifier (according to EN 13757–1 and EN 62056– 5-3)a

64h

Command to device

APL

Long

Reserved for OBIS-type value descriptorsa

Response of selected APL application from device

None

Application Selection; according to EN 13757–3:2018, Clause 7

60h

62h to 63h 65h 66h 67h 68h

16

Command to device

Reserved

Command to device

APL

APL

Response of selected APL application from device Response of selected APL application from device

Long

Short Short Long

See Bibliographical Entry [8].

DLMS/COSEM with OBIS-Identifier (according to EN 13757–1 and EN 62056– 5-3)a

Reserved for OBIS-type value descriptorsa

Application Selection; according to EN 13757–3:2018, Clause 7 Application Selection; according to EN 13757–3:2018, Clause 7

EN 13757-7:2018 (E)

CI-field

Direction

Layer

TPLHeader

Higher layer protocol

69h

Response from device (M-BusAPL Format frame)

None

M-Bus; according to EN 13757–3:2018, 6, Annex G

6Bh

Response from device (M-BusAPL Format frame)

Long

M-Bus; according to EN 13757–3:2018, Annex G

6Ah 6Ch

6Dh 6Eh 6Fh

70h 71h 72h 73h 74h 75h

76h to 77h 78h 79h

7Ah 7Bh 7Ch

Response from device (M-BusAPL Format frame) Time sync to device

APL

Application error from device

APL

Time sync to device

Application error from device

Application error from device Alarm from device

Response from (full M-Bus frame)

device

APL APL APL APL APL

Response from device (M-BusAPL Compact frame) Alarm from device

APL

Alarm from device Reserved

APL

Response from (full M-Bus frame)

device

Response from (full M-Bus frame)

device

Short Long Long

Short Long

None None Long Long

Short Long

According to EN 13757–3:2018, Clause 10 According to EN 13757–3:2018, Clause 9

M-Bus; according to EN 13757–3:2018, Clause 6 M-Bus; according to EN 13757–3:2018, Clause 6, Annex G According to EN 13757–3:2018, Clause 9 According to EN 13757–3:2018, Clause 9

Short

M-Bus; according to EN 13757–3:2018, Clause 6

Response from device (M-BusAPL Compact frame)

Short

7Dh

Response from device

APL

Short

7Fh

Response from device

APL

Short

APL

Transport Layer to device TPL (without APL) Network Layer data

According to EN 13757–3:2018, Clause 10

APL

None

Long

81h

According to EN 13757–3:2018, Clause 10

M-Bus; according to EN 13757–3:2018, Clause 6

APL

80h

According to EN 13757–3:2018, Clause 8

None

Response from device (M-BusAPL Compact frame)

Response from device

According to EN 13757–3:2018, Clause 8

APL

Response from device

7Eh

M-Bus; according to EN 13757–3:2018, Annex G

NWL

Long Long

M-Bus; according to EN 13757–3:2018, Clause 6, Annex G M-Bus; according to EN 13757–3:2018, Annex G and EN 13757–3:2018, Clause 6

DLMS/COSEM with OBIS-Identifier (according to EN 13757–1 and EN 62056– 5-3)a DLMS/COSEM with OBIS-Identifier (according to EN 13757–1 and EN 62056– 5-3) a Reserved for OBIS-type value descriptorsa Reserved for OBIS-type value descriptorsa According to EN 13757–4 According to EN 13757–5

17

EN 13757-7:2018 (E)

CI-field

Direction

Layer

TPLHeader

Higher layer protocol

82h

Network management data to APL device

Long

According to EN 13757–4 and EN 13757– 5

84h

Transport Layer to device (MTPL Bus-Compact frame expected)

Long

According to EN 13757–3:2018, Annex G

83h 85h 86h 87h 88h 89h

8Ah 8Bh

8Ch to 8Fh 90h 91h

92h to 97h 98h – 9Dh 9Eh 9Fh

Network management data to APL device Transport Layer to device (MTPL Bus-Format frame expected) Reserved for Extended Link ELL Layer

Long

Network management data APL from device

None

Network management data APL from device Transport Layer from device TPL (without APL) Transport Layer from device TPL (without APL) Extended Link Layer

Authentication Fragmentation Sublayer Reserved Reserved

Specific usageb Specific usageb

Set baud rate to 300 Bd

BAh

Set baud rate to 1 200 Bd

BCh

18

and

ELL

Short

Short Long

AFL

Set baud rate to 600 Bd

Set baud rate to 2 400 Bd Set baud rate to 4 800 Bd

According to EN 13757–4 and EN 13757– 5 According to EN 13757–3:2018, Annex G According to EN 13757–4

According to EN 13757–4, EN 13757–5 According to EN 13757–4, EN 13757–5 According to EN 13757–4, EN 13757–5 According to EN 13757–4 According to EN 13757–4 According to EN 13757–4 According to Clause 6

Reserved

B8h

BBh

Long

Network management data APL from device

A0h to B7h Manufacturer specific B9h

None

According to EN 13757–4, EN 13757–5 TPL TPL

APL

Short Long

APL

None

APL

None

APL

APL APL

None

None None

NOTE NOTE

See Bibliographical Entry [8]. See Bibliographical Entry [8].

According to EN 13757–3:2018, 13 Management of according to 8.2

lower

layers;

Management of according to 8.2

lower

layers;

Management of according to 8.2 Management of according to 8.2 Management of according to 8.2

lower

lower lower

layers;

layers; layers;

EN 13757-7:2018 (E)

CI-field

Direction

Layer

TPLHeader

Higher layer protocol

BDh

Set baud rate to 9 600 Bd

APL

None

Management of according to 8.2

lower

layers;

BFh

Set baud rate to 38 400 Bd

APL

None

Management of according to 8.2

lower

layers;

BEh C0h C1h C2h C3h C4h C5h

C6h to FFh

Set baud rate to 19 200 Bd

Command to device

Response from device Response from device Command to device

Response from device Response from device Reserved

APL

APL APL APL APL APL APL

None

Long

Short Long Long

Short Long

Management of according to 8.2

lower

layers;

Image transfer; according to EN 13757– 3:2018, Annex I, Image transfer; 3:2018, Annex I

according

EN 13757–

Image transfer; according to EN 13757– 3:2018, Annex I Security Information Transfer; according to Annex A Security Information Transfer; according to Annex A Security Information Transfer; according to Annex A

NOTE All SND-UD datagrams are acknowledged in the Data Link Layer, even if the function of these CI-fields is not implemented.

a These application protocols also contain OBIS identifiers. In the M-Bus application protocol, these OBIS identifiers are not included, but they can be added afterwards. For generating the OBIS identifiers from M-Bus data records, EN 13757–3:2018, Annex H shall be used. b Used for specific national implementations. See reference in bibliography for use of this CI-field at time of release of this standard.

6 Authentication and Fragmentation Sublayer (AFL) 6.1 Introduction

The AFL shall be considered as part of Transportation Layer. This clause explains the usage of the Authentication and Fragmentation Sublayer (AFL) in combination with the other layers and Security modes. The Authentication and Fragmentation Sublayer provides three essential services: — fragmentation of long messages in multiple datagrams;

— a Message Authentication Code (MAC) to prove the authenticity of the TPL and APL;

— a Message counter which supplies a security relevant message identification that may be used for the key derivation function (refer to 9.6.1). This optional layer shall be applied if at least one of these services is required.

19

EN 13757-7:2018 (E)

NOTE Message authentication codes (MAC) and Message counter can also be provided by Security mechanisms in Transport Layer.

Fragmentation is required to transport large messages, like Software update. The AFL is separated in a section for each single fragment and a section for the whole message. The position of the AFL in the MBus Layer Model is shown in Table 1.

In general, two alternative capabilities of message authenticity and integrity supported by MAC may be applied in AFL: — individual fragment authentication by a MAC (this encapsulates the authentication of the fragments as layer specific protocol data units),

— overall message authentication by a MAC (this combines fragment transport with the authentication of one application protocol data unit). The MAC service (see 9.3) protects all layers above the AFL during transmission. Therefore, no changes in higher layers are possible, as soon as the MAC has been calculated.

To ensure authentication of APDUs with other communication partners beyond media-dependant transportation, additional MAC service in Application Layer is applicable.

6.2 Overview of the AFL-Structure

A message consists of one or more fragments. Each fragment shall be transported in one Data Link Layer datagram. The shadowed fields of Table 3 are present in each fragment. The other fields are optional.

20

EN 13757-7:2018 (E)

Table 3 — Overview of all AFL Fields Size (bytes)

CI

Indicates that an Authentication and Fragmentation Sublayer follows.

2

FCL

Fragmentation Control field

1 2 4

Nb b

Description

1 1

a

Field Name

2

AFLL MCL KI

MCR

MAC ML

AFL-Length

Message Control fielda Key Information fielda

Message counter fielda

Message Authentication Codea Message Length fielda

This is an optional field. Their inclusion is defined by the Fragmentation Control Field specified in 6.3.2.

The length of MAC depends on AT-subfield in AFL.MCL.

All multi byte fields of AFL except the AFL.MAC shall be transmitted with least significant byte first (little endian).

6.3 Components of the AFL

6.3.1 AFL Length Field (AFL.AFLL) This field describes the number of all bytes within the AFL excluding the field AFL.AFLL itself. The field AFL.AFLL is not part of the MAC protected data. 6.3.2 AFL Fragmentation Control Field (AFL.FCL)

The Fragmentation Control Field indicates presence of the following fields in the current fragment. The field AFL.FCL (see Table 4) is not part of the MAC protected data.

21

EN 13757-7:2018 (E)

Table 4 — AFL Fragmentation Control Field – bit field definitions Bit

Description Reserved (0b by default)

15

RES

14

MF

More-Fragments 0b This is the last fragment

13

MCLP

Message Control in this Fragment Presenta

11

MCRP

12 10

9 8

a

Field Name

7 to 0

MLP

MACP KIP

RES FID

1b More fragments are following

Message Length in this Fragment Presenta

Message counter in this Fragment Presenta MAC in this Fragment Presenta

Key Information in this Fragment Presenta Reserved (0b by default) Fragment-ID

0 = field is not present; 1 = field is present

The Fragment ID is used for the identification of each single fragment of a long message. Set FID to 1 for the first fragment of a fragmented message. FID shall increment with each fragment. The FID shall never roll over. For unfragmented messages the FID shall be set to 0. 6.3.3 AFL Message Control Field (AFL.MCL)

The AFL Message Control Field indicates presence of the following fields in a fragment of the message (see Table 5). Table 5 — AFL Message Control Field - bit field definitions

Bit

Description

7

RES

Reserved (0b by default)

5

MCMP

Message counter in Message Presenta

6 4 3 2 1 a

Field Name

0

MLMP KIMP AT

Message Length in Message Presenta

Key Information in Message Presenta Authentication-Type (see Table 6)

0 = field is not present; 1 = field is present

The bits 4 to 7 in the AFL.MCL field define the presence of additional fields in the message. Table 6 describes the usage of the AT-subfield.

If the AFL.MCL field is used it always shall be present in the first fragment. It shall not be present in any following fragments of the same message.

22

EN 13757-7:2018 (E)

Table 6 — AT-subfield of AFL.MCL Value

Authentication Type

0

No authentication

3

AES-CMAC-128

2 bytes

5

AES-CMAC-128

8 bytes

1 to 2

Length of Authentication Code

Reserved

4

AES-CMAC-128

6 7

4 bytes

AES-CMAC-128

12 bytes

AES-GMAC-128

12 bytes

AES-CMAC-128

8

9 to 15

16 bytes

Reserved

The standard allows different levels of integrity strength e.g. by selection of Authentication tag length. The level shall be selected depending on type of application (e.g. transfer of consumption value, switch commands, software update, etc.). 6.3.4 AFL Key Information-Field (AFL.KI)

The Key Information field (see Table 7) enables the recipient of a message to identify the corresponding authentication key. Table 7 — AFL Key Information Field – bit field definitions

Bit

Field Name

15 to 8

Key Version

5 to 4

KDF-Selection

7 to 6 3 to 0

RES

Key ID

Description The Key Version identifies the applied key version, as specified in 7.7.1. Reserved (0b by default)

The KDF-Selection identifies the applied Key Derivation Function, as specified in Table 25. The Key ID identifies the applied key, as specified in Table 24.

In case of individual fragment authentication, the message key shall be applied for all fragments of the message. If the KI is not present, values of the configuration field in the TPL shall be used for the key selection. 6.3.5 AFL Message counter field (AFL.MCR)

Table 8 — AFL Message counter field - bit field definitions Bits

Field Name

31 to 0

C

Description AFL Message counter of this message. See 9.2 for details.

The presence of the filed AFL.MCR depends on the selected Security mode. See 9.4 for details.

If the Message counter Field is used, the AFL.MCR field shall always be present in the first fragment. It shall not be present in any following fragments of the same message. If the AFL.MCR is not present, values of the Message counter field in the TPL shall be used for the AFL.MCR.

23

EN 13757-7:2018 (E)

6.3.6 AFL MAC-field (AFL.MAC) The length of the MAC field depends on the selected option in sub field AT indicated by the AFL.MCL field. If the MAC-field is used, the AFL.MAC field shall be present in case of — individual fragment authentication: in each fragment;

— message authentication: only in the last fragment of a message.

In deviation to the usual transmission order for multi byte fields on the M-Bus, the MSB of the MAC shall be transmitted as first byte, the LSB as last. For details of using MAC, see 9.3. 6.3.7 AFL Message Length Field (AFL.ML)

The field AFL.ML (see Table 9) declares the number of bytes following AFL.ML until the end of the unfragmented message (excluding Link Layer fields like CRC or checksum). The message length shall be calculated before the message is separated in several fragments. Table 9 — AFL Message Length Field - bit field definitions

Bits

Field Name

Description

15 to 0

ML

The message length allows a maximum length of 64 kBytes. The message length contains the sum of all fragments (starting from TPL) for one message. It does not include any DLL, ELL or AFL Fields.

NOTE 1 NOTE 2

The message length is also limited by the maximum numbers of Fragment ID's (255).

Not all receivers are able to receive such long messages because of the limited message buffer size.

The AFL.ML Message Length Field shall only be present in the first fragment of a fragmented message to indicate the total message length. For unfragmented messages, the field AFL.ML can be disabled.

7 Transport Layer (TPL) 7.1 Introduction

Table 10 shows a general TPL-Structure of a message with an embedded APL. Table 2 (see 5.2) shows the respective CI-fields, which introduce the TPL with one of the possible TPL-Header (marked with None, Short or Long). Table 10 — General structure of TPL

CI-Field

TPL Header

APL data

TPL Trailer (optional)

1 byte

None header Short header Long header

Variable number

Variable number

When using a long TPL header, the meter application address is contained in this header. This meter application address may be different to the manufacturer assigned unique Link Layer Address. This allows, for example, a wired to wireless converter to supply the supported meter application address in the long data header and its own address in the radio Data Link Layer. For a simple meter, which does not need an additional converter, the short TPL header is sufficient.

24

EN 13757-7:2018 (E)

If nothing other declared then multi byte fields of TPL shall be transmitted with least significant byte first (little endian).

7.2 Structure of none TPL header

This structure has no TPL header. The first byte following the CI-field is the start of the application data. This data structure does not support transmission properties like encryption, access number or an additional meter address. This structure can be used together with the Extended Link Layer of EN 13757-4.

7.3 Structure of short TPL header

The first 4 bytes after the CI-field are always present. After the configuration field may be a configuration field extension depending on selected Security mode in the configuration field. Thereafter follows optional fields of TPL header, which depend on the Security mode, chosen in the configuration field (refer to Table 19 in 7.5.8) or from control bits of the configuration field respectively the configuration field extension (see Table 11). For details, see 7.6. Table 11 — Short TPL header

CI-dependent fields

CF-dependent fields

Access No.

Status

Configuration Field (CF)

Configuration Field Extension (CFE)

Optional TPL-Header Fields

1 byte

1 byte

2 bytes

0 to n bytes

0 to n bytes

The short TPL header is used for systems supporting the Physical and Link Layer of wireless M-bus communication (refer to EN 13757-4). In this standard, the Link Layer Address contains the information fields of the manufacturer, the identification number, the version and the device type. If the meter address is identical with Link Layer Address or the meter address is selected by secondary address (see 8.4), then the 8 bytes of the meter address may be omitted from the Transport Layer.

7.4 Structure of long TPL header

The first 12 bytes after the CI-field are always present. After the configuration field may be a configuration field extension depending on selected Security mode in the configuration field. Thereafter follows optional fields of TPL header, which depend on the Security mode chosen in the configuration field (refer to Table 19 in 7.5.8) or from control bits of the configuration field respectively the configuration field extension (see Table 12). For details, see 7.6. Table 12 — Long TPL header

CI-depended fields Ident. No. 4 bytes

ManuVersion facturer 2 bytes

1 byte

CF-depended fields

Device type

Access No.

Status

Configuration Field (CF)

Configuration Field Extension (CFE)

Opt. TPLHeader Fields

1 byte

1 byte

1 byte

2 bytes

0 to n bytes

0 to n bytes

The address fields of the long TPL header always contain the address of the meter regardless of the transmission direction. In case of wireless communication based on EN 13757-4, the long TPL header shall be used when the Link Layer Address differs from meter address.

7.5 CI-field dependent elements 7.5.1 Identification number

The identification number is either a fixed fabrication number or a number changeable by the customer, coded with 8 BCD packed digits (4 bytes), and which thus runs from 00000001 to 99999999. It can be

25

EN 13757-7:2018 (E)

preset at fabrication time with a unique number, but can be changeable afterwards, especially if, in addition, a unique and not changeable fabrication number (see also 8.5) is provided.

An Fh at any position of Identification number shall be interpreted as wildcard. A wildcard can replace any digit with value from 0 to 9. An Identification number of e.g. 112233FF addresses all meters with Identification numbers from 11223300 to 11223399. Wildcards are used by the communication partner to address a group of meters. A meter shall accept the address with wildcards if it matches to its own address. 7.5.2 Manufacturer identification

The field manufacturer is coded unsigned binary with 2 bytes. This manufacturer ID is calculated from the ASCII code of EN 62056-21 manufacturer ID (three uppercase letters) with the following formula: Man. ID =

+ +

[ASCII(1st letter)

− 64]

[ASCII(3rd letter)

− 64]

[ASCII(2nd letter)

− 64]

× ×

32 32

×

32

(1)

NOTE The flag association, UK (http://www.dlms.com/flag) administers these three letter manufacturers ID of EN 62056–21.

An FFh shall be interpreted as wildcard. A wildcard can replace any value from 00h to FEh. A Manufacturer Identification FFFFh addresses the meter independent of its own Manufacturer Identification. Wildcards are used by the communication partner to address a group of meters. A meter shall accept the address with wildcards if it matches to its own address. 7.5.3 Version identification

The field version specifies the generation or version of the device and depends on the manufacturer. It can be used to make sure that within each version number the identification number is unique.

The value FFh shall be interpreted as a wildcard. A wildcard can replace any value from 00h to FEh. Wildcards are used by the communication partner to address a group of meters. A meter shall accept the address with wildcards if it matches to its own address. 7.5.4 Device type identification

The device type is coded as given in Table 13.

26

EN 13757-7:2018 (E)

Table 13 — Device type identification Code bin. Bit 7 … 0

Code hex.

Other

0000 0000

00

Electricity meter

0000 0010

02

Device type (previously called medium)

Oil meter

Gas meter

Thermal energy meter – Heat (volume measured at return temperature: outlet) Steam meter

Warm water meter (30 °C … 90 °C)e Water metere

Heat cost allocator Compressed air

Thermal energy meter – Cooling (volume measured at return temperature: outlet) Thermal energy meter – Cooling (volume measured at flow temperature: inlet)

Thermal energy meter – Heat (volume measured at flow temperature: inlet)

Thermal energy meter – Combined heat/cooling Bus/system component Unknown device type

Irrigation water meterd Water data logger Gas data logger Gas converter

Calorific value

Hot water meter (≥90 °C)d Cold water metere

Dual register (hot/cold) water metera, e Pressure meter A/D converter

Smoke detector

Room sensor (e.g. temperature or humidity) Gas detector

Reserved for sensors

0000 0001 0000 0011 0000 0100 0000 0101 0000 0110 0000 0111 0000 1000 0000 1001

01 03 04 05 06 07 08 09

0000 1010

0A

0000 1100

0C

0000 1011

0B

0000 1101

OD

0000 1111

0F

0000 1110

0E

0001 0000

10

0001 0010

12

0001 0001 0001 0011 0001 0100 0001 0101 0001 0110 0001 0111 0001 1000 0001 1001

11 13 14 15 16 17 18 19

0001 1010

1A

0001 1100

1C

0001 1011 ..........

1B

1D to 1F

27

EN 13757-7:2018 (E)

Device type (previously called medium) Breaker (electricity) Valve (gas or water)

Reserved for switching devices

Code bin. Bit 7 … 0

Code hex.

0010 0000

20

..........

22 to 24

..........

26 to 27

0010 1001

29

0010 0001

Customer unit (display device)

0010 0101

Waste water meterd

0010 1000

Reserved for carbon dioxide

0010 1010

Reserved for customer units Garbage

Reserved for environmental meter

31

0011 0010 0011 0011

37

0011 1000

Wildcard

33

0011 0111

Bus converter (meter side)c Reserved

32 34 to 35

0011 0110

Reserved for system devices

30

..........

Radio converter (system side)b Radio converter (meter side)c

2A

0011 0001

Unidirectional repeater

Reserved for system devices

28

2B to 2F

0011 0000

Bidirectional repeater

25

..........

Service tool

Communication controller (Gateway)

21

.......... ..........

1111 1111

36 38

38 to 3F

40 to FE FF

a Such a meter registers water flow above a limit temperature in a separate register with an appropriate tariff ID. b A radio converter at system side works as radio master and bus slave. c A radio or bus converter at meter side operates as slave like a meter. d e

This Device type shall be used for non-potable water/industrial water.

This Device type shall be used for potable water.

An FFh shall be interpreted as wildcard. A wildcard can replace any value from 00h to FEh. Wildcards are used by the communication partner to address a group of meters. A meter shall accept the address with wildcards if it matches to its own address. 7.5.5 Access number

7.5.5.1 Overview The access number is a part of the TPL header. It is used by the Extended Link Layer, the Transport Layer or the Application Layer protocol. It is coded as a 1-byte unsigned binary number. It has originally been added to support the wired M-Bus of EN 13757-2 and signals to the user that its meter has been read out by the pull-type readout of EN 13757-2. This function supports the detection of unwanted frequent readouts. For the typical push type frequent transmit modes of radio devices based on the

28

EN 13757-7:2018 (E)

EN 13757-4, this usage is no longer sensible. Acceptable maximum readout or transmit frequency is either an issue of legal requirements or of a contract between the meter reading organization and the consumer. For devices based on the EN 13757-4, the access number shall be applied for clear indication of a new datagram for both pushed data as well as for requested data by strict rules of increments. For the partner-generated datagrams, relaxed generation rules simplify the implementation. The detection rules are identical between meter and partner; i.e. a datagram with an identical access number is considered a repetition of an identical previously already received datagram and shall be ignored. All datagrams with a different access number than the last received datagram are considered as a new data datagram. The term “new data” means that the meter application provides newer measurement values than in the last (old) data datagram.

This Link Layer oriented function is not sufficient for a unique message identification from an application. If an application requires such a unique identification of a message, a data record with a VIF of = FDh,08h (unique message identification) and a data length of at least 4 bytes may be added to each message.

If both Extended Link Layer and Transportation Layer exist, then the access number of the Extended Link Layer will be applied for the timing of synchronous transmission, whereas the access number in the Transport Layer will be used to indicate new data. 7.5.5.2 Generation of access number for meter initiated datagrams

If a meter generates a datagram (SND-NR, SND-IR, ACC-DMD or ACC-NR; see EN 13757-4:2013, 11.5.4), the access number is incremented (modulo 256) by one before or after each new transmission of the meter.

If the meter supports the feature of synchronized transmission for battery operated receiver (refer to EN 13757-4) then the access number shall be incremented by exactly one with every synchronous transmission. For every asynchronous transmission between two synchronous datagrams, the meter shall use the access number from the last synchronous transmission. To avoid the detection of zero consumption, it is recommended to add a time stamp or an incremental counter (VIFE “unique message identification”) to the message content if one or several asynchronous transmissions are sent in the interval between two synchronous transmissions. If such asynchronous transmission contains new data, the Extended Link Layer may be applied to separate the indication of synchronous transmission from the indication of new data. After the power up of the meter, its value of the access number shall be set by a randomized initial value from 0 to 255. The access number of the meter shall not be resettable.

When the datagram is a response to a datagram of the communication partner (i.e. ACK, RSP-UD or other) then the access number repeats the received access number of the communication partner. Otherwise, the access number of the meter is used. Meter initiated datagrams are not allowed by the wired M Bus standard (refer to EN 13757-2).

7.5.5.3 Generation of access number for partner generated datagrams

If the communication partner generates a wireless datagram (SND-UD, SND-NKE, REQ-UD1, REQ-UD2; see EN 13757-4:2013, 11.5.4), each such datagram shall use a different value of the access number within 300 s or within a frequent access cycle as defined in EN 13757-4. A simple increment is recommended to fulfil this requirement. If the partner transmits an answer to the meter (i.e. ACK or CNF-IR with CI-field), the transmitted access number of the partner repeats the received access number of the meter. After the power up of the communication partner, its value is undefined, but an initial value of zero is recommended. For the usage of the FCB, see CEN/TR 17167:2018, A.7.

For the wired communication according to EN 13757-2, the meter shall increment its own access number before or after each response (RSP-UD) to the communication partner. If the communication

29

EN 13757-7:2018 (E)

partner (M-Bus-master) transmits an access number (e.g. with a SND-UD), it may be ignored by the meter. NOTE

The communication partner provides an access number in case of encrypted commands.

7.5.6 Status byte in meter messages

Table 14 describes the usage of each bit in the Status byte.

Table 14 — Coding of the status field

Bit

Meaning with bit set

Significance with bit not set

7

Specific to manufacturer

Specific to manufacturer

5

Specific to manufacturer

Specific to manufacturer

6 4 3 2

1, 0

Specific to manufacturer

Specific to manufacturer

Temporary error

No temporary error

Permanent error

No permanent error

Power low

Power ok

See Table 15

See Table 15

Table 15 — Application errors coded with the status field Status bit 1 bit 0

Application status

00

No error

10

Any application error

01 11

The status bits shall be used in this meaning:

Application busy

Abnormal condition/alarm

Power low

Warning — The bit “power low” is set only to signal interruption of external power supply or the end of battery life.

Temporary error

Warning — The bit “temporary error” is set only if the meter signals a slight error condition (which not immediately requires a service action). This error condition may later disappear.

Permanent error

Any application error

Abnormal condition

Failure — The bit “permanent error” is set only if the meter signals a fatal device error (which requires a service action). Error can be reset only by a service action. Shall be used to communicate a failure during the interpretation or the execution of a received command, e.g. if a non-decipherable message was received.

The meter can provide details about the occurred application error in next meter response using the application error protocol (refer to EN 13757– 3:2018, Clause 10).

Shall be used if a correct working application detects an abnormal behaviour like a permanent flow of water by a water meter. More details about the error state of the meter can be provided in the M-Bus application protocol of the meter response (refer to EN 13757-3:2018, Annex E).

30

EN 13757-7:2018 (E)

7.5.7 Status byte in partner messages Information on signal levels at the communication partner may be returned to the meter in the status byte (see Table 16) in the partner message. This makes it possible to perform control of the RF transmission power from the meter during installation and operation. A feedback of the RSSI may be useful during the installation of the meter. Information about link quality is helpful for the rating of several radio links between a meter and different partners. It will also be used for signalling the link quality to an installation service tool. NOTE

For details see CEN/TR 17167:2018, Annex D.

However, in the presence of noise, the RSSI is not a good measure to base a power adjustment algorithm on. A measure of the excess signal-to-noise ratio or link margin is more useful during operation. The Link Margin expresses the signal-to-noise ratio margin while still having a sufficient signal level for demodulation (as deemed by the receiver). It enables the meter to perform an autonomous power level adjustment without being dependent on information on the required minimum signal-to-noise ratio in the receiver at the communication partner. For that reason, the communication partner should support a valid link margin or at least a valid RSSI value.

The meter may adjust its output power based on the link margin but the meter should have an automated exception handling mechanism (to set the RF transmission power to a default value) in case it does not receive information from the communication partner for a prolonged time. Table 16 — Meaning of status byte for partner messages

Bit no.

Value and meaning

7

This content of the status byte is reserved for future use

0:

The content represents the last received RSSI value for a reception from this meter

0:

6

5 to 0

1: 1:

0 to 63:

Link Margin

The content represents the link margin for the last reception from this meter

Unsigned integer. The figure for the received level, to be handled as shown in Table 17

Table 17 — Meaning of bits 0 to 5 in status byte for partner messages

Type

RSSI

The status byte contains signal level information as specified in the bits that follows

Value and meaning 0:

No RSSI value available or wired communication

2 to 62:

The reception level is calculated The level is in the range −126 dBm to −6 dBm

1:

63: 0: 1:

2 to 62: 63:

The reception level is −128 dBm or below The reception level is −4 dbm or above

as

−130+(2 × RSSI

value) dBm

No link margin information available or wired communication The link margin is −10 dB or below

The link margin is calculated as The level is in the range −9 dB to +51 dB The link margin is +52 dB or above

(−11

+

Link

margin

value) dB

The value of “0” in bits 0 … 5 means either that the partner does not provide RSSI values or that the partner has so far not received any message from the meter.

31

EN 13757-7:2018 (E)

7.5.8 Configuration field The configuration field (CF) consists of two bytes and contains information about the applied Security mode. This Security mode defines: — applied set of security mechanisms;

— content of other bits in the configuration field;

— presence, length and content of configuration field extension (CFE);

— number, length and content of optional TPL-header/trailer fields after the configuration field respectively after the configuration field extension. Table 18 shows where to find the Security mode bits. The decoding of the other bits (marked with “X”) depends on the selected Security mode (see 7.7). MS Bit 15

Bit 14

Bit 13

Bit 12

Bit 11

Bit 10

Bit 9

Bit 8

Bit 7

Bit 6

Bit 5

Bit 4

Bit 3

Bit 2

Bit 1

LS Bit 0

Security mode specific

Security mode specific

Security mode specific

Security mode bit 4

Security mode bit 3

Security mode bit 2

Security mode bit 1

Security mode bit 0

Security mode specific

Security mode specific

Security mode specific

Security mode specific

Security mode specific

Security mode specific

Security mode specific

Security mode specific

Table 18 — General definition of the two mandatory configuration field bytes

X

X

X

M

M

M

M

M

X

X

X

X

X

X

X

X

The field Security mode in the configuration field allows to select a Security mechanism to protect the message. Table 19 provides a list of available Security mechanisms. The Security mechanisms of the Transport Layer are described in 9.4.

32

EN 13757-7:2018 (E)

Table 19 — Definition of the mode bits in the configuration field (Security mode) Security Mode

Reference

0

No encryption used

—

2

DES; IV = 0 (deprecated)

9.4.3

1 3 4 5 6 7 8 9

10 11 12 13 14 15

a

Characteristics

16–31

Manufacturer specific usage

9.4.2

DES; IV ≠ 0 (deprecated)

9.4.3

Specific usagea

NOTE

AES-CBC-128; IV ≠ 0

See Bibliographical Entry [6].

9.4.4

Reserved for future use

—

AES-CBC-128; IV = 0

9.4.5

AES-CTR-128; CMAC

9.4.6

AES-GCM-128

9.4.7

AES-CCM-128

9.4.8

Reserved for future use

—

Reserved for future use

—

Specific usagea

Reserved for future use

NOTE

See Bibliographical Entry [8].

NOTE

See Bibliographical Entry [7].

—

Specific usagea

Reserved for future use

—

See reference in Bibliography for use of this mode at time of release of this standard.

7.6 Configuration field dependent structure 7.6.1 General

Table 20 — TPL structure of a secured message TPL-Header CI-field

CIdependent fields (see 7.3 and 7.4)

Configuration field extension

APL Optional TPL-header fields

Encrypted application data

TPL-Trailer Unencrypted application data

Optional TPLtrailer fields

If a short or long TPL-header is applied, there is always a configuration field. Behind the configuration field and in front of the application data may be a configuration field extension and additional optional TPL header fields. There may also be optional TPL-trailer fields behind the application data. The presence of these fields is controlled by the configuration field and the configuration field extension.

All fields before the configuration field, the configuration field itself and the configuration field extension are always unencrypted. Depending on the selected Security mode, optional TPLheader/trailer fields may be encrypted. Application data can be encrypted, unencrypted or partial encrypted. In case of partial encryption, the encrypted data are always transmitted before the unencrypted data (see 7.6.5).

33

EN 13757-7:2018 (E)

The length of encrypted data are coded either in the configuration field or in optional TPL-header fields. The calculation of the length of encrypted data are Security mode specific. 7.6.2 Configuration field extension

The configuration field extension is an optional component of the TPL. Presence and content depends on the Security mode chosen in the configuration field.

It contains a set of controlling bits for security relevant parameters like Key IDs, KDF function definitions and gives information about the presence of following optional TPL-header and TPL-trailer fields. 7.6.3 Optional TPL-header fields

The optional TPL-header fields after the configuration field or configuration field extensions are optional components of the TPL. The presence and size depends on the controlling bits (including Security mode bits) in the configuration field or configuration field extensions. Optional TPL-header fields contain security relevant parameters, such as counters, time stamps or length information of secured data. 7.6.4 Optional TPL Trailer fields

The optional TPL Trailer fields after the Application Layer are optional components, which are located at the end of the message. The presence and length is predefined by controlling bits in the configuration field respectively the configuration field extension.

Together with the TPL-header, the TPL Trailer encapsulates the application data of a message. It contains security relevant parameters like authentication tags and time stamps. 7.6.5 Partial encryption

If the number of encrypted bytes is less than the total length of application data, unencrypted data follow the encrypted data. The boundary between encrypted and unencrypted data shall not be within a data point. If necessary, remaining unused bytes in encrypted part shall be filled up by padding bytes.

Some Security modes specify the number of encrypted bytes or blocks by using the N-bits of the configuration field. All N-bits set to 1 (e.g. NNNNNNNN = 11111111b) specifies that partial encryption is disabled and no unencrypted data follows after the encrypted data. This enables the possibility to encrypt very large fragmented messages. If all N-bits set to 0b, no encrypted data follows. This is useful if the message should be transmitted unencrypted but authenticated. The receiver of the message needs to interpret the header structure of the applied Security mode for correct recognition of the unencrypted part of a partial encrypted message.

NOTE 1 Some Security modes add security related fields (such as an authentication tag) after the optionally unencrypted data. The fields and number of attached bytes are indicated by the header of the Transport Layer.

NOTE 2 The addition of encrypted or unencrypted data from another device (such as repeater latency) to the application data of an authenticated message is not feasible, as otherwise the authentication fails.

7.7 Security mode specific TPL-fields

7.7.1 Shared subfields of configuration field and configuration field extension Apart from the declaration of Security mode the configuration field defines additional mode specific subfields. This section declares subfields of the configuration field shared by several Security modes (see 7.7.2 to 7.7.8).

Subfield H and R: message repetition

34

EN 13757-7:2018 (E)

Bit H and bit R of the configuration field are reserved for use in repeated messages (according to EN 13757-5). A meter shall always set H = 0b and R = 0b in a transmitted message. The meter may ignore these bits in a received message. These bits are reserved for the wireless M-Bus communication. For the communication on wired M-Bus, the bits H and R shall be set to “0”. Security modes which not support these subfields can apply this service by using an ELL (refer to EN 13757-4). Subfield CC: message content

Bits CC are used to describe the contents of the message. The definition distinguishes between a meter and a partner message (refer to Table 21 and Table 22). Table 21 — Content of meter message

Bit CH

Bit CL

0

0

Standard data message

1

0

Static message (consists of parameter, OBIS-definitions and other data, which are not frequently changed).

0 1

1

Content of the message

Reserved

1

Reserved for future extensions

NOTE The subfield CC shall only be applied for message types SND-NR and SND-IR (see EN 13757–4). All other meter message types shall use CC = 00b.

Table 22 — Content of partner message

Bit CH

Bit CL

0

0

Standard command message

1

0

Reserved

0 1

1 1

Content of the message

Reserved

Reserved for future extensions

NOTE The subfield CC shall only be applied for message types SND-UD, SND-UD2 or SND-UD3 (see EN 13757–4). All other partner message types shall use CC = 00b.

Subfield IIII: Content index

This field is used to differentiate between meter messages with different content but with the same content field value ‘CC’. Using this field a receiver is able to identify and store or filter messages with different content without the need to decrypt the application data. Transmitters not supporting this optional feature shall always set this field to 0. Receivers not supporting this optional feature shall ignore this field. This field does not specify the actual content but best practice would be to use the lowest value for the most frequently transmitted messages. Subfield B, A and S: Link Access Control

Bit S is used to declare a synchronous transmission. If the transmission timing (predictable transmission time) fulfils the requirements of a synchronous transmission as defined in EN 13757-4, it shall mark this transmission with a set bit S. Otherwise, the bit S shall always be 0. The configuration field bits A and B (Accessibility and Bidirectional communication) are used as defined in Table 23 for access control to the meter.

35

EN 13757-7:2018 (E)

Table 23 — Accessibility of a meter Bit B

Bit A

0

0

Meter/actuator provides no access window (unidirectional meter)

1

0

Meter provides a short access window only immediately after this transmission

0

1

1

1

Accessibility of a wireless meter

Meter supports bidirectional access in general, but there is no access window after this transmission Meter provides unlimited access (at least until the next transmission)

Security modes which not support these subfields can apply this service by using an ELL (refer to EN 13757-4).

These bits are reserved for the wireless M-Bus communication. For the communication on wired M-Bus, the bits B, A and S shall be set to “0”. Subfield KKKK: Key ID

The Key ID (KKKK) is used to identify the applied key for this message. Table 24 shows the structure of the Key ID list. Table 24 — The Key ID

Key ID

K

K

K

K

00

0

0

0

0

User Key 0

02

0

0

1

0

User Key 2

01 03 04 05 06 07 08 09 10 11 12 13 14 15

0 0 0 0 0 0 1 1 1 1 1 1 1 1

0 0 1 1 1 1 0 0 0 0 1 1 1 1

0 1 0 0 1 1 0 0 1 1 0 0 1 1

1 1 0 1 0 1 0 1 0 1 0 1 0 1

Encryption or Authentication keys User Key 1 User Key 3 User Key 4 User Key 5 User Key 6 User Key 7 User Key 8 User Key 9

User Key 10 User Key 11 User Key12

User Key 13 User Key 14 User Key 15

In case of derived ephemeral keys, the Key ID of the persistent key (applied in the KDF) shall be used. Subfield V: Version (and Key Version field)

The Version bit (V) enables the Key Version field. The Key Version field is only present in TPL-Header (see 7.7.5 to 7.7.8) if the Version bit is set. The AFL.KI-field supports also a Key Version subfield (see 6.3.4). If the Key Version field is present it identifies the applied version of key with the concerning Key ID.

The Key Version field is used to distinguish keys with same Key ID (and the same purpose). A new key should apply a higher version number than an older one. A valid key version is in the range from

36

EN 13757-7:2018 (E)

0 to 254. The value 0 is used as default value by the manufacturer. The value 255 signals that the Key Version field is not in use.

In case of derived ephemeral keys, the Key Version of the persistent key (applied in the KDF) shall be used.

NOTE

The meter holds typically only a small set of keys.

Subfield DD: KDF-Selection

The KDF-Selection (DD) identifies the applied Key Derivation Function (KDF), if any. Table 25 shows the possible values of this subfield. Table 25 — KDF-Selection

KDF

D

D

—

0

0

Persistent keya

B

1

0

Reserved

A

a

0

C

Applied Key Derivation Function

1

1

Key Derivation Function A (see 9.6.1)

1

Reserved

No key derivation – stored key is used directly for encryption or authentication.

7.7.2 Configuration field of Security mode 0

Table 26 shows message structure behind (and including) the configuration field in case of Security mode 0. Table 26 — Configuration field and subsequent fields with Security mode 0 Field name

Config. Field (see Table 27)

Length

Unencrypted application data

2

…

Table 27 — Definition of the configuration field for Security mode 0

Hop counter

LS Bit 0

Repeater access

Bit 1

Content of message

Bit 2

Content of message

Bit 3

Reserved

Bit 4

Reserved

Bit 5

Reserved

Bit 6

Reserved

Bit 7

Security mode

Bit 8

Security mode

Bit 9

Security mode

Bit 10

Security mode

Bit 11

Security mode

Bit 12

Synchronized

B

Bit 13

Accessibility

Bit 14

A

M

M

M

0

0

C

H

Bidirectional communication

MS Bit 15

S

M

M

0

0

C

R

Bit 0: Hop counter ‘H’

— This bit is specified in 7.7.1. Bit 1: Repeater Access ‘R’

— This bit is specified in 7.7.1.

Bit 2 to bit 3: Content of Message ‘CC’

— These bits are defined in Table 21 and Table 22 (see 7.7.1)

37

EN 13757-7:2018 (E)

Bit 4 to bit 7: Reserved with value equal 0b Bit 8 to bit 12: Security mode ‘MMMMM’

— For specification of modes (see Table 19)

— Mode 0 is declared by MMMMM = 00000b Bit 13: Synchrony bit ‘S’

— This bit is specified in 7.7.1. Bit 14: Accessibility bit ‘A’

— This bit is specified in 7.7.1. Bit 15: Bidirectional bit ‘B’

— This bit is specified in 7.7.1.

7.7.3 Configuration field of Security modes 2 and 3

Table 28 shows message structure behind (and including) the configuration field in case of Security mode 2 and 3. Table 28 — Configuration field and subsequent fields with Security mode 2 and 3 Config. Field (see Table 29)

Field name Length

Unencrypted application data (optional)

Encrypted application data

2

NNNNNNNN

Table 29 — Definition of the configuration field for Security modes 2 and 3

Number of encr. bytes

LS Bit 0

Number of encr. bytes

Bit 1

Number of encr. bytes

Bit 2

Number of encr. bytes

Bit 3

Number of encr. bytes

Bit 4

Number of encr. bytes

Bit 5

Number of encr. bytes

Bit 6

Number of encr. bytes

Bit 7

Security mode

Bit 8

Security mode

Bit 9

Security mode

Bit 10

Security mode

Bit 11

Security mode

Bit 12

Reserved

Bit 13

Reserved

Bit 14

Reserved

MS Bit 15

…

0

0

0

M

M

M

M

M

N

N

N

N

N

N

N

N

Bit 0 to bit 7: Length ‘NNNNNNNN’

— Number of bytes of encrypted data (e.g. NNNNNNNN = 000100000b equate to 32 bytes; see also 7.6.5)

Bit 8 to bit 12: Security mode ‘MMMMM’

— For specification of Security modes (see Table 19) — Mode 2 is declared by MMMMM = 00010b

38

EN 13757-7:2018 (E)

— Mode 3 is declared by MMMMM = 00011b Bit 13 to bit 15: Reserved with value equal 0b

Refer to 9.4.3 for details about these Security modes.

7.7.4 Configuration field of Security mode 5

Table 30 shows message structure behind (and including) the configuration field in case of Security mode 5. Table 30 — Configuration field and subsequent fields with Security mode 5 Decryption Verification (encrypted)

Config. Field (see Table 31)

Field name Length

2

Unencrypted application data (optional)

Encrypted application data

2

16*NNNN – 2

Table 31 — Definition of the configuration field for Security mode 5

Hop counter

A

M

M

M

N

N

C

LS Bit 0

Repeater access

Bit 1

Content of message

Bit 2

Content of message

Bit 3

Number of encr. blocks

Bit 4

Number of encr. blocks

Bit 5

Number of encr. blocks

Bit 6

Number of encr. blocks

Bit 7

Security mode

Bit 8

Security mode

Bit 9

Security mode

Bit 10

Security mode

Bit 11

Security mode

Bit 12

Synchronized

B

Bit 13

Accessibility

Bit 14

Bidirectional communication

MS Bit 15

…

S

M

M

N

N

C

R

H

For the communication on wireless M-Bus the bits shall be used as follows:

Bit 0: Hop counter ‘H’

— This bit is specified in 7.7.1. Bit 1: Repeater Access ‘R’

— This bit is specified in 7.7.1.

Bit 2 to bit 3: Content of Message ‘CC’

— These bits are defined in Table 21 and Table 22 (see 7.7.1).

Bit 4 to bit 7: Length ‘NNNN’

— Length of encrypted data, given in blocks of 16 bytes each (e.g. NNNN = 0010b equate to 32 bytes; see also 7.6.5.)

Bit 8 to bit 12: Security mode ‘MMMMM’

— For specification of modes (see Table 19)

— Mode 5 is declared by MMMMM = 00101b

39

EN 13757-7:2018 (E)

Bit 13: Synchrony bit ‘S’

— This bit is specified in 7.7.1. Bit 14: Accessibility bit ‘A’

— This bit is specified in 7.7.1. Bit 15: Bidirectional bit ‘B’

— This bit is specified in 7.7.1.

Refer to 9.4.4 for details about these Security modes.

7.7.5 Configuration field of Security mode 7

Table 32 shows message structure behind (and including) the configuration field in case of Security mode 7. Table 32 — Configuration field and subsequent fields with Security mode 7

(1)

(4)

2

16*NNNN – 2

(1 to 16)

Unencrypted application data (optional) …

Table 33 — Definition of the configuration field for Security mode 7

Bit 1

LS Bit 0

Content index

Bit 2

Content index

Bit 3

Content index

Bit 4

Padding

Bit 5

Number of encr. blocks

Bit 6

Number of encr. blocks

Bit 7

Number of encr. blocks

Bit 8

Number of encr. blocks

Bit 9

Security mode

Bit 10

Security mode

Bit 11

Security mode

Bit 12

Security mode

Bit 13

Counter size

Bit 14

1

TPLpadding (optional)

Content of Message

MS Bit 15

2

Encrypted application data

Security mode

Length

Config. Config. field Message Key Decryption field (see extension counter Version Verification Table 33 (see (optional (optional) (encrypted) ) Table 34) )

Content of Message

Field name

C

C

Z

M

M

M

M

M

N

N

N

N

P

I

I

I

Bit 0 to bit 2: Content index ‘IIII’

— Content index as specified in 7.7.1. with a limitation to maximum Content index value = 7. Bit 3: Padding 'P'

— This bit defines the presence of the field TPL-padding

— Padding bit equal 0b:field TPL-padding is not present. (0 byte)

— Padding bit equal 1b:field TPL-padding is present (1–16 byte according to 9.4.5.4) NOTE

The size of the field TPL-padding is defined by the field itself.

Bit 4 to bit 7: Length ‘NNNN’

40

EN 13757-7:2018 (E)

— Length of encrypted data, given in blocks of 16 bytes each (e.g. NNNN = 0010b equate to 32 bytes; see also 7.6.5.)

Bit 8 to bit 12: Security mode ‘MMMMM’

— For specification of Security modes (see Table 19) — Mode 7 is declared by MMMMM = 00111b Bit 13: Counter size ‘Z’

— This bit defines size of counter in TPL

— Counter size bit equal 0b: counter size is 0 byte (not present)

— Counter size bit equal 1b: counter size is 4 bytes (present)

Bit 14 to bit 15: Content of Message ‘CC’

— These bits are defined in Table 21 and Table 22 (see 7.7.1).

Table 34 — Definition of the configuration field extension for Security mode 7 LSBit 0

Key ID

Bit 1

Key ID

Bit 2

Key ID

Bit 3

Key ID

Bit 4 KDF-Selection

Bit 5 KDF-Selection

0b

Bit 6

Version

Reserved

MSBit 7

V

D

D

K

K

K

K

Bit 0 to bit 3: Key ID ‘KKKK’

— Key IDs as specified in Table 24 (see 7.7.1).

Bit 4 to bit 5: KDF-Selection ‘DD’

— Selector for key derivation function as specified in Table 25 (see 7.7.1).

Bit 6: Version ‘V’

— Version bit equal 0b: the field Key Version is not present (0 byte)

— Version bit equal 1b: the field Key Version is present (1 byte) (see 7.7.1).

Bit 7: Reserved with value equal 0b

Refer to 9.4.5 for details about this Security mode.

7.7.6 Configuration field of Security mode 8

Table 35 shows message structure behind (and including) the configuration field in case of Security mode 8.

41

EN 13757-7:2018 (E)

Length

2

(1)

(1)

(1)

2/3/4

Length (E)

Transmission Time stamp (optional)

Authentication Tag 1

…

Authentication Tag 2 (optional)

Unencrypted Application data (optional)

Encrypted Application data

Message counter

Length[E] (optional)

Key Version (optional)

Config. Field (see Table 36)

Field name

Config. field extension (optional) (see Table 37)

Table 35 — Configuration field and subsequent fields with Security mode 8

4

(3)

(2)

In deviation to the usual transmission order of multi byte fields the Authentication Tag 1 and Authentication Tag 2 shall be transmitted with MSB first.

NOTE 1 The Authentication Tag1 (MAC_1) and 2 (MAC_2) and the Transmission Time stamp are located at the end of message. When Transmission Time stamp is activated, the Authentication Tag2 is also enabled to authenticate the Transmission Time stamp field. NOTE 2

Table 36 — Definition of the configuration field for mode 8

M

M

E

Bit 0 to bit 3: Key ID ‘KKKK’

O

Z

Z

K

K

K

K

— Key ID as specified in Table 24 (see 7.7.1)

Bit 4 to bit 5: Counter size ‘ZZ’

— Counter size bits equal 00b: reserved

— Counter size bits equal 01b: Subsequent counter field has size of 2 bytes

— Counter size bits equal 10b: Subsequent counter field has size of 3 bytes

— Counter size bits equal 11b: Subsequent counter field has size of 4 bytes Bit 6: Authentication Tag2 and Transmission Time Stamp ‘O’

— bit Authentication Tag2 and Transmission Time Stamp equal 0b: both Authentication Tag 2 and Transmission Time Stamp are not present (0 byte)

— bit Authentication Tag2 and Transmission Time Stamp equal 1b: Authentication Tag 2 is present (2 byte) and Transmission Time Stamp is present (3 bytes)

42

LS Bit 0

Key ID

M

Bit 1

Key ID

M

Bit 2

Key ID

D

Bit 3

Key ID

X

Bit 4

Counter size

M

Bit 5

Counter size

Len E bit

D

Bit 6

Authentication Tag2 and Transmission Time Stamp

Bit 7

Security Mode

Bit 8

Security Mode

Bit 9

Security Mode

Bit 10

Security Mode

Bit 11

Security Mode

Bit 12

KDF-Selection

Bit 13

KDF-Selection

Bit 14

CFE

MS Bit 15

All optional fields from TPL-header and TPL-trailer are transmitted unencrypted.

EN 13757-7:2018 (E)

Bit 7: Len E bit ‘E'

— Len E bit equal 0b: the field Length[E] is not present (0 (There will be no unencrypted application data after the encrypted application data.)

byte)

— Len E bit equal 1b: the field Length[E] is present (1 byte) (The field Length[E] is coded as unsigned integer. This allows a maximum length of 255 bytes of encrypted application data.)

Bit 8 to bit 12: Security mode ‘MMMMM’

— For specification of Security modes (see Table 19) — Mode 8 is declared by MMMMM = 01000b Bit 13 to bit 14: KDF-Selection ‘DD’

— Selector for key derivation function as specified in Table 25 (see 7.7.1)

Bit 15: CFE ‘X’

— CFE bit 0: The configuration field extension is not present (0 byte)

— CFE bit 1: The configuration field extension is present (1 byte); see Table 35

Table 37 — Definition of the configuration field extension for Security mode 8

Content of Message

LSBit 0

Content of Message

Bit 1

Version

Bit 2

Reserved

Bit 3

Content index

Bit 4

Content index

Bit 5

Content index

Bit 6

Content index

MSBit 7

I

I

I

I

0b

V

C

C

Bit 0 to bit 1: Content of Message ‘CC’

— These bits are defined in Table 21 and Table 22 (see 7.7.1)

Bit 2: Version ‘V’

— Version bit equal 0b: the field Key Version is not present (0 byte)

— Version bit equal 1b: the field Key Version is present (1 byte) (see 7.7.1) Bit 3: Reserved with value equal 0

Bit 4 to bit 7: Content index ‘IIII’

— Content index as specified in 7.7.1. Message counter field: — See 9.2.

Authentication Tag 1:

43

EN 13757-7:2018 (E)

— For specification of Authentication Tag 1 see 9.4.6.3. Transmission Time Stamp:

— The optional transmission time stamp indicates the transmission date/time of the message by the meter or the communication partner. This Transmission Time Stamp does not represent the time of data acquisition. It shall be updated in case of transmitting the same payload multiple times. This provides replay attack protection. Format: date in seconds (like UNIX EPOCH) since January 1st, 2013 at 00:00 coded with 3 bytes. The maximum value is FFFFFFh Example: coding February 1st, 2015 at 02:00

— Number of seconds since January 1st, 2013 at 00:00 = 65 757 600 s

— Conversion in hexadecimal: 3EB61A0h

— Transmission Time Stamp value: EB61A0h, results in 15 425 952 s. Authentication Tag 2:

— For specification of Authentication Tag 2 see 9.4.6.3. 7.7.7 Configuration field of Security mode 9

Table 38 shows message structure behind (and including) the configuration field in case of Security mode 9.

Length NOTE

2

(1)

1 or 2

1 or 2

4

The Authentication Tag is located at the end of the message.

Length (E)

Length (U)

Authentication Tag (optional)

Unencrypted Application data (optional)

Encrypted Application data

Message counter

Length (U)

Length (E)

Key Version (optional)

Field name

Config. field (see Table 29)

Table 38 — Configuration field and subsequent fields with Security mode 9

12

In deviation to the usual transmission order of multi byte fields the Authentication Tag shall be transmitted with MSB first.

44

EN 13757-7:2018 (E)

Table 39 — Definition of the configuration field for Security mode 9

Key ID

V

M

M

M

E

D

K

K

O

Bit 0 to bit 3: Key ID ‘KKKK’

Key ID

LS Bit 0

Key ID

Bit 1

Key ID

Bit 2

KDF-Selection

Bit 3

KDF-Selection

Bit 4

Len E bit

Bit 5

Len U bit

Bit 6

Security mode

Bit 7

Security mode

Bit 8

Security mode

Bit 9

Security mode

Bit 10

Security mode

0b

Bit 11

Version

Tag

Bit 12

Authentication size

Bit 13

field

Bit 14

Reserved for extensions

MS Bit 15

M

M

U

D

K

K

— Key IDs as specified in Table 24 (see 7.7.1)

Bit 4 to bit 5: KDF-Selection ‘DD’

— Selector for key derivation function as specified in Table 25 (see 7.7.1)

Bit 6: Len E bit ‘E’

— Len E bit equal 0b: the field Length (E) is one byte (This allows a maximum length of 255 bytes encrypted application data)

unsigned

integer

— Len E bit equal 1b: the field Length (E) is two bytes (This allows a maximum length of 65535 bytes encrypted application data)

unsigned

integer

— Len U bit equal 0b: the field Length (U) is one byte (This allows a maximum length of 255 bytes unencrypted application data)

unsigned

integer

— Len U bit equal 1b: the field Length (U) is two bytes unsigned (This allows a maximum length of 65535 bytes unencrypted application data)

integer

Bit 7: Len U bit ‘U’

Bit 8 to bit 12: Security mode ‘MMMMM’

— For specification of Security modes (see Table 19) — Mode 9 is declared by MMMMM = 01001b Bit 13: Authentication Tag size ‘O’

— Authentication Tag size bit equal 0b: Authentication Tag is 0 byte (not present) — Authentication Tag size bit equal 1b: Authentication Tag is 12 bytes (present)

Bit 14: Version ‘V’

— Version bit equal 0b: the field Key Version is not present (0 byte)

— Version bit equal 1b: the field Key Version is present (1 byte) (see 7.7.1)

45

EN 13757-7:2018 (E)

Bit 15: Reserved for field extensions with value equal 0b Refer to 9.4.7 for details about this Security mode. 7.7.8 Configuration field of Security mode 10

Table 40 shows message structure behind (and including) the configuration field in case of Security mode 10.

Length

2

2

(1)

(4)

NNNNNNNN

…

Authentication tag (encrypted)

Unencrypted application data (optional)

Encrypted application data

Message counter (optional)

Field name

Key Version (optional)

Config. field extension (see Table 42)

Config. field (see Table 41)

Table 40 — Configuration field and subsequent fields with Security mode 10

4/8/12/16

In deviation to the usual transmission order of multi byte fields the Authentication Tag shall be transmitted with MSB first. Table 41 — Definition of the configuration field for Security mode 10

M

N

N

N

Bit 3

N

Bit 2

N

Bit 1

N

N

— Length of encrypted data (e.g. NNNNNNNN = 000100001b equate to 33 bytes; see also 7.6.5.)

Bit 8 to bit 12: Security mode ‘MMMMM’

— For specification of Security modes (see Table 19) — Mode 10 is declared by MMMMM = 01010b Bit 13: Counter size ‘Z’

— This bit defines size of counter in TPL

— Counter size bit equal 0b: counter size is 0 byte (not present)

— Counter size bit equal 1b: counter size is 4 bytes (present)

Bit 14 to bit 15: Content of Message ‘CC’

— These bits are defined in Table 21 and Table 22 (see 7.7.1).

46

LS Bit 0 Number of encrypted bytes

M

Bit 4

Number of encrypted bytes

M

Bit 5

Number of encrypted bytes

C

Bit 0 to bit 7: Length ‘NNNNNNNN’

Bit 6

Number of encrypted bytes

Security mode

M

Security mode

M

Security mode

Z

Content of Message

C

Bit 7

Number of encrypted bytes

Bit 8

Number of encrypted bytes

Bit 9

Number of encrypted bytes

Bit 10

Number of encrypted bytes

Bit 11

Security mode

Bit 12

Security mode

Bit 13

Counter size

Bit 14

Content of Message

MS Bit 15

N

EN 13757-7:2018 (E)

Table 42 — Definition of the configuration field extension for Security mode 10 Bit 13

Bit 12

Bit 11

Bit 10

Bit 9

Bit 8

Bit 7

Bit 6

Bit 5

Bit 4

Bit 3

Bit 2

Bit 1

LS Bit 0

Key ID

Key ID

O

Key ID

Bit 0 to bit 3: Key ID ‘KKKK’

O

Key ID

I

KDF-Selection

I

KDF-Selection

I

Version

I

Reserved

0b

Authentication size

0b

Authentication size

Content index

Content index

Content index

Content index

Reserved

Reserved

Tag

Bit 14

Tag

MS Bit 15

0b

V

D

D

K

K

K

K

— Key ID as specified in Table 24 (see 7.7.1)

Bit 4 to bit 5: KDF-Selection ‘DD’

— Selector for key derivation function as specified in Table 25 (see 7.7.1)

Bit 6: Version ‘V’

— Version bit equal 0b: the field Key Version is not present (0 byte)

— Version bit equal 1b: the field Key Version is present (1 byte) (see 7.7.1) Bit 7: Reserved with value equal 0b

Bit 8 to bit 9: Authentication Tag size ‘OO’

— Authentication Tag size bits equal 00b:

Authentication Tag is 4 bytes (present)

— Authentication Tag size bits equal 10b:

Authentication Tag is 12 bytes (present)

— Authentication Tag size bits equal 01b: — Authentication Tag size bits equal 11b:

Bit 10 to bit 13: Content index ‘IIII’

Authentication Tag is 8 bytes (present)

Authentication Tag is 16 bytes (present)

— Content index as specified in 7.7.1.

Bit 14 to bit 15: Reserved with value equal 0b

Refer to 9.4.8 for details about this Security mode.

47

EN 13757-7:2018 (E)

8 Management of lower layers 8.1 General This clause provides management functions as well as specific M-Bus procedures and definitions, which are used by several layers. Most of them are dedicated to the wired M-Bus according to EN 13757-2.

8.2 Switching baud rate for M-Bus Link Layer according to EN 13757-2

The baud rate of a slave can be controlled by a switch baud rate command according to EN 13757-3:2018, Clause 11.

8.3 Address structure if used together with the wireless Data Link Layer according to EN 13757-4

The Link Layer of EN 13757-4 contains an 8-byte address, which starts with a 2-byte manufacturer identification according to EN 62056-21 (see 7.5.2), followed by 6 bytes consisting of the identification number, version and device type, as shown in Table 43. Table 43 — Address structure of the wireless Link Layer

Manufacturer identification

Identification number

Version

Device type

2 bytes

4 bytes(BCD)

1 byte

1 byte

The content of the fields shall be according to 7.5.1, 7.5.2, 7.5.3 and 7.5.4.

The 8-byte address in the long header of this standard uses the same elements but they are structured in a different order (see 7.4, Table 12). The meter shall also support wild cards (see 7.5) for the wireless Extended Link Layer Address.

8.4 Selection and secondary addressing

This technique allows the M-Bus protocol to logically “connect” a slave with a certain (secondary) address and it then associates this selected slave with the primary address of 253 (FDh). So the maximum number of 250 addresses (primary) is extended by this technique to an arbitrary number of possible slaves, effectively increasing the address range of the Link Layer. This function is only enabled by a SND-UD with CI-field 52h to address 253. When addressing in the Data Link Layer with the help of the A-field, the problem of the address allocation could arise. The addresses are normally set to a value of 0 by the manufacturer of the meters, in order to designate them as unconfigured slaves. A very laborious method of address allocation consists of setting the addresses when installing the slaves. A further method of address allocation is to determine the bus addresses when connecting the equipment to the bus with the master. This sends a command for address allocation (see CEN/TR 17167:2018, A.5) to the address 0. In this case the slaves have to be connected one at a time to the bus, which may lead to a higher installation effort. By using the secondary address in the Transport Layer these disadvantages are avoided and the address region is essentially extended beyond the number of 250. The secondary addressing is introduced with the following so-called selection (according to Table 44). Table 44 — Structure of a datagram for selecting a slave

68h

0Bh

0Bh

68h

53h/ 73h

FDh

52h

ID1–4

Man 1–2

Gen

Dev

CS

16h

The master sends a SND-UD with the control information 52h to the address 253 (FDh) and fills the specific meter secondary address (identification number, manufacturer, version and device type) with

48

EN 13757-7:2018 (E)

the values of the slave which is to be addressed. After the reception of the address 253 (FDh) the selection mode is entered. If then the proper CI-selection code CI = 52h is received, the internal selection bit is set; otherwise, it is reset. If further data bytes follow, they are compared with the corresponding internal addresses respective values of the meter. If they disagree, the selection bit is cleared; otherwise, it is left unchanged. Thus, “selecting” a meter with only a proper CI-field and no further data will select all meters on the bus capable of secondary addressing. A set selection bit means that this slave can be addressed (e.g. REQ_UD) with the bus address 253 (FDh) and in this example will reply with RSP-UD. In other words, the Transport Layer has associated this slave with the address 253 (FDh).

During selection, individual positions of the secondary addresses can be occupied with wildcards (Fh). Such a wildcard means that this position will not be taken account of during selection, and that the selection will be limited to specific positions, in order to address complete groups of slaves (multicasting). In the identification number, each individual digit can be wildcarded by a wildcard nibble Fh while the fields for manufacturer, version and device type can be wildcarded by a wildcard byte FFh. The state of the selection remains unchanged until the slave is deselected with a selection command (as described above) with non-matching secondary addresses, or a SND-NKE to address 253. In case of a SND-NKE to address 253 a selected slave shall acknowledge the deselection with a ACK. The slave will be selected by a datagram with the CI-field 52h and the correct secondary address, but it will be deselected by a datagram with any other secondary address.

A slave with implemented primary and secondary addressing shall also answer datagrams to its primary address. A SND-NKE to its primary address (0 to 250, 254, 255) will not influence the internal selection bit for the secondary addressing mode. This is comparable to the FCB management, where primary and secondary addressing is also handled separately. A slave with only secondary addressing (i.e. internal primary address = 253) shall occupy the address field in the RSP-UD datagram with 253 (FDh) to signal that it will not participate in primary addressing.

A slave with implemented primary and secondary addressing shall occupy the address field in the RSPUD telegram with its own primary address to signal its accessibility via this primary address. The slave shall ignore the state of the FCB-Bit if it receives a SELECT message (CI-field = 52h).

8.5 Generalized selection procedure

For including new or restructured identification parameters into a selection procedure an enhanced definition of the selection datagram (CI = 52h) can be used.

After the 8 bytes of the fixed selection header may also follow standard records with data. In this case only those meters will be selected where, in addition to the fixed header, all record data agree. In most but not all cases this means that the DIF and parts of the VIF (not exponent) shall match. Again wildcard rules apply to the record data (digit wildcard for BCD-coded data and byte wildcard for binary or string data). With this generalized selection it will be possible to select slaves using e.g. additional fabrication number, longer identification numbers, customer location and more information.

After the field “device type” the 8-digit BCD-fabrication number follows. Parts of the fabrication number (Fab1 … Fab4) can be occupied with wildcards (Fh). Enhanced selection with fabrication number

The identification number can be used as a customer number and then can be changed by the operator. Therefore, it is possible that two slaves have the same secondary address. For this reason the selection datagram can be extended by a fabrication number to make sure that in any case all slaves are distinguishable. This number is a serial number allocated during manufacture, coded with 8 BCD packed digits (4 bytes) like the identification number, and thus runs from 00000000 to 99999999.

49

EN 13757-7:2018 (E)

The following table shows the structure of an enhanced selection datagram released by the master. Table 45 — Application Layer structure of a datagram for enhanced selection

ID1 CI = 52h (LSB )

ID2

ID3

ID4 Man1 Man2 Ver (MSB)

Dev. Type

DIF = 0C VIF = 78 Fab h Fab1 2 h

Fab Fab4 3

After the field device type the new data are given in form of a structured data record with DIF = 0Ch and VIF = 78h. Parts of the fabrication number (Fab1 … Fab4) can be occupied with wildcards (Fh).

If a fabrication number exists and is needed for the selection procedure, the slave shall add this data to the variable data blocks in every RSP-UD datagram. If the fabrication number and enhanced selection is not implemented in a slave this device shall not confirm the enhanced selection datagram and shall be deselected. Enhanced selection should be used only if the normal kind of selection is not successful.

8.6 Searching for installed slaves 8.6.1 Primary addresses

To read out all installed slaves the master shall know all the slaves, which are connected to the bus. Therefore, the master searches for slaves with primary addressing by sending a REQ_UD2 to all allowed addresses (1 … 250) with all available baud rates. The master notes used primary addresses with the respective baud rates. 8.6.2 Secondary addresses

The secondary addressing described in the preceding section draws attention to the problem of determining the secondary addresses of slaves connected to the bus. The master can read out the slaves making use of secondary addresses with previous selection (see 8.5). Testing all possible identification numbers with the master would take years since the identification number offers millions of combinations. For this reason, a procedure was developed for the rapid and automatic determination of already installed slaves. 8.6.3 Wildcard searching procedure

The following wildcard searching procedure uses the occupation of individual parts of the secondary address with wildcards (Fh) for selection.

For the identification number (BCD), each individual position can be replaced by an wild card Fh. For manufacturer, version and device type (binary coding), only one complete byte (FFh) can be occupied with wildcards. The master begins the selection using a SND-UD with the control information 52h and occupies all positions in the identification number, except the top one, with wildcards. The top position is running through in 10 selections from 0 to 9 (0FFFFFFF to 9FFFFFFF).

If after such a selection the master receives no acknowledgement, it goes to the next selection. If the master receives an ACK, it sends a REQ_UD2 and learns the secondary address of the slaves from the reply datagram, as long as no collision occurs. If there is a collision after the selection or the REQ_UD2, the master varies the next positions and holds the existing one. If there is a collision, for example at 5FFFFFFF, the selection is running through from 50FFFFFF to 59FFFFFF. If in this case collisions again occur, then a change is made to a variation of the next position. After running through a complete position, the next higher position is processed up to 9. With this wildcard searching procedure, it will be seen that at least the top position shall be run through in order to reach all slaves. Running through further positions may be necessary, depending on the number of the slaves and the distribution of the identification numbers. This procedure allows a statement of the maximum number of selections in relation to the number of slaves, but as a

50

EN 13757-7:2018 (E)

disadvantage frequent collisions may occur. The wildcard searching procedure shall be performed for all used baud rates.

The search procedure can be extended with searching for manufacturer, generation and finally device types to find slaves, which have the same identification number. It is also possible to search for all slaves of a certain manufacturer or all slaves of a certain device type by setting the corresponding value. With extended selection meters, which differ only in their manufacturer, a specific fixed fabrication number can be distinguished. NOTE For further information on the Wildcard search procedure (secondary search), see CEN/TR 17167:2018, Annex B.

9 Security Services 9.1 General

Data transferred from and to the meter shall be regarded as private data in most cases. Therefore, they are subject to EU and national rules for the protection of private data. Different constraints in different environments make it advantageous to define not only a single but a set of methods. This clause identifies for meters as components of a smart metering system three major security services to support the objectives by the specified Security modes in this standard, given in Table 46. Table 46 — Security Services and Security objectives

Security Service

Security objective

Integrity

prevent modification of information by unauthorized parties

Confidentiality

prevent disclosure of information to unauthorized parties

Authenticity

determine the true identity of a communication party

NOTE 1 The security service “Non-repudiation” to ensure that a party cannot repudiate/refute the validity of data, is identified as not relevant for application of this standard.

Examples of the use of these security services are the following:

— Detection of zero consumption can be avoided by applying encryption using a constant varying field like a counter. An adversary cannot detect whether or not the plaintext data are unchanged by analysing the encrypted data. — Simulated transmissions can be detected by applying secure hashing of data (integrity, authenticity). An adversary cannot calculate a correct hash for the simulated data. This is only possible for the holder of the key used.

— Replay of old messages can be detected by using sequential message numbering and by applying secure hash over plaintext header and data (integrity, authenticity). The sending of an old message further along the line will be detected by the message number. An adversary will not be able to modify the time stamp/message number and then calculate a correct hash without access to the applied key.

These security services can be realized with different methods and/or techniques with adaption to their characteristics.

NOTE 2 The above mentioned functions cannot take into account that other weaknesses may reduce or remove the security. These are issues like incorrect application of cryptographic algorithms, vulnerability in the design of the software, unsecure storage of keying material and social engineering.

51

EN 13757-7:2018 (E)

The M-Bus protocol is optimized to comply with technical constraints as indicated by the introduction clause. For that reason, the security services are based on usage of symmetrical cipher methods. Much experience is gained with the Advanced Encryption Standard (AES; see ISO/IEC 18033-3) algorithm and its modes of operation and their strength has been assessed by crypto experts. Additionally a minimized footprint is provided. Hardware support for AES-128 is also widely available. NOTE 3

The application of certain encryption methods might be prohibited by local laws.

9.2 Message counter 9.2.1 Overview

The meter shall support one message counter (meter counter CM) independent of the number of used keys. The message counter shall be used to identify a message. This subclause describes the algorithms for control and verification of message counters. The following counters are needed for data exchange:

—

CM

meter counter used by the meter as transmission counter;

—

C’CP

unverified copy of communication partner counter used by the meter;

— —

CCP

C’M

communication partner counter used by the communication partner as transmission counter; unverified copy of meter counter used by the communication partner;

— C”M verified copy of meter counter used by the communication partner. The meter counter CM is the leading counter in the system.

The communication partner counter CCP shall be managed according to the meter counter as described in the following subclauses. See Annex B for an example of the message counter handling.

The unverified copy of the counter is necessary because the authentication of fragmented messages cannot be checked before the last fragment is received. Thus the counter, received with the first fragment, shall be stored as an unverified copy until the last fragment is received. The communication partner shall additionally save an authenticated (verified) copy of received meter counter to avoid replay attacks. 9.2.2 Message counter CM transmitted by the meter

CM is used for the derivation of keys applicable to messages transmitted from the meter to the communication partner and for the counter based security mechanisms (like GCM). The initial value of CM is 0.

The meter shall increment CM by 1 prior to generating an authenticated or encrypted message. The applied message counter CM is being transmitted in the unencrypted part of the secured message.

When the counter CM reaches the maximum value it should roll over with next increment. In this case the meter transmits next message with counter value 0. The counter roll over may cause a reuse of a previously applied key/counter combination (if key was not exchanged in between). This may enable also a replay attack. For this reason the keys should be replaced before a counter rolls over. Restrictive systems will not allow a roll over of the counter in general. In this case the counter should be reset when keys were changed. Note that this can cause a problem in the case that counter is used for several keys. To avoid a counter overflow it is recommended to select a sufficient counter size.

52

EN 13757-7:2018 (E)

NOTE In case that a 4 byte counter is used with a meter using a frequent transmission interval the time span for reaching the maximum value exceeds the defined life time of the meter by far.

9.2.3 Message counter CCP transmitted by the communication partner

CCP is used for the derivation of keys applicable to messages transmitted from the communication partner to the meter and for the counter based security mechanisms (like GCM). The initial value of CCP for each meter is 0.

The communication partner shall increment CCP prior to generating an authenticated and/or encrypted message. The increment shall not exceed the value of 100. The Message counter CCP may also be set when a message from the meter is received (see 9.2.5).

When the counter CCP reaches the maximum value it should roll over to zero with the next increment. In this case the communication partner transmits the next message with counter value between 0 and 99.

Restrictive systems may not allow a roll over of the counter in general. In this case the counter may be reset when the key is changed. Consider that this may cause problems by the fact that the counter might be used for several keys. 9.2.4 Message counter C’CP received by the meter

When a meter receives a message from the communication partner, the value of its message counter shall be checked. If the received message counter value is not in range between CM+1 and CM+100, the message shall be discarded (see 9.5), otherwise a copy of the received message counter value shall be stored as C’CP. This counter C’CP is used for the key derivation function and for the counter based security mechanisms (if applicable). The derived key(s) are used for the decryption or authentication check of messages depending on the applied security mechanism.

If the message passes the authentication check successfully and if counter value C’CP is greater than the current meter counter CM then CM shall be set to C’CP. Otherwise the counter CM shall remain unchanged. The check of “greater than” should consider the case of roll over.

C’CP may be discarded after the authentication check (executed after reception of the last fragment).

9.2.5 Message counter C’M and C”M received by the communication partner

When a communication partner receives a message from the meter, the value of its message counter shall be compared with the last stored copy of verified meter message counter C”M. If the currently received message counter value is less than or equal to C”M, the communication partner shall discard the message (see 9.5). Otherwise the received message counter value is stored as a copy of the unverified meter message counter C’M. The check of “less than” should consider the case of roll over.

If the message passes the authentication check successfully then C”M shall be set to C’M and if C”M is greater than the current counter value of CCP then CCP shall be set to counter value C”M. Otherwise the counter CCP shall remain unchanged. C’M may be discarded after the authentication check (executed after reception of the last fragment). C”M shall be stored permanently. The initial value of C”M is 0.

NOTE Because of the short response time of some wireless M-Bus transmission modes the communication partner is able to calculate the Encryption Key and Authentication Key in advance, based on the assumption of the next Message counter value (CM).

53

EN 13757-7:2018 (E)

The value of verified Meter Message counter copy C”M shall be used for the key derivation function and for the counter based security mechanisms (if applicable). The derived key(s) are used for the decryption or authentication check of messages depending on the applied security mechanism.

9.3 Authentication methods in the AFL 9.3.1 Overview

This subclause describes the applicable Security mechanisms in the Authentication and Fragmentation Sublayer (AFL). The applied authentication method in the AFL is identified by the AT-subfield in MCLfield of AFL (see Table 6 in 6.3.3). The key material used for the authentication is defined as:

— KMAC: applied in transmission direction from meter to communication partner;

— LMAC: applied in transmission direction from communication partner to meter.

Those keys can be persistent keys or ephemeral keys generated with a key derivation function according to 9.6 (see also 7.7.1). This depends on the security system design. If an ephemeral key is used the Message counter shall be transmitted in the AFL.MCR field (see 6.3.5).

The MAC shall be calculated over the TPDU. The MAC of a received message shall be verified before the received TPDU is forwarded to the next layer. In case of failures resulting from MAC calculation the actions specified in 9.5 shall be applied. CEN/TR 17167:2018, Annex F shows examples of data authenticated by the AFL. 9.3.2 Authentication method AES-CMAC-128

The authentication of the message is supported by the AFL with the Authentication Type AT = 3, 4, 5, 6 or 7 (refer to 6.3.3). The MAC shall be calculated according to NIST/SP 800-38B.

Input for the algorithm AFL.MAC =

CMAC (Kmac/Lmac, AFL.MCL || {AFL.KI} || {AFL.MCR} || {AFL.ML} || First byte of TPDU (CI-field) || ... || Last byte of TPDU) All multi byte fields are arranged in the same order as in the transmitted message. fields within curly braces may not be transmitted and shall be ignored during the concatenation of fields, if they are not present. The presence of the AFL.KI, AFL.MCR and AFL.ML field depends on the selection bits in the AFL.MCL field. Output of the algorithm

The 16 byte result of this CMAC-function may be truncated as defined in NIST/SP 800-38B. The length of the transmitted result (4, 8, 12 or 16 bytes) shall be declared in the AFL.MCL.AT field (refer to 6.3.3). The authentication tag corresponding to the protected data shall be transported in the AFL.MAC field according to the specification in 6.3.6. 9.3.3 Authentication method AES-GMAC-128

This authentication method is provided by the AFL with the Authentication Type AT = 8 (refer to Table 6). The MAC shall be calculated by application of the AES-GCM algorithm as specified in 9.4.7.

Initialization Vector IV

54

EN 13757-7:2018 (E)

The Initialization Vector IV to be supplied for this algorithm consists of the concatenation of a fixed field and an invocation field, where:

— the fixed field (leading 8 bytes) shall be constructed as concatenated data field values identifying hosting physically device: Fixed field = Manufacturer-ID || Identification No || Version || Device type;

— the invocation field (trailing 5 bytes) shall be an integer counter, which is the concatentation of the Message counter and the fragment identifier: Invocation field = AFL.MCR || AFL.FID.

This results in a total length of 13 bytes. Input for the algorithm

Data to be authenticated is concatenated according the following specification: AFL.MAC =

GMAC (Kmac/Lmac, AFL.MCL || {AFL.KI} || {AFL.MCR} || {AFL.ML} || First byte of TPDU (CI-field) || … || Last byte of TPDU) All multi byte fields are arranged in the same order as in the transmitted message. fields within curly braces may not be transmitted and shall be ignored during the concatenation of fields, if they are not present. The presence of the AFL.KI, AFL.MCR and AFL.ML field depends on the selection bits in the AFL.MCL field. Output of the algorithm

The 12 byte result of this GMAC-function shall not be truncated. The authentication tag corresponding to the protected data shall be transported in the AFL.MAC field according the specification in 6.3.6.

9.4 Encryption and Authentication methods in the TPL 9.4.1 Overview about TPL-Security mechanisms

This subclause describes the applicable security mechanism in the Transport Layer (TPL). The applied security mechanism in the TPL shall be identified by the configuration field (see 7.5.8).

Table 47 describes the key features for each of the Security mechanisms. The content of the different columns is as follows: —

Security Mode:

The ordinal identifier used as reference (see Table 19 in 7.5.8).

—

Mode of operation:

The way of using the specific algorithm.

— — — — —

Algorithm:

Security Service: Overhead: Keys:

MAC size:

The cryptographic algorithm used.

The capabilities of the Security mechanism regarding confidentiality, integrity, authentication and protection against replay attack (see 9.1). The number of bytes overhead in an encrypted and authenticated datagram, compared to an unsecured/plaintext message. This overhead considers also the MAC. The total number of different keys used for a single message. The size of the Message Authentication Code(s) in bytes.

55

EN 13757-7:2018 (E)

Table 47 — Security mechanisms for meter reading

none

3

DES

—

5

AES-128

CBC

8

AES-128

9

10

AES-128 AES-128 AES-128

—

X

—

X

CBC

CMACb

GCM

GCM/ GMACd

CTR

CCM

CMAC CCM

Auth.

CBC

CBC

Int.

—

Conf.

—

DES

7

a

Repl. Auth.

0 2

Security service

Algorithm Encr.

SecurityModea

Mode of operation

X

X

X

X

X

X

X

Keys

MAC size (bytes)

0

0

0

1–8

1

0

1–8

X X

Overhead (bytes)

X X

X X

X

2–17

1 1

0 0

X

3–23b

2c

2,4,8,12,16

X

18–21

1

12

X X

6–16

10–23

3 1

4+2

4,8,12,16

This table only lists Security modes which are specified by this standard. b For this Security mode the use of Authentication provided by the AFL sub-layer is recommended. This will add an additional overhead of 6 to 22 bytes to the datagram if fragmentation is used, and 11 to 29 bytes if the AFL was not already used. c Including key for authentication in the AFL d

GMAC in case of authentication only

The different Security modes are the following: — Security mode “0”

Applies when neither encryption nor authentication is performed in the Transport Layer. — Security mode “2”

This Security mode is retained for backward capability. The use of this Security mode is deprecated. — Security mode “3”

This Security mode is retained for backward capability. The use of this Security mode is deprecated.

— Security mode “5”

This is a simple Security mode, only supporting encryption. The Security mode is limited to a single persistent key per device. It does not support any key derivation method. The configuration word of this Security mode allows messages without using an ELL. NOTE

If Authentication in the AFL is enabled, the ELL is necessary.

— Security mode “7”

This Security mode is intended to be used with authentication service provided by the AFL. The key derivation function is applicable for both, encryption and authentication keys.

— Security mode “8”

56

EN 13757-7:2018 (E)

This Security mode is a compact solution that provides an authentication method suitable to ensure an end-to-end data integrity. It provides two MAC-fields to allow separate authentication checks during the transport. — Security mode “9”

This Security mode is performant by one-pass authenticated encryption/decryption.

It applies the same Security mechanisms as for DLMS/COSEM messages according to EN 62056-5-3:2014. This allows efficient operation of co-existing M-Bus applications and DLMS/COSEM applications in the same meter and in gateway applications connected to M-Bus and DLMS/COSEM meters. — Security mode “10”

This Security mode provides authenticated encryption, optimized for minimum message overhead. The verification is an integral part of the decryption.

CEN/TR 17167:2018, Annex F shows examples with both unencrypted and encrypted data for different Security mechanisms. 9.4.2 Manufacturer specific Security mechanism (Security mode 1)

The Security mode 1 can be used for manufacturer specific Security mechanisms.

9.4.3 Security mechanism DES-CBC (Security mode 2 and 3) 9.4.3.1 Encryption

Security mode 2 and 3 uses DES-CBC according to ISO 8372. DES has a key length of 64 bits, including parity bits. DES has been withdrawn as a standard. New implementations, based on DES should not be introduced. Security mode 2 uses a zero initialization vector, IV = 0 (8 bytes of 00h).

Implementations using this security mode 2 should contain the current data ahead the meter reading data in the unencrypted message. This ensures that the encrypted data holding the meter reading information changes at least once a day even if the meter index is unchanged. This prevents a later undetected replay of stored encrypted meter readings, by and adversary.

Security mode 3 uses a variable initialization vector. The initialization vector, of 8 bytes, shall consist of the identification number in the 4 lowest bytes followed by the manufacturer ID in the 2 next higher bytes and finally the current date, coded in records structure “G”, in the 2 highest bytes. This ensures that all encrypted data will change once per day event if the data content is unchanged. This prevents a later undetected replay of stored encrypted meter readings, by and adversary. The DES algorithm specifies that data are encrypted and decrypted in blocks of 8 bytes. Unencrypted data shall be padded to an 8 byte block. NOTE

The M-Bus application protocol uses as padding byte 2Fh.

9.4.3.2 Decryption

The encrypted part of the message shall contain the same identification number as present in the unencrypted part of the header. This may be within a proper application layer coding (DIF and VIF). This makes it possible to verify that the data has been correctly decrypted and that the unencrypted verification number in the header has not been modified.

57

EN 13757-7:2018 (E)

9.4.4 Security mechanism AES-CBC-128 (Security mode 5) 9.4.4.1 Encryption The Security mode 5 shall apply Cipher Block Chaining (CBC) method according to NIST/SP 800-38A.

Definitions of the configuration field are according to Table 31 in 7.7.4.

The initialization vector for Security mode 5 is given in Table 48:

Table 48 — Initialization vector of Security mode 5

15

14

Manufacturer (LSB first)

13

12

11

10

Identification number (LSB first)

9

8

7

6

5

4

3

2

1

0

Version

Dev. Type

Acc. no.

Acc. no.

Acc. no.

Acc. no.

Acc. no.

Acc. no.

Acc. no.

Acc. no.

The initialization vector always contains the address of the meter. The address elements are specified in 7.5.1 to 7.5.4.

For messages from and to the meter with long TPL-header (like CI = 5Bh or CI = 72h; see 7.4) the initialization vector shall apply address fields of the TPL-header. For messages from the meter to the communication partner using no or short TPL-header, (like CI = 7Ah; see 7.3) the initialization vector shall apply address fields of the Link Layer. Note that the order of address elements in Link layer and Transport layer differs.

Since the meter access number changes with each new transmission, the initialization vector is different in each new transmission of meter data. Due to the mathematical properties of the encryption algorithm, this changes the complete message even if the unencrypted data (e.g. the meter index) is constant (e.g. because of zero consumption) which might indicate an uninhabited apartment and might hence be some indication for possible burglars. This protection may be increased by using an additional time stamp or an incremental counter (VIFE “unique message identification”) in the first block. Due to the mathematical nature of the AES-algorithm, the length of encrypted data (provided in the configuration field) shall be an integer multiple of 16 bytes. Unused bytes in the last 16-byte block shall be filled with padding bytes to achieve the required data point boundary at the end of the encrypted data. One or several padding bytes (like padding byte 2Fh for M-Bus protocol) shall be used to fill such gaps.

Partial encryption may be used to allow unencrypted access to operational parameters. The encrypted bytes follow as zero, one or several encrypted 16-byte blocks directly after the header. Optional unencrypted bytes may follow the encrypted blocks if the Link Layer datagram length signals more bytes than the encryption length of 16*NNNNb bytes in the configuration field.

9.4.4.2 Decryption verification

In order to verify that the message is decrypted correctly, the encrypted part starts with a known sequence. The header will be expanded by decryption verification in dependency of the selected Security mode. A device supporting Security mode 5 shall start with 2 bytes of 2Fh (AES-check) before the first data record.

Since the message shall have an encrypted length of an integer multiple of 16 bytes, idle filler bytes often will also be added at the end of the last encrypted block. NOTE

58

The decryption verification is independent of the wired or wireless transmission.

EN 13757-7:2018 (E)

9.4.5 Security mechanism AES-CBC-128 (Security mode 7) 9.4.5.1 Encryption Security mode 7 uses AES-128-CBC with an ephemeral key of 128 bits and a static Initialization Vector IV = 0 (16 bytes of 0x00). The Cipher Block Chaining (CBC) method shall be according to NIST/SP 800-38A.

An ephemeral key shall be used which is generated with the Key Derivation Function (KDF) and which is described in 9.6. The KDF requires a Message counter. The KDF shall use the Message counter provided by the TPL. If no TPL counter is present (bit Z = 0 in configuration field, see Table 33) then the counter of the AFL (AFL.MCR) shall be used instead.

The data to be encrypted shall be padded to a multiple of 16 bytes before encryption. The padding can be achieved by either enabling TPL-padding (according to 9.4.5.4) or by adding suitable padding bytes within the application protocol. NOTE The padding value depends on the selected application protocol. E.g. the M-Bus application protocol uses as padding byte 2Fh.

9.4.5.2 Decryption verification

In order to verify that the message is decrypted correctly, the encrypted part starts with a known sequence. A device supporting Security mode 7 shall insert 2 bytes of 2Fh before the first plain data record. The Decryption procedure of the meter or communication partner shall verify the correct presence of this test sequence. If it fails, the decryption shall be marked as faulty. Otherwise, the decryption procedure removes the 2 byte decryption verification sequence and forward the decrypted message for further processing. 9.4.5.3 Authentication

Security mode 7 does not support an implicit Authentication method in TPL. The Authentication method of the AFL (see 9.3.2) should be used instead.

9.4.5.4 TPL-padding

If the TPL-padding is enabled in the configuration field (see 7.7.5) then 1 to 16 padding bytes will be added. The number of TPL-padding bytes shall be (16-l mod 16) bytes (but at least 1 byte), where l equals the byte length of the Application data plus the 2 bytes Decryption Verification (see 9.4.5.2).

The TPL-padding bytes shall be added directly after the encrypted application data (see Table 32). The TPL-padding bytes shall be added before the encryption is applied and they shall be removed after the message was successfully decrypted. The value of the TPL-padding bytes corresponds to the number of added TPL-padding bytes. EXAMPLE

A TPL-padding sequence of 3 bytes is: 03h 03h 03h

NOTE If the TPL-padding is enabled the last byte of the decrypted data are always a TPL-padding byte. The value of this TPL-padding byte identifies the number of bytes to be removed from the end of the decrypted data.

9.4.6 Security mechanism AES-CTR-128 (Security mode 8)

9.4.6.1 General ‘This security mode provides two authentication mechanisms MAC1 and MAC2, to ensure an end-to-end data integrity and to prevent the replay of the data over a certain period.

59

EN 13757-7:2018 (E)

a) MAC_1 provides both data integrity and authentication controls for unicast message. In addition MAC_1 allows to easily detect replay messages, even if the data are constant thanks to the Counter that is incremented at every message. It is recommended to use MAC_1 as an end-to-end security field that can be generated/checked by the meter and the information system. b) The main purpose of the optional MAC_2 is to apply first level of authentication between device and communication partner. An end-to-end authentication using MAC_1 is however necessary.

c) The key management should be handled by operators in accordance with their security policy and/or with the national security authority. Each key may be renewable.

9.4.6.2 Encryption

The message with Security mode 8 shall be encrypted with AES-CTR method according to NIST/SP 80038A. The initialization vector (also called “counter” in NIST/SP 800-38A) shall be according to 9.4.6.4. If the message contains unencrypted application data (see 7.6.5) the field Length (E) is required (configuration field bit ‘E’ = 1; see 7.7.6). Messages with encrypted data of a length greater than 254 bytes shall contain neither field Length (E) nor unencrypted application data (configuration field bit ‘E’ = 0). 9.4.6.3 Authentication

The content of Authentication Tag 1 and Authentication Tag 2 of Security mode 8 shall be calculated according to AES-CMAC method as described in NIST/SP 800-38B.

The Authentication Tag 1 (MAC_1) is calculated as follows: MAC_1 =

CMAC(Kmac_1, Manufacturer || ID Number || Version || Device Type || Message counter (4 bytes) || Padding zeros (4 bytes) || Encrypted Application Data || {Unencrypted application data}). All multi byte fields are arranged in the same order as in the transmitted message. fields within curly braces may not be transmitted and shall be ignored during the concatenation of fields, if not present.

The Message counter shall be according to 9.2.

The Authentication Tag 2 (MAC_2) is calculated as follows: MAC_2 =

CMAC (Kmac_2, Manufacturer || ID Number || Version || Device Type || Padding zeros (8 bytes) || Access Number || Status || configuration field || {configuration field Extension} || {Key Version} || {Length (E)} || Message counter || Encrypted Application Data || {Unencrypted application data} || MAC_1 || {Time Stamp of TPL-Trailer}) All multi byte fields are arranged in the same order as in the transmitted message. fields within curly braces may not be transmitted and shall be ignored during the concatenation of fields, if not present.

MAC_1 and MAC_2 shall be calculated with same address elements as used for the initialization vector (see 9.4.6.4).

Kmac_1 and Kmac_2 are authentication keys and shall be different for MAC_1 and MAC_2 calculation. Key derivation shall not be applied for Kmac2.

Messages which use a multicast or broadcast address shall not apply Transmission Time stamp with Authentication Tag 2 (configuration field bit ‘O’ = 0).

9.4.6.4 Defining CTR Initialization Vector

The initialization vector shall be according to Table 49.

60

EN 13757-7:2018 (E)

Table 49 — Structure of Initialization vector in security mode 8 15

14

Manufacturer (LSB first)

13

12

11

10

Identification number (LSB first)

9

8

Versio n

Dev. Type

7

6

5

Message counter (MSB first)

4

3

2

00h

00h

1

0

Block counter (MSB first)

There are two counters, the message counter and the block counter. The message counter shall be used according to 9.2. If the message counter size is smaller than 4 bytes (see 7.7.6), then the most significant byte(s) shall be filled with 0. The block counter shall be initialized with 0 and shall be incremented according to NIST/SP 800-38A. NOTE In deviation to common rules the message counter and the Block counter are coded in initialization vector with the most significant byte first.

The address elements are specified in 7.5.1, 7.5.2, 7.5.3 and 7.5.4.

For messages from the meter to the communication partner which use a short TPL-header (like CI = 7Ah; see 7.3), the initialization vector shall apply address fields of the Link Layer. For messages from and to the meter with long TPL-header (like CI = 5Bh or CI = 72h; see 7.4) the initialization vector shall apply address fields of the Transport Layer. Note that the order of address elements in the Link Layer and the Transport Layer differs. 9.4.7 Security mechanism AES-GCM-128 (Security mode 9) 9.4.7.1 Overview In general NIST/SP 800-38D applies to Security mode 9.

Galois/Counter Mode (GCM) is an algorithm for authenticated encryption with associated data. GCM is constructed from an approved symmetric key block cipher with a block size of 128 bits, such as the Advanced Encryption Standard (AES) algorithm (according to ISO/IEC 18033-3). Thus, GCM is a mode of operation of the AES algorithm. The two functions that comprise GCM are called authenticated encryption and authenticated decryption; see Figure 1.

61

EN 13757-7:2018 (E)

Key F1

AES Galois/Counter Mode authenticated encryption function

P

plaintext (data to encrypt)

F2 A

K I

C

T F

AES Galois/Counter Mode authenticated decryption function data to authenticate only GCM-key

initialization vector encrypted data

authentication tag

fail, special error code

Figure 1 — GCM algorithm input and output

Table 50 reflects the GCM algorithm input and output details for GCM authenticated encryption and authenticated decryption function, given the selection of a block cipher key. Table 50 — GCM functions input and output details

GCM function

Authenticated encryption

Authenticated decryption a

b c

d e

62

Algorithm input P — plaintext (data to encrypt)a, b A — data to authenticate onlya, c I — initialization vector C — encrypted data

T — authentication tag

A — data to authenticate only

Algorithm output C — encrypted datad

T — authentication tag P — plaintext(data to encrypt)b, e F — special error codee

I — initialization vector

The bit lengths of the input strings shall all be multiples of 8, so that these values are byte strings. The plaintext data contains the part of application data that is sent encrypted.

The data to authenticate only contains parts of TPL and the part of application data that is sent unencrypted.

The length of the output string is the same as of the input string.

In case of algorithm failure the output is a special error code instead of the plaintext.

EN 13757-7:2018 (E)

9.4.7.2 Encrypted data Encrypted data are the data to be both encrypted and authenticated.

The length of encrypted data E in bytes is specified by the Length (E) field, capable for a maximum length of 255 bytes or 65535 bytes acc. the format as specified in the configuration field CF. F1 − algorithm input (P) 1) = plaintext 2)

All multi byte fields are arranged in the same order as in the transmitted message. 9.4.7.3 Unencrypted data

Unencrypted data are the data to be authenticated, but not to be encrypted.

The length of unencrypted application data U in bytes is specified by the Length (U) field, capable for a maximum length of 255 bytes or 65535 bytes acc. the format as specified in the configuration field CF.

Data to be only authenticated (U) shall be concatenated according the following specification as input for the algorithm: CI-field || Access-No || Status || Config. field CF || {Key Version} || Length (E) || Length (U) || Unencrypted application data All multi byte fields are arranged in the same order as in the transmitted message. fields within curly braces may not be transmitted and shall be ignored during the concatenation of fields, if not present. F1 − algorithm input (A)1) =

9.4.7.4 Authentication tag

The byte length of the authentication tag is a security parameter and its value shall be 12 bytes. The authentication tag corresponds to the protected data C and A.

The F1-algorithm output (T)1) is applied in Authentication tag of TPL (see 7.7.7).

The authentication tag of a received message shall be verified before further processing of the message. 9.4.7.5 Defining GCM key

For the GCM specification refer to NIST/SP 800-38D:2007-11, 8.1. NOTE

GCM uses one common block cipher key for both encryption and authentication.

The key length in this mode shall always be 128 bit.

The GCM-key K is identified by the “Key ID”-subfield and the “KDF-Selection” subfield of the configuration field (see Table 39).

9.4.7.6 Defining GCM Initialization Vector

The initialization vector IV is essentially a nonce, i.e. a value that is unique within the specified (security) context, which determines an invocation of the authenticated encryption function on the input data to be protected.

In Security mode 9, for the construction of the initialization vector IV deterministic construction as specified in NIST/SP 800-38D:2007-11, 8.2.1 shall be used: The IV is the concatenation of two fields, called the fixed field and the invocation field. The fixed field shall identify the physical device or, more 1) See key in Figure 1.

2) See Table 50.

63

EN 13757-7:2018 (E)

generally, the (security) context for the instance of the authenticated encryption function. The invocation field shall identify the sets of inputs to the authenticated encryption function in that particular device. For any given key, no two distinct physical devices shall share the same fixed field, and no two distinct sets of inputs to any single device shall share the same invocation field. The length of the IV shall be 12 bytes.

Within this:

— The leading (i.e. the leftmost) 8 bytes shall hold the fixed field. It shall be constructed as concatenated data field values identifying hosting physically device: Fixed field = Manufacturer-ID || Identification No || Version || Device type;

— The trailing (i.e. the rightmost) 4 bytes shall hold the invocation field. The invocation field shall be an integer counter, which is related to the Message counter (see 9.2).

The bit length of the fixed field limits the number of distinct physical devices that can implement the authenticated encryption function for the given key to 264. The bit length of the invocation field limits the number of invocations of the authenticated encryption function to 232 with any given input set without violating the unique requirement. Table 51 — Structure of Initialization vector in Security mode 9 Fixed field 11

10

9

Manufacturer (LSB first)

8

7

Identification number (LSB first)

Invocation field 6

5

4

Version

Device type

3

2

1

0

Message counter (MSB first)

The address elements of the fixed field are specified in 7.5.1, 7.5.2, 7.5.3 and 7.5.4.

9.4.7.7 Reaction to algorithm fail

In the case of F2-algorithm output (F) 3) = ‘fail’, the reaction shall follow the rules described in 9.5.

9.4.8 Security mechanism AES-CCM-128 (Security mode 10) 9.4.8.1 General

This method uses a mode of operation, called CCM, defined for a symmetric key block cipher algorithm. CCM is used to provide assurance of the confidentiality and the authenticity of data by combining the techniques of the Counter mode and the Cipher Block Chaining-Message Authentication Code (CBCMAC) algorithm.

The CCM mode shall be implemented as defined in the NIST recommendations for block cipher modes of operation, according to NIST/SP 800-38C. This method uses the CCM mode with the AES128 block cipher algorithm. The structure of a message with Security mode 10 applied is shown in Table 40.

The configuration field for this Security mode is specified in 7.7.8. NOTE 1

Adding of padding bytes is not needed when using this security mechanism.

3) See key in Figure 1.

64

EN 13757-7:2018 (E)

NOTE 2 Idle filler bytes (2Fh) are not used with this security mechanism for decryption verification. The authentication tag verifies the decryption.

9.4.8.2 CCM-Counter

The CCM Counter uses the Message counter from the message as specified in 9.2.

It shall use the Message counter provided by the TPL. If no TPL counter is present (bit Z = 0 in configuration field; see 7.7.8) then the Message counter of the AFL (AFL.MCR; see 6.3.5) shall be used instead. 9.4.8.3 Authentication tag

The length of the authentication tag is defined by the OO-subfield of the configuration field extension (see 7.7.8).

9.4.8.4 Encrypted data

The encrypted data are the data to be both encrypted and authenticated. The length of the encrypted data are defined by the N-subfield of the configuration field (see 7.7.8).

9.4.8.5 Unencrypted data

The unencrypted data are the data to be authenticated but not encrypted. The unencrypted data are all the remainder of the Application Layer after the encrypted data (see 7.7.8). 9.4.8.6 Defining CCM key

For the CCM specification refer to NIST/SP 800-38C:2004-05, Clause 6.

The CCM-key, K, is defined by the “Key ID”-subfield and the “KDF-Selection”-subfield of the configuration field. In case that the key selection specifies separate keys for authentication and encryption, the encryption key shall be used for the security mechanism CCM. The key length, Klen, shall always be 128 bit. If an ephemeral key is used the KDF shall apply the Message counter in TPL (see 7.7.8).

If no TPL counter is present (bit Z = 0 in configuration field; see 7.7.8) then the Message counter of the AFL (AFL.MCR; see 6.3.5) shall be used instead. 9.4.8.7 Defining CCM payload data

For the CCM specification refer to NIST/SP 800-38C:2004-05, Clause 6. The payload, P, is set to the encrypted data defined in 9.4.8.4. 9.4.8.8 Defining CCM associated data

For the CCM specification refer to NIST/SP 800-38C:2004-05, Clause 6.

The associated data, A, is set to the concatenation of the CI-field, the TPL-Header and the unencrypted data, defined in 9.4.8.5. A=

(CI-field || Access No. || Status || Config. field (CF) || Config. field extension (CFE) || {Key Version} || Unencrypted application data) All multi byte fields are arranged in the same order as in the transmitted message. Optional fields defined in curly braces “{ }” are included only if contained in the message.

NOTE Only selected parts of the TPL-header is included in the associated data as specified above. Other fields like address and Message counter are instead included in the CCM nonce (see 9.4.8.9).

65

EN 13757-7:2018 (E)

9.4.8.9 Defining CCM nonce For the CCM specification, refer to NIST/SP 800-38C:2004-05, Clause 6.

The length, n, of the nonce, N, is fixed to 13 bytes. The nonce is specified in Table 52. Table 52 — Structure of the nonce, N

12

11

Manufacturer (LSB first)

10

9

8

7

Identification number (LSB first)

6

5

4

Version

Device type

00h

The counter shall be set to the CCM counter specified in 9.4.8.2.

3

2

1

0

CCM counter (MSB first)

If the application layer contains a long TPL-header the address-fields (Identification number, Manufacturer, Version and Device type) of the nonce shall be set to the address-fields from the TPLheader. In other cases the address-fields of the nonce shall be set to the address-fields from the Link Layer.

NOTE 1 The meter address is located in the Link Layer of messages transmitted in the direction from meter to communication partner and in the Extended Link Layer of messages transmitted in the direction from communication partner to meter. Refer to EN 13757–4.

NOTE 2 The address fields of the Link Layer Address and the Application Layer address are not structured in the same order.

9.4.8.10 CCM formatting and counter generation function

For the CCM formatting and counter generation function refer to NIST/SP 800-38C:2004-05, Annex A. For the use of this standard, the following conditions are set. — Length of tag-field, t, is an element of {4, 8, 12, 16} bytes as described in 7.7.8.

— Length of length-field, q, is fixed to 2 bytes. — Length of nonce, n, is fixed to 13 bytes. 9.4.8.11 Reaction to authentication fail

In case of an authentication failure, the reaction shall follow the rules described in 9.5.

9.5 Reaction to security failure

If a meter receives a message during a communication session that fails of the counter check, the Authentication check or the Decryption verification the message shall be rejected. In this case the meter shall prepare an Application error “Security error” or “Security mechanism not supported” (according to EN 13757-3:2018, Table 21) as response. This response of application errors should be transmitted unencrypted.

NOTE The application error response will be transmitted only if the meter receives a REQ-UD2 or SND-UD2 from the communication partner.

It is recommended that, if a wireless meter receives several messages during a communication session that fail one of the security checks, it informs its lower protocol layers to interrupt the current communication session (by disabling the accessibility — see EN 13757-4). In this case a new session can be initiated again after the next unsolicited meter transmission.

66

EN 13757-7:2018 (E)

If the communication partner receives a message during normal reception of unidirectional meter transmissions that fails one or more of the security checks, the complete message shall be treated by silent discard and the failure information should be indicated to the system for monitoring.

9.6 Key derivation 9.6.1 General

The encryption and authentication of application data may be based on an ephemeral key. The ephemeral key shall be generated using the Key Derivation Functions defined below.

Key derivation functions are used to derive an ephemeral key from a persistent key. For that reason, it uses at least one dynamic input value to generate always a new ephemeral key with each function call.

The usage of an ephemeral key is indicated in the subfield DD of the configuration field respectively configuration field extension (see 7.7.1). NOTE

Not all Security Modes support the usage of ephemeral keys.

9.6.2 Key derivation function A 9.6.2.1 General

The Key Derivation Function shall apply the CMAC-Function according to NIST/SP 800-38B.

NOTE

This Key Derivation Function bases on key expansion procedure of NIST/SP 800–56C.

There are five input values to the KDF A, specified in the following subclauses.

9.6.2.2 Message Key (MK)

Before each transmission an ephemeral key for encryption or authentication are derived from the individual persistent message key MK. NOTE

The number of used keys depends on security mechanisms applied in AFL or TPL.

9.6.2.3 Derivation Constant (DC)

There are two sets of key pairs (one set for the meter Kenc/Kmac and one set for the communication partner Lenc/Lmac). The Derivation constant DC is used to derive different keys for both encryption and authentication as well as for the two directions - from and to the meter. See Table 53 for values of Derivation constant DC. Table 53 — Constant DC for the key derivation

Sequence

Applicable key

00h

Encryption from the meter (Kenc)

10h

Encryption from the communication partner (Lenc)

01h 11h

MAC from the meter (Kmac)

MAC from the communication partner (Lmac)

9.6.2.4 Message counter (C)

The Message counter shall be applied according to 9.2. It is transported either in the AFL (see 6.3.5) or in the TPL (see 7.7.5 to 7.7.8). If the counter has less than 4 bytes the counter bytes are used for the least significant bytes. The missing most significant bytes shall be filled with 00h.

67

EN 13757-7:2018 (E)

9.6.2.5 Meter-ID (ID) For messages from the meter to the communication partner which use a short TPL-header, (like CI = 7Ah; see 7.3) the ID corresponds to the Identification Number in the Link Layer Address (see 8.3) of the meter. For messages with long header (like CI = 72h; see 7.4) the ID corresponds to the Application Layer Identification Number (see 7.5.1) of the meter.

For messages from the communication partner to the meter the Long Header is always used. The ID corresponds to the Identification Number in the Application Layer Address (see 7.5.1) of the meter (not the communication partner). 9.6.2.6 Padding

The remaining bytes of the 16 byte block are filled with a padding sequence. For the generation of Kmac, Lmac and Kenc, Lenc the padding is fixed and consists of seven octets each containing the value of 0x07 according to the rule that the input to the MAC shall be padded with 0x(16-l mod 16) bytes with value 0x(16-l mod 16), where l equals the byte length of the input. 9.6.2.7 Key calculation

The calculation of key K shall be as follows:

K = CMAC(MK, DC || C || ID || 07h || 07h || 07h || 07h || 07h || 07h || 07h)

where

MK is Message key;

DC is Derivation constant; C

is Message counter;

ID is Meter ID.

Multi byte fields C and ID are arranged in the same order as in the transmitted message. K can be Kenc, Kmac, Lenc, Lmac depending on selected Derivation constant.

9.7 Key Exchange

If the communication partner need to change keys of the meter, the Security information transfer protocol shall be used. See Annex A for details.

68

EN 13757-7:2018 (E)

Annex A (normative)

Security Information Transfer Protocol A.1 Introduction This specific application protocol is intended for all kind of security information handling and management of security relevant services in a metering system. The main use case is to update key information. Handling of security information requires bidirectional access to the device. In detail the SITP provides the following services: — Transfer security information (to meter) — Activate security information

— Deactivate security information

— Combined activation/deactivation of security information

— Generate security information

— Get security information (from meter)

— Get list of all security information (from meter)

— Get list of active security information (from meter)

— Transfer end to end secured application data

The usage of this upper layer protocol is introduced with a specific sub-range of CI-fields. It is therefore independent from the M-Bus Application Layer protocol. Examples which show the usage of the SITP are provided in the CEN/TR 17167:2018, F.7.

A.2 SITP Services

A.2.1 Transfer security information The purpose of this service is to transfer security information (e.g. security keys) from a communication partner to a device in a secure way. The security information itself is often generated by a backend system and not by the communication partner. This service provides, in addition to security service from the lower layers a wrapping mechanism. The wrapping mechanism ensures a strong binding between the key and the set of data specifying the use of the key. The transferred security information contains a target time that gives an absolute or relative timestamp of usage. The target time may as well be given by the separate activation or deactivation service described below.

NOTE This service gives no advice on how to handle existing security information when new information is received. Such handling is a part of the security policy of the whole system.

69

EN 13757-7:2018 (E)

A.2.2 Activate security information The purpose of this service is to activate prior transferred security information (e.g. activate a security key) or to activate one of several keys which were inserted into the meter at production site (identified by the Key ID). The activation can be done immediately, i.e. when the command is received, or as defined by absolute or relative target time information.

A.2.3 Deactivate security information

The purpose of this service is to deactivate specific security information formerly used by the meter. This is helpful in case of overlapping validity periods for security information or especially for several versions of one specific security information. This enables a design, which holds the current key as backup until the use of the new key is proved successful by the communication partner or the backend system. Once the functionality is ensured the communication partner can deactivate the (old) security information without any risk. This can be done immediately, i.e. when the command is received, or as defined by absolute or relative target time information. NOTE This service gives no advice how to handle the deactivated security information in the meter. Whether or not this information shall be deleted (see A.2.4) is a part of the security policy of the whole system.

A.2.4 Destroy security information

The purpose of this service is to destroy (and delete) specific security information formerly used by the meter. It avoids possible security issues with old security information material. The meter shall not allow destroying active security information.

A.2.5 Combined activation/deactivation of security information

The purpose of this service is to combine the action of activation and deactivation. It is needed in case of a “Message counter sharing” between an old and a new key. As a new key may require a reset of the Message counter the old key cannot be used with this counter value zero anymore. To avoid security issues in that situation both actions have to take place simultaneously.

A.2.6 Generate security information

The purpose of this service is to instruct the meter to create security information. The security information can be requested by a separate command.

A.2.7 Get security information

The purpose of this service is to get single security information from the meter. This can be used to ask for the applied Key ID, Key Version of this device.

A.2.8 Get list of all key information

The purpose of this service is to get a list of all used Key ID's and the available Key versions stored in a device.

A.2.9 Get list of active key information

The purpose of this service is to get a list of Key ID's and Key Versions, which are currently activated.

A.2.10 Transfer end to end secured application data

The purpose of this service is to securely transfer an application layer protocol message between a remote command initiator and a meter. The application data are integrity and maybe privacy protected by usage of a key which is only known to the meter and the command initiator. An intermediary will not

70

EN 13757-7:2018 (E)

be able to alter this message as the end parties are able to detect this modification. This allows an end to end secured transfer of critical commands or critical data.

A.3 CI-Fields

Commands and responses for the Security Information Transfer Protocol are identified by specific values of the CI-field. The applicable CI-fields are listed in the Table A.1: Table A.1 — Security Information Transfer Protocol CI-fields

CI-field

Designation

Header

Remarks

C3h

Command to device

Long

Security Information Transfer Protocol

C5h

Response from device

Long

Security Information Transfer Protocol

C4h

Response from device

A.4 SITP structure

Short

Security Information Transfer Protocol

The SITP structure is implemented as APL data (see EN 13757-7:2018, Table 10). It provides the possibility to transfer multiple blocks of security information in one message. Each block contains a single SITP-command or -response (see Table A.3). The block is identified by a Block ID which shall be used for a correlation between commands and responses. The function of each block is specified by the Block Control Field. Each command and each response shall have a principal structure as depicted in the table below: Table A.2 — Internal Block structure of SITP

Block length (BL)

Block ID field (BID)

Block control field (BCF)

Block parameters

2 bytes

1 byte

1 byte

n bytes

The elements are: Block length:

BL, Length of this block including BID, BCF and all block parameters (LSB first) BL = 0 signals no more blocks to follow

Block control field:

BCF, coding of the usage of this command or response, see Table A.3

Block ID field:

BID, Identifier of this block, start with first block BID = 0

Block parameters: Variable parameters depending on the BCF, see A.6 Block length is a multi byte field. Block parameters may also contain multi byte fields. If nothing else is declared then multi byte fields shall be transmitted with the least significant byte first (little endian).

A.5 Block Control Field

The block control field gives the function of the block and shall have one of the listed values for Command or Response as shown in the table below. There is a fixed relation between a certain command and its assigned response, e.g. Command 01h requires a Response with 81h.

71

EN 13757-7:2018 (E)

Table A.3 — Block Control Field Command

Applicable DSI

00h

01h

02h

02h

01h

02h

03h

09h to 1Fh

00h

22h

Get list of active key information (see A.2.9)

30h to 37h

70h to 7Fh

F0h to FFha

a

82h

Get list of all key information (see A.2.8)

20h

21h to 6Fh

Deactivate security information (see A.2.3)

Get security information (see A.2.7)

00h

08h

22h

Generate security information (see A.2.6)

00h

07h

80h

Combined activation/deactivation of security information (see A.2.5)

02h

06h

Transfer security information (see A.2.1)

Destroy security information (see A.2.4)

03h

05h

Applicable DSI

Activate security information (see A.2.2)

02h

04h

Response

Function

81h 83h 84h 85h

22h

88h

21h, 22h

87h

Reserved for future use

A1h to EFh

All other DSI can be used as well

22h 01h, 22h

89h to 9Fh

Manufacturer specific usage

22h

86h

Reserved for future use

Transfer end to end secured application data (see A.2.10)

22h

20h, 22h

A0h

22h, 30h to 37h

F0h to FFh

F0h to FFha

A.6 Block parameters

The structure of the block parameter is defined in Table A.4. It is applied for all SITP Commands and Responses. In case of status responses this structure is also used but the data structure content will be different (see Table A.5).

The structure is designed to transport applicative data in the “Data structure content”. The other fields serve as organisational and introductive information. The Recipient ID and the DSH shall have the same values in a command and the respective response. This is essential for a correct assignment of the response by the command initiator. Table A.4 — Block parameter structure

72

Recipient ID

Data structure identifier (DSI)

1 byte

1 byte

Data structure header (DSH) DSH1

DSH2

1 byte

1 byte

Data structure content n bytes

EN 13757-7:2018 (E)

Recipient ID:

Identifier of the application. Set to 00h if no dedicated application is addressed.

Data structure identifier:

DSI, identifying the applied data structure declared in Table A.5

Data structure header:

Data structure content:

NOTE For example to address the gateway function in a combined electricity meter. In the TCP world this would be the port number.

DSH introduces the data structure. Its meaning depends on the data structure identifier. DSH1 and DSH2 are autonomous 1-byte fields as shown in Table A.5. Structured security information according to A.7

A.7 Overview about Data Structures / Mechanisms

This Clause informs about the data structures, the applied mechanisms and the usage of the DSH. The “data structure content” as shown in Table A.4 is provided in the dedicated sub clauses.

There are two different groups of data structures defined which can be seen in Table A.5. One group is mainly intended for handling and management of security information and their relevant services (DSI 00h to 2Fh, see Data structures for Security Information). The other group is defined for the use case of secured application data transfer (DSI 3xh, see Data structures for secured application data). Table A.5 shows the list of data structures / mechanisms, the usage of DSH and the applicable BCF values. Details about the DSH values can be found below the Table. Table A.5 — List of SITP data structures/mechanisms

Data Structure identifier (DSI)

Data structure header (DSH)

Data Structure/Mechanism

DSH1

00h

Empty structure / no wrapping (see A.8.2)

02h

Wrapping AES-128 according NIST/SP 800–38F Wrapper Key ID type KWP (see A.8.4)

01h 03h

04h to 0Fh

10h to 19h 1Ah to 1Fh 20h 21h 22h

23h to 2Fh

Key ID

Wrapping AES-128 according NIST/SP 800–38F Wrapper Key ID type KWP (see A.8.3) Wrapping AES-128 according NIST/SP 800–38F Wrapper Key ID type KWP (see A.8.5) Reserved for future use Reserved for according [8]

asymmetric

technologies

Reserved for asymmetric technologies

n/a n/a n/a

All Keys structure wrapped with AES128 according NIST/SP 800–38F type KWP (see Wrapper Key ID A.8.6) Active Keys structure (see A.8.7)

unuseda

Reserved for future use

n/a

Status Response structure (see A.8.8)

Key IDb

DSH2 Key Version

Wrapper Key Version

Wrapper Key Version Wrapper Key Version n/a n/a n/a

Wrapper Key Version unuseda

Key Versionb n/a

73

EN 13757-7:2018 (E)

Data Structure identifier (DSI)

Data structure header (DSH)

Data Structure/Mechanism

DSH1

DSH2

30h

Wrapping AES-128 according to NIST/SP 800–38F Wrapper Key ID type KWP (see A.9)

Wrapper Key Version

32h

Authentication with (8 byte MAC, see A.9.4)

Wrapper Key Version

31h 33h 35h

Authentication with (16 byte MAC, see A.9.4)

Wrapper Key ID

AES128-CMAC

encryption

with

Authenticated encryption (8 byte MAC, see A.9.6)

with

AES128-CMAC AES128-GCM

Authentication with AES128-GMAC (see A.9.5)

36h 37h

38h to EFh F0h to FFh b

Wrapper Key ID

Authenticated (see A.9.5)

34h

a

Authentication with HMAC-SHA256 (see A.9.3)

Authenticated encryption (16 byte MAC, see A.9.6) Reserved for future use

with

AES128-CCM AES128-CCM

Manufacturer specific

Set unused fields to FFh.

Wrapper Key ID

Wrapper Key ID Wrapper Key ID Wrapper Key ID Wrapper Key ID n/a n/a

Wrapper Key Version Wrapper Key Version Wrapper Key Version Wrapper Key Version Wrapper Key Version Wrapper Key Version n/a n/a

The same DSH value than used in command.

Contents of data structure header (DSH): Wrapper Key ID:

Wrapper Key Version: Key ID:

Key Version:

ID of the key used for wrapping or authentication according the Key ID definition. If not used (no wrapping applied) set to FFh. Note that only Key ID's in the range from 00h to 0Fh are used for TPL-security (see Table 24). Wrapper keys used for the APL-security should use a Key ID larger than 0Fh. Version of the key used for wrapping. If not used set to FFh. The ID of the intended key. If not used set to FFh.

The version of the intended Key ID. If not used set to FFh.

A.8 Data structures for Security Information A.8.1 General

The data structures for Security Information are applicable to certain BCF commands and responses (BCF 00h to 1Fh and 80h to 9Fh; as shown in last column of Table A.5). The response to a command will either be a special data structure with the requested data content (like data structure 01h or 21h) or a SITP status response (with data structure 22h). The SITP status response contains the state of command execution.

74

EN 13757-7:2018 (E)

A.8.2 Data Structure 00h This data structure contains no data (n = 0). It can be used to request security information from a meter. Only the Key ID and the Key Versions are transferred (as DSH) to select the concerning security information. This structure is not wrapped / protected as the Key ID's and Key Versions are transferred in clear text in normal communication anyway.

If this data structure is used with BCF = 07h/08h the DSH values for Key ID and Key Version shall be FFh (unused).

A.8.3 Data Structure 01h

The wrapped data structure 01h uses a 32 bytes data structure shown in Table A.6. It shall be used for transport of symmetrical 128 bit keys and the corresponding set of data specifying the use of the key. Table A.6 — Wrapped data structure 01h

ICV

MLI

Key

Target Time

Key ID

Key Version

Padding

4 bytes

4 bytes

16 bytes

5 bytes

1 byte

1 byte

1 bytes

The different elements are: ICV:

4 bytes integrity check value defined as: A65959A6h

Key:

16 bytes, AES-128 key to be wrapped with MSB first

MLI:

Target Time: Key ID:

Key Version: Padding:

4 bytes Message Length Indicator (unsigned integer, MSB first) covering the size of plaintext (all shaded fields) without padding bytes (for this fixed structure: 00000017h) NOTE The security mechanism will normally apply the Key as transmitted means with MSB first.

5 bytes timestamp according EN 13757–3:2018, Annex A, Type M (LSB first; X = 40 bits)

1 byte Key Identifier, as identified in CF or CFE. Shall be FFh if no Key Identifier is used 1 byte Key Version, as identified in CF or CFE. Shall be FFh if no version is used 1 padding bytes with 00h

A.8.4 Data Structure 02h

The wrapped data structure 02h uses a 16 bytes data structure shown in Table A.7. It shall be used for activation, deactivation, generation and destroying of an identified key. Table A.7 — Wrapped data structure 02h

ICV

MLI

Target Time

Key ID

Key Version

Padding

4 bytes

4 bytes

5 bytes

1 byte

1 byte

1 bytes

The different elements are: ICV:

MLI:

4 bytes, integrity check value defined as: A65959A6h

4 bytes, Message Length Indicator (unsigned integer, MSB first) covering the size of plaintext (all shaded fields) without padding bytes (for this fixed structure:

75

EN 13757-7:2018 (E)

00000007h)

Target Time:

5 bytes timestamp according EN 13757–3:2018, Annex A, Type M (LSB first; X = 40 bits)

Key ID:

1 byte Key Identifier, as identified in CF of CFE. Shall be FFh if no Key Identifier is used

Key Version:

1 byte Key Version, unsigned char, Shall be FFh if no version is used

Padding:

1 padding bytes with 00h

A.8.5 Data Structure 03h

The wrapped data structure 03h uses a 24 bytes data structure shown in Table A.8. It shall be used for the combined activation and deactivation of two identified keys. Table A.8 — Wrapped data structure 03h

ICV

MLI

Target Time

Activated Key ID

Activated Key Version

Deactivated Key ID

Deactivated Key Version

Option

Padding

4 bytes

4 bytes

5 bytes

1 byte

1 byte

1 byte

1 byte

1 byte

6 bytes

The different elements are: ICV:

4 bytes, integrity check value defined as: A65959A6h

Target Time:

5 bytes timestamp according EN 13757–3:2018, Annex A, Type M (LSB first; X = 40 bits)

MLI:

4 bytes, Message Length Indicator (unsigned integer, MSB first) covering the size of plaintext (all shaded fields) without padding bytes (for this fixed structure: 0000000Ah)

Activated Key ID: 1 byte Key Identifier of the key to be activated Activated Version:

Key 1 byte Key Version of the key to be activated. Shall be FFh if no version is used

Deactivated Key 1 byte Key Identifier of the key to be deactivated ID:

Deactivated Key 1 byte Key Version of the key to be deactivated. Shall be FFh if no version is used Version: Option:

1 byte value defining the options to be performed along with the command according Table A.9: Table A.9 — Options for Wrapped data structure 03h

Bit 7 to 1

Padding:

76

0

Option name Reserved

Message counter reset

6 padding bytes with 00h

Value and meaning — 0: 1:

no Message counter reset perform a Message counter reset

EN 13757-7:2018 (E)

A.8.6 Data Structure 20h This data structure is used to report all active keys or those which are available for activation (new keys). Deactivated (old) key versions will not be transferred. Only the Key ID's and the Key Versions will be transferred, not the keys itself. This structure provides the possibility to transport all Key Versions of each Key ID in a wrapped/protected container. The length of the whole structure is variable as the number of Key ID's and Key Versions is not defined as shown in Table A.10. Table A.10 — All Keys Wrapped data structure 20h

ICV

MLI

Key ID

Number of Key Versions for Key ID

First Key Version of Key ID

Next Key Versions of Key ID

Last Key Version of Key ID

4 bytes

4 bytes

1 byte

1 byte

1 byte

x bytes

1 byte

…

…

…

…

…

1 byte

1 byte

1 byte

1 byte

The different elements are:

1 byte 1 byte

x bytes

x bytes

Padding

1 byte 1 byte

m bytes

ICV:

4 bytes integrity check value defined as: A65959A6h

Key ID:

1 byte value of the reported Key ID. Only Key ID's which has any Key Version shall be given here

MLI:

4 bytes Message Length Indicator (unsigned integer, MSB first) covering the size of plaintext (all shaded fields) without padding bytes

Number of Key Versions for Key ID: Key Version of Key ID:

1 byte number which counts all versions of this Key ID, e.g. if there are eight keys preloaded for a specific Key ID provide the number “8” in this field and use the next eight bytes to show the Key Versions of those keys 1 byte Key Version for each key assigned to this Key ID. If only one Key Version is available for this Key ID omit the Next- and Last Key Version bytes in this line

Padding:

m padding bytes with 00h, where m = 7 − ((MLI − 1) mod 8)

A.8.7 Data Structure 21h

This data structure is used to report the currently active keys of a meter. Only the Key ID's and the Key Versions will be transferred, not the keys itself. This structure provides the possibility to transport one (the active) Key Version of each Key ID. It is not wrapped/protected as the active Key ID's and Key Versions are transferred in clear text in normal communication anyway. The length of the whole structure is variable as the number of used Key ID's is not defined as shown in Table A.11 (the maximum length is 256 * 2 bytes). Table A.11 — Active Keys data structure 21h Key ID

Key Version

1 byte

1 byte

1 byte

1 byte

…

…

77

EN 13757-7:2018 (E)

Key ID: 1 byte value of the reported Key ID. Only Key ID's which has an active Key Version shall be given here. Key Version: 1 byte Key Version for the active Key Version of this Key ID. If no key versioning used set to FFh.

A.8.8 Data Structure 22h

This data structure is used to report status information. It can be applied for responses only and will inform about the success or error in applying the command. It is a single byte structure like shown in Table A.12. Table A.12 — Status response structure Status Response 1 byte

Table A.13 — Status response byte definition Status response byte

Explanation

00h

Successful SITP command

02h to 07h

Reserved for status information (no error)

01h 08h

09h to 0Fh 10h

11h to 13h 14h 15h 16h 17h 18h 19h

1Ah to 1Fh 20h 21h 22h 23h 24h

78

Command successfully scheduled at target time SITP application busy

Reserved for status information (no error) Unspecified SITP error

Reserved for data structure header errors Unknown recipient ID

DSI error: Unknown data structure (DSI)

DSI error: Mismatch command (BCF) and data structure (DSI) DSI error: Mismatch DSI and data structure content

DSH error: Unknown or invalid wrapper Key ID/Version) DSH error: Unknown or invalid Key ID/Version Reserved for data structure header errors

Data structure content error: Unspecified error in data content

Data structure content error: Unknown or invalid Key ID/Version

Data structure content error: Action is not allowed for the active key Data structure content error: Target time error

Data structure content error: Key counter error

EN 13757-7:2018 (E)

Status response byte

Explanation

25h

Data structure content error: Unwrapping fails (ICV check failed)

27h

Data structure content error: Unknown or invalid protocol identifier (PID)

26h 28h to 2Fh 30h to 7Fh 80h to 8Fh

90h to DFh E0h to FFh

Data structure content error: MAC error

Reserved for data structure content errors Reserved for future Use

Reserved for asymmetric usage Reserved for future Use

Manufacturer specific usage

A.9 Data structures for secured application data A.9.1 General The data structures for secured application data transfer are applicable to the specific BCF command 20h and the response A0h. The response shall therefore either be one of those structures (30h − 37h) or a SITP status response (data structure 22h). The SITP status response is responded in case of

— a delayed command (using field Target time — see status response codes 01h in Table A.13),

— problems with the DSI or DSH (see status response codes 10h − 1Fh in Table A.13) or

— problems with the data structure content (see status response codes 20h − 2Fh in Table A.13).

In case of a successful delivered command (without delayed execution using Target Time) the applicative content (APDU’s of structures 30h − 37h) in the response shall contain either — the requested Application data (e.g. selected M-Bus data like “Get valve state”) or

— the standard response (if no data were requested like response to command “set cut-off date”) or

— an Application error if an failure was happened during command interpretation or execution (see EN 13757-3:2018, Clause 10 or using another application protocol see EN 13757-3:2018, Clause 10). The responses are also end-to-end protected using the same data structures (data structures 30h to 37h) as in the corresponding requests. The Key counter and Target Time (as well as Recipient ID, Key ID and Key Version — see A.6) of a response shall be the same as in the request. This will allow the command initiator to match outstanding commands with the responses. All data structures in the following sub clauses supports these fields: Key counter:

The Key counter is used together with the Key ID for the identification of a secured command and it's concerning response. This counter is managed by the command initiator. The meter shall store a copy of the received Key counter for each activated Key ID. If a message is received

79

EN 13757-7:2018 (E)

with a Key counter equal or smaller than the last stored one, the meter shall discard the command and indicate the Key-counter error by a SITP status response (see A.8.8). The Key counter shall use 0 as initial value. If the Key for this Key ID is changed the concerning Key counter should be reset to the initial value. The Key counter is transmitted with LSB first (little endian).

Target Time:

5 bytes timestamp according EN 13757–3:2018, Annex A, Type M (LSB first with X = 40 bits). In case the meter is able to correctly unwrap the security container, it shall schedule to execute the APL command at the time indicated by the Target Time field.

PID:

The Protocol Identifier Field (PID) indicates the application layer protocol that is used. The list all supported protocols. Table A.14 — List of supported PID's

PID

Protocol (according to Table 2)

00h

Reserved

02h

Application error (see EN 13757–3:2018, Clause 6)

01h

M-BUS (see EN 13757–3:2018, Clause 6)

03h

Application reset or select (see EN 13757–3:2018, Clause 7)

04h

Time Sync (see EN 13757–3:2018, Clause 8)

05h

Alarm protocol (see EN 13757–3:2018, Clause 9)

06h

Image transfer (see EN 13757–3:2018, Annex I)

07h

Network management (see EN 13757–4 and EN 13757–5)

08h

DLMS/COSEM with OBIS Identifier (see EN 13757–1)

09h to 0Fh

Reserved

10h to DFh

Reserved

E0h to F7h

Manufacture specific (corresponds to CI = A0h to B7h)

F8h to FFh

Reserved

APDU: This field contains the (in the PID declared) Application Protocol Data Unit. The first byte of APDU corresponds to the first byte of the application protocol (e.g. a DIF for the M-Bus protocol).

A.9.2 Data Structure 30h — AES Key-Wrap

The use of the AES Key Wrap mechanism (with padding) is indicated by the use of the value 30h for the “Data Structure Identifier” byte. The AES Key Wrap mechanism shall be implemented according to NIST/SP 800-38F, type KWP and provides both confidentiality and integrity protection of the encapsulated APL command. Table A.15 — Wrapped data structure 30h

Key counter

ICV

MLI

Key counter

Target Time

PID

APDU

Padding

4 bytes

4 bytes

4 bytes

4 bytes

5 bytes

1 byte

Variable

Variable

The table above shows the structure of the “Data Structure Content” part. The grey fields of the structure are confidentiality protected.

80

EN 13757-7:2018 (E)

ICV:

Key counter:

MLI: Target Time: PID:

APDU:

4 bytes integrity check value defined as: A65959A6h

This field shall be as defined in A.9.1.The Key counter outside and inside the wrapped container shall be identical. If the plain Key counter differs from encrypted one, the message shall be rejected and the meter shall respond a SITP status response indicating a Key counter error (see A.8.8). NOTE The Key counter is transmitted twice, once unencrypted to identify the counter before decrypting and once inside the wrapped data to ensure that the counter has not been manipulated.

4 bytes Message Length Indicator (unsigned integer, MSB first) covering the total size in bytes of the fields Key counter, Target Time, PID and APDU. The padding bytes are not included in the MLI. This field shall be as defined in A.9.1. This field shall be as defined in A.9.1. This field shall be as defined in A.9.1.

Padding: m padding bytes with 00h, where m = 7 − ((MLI − 1) mod 8) When the meter receives this data structure it shall unwrap the content and compare the ICV with the preset value. If both values match, the meter will further process the APDU. Otherwise it shall create a status response (see A.8.8). In case the AES-Key-Wrap algorithm is applied, end-to-end integrity and confidentiality protection is provided.

A.9.3 Data Structure 31h — HMAC-SHA256

The use of the HMAC-SHA256 mechanism to protect the encapsulated Application Layer Command is indicated by using the value 31h for the “Data Structure Identifier” byte. This mechanism only provides end to end integrity protection of the encapsulated APL. The structure of the wrapped data are as indicated in the table below: Table A.16 — Data structure 31h

Key counter

Target Time

PID

APDU

MAC

4 bytes

5 bytes

1 bytes

Variable

32 bytes

Key counter:

This field shall be as defined in A.9.1.

PID:

This field shall be as defined in A.9.1.

Target Time: APDU: MAC:

This field shall be as defined in A.9.1. This field shall be as defined in A.9.1.

The output of the HMAC-SHA256 algorithm will be placed in the last 32 bytes (256 bits) of this structure. Note that the MAC value is transmitted with MSB first (big endian). The key used for the HMAC calculation is indicated by the DSH1 and DSH2 fields. The HMAC algorithm shall be used according to FIPS PUB 198-1. The SHA256 algorithm shall be used according to FIPS PUB 180-4.

The data to be authenticated is the concatenation of the following fields: — Key counter || Target Time || PID || APDU.

81

EN 13757-7:2018 (E)

When the meter receives this data structure it shall calculate the MAC and compare it with the transmitted MAC. If both values match, the meter will further process the APDU. Otherwise it shall create a status response (see A.8.8). In case the HMAC-SHA256 algorithm is applied, only end-to-end integrity protection is provided.

A.9.4 Data Structure 32h and 33h — CMAC

The use of the AES128-CMAC wrapping mechanism is indicated by the use of the value 32h and 33h for the “Data Structure Identifier” byte. The CMAC value shall be calculated according to NIST/SP 800-38B. The 16 byte of the CMAC-function may be truncated as defined in NIST/SP 800-38B. The applied CMAC length is indicated by the data structure identifier as defined in Table A.17: Table A.17 — Selection of data structure 32h and 33h

Data structure identifier

AES128-CMAC length

32h

8 bytes

33h

16 bytes

The structure of the wrapped data are as indicated in the table below:

Table A.18 — Data structure 32h and 33h

Key counter

Target Time

PID

APDU

MAC

4 bytes

5 bytes

1 bytes

Variable

8 or 16 bytes

Key counter:

This field shall be as defined in A.9.1.

PID:

This field shall be as defined in A.9.1.

Target Time: APDU: MAC:

This field shall be as defined in A.9.1. This field shall be as defined in A.9.1.

This field contains the calculated CMAC value. Note that the CMAC value is transmitted with MSB first (big endian). The MAC length is indicated by the data structure identifier as defined inTable A.17. The key used in the AES128-CMAC algorithm is the key indicated by the DSH1 and DSH2 fields. The data to be authenticated is the concatenation of the following fields (i.e. input for CMAC calculation) — Key counter || Target Time || PID || APDU.

When the meter receives this data structure it shall calculate the CMAC and compare it with the transmitted MAC. If both values match, the M-BUS device will further process the APDU. Otherwise it shall create a status response (see A.8.8). In case the AES-CMAC algorithm is applied, only end-to-end integrity protection is provided.

A.9.5 Data Structure 34h — AES-GCM

This data structure uses the Galois/Counter Mode for authenticated encryption. The Galois/Counter Mode is an algorithm for authenticated encryption with associated data. The structure of the wrapped data are as indicated in the table below:

82

EN 13757-7:2018 (E)

Table A.19 — Data structure 34h Key counter

Target Time

PID

APDU

Authentication Tag

4 bytes

5 bytes

1 byte

Variable

12 bytes

The grey fields are confidentiality protected. Key counter:

This field shall be as defined in A.9.1.

PID:

This field shall be as defined in A.9.1.

Target Time:

This field shall be as defined in A.9.1.

APDU:

Authentication Tag:

This field shall be as defined in A.9.1.

This field contains the calculated GMAC value. It has a fixed length of 12 bytes. Note that it is transmitted with MSB first (big endian). AES128-GCM is described in more detail in 9.4.7 and shall be implemented according to NIST/SP 80038D. The key to be used as the GCM key (K) is indicated by the Data Structure Header fields DSH1 and DSH2. The plaintext data (P) to encrypt is the concatenation of the fields: — Target Time || PID || APDU.

The algorithm will convert this plaintext data into encrypted data (C).

The AES-GCM algorithm ensures that the plaintext data (P) is also authenticated. There is no additional “associated data” (A) to be authenticated (i.e. A is empty). The length of the initialization vector IV shall be 12 bytes and is defined in Table A.20:

— The leading (i.e. the leftmost) 8 bytes contain the fixed field. This fixed field is the concatenation of data field values identifying the M-BUS meter, i.e. Fixed Field = Manufacturer-ID || Identification No || Version || Direction

— The trailing (i.e. the rightmost) 4 bytes shall hold the invocation field. This invocation field contains the Key counter. Table A.20 — Structure of the IV in case of AES-GCM Fixed Field 11

10

Manufacturer (LSB first)

Direction: NOTE purpose.

9

8

7

Identification number (LSB first)

Invocation Field 6

5

4

Version

Direction

3

2

1

0

Key counter (MSB first)

This field shall be 01h for downlink and 02h for uplink to ensure a different IV.

It is not necessary to provide a full 8 byte address here as this fields are not used for addressing

When the meter receives this data structure it shall calculate the GMAC and compare it with the Authentication Tag. If both values match, the meter will further process the APDU. Otherwise it shall create a status response (see A.8.8).

In case the AES-GCM algorithm is applied, end-to-end integrity and confidentiality protection is provided.

83

EN 13757-7:2018 (E)

A.9.6 Data Structure 35h — AES-GMAC This data structure uses the Galois/Counter Mode for authentication only (GMAC). In this case the algorithm is called AES-GMAC. The structure of the wrapped data are as indicated in the table below: Table A.21 — Data structure 35h

Key counter

Target Time

PID

APDU

Authentication Tag

4 bytes

5 bytes

1 byte

Variable

12 bytes

Key counter:

This field shall be as defined in A.9.1.

PID:

This field shall be as defined in A.9.1.

Target Time:

This field shall be as defined in A.9.1.

APDU:

Authentication Tag:

This field shall be as defined in A.9.1.

This field contains the calculated GMAC value. It has a fixed length of 12 bytes and is transmitted with MSB first (big endian). AES128-GMAC shall be implemented according to NIST/SP 800-38D. In this case, there is no plaintext (P) to encrypt (i.e. P is empty), only data to authenticate. The data to authenticate (A) (i.e. the “associated data”) is defined as the concatenation of the following fields: — Target Time || PID || APDU.

The key to be used as the GMAC key (K) is indicated by the Data Structure Header fields DSH1 and DSH2. The length of the initialization vector IV shall be 12 bytes and is defined in Table A.22:

— The leading (i.e. the leftmost) 8 bytes contain the fixed field. This fixed field is the concatenation of data field values identifying the M-BUS meter, i.e. Fixed Field = Manufacturer-ID || Identification No || Version || Direction

— The trailing (i.e. the rightmost) 4 bytes shall hold the invocation field. This invocation field contains the Key counter. Table A.22 — Structure of the IV in case of AES-GMAC Fixed Field 11

10

Manufacturer (LSB first)

Direction:

NOTE purpose.

9

8

7

Identification number (LSB first)

Invocation Field 6

5

4

Version

Direction

3

2

1

0

Key counter (MSB first)

This field shall be 01h for downlink and 02h for uplink to ensure a different IV.

It is not necessary to provide a full 8 byte address here as this fields are not used for addressing

When the meter receives this data structure it shall calculate the GMAC and compare it with the Authentication Tag. If both values match, the meter will further process the APDU. Otherwise it shall create a status response (see A.8.8). In case the AES-GMAC algorithm is applied only end-to-end integrity protection is provided.

84

EN 13757-7:2018 (E)

A.9.7 Data Structure 36h and 37h — AES-CCM The use of the AES128-CCM wrapping mechanism is indicated by the use of the value 36h and 37h for the “Data Structure Identifier” byte. The CCM mode shall be implemented according to the NIST recommendations for block cipher modes of operation and published as NIST Special Publication 80038C. This mechanism uses the CCM mode with the AES128 block cipher algorithm. The applied MAC length is indicated by the data structure identifier as defined inTable A.23. Table A.23 — Selection of data structure 36h and 37h

Data structure identifier

AES128-CCM MAC length

36h

8 bytes

37h

16 bytes

This mechanism uses a mode of operation, called CCM, defined for a symmetric key block cipher algorithm. CCM is used to provide assurance of the confidentiality and the authenticity of data by combining the techniques of the counter mode and the cipher block chaining-message authentication code (CBC-MAC) algorithm. The structure of the data are as indicated in the Table A.24 below: Table A.24 — Wrapped data structure 36h and 37h

Key counter

Target Time

PID

APDU

Authentication Tag

4 bytes

5 bytes

1 bytes

Variable

8 or 16 bytes

The grey fields are confidentiality protected. Key counter:

This field shall be as defined in A.9.1. This wrapping mechanism applies the Key counter as the CCM counter.

PID:

This field shall be as defined in A.9.1.

Target Time:

This field shall be as defined in A.9.1.

APDU:

Authentication Tag:

This field shall be as defined in A.9.1.

This field contains the calculated MAC which is transmitted with MSB first (big endian). The length is indicated by the data structure identifier as defined in Table A.23. The data to be encrypted and authenticated is the concatenation of the following fields: — Target Time || PID || APDU

There is no additional “associated data” to be authenticated.

The length of the CCM nonce is fixed to 13 bytes as shown in Table A.25:

Table A.25 — Structure of the CCM nonce in case of AES-CCM

12

11

Manufacturer (LSB first)

10

9

8

7

Identification number (LSB first)

6

5

4

Version

Device type

Direction

3

2

1

0

Key counter (MSB first)

85

EN 13757-7:2018 (E)

Direction:

This field shall be 01h for downlink and 02h for uplink to ensure a different nonce.

When the meter receives this data structure it shall decrypt the encrypted fields and calculate the Authentication Tag using the decrypted values for the Target Time, PID and APDU and compare it with the decrypted Authentication Tag. If both values match the values for Target Time PID and APDU can be considered as correct and the meter will further process the APDU. Otherwise it shall create a status response (see A.8.8).

In case the AES-CCM algorithm is applied, end-to-end integrity and confidentiality protection is provided.

86

EN 13757-7:2018 (E)

Annex B (informative)

Message counter example

The figures in the annex depict the control flow for the Message counter in the data exchange between the meter and an communication partner i.e. a gateway. There is for each end, the local counter (CM or CCP), an unverified copy of the remote counter (CM’ or CCP’), and a verified copy of the remote counter (CM” or CCP”). Operations on the local counter is always based on the verified copy of the remote counter (CM” or CCP”). Verification of the counter contains a range check for the counter and a verification of the authentication of the datagram.

87

EN 13757-7:2018 (E)

Key a The gateway restores the verified version of the meters counter CM” after power up. b The gateway assigns this value to its own Message counter CCP.

c The Meter retrieves its Message counter CM, Its value is larger than the previous value. d A one-way datagram, SND-NR is sent from the Meter to the gateway.

e The gateway stores the value, as an unverified copy, until it has verified that is in a valid range and that the frame is correctly authenticated. f It is then marked as validated and used as baseline for the gateways own counter.

g The gateway generates its own counter by adding an offset to allow for some delay before sending a datagram. h The Meter increments the Message counter. i and sends the next one-way datagram,

j The gateway starts sending a command to the meter, SND-UD, using its own, offset, Message counter. The command consists of three fragments, sent one at a time. k The meter checks the counter value. But it cannot validate the message yet and will temporarily store the unvalidated Message counter; l and confirm the first fragment.

Figure B.1 — Message counter control flow (part 1)

88

EN 13757-7:2018 (E)

Key m The next datagram from the gateway, holding the next fragment, may get lost. n or the confirmations from the Meter are lost.

o The meter will stop retrying the confirmation.

p It will however still continue its metering task.

q and send the one-way datagrams. Receiving the datagram show that the meter is connected. The gateway, however, cannot send as the datagram indicates that the Meter is not ready to receive commands, i.e. B = 0. r Once B = 1, the gateway is allowed to send the datagrams to the Meter again. s It sends the latest non-confirmed data, i.e. the data lost at “m”. t

The datagram gets confirmed by the Meter.

u The gateway is now able to send the last fragment of the message. It contains the authentication, CMAC.

89

EN 13757-7:2018 (E)

v Validation of the MAC makes the meter update the validated Message counter for the gateway. The meter will adjust its counter accordingly w The datagram is confirmed at the link layer by the ACK. The message is as well confirmed at the transport layer by the insertion of the TPL_ACC in the response. This is not a confirmation at the application level. x It is, to get the confirmation at the application level, recommended to request status at the application layer, using a REQ-UD2. y The meter returns the command response or an application error, with an updated Message counter. z At the end the gateway finish the communication with a SND-NKE.

Figure B.2 — Message counter control flow (part 2)

90

EN 13757-7:2018 (E)

Bibliography

[1]

[2] [3] [4] [5] [6]

EN 1434–3, Heat meters - Part 3: Data exchange and interfaces

EN 60870-5-1, Telecontrol equipment and systems - Part 5: Transmission protocols - Section 1: Transmission frame formats

EN 62056-6-2, Electricity metering data exchange — The DLMS/COSEM suite — Part 6-2: COSEM interface classes

CEN/CLC/ETSI/TR 50572, Functional Reference Architecture for Communications in Smart Metering Systems

ANSI X9 TR-31:2010, Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms

DSMR 2.2 P2, Dutch Smart Meter Requirements — P2 Companion Standard. April 2008. http://www.netbeheernederland.nl

[7]

DSMR 4.2.2 P2, Dutch Smart Meter Requirements — P2 Companion Standard. March 2014. http://www.netbeheernederland.nl

[8]

Federal Office for Information Security — Technical Directive BSI TR 03109-1; Annex III: Fine Specification „Wireless Local Metrological Network Interface“ Part b: „OMS Technical Report Security“ https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03109/index_htm.html

[9] [10] [11] [12] [13]

EN ISO 11568-3:1996, Banking — Key management (retail) — Part 3: Key life cycle for symmetric ciphers (ISO 11568-3:1994)

EN ISO/IEC 7498-1:1995, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model (ISO/IEC 7498-1:1994)

ISO 7498-2:1989, Information processing systems — Open Systems Interconnection — Basic Reference Model — Part 2: Security Architecture

NIST/SP 800-56C:2011-11, Recommendation for Key Derivation through Extraction-thenExpansion

NIST/SP 800-57 Part 1:2012-07, Recommendation for Key Management — Part 1: General (Revision 3)

[14]

EN 62056-6-1, Electricity metering data exchange — The DLMS/COSEM suite — Part 6-1: Object Identification System (OBIS)

[15]

ISO 8372, Information processing — Modes of operation for a 64-bit block cipher algorithm

91