Network Time Security (NTS) Deep Dive
Zeit – oder genauer, die aktuelle Uhrzeit – ist essentiell für jedes IT-System, das steht außer Frage. Seit Jahrzehnten ist es üblich, dass sich Netzwerkteilnehmer unterschiedlichster Arten hierfür dem Network Time Protocol (NTP) bedienen, um sich zu anderen Uhren zu synchronisieren. Zur Synchronisation können hierbei die unterschiedlichsten Quellen verwendet werden, seien es öffentliche, durch Institutionen betriebene oder gar eigene NTP-Server, welche ihre Zeit wiederum über beispielsweise Funk- (z. B. DCF77) oder Satellitensysteme (z. B. GPS) beziehen.
Ungeachtet der Zuverlässigkeit und Qualität der gewählten NTP-Server, stellen sich zudem die Fragen: Sind die vom Server übermittelten Zeiten auch tatsächlich von diesem und sind sie glaubhaft und unverändert – oder soll einem eine „Fake-Zeit“ untergeschoben werden?
Genau hier setzt Network Time Security, kurz NTS, an. Verschlüsselung sowie die Gewährleistung von Integrität and Authentizität von Daten – Funktionen, die durch die Verwendung von TLS alltäglich genutzt werden und für sensible Daten selbstverständlich sind – können mit NTS auch für die Zeitsynchronisation verwendet werden.
Warum NTS
Die Uhrzeit eines Systems ist einer der grundlegendsten Faktoren für den Betrieb. Ohne eine korrekte Uhrzeit – oder besser gesagt, ohne gute Synchronität zwischen mehreren Systemen – lassen sich vielerlei Operationen nicht bewerkstelligen, z. B. bereits das Prüfen der Gültigkeit eines Zertifikats.
Welche Auswirkungen eine falsche Systemzeit hat, kann unendlich vielfältig ausfallen. Stellen Sie sich nur vor, was es für Ihre Infrastruktur bedeutet, wenn Kerberos nicht mehr funktioniert oder keine TLS-Verbindungen mehr zustande kommen.
NTP ist ein Klartext-Protokoll. Das heißt, jedes NTP-Paket kann auf dem Transportweg gelesen und eventuell manipuliert werden. Der Empfänger des Pakets ist aber nicht in der Lage eine Manipulation zu erkennen. Eine solche Man-in-the-Middle-Attacke (MITM) kann zur Folge haben, dass die Systemzeit des anfragenden Systems manipuliert wird.
NTS löst dieses Problem dadurch, dass an die NTP-Pakete weitere NTP-Erweiterungen (Extensions) angehängt werden. Diese ermöglichen die kryptographische Prüfung der Daten auf Authentizität und Manipulation sowie zusätzlich den Transport von weiteren verschlüsselten Daten.
Funktionsweise im Überblick
NTS ist eine kryptographische Erweiterung zu NTP. Damit innerhalb der NTP-Kommunikation überhaupt mit kryptographischen Operationen gearbeitet werden kann, ist vorab ein zusätzlicher Schritt notwendig – der Schlüsselaustausch.
Network Time Security Key Establishment Protocol
Hierfür wurde ein neues Protokoll standardisiert, das Network Time Security Key Establishment Protocol, kurz NTS-KE.
Bevor die Kommunikation mit einem NTP-Server gestartet wird, nimmt der Client Kontakt mit dem NTS-KE-Server auf, um mit diesem Schlüsselmaterial auszutauschen (Abb. 1 Schritt 1 und 2).
Hier zeigt sich auch, dass auf Client-Seite nicht mehr direkt der NTP- sondern der NTS-KE-Server konfiguriert wird. Ist der NTP-Server unter einer anderen Adresse oder einem vom Standard abweichenden Port zu erreichen, so wird dies vom NTS-KE-Server mitgeteilt.
Es ist hierbei nicht notwendig, dass NTS-KE- und NTP-Server voneinander separiert sind (Abb. 1). Der Protokollstandard lässt allerdings zu, diese Dienste getrennt oder gar auf unterschiedlichen Servern zu betreiben. Üblich ist hingegen, dass die beiden Dienste von ein und derselben Software ausgeführt werden.
NTP-Kommunikation und Extensions
Ausgestattet mit dem Schlüsselmaterial und ggf. der Information, dass der NTP-Server auf einer abweichenden Adresse oder einem abweichenden Port lauscht, startet die NTP-Kommunikation (Abb. 1 Schritt 3 und 4) wie gewohnt, jedoch mit dem wesentlichen Unterschied, dass weitere Extensions an das NTP-Paket angehängt werden. Diese Extensions machen den Unterschied zum klassischen NTP. Denn die in den Extensions enthaltenen Daten, zusammen mit dem Schlüsselmaterial aus der NTS-KE-Sitzung, erlauben es Sender und Empfänger, die ausgetauschten NTP-Pakete kryptographisch zu überprüfen sowie weitere Daten zu ver- bzw. entschlüsseln.
Funktionsweise im Detail
Verbindungsaufbau: TLS und NTS-KE
Wie bereits in der Funktionsübersicht erwähnt, ist es vor der eigentlichen NTP-Kommunikation notwendig, Schlüsselmaterial über NTS-KE zu beziehen.
Bevor der NTS-KE-Paketaustausch startet, wird zwischen Client und Server zuerst eine TLS-Verbindung mit dem Applikationshinweis (ALPN) „ntske/1“ aufgebaut, denn NTS-KE ist auf einen sicheren und vertraulichen Datenaustausch sowie auf kryptographische Funktionen von TLS angewiesen (Abb. 2 Schritt 1). Strikte Voraussetzung ist hierfür die Verwendung von TLS in der Mindestversion 1.3.
Ist die TLS-Verbindung erfolgreich aufgebaut, sendet der Client den NTS-KE Request (Abb. 2 Schritt 2; Abb. 3). Dieser beinhaltet die von ihm unterstützen AEAD-Algorithmen zusammen mit dem Zielprotokoll, das verwendet werden soll (Next Protocol; hier: 0 = NTPv4).
AEAD steht hier für Authenticated Encryption with Associated Data. Dies sind kryptographische Algorithmen, die zwei Zwecke gleichzeitig erfüllen. Zum einen erlauben sie es, Daten zu verschlüsseln und diese zu überprüfen (Authentizität, Integrität) während sie zusätzlich weitere Daten (Associated Data), die nicht verschlüsselt sind, überprüfen.
Was das genau für die NTP-Pakete bedeutet, ist weiter unten im NTP-Ablauf näher erläutert.
Schlüsselableitung und -Austausch
Wurde dem NTS-KE-Server mitgeteilt, welche AEAD-Algorithmen vom Client unterstützt werden und welches Protokoll (hier: NTPv4) verwendet werden soll, prüft der Server, ob er den Anforderungen entsprechen kann. Dies sollte in der Regel erfolgreich sein, denn alle Parteien müssen mindestens AEAD_AES_SIV_CMAC_256 unterstützen, der sozusagen als kleinster gemeinsamer Nenner dient. Der Server nennt den von ihm gewählten AEAD-Algorithmus und teilt diesen dem Client später im NTS-KE Response (Abb. 4) mit.
Der NTS-KE-Server muss nun zwei dauerhafte Schlüssel ableiten (Abb. 2 Schritt 4), den Client-to-Server (C2S) und Server-to-Client (S2C) Key. Wie es der Name bereits suggeriert, sind dies die Schlüssel, die später für kryptographische Operationen verwendet werden, einmal für NTP-Nachrichten von Client zum Server und zum anderen vom Server zum Client.
Die beiden Schlüssel werden durch eine Schlüsselableitungsfunktion (HKDF, Hashed Message Authentication Code-based Key Derivation Function) aus dem Exporter-Secret der bestehenden TLS-Sitzung abgeleitet. Weitere Parameter, die in die Schlüsselableitung einfließen, sind ein fester Disambiguating Label String sowie die Per-Association Context Value, welche aus den Parametern Protokoll, AEAD und Richtung (C2S oder S2C) gebildet wird.
Info: Der Zwischenschritt 3 in Abb. 2 ist ebenso wie Schritt 9 nur notwendig, wenn die Dienste NTS-KE und NTP getrennt sind. Ist dies der Fall, dann müssen die Schlüsselmaterialien, geschützt durch einen gemeinsamen Schlüssel, zwischen diesen Instanzen ausgetauscht und ggf. weitere Schritte an anderer Stelle vorgenommen werden. Die Schritte 3 und 9 sind daher optional und exemplarisch im Sequenzdiagramm vermerkt, da dieser Vorgang nicht standardisiert und somit abhängig von der Implementierung ist.
NTS-Cookies
Eine zentrale Notwendigkeit des NTS-KE- bzw. NTP-Servers ist, dass er stateless funktionieren muss. Das heißt, der Server darf nicht darüber buchführen, welche Clients ihn kontaktiert haben und welche Schlüssel dafür abgeleitet wurden. Der Server müsste sonst eine Datenbank führen, in der jedoch nie klar wäre, welche Schlüssel darin zur Anwendung kommen und welche verworfen werden können.
Stattdessen überlässt er es dem Client, die sonst in einer Datenbank abgelegten Daten für ihn zu speichern. Die abgeleiteten Schlüssel sowie die zugehörigen Parameter übergibt er an den Client zur Verwahrung – sicher und verschlüsselt verpackt als NTS-Cookie, mit dessen Daten nur der NTP-Server selbst wieder arbeiten kann. Für den Client ist es lediglich eine nicht interpretierbare Ansammlung von Bytes. Bei der späteren NTP-Kommunikation übergibt der Client ein solches Cookie im Klartext, d. h. ohne Transportverschlüsselung, dem NTP-Server. Dieser kann wiederum alle zur Kommunikation notwendigen Daten (v. a. C2S und S2C Keys und AEAD) aus den Cookie-Bytes entschlüsseln und extrahieren.
Diese Cookie-Daten werden dem Client im NTS-KE Response (Abb. 2 Schritt 5) zusammen mit dem vom Server aus den Client-Vorschlägen ausgewählten AEAD sowie einer ggf. abweichender NTP-Server-Adresse und ggf. abweichendem Port mitgeteilt (Abb. 4).
Der Client nimmt nun dieselben Schlüsselableitungen vor (Abb. 2 Schritt 6), wie sie der Server bereits in Abb. 2 Schritt 4 durchführte. Diese Schlüssel werden zusammen mit den übermittelten Cookies und Parametern vom Client gespeichert.
Da per Standard direkt acht solcher Cookies vom NTS-KE-Server generiert und an den Client übermittelt werden, hat dieser nun die Möglichkeit, den NTP-Server acht Mal zu kontaktieren. Sobald ein Cookie verwendet wurde, sollte es vom Client kein zweites Mal verwendet werden.
Die Schlüsselableitung und der Schlüsselaustausch ist damit abgeschlossen und die TLS-Sitzung kann abgebaut werden (Abb. 2 Schritt 7).
NTS – Secure NTP-Request
Nun da alle notwendige kryptographischen Daten vorliegen, kann die NTS-gesicherte NTP-Kommunikation beginnen (Abb. 2 Schritt 8). Der Paket-Flow ist hierbei identisch zum normalem NTP. Der Unterschied liegt in den Extensions, die dem NTP-Paket angehängt werden. Wie in Abb. 5 zu sehen ist, sind dem NTP-Paket die drei Extensions Unique Identifier, NTS Cookie und NTS Authenticator and Encrypted Extension Fields hinzugefügt.
Das Feld Unique Identifier enthält einen vom Client generierten eindeutigen Bezeichner für diesen NTP-Vorgang. Der NTP-Server hat diesen in seiner Antwort unverändert zu senden, damit der Client die Antwort eindeutig einer Anfrage zuordnen kann.
Im NTS Cookie Feld wird dem NTP-Server eines der zuvor ausgestellten Cookies mitgeteilt. Die Cookie-Bytes werden hier im Klartext übertragen, denn nur der Server kann die bereits serverseitig verschlüsselten Cookies wieder entschlüsseln und interpretieren.
Wird das Paket von jemandem aufgegriffen, könnte das Cookie von diesem zwar wiederverwendet werden, allerdings wird der Server dieses sofort verwerfen, sollte nur ein einziges Bit im NTP-Paket anders sein – warum folgt in Kürze.
Das Feld NTS Authenticator and Encrypted Extension Fields ist die eigentliche Erweiterung, mit der die Kryptographie stattfindet. Die gesamten Paket-Bytes vom Beginn des NTP-Pakets bis zum Ende des vorherigen Feldes (Abb. 5 – grün) werden dem selektierten AEAD-Algorithmus als Associated Data übergeben. Zusammen mit der vom Client generierten Nonce und dem bekannten C2S Key gibt der AEAD-Algorithmus den in der Extension platzierten Ciphertext aus.
Info: Hier wurden noch keine Daten verschlüsselt, denn nur die Authentizität und Integrität des NTP-Pakets sollen hier gewährleistet werden. Der Ciphertext enthält daher keine verschlüsselten Daten sondern lediglich den Authentication Tag, eine kryptographische Prüfsumme.
Der empfangende NTP-Server entschlüsselt zuerst das Cookie und extrahiert das Schlüsselmaterial. Anschließend führt der Server mit dem C2S Key dieselbe Berechnung durch. Entspricht der Authentication Tag dem im NTP-Paket, so wurde das Paket auf dem Weg nicht verändert und die kryptographische Prüfung ist erfolgreich.
NTS – Secure NTP-Response
Der Response (Abb. 2 Schritt 10) des NTP-Servers verhält sich analog zum Request: Die NTP-Daten werden im Klartext übertragen und es folgen die gleichen Extensions, wie schon vom Request bekannt (Abb. 6), jedoch dient als Schlüssel nun der S2C Key.
Der Server antwortet mit dem gleichen Unique Identifier, so dass Replay-Attacken vom Client erkannt werden können.
Was nun auffällt ist, dass das Feld NTS Authenticator and Encrypted Extension Fields (Abb. 6 – orange) deutlich mehr Daten enthält als im Request.
Dieses Mal enthält das Feld nicht nur den Authentication Tag zur Überprüfung der vorgelagerten NTP-Paketdaten (Abb. 6 – grün), sondern enthält zusätzlich weitere verschlüsselte Daten.
Werden die Daten mit dem S2C Key entschlüsselt, stellt sich heraus, dass eine weitere NTS Cookie Extension vom Server auf verschlüsselte Weise mitgeschickt wurde.
Über den initialen NTS-KE-Austausch ist der Client im Besitz von acht Cookies. Jedes gesendete NTP-Paket an den Server „kostet“ ein Cookie, somit wäre nach acht Anfragen Schluss und NTS-KE müsste erneut gestartet werden.
Um dies zu vermeiden, generiert der NTP-Server dem Client für jeden Request ein neues Cookie und übergibt ihm dies im Response, damit ein „Cookie-Verbrauch“ direkt wieder aufgefüllt wird und der Client wieder im Besitz von acht Cookies ist.
Info: Der Grund warum Cookies im NTS Response (wie auch durch NTS-KE innerhalb TLS) verschlüsselt übertragen werden, obwohl die Daten darin bereits verschlüsselt sind, liegt ebenso wie der Grund für den Bezug von gleich mehreren Cookies und das Vermeiden der Wiederverwendung dieser, darin, dass die gesamte NTP-Kommunikation keinen Rückschluss auf den Client zulassen soll.
In anderen Worten: Ein Man-in-the-Middle soll nicht in der Lage sein, aus verschiedenen Requests schließen zu können, dass es sich dabei um denselben Client handelt (Unlinkability). Um dies zu bewerkstelligen, müssen sich Daten, die solche Rückschlüsse zulassen könnten (z. B. Schlüssel, Nonce), bei jeder NTP-Kommunikation ändern und vorher keiner anderen Instanz als Client und Server bekannt sein.
Verlorene Cookies
Nun kann es passieren, dass NTP-Requests unbeantwortet bleiben, z. B. durch Paketverlust. In diesem Fall schrumpft der Bestand an verwendbaren Cookies auf Client-Seite. Sind alle Cookies aufgebraucht, muss erneut mit NTS-KE gestartet werden. Für diesen Fall, dass noch Cookies vorhanden sind, jedoch weniger als acht, existiert die NTS Cookie Placeholder Extension. Erhält ein NTP-Server ein Paket mit n solcher Extensions, so übergibt er im Response n+1 NTS Cookie Extensions, so dass der Client seinen Bestand wieder auf acht Cookies „auffüllen“ kann.
NTS Paketaufbau
Aus den bisherigen Ausführungen geht hervor, dass ein NTP-Paket, das NTS verwendet, drei verschiedene Sektionen aufweist. Abb. 7 zeigt den systematischen Paketaufbau in Gänze.
Sektion 1 erstreckt sich vom Beginn des NTP-Pakets bis zum letzten Byte, bevor die NTS Authenticator and Encrypted Extension Fields Extension beginnt (Abb. 6 – grün; Abb. 7 – „authenticated“). Daten innerhalb dieser Sektion werden im Klartext übertragen, sind aber kryptographisch in Bezug auf Authentizität und Manipulation überprüfbar.
Sektion 2 erstreckt sich über die NTS Authenticator and Encrypted Extension Fields Extension (Abb. 6 – orange). Die Daten in Sektion 2 dienen der kryptographischen Prüfung und Verschlüsselung. Das heißt, sie sind notwendig um die Daten der Sektion 1 auf Authentizität und Veränderung zu prüfen (Abb. 7 – „authenticated“), und können zudem weitere kryptographisch verschlüsselte und prüfbare Daten (NTP Extensions) enthalten (Abb. 7 – „authenticated & encrypted“).
Sektion 3 erstreckt sich über Daten, die der NTS Authenticator and Encrypted Extension Fields Extension folgen (Abb. 6 – braun; Abb. 7 – „not protected“). Daten innerhalb dieser Sektion (wenn vorhanden) werden im Klartext übertragen und sind nicht mehr kryptographisch geschützt.