Details
Crypto - Java

Allgemein - Verschlüsselung im HIT-Protokoll

	HIT unterstützt seit 2004 sichere Datenübertragung mit selbst implementierten Verschlüsselungsverfahren auf Basis von definierten Standard Algorithmen und "open source" Routinen.
	Im Rahmen der Anforderungen an die HIT/ZID zentrale Datenbank und Ihre Benutzer bezüglich Informationssicherheit begründet durch die DSGVO und die Zertifizierung nach BSI-Standard ist es unumgänglich verschiedene Maßnahmen umzusetzen. Insbesondere ist die Kommunikation zwischen den Clients und dem HIT-Server mittels HIT-Protokoll unbedingt verschlüsselt durchzuführen.
	Die Verschlüsselung bei der Übertragung von Daten durch Programme liegt in der Verantwortung des Nutzer. Die zentrale Datenbank HIT/ZID bietet verschiedene Mechanismen zur Unterstützung an.
	Mittelfristig wird die Nutzung des unverschlüsselten HIT-Protokolls unterbunden werden. Noch steht kein konkreter Zeitpunkt fest, aber - falls noch nicht erfolgt - stellen Sie die Übertragung auf sichere Verfahren um!

Verschlüsselung bei Nutzung des HitBatch-Clients

Sofern Nutzer Software einsetzen, die im Hintergrund den von HIT/ZID bereitgestellten HitBatch-Client verwenden, ist die Nutzung von Verschlüsselung einfach realisierbar mittels entsprechender Konfiguration und Parametereinstellungen (siehe CIPHERLEVEL und SVRPUBKEY). Es kann hier aber zu Problemen kommen, wenn keine Updates oder Wartung bzw. Unterstützung vom Hersteller der eingesetzten Primärsoftware gegeben ist.

Verschlüsselung bei Nutzung eigen entwickelter Software

Besonders betroffen sind Nutzer von Software, die das HIT-Protokoll selbst umgesetzt haben. Hier muss entweder der Verschlüsselungsmechanismus in der lokalen Software implementiert werden (siehe Details) oder es kann ein kostenfrei erhältlicher, von Baden-Württemberg entwickelter "Crypto-Proxy" zwischengeschaltet werden - siehe unten bei HitCryptoProxy.

Arbeitsprinzip - Verschlüsselung im HIT-Protokoll

Mit einem asymmetrischen Verschlüsselungsverfahren wird die Anmeldung in HIT bewerkstelligt; war sie erfolgreich, dann können weitere Meldungen entweder unverschlüsselt (wie bisher) oder mit einem symmetrischen Verschlüsselungsverfahren ausgetauscht werden.

Sie erhalten von uns einen Public Key für die asymmetrische Verschlüsselung während der Anmeldung. Für die Anmeldung müssen Sie wie bisher die Anmeldedaten wie BNR15, MBN, PIN, MELD_WG und zusätzlich die Spalten SVR_HELO, RAND_CLI und SESS_KEY mitliefern. Das SVR_HELO erhalten Sie direkt nach der Verbindung, RAND_CLI sind irgendwelche zufälligen Daten beliebiger Länge und das SESS_KEY sind auch beliebige Daten (bis zu einer Länge von 48 Bytes), die dann als symmetrischer Schlüssel zwischen Server und Ihrem Client verwendet werden (sofern Sie den Datenaustausch auch verschlüsseln). Der komplette Anmeldestring wird nun mit dem Public Key verschlüsselt und mit einem vorangestellten $ an den Hitserver gesendet. Der HitServer antwortet Ihnen dann in jedem Fall unverschlüsselt, ob Ihre Anmeldung erfolgreich war oder nicht.

War sie erfolgreich, können Sie entweder wie bisher unverschlüsselt Daten austauschen (Sie senden unverschlüsselt und Sie erhalten unverschlüsselt Antworten) oder aber mit dem von ihnen selbst generierten SESS_KEY die kompletten Anfragen bzw. Meldungen verschlüsseln und mit einem vorangestellten # an HIT senden. Sie erhalten dann auch mit vorangestelltem # eine (oder mehrere) mit Ihrem symmetrischen Schlüssel verschlüsselte Antwort(en) zurück.

Die Spalte SESS_KEY gibt bei der Anmeldung Aufschluss darüber, ob die Datenübertragung nach einer erfolgreichen Anmeldung verschlüsselt wird oder nicht: Wird die Spalte nicht angegeben, dann wird der Datenaustausch nicht verschlüsselt. Wird sie angegeben, dann müssen sämtliche Anfragen und sämtliche Antworten damit entschlüsselt werden.

Wichtig ist: Jede Meldung bzw. Abfrage und Antwort wird separat verschlüsselt, nicht alle Meldungen bzw. Antworten am Stück.

Freigegebener PUBLIC KEY

Folgender Public Key ist ab 08.02.2017 15:30 Uhr (ohne die Zeilenumbrüche) für die Verschlüsselung der Anmeldung in HIT zu verwenden:

48015250010000010100970348B03E911DCCE5ED8F555C2116DBC4D7E96D4C1CDC4BBBAAD26BAA54
B5C834F604F9DFB391459459772FB51D00AFD0FE3A9B2DA724E62113A9E8C95BEF377CB5FCF7FEBE
42E5282A0DA50F01D5D2635DD958F9836CFB4F8B616777C0CF67DB9A5530AD679E321972E4D4F4F3
3DED057CB690417A3B42FBFCE2AD9FDD80C815AF1EC858C796D4EA2F17954E4BFAD08E3E0397FA34
122AC5951D889B06359A401E5506E50FA176B5A77FAB84E25CFCDBF2330AA173DA1156C8B79D6DB6
BFAE828B00811183E63F137648E1FC1786B52D815C248BCADDDF6A17C941414F67A23ADFE82FE761
96B64B96E36F8604FA00E8E357F5AE6C83B992D622D5E9CD9C1D00000003010001

(MD5-Hash des hexadezimal codierten Schlüssels: E599362A39B7FB4F250A64FA24906C54
 und des decodierten binären Schlüssels: ADB00F99A980B924E3BB1159F3037403)

Sie müssen auf jeden Fall die Anmelde-Antworten auf Hinweise bezüglich ungültiger Public Keys überprüfen, da wir diesen Public Key in (un)regelmäßigen Abständen austauschen werden!

Der Schlüssel kann auch als Datei herunter geladen werden hier unter hitserver.pub bzw. unter dem alternativen Datenamen key20161221.pub.

Die Verwendung im HitBatch geschieht dann mittels Parameter: SvrPubKey=@<pfad>key20161221.pub

Dieser Schlüssel läuft nun aus und ist nur noch bis vsl. Juni 2017 gültig:

480152500100000081009CA3D65EAC3318178F31667C3C5E60EE26DD6B090B2671928F8D461B5987
31AE931A2C8D02B593189DCDF17C591634DE10657AA9957CB6D9952B9040C96536F96A4BFDF0F977
03893EF8D52AA91762B85D010AFCE4C3E6CB0338559DECA54D774A6640CB57B8F169B96ED223000F
C950254646FA8AD7AA4361D1BCAE9694477D00000003010001

(MD5-Hash des hexadezimal codierten Schlüssels: 2D0922C029E833501D18DC94CC0339E3
 und des decodierten binären Schlüssels: F12F43B039D0EBAAC1105AE696682DCF)

Praktische Anwendung

Beim Verbinden mit dem HitServer erhalten Sie einen Antwortstring der Form

=0:0/42::HitServer bereit. Version 42, 03.11.2004 13-00h. Sie sind mit dem Echtsystem über den Primär-Server verbunden (Server benutzt neue Betriebstabellen/NEWADS) HI-Tierzeit Nov 26, 2004 10-03-03 AMh Challenge -1867540788734295357

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

Anschließend generieren Sie 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 (max. 48 Bytes). Byteströme müssen generell hexencoded werden.

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

*1:XS:LOGON/BNR15;PIN;MELD_WG;SVR_HELO;RAND_CLI;SESS_KEY:276090000000015;900015;4;HitServer bereit. Ver...;01234567890ABCDEF;01234567890ABCDEF

Dieser komplette String wird mit dem Public Key verschlüsselt (der erhaltene Binär-String wird hexencoded) und mit einem $ vorangestellt an HIT gesendet, also etwa als

$8559DECA54D774A6640CB57B8...

HIT packt die Daten mit dem nur dem HIT bekannten Private Key aus, überprüft Ihre Anmeldung und antwortet Ihnen unverschlüsselt. Die Antwort muss natürlich wie alle anderen auf Fehlerhinweise ausgewertet werden.

Bei erfolgreicher Anmeldung können Sie nun wie bisher unverschlüsselt mit HIT kommunizieren.

Wollen Sie jedoch die weitere Kommunikation verschlüsseln, verwenden Sie dafür Ihren selbst generierten SESS_KEY. Bauen Sie wie bisher den HIT-Befehl zusammen, den Sie an HIT schicken wollen, verschlüsseln den komplett mit dem SESS_KEY (der erhaltene Binär-String wird hexencoded) und senden ihn mit einem # vorangestellt an HIT. HIT packt die Daten mit dem SESS_KEY aus (Sie haben HIT ja den Schlüssel während der Anmeldung mitgeteilt), führt seine Aktion(en) aus und antwortet Ihnen mit einer mit SESS_KEY verschlüsselten Nachricht (auch die ist mit einem # vorangestellt). Die Antwort(en) müssen Sie dann nur mit Ihrem SESS_KEY wieder auspacken (ohne das # natürlich) und erhalten die HIT-Antworten, die Sie wie bisher zerlegen und auswerten.

Wir haben unseren HitBatch dahingehend erweitert, dass dieser auch mit der hier beschriebenen Methodik verschlüsselt Daten austauschen kann. Für Selbstprogrammierer steht natürlich auch ein aktualisiertes HitUpros zur Verfügung (die Klassen HitSecurity und HitSecurityKeys werden dafür benötigt).

Es gibt inzwischen von uns eine .NET Assembly, mit der die Verschlüsselung in eigene Windows-Programme eingebaut werden kann.

HitCryptoProxy

Der HitCryptoProxyServer ermöglicht als Proxy die verschlüsselte Kommunikation zwischen dem Herkunftssicherungs- und Informationssystem für Tiere (HIT) und einem unverschlüsselt kommunizierenden Client. Über den HitCryptoProxyServer kann sowohl mit dem HIT Produktionssystem als auch mit dem HIT Testsystem kommuniziert werden.

Achtung: Dieser Proxy ist nur für einen internen "Rechenzentrumsbetrieb" und nicht als "Endkundentool" gedacht!

Download von Programm, inklusive Sourcecode, Dokumentation und Installationsanleitung hier unter: Dateibereich/hitcryptoproxy.zip

Kurzanleitung zu Installation:

1. Datei entpacken
2. Unter hitcryptoproxy\conf die HitCryptoProxyServer.properties anpassen ( PublicKey, ThreadPoolSize und hier evtl. Port ändern)
3. Unter hitcryptoproxy\bin\ die service.bat anpassen (meist nur die ARCHITECTURE=x86, evtl. Umgebungsvariablen etc. ).
4. Den Service über service.bat install installieren.
    

Zusätzliche Hinweise für Kurzanleitung zu Installation:

	der Befehl "service install" ist mit Administrator-Rechten auszuführen
	Je nach Windows-Version muss dem HitCryptoProxyServer-Dienst noch erlaubt werden mit Administratorrechten ausgeführt zu werden