KRITIS-Verordnung

Die KRITIS-Verordnung ist ein Dekret, das gewisse Schutzziele von kritischen Infrastrukturen bestimmt. Auch der Sektor Wasser ist eine kritische Infrastruktur, für die es lebensnotwendige Vorgaben gibt. So ist z. B. bei einer Wasserversorgung zwingend von einer Notversorgung in Höhe von 15 Litern pro Person am Tag zu sorgen, falls der Verteidigungsfall eintreten sollte.[1][S.50- 55]

Die IT-Sicherheit als solche kann aber nicht nur einem Sektor zugeordnet werden, sondern steht in allen KRITIS eine Rolle. Ihre Aufgabe ist dabei die Erfüllung der Schutzziele (Authentizität, Verfügbarkeit, Integrität und Vertraulichkeit) sicherzustellen. Die darunterfallenden Werte bilden Daten und Informationen ab, die zur Sicherstellung von z. B. Versorgungsleistungen benötigt werden. Im Bereich Wasser wäre dies z. B. die Ansteuerung einer Brunnenpumpe zum Befüllen eines Hochbehälters, der wiederum Wassermengen für jeden einzelnen Bürger zur Verfügung stellt.[1][S.219-220]

Zur Erfüllung der Schutzziele verweist die KRITIS-V auf das BSI und BMWK. Sie fordert ebenso alle Betreiber (Versorger) dazu auf, sich mit IT-Sicherheitsgesetzen, IT-Sicherheitsanforderungen und Cyber-Sicherheit zu beschäftigen. Dies gilt für alle Betreiber von kritischen Infrastrukturen, jedoch gibt es eine Grenze zur Nachweispflicht. Im Sektor Wasser Bereich Trinkwasserversorgung liegt dieser Grenzwert bei einer jährlichen Wasserfördermenge von 22 Mio. m³, wodurch einige Versorger der Meinung sind die IT-Sicherheit zu vernachlässigen (Kenntnis aus jahrelanger beruflicher Erfahrung mit Wasserversorgern).

 

BMWK

Das BMWK hat die Aufgabe sich um die Wirtschaft und den Klimaschutz in Deutschland zu kümmern. Dabei spielen die IT-Sicherheit sowie die Cyber-Sicherheit eine immer größer werdende Rolle. Angeheizt durch die Industrie 4.0 und dem Drang zur immer weiteren Digitalisierung auch im Sektor Wasser, werden einige Anforderungen durch das BMWK erklärt. Das BMWK gibt jedoch diese Anforderungen an das BSI weiter, welches dann speziell zur IT- sowie Cyber-Sicherheit Vorgaben und somit IT-Sicherheitsanforderungen erstellt. Viele Anforderungen werden auch aus dem IT-Sicherheitsgesetz bezogen und sollten bei der Digitalisierung beachtet werden. So lautet eine Anforderung oft, dass der Stand der Technik eingehalten werden soll, welcher im § 8 Abs. 1 S. 2 BSI-G niedergeschrieben ist. Alle Forderungen des BMWK für kritische Infrastrukturen im Sektor Wasser übereinstimmen mit der KRITIS-V. Die enge Zusammenarbeit zwischen diesen Ämtern und dem Ministerium wird dadurch deutlich erkennbar.[2][S.35-36, 202- 203][3]

Die Aufgaben des BMWK sind jedoch noch weitreichender. Sie fordern nicht nur Sicherheit in der Telekommunikation und IT-Landschaft, sondern versuchen die Wirtschaft anzukurbeln. Neue oder weitere Unternehmen heranzuziehen und diese am digitalen Wandel teilnehmen zu lassen. Eine weitere Aufgabe besteht darin, den weltweiten Handel für deutsche Unternehmen mit Rahmenbedienungen zu sichern sowie den sozialen Zusammenhalt im eigenen Land zu wahren.[3]

 

BSI

Das BSI dient zur Förderung der Informations- und Cyber-Sicherheit. Dabei werden Informations- und Kommunikationstechniken und deren Einsatz so weit vorgegeben, dass ein hohes Sicherheitsniveau und somit der Schutz von IT-Systemen gegen mögliche Bedrohungen etabliert ist.[4]

Das BSI bietet keine direkten IT-Sicherheitsanforderungen an den Sektor Wasser, sondern legt gewisse Anforderungen für kritische Infrastrukturen fest. Ebenfalls gibt es keine direkten IT-Sicherheitsvorgaben an LPWAN-Standards oder LPWAN-Systeme. Um eine mögliche Verbindung von IT-Sicherheitsanforderungen des BSI und LPWAN-Systemen, die im Sektor Wasser eingesetzt werden sollen, zu kreieren, werden die IT-Sicherheitsanforderungen für Smart Meter Systeme bzw. Smart Meter Gateways, die im Sektor Energie (Stromversorgung) eingesetzten werden, herangezogen.

 

Kryptografische Vorgaben

Die Kommunikation zwischen Smart Meter Gateways und deren Kommunikationspartner soll stets mit TLS abgesichert werden. Dabei muss die TLS Version mindestens 1.2 betragen. Eine Fallbackfunktion auf ältere Versionen ist nicht erlaubt. Die TLS Version 1.3 wird jedoch empfohlen. Eine Session sollte dabei nicht über 48 Stunden lang andauern und muss nach Ablauf einen neuen TLS-Handshake durchführen [5][S.5, 10]. Die Übertragung der Daten zwischen Gateways im LPWAN-Netzwerk an den speziellen Netzwerkserver ist somit mindestens über TLS zu sichern.

 

Kryptografische Algorithmen

Zu den Verfahren werden folgende genannt:

Tabelle 1: Kryptografische Basisverfahren (angelehnt an [5][S.7])

Primitive	Verfahren
Digitale Signatur	ECDSA
Schlüsselgenerierung	ECKA-DH
Schlüsseltransport	ECKA-EG
Blockchiffre	AES CBC-Mode CMAC-Mode GCM-Mode
Hashfunktionen	SHA-2 Familie

Für die Verwendung von elliptischen Kurven (in TLS, ECDSA und ECKA) müssen Primkörper mit entsprechender Bit-Länge verwendet werden. Diese müssen aus folgenden EC-Domain-Parametern genommen werden: [5][S.7]

•    BrainpoolP256r1
•    BrainpoolP384r1

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

Zur Erzeugung von Zufallszahlen müssen die kryptografischen Protokolle einen Zufallszahlgenerator besitzen, die mindestens folgende Klassen verwenden: [5][S.8]

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

Nach der Verwendung von Sitzungsschlüsseln müssen diese vernichtet und dürfen auf keinen Fall mehrfach für Sitzungen verwendet werden. Dies gilt auch für eingesetzte ephemere Schlüssel.[5][S.8]

 

Öffentliche Schlüssel – Infrastruktur

Die Authentifizierung und Integritätssicherung durch einen verschlüsselten Aufbau per TLS, wird durch das Smart Metering Public Key Infrastructur (SM-PKI) vorgegeben. Dabei besteht der Aufbau aus einem Root-CA (Wurzelinstanz-Zertifikat) und Sub-CA (Endnutzerzertifikat).[5][S.9]

Das Signaturverfahren muss das Elliptic Curve Digital Signature Algorithm (ECDSA)-Verfahren verwenden. Das ECDSA wird hier kurz vorgestellt. Tabelle 2 beinhaltet Hashfunktionen und Kurvenparameter, die bei der Erzeugung der CAs verwendet werden müssen:

Tabelle 2: Public Key Infrastruktur - Verfahren & Parameter (angelehnt an[5][S.9])

CA	Verfahren	Vorgabe
Root	Signaturalgorithmus	ECDSA-WITH-SHA384 ECDSA-WITH-SHA512
Root	EC-Domain-Parameter	BrainpoolP384r1 BrainpoolP512r1
Sub	Signaturalgorithmus	ECDSA-WITH-SHA256 ECDSA-WITH-SHA384
Sub	EC-Domain-Parameter	BrainpoolP256r1 BrainpoolP384r1

Die Laufzeit der CAs sind folgend angegeben:

 

Tabelle 3: Laufzeiten von Zertifikaten (angelehnt an [6][S.21-22])

TLS-Zertifikate	Gültigkeitszeit
Root-CA	2 Jahre
Sub-CA	2 Jahre

 

Da die dargestellten Zeiten in Tabelle 3 für ein Smart Meter Gateway festgelegt wurden, könnten diese ebenfalls für Gateways, die für den Sektor Wasser eingesetzt werden, gelten. Für den Einsatz von Nodes im Bereich Trinkwasserversorgung könnte das Eichgesetz herangezogen werden, welches den Turnus für Wasserzähler beschreibt. In diesem werden alle 5 Jahre Warm- und alle 6 Jahre Kaltwasserzähler geeicht. Jedoch wird aus Kostengründen keine Eichung vollzogen, sondern die Zähler komplett ausgetauscht [7]. Dementsprechend kann die Gültigkeitsdauer der TLS-Zertifikate diesem Turnus angeglichen werden. Der Wechsel des Wasserzählers impliziert den Wechsel der Zertifikate. Ausgang ist z. B. die Kommunikation eines Wasserzählers mit einem LoRaWAN-Gateway. Jedoch muss beachtet werden, dass diese Ende-zu-Ende-Verschlüsselung sehr viel Strom verbraucht und bei LPWAN-Systemen keine Anwendung finden, sondern durch eigene IT-Sicherheitsfeatures gewährleistet werden.

 

TLS-Kommunikation mit Version 1.2

Die Implementierung des TLS muss mit Elliptic Curve Deffie-Hellmann Ephermal (ECDHE) erfolgen. Dabei müssen eine der folgenden Cipher Suites verwendet werden: [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

Durch die Wahl der Cipher Suite werden folgende Bereiche des TLS-Protokolls festgelegt: [5][S.11]

•    Schlüsselaustausch
•    Authentifizierung
•    Hashfunktion
•    Verschlüsselung und Message Authentication Code (MAC)

Für die TLS-Kommunikation werden im Bereich des WAN folgende Cipher Suites und elliptische Kurven vorgegeben:

Tabelle 4: Vorgaben zur TLS-Kommunikation V1.2 (angelehnt an [5][S.11])

Verfahren	Vorgabe
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

Für die digitalen Signaturen im TLS-Handshake, müssen folgende Hashfunktionen unterstützt werden: [5][S.12]

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

Die digitalen Signaturen müssen dabei mit ECDSA erstellt werden [5][S.12].

Elliptic Curve Digital Signature Algorithm: ECDSA ist ein Algorithmus zur Erzeugung einer Signatur. Die Signatur verwendet dabei die Kryptografie der Elliptische-Kurven.[8][S.22]

Zur Erstellung einer solchen Signatur werden benötigt:

•    Datei (z. B. Dokument)
•    Kprv (Privater geheimer Schlüssel)
•    Kpub (Öffentlicher Schlüssel)
•    Hash-Verfahren (SHA-2) muss Ersteller und Verifizierer bekannt sein
•    q (große Primzahl)
•    Punkt G (ein Punkt auf einer elliptischen Kurve durch G(xe,ye))
•    Zufallszahl ke (Ephemere Zufallszahl nur für diesen einen Prozess gültig)

Alle Rechnungen werden mit Modulo q berechnet [8][S.22].

Die Originaldatei wird mit der erstellten Signatur an den Verifizierer gesendet. Dieser muss den Generator sowie das verwendete Hash-Verfahren wissen. Den öffentlichen Schlüssel des verwendeten Schlüsselpaares muss er ebenfalls besitzen.[8][S.22]

Zur Verifizierung solch einer Signatur werden benötigt:

•    Datei (z. B. Dokument)
•    Kpub (Öffentlicher Schlüssel)
•    Hash-Verfahren (SHA-2) muss Ersteller und Verifizierer bekannt sein
•    Generator G (ein Punkt auf einer elliptischen Kurve durch G(xe,ye))
•    Signatur: r, s

Elliptic Curve Deffie-Hellmann Ephermal: ECDHE ist ein Verfahren zum Schlüsselaustausch, der das Deffie-Hellmann-Verfahren mit der Kryptografie der Elliptische-Kurven kombiniert.

Benötigt werden dafür:

 

•    Generator G (ein Punkt auf einer elliptischen Kurve durch G(xe,ye))
•    Der Generatorpunkt G bildet die Primzahl p und Generatorzahl q aus dem Deffie-Hellmann-Verfahren ab

•    Zufallszahl beider Parteien (kea & keb)
•    Die ephemere Zufallszahl ist jeweils geheim zu halten

 

Aus diesen Kennzahlen lässt sich der Schlüsselaustausch wie folgt berechnen:

Aus dem Punkt S(xk,yk) kann nun ein Koordinatenpunkt z. B. die x-Koordinate (xk) als gemeinsamer Schlüssel verwendet werden. Dieser könnte jedoch noch eine Hashfunktion durchlaufen und der Hash davon als Schlüssel verwendet werden.

 

TLS-Kommunikation mit Version 1.3

In Version 1.3 der TLS-Kommunikation muss für den Handshake-Modus das ECDHE verwendet werden. Dabei darf das Senden und Annehmen von 0-RTT nicht erfolgen.[5][S.13]

Vorgeschriebene Algorithmen zur authentifizierten Verschlüsselung von Datenpaketen und Hashfunktionen zur Schlüsselableitung werden durch folgende Cipher Suites definiert und müssen verwendet werden: [5][S.13-14]

•    TLS_AES_128_GCM_SHA256
•    TLS_AES_256_GCM_SHA384
•    TLS_AES_128_CCM_SHA256

Die Verwendung von elliptischen Kurven im TLS 1.3 wird wie in folgender Tabelle gezeigt vorgeschrieben:

Tabelle 5: Elliptische Kurven im TLS Version 1.3 (angelehnt an [5][S.14])

Empfehlung	Elliptische Kurven
Notwendigkeit	BrainpoolP256r1 BrainpoolP384r1 Secp256r1
Aufforderung	BrainpoolP512r1tls13 Secp384r1

 

Für die digitalen Signaturen im TLS-Handshake, müssen folgende Algorithmen unterstützt werden: [5][S.14-15]

• • • •  

• ECDSA_BrainpoolP256r1tls13_SHA256

• ECDSA_BrainpoolP384r1tls13_SHA384

• ECDSA_BrainpoolP512r1tls13_SHA512

• ECDSA_Secp256r1_SHA256

• ECDSA_Secp384r1_SHA384

 

1. 1. 1. Inhaltsdatensicherung

Die im WAN übermittelten Informationen müssen innerhalb eines TLS-Kanals mittels verschlüsselter und signierter Nachrichten gesendet werden. Dazu muss die Inhaltsdatenverschlüsselung den Authenticated-Enveloped-Data Content Type verwenden, der wiederum den ephemer-statischen Deffie-Hellmann einsetzt. Dabei werden die Daten symmetrisch verschlüsselt und diese per MAC gesichert.[5][S.24] 

Folgende Verfahren müssen für die Verschlüsselung und MAC-Sicherung eingesetzt werden:

 

Tabelle 6: Vorgaben zum Content-Authenticated-Encryption (angelehnt an [5][S.24])

Verfahren	Schutzziel	Länge
AES-GCM	Verschlüsselung und Authentizität	128 Bit
AES-CBC	Verschlüsselung	128 Bit
AES-CMAC	Authentizität	128 Bit

 

Jegliche symmetrischen Schlüssel zur Verschlüsselung und MAC-Sicherung dürfen nicht für mehrere Nachrichtensendungen verwendet werden.

Schlüssel zur Verschlüsslung und MAC-Sicherungen, die zufällig erzeugt wurden, liegen ebenfalls verschlüsselt im CMS-Container ab. Zur Verschlüsselung der Schlüssel (Key Encryption) muss ein Schlüssel K mittels ECKA-EG-Verfahren berechnet werden. Zur korrekten Implementierung muss die Hashfunktion: [5][S.24-25]

 

•    SHA-256

 

und die Kurvenparameter (EC-Domain-Parameter): [5][S.25]

 

•    BrainpoolP256r1

 

verwendet werden. Der abgeleitete Schlüssel K muss auf Basis der symmetrischen Kryptografie durch Einsatz der Vorgabe: [5][S.25]

 

•    ID-AES128-wrap verschlüsselt werden.

Zur Signierung der verschlüsselten Daten, muss wieder das ECDSA-Verfahren implementiert werden [5][S.25]. Tabelle 7 beinhaltet Funktionen und Parameter, die zur Signierung eingesetzt werden müssen:

 

Tabelle 7: Funktionen und Parameter zur Signatur (angelehnt an [5][S.25])

Verfahren	Vorgaben
Notwendigkeit	SHA-256
EC-Domain- Parameter	BrainpoolP256r1

 

PACE und Secure Messaging

Für Zugriffe auf das Sicherheitsmodul eines Smart Meter Gateways, muss das Password Authenticated Connection Establishment (PACE) eingesetzt werden. Dieses Verfahren ist ein Passwort-basiertes Schlüsseleinigungs- und Authentisierungsverfahren. Eine gemeinsame PIN dient dabei zur Ableitung von Sitzungsschlüssel und Secure Messaging. Das Secure Messaging ist ein authentisierter Kanal zwischen Smart Meter Gateway und Sicherheitsmodul. Zur richtigen Implementierung des Sicherheitsmoduls müssen folgende Vorgaben eingehalten werden: [5][S.28]

 

Tabelle 8: Vorgaben zum PACE und Secure Messaging (angelehnt an [5][S.28])

Verfahren	Vorgaben
Algorithmus	ID-PACE-ECDH-GM-AES-CBC-CMAC-128
EC-Domain- Parameter	BrainpoolP256r1
PACE-PIN	mind. 10 Dezimalziffern

 

1. 1. 1. Sicherheitsmodul

Ein Sicherheitsmodul ist für ein Smart Meter Gateway vorgeschrieben. Dieses dient zur Schlüsselgenerierung, -verteilung und hält die Lebenszyklen der Schlüssel ein. Das Lebenszyklus-Modell ist ausschließlich für das SM-PKI zuständig. Das Sicherheitsmodul verwaltet dabei vor allem alle am Smart Meter Gateway vorhandenen Schnittstellen und Zugriffe.[9][S.120-127]

Alle Zugriffe sind dabei in drei verschiedenen Kommunikationsnetzen getrennt, die durch Abbildung 4 dargestellt werden sollen. Vorher wurde bereits intensiv in die Vorgaben an einem WAN eingegangen. Die beiden anderen werden jedoch vernachlässigt, da die Betrachtung vorab nur auf die LPWAN-Konnektivität liegt und somit die Betrachtung des lokalen Heimnetzes (HAN) und Lokalen Metrologischen Netz (LMN) entfällt.[9][S.12-19]

 

Quellen:

[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.