In den letzten Monaten begegneten wir in Projekten einigen Herausforderungen in Sachen Verschlüsselung. Diese Herausforderungen geben Anlass dafür, über die grundsätzliche Frage im Titel dieses Textes nachzudenken.

Verschlüsselung ist ein wichtiges Werkzeug der IT-Sicherheit. Dieses Werkzeug ermöglicht auf sehr wirksame Weise die Realisierung des Sicherheitsziels der Vertraulichkeit. Doch nicht nur Vertraulichkeit kann mit Verschlüsselung erreicht werden. Verschlüsselte Daten lassen sich nämlich bei Unkenntnis des Schlüssels meistens nicht manipulieren, ohne eine Spur zu hinterlassen. Daher kann die Verschlüsselung neben der Vertraulichkeit auch anderen Zielen wie zum Beispiel Integrität und Authentizität dienen.

Das für die IT-Sicherheit sehr zentrale Verfahren Verschlüsselung wird deshalb sehr gerne auf schützenswerte Daten angewandt. Daten können auf Speichermedien verschlüsselt werden („Data at Rest“), oder bei Übertragung („Data in Motion“). Während für gespeicherte und bewegte Daten etablierte Verschlüsselungsverfahren verfügbar sind, ist die Anwendung von Verschlüsselung auf in Verarbeitung befindliche Daten („Data in Use“) komplexer und ein relativ neues Feld.

Im Folgenden geht es um Verschlüsselung von bewegten Daten, um sie vor Späh- oder anderen Angriffen auf Netzverbindungen zu schützen.

Herausforderungen in der Praxis

Eingangs erwähnte ich Herausforderungen, denen wir bezüglich Verschlüsselung in der jüngsten Projektpraxis begegnet sind. Ich möchte drei Beispiele nennen:

• In einem Projekt ging es darum, auf Routern Internet Protocol Security (IPsec) für die Verschlüsselung von Daten zu nutzen. Tests haben ergeben, dass der vom Hersteller genannte Durchsatz im Falle der Verschlüsselung bei Weitem nicht erreicht wurde. Merkwürdigerweise konnte man bei bestimmten Paketlängen nur wenig Durchsatz erreichen, während sowohl bei längeren als auch bei kürzeren Paketen der erreichte Durchsatz höher war.
• Eine Anforderung in einer Reihe von Projekten ist die Unterstützung von Media Access Control Security (MACsec) durch LAN-Switches. Insbesondere bei Übertragung über öffentlichen Grund kann die Anwendung von MACsec sinnvoll sein. Problematisch ist die Unterstützung von MACsec durch Hersteller. Die meisten LAN-Hersteller tun sich mit MACsec sehr schwer, insbesondere wenn Netzverbindungen hoher Bitrate wie 100 Gbit/s verschlüsselt werden sollen.
• Ein Weitverkehrsnetz (Wide Area Network, WAN) arbeitet zwar meist mit wesentlich niedrigeren Bitraten als 100 Gbit/s, doch bei Zugriff von vielen Standorten auf ein Rechenzentrum (RZ) kann im RZ der Bedarf an aggregierter Verschlüsselungsleistung in der Größenordnung von 100 Gbit/s entstehen. Wenn WAN-Plattformen genutzt werden, bei denen das RZ über eine oder zwei physische Verbindungen an das WAN angeschlossen wird, müssen diese RZ-Verbindungen eine hohe Bitrate und Verschlüsselung unterstützen. Typische WAN-Komponenten können in der Regel nicht mit einem Durchsatz von 100 Gbit/s verschlüsseln.

Alle drei Fälle weisen die Gemeinsamkeit auf, dass im Netz viele Kommunikationsbeziehungen zusammenkommen. Die aggregierten Datenströme an einer Stelle zu verschlüsseln ist gar nicht so einfach möglich, wie es auf den ersten Blick scheint.

Die Verschlüsselung muss nicht nur mit hohem Durchsatz, sondern auch so erfolgen, dass der Aufwand für die Verwaltung der Verschlüsselung nicht exorbitant hoch ist. Für einige Verfahren wie MACsec müssen meistens Shared Secrets an beiden Enden der Verbindung manuell eingestellt werden. In einem solchen Fall verursacht das Schlüsselmanagement bei einer hohen Anzahl von Verbindungen einen hohen Aufwand. Selbst bei einer niedrigen Anzahl von Verbindungen ist der Aufwand für den immer empfohlenen regelmäßigen Wechsel der Shared Secrets zu berücksichtigen.

Ist die Verschlüsselung auf Applikationsebene besser?

Auf Applikationsebene gibt es schon längst etablierte Verfahren für die Verschlüsselung von bewegten Daten. Das verbreitetste dieser Verfahren ist Transport Layer Security (TLS). TLS geht ursprünglich auf Secure Socket Layer (SSL) zurück und ist von der Internet Engineering Task Force (IETF) standardisiert worden. Das Verfahren ist die Basis des weltweit am häufigsten genutzten verschlüsselten Protokolls, nämlich HTTPS. Laut einem Google-Bericht vom 5. September 2020 wurden in Deutschland 93% der Webseiten über HTTPS geladen [1].

TLS hat folgende Vorteile:

• Das Verfahren nutzt für Schlüsselmanagement ein weltweit etabliertes System der Vertrauensketten mit Zertifikaten. Bei Nutzung von gängigen Betriebssystemen und Browsern ist es möglich, für das Schlüsselmanagement Zertifikate zu nutzen, die von einer etablierten Certificate Authority (CA) signiert sind.
• Verschlüsselung auf Applikationsebene schützt die Daten auf der gesamten Strecke zwischen den beiden Kommunikationspartnern und nicht nur auf einer Teilstrecke zwischen zwei Netzkomponenten (Switches, Routern, VPN-Gateways).
• Für die Verschlüsselung wird die Prozessorleistung vieler beteiligter Systeme genutzt. Das sorgt für Skalierbarkeit und vermeidet den Verschlüsselungsengpass auf Netzkomponenten, die einen hohen aggregierten Durchsatz haben müssen.

Würden alle Applikationen Verschlüsselung unterstützen, bräuchte man im Netz gar nicht zu verschlüsseln, und man müsste nicht nach Netzkomponenten suchen, die bei hohen aggregierten Übertragungsraten auch noch Verschlüsselung mit Wire Speed unterstützen.
Leider gibt es eine Reihe von Applikationen, die Daten unverschlüsselt übertragen. Dazu gehören gängige vernetzte File-Systeme, Print Services und einiges mehr.

Und was ist mit Verschlüsselung auf Systemebene?

Zwischen der Applikations- und der Netzebene gibt es noch die Ebene der Systeme. Theoretisch kann ein System so eingestellt werden, dass es zum Beispiel nur IP-Verbindungen zulässt, die mit IPsec gesichert sind. Natürlich müssten dann alle anderen denkbaren Systeme, mit denen kommuniziert werden muss, ebenfalls IPsec unterstützen. Das ist leider noch weniger realistisch als die Einigung auf TLS als Basis aller Applikationen. Obwohl IPsec zum Beispiel geeignet ist, Datenströme im Rahmen von Internet of Things (IoT) zu schützen, lassen die meisten IoT-Geräte wie intelligente Stromzähler IPsec-Unterstützung vermissen.

Auch der Ansatz, Network Access Control (NAC) mit Verschlüsselung bis zum Endgerät zu kombinieren, scheitert bisher an mangelnder Unterstützung durch die Endgeräte. Selbst wenn alle Endgeräte diesen Ansatz unterstützten, bliebe erstens die Frage, ob auf der Gegenseite der Switch die erforderliche Leistungsfähigkeit für die Verschlüsselung der Kommunikation mit einer Vielzahl von Endgeräten aufweist. Zweitens müsste der Switch auf Verbindungen mit anderen Switches ebenfalls verschlüsseln. Auch hierfür muss er leistungsfähig genug sein.

Zweigleisige Vorgehensweise

Man sieht: Es gibt leider noch kein einzelnes Allheilmittel im Bereich der Verschlüsselung von bewegten Daten. „Zweigleisig fahren“ ist geboten:

• Wo möglich, sollten alle Applikationen so modernisiert, entwickelt bzw. ausgewählt werden, dass sie TLS unterstützen. Dieses Verfahren hat sich im weltweiten Internet als skalierbar erwiesen. Es gibt etablierte Certificate Authorities (CA). Die für TLS-Schlüsselmanagement erforderliche Infrastruktur öffentlicher Schlüssel (Public Key Infrastructure, PKI) ist verfügbar bzw. realisierbar. Zu vielen Legacy-Applikationen wie zum Beispiel klassisches Filesharing ohne Verschlüsselungsunterstützung gibt es Alternativen. Klassisches Filesharing kann zum Beispiel durch Web-basierende Datenaustauschplattformen ersetzt werden.
• Die ideale Lösung mit TLS-Nutzung durch alle Applikationen ist jedoch in vielen Umgebungen noch nicht erreichbar, weil einige Anwendungen Verschlüsselung nicht unterstützen und nur unter Verzicht auf wesentliche Funktionen durch Applikationen mit Verschlüsselungsunterstützung abgelöst werden können. Es gibt also häufig einen Anteil nichtverschlüsselter Datenströme. Solange dies der Fall ist und die Daten durch Verschlüsselung geschützt werden müssen, ist im Netz zu verschlüsseln.

Man kann aus den oben beschriebenen Gründen nicht überall im Netz verschlüsseln, insbesondere auf Verbindungen zwischen Switches und Endgeräten ist dies nicht durchgängig möglich. Es wäre nicht plausibel, alle Verbindungen zwischen Switches zu verschlüsseln, während das Gros der Verbindungen unverschlüsselt bleibt, nämlich die Verbindungen zu den Endgeräten.

Verschlüsselung im Netz ist daher dann sinnvoll, wenn die Netzverbindungen exponierter und somit gefährdeter sind als LAN-Verbindungen innerhalb von Gebäuden. Exponierte Netzverbindungen sind zum Beispiel solche über öffentlichen Grund oder ungesichertes Gelände.

Verschlüsselung auf welcher Netzebene?

Wenn besonders exponierte, ergo gefährdete Netzverbindungen zu schützen sind, wenden wir also Verschlüsselung auf der Netzebene an.

Aber die „Netzebene“ ist noch zu undifferenziert. Man kann Verschlüsselung nämlich auf verschiedenen Netzebenen anwenden:

• Schicht 1 (physische Übertragung): Ein Beispiel für Schicht-1-Verschlüsselung ist die Nutzung der kryptografischen Funktion von DWDM-Komponenten. DWDM (Dense Wavelength Division Multiplexing) dient der Nutzung derselben Glasfasern mit verschiedenen Wellenlängen. Ein solches Szenario gibt es häufig bei LAN- und SAN-Verbindungen zwischen zwei Rechenzentren. Optische Multiplexer unterstützen Verschlüsselung für den ganzen Datenstrom einer bestimmten Wellenlänge. Auf derselben Glasfaser ist die Mischung verschlüsselter und unverschlüsselter Übertragungen möglich. In der Regel entscheidet man sich jedoch für die Verschlüsselung aller Datenströme und nicht eines Teils. Das ist darauf zurückzuführen, dass es im laufenden Betrieb nicht praktikabel ist, zwischen zu verschlüsselnden und nicht zu verschlüsselnden Datenströmen zu unterscheiden.
• Schicht 2 (MAC): MACsec kann für Verschlüsselung auf MAC-Ebene angewandt werden. Ähnlich wie bei DWDM-Verschlüsselung richtet man MAC-Verschlüsselung auf einer Punkt-zu-Punkt-Verbindung ein. Während bei DWDM die Endpunkte der Verschlüsselung die Multiplexer sind, sind es bei MACsec die Switches. Es gibt Szenarien, in denen man zwei LAN-Switches über ungeschütztes Gelände oder gar öffentlichen Grund miteinander verbindet. In einem solchen Fall kann MACsec helfen, wenn es Datenströme gibt, die erstens schützenswert sind und zweitens nicht auf Applikationsebene verschlüsselt werden können.
• Schicht 3 (IP): IPsec ist das etablierte Verfahren für Verschlüsselung auf der Ebene des Internet Protocol. Breite Anwendung findet IPsec in Virtual Private Networks (VPNs) über das Internet. Doch auch in vielen WANs wird IPsec genutzt. Bei einer Vielzahl von IPsec-Tunneln zwischen Standorten lohnt es sich, statt der aufwendigen manuellen Bildung einer Vielzahl verschlüsselter Tunnel dynamische Verfahren für Tunnelbildung zu nutzen. Hersteller wie Cisco, Juniper und Palo Alto unterstützen solche Verfahren in ihren VPN-Lösungen. In der Regel funktionieren dynamische Verfahren der Tunnelbildung so, dass auf jedem Tunnelendpunkt nicht Tunnel zu allen anderen Endpunkten konfiguriert werden, sondern die Verbindung zu einer oder zwei Instanzen, die dann beim dynamischen Tunnelaufbau bzw. Schlüsselmanagement vermitteln.
• Schicht 4 (TLS): Nicht nur für Verschlüsselung auf Applikationsebene, sondern auch für die Bildung verschlüsselter Tunnel zwischen VPN Gateways kann TLS angewandt werden. Das auf Open Source basierende OpenVPN ist ein Beispiel für die Nutzung von TLS zwecks Bildung verschlüsselter Verbindung zwischen Gateways.

Fazit

Um auf die Frage im Titel zurückzukommen: Die gängigen Verfahren der Verschlüsselung bewegter Daten haben ihre Daseinsberechtigung. Jedes dieser Verfahren ist für bestimmte Szenarien besonders geeignet, für andere weniger oder gar nicht. Es gibt kein einzelnes Allheilmittel im Bereich der Verschlüsselung von „Data in Motion“.