Power Metering in Germany

based on information released by the Bundesamt für Informationssicherheit (BSI) / German Federal Agency on IT-Security on Cybersecurity for the Digitalization in Energy Industries

The basic principles, requirements and threat profiles documented by the releasing agency can be found in a set of technical guidelines named: BSI-TR-03116

As digital communications is and will inevitably related to current and future smart energy industries, the available standards do in fact focus on all levels of communication from generation over distribution to consumers. That includes general and generic methods for protection (encryption) and verification (electronic signatures) in a Public Key Infrastructure or PKI of national scale to communication protocols for the specific interchange of information within business processes in energy industries, like (for example) transferring a meter’s value for invoicing through a Metered Services Consumption report message (UN/CEFACT BDEW MSCONS PID 13017).

• PKI: BSI TR-03109-4
• MSCONS: BEDEW MSCONS

Editor’s Note: Without being able to describe all aspects of the above-mentioned standards and their implications in whole, I will follow a route on how it works and what is happening from the point of view of a regular consumer of energy services. Pleas keep in mind that the roll-out for this digital infrastructure is still in full swing at the point of this writing (2025). Whenever use cases are used as examples, they refer to electric energy. This should not divert attention from the fact, these communication standards and protocols do apply to all metered products (Sparten) in energy industries (Water, Heat, Gas, Contracting Services…) as well. Also, I do use the words “electricity” and “electric energy” synonymously and electricity or energy cannot be “consumed” – I know that. Finally: I am only beginning to investigate this. I have some professional experience, but it is limited. If I am wrong and/or describing situations inadequately, please share your insight either in this Wiki, Recessim Discord or DM (Discord)

Chapter 1 Home

So you live in an apartment or house and use electricity. Big deal! And it really is. Let us see why. All the electric energy delivered for your convenience goes through at least one measuring device – the meter. That will be in our digitized world an electronic device called in Germany for unknown reasons a smart-meter or moderne Messeinrichtung (mME). This thing in its initial configuration is not “smart” at all, given the idea "smart" means also: able to communicate. It’s not. It is an electronic counter with no ability to communicate. The meter resides logically in a market-location or MaLo (address of the building or apartment), which is associated with your invoicing details (customer name & address). The meter itself or multiple meters represent the measuring-location or MeLo. Ant this is bound to a meter-ID which is then associated with the physical meter, which again has a serial number.

List of EU Smart Meters

Identification Hierarchy:

The Format of a Market Location MaLo consist out of a 11-digit code:

1st Digit 	= authorizing body (1-3: DVGW; 4-9: BDEW)
2nd to 10th 	= (9 digits) ID provided by the grid provider / measurement device provider
11th digit 	= checksum

Example: 012345678901

The Format of a Measurement Location MeLo consist out of a 33-digit code called ZBP:

1,2 digit 	= country code 
3-9 digit 	= distribution grid provider 
10-14 digit 	= postcode 
15-33 digit 	= “counting point number” / Zählpunktnummer

Example: DE012345678901234567890

Associated with the MeLo is an dynamic OBIS Value (Object Identification System), which relates the meter to the product variant: import only, import/export, multi-tariff…

Consumption of electricity is measured in kWh which is kilowatt-hours or 1.000 watts per hour. With a price of 35 to 45 eurocent per kWh, this is a commodity worth to think a moment on how to organize the value chain to ensure money can be collected from consumers (Endverbraucher) and distributed to the contributors in the energy industry. The “bottom” end if this value chain is the “electricity bill” (invoice) you are receiving from a supplier (Lieferant). As Germany is an open market for electricity, this supplier buys the electric energy for your future consumption from an exchange-like market and/or has means to produce electricity themselves. But this will be covered later in more detail. For the moment we just reduce it to the fact that the supplier estimates your individual consumption of electricity based on a standardized load profile (SLP) and if everything is normal, it will be there to power whatever electric appliances you might have.

Local Metrological Network or LMN

In order to “smartify” the situation, communication must be enabled. Therefore an communication interface needs to be added to the smart-meter. Furthermore a smart-meter-gateway (SMGW) needs to be added and accessible from the meters communication interface. These two devices can now communicate and are called in Germany an intelligent measuring system or iMSys - and yes, this communication is already protected (encrypted). The protocol used here is a COSEM (Companion Specification for Energy Metering) / OBIS (Object Identification System) / OMS (Operation Management System) protocol based on RS485 which can be either by wire or wireless, defined in TR-03109

One or more smart-meters with communication interfaces connect with a single smart meter gateway and form the Local Metrological Network or LMN.

LNM HAN WAN Overview

As the central communication component, the smart meter gateway must implement secure means for communication with two additional networks:

Home Access Network or HAN

In the HAN you will find all the Controllable Local Systems (CLS). These are switches controlled by the SMGW and can be turned on or off or put into a “reduced power mode”. This is the sole purpose of the HAN to have access to one or more CLS. Pictures are often shown with including the consumers smart-home components and proprietary in-home-displays (IHD), but this is just obfuscation. The truth is all consumers will connect their smart home components in their home WLAN and in one way or another directly to the meters for readout or in the case of a power generating situation (photovoltaic, wind, generators) to the inverters / regulators of that generation unit. The CLS sole purpose is reduce the risk of instability for the grid in energy shortage situations and to enable the grid operators to shut down high consumption appliances like professional grade electric heaters, air conditioning, washer and dryers, kitchen ovens, stove, furnaces, wall boxes for e-mobility, instantaneous water heaters and heat pumps. The owner of a house will effectively loose the final control over these appliances if they have been connected through an CLS. As of now, consumers and house owners are tricked into the CLS acceptance process by offering discounts on the price of the kWh. But the national institute for electrical engineering (VDE) is working on standards making it mandatory to connect anything with an electrical power of more than a thousand Watts to a CLS. Making it illegal to constantly operate those without an CLS.

CLS in HAN

Imagine, you are generating electricity from solar power coming from your house’s roof to charge your electric vehicle in your garage, which is connected to a wall box. Now the grid’s frequency turns suddenly low, and the grid operator decides to dump “unnecessary” load. Your CLS will be turned off. The excessive electricity from your roof will be immediately diverted to the grid to have it furthermore stabilized. You get 8ct per kWh for tis stunt, but your car remains uncharged. A similar doomed situation occurs if grid frequency rises. Your solar export to the grid will be just cut off by commanding the inverters to reduce efficiency by frequency manipulation. The electric vehicle is charged with grid power at 50 ct/kWh. Your customer data record at the energy supplier and the grid operator will contain and release the information about the possibility of remotely deactivating import or export to the grid. This information is exchanged through UN/CEFACT BDEW UTILMD PID 55112/55113/55114

UN/CEFACT BDEW UTILMD PID 55112/55113/55114

You can be exempt from remote control if you are a hospital or a government agency and do rely on electricity on a higher priority than consumers. The HAN communication protocol is based on mostly wireless cell broadcasts in the 2.4 GHz band similar to the capabilities of Bluetooth:

HAN communication protocol

It does not connect or need to connect to your home’s WiFi. It can be wired of course.

Wide Area Network or WAN

This network carries the communication from the grid operator (Gateway-Administrator) to and from the intelligent measuring System. The gateway administrator is a role. This role is controlled by the grid operator and his rules for redispatch (rules to control frequency in the power grid at a acceptable stable level). That is a very important role and numerous apocalyptic movies do build their plot on the idea of something going wrong here. This role is the true divers’ seat in this orchestra. With CLS the ability to reduce the impact of medium or larger stability incidents to a desired audience of maximum suffering tolerable individuals, the possibilities have substantially increased. Of course, it is up the German government and the minister of energy, to decide how this audience should be exactly composed of.

Also an external market player role (externer Markteilnehmer) is defined. These is for example your energy supplier (Lieferant). He can communicate with the SMGW as well and have it sending consumption-based data in higher or lower frequency or change your tariff. If you for instance, are notorious late with payments, the supplier can switch your invoicing from billing to prepaid and cut you off the grid until a positive balance materializes in the payable account. WAN communication from the SMGW is based exclusively on GSM or Power Line Communication (PLC) protocols and effectively do form an ISO/OSI stack IP network which can be tunneled through the internet by SLL for cost effectiveness. Payload will be always encrypted on the byte level Please note, routing is not available between these networks: LMN, HAN and WAN trough the smart meter gateway. It purely acts as a “bridge”, receiving messages from one network and sending different messages but accordingly to the purpose, to another attached network.

Directly Reading Information from the Smart Meter (IR-Port)

entering PIN with a flashlight

Tasmota based reader writer

Most smart meters in Germany are equipped with an bidirectional ifrared-port (actually two ports: one for TX and one for RX) for sending and receiving data. This port will send additional metering information if activated. This includes momentary power import/export to and from the grid and voltage in different phases (L1, L2, L3). Activation is protected by a 4-digit PIN, which is (for data protection reasons) only available from the company owning the meter, or if unconfigured "0000" as a factory default. To activate the sending of additional metering data, the pin has to be entered by using a simple flashlight. Here's a video showing, how this is done. PIN protetion can be permanaently deactivated. After successfull activation, the meter can be configured by sending serial communication commands via the ir port either by OBIS protocol (ASCII or binary (SML) depending on the meter). After configuration the meter will transmit the information requested via the ir-port. Users communicate with these meters via diy-style serial opto-couples via cable link or WiFi. Freely available Tasmota (github) software based soultions do make use of inexpensive microcontrollers (ESP8266 or ESP32) for that purpose. There is a description of the smart meter interface API, running an OBIS-Protocol here.

Example of the OBIS ASCII communication protocol:

09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"/KFM5KAIFA-METER\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"1-3:0.2.8(42)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"0-0:1.0.0(200913101618S)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"0-0:96.1.1(4530303235303030303639363432393136)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"1-0:1.8.1(005779.835*kWh)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"1-0:1.8.2(005583.617*kWh)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"1-0:2.8.1(000000.000*kWh)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"1-0:2.8.2(000000.000*kWh)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"0-0:96.14.0(0001)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"1-0:1.7.0(00.498*kW)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"1-0:2.7.0(00.000*kW)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"0-0:96.7.21(00000)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"0-0:96.7.9(00000)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"1-0:99.97.0(1)(0-0:96.7.19)(000101000001W)(2147483647*s)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"1-0:32.32.0(00000)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"1-0:32.36.0(00000)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"0-0:96.13.1()\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"0-0:96.13.0()\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"1-0:31.7.0(002*A)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"1-0:21.7.0(00.496*kW)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"1-0:22.7.0(00.000*kW)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"0-1:24.1.0(003)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"0-1:96.1.0(4730303332353631323736373836373136)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"0-1:24.2.1(200913100000S)(04139.079*m3)\r"} 
09:16:17 MQT: tele/wemos-9/RESULT = {"SerialReceived":"!F798\r"}

Example of the OBIS SML (binary) Protocoll:

1b 1b 1b 1b 01 01 01 01 76 05 03 2b 18 0f 62 00 62 00 72 63 01 01 76 01 01 05 01 0e 5d 5b 0b XX XX 
XX XX XX XX XX XX XX XX 01 01 63 49 00 00 76 05 03 2b 18 10 62 00 62 00 72 63 07 01 77 01 0b XX XX 
XX XX XX XX XX XX XX XX 07 01 00 62 0a ff ff 72 62 01 65 02 1a 58 7f 7d 77 07 81 81 c7 82 03 ff 01 
01 01 01 04 49 53 4b 01 77 07 01 00 00 00 09 ff 01 01 01 01 0b XX XX XX XX XX XX XX XX XX XX 01 77 
07 01 00 01 08 00 ff 65 00 01 01 80 01 62 1e 52 ff 59 00 00 00 00 01 c9 0c a7 01 77 07 01 00 01 08 
01 ff 01 01 62 1e 52 ff 59 00 00 00 00 01 c9 0c a7 01 77 07 01 00 01 08 02 ff 01 01 62 1e 52 ff 59 
00 00 00 00 00 00 00 00 01 77 07 01 00 02 08 00 ff 01 01 62 1e 52 ff 59 00 00 00 00 00 00 00 00 01 
77 07 01 00 02 08 01 ff 01 01 62 1e 52 ff 59 00 00 00 00 00 00 00 00 01 77 07 01 00 02 08 02 ff 01 
01 62 1e 52 ff 59 00 00 00 00 00 00 00 00 01 77 07 01 00 10 07 00 ff 01 01 62 1b 52 00 55 00 00 00 
5b 01 77 07 01 00 24 07 00 ff 01 01 62 1b 52 00 55 00 00 00 17 01 77 07 01 00 38 07 00 ff 01 01 62 
1b 52 00 55 00 00 00 2e 01 77 07 01 00 4c 07 00 ff 01 01 62 1b 52 00 55 00 00 00 15 01 77 07 81 81 
c7 82 05 ff 01 01 01 01 83 02 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 01 01 01 63 54 86 00 76 
05 03 2b 18 11 62 00 62 00 72 63 02 01 71 01 63 fa 36 00 1b 1b 1b 1b 1a 00 70 b2

(sensitive data blanked out = XX)

Chapter 2 Public Key Infrastructure

General

While until 1st of April 2024 most communications between energy market participants (roles) were relying on automatically processed email, this is changed to a machine-to-machine communication via webservices, using AS4 (https://en.wikipedia.org/wiki/AS4 ) encrypted payloads. The requirements for the XML encryption / signing public key infrastructure (PKI) leans on Diffie-Hellman key exchange procedures. The keys algorithms themselves however can be based on anything commonly accepted like: RSA, Diffie-Hellman, DLIES or Elliptic-Curve (https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile&v=9 ).

Keygen and Distribution

In theory every market participant is obliged to create their own key-pair for each role in the EDI@Energy framework. Then the public key needs to be signed by an officially certified CA. Officially certified CAs in this case are IT service providers, registered with the National Energy Grid Agency (BNetzA) and do include like Arvato, Telesec and Deutsche Telekom. The signed public key must be made available in a central directory operated by the BDEW, an energy industry standardization organization. It turns out, the challenge to generate key pairs in a secure fashion is overwhelming most IT organizations in small and medium sized utilities companies. The challenges arising from installing and maintaining trust-centre grade “circle of trust” procedures including the necessary escrow mechanisms, keeping employees from stealing keys and passwords, are substantial. Some larger organizations are known to have the resources and procedures in place, most smaller companies seem to ignore the risks and have their admins generating X.509 keys with ssh-keygen on their Linux machines and some totally rely on the service offerings of the CAs. In the case of some IT-guy made the key pair, there is a substantial risk, this pair will sooner or later be compromised. Additionally relying on a CA service provider to generate, distribute and maintain thousands of key-pairs for smaller organizations creates a single target, which if compromised, will void the security of the whole PKI at least for a while.

Payload Encryption vs. Transport encryption

The National Institute for IT Security (BSI) emphasizes two alternative AS4 compatible approaches: PKI encrypted payloads with electronic signatures and transport based (TLS 1.2) encryption. It is not clear from the requirements specification which one should be used when. But the initial thinking probably was to go for the payload encryption in the first place and to fall back to TLS, when the procedures implemented proved unreliable for the market participants. As this is currently under implementation by a multitude of software vendors for energy market communication products at the point of this writing (March/2024), no statement can be made on the initial success and use of payload encryption.