Zur Homepage www.HI-Tier.de Verschlüsselung: Details
Zurück Home Nach oben Weiter
Öffentlicher Bereich für Entwickler

 

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.

Ablauf verschlüsselte Anmeldung

Als asymmetrische Verschlüsselung wird das RSA-Verfahren verwendet. Dieses besteht aus einem Public Key und Private Key, welche getrennt voneinander zum Ver- und Entschlüsseln verwendet werden. Um die Blockgrößen des Algorithmus effizient auszunutzen, wird der Trailing Bit Complement padding algorithm angewandt.

HitServer

 

Client

 
verbindet sich mit HIT-Server z.B. an Port 2222
generiert ein SRV_HELO und meldet z.B.
=0:0/2600::HitServer bereit. ... 6438108607920216050

 
 
Zur Verschlüsselung wird das SRV_HELO aus der Antwort extrahiert: es ist die komplette Zeichenkette nach dem dritten : - links gelb markiert.
Danach generiert man sich einen zufälligen SESS_KEY einer beliebigen Länge (max. 48 Bytes) und Zufallsdaten RAND_CLI einer beliebigen Länge (mind. 30 Bytes). Die binären Zufallsdaten werden jeweils in einen Hexstring gewandelt.
NEU: die Spalte ENC_SYM kann (muss nicht) zusätzlich angegeben werden, um die symmetrische Verschlüsselung zu steuern - Details unten.
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;SRV_HELO;RAND_CLI;SESS_KEY;ENC_SYM:
276009999999999;0;123456;3;
HitServer bereit. ... 6438108607920216050;
F5EB86C717F47F2BDA36537A5E06F7FDAEC0AF330B34F50F;
5330C23D4E70A28CEF843618;2

Der verschlüsselte Text wird als $........ (in Hexadezimalform) an den Server geschickt.

Der 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, SRV_HELO mit dem eigenen verglichen und wenn identisch, wird der SESS_KEY für die weitere symmetrische Verschlüsselung gemerkt. Ist Entschlüsselung fehlgeschlagen bzw. lieferte sie illegale Daten oder ist SRV_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 korrekter Anmeldedaten als fehlgeschlagen aufgefasst.

In dem Fall liefert der Server dann ein oder mehrere unverschlüsselte Antworten (Zeilen beginnend mit % und =).

Im Erfolgsfall werden diese Antworten im Falle eines gelieferten SESS_KEYs zeilenweise symmetrisch verschlüsselt und gesendet.


 
    War PIN korrekt, erhält Client symmetrisch verschlüsselt (siehe unten) oder unverschlüsselt ein oder mehrere Antworten. Diese sind wie im weiteren Verlauf immer auszuwerten.

Nun kann fortan ein symmetrisch verschlüsselter Datenaustausch durchgeführt werden.

Ablauf verschlüsselter Datenaustausch

Als symmetrische Verschlüsselung wird 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).

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

Auch hier wird der Trailing Bit Complement padding algorithm angewandt, um den letzten Block an die Blockgröße des Algorithmus anzupassen.

HitServer

 

Client

    Voraussetzung:
Verbindung zum HIT-Server steht und verschlüsselte Anmeldung war erfolgreich
 
Anfrage an HIT-Server zusammenbauen, z.B. als Abgangsmeldung:

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

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.

NEU: Einführung des Steuerparameters ENC_SYM, siehe unten.

Der Server erkennt am einleitenden #, dass eine symmetrisch verschlüsselte Nachricht vorliegt und decodiert diese mit dem ihm auch bekannten SESS_KEY.

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.


 
    Die Antwort vom Server erkennt der Client am einleitenden #, dass eine symmetrisch verschlüsselte Nachricht vorliegt und decodiert diese mit dem ihm auch bekannten SESS_KEY.

NEU: Einführung des Steuerparameters ENC_SYM, siehe unten.

ENC_SYM zur Steuerung symmetrischer Verschlüsselung

TODO & at work

Achtung: aufgrund von Sicherheitsauflagen wird die bisherige Methode, über einen Codeset die symm. Verschlüsselung zu steuern, derzeit entfernt und auch das Format einer verschlüsselten Zeile wird "zurückgesetzt". An dessen Stelle wird ein flexibleres Verfahren treten...

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.HitSecurity ist der Einstiegspunkt zur Anwendung der Ver- und Entschlüsselung, mehr Details hierzu.

 

 


© 1999-2021 Bay.StMELF, verantwortlich für die Durchführung sind die  Stellen der Länder , fachliche Leitung ZDB: Frau Dr. Kaja.Kokott@hi-tier.de, Technik: Helmut.Hartmann@hi-tier.de
Seite zuletzt bearbeitet: 03. November 2021 16:34, Anbieterinformation: Impressum - Datenschutz - Barrierefreiheit