Implementierung Verschlüsselung im HIT-Protokoll

HIT/ZID unterstützt seit 2004 sichere Datenübertragung mit selbst implementierten Verschlüsselungsverfahren auf Basis von Standard-Algorithmen und Open Source.
Den veröffentlichten Public Key findet man hier.

Die Verschlüsselung besteht aus zwei Teilen: asymmetrische Verschlüsselung der Anmeldung und symmetrische Verschlüsselung weiterer Befehle und der jeweils dazugehörigen Antworten. Ohne verschlüsselte Anmeldung ist keine symmetrische Verschlüsselung des Datenaustausches möglich.

Ablauf verschlüsselte Anmeldung

Als asymmetrische Verschlüsselung wird das RSA-Verfahren verwendet, das aus einem Private Key und als Teil davon einen Public Key besteht. Diese Verschlüsselung erlaubt das Verschlüsseln von Nachrichten mit dem Public Key oder Private Key und das Entschlüsseln einer verschlüsselten Nachricht nur mit dem Private Key. Um die Blockgrößen des Algorithmus effizient auszunutzen, wird der Trailing Bit Complement padding algorithm angewandt.

Die Bitlänge von 2048 oder mehr Bits erlaubt eine sehr große Sicherheit gegenüber Brute Force-Attacken. Da bei der Verschlüsselung der Anmeldedaten drei Blocks mit zufälligen Zeichen (einer kommt vom Server) enthalten sind, macht es das Attackieren für einen Angreifer schwieriger.

Für die Initiierung der verschlüsselten Anmeldung sind zusätzlich die Spalten SVR_HELO und RAND_CLI notwendig. Optional wird zeitgleich mit SESS_KEY und ggf. ENC_SYM der verschlüsselte Datenaustausch initiiert. Details zur Spalte ENC_SYM siehe unten.

Client	verbindet sich mit HIT-Server z.B. an Port 2222
Server	generiert ein `SVR_HELO` und meldet z.B. `=0:0/2600::HitServer bereit. ... 6438108607920216050`
Client	extrahiert das `SVR_HELO` aus der Antwort: es ist die komplette Zeichenkette nach dem dritten `:` - gelb markiert. Danach generiert man sich einen zufälligen `SESS_KEY` einer zum `ENC_SYM` passenden Länge und Zufallsdaten `RAND_CLI` einer beliebigen Länge (mind. 30 Bytes). Die binären Zufallsdaten werden jeweils in einen Hexstring gewandelt. Zur Anmeldung werden alle benötigten Daten als HIT-Anfrage zusammengefaßt, mit dem öffentlich bekannten Public Key asymmetrisch verschlüsselt, die Bytes als Hexstring umgewandelt, ein `$` vorangestellt und an den Server gesendet. Mit Public Key zu verschlüsselnde Datenanfrage z.B. (mit etwas kürzeren Hexstrings dargestellt): `*1:XS:LOGON/ BNR15;MBN;PIN;MELD_WG;SVR_HELO;RAND_CLI;ENC_SYM;SESS_KEY: 276009999999999;0;123456;3; HitServer bereit. ... 6438108607920216050; F5EB86C717F47F2BDA36537A5E06F7FDAEC0AF330B34F50F; Blowfish/CBC/TBC; 5330C23D4E70A28CEF843618` Der verschlüsselte Text wird (in Hexadezimalform) als `$........` an den Server geschickt.
Server	erkennt am einleitenden `$`, dass eine asymmetrisch verschlüsselte Nachricht vorliegt. Diese entschlüsselt er mit dem nur ihm bekannten Private Key. Die Bestandteile werden extrahiert, `SVR_HELO` mit dem eigenen verglichen und wenn identisch, werden die optional vorhandenen `SESS_KEY` und `ENC_SYM` für die weitere symmetrische Verschlüsselung gemerkt. Ist Entschlüsselung fehlgeschlagen bzw. lieferte sie illegale Daten oder ist `SVR_HELO` nicht mit der der Session identisch oder stimmen die HIT-Anmeldeinformationen nicht, wird eine unverschlüsselte Fehlermeldung analog bisher zurückgeliefert und der `LOGON` trotz eventuell korrekter Anmeldedaten als fehlgeschlagen aufgefasst. In dem Fall liefert der Server dann ein oder mehrere unverschlüsselte Antworten (Zeilen beginnend mit `%` und `=`), wenn vorher keine aktive symmetrisch verschlüsselte Sitzung bestand. Bestand eine, dann wird die Antwort weiterhin mit dem vorherigen/alten `SESS_KEY` und `ENC_SYM` verschlüsselt! Im Erfolgsfall werden diese Antworten im Falle eines gelieferten `SESS_KEY` und `ENC_SYM` zeilenweise symmetrisch verschlüsselt und gesendet.
Client	erhält symmetrisch verschlüsselt (siehe unten) oder unverschlüsselt ein oder mehrere Antworten, wenn das Passwort korrekt war. Im Falle eines gelieferten `SESS_KEY` und `ENC_SYM` kann nun fortan ein symmetrisch verschlüsselter Datenaustausch durchgeführt werden.

Die Erzeugung der zufälligen Daten für z.B. den SESS_KEY oder RAND_CLI wird über einen Pseudo Random Number Generator ("PRNG") bewerkstelligt. Der für HIT implementierte greift auf ein Hashverfahren zurück, um anhand dessen zufällige Zeichen zu generieren.
Unterstützung für eine Reproduzierbarkeit der Zufallsreihen ist vorhanden. Wenn es nicht reproduzierbar sein soll, wird intern als Startwert ("seed") der Systemtimestamp (in Millisekunden) verwendet, der vor der Anwendung durch Bitoperationen etwas umgestellt wird.

Ablauf verschlüsselter Datenaustausch

Symmetrische Verschlüsselungen besitzen folgende Eigenschaft: Verschlüsselt man eine Originalnachricht mit demselben Schlüssel zweimal (sprich Original in Verschlüsselt und dann Verschlüsselt erneut mit gleichem Verfahren), erhält man wieder die Originalnachricht. Daher besitzen die Methoden nur eine Verschlüsselung und keine explizite Entschlüsselung (wäre ja identisch mit der Verschlüsselung).

Voraussetzung für den verschlüsselten Datenaustausch ist eine erfolgreiche asymmetrisch verschlüsselte Anmeldung, aus der SESS_KEY und optional ENC_SYM zum Ver- und Entschlüsseln verwendet wird.

Als symmetrische Verschlüsselung wird standardmässig Blowfish verwendet, das Daten mit einem (bei der Anmeldung) selbst vergebenen zufälligen Schlüssel in 64bit-Blöcken verschlüsseln und auch mit dem selben Schlüssel wieder entschlüsseln kann (=symmetrisch). Standardmässig wird auch hier der Trailing Bit Complement padding algorithm angewandt, um den letzten Block an die Blockgröße des Algorithmus anzupassen.

Seit Februar 2024 können weitere Algorithmen, Blockmodi und Paddingverfahren verwendet werden; Details dazu unten.

Client

ist verbunden mit einem HIT-Server und die Anmeldung war erfolgreich.

Anfrage an HIT-Server zusammenbauen, z.B. als Zugangsmeldung:

*3:XS/ZUGANG:BNR15;LOM;ZUGA_DAT:01 234 567 8901;DE 01 234 56789;01.01.2024

Diese wird mit dem Key aus SESS_KEY und ggf. mit der Option ENC_SYM symmetrisch verschlüsselt, dann die Bytes als Hexstring umgewandelt, ein # vorangestellt und an den Server gesendet.

Server

erkennt am einleitenden

, dass eine symmetrisch verschlüsselte Nachricht vorliegt und decodiert diese mit dem ihm auch bekannten SESS_KEY und der beim LOGON unter ENC_SYM hinterlegten Transformationsvorschrift.

Nach der Verarbeitung der Anfrage (Meldung oder Abfrage) liefert der Server in jedem Fall auch symmetrisch mit dem SESS_KEY verschlüsselt die Daten und Antwort(en) zur gesendeten Anfrage. Diese sind wie die Anfrage ebenfalls als Hexstring codiert und mit einem # als Präfix versehen.

Client erkennt in der Antwort vom Server am einleitenden #, dass eine symmetrisch verschlüsselte Nachricht vorliegt und decodiert diese mit dem ihm auch bekannten SESS_KEY und der beim LOGON unter ENC_SYM hinterlegten Transformationsvorschrift. Beginnt die Antwort mit %, dann ist solange zu lesen und zu decodieren, bis die Antwortzeile mit = beginnt.

Dieser dreistufige Ablauf ist für jede Anfrage und den dazugehörigen 1..n Antworten essentiell.

ENC_SYM zur Steuerung symmetrischer Verschlüsselung

Der Parameter ENC_SYM beim LOGON wurde im Aug. 2021 eingeführt, um einen alternativen Blockmodus für den Blowfish-Cipher aktivieren zu können, und war numerisch. Der HitBatch bekam dafür einen weiteren Ini-Parameter spendiert.

Seit Januar 2024 steuert der Parameter die symmetrische Verschlüsselung als Ganzes, indem eine Transformationsvorschrift gemäß dem Java Cryptographic Extensions (JCE) Framework als Zeichenkette mitgegeben wird. Das Format ist "algorithm/mode/padding", wobei algorithm für den Namen des Cipher steht, mode den Blockmodus und padding die Auffüllvorschrift festlegt. Folgende Transformationskomponenten können miteinander kombiniert werden:

	algorithm: `Blowfish`, `TripleDES`, `AES`, `Twofish`
	mode: `ECB`, `CBC`, `CFB`, `OFB`
	padding: `TBC`, `PKCS7`

Wird beim LOGON kein ENC_SYM angegeben, wird abwärtskompatibel "Blowfish/CBC/TBC" verwendet. Der HitBatch unterstützt ab Version 62 den Parameter ebenfalls als Zeichenkette (Version 61 "versteht" nur numerisch!).

Der HitServer verwendet für die Transformationen die Crypto-Bibliothek Bouncy Castle ab Version 1.76 (Stand Februar 2024). Auch der HitBatch ab Version 62 kann die Bibliothek mit verwenden (muss es aber nicht). Ohne Bouncy Castle kann nur "Blowfish/ECB/TBC" oder "Blowfish/CBC/TBC" verwendet werden!

Die numerischen Parameter des ENC_SYM sind abwärtskompatibel weiterhin nutzbar: 0 stand für nicht verschlüsseln, 1 für "Blowfish/ECB/TBC" und 2 für "Blowfish/CBC/TBC". Man wird aber über einen Hinweis gebeten (kein muss), diesen auf die Transformationsvorschrift (d.h. in Textform) umzustellen. Ggf. ist dafür ein Update des HitBatch auf Version 62 oder höher notwendig.

Verschlüsselungsdetails

Asymmetrisch

Der veröffentlichte Schlüssel besteht aus einem Magic (4 Bytes, zur Identifizierung), einer Versionsnummer (1 Byte), dem Modulus und dem Exponenten des RSA-Verfahrens:

Komponente	Länge	Beschreibung
Magic	1 Byte	Zeichen 'H' (für HIT) als Byte (=0x48)
	1 Byte	Format, derzeit nur 0x01 für 'RAW'
	1 Byte	Zeichen 'R' (für RSA) als Byte (=0x52)
	1 Byte	Zeichen 'P' (für PublicKey) als Byte (=0x50)
Version	1 Byte	derzeit nur 0x01
RSA Modulus	4 Bytes	Länge `m` in Bytes als BigEndian
RSA Modulus	`m` Bytes	`m` Bytes Modulus des RSA-Verfahrens
RSA Exponent	4 Bytes	Länge `e` in Bytes als BigEndian
RSA Exponent	`e` Bytes	`e` Bytes Exponent des RSA-Verfahrens

Aus der Länge des Modulus ergibt sich die Blockgröße, mit der verschlüsselt wird (sollte ein Mehrfaches von 1024 bit sein). Es werden 1..n Blöcke dieser Größe separat verschlüsselt und aneinandergereiht. Ein ggf. kürzerer letzter Block wird mit dem TBC (Trailing Bit Complement)-Verfahren aufgefüllt, bevor dieser verschlüsselt wird.

Symmetrisch

Bis Januar 2024 konnte der Datenaustausch nur mit dem Blowfish-Cipher und zwei Blockmodi bewerkstelligt werden. Seitdem sind sowohl weitere Cipher als auch Blockmodi möglich, wenn (nur dann) die Bouncy Castle-Bibliothek verwendet wird. Dies wird beim LOGON via Spalte ENC_SYM für die Anmeldesitzung mitgegeben (=Transformationsvorschrift).

Der für die symmetrische Verschlüsselung verwendete Schlüssel wird vom Client zufällig und in der Länge (=Blockgröße beim Ver-/Entschlüsseln) passend zum verwendeten Cipher angelegt. Dieser wird als Bytearray lediglich in einen Hex-String gewandelt und hat keinerlei "Magic" oder Formatierung. Der Hex-String wird beim LOGON als SESS_KEY (mit der Transformationsvorschrift in ENC_SYM) mitgegeben. Damit arbeiten Server und Client mit dem selben Schlüssel und der selben Transformationsvorschrift und können Daten in beide Richtungen austauschen.

Alle erlaubten Blockmodi ausser ECB erfordern zusätzlich zum Schlüssel einen IV (initialization vector). Diesen muss man selbst zufällig erzeugen und als ersten Block in den Ausgabestream schreiben, anschließend folgen 1..n verschlüsselte Datenblöcke. Ein ggf. kürzerer letzter Block wird mit dem in der Transformationsvorschrift mitgegebenen Padding-Verfahren aufgefüllt, bevor dieser verschlüsselt wird.
Zum Entschlüsseln greift man den ersten Block als IV ab und entschlüsselt damit (zusammen mit dem Schlüssel) die weiteren verschlüsselten Blöcke.

Bevor die Frage aufkommt, ob das unverschlüsselte Mitschicken eines IV nicht unsicher sei, wird auf das folgende Zitat aus Applied Cryptography von Bruce Schneier verwiesen:

Assume that we have a message of several blocks: B1, B2, ..., Bn.
B1 is encrypted with the IV.
B2 is encrypted using the ciphertext of B1 as the IV.
B3 is encrypted using the ciphertext of B2 as the IV, and so on.
So, if there are n blocks, there are n-1 exposed IVs, even if the original IV is kept secret.
So there's no reason to keep the IV secret; the IV is just a dummy ciphertext block - you can think of it as B0 to start the chaining.

Java-Sourcecode

Der Sourcecode in Java, der oben beschriebene Verfahren implementiert, kann aus der HitUpros-Bibliothek entnommen werden, welcher beim HitBatch-Client als hitbatch-sources.zip verfügbar ist. Die Klasse de.hi_tier.hitupros.crypto.HitCrypto ist der Einstiegspunkt zur Anwendung der Ver- und Entschlüsselung, mehr Details hierzu.