Clients kommunizieren unverschlüsselt mit UTM-Services. Damit besteht die Möglichkeit, dass Unbefugte auf der Leitung mitlesen und verändern (Man-in-the-Middle-Angriff) und z.B. Passwörter für UTM-Benutzerkennungen oder sensible Benutzerdaten ermitteln. Um dies zu verhindern, unterstützt openUTM die Verschlüsselung von Passwörtern und Benutzerdaten für Client-Verbindungen.
Die Verschlüsselung kann bei openUTM auch dazu verwendet werden, den Zugang durch Clients und den Zugriff auf bestimmte Services zu kontrollieren.
openUTM verwendet zum Verschlüsseln ein Hybrid-Verfahren. Dieses ist eine Kombination aus asymmetrischer Verschlüsselung des AES-Schlüssels zum Schlüsselaustausch und symmetrischer Verschlüsselung für die Daten mit diesem AES-Schlüssel.
Verschlüsselungsverfahren
Die Verschlüsselung von Anwenderdaten auf Verbindungen zu UTM-Anwendungen läuft immer nach dem gleichen Muster ab: Zuerst wird zwischen den beiden Partnern ein Session Key ausgetauscht bzw. vereinbart und im Anschluss daran werden die Anwenderdaten mit diesem Session Key verschlüsselt zwischen den beiden Partnern übertragen.
Als Session Key wird bei allen Encryption Levels ein AES-Schlüssel mit einer Länge von 128 Bits verwendet.
Bei den Encryption Levels 3 und 4 geschieht der Austausch des Session Keys mit dem RSA-Algorithmus. Der Client verschlüsselt dabei den von ihm erzeugten AES-Schlüssel mit dem öffentlichen RSA-Schlüssel der UTM-Anwendung. Dabei wird abhängig vom Encryption Level ein RSA-Schlüssel mit einer Länge von 1024 oder 2048 Bits verwendet.
Bei Encryption Level 5 geschieht die Vereinbarung des AES-Schlüssels mit dem Elliptic Curve Diffie Hellman Verfahren. Der RSA Schlüssel der UTM-Anwendung wird bei diesem Verfahren nur noch zum Signieren des öffentlichen Diffie-Hellman Schlüssels der UTM-Anwendung verwendet, um den Ursprung des Diffie-Hellman Schlüssels zu belegen. Das Diffie Hellman Verfahren hat den Vorteil, dass der AES-Schlüssel nicht vom Client an den Server übertragen werden muss. Damit bietet dieses Verfahren Perfect Forward Secrecy.
Zur Verschlüsselung der Anwenderdaten wird bei Encryption Level 3 und 4 das AES-CBC Verfahren verwendet. Bei Encryption Level 5 kommt das neuere AES/GCM Verfahren zum Einsatz. AES/GCM bietet den Vorteil, dass zusätzlich zur Verschlüsselung der Anwenderdaten weitere Protokollteile der Nachricht durch einen Message Authentication Code (MAC) gegen Veränderungen geschützt werden.
Tabelle 6: Generierte Verschlüsselungsebenen und zugehörige Schlüssel
Generierte Verschlüsselungsebene | Öffentlicher Schlüssel | Symmetrischer Schlüssel | authentifizierte Verschlüsselung | perfect forward secrecy |
TRUSTED | kein Schlüssel | kein Schlüssel | nein | nein |
NONE | situationsabhängig | situationsabhängig | situationsabhängig | situationsabhängig |
3 | RSA -1024 Bit | AES (128-Bit) | nein | nein |
4 | RSA - 2048 Bit | AES (128-Bit) | nein | nein |
| 5 (nicht im BS2000) | ECDH secp256k1 | AES (128-Bit) | ja | ja |
Jedes RSA-Schlüsselpaar kann in openUTM per Administration geändert und aktiviert werden. Nur aktivierte RSA-Schlüssel werden auch verwendet. Zusätzlich besteht für den UPIC-Client die Möglichkeit, den bei LEVEL 3 und 4 den öffentlichen Schlüssel lokal zu hinterlegen, um eine Man-in-the-Middle-Attacke zu erschweren. Beim Verbindungsaufbau wird der empfangene öffentliche Schlüssel mit dem hinterlegten öffentlichen Schlüssels verglichen.
Der aktive RSA-Schlüssel kann über Aufrufe der UTM-Administrationsschnittstelle oder mit dem Administrationstool openUTM-WinAdmin ausgelesen und gelöscht werden.
Voraussetzungen
Voraussetzung für die Verschlüsselung zwischen openUTM und UPIC-Clients ist, dass auf beiden Seiten die Softwarevoraussetzungen zum Verschlüsseln vorhanden sind.
Wenn bei openUTM für diesen Partner eine Verschlüsselungsebene 3 bis 5 generiert ist, diese Voraussetzungen jedoch nicht erfüllt sind, dann wird der Verbindungsaufbau abgelehnt. Dies hat folgenden Grund:
Der Client unterstützt keine Verschlüsselung, weil die Verschlüsselungssoftware nicht verfügbar ist
Ablauf
Beim Verbindungsaufbau des Client zur UTM-Anwendung erhält openUTM vom Client die Information, ob er Verschlüsselung unterstützt.
Wenn die Verbindung zwischen Client und Server zustande gekommen ist und von beiden Partnern Verschlüsselung unterstützt wird, dann sendet der Client an den Server die Information, bis zu welcher Verschlüsselungsebene er die Verschlüsselung unterstützt. Der Server vergleicht dies mit seiner Generierung für diesen Partner.
Abhängig von der Verschlüsselungsebene, die für den Client in der UTM-Anwendung generiert ist, können unterschiedliche Situationen auftreten:
ENCRYPTION-LEVEL=TRUSTED
Der Client ist als vertrauenswürdig generiert. In diesem Fall fordert openUTM keine Verschlüsselung an. Der Client kann auch keine Verschlüsselung erzwingen.
ENCRYPTION-LEVEL=NONE
In diesem Fall sendet die UTM-Anwendung den RSA-Schlüssel mit der größten Modulo-Länge an den Client. Dieser RSA-Schlüssel bestimmt die Verschlüsselungsebene.
Der Client erzeugt einen AES-Schlüssel. Der Client verschlüsselt den AES-Schlüssel mit dem RSA-Schlüssel und schickt ihn an den Server zurück. openUTM speichert den Schlüssel für die spätere Verwendung auf dieser Verbindung.
Es werden standardmäßig nur Passwörter verschlüsselt.
Der Client kann jedoch die Verschlüsselung der Benutzerdaten über das Schlüsselwort ENCRYPTION_LEVEL in der upicfile oder über den Aufruf Set_Conversation_Encryption_Level erzwingen.
Hinweis
Wenn die Verschlüsselungsfunktionalität nicht installiert ist, dann werden Passwörter und Benutzerdaten unverschlüsselt ausgetauscht.
ENCRYPTION-LEVEL= 3 oder 4
Die UTM-Anwendung sendet den öffentlichen RSA-Schlüssel, der zu der jeweiligen Ebene gehört. Dieser hat die Länge 1024 oder 2048, siehe Tabelle 6.
Der Client erzeugt einen AES-Schlüssel, verschlüsselt ihn mit dem RSA-Schlüssel und sendet ihn an die UTM-Anwendung zurück. openUTM speichert den AES-Schlüssel für die spätere Verwendung auf dieser Verbindung.
Es werden Passwörter und Benutzerdaten verschlüsselt.
Der Aufruf Set_Conversation_Encryption_Level oder der Eintrag ENCRYPTION_LEVEL in der upicfile haben keine Wirkung.
ENCRYPTION-LEVEL= 5
Der UPIC-Client und die UTM-Anwendung vereinbaren mit dem ECDH-Verfahren ein gemeinsames Secret.
Der Client erzeugt einen AES-Schlüssel, verschlüsselt ihn mit dem gemeinsam ausgehandelten Secret und sendet ihn an die UTM-Anwendung zurück. openUTM speichert den AES-Schlüssel für die spätere Verwendung auf dieser Verbindung.
Es werden Passwörter und Benutzerdaten verschlüsselt.
Der Aufruf Set_Conversation_Encryption_Level oder der Eintrag ENCRYPTION_LEVEL in der upicfile haben keine Wirkung.
Die Verschlüsselungsebene client-level der Conversation kann mit dem Aufruf Extract_Conversation_Encryption_Level ausgelesen werden, am besten nach dem Aufruf Allocate.
Verschlüsselung bei geschütztem TAC
Ein Vorgang einer UTM-Anwendung kann geschützt werden, indem dem zugehörigen TAC per Generierung im Operanden ENCRYPTION-LEVEL=tac-level eine Verschlüsselungsebene zugeordnet wird. D.h., dass ein Client den so geschützten Vorgang nur dann aufrufen kann, wenn die Daten entsprechend verschlüsselt übertragen werden. Abhängig von der Generierung des Client und der Verschlüsselungsebene des TAC können dabei folgende Situationen auftreten:
TRUSTED ist für den Client generiert
openUTM fordert keine Verschlüsselung an, der Client kann auch geschützte Vorgänge starten. Der Client kann keine Verschlüsselung erzwingen, da keine Schlüssel ausgetauscht wurden.
NONE ist für den Client generiert
openUTM fordert in diesem Fall keine Verschlüsselung an.
Wenn sich beim Verbindungsaufbau eine Verschlüsselungsebene client-level > 0 ergeben hat und wenn eine Conversation initialisiert wird, deren TAC Verschlüsselung der Ebene 2 oder 5 erfordert (tac-level), dann gibt es folgende Möglichkeiten:
client-level >= tac-level
wobei der Client für diese Conversation die Verschlüsselung eingeschaltet hat.Der Vorgang kann gestartet werden. Der Client sendet schon die ersten Benutzerdaten verschlüsselt.
client-level >= tac-level
wobei der Client für diese Conversation von sich aus keine Verschlüsselung eingeschaltet und noch keine Benutzerdaten gesendet hat.Der Vorgang kann gestartet werden. Die UTM-Anwendung übergibt alle Ausgaben verschlüsselt auf der Ebene client-level an den Client. Der Client verschlüsselt nun ebenfalls alle weiteren Nachrichten an openUTM auf der Ebene client-level.
client-level < tac-level
Der UPIC-Client hat schon Benutzerdaten gesendet, die entweder nicht verschlüsselt waren oder mit der niedrigeren Verschlüsselungsebene verschlüsselt waren.openUTM beendet die Conversation.
3, 4 oder 5 ist für den Client generiert
Wird eine Conversation initialisiert, deren TAC Verschlüsselung der Ebene 2 oder 5 erfordert (tac-level), dann gibt es folgende Möglichkeiten:
client-level >= tac-level
Der Vorgang kann gestartet werden.client-level < tac-level
Der Vorgang kann nicht gestartet werden, openUTM beendet die Conversation.