TCPcrypt: IETF veröffentlicht zwei RFCs zur TCP-Verschlüsselung

Das TCP überträgt Daten bislang unverschlüsselt. Die IETF hat nun zwei RFCs zur TCP-Verschlüsselung veröffentlicht. Diese sind als experimentell gekennzeichnet und dienen zur Dokumentation der Forschung.

Artikel veröffentlicht am 29. Mai 2019, 10:57 Uhr, Kristian Kißling/Linux Magazin/Sebastian Grüner

TCP kann auch verschlüsselt werden, wie erklären zwei experimentelle RFCs. (Bild: Robert, flickr.com/CC-BY 2.0)

Die Internet Engineering Task Force (IETF) hat zwei als experimentell gekennzeichnete RFC-Spezifikationen veröffentlicht, die darlegen, wie TCP-Verkehr verschlüsselt übertragen werden kann. Die Idee, TCP zu verschlüsseln, ist nicht neu. Der erste Entwurf bei der IETF dazu stammt von 2011, erstmals vorgestellt wurde das Projekt TCPcrypt auf der Usenix 2010. Nachdem das Projekt eine Weile schlief, nahm es nach den Enthüllungen von Edward Snowden 2013 und 2014 wieder an Fahrt auf.

Einer der Gründe, TCP nicht zu verschlüsseln, liegt laut RFC 8547 daran, dass ein Signaling-Mechanismus in vielen veralteten Protokollen fehlt. Diese können so nicht mitteilen, ob sie Verschlüsselung unterstützen oder nicht. Zugleich lassen sich viele Legacy-Anwendungen nicht nachträglich aktualisieren. Eine Verschlüsselung müsste daher nachträglich und transparent in die Transportschicht eingebaut werden.

Zwei RFCs für die TCP-Verschlüsselung

Die TCP Encryption Negotiation Option (TCP-ENO) löst laut dem RFC beide Probleme. Die neue Art von TCP-Option ermöglicht es, außer der Reihe und vollständig abwärtskompatibel einen Verhandlungsmechanismus für Verschlüsselung zu ergänzen. Dies kann inkrementell geschehen.

Ein Framework ermöglicht es zwei Endpunkten, das TCP Encryption Protocol zur Verschlüsselung der Verbindung zwischen beiden Endpunkten auszuhandeln. Mehrere TEPs sind möglich, was Anpassungen erlaubt, wenn sich die Verschlüsselungsanforderungen zukünftig ändern. Ist eine Seite nicht in der Lage zu verschlüsseln, findet keine Verschlüsselung statt. Die Details zu TCP-ENO liefert RFC 8547.

Zu TCP-ENO gehört wie erwähnt auch TCPcrypt, das TCP Encryption Protocol, das RFC 8548 definiert. Die Autoren des RFC weisen darauf hin, dass TCPcrypt friedlich mit so genannten Middleboxen koexistieren kann, weil es "Resegmentierungen, NATs sowie andere Modifikationen des TCP-Headers" toleriere.

Das Protokoll sei dabei recht selbstgenügsam, brauche also keine externen Abhängigkeiten wie etwa eine PKI, was unter anderem für den Einsatz in Kernel wichtig sei. Der Schlüsselaustausch erfordere aber bei Hosts, die sich noch nicht kennen, einen zusätzlichen Hop.

Moderne Crypto für TCP

Zentral für TCPcrypt ist zunächst eine Extract-Funktion, die einen Salt-Wert und sogenanntes Initial Keying Material (IKM) entgegennimmt, um einen pseudozufälligen Schlüssel zu generieren. Die Extract-Funktion gibt dann den Schlüssel aus. Aus diesem erzeugt eine kollisionsresistente pseudozufällige Funktion (CPRF) dann mehrere cryptografische Schlüssel sowie eine willkürliche Menge an Output Keying Material (OKM).

Die beiden genannten Funktionen nutzen die Extract- und Expand-Funktionen der Key Derivation Function (HKDF), die auf HMAC basiert (RFC 2104). Sind die Schlüssel ausgehandelt und ist eine Verbindung hergestellt, kümmert sich schließlich ein AEAD-Algorithmus (Authenticated Encryption with Associated Data) darum, die Vertraulichkeit und Integrität der übermittelten Anwendungsdaten zu gewährleisten.

Da die beiden RFC-Spezifikationen von der IETF explizit als experimentell gekennzeichnet sind, weisen diese nur den aktuellen Forschungsstand aus und sind damit nicht für den produktiven Einsatz gedacht. Ob es dazu überhaupt jemals kommt, ist derzeit auch nicht absehbar. Darüber hinaus arbeitet die IETF mit QUIC an einem neuartigen Protokoll, das einerseits als Ersatz von TCP in der Transportschicht dienen kann und andererseits standardmäßig verschlüsselt ist.