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 |
m Bytes |
m Bytes Modulus des RSA-Verfahrens |
| RSA Exponent |
4 Bytes |
Länge e in Bytes als BigEndian |
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.
.
| 
