In der Beschreibung von technischen und organisatorischen Maßnahmen (TOMs) gemäß Art. 32 Abs. 1 lit. a DSGVO liest man oft den Namen der verwendeten Blockchiffren, mit deren Hilfe durch Verschlüsselung das Schutzziel der Vertraulichkeit gewährleistet wird. Blockchiffren sind Algorithmen, die aus einem Block Klartext einen Block Ciphertext erzeugen.

Dafür empfohlene Algorithmen finden sich in der Technischen Richtlinie BSI TR-02102-1 „Kryptografische Verfahren: Empfehlungen und Schlüssellängen“ des Bundesamtes für Sicherheit in der Informationstechnik. Dabei ist die Liste der empfohlenen Verfahren – aus Sicht der Implementierung und Überprüfung – erfreulich kurz, es wird nur AES empfohlen. Diese Chiffre wird in der Veröffentlichung „Federal Information Processing Standards Publication 197“ (FIPS PUB 197) des US-amerikanischen Normungsinstituts „National Institute of Standards and Technology“ (NIST) definiert.

Schlüssellänge

Über den reinen Algorithmus hinaus gibt die BSI-Empfehlung auch die Schlüssellängen vor: 128, 192 oder 256 Bit Länge müssen es sein. Dementsprechend finden sich im TOMs dokumentierte Verfahren als AES-128, AES-192 oder AES-256.

An dieser Stelle mit der Dokumentation des Algorithmus und der Schlüssellänge zu enden greift allerdings etwas zu kurz. Blockchiffren verschlüsseln nur Daten der Länge eines Blocks, für AES sind das 128 Bit resp. 16 Byte. In der real gelebten Informationspraxis wird kaum ein Datensatz personenbezogener Daten mit 16 Byte Speicherplatz auskommen. Daher muss der AES-Algorithmus mit der gewählten Schlüssellänge wiederholt auf alle Blöcke eines Datensatzes angewendet werden.

Jeder für sich

Ein intuitiver Ansatz ist, mit dem vereinbarten Schlüssel jeden Block einzeln zu verschlüsseln, genannt „electronic code book mode“ (ECB). Dies führt allerdings dazu, dass Klartextblöcke gleichen Inhalts auch in Cipherblöcke gleichen Inhalts verschlüsselt würden. Dies würde verschiedene Angriffsformen ermöglichen, deshalb ist von dieser Art der Verschlüsselung dringend abzusehen. Vielmehr müssen unterschiedliche Klartextblöcke unbedingt unterschiedliche Cipherblöcke ergeben.

Um dies zu erreichen, werden bei der Verschlüsselung von Blöcken Informationen aus der Verschlüsselung vorangegangener Blöcke hinzugezogen, um so ein weiteres Maß an Entropie zu gewinnen. Diese Art der Verwendung von Blockchiffren für zusammenhängende Blöcke wird als „Betriebsart“ (“mode of operation” im Englischen) bezeichnet und ist von entscheidender Bedeutung für die Sicherheit der verschlüsselten Daten.

Betriebsarten

In der Literatur finden sich verschiedene Betriebsarten, z.B. die historischen Betriebsarten ECB, CBC, OFB oder CFB. Neuere Betriebsarten sind beispielsweise CTR und XTS-AES. Sie unterscheiden sich in ihren kryptografischen Eigenschaften und weisen jeweils spezifische Vor- und Nachteile auf. Das BSI empfiehlt in der genannten Technischen Richtlinie die folgenden Betriebsarten: CCM, GCM, CBC und CTR.

Um dem Detail die Krone aufzusetzen: Blockchiffren verschlüsseln immer genau einen Block und bestimmte Betriebsarten benötigen ebenfalls einen vollständigen Block, um anwendbar zu sein, aber nicht alle Klartexte haben eine Länge von einem exakten Vielfachen eines Blocks des Algorithmus. Um für die Verschlüsselung auf die nötige Blocklänge zu kommen, wird abhängig vom Algorithmus und der Betriebsart der Klartext auf Blocklänge verlängert, dies wird „Padding“ genannt.

Auch für Padding-Verfahren gibt es verschiedene Standards. Von den vom BSI empfohlenen Betriebsarten benötigt nur CBC ein Padding. Das BSI empfiehlt dafür ISO-Padding gemäß ISO/IEC 9797-1-2011 – Methode 2, äquivalent zu NIST SP800-38A Anhang A, Padding gemäß RFC 5652 der IETF (kurz CMS-Padding) oder ESP-Padding gemäß IETF RFC 4303.

Zusammengefasst:

Die Dokumentation von „AES“ oder „AES-256“ in TOMs als verwendetes Verschlüsselungsverfahren ist technisch betrachtet nicht spezifisch genug, da Betriebsart und ggf. Padding nicht beschrieben werden. Konkretere Beschreibungen wären z. B. „AES-256 mit CTR“ oder „AES-256 mit CBC und ESP-Padding“.

| | | , , ,