KRITIS Regulation

For example, in the case of a water supply, it is mandatory to provide an emergency supply of 15 liters per person per day in the event of a defense situation.[1][S.50- 55]

However, IT security as such cannot be assigned to just one sector, but plays a role in all CRITIS. Its task is to ensure that the protection goals (authenticity, availability, integrity and confidentiality) are met. The values that fall under this category represent data and information that are required to ensure, for example, utility services. In the area of water, for example, this would be the control of a well pump for filling an elevated tank, which in turn provides water quantities for each individual citizen.[1][S.219-220]

The KRITIS-V refers to the BSI and BMWK for the fulfillment of the protection goals. It also calls on all operators (utilities) to deal with IT security laws, IT security requirements and cyber security. This applies to all operators of critical infrastructures, but there is a limit to the obligation to provide evidence. In the water sector, drinking water supply, this limit is 22 million m³ per year, which means that some utilities are of the opinion that they are neglecting IT security (knowledge gained from years of professional experience with water utilities.

 

BMWK

The BMWK has the task of looking after the economy and climate protection in Germany. In this context, IT security and cyber security are playing an increasingly important role.Fueled by Industry 4.0 and the push for ever further digitalization also in the water sector, some requirements are declared by BMWK s. However, the BMWK passes these requirements on to the BSI, which then creates specifications and thus IT security requirements specifically for IT as well as cyber security. Many requirements are also drawn from the IT Security Act and should be taken into account during digitization. For example, one requirement is often that the state of the art should be complied with, which is set out in Section 8 (1) Sentence 2 BSI-G. All of the BMWK s requirements for critical infrastructures in the water sector are consistent with the KRITIS-V. This clearly shows the close cooperation between these offices and the ministry.[2][S.35-36, 202- 203][3]

However, the BMWK s tasks are even more far-reaching.Not only do they demand security in the telecommunications and IT landscape, but they also try to stimulate the economy.To attract new or additional companies and let them participate in the digital transformation.Another task is to secure global trade for German companies with framework conditions and to maintain social cohesion in their own country.[3]

 

BSI

The BSI serves to promote information and cyber security. This involves specifying information and communication technologies and their use to such an extent that a high level of security and thus the protection of IT systems against possible threats is established.[4]

The BSI does not provide any direct IT security requirements for the water sector, but specifies certain requirements for critical infrastructure. Likewise, there are no direct IT security requirements for LPWAN standards or LPWAN systems. To create a possible link between IT security requirements of the BSI and LPWAN systems to be deployed in the water sector, the IT security requirements for smart meter systems or smart meter gateways deployed in the energy sector (power supply) are used.

 

Cryptographic specifications

Communication between smart meter gateways and their communication partners should always be secured with TLS. The TLS version must be at least 1.2. A fallback function to older versions is not permitted. However, TLS version 1.3 is recommended. A session should not last longer than 48 hours and must perform a new TLS handshake after expiration [5][p.5, 10]. The transmission of data between gateways in the LPWAN network to the special network server must thus be secured at least via TLS.

 

Cryptographic algorithms

The following are mentioned among the procedures:

Table 1: Basic cryptographic methods (adapted from [5][S.7])

Primitive	Procedure
Digital signature	ECDSA
Key generation	ECKA-DH
Key transport	ECKA-EG
Block cipher	AES CBC-Mode CMAC-Mode GCM-Mode
Hash functions	SHA-2 family

For the use of elliptic curves (in TLS, ECDSA and ECKA), prime bodies with appropriate bit length must be used. These must be taken from the following EC domain parameters: [5][S.7]

•    BrainpoolP256r1
•    BrainpoolP384r1

•    BrainpoolP512r1
•    NIST P-256
•    NIST P-384

To generate random numbers, cryptographic protocols must have a random number generator using at least the following classes: [5][S.8]

•    DRG.4
•    PTG.3
•    NTG.1

After session keys have been used, they must be destroyed and may under no circumstances be used more than once for sessions. This also applies to ephemeral keys used.[5][S.8]

 

Public keys - infrastructure

Authentication and integrity assurance by means of an encrypted structure via TLS is specified by the Smart Metering Public Key Infrastructure (SM-PKI). The structure consists of a root CA (root instance certificate) and sub-CA (end user certificate).[5][S.9]

The signature method must use the Elliptic Curve Digital Signature Algorithm (ECDSA) method.The ECDSA is briefly introduced here. Table 2 contains hash functions and curve parameters that must be used when generating the CAs:

Table 2: Public Key Infrastructure - Procedure & Parameters (based on[5][S.9])

CA	Procedure	Default
Root	Signature algorithm	ECDSA-WITH-SHA384 ECDSA-WITH-SHA512
Root	EC-Domain-Parameter	BrainpoolP384r1 BrainpoolP512r1
Sub	Signature algorithm	ECDSA-WITH-SHA256 ECDSA-WITH-SHA384
Sub	EC-Domain-Parameter	BrainpoolP256r1 BrainpoolP384r1

The running times of the CAs are given below:

 

Table 3: Maturities of certificates (based on [6][S.21-22])

TLS certificates	Validity time
Root-CA	2 Jahre
Sub-CA	2 years

 

Since the times shown in Table 3 were defined for a smart meter gateway, they could also apply to gateways used for the water sector. For the use of nodes in the drinking water supply sector, the calibration law could be used, which describes the cycle for water meters. In this, hot water meters are calibrated every 5 years and cold water meters every 6 years. However, for cost reasons, no calibration is carried out, but the meters are completely replaced [7]. Accordingly, the validity period of the TLS certificates can be aligned with this cycle. The change of the water meter implies the change of the certificates. Output is, for example, the communication of a water meter with a LoRaWAN gateway. However, it must be noted that this end-to-end encryption consumes a lot of power and is not applied in LPWAN systems, but is ensured by separate IT security features.

 

TLS communication with version 1.2

The TLS must be implemented using Elliptic Curve Deffie-Hellmann Ephermal (ECDHE). One of the following cipher suites must be used:[5][S.10-11]

•    TLS_ECDHE_WITH_AES_128_CBC_SHA256
•    TLS_ECDHE_WITH_AES_256_CBC_SHA384
•    TLS_ECDHE_WITH_AES_128_GCM_SHA256
•    TLS_ECDHE_WITH_AES_128_GCM_SHA384

The choice of Cipher Suite defines the following areas of the TLS protocol: [5][S.11]

•    Key exchange
•    Authentication
•    Hash function
•    Encryption and Message Authentication Code (MAC)

The following cipher suites and elliptic curves are specified for TLS communication in the WAN area:

Table 4: Specifications for TLS communication V1.2 (based on [5][S.11])

Procedure	Default
Cipher Suite	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
EC-Parameter	NIST P-256 NIST P-384 BrainpoolP256r1 BrainpoolP384r1 BrainpoolP512r1

For the digital signatures in the TLS handshake, the following hash functions must be supported: [5][S.12]

•    SHA-256
•    SHA-384
•    SHA-512

The digital signatures must be created with ECDSA. [5][S.12].

Elliptic Curve Digital Signature Algorithm: ECDSA is an algorithm for generating a signature. The signature uses elliptic curve cryptography.[8][S.22]

To create such a signature are needed:

•    File (z. B. document)
•    Kprv (Private secret key)
•    Kpub (Public key)
•    Hash method (SHA-2) must be known to creator and verifier
•    q (large prime number)
•    Point G (a point on an elliptic curve through G(xe,ye))
•    Random number ke (Ephemeral random number valid only for this one process).

All invoices are calculated with modulo q [8][S.22].

The original file is sent to the verifier with the generated signature. The verifier must know the generator and the hash method used. He must also have the public key of the key pair used.[8][S.22]

For the verification of such a signature are needed:

•    File (e.g. document)
•    Kpub(Public key)
•    Hash method (SHA-2) must be known to creator and verifier
•    Generator G (a point on an elliptic curve through G(xe,ye))
•    Signature: r, s

Elliptic Curve Deffie-Hellmann Ephermal: ECDHE is a key exchange method that combines the Deffie-Hellmann method with elliptic curve cryptography.

Required for this are:

 

•    Generator G (a point on an elliptic curve through G(xe,ye))
-    The generator point G maps the prime number p and generator number q from the Deffie-Hellmann method

•    Random number of both parties (kea & keb)
-    The ephemeral random number shall be kept secret in each case.

 

From these metrics, the key exchange can be calculated as follows:

From the point S(xk,yk) a coordinate point e.g. the x-coordinate (xk) can now be used as a common key. However, this could still be run through a hash function and the hash of it used as the key.

 

TLS communication with version 1.3

In version 1.3 of TLS communication, the ECDHE must be used for handshake mode. In this case, the sending and accepting of 0-RTT must not take place.[5][S.13]

Prescribed algorithms for authenticated encryption of data packets and hash functions for key derivation are defined by the following cipher suites and must be used:[5][S.13-14]

•    TLS_AES_128_GCM_SHA256
•    TLS_AES_256_GCM_SHA384
•    TLS_AES_128_CCM_SHA256

The use of elliptic curves in TLS 1.3 is prescribed as shown in the following table:

Table 5: Elliptic curves in TLS version 1.3 (adapted from [5][S.14])

Recommendation	Elliptic curves
Necessity	BrainpoolP256r1 BrainpoolP384r1 Secp256r1
Request	BrainpoolP512r1tls13 Secp384r1

 

For digital signatures in the TLS handshake, the following algorithms must be supported: [5][S.14-15]

• • • •  

• ECDSA_BrainpoolP256r1tls13_SHA256

• ECDSA_BrainpoolP384r1tls13_SHA384

• ECDSA_BrainpoolP512r1tls13_SHA512

• ECDSA_Secp256r1_SHA256

• ECDSA_Secp384r1_SHA384

 

1. 1. 1. Content backup

The information transmitted on the WAN must be sent within a TLS channel using encrypted and signed messages. For this purpose, the content data encryption must use the Authenticated-Enveloped-Data Content Type, which in turn uses the ephemeral-static Deffie-Hellmann. In this case, the data is symmetrically encrypted and this is secured by MAC.[5][S.24] 

The following procedures must be used for encryption and MAC security:

 

Table 6: Content-Authenticated-Encryption specifications (adapted from [5][S.24])

Procedure	Protection target	Length
AES-GCM	Encryption and authenticity	128 Bit
AES-CBC	Encryption	128 Bit
AES-CMAC	Authenticity	128 Bit

 

Any symmetric keys for encryption and MAC security must not be used for multiple message broadcasts.

Keys for encryption and MAC backups generated randomly are also stored encrypted in the CMS container. To encrypt the keys (key encryption), a key K must be calculated using the ECKA-EG method. For correct implementation, the hash function:[5][S.24-25]

 

•    SHA-256

 

and the curve parameters (EC domain parameters): [5][S.25]

 

•    BrainpoolP256r1

 

must be used. The derived key K must be based on symmetric cryptography by using the default: [5][S.25]

 

•    ID-AES128-wrap be encrypted.

To sign the encrypted data, the ECDSA procedure must again be implemented [5][p.25]. Table 7 contains functions and parameters that must be used for signing:

 

Table 7: Functions and parameters for the signature (based on [5][S.25])

Procedure	Specifications
Necessity	SHA-256
EC domain parameters	BrainpoolP256r1

 

PACE and Secure Messaging

For access to the security module of a smart meter gateway, the Password Authenticated Connection Establishment (PACE) must be used. This procedure is a password-based key agreement and authentication procedure. A common PIN is used to derive the session key and secure messaging. The secure messaging is an authenticated channel between the smart meter gateway and the security module. To implement the security module correctly, the following specifications must be observed:[5][S.28]

 

Table 8: Specifications for PACE and secure messaging (based on [5][S.28])

Procedure	Specifications
Algorithm	ID-PACE-ECDH-GM-AES-CBC-CMAC-128
EC domain parameters	BrainpoolP256r1
PACE-PIN	at least 10 decimal digits

 

1. 1. 1. Security module

A security module is mandatory for a smart meter gateway. This is used for key generation, distribution and maintains the life cycles of the keys. The life cycle model is exclusively responsible for the SM-PKI. The security module primarily manages all interfaces and accesses available on the smart meter gateway.[9][S.120-127]

All accesses are separated in three different communication networks, which are shown in Figure 4.The specifications for a WAN have already been discussed in detail.However, the other two will be neglected, since only LPWAN connectivity will be considered in advance and the local home area network (HAN) and local metrological network (LMN) will not be considered.[9][S.12-19]

 

Sources:

[1] BKK: Definition von Schutzzielen für Kritische Infrastrukturen, Band 28, 09.2019:https://www.kritis.bund.de/SharedDocs/Downloads/BBK/DE/Publikationen/ PublikationenForschung/FiB_Band_28_Definition_von_Schutzzielen_fuer_ KRITIS.pdf? blob=publicationFile, Aufgerufen am 01.08.2021.

[2] BMWi: IT-Sicherheit für die Industrie 4.0, 01.2016:https://www.bmwi.de/Redaktion/DE/Publikationen/Studien/it-sicherheit- fuer-industrie-4-0.pdf?blob=publicationFile&v=4, Aufgerufen am 02.08.2021.

[3] BMWi: Was macht das Ministerium:https://www.bmwi.de/Redaktion/DE/Artikel/Service/leichte-sprache-was- macht-das-bmwi.html, Aufgerufen am 02.08.2021.

[4] BSI: Fragen und Antworten zu Aufgaben und Themen des BSI:https://www.bsi.bund.de/DE/Service-Navi/FAQ/BSI-Aufgaben/faq_bsi- aufgaben_node.html#:~:text=Zu%20den%20Aufgaben%20des%20BSI,vo n%20IT%2DProdukten%20und%20%2DDienstleistungen, Aufgerufen am 03.08.2021.

[5] BSI: Technische Richtlinie BSI TR-03116 Kryptographische Vorgaben für Projekte der Bundesregierung Teil 3: Intelligente Messsysteme, 03.03.2021:https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Te chnischeRichtlinien/TR03116/BSI-TR-03116-3.pdf? blob=publicationFile&v=6, Aufgerufen am 03.08.2021.

[6] BSI: Technische Richtlinie BSI TR-03109-4 Smart Metering PKI – Public Key Infrastruktur für Smart Meter Gateways, 09.08.2017:https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Te chnischeRichtlinien/TR03109/TR-03109- 4_PKI.pdf;jsessionid=9043250820E2D9825A46C2BAE946C46E.internet0 82? blob=publicationFile&v=1, Aufgerufen am 14.08.2021.

[7] J. Witte, Welt: Die Wasserzähler-Wechselwut der Deutschen, 11.09.2017:https://www.welt.de/regionales/hamburg/article168532421/Die- Wasserzaehler-Wechselwut-der-Deutschen.html, Aufgerufen am 14.08.2021.

[8] BSI: Technical Guideline BSI TR-03111 Elliptic Curve Cryptography, 01.06.2018:https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Tec hGuidelines/TR03111/BSI-TR-03111_V-2- 1_pdf.pdf;jsessionid=882DBEBE1A02C11D63B38F38E83F86BE.internet4 72?blob=publicationFile&v=1, Aufgerufen am 16.08.2021.

[9] BSI: Technische Richtlinie BSI TR-03109-1 Anforderungen an die Interoperabilität der Kommunikationseinheit eines intelligenten Messsystems, 16.01.2019:https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03109/TR03109-1.pdf? blob=publicationFilev=1, Aufgerufen am 17.08.2021.