Arbeitsprinzip - Verschlüsselung im HIT-Protokoll

Mit einem asymmetrischen Verschlüsselungsverfahren wird die sichere Anmeldung in HIT bewerkstelligt. War sie erfolgreich, dann können weitere Meldungen entweder unverschlüsselt oder mit einem symmetrischen Verschlüsselungsverfahren ausgetauscht werden.

Es gibt somit diese Varianten:

	komplett unverschlüsselt
	asymmetrisch verschlüsselte Anmeldung, dann unverschlüsselter Datenaustausch
	asymmetrisch verschlüsselte Anmeldung, dann symmetrisch verschlüsselter Datenautausch

Für eine asymmetrisch verschlüsselte Anmeldung nutzt man den von uns erhaltenen Public Key zusammen mit einer erweiterten Anmeldung. Werden anschließend symmetrisch verschlüsselt Daten ausgetauscht, wird der bei der Anmeldung verwendete Schlüssel dafür genutzt.

Verschlüsselte Anmeldung

	Anmeldebefehl zusammenstellen: zusätzlich zu den bisherigen Anmeldedaten (wie BNR15, MBN, PIN, MELD_WG, TIMEOUT etc) die Spalten SVR_HELO, RAND_CLI und optional SESS_KEY und ENC_SYM mit deren Daten hinzufügen Das SVR_HELO erhält man als erste Antwort nach der Verbindung mit einem HitServer (nur den Daten-Teil, nicht alles) RAND_CLI sind zufällige Daten beliebiger Länge (mind. 30 Bytes) ein SESS_KEY muss mitgeliefert werden, wenn nach der Anmeldung der Datenaustausch auch verschlüsselt werden soll. Dies sind ebenfalls beliebige Daten, die dann als Schlüssel für die symmetrische Verschlüsselung zwischen Server und Ihrem Client (bidirektional) verwendet werden zusätzlich kann ENC_SYM mitgeliefert werden (wenn SESS_KEY angeben), um eine spezifische symmetrische Verschlüsselung festzulegen. Wird die Spalte nicht angeben, wird wie bisher verschlüsselt. Die Länge von SESS_KEY ist abhängig vom angegebenen ENC_SYM! Die zufällig generierten Bytes für RAND_CLI und SESS_KEY müssen für die Verwendung im HIT-Protokoll hex-encodet werden.
	Der so zusammengestellte, komplette Anmeldestring wird schließlich mit dem Public Key verschlüsselt, hex-encodet und mit einem vorangestellten $ an den HitServer gesendet
	Wenn SESS_KEY mitgeliefert wurde, antwortet der HitServer dann symmetrisch verschlüsselt. Anderenfalls unverschlüsselt. Beides unabhängig davon, ob die eigentliche Anmeldung erfolgreich war oder nicht

Verschlüsselter Datenaustausch

Nur, wenn bei der verschlüsselten Anmeldung die selbstgenerierte Spalte SESS_KEY mitgeliefert wurde und die Anmeldung als solches erfolgreich war:

	vollständige Meldung oder Abfrage mit dem SESS_KEY und ggf. ENC_SYM symmetrisch verschlüsseln und mit einem vorangestellten # an den HitServer senden
	gilt auch für Anfragen im Blockmodus, wobei dort jede einzelne Meldung/Abfrage mit dem SESS_KEY und ggf. ENC_SYM verschlüsselt und jeweils mit einem vorangestellten # an den HitServer gesendet werden muss
	der HitServer antwortet ebenfalls mit einer oder mehreren Zeilen mit jeweils vorangestellten #, die dann einzeln mit dem SESS_KEY zu entschlüsseln sind

Wichtig: jede Meldung/Abfrage und Antwort wird separat ver- bzw. entschlüsselt, nicht alle Meldungen bzw. Antworten am Stück.

Praktische Anwendung

Beim Verbinden mit dem HitServer erhält man einen Antwortstring der Form

=0:0/42::HitServer bereit. Version 2600, 01.01.2020 00-00. Sie sind mit dem Produktionssystem P1B_HZ05 verbunden. 
(Server benutzt neue Betriebstabellen/NEWADS) HI-Tierzeit 01.01.2020, 00-00-00h Challenge 14715426292224812683

Die Daten der Antwort merkt man sich komplett (d.h. der vierte Teil der Hit-Antwort, beginnend mit HitServer bereit. Ver...) als Feld SVR_HELO.

Anschließend generiert man sich einen zufälligen Bytestrom für das Feld RAND_CLI (Länge beliebig, aber ausreichend, z.B. 50 Bytes).

Gleiches gilt für das Feld SESS_KEY (passend zu ENC_SYM). Byteströme müssen generell hexencoded werden, da das HIT-Protokoll keine binären Daten handhaben kann.

Der Anmeldestring wird dann wie bisher zusammengestellt und um die vier genannten Felder erweitert, z.B..

*1:XS:LOGON/BNR15;PIN;MELD_WG;SVR_HELO;RAND_CLI;SESS_KEY:09 000 000 0001;Aaaa$900001;4;HitServer bereit. Ver...;01234567890ABCDEF;01234567890ABCDEF

Dieser komplette String wird mit dem Public Key verschlüsselt (auch dieser erhaltene Bytestrom wird hexencodet) und mit einem $ vorangestellt an den HitServer gesendet, also etwa als

$8559DECA54D774A6640CB57B8...

Der HitServer packt die Daten mit dem nur dem HitServer bekannten Private Key aus, überprüft den LOGON und antwortet entweder symmetrisch verschlüsselt oder unverschlüsselt. Letzteres kann passieren, wenn mit dem LOGON semantisch etwas nicht stimmt oder gar kein SESS_KEY bei der Anfrage mitgesendet wurde. Die ggf. symmetrisch entschlüsselte Antwort(en) müssen natürlich wie alle anderen Antworten auf Fehlerhinweise hin ausgewertet werden.

Wurde ein selbst generierter SESS_KEY bei der Anmeldung mitgesendet, dann werden (bis zur Abmeldung) alle weiteren Meldungen oder Abfragen mit dem SESS_KEY und Option ENC_SYM zeilenweise symmetrisch verschlüsselt, jeweils der erhaltene Bytestrom hexencodet und jeweils mit einem # vorangestellt an den HitServer gesendet.

Die dann erhaltenen zeilenweise symmetrisch verschlüsselten Antworten sind jeweils wieder in einen Bytestrom zu hexdecodieren (natürlich ohne dem vorangestellten #) und schließlich jeweils mit dem SESS_KEY zu entschlüsseln. Dann können wie gewohnt die Antworten zerlegt und ausgewertet werden.

Das Verfahren ist hier noch detailierter aufgezeigt - insbesondere für Programmierer interessant(er), da technische Details genannt werden.