Clients greifen häufig über offene Netze auf UTM-Services zu. Damit besteht die Möglichkeit, dass Unbefugte auf der Leitung mitlesen und z.B. Passwörter für UTM-Benutzerkennungen oder sensible Benutzerdaten ermitteln. Um das zu verhindern, unterstützt openUTM die Verschlüsselung von Passwörtern und Benutzerdaten für Verbindungen zu UPIC-Clients.
openUTM verwendet zum Verschlüsseln entweder eine Kombination aus RSA Verfahren (benannt nach den Autoren Rivest, Shamir und Adleman) und AES-CBC Verfahren (Advanced Encryption Standard Cipher Block Chaining Mode) oder DES Verfahren, oder eine Kombination aus Ephemeral Elliptic Curve Diffie-Hellman Verfahren (ECDHE) und AES-GCM Verfahren (Advanced EncryptionStandard Gallois Counter Mode). Die zweite Kombination ist moderner und bietet eine erhöhte Sicherheit im Vergleich zu der erstgenannten Kombination, wird von openUTM z.Zt. aber nur für LUW Plattformen unterstützt.
Der AES-Schlüssel wird vom UPIC-Client beim Aufbau einer Client-Server-Verbindung jeweils neu erzeugt.
Das RSA-Schlüsselpaar wird von openUTM erzeugt und besteht aus einem öffentlichen Schlüssel (= public key) und einem privaten Schlüssel (= private key). Es können in einer Anwendung mehrere Schlüsselpaare mit unterschiedlichen Schlüssellängen generiert werden. Damit lassen sich mehrere Verschlüsselungsebenen realisieren.
Nutzung des RSA-AES-CBC Verschlüsselungsverfahrens
Die Daten werden in folgenden Schritten verschlüsselt und entschlüsselt:
Beim Verbindungsaufbau wird der öffentliche RSA-Schlüssel, der zur generierten Verschlüsselungsebene passt, an den UPIC-Client übertragen. Ist keine Verschlüsselungsebene generiert (NONE), dann wird der längste aktuell verfügbare RSA-Schlüssel übertragen.
Der UPIC-Client erzeugt einen Verbindungs-spezifischen AES-Schlüssel. Dieser wird mit dem öffentlichen Schlüssel verschlüsselt und an die UTM-Anwendung gesendet.
Nachdem die UTM-Anwendung den AES-Schlüssel mithilfe des RSA-Schlüssels richtig entschlüsselt hat, versendet der Client die verschlüsselten Daten.
openUTM entschlüsselt die Daten mit dem AES-Schlüssel.
Alle weiteren Daten, die auf dieser Verbindung zwischen Client und openUTM ausgetauscht werden, werden ebenfalls mit den AES-Schlüssel verschlüsselt.
Nutzung des ECDHE-RSA-AES-GCM Verschlüsselungsverfahrens (nur für Linux-, Unix- und Windows-Systeme)
Bei der Kombination ECDHE-RSA-AES-GCM wird zur Vereinbarung des AES-Session-Schlüssels das auf Elliptischen Kurven basierende Ephemeral Diffie-Hellman Verfahren verwendet. Dabei erzeugt jede Seite ein Diffie-Hellman Schlüsselpaar, überträgt den öffentlichen Teil seines Schlüsselpaars an den Partner und erzeugt aus seinem privaten Schlüssel und dem öffentlichen Schlüssel des Partners den gemeinsamen AES-Session-Schlüssel. D.h. bei diesem Verfahren wird der AES-Session-Schlüssel nicht auf der Datenverbindung übertragen.
Der Server signiert zusätzlich seinen privaten Schlüssel mit dem privaten RSA-Schlüssel der UTM-Anwendung. Auf diese Weise kann der Client überprüfen, dass der gesendete öffentliche Diffie- Hellman-Schlüssel des Servers wirklich von der UTM-Anwendung stammt. Auch hier ist es, wie schon oben beschrieben, zur Abwehr von Man-in-the-Middle Angriffen erforderlich, dass der öffentliche RSA-Schlüssel dem Client zusätzlich auf getrenntem Weg bekannt gemacht wird.
Das Ephemeral Diffie-Hellman Verfahren bietet dem Anwender Perfect Forward Secrecy, das bedeutet, dass selbst aufgezeichnete Daten nicht nachträglich entschlüsselt werden können, falls der Long-Term-Schlüssel (RSA-Schlüssel) später aufgedeckt werden sollte.
Zur Verschlüsselung von Benutzerdaten wird das AES-GCM Verfahren eingesetzt. Dieses Verfahren hat gegenüber AES-CBC u.a. den Vorteil, dass es Authenticated Encryption with Associated Data (AEAD) unterstützt, bei dem die verschlüsselte Nachricht und die weiteren Protokollteile der Nachricht durch einen Message Authentication Code (MAC) gegen Veränderungen geschützt werden.
Es besteht die Möglichkeit, den öffentlichen RSA-Schlüssel einer UTM-Anwendung über die Administrationsschnittstelle auszulesen und auf sicherem Wege bei den UPIC-Clients lokal zu hinterlegen. In diesem Fall kann der Client beim Verbindungsaufbau überprüfen, ob der empfangene öffentliche Schlüssel mit dem lokal hinterlegten Schlüssel übereinstimmt (zur Abwehr des „Man-in-the-middle“-Problems).
Ein RSA-Schlüsselpaar einer UTM-Anwendung sollte aus Sicherheitsgründen in regelmäßigen Abständen durch ein neues Paar ersetzt werden (per programmierter Administration oder über WinAdmin/WebAdmin). Per Administration können RSA-Schlüssel aktiviert, deaktiviert und gelöscht werden. Damit kann man einen neu erzeugten RSA-Schlüssel zuerst an alle UPIC-Clients verteilen, bevor man ihn aktiviert und anschließend das alte Schlüsselpaar deaktiviert oder löscht.
Die Verschlüsselung kann bei openUTM dazu verwendet werden, sowohl den Zugang durch Clients als auch den Zugriff auf bestimmte Services zu kontrollieren.
Zugangsschutz
In der UTM-Konfiguration kann man für jeden Client und jede Client-Gruppe festlegen, ob und inwieweit sie Nachrichten und Passwort verschlüsseln müssen. Dabei gibt es drei Fälle:
Der Client muss auf jeden Fall verschlüsseln, sonst bekommt er keinen Zugang zur UTM-Anwendung. Dabei lassen sich mehrere Verschlüsselungsebenen festlegen. Der Client muss mindestens die Anforderung der jeweiligen Ebene erfüllen.
Der Client wird zwar ohne Verschlüsselung zugelassen, er muss jedoch verschlüsseln, wenn es ein Service explizit verlangt (siehe unten unter „Zugriffsschutz“).
Der Client gilt als sicher (trusted) und muss nicht verschlüsseln.
Zugriffsschutz
openUTM kann einzelne Services schützen. Ein Client darf auf solche Services nur dann zugreifen, wenn er entweder als sicher eingestuft ist oder wenn er mindestens mit der geforderten Verschlüsselungsebene verschlüsseln kann.
Möchte ein Client, der nicht als sicher gilt, auf einen derart geschützten Service zugreifen, dann muss er eine eventuelle Eingabe-Nachricht verschlüsselt senden. openUTM schickt die Ausgabe-Nachricht verschlüsselt zurück, auch dann, wenn der Client den Service ohne Eingabe-Nachricht gestartet hat oder der Service durch Vorgangskettung gestartet wurde.
| Informationen über Verschlüsselung für Clients und Services finden Sie im openUTM-Handbuch „Anwendungen generieren“ unter dem Stichwort ENCRYPTION-LEVEL und im openUTM-Handbuch „Anwendungen administrieren“ unter dem Stichwort KC_ENCRYPT. |
