Das TCP überträgt Daten bislang unverschlüsselt. Die IETF hat nun zwei RFCs zu TCP-ENO und Tcpcrypt als “experimentell” gekennzeichnet, die das ändern wollen.
Tcpcrypt ist keine neue Idee. Der erste IETF-Entwurf stammt von 2011, erstmals vorgestellt wurde 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. Seit letzter Woche kennzeichnet die IETF beide RFCs als “Experimentell”. Sie sind nun für Experimente geeignet.
TCP-ENO: Verschlüsselung möglich?
Einer der Gründe, TCP nicht zu verschlüsseln, liege laut RFC 8547 im Fehlen eines Signaling-Mechanismus in vielen veralteten Protokollen. 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.
Die TCP Encryption Negotiation Option (TCP-ENO) löse laut dem RFC beide Probleme. Die neue Art von TCP-Option ermögliche es, außer der Reihe und vollständig rückwärtskompatibel einen Verhandlungsmechanismus für Verschlüsselung zu ergänzen. Dies könne inkrementell geschehen. Ein Framework erlaubt es zwei Endpunkten, ein TCP Encryption Protocol (TEP) zur Verschlüsselung der Verbindung zwischen beiden auszuhandeln. Mehrere TEPs sind möglich, was Anpassungen erlaubt, wenn sich die Verschlüsselungsanforderungen zukünftig ändert. Ist eine Seite nicht in der Lage, zu verschlüsseln, findet keine Verschlüsselung statt. Die Details zu TCP-ENO liefert das RFC.
Tcpcrypt: Verschlüsselung aufbauen
Zusammen mit TCP-ENO gehört 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, 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.
Auch für Tcpcrypt liefert ein RFC-Dokument die technischen Details nach. Zentral ist zunächst eine Extract-Funktion (“extract(S, IKM)”), die ein Salt (S) und so genanntes Initial Keying Material (IKM) entgegen nimmt, 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 kryptografische Schlüssel sowie eine willkürliche Menge an Output Keying Material (OKM).
Beide Funktionen, “extract()” und “CPRF()”, basieren auf den Extract- und Expand-Funktionen der HMAC-basierten Key Derivation Function (HKDF), die, wie der Name schon sagt, auf HMAC (RFC 2104) basiert. Sind die Schlüssel ausgehandelt und ist eine Verbindung hergestellt, kümmert sich schließlich ein Algorithmus (Authenticated Encryption with Associated Data, kurz AEAD) darum, die Vertraulichkeit und Integrität der übermittelten Anwendungsdaten zu gewährleisten.
Der nächste Schritt der Kryptographen hinter TCP-ENO und Tcpcrypt dürfte sein, die Verschlüsselung als Standard vorzuschlagen. Auch eine künftige Kernel-Implementierung ist denkbar.
