Analyse des NTP-Autokey-Verfahrens

Transkript

1 Technische Universität Braunschweig Physikalisch-Technische Bundesanstalt Projektarbeit Analyse des NTP-Autokey-Verfahrens Stephen Röttger 9. September 2011 TU Braunschweig Institut für Theoretische Informatik Prof. Dr. Jiri Adamek betreut durch Dr. Dieter Sibold und Dr. Stefan Milius

2 Inhaltsverzeichnis 1. Einleitung 1 2. Analyse des NTP-Autokey-Verfahrens Client-Server-Modus Authentitizätsprüfung Protokoll-Ablauf Schwachstellen/Sicherheitsanalyse Symmetrischer Modus Schlüsselerzeugung Protokollablauf Schwachstellen/Sicherheitsanalyse Alternativen IPsec TLS-Tunnel (z. B. OpenVPN) DTLS Fazit NTP-Autokey Verbesserungen Hash- und MAC-Algorithmen Authentifizierung Protokollablauf Sicherheitsüberlegungen Fazit 29 Literaturverzeichnis 30 A. Challenge-Response Identity Schemes 33 A.1. Schnorr Identify Friend or For A.2. Guillou-Quisquater A.3. Mu-Varadharajan i

3 B. Inhalt der CD 38 ii

4 1. Einleitung Im deutschen Energiewirtschaftsgesetz ist festgelegt, dass in Neubauten folglich intelligente Zähler eingebaut werden müssen, die dem Nutzer den tatsächlichen Energieverbrauch und die tatsächliche Nutzungszeit widerspiegeln. Intelligent ist dabei als Kommunikationsfähig zu verstehen, d. h. die Zähler kommunizieren mit den Messstellenbetreibern und können Verbrauch und Nutzungszeiten automatisch an diese übertragen. Dies hat den Zweck, dass Abrechnungen so häufig durchgeführt werden können, dass der Kunde seinen Stromverbrauch aktiv steuern kann. Nach der geltenden Eichordnung unterliegen diese Zähler der Eichpflicht, wenn ihr Stand und ihre Schaltzeiten bei geschlossenem Gehäuse nicht erkennbar sind. Insbesondere gilt dies für Zähler, die aus Kostengründen kein Display besitzen. Um für diese Geräte eine genaue Zeit zu garantieren wird eine authentifizierte Zeitsynchronisation zu einer vertrauenswürdigen Zeitquelle, beispielsweise einem Zeitserver des Stromnetzbetreibers, benötigt. Die Authentifizierung ist dabei wichtig, um eine Manipulation Dritter ausschließen zu können. Dazu wird in dieser Arbeit das NTP-Autokey-Verfahren untersucht, dass eine authentifizierte Zeitsynchronisation über das Netzwork Time Protocol (NTP) [1] ermöglichen soll. Das Network Time Protocol ist das im Internet am weitesten verbreitete Protokoll zur Zeitsynchronisation, die es in drei verschiedenen Modi bereitstellt. Im Client-Server-Modus stellt ein Client eine Verbindung zu einem Server her und fragt von diesem die Zeit ab. Im symmetrischen Modus passen zwei NTP-Server ihre Zeit gegenseitig aneinander an. Im Broadcast-Modus sendet ein NTP-Server seine Zeitupdates an eine Broadcast Adresse. Für jeden dieser Modi bietet das in RFC 5906 [2] beschriebene NTP-Autokey-Verfahren eine Erweiterung, die eine Authentifizierung des NTP-Servers gewährleisten soll. Die Verbindungen zwischen Server und Client werden Assoziationen genannt. Ein NTP-Server behält dabei keine Informationen über seine Clients. Für eine Zeitanfrage sendet ein Client ein NTP-Paket (vgl. Abbildung 1.1), dass die Zeit t 1 beinhaltet, zu der es abgesendet wurde. Der Server antwortet darauf mit einem Paket, dass die Ankunftszeit t 2 sowie die Sendezeit t 3 der Antwort enthält. Zusammen mit der Ankunftszeit t 4 dieser Antwort kann der Client den Zeitunterschied t = 1 2 ((t 2 t 1 ) (t 4 t 3 )) zu dem Server berechnen [3]. NTP-Pakete können optional ein oder mehrere der in Abbildung 1.2 gezeigten 1

5 Extension-Felder beinhalten. Jedes Extension-Feld enthält einen Opcode, der den Typ der Extension und damit den Inhalt des Value-Feldes beschreibt, Daten variabler Länge sowie eine optionale Signatur. 2

6 Flags Peer Clock Stratum Peer Polling Interval Peer Clock Precision Root Delay Root Dispersion Reference Clock ID Reference Clock Update Time Originate Timestamp (t 1 ) NTP-Daten Receive Timestamp (t 2 ) Transmit Timestamp (t 3 ) Extension-Felder (optional) KeyID Message Authentication Code (optional) Abbildung 1.1.: NTP Paketformat 3

7 Flags Opcode Extension Length Association ID Timestamp File Timestamp Value Length Value (optional) Signature Length Signature (optional) Abbildung 1.2.: Format des Extension-Feldes 4

8 2. Analyse des NTP-Autokey-Verfahrens Das NTP-Autokey-Verfahren basiert auf symmetrischen Schlüsseln, den sogenannten Autokeys, die jeweils nur für ein Paket gültig sind. Jedem NTP- Paket wird eine 32 Bit umfassende KeyID und ein Message Authentication Code (MAC) angehängt. Die KeyID identifiziert den verwendeten Autokey auf eindeutige Weise. Der MAC wird verwendet, um die Authentizität des Pakets zu überprüfen und kann nur erstellt werden, wenn man den Autokey passend zu der KeyID kennt oder berechnen kann. Für den Austausch von Daten, die für die Autokey-Authentifizierung benötigt werden, werden NTP-Extension-Felder verwendet. Dies passiert zu Beginn der Autokey-Kommunikation sowie zur eventuellen Auffrischung der Autokey- Parameter. Der MAC für Pakete, die ein NTP-Extension-Feld beinhalten, wird immer nur mit öffentlichen Werten berechnet und kann somit keine Authentizität gewährleisten. Für diese Pakete kann die optionale Signatur im Extension-Feld die Authentizität gewährleisten, die allerdings nur die Daten des Extension-Feldes schützt. Die Zeitinformationen, die solch ein Paket enthält sind nicht geschützt und können unbemerkt von einem Angreifer verändert werden Client-Server-Modus Client und Server besitzen im Autokey-Verfahren ein gemeinsames Geheimnis, Cookie genannt, dass nur sie kennen. Der Server wählt dieses Geheimnis zu Beginn einer Assoziation und übermittelt es dem Client in verschlüsselter Form damit es kein Dritter mitlesen kann. Das Cookie wird anschließend verwendet, um den Autokey aus einer KeyID zu bestimmen. Der Autokey wird wie folgt berechnet 1 : Autokey = H (Sender-IP Empfänger-IP KeyID Cookie). (2.1) 1 bezeichnet die Konkatenation der Daten. 5

9 H() ist dabei eine kryptographische Hash-Funktion. Für die Autokey-Berechnung wird das MD5-Verfahren verwendet, wodurch der resultierende Schlüssel eine Länge von 128 Bit hat. Sender- und Empfänger-IP bestehen jeweils aus 32 Bit falls IPv4 verwendet wird, bzw. 128 Bit bei IPv6. KeyID und Cookie sind jeweils 32 Bit lang. Im Anschluss kann der Message Authentication Code für das Paket berechnet werden: MAC = H (Autokey NTP-Paket) (2.2) Für den MAC können verschiedene Hash-Algorithmen verwendet werden. Die Referenzimplentierung unterstützt die MD5- und SHA1-Hash-Algorithmen, wobei der jeweils verwendete Algorithmus anhand der Länge des MAC erkannt wird. Beim Erhalt eines Pakets, berechnet der Empfänger den Autokey unter Verwendung des Cookies, berechnet anschließend den MAC über das erhaltene Paket und vergleicht ihn mit dem MAC, der vom Sender an das Paket angehängt wurde. Stimmen sie überein, weiss der Empfänger, dass der Sender des Pakets im Besitz des Cookies ist. Wie zu sehen ist, ist die Geheimhaltung des Cookies kritisch, da ein Angreifer der im Besitz des Cookies ist, Message Authentication Codes selbst erstellen und sich somit als Server ausgeben kann. Da der Server keinen State über seine Clients behält, kann er kein zufälliges Cookie wählen, sondern muss es bei jeder Anfrage eines Clients neu berechnen können. Zusätzlich muss jeder Client ein eindeutiges Cookie erhalten und Dritte dürfen nicht in der Lage sein, selbst Cookies zu erstellen. Der Server besitzt dazu einen zufälligen 32 Bit Wert, den Server Seed, der von ihm zur Cookie- Berechnung verwendet wird und geheim bleibt. Das Cookie berechnet sich als: Cookie = MSBs 32 (H (Client-IP Server-IP 0 Server Seed)). (2.3) MSBs 32 () schneidet dabei die 32 höchstwertigsten Bits des Ergebnisses der Hash-Funktion ab. Die verwendete 0 besteht aus 32 Bit. Als Hash-Funktion wird MD5 verwendet. Das Cookie eines Clients ändert sich somit nicht, außer der Server wechselt seinen Server Seed. Ist dies der Fall, merkt der Server, dass ein Client noch ein altes Cookie verwendet, da dessen Anfragen ebenfalls einen Message Authentication Code enthalten. Der MAC des Clients kann somit nicht vom Server verifiziert werden und dieser antwortet mit einem negativen Acknowledgement (Crypto-NAK). Der Client setzt daraufhin die Assoziation zum Server zurück und handelt danach die Parameter neu aus. 6

10 Authentitizätsprüfung Damit der Client die Authentizität des Servers prüfen kann, werden Extension- Felder vom Server signiert. Somit trägt auch das Paket mit dem der Server das Cookie zum Client sendet eine Signatur. Um die Signaturen zu verifizieren, benötigt der Client den öffentlichen Schlüssel des Servers und muss sicher sein, dass dieser Schlüssel zu dem Server gehört und ihm vertraut werden kann. Dazu sendet der Server ein Zertifikat zum Client, dessen Vertrauenswürdigkeit vom Client durch eines von fünf Identity Schemes überprüft wird. Trusted Certificate Im Trusted Certificate Scheme sendet der Server zusätzliche Zertifikate, die eine Zertifikatskette von ihm zu einer Trusted Authority herstellen. Im Gegensatz zur üblichen Praxis besitzt der Client kein Zertifikatsspeicher mit den Zertifikaten von Trusted Authorities denen er vertraut, sondern er akzeptiert ein vom Server gesendetes Zertifikat als das einer Trusted Authority, wenn es ein X.509v3 Extended Key Usage Erweiterungs-Feld mit dem Inhalt trustroot beinhaltet. Private Certificate Im Private Certificate Scheme besitzen Server und Client das gleiche Zertifikat mit zugehörigem privaten Schlüssel. Dieses Scheme entspricht einem Pre-shared-key-Verfahren und es sichert die Authentizität, solange der private Schlüssel geheim bleibt. Wird derselbe Schlüssel für mehrere Clients verwendet, kann sich jeder dieser Clients gegenüber den anderen als Server ausgeben. Diesen Fall kann man zwar durch NTP Secure Groups einschränken, allerdings hat dieses Scheme keine Vorteile im Vergleich zu der Verwendung von NTP mit symmetrischen Schlüsseln [1]. Schnorr Identify Friend or Foe Das Identify Friend or Foe (IFF) Scheme [2] ist ein Challenge-Response-Verfahren das einen abgewandelten Schnorr- Signatur-Algorithmus [4] verwendet. Der Client besitzt öffentliche Parameter des Servers, von denen er sicher weiß, dass sie zu dem Server gehören. Diese müssen allerdings nicht geheim gehalten werden. Der Client erstellt einen zufälligen Wert, das Challenge, und sendet es dem Server. Dieser kann darauf eine Berechnung durchführen, die dem Client beweist, dass er im Besitz eines zu den öffentlichen Parametern gehörenden Geheimnisses ist. Eine genaue Beschreibung dieses und der beiden folgenden Verfahren befindet sich in AbschnittA. Guillou-Quisquater Das Guillou-Quisquater (GQ) Scheme [2] basiert auf einem Signatur-Verfahren von L. Guillou und J. Quisquater [5]. In diesem 7

11 Challenge-Response Scheme benötigen Client und Server ein gemeinsames Geheimnis, den sogenannten Gruppenschlüssel. Der Gruppenschlüssel wird verwendet, um Schlüssel für das Challenge-Response-Verfahren zu generieren und um die Response zu überprüfen (vgl. AbschnittA.2). Analog zum Private Certificate Scheme kann sich ein Client gegenüber anderen Clients als Server ausgeben, wenn für sie derselbe Gruppenschlüssel verwendet wird. Mu-Varadharajan Das Mu-Varadharajan (MV) Scheme [2] ist ein Challenge- Response-Protokoll, dass auf einem Verschlüsselungsverfahren von Y. Mu und V. Varadharajan basiert [6]. Das Verschlüsselungsverfahren wurde für die Verschlüsselung von Broadcasts entworfen, so dass Daten mit mehreren Schlüsseln entschlüsselt werden können, wobei zusätzlich einzelne Schlüssel hinzugefügt oder widerrufen werden können. Um dieses Verfahren als Identity Scheme zu verwenden, sendet der Client dem Server einen zufälligen Wert. Dieser Wert wird vom Server verschlüsselt und zurück zum Client gesendet. Der Client entschlüsselt ihn und vergleicht ihn mit dem ursprünglichen Wert. Eine genaue Beschreibung des Verfahrens befindet sich in AbschnittA Protokoll-Ablauf Zu Beginn einer Assoziation tauschen Client und Server in mehreren Schritten Informationen aus, die der Client benötigt, um die Authentizität des Servers und der späteren Zeit-Antworten zu überprüfen. Der Client stellt dazu jeweils Anfragen mit einem eingefügten Extension-Feld und bekommt entsprechende Antworten vom Server. Der Client ist zu diesem Zeitpunkt abhängig vom verwendeten Identity Scheme bereits im Besitz von öffentlichen Parametern oder eines Zertifikats von einer vertrauenswürdigen Instanz (Trusted Authority), mit dem der Client die Identität des Servers verifizieren kann. Die Kommunikation läuft dann in der folgenden Reihenfolge ab: ASSOC Die erste Anfrage des Clients enthält ein Extension-Feld vom Typ Association. Die Anfrage enthält ein 32 Bit Status Feld und den Autokey- Hostnamen des Clients. Die Antwort des Servers enthält entsprechend ein Status-Feld und den Autokey-Hostnamen des Servers. Das Status-Feld enthält Informationen darüber, welche kryptografischen Algorithmen von Server und Client verwendet werden. CERT Darauf folgend sendet der Client eine Zertifikats-Anfrage (mit Ausnahme des Private Certificate Schemes). Diese beinhaltet einen Hostnamen, 8

12 für den der Client ein Zertifikat zugesendet bekommen möchte. Im ersten Schritt ist das der Hostname, den er im vorigen Schritt mit der Association-Nachricht vom Server erhalten hat. Die Antwort des Servers enthält dann ein Zertifikat für den erfragten Hostnamen. Ist dieses Zertifikat nicht selbst-ausgestellt, fragt der Client erneut nach dem Zertifikat des Ausstellers. Bekommt der Client in der Antwort schließlich ein selbst-ausgestelltes Zertifikat, überprüft er, ob dieses ein Zertifikat einer Trusted Authority ist. Damit ist eine Zertifikatskette von einer Trusted Authority bis zu dem Server mit dem der Client gerade kommuniziert hergestellt und ihm wird vertraut. Dabei ist zu beachten, dass der Client ein Zertifikat als das einer Trusted Authority anerkennt, falls in dem Zertifikat trustedroot in einem Erweiterungsfeld steht. Das Vertrauen wird nicht wie üblich dadurch hergestellt, dass der Client bereits im Besitz des Zertifikats der Trusted Authority ist, sondern durch das verwendete Identity Scheme mit den dazu gehörigen öffentlichen Parametern. IFF/GQ/MV Falls ein Challenge-Response Identity Scheme verwendet wird, versendet der Client anschließend ein Paket mit einem Extension-Feld vom entsprechenden Typ IFF, GQ oder MV. Dieses Paket enthält das Challenge des Clients und die Antwort des Servers enthält die Response entsprechend dem verwendeten Identity Scheme zusammen mit einer Signatur. Die Parameter, die der Client benötigt um die Response zu überprüfen hat er vor Inbetriebnahme bereits auf einem sicheren Weg erhalten, so dass diese nicht von einem Angreifer ausgetauscht werden konnten. COOK Im nächsten Schritt fragt der Client den Server nach dem geheimen Cookie. Die Cookie-Anfrage enthält dabei einen öffentlichen Schlüssel des Clients, der zum Verschlüsseln verwendet werden kann. Der Server berechnet das Cookie (vgl. Formel 2.3), verschlüsselt das Cookie mit dem öffentlichen Schlüssel des Clients und sendet es in einem Extension- Feld mit Signatur. Der Client überprüft die Signatur des Servers und entschlüsselt das Cookie. An dieser Stelle hat der Client die Authentizität des Servers überprüft und das geheime Cookie erhalten. Nun synchronisiert er seine Zeit mit dem Server durch normale NTP-Pakete, die kein Extension-Feld beinhalten, aber KeyID und Message Authentication Code angehängt haben. Die KeyID kann der Client beliebig wählen und den zugehörigen Autokeys berechnen (vgl. Formel 2.1). Der Server beantwortet diese Pakete nach dem normalen NTP-Verfahren und hängt an die Antworten ebenfalls KeyID und einen MAC. Als KeyID verwendet der 9

13 Server die KeyID aus der zugehörigen Anfrage des Clients. Bei der Berechnung des zugehörigen Autokeys ist allerdings zu beachten, dass die beiden IP-Adressen vertauscht sind und somit daraus ein Autokey resultiert, der von dem in der Anfrage verwendeten verschieden ist. SIGN Nach der Zeit-Synchronisation sendet der Client eine Signatur-Anfrage in einem Extension-Feld. Diese beinhaltet das Zertifikat des Clients. Der Server signiert dieses Zertifikat und sendet es zurück zum Client. Anschließend ist der Client in einem Modus in dem er nur noch die Millisekunden zu dem Server synchronisiert und keine großen Zeitsprünge mehr durchführt. Dies passiert weiterhin durch Extension-Feld-freie NTP-Pakete mit Message Authentication Code Schwachstellen/Sicherheitsanalyse Für einen Angreifer gibt es zwei mögliche Ziele: Denial-of-Service Masquerading zur Verstellung der Zeit des Clients Denial-of-Service (DoS) bezeichnet Angriffe, die darauf ausgelegt sind einen Rechner bzw. einen Dienst zu überlasten, so dass seine Verfügbarkeit nicht mehr gegeben ist. Diese Angriffe sind häufig nicht zu verhindern, wenn der Angreifer genügend Ressourcen 2 zur Verfügung hat; es kann jedoch Protokoll- Schwachstellen geben, durch die diese noch erleichtert werden. Im Folgenden werden nur Masquerading-Schwachstellen betrachtet, da diese ein viel höheres Risiko darstellen. In einem Masquerading-Angriff gibt sich ein Angreifer zu einem Client als NTP-Server aus und kann damit dessen lokale Zeit verstellen. Im Regelfall erfragt ein Client gleichzeitig die Zeit von mehreren NTP-Servern. Diese sind in der Client-Konfiguration entweder durch eine IP-Adresse oder einen DNS-Namen angegeben. Optional besitzt der Client die öffentlichen Parameter der Identity Schemes der Server, um deren Authentizität überprüfen zu können. Für die Analyse wird davon ausgegangen, dass der Angreifer keinen physischen Zugriff auf den Client hat und daher keine Konfigurationsdateien ändern oder Parameter austauschen kann. Da das NTP-Protokoll alle Server miteinander vergleicht, um falsch-laufende Zeitquellen auszufiltern, muss der Angreifer in der Lage sein, die Pakete von der Mehrheit der Server zu ändern. Im Folgenden 2 Zum Beispiel Rechenleistung oder Netzwerkdurchsatz. 10

14 wird daher davon ausgegangen, dass sich der Angreifer als Man-in-the-Middle zwischen dem Client und einer Mehrheit der Server befindet. Um die Zeit des Clients zu manipulieren, muss der Angreifer in der Lage sein, auf Zeit-Anfragen des Clients mit einem NTP-Paket zu antworten, das einen gültigen bzw. vom Client akzeptierten Message Authentication Code enthält. Dies kann entweder möglich sein, wenn die verwendeten kryptographischen Primitive Sicherheitslücken beinhalten, falls der Angreifer in den Besitz der privaten Parameter eines Identity Schemes kommt, das Identity Scheme umgehen kann oder wenn der Angreifer in den Besitz des geheimen Cookies kommt, dass zwischen Client und Server zur Authentifizierung verwendet wird. Unzureichende Bitlängen Der Server Seed aus dem Client Cookies berechnet werden ist mit 32 Bit zu kurz. Ein Angreifer kann sich zu einem Server verbinden und von ihm ein Cookie erfragen. Die einzigen geheimen Informationen, die zur Berechnung des Cookies verwendet werden, ist der Server Seed (vgl. Formel 2.3). Durch einen Brute-Force-Angriff kann der Angreifer aus dem erhaltenen Cookie den Server Seed herausfinden. Dazu probiert er wie in Algorithmus 1 beschrieben jeden möglichen Server Seed durch und berechnet damit ein eigenes Cookie. Stimmt dieses Cookie mit dem vom Server erhaltenen überein, hat er den richtigen Server Seed gefunden und kann damit Cookies für andere Clients berechnen. Diese Cookies kann der Angreifer dann dazu verwenden um sich bei den zugehörigen Clients als Server auszugeben, da er in der Lage ist Message Authentication Codes zu fälschen. Algorithmus 1 Brute-Force-Algorithmus zum Berechnen des Server Seeds. for i = do C i H (Server-IP Client-IP 0 i) if C i = Cookie then return i end if end for Dieser Algorithmus wurde auf einem Intel Core i5 mit 2 2, 53 GHz unter Verwendung eines einzigen Threads ausprobiert. Dieser konnte die 2 32 MD5- Berechnungen in unter 25 Minuten durchführen. Das Cookie selbst ist mit 32 Bit ebenfalls zu kurz. Der Angreifer kann ein Paket aus der Client-Server-Kommunikation abfangen und durch einen Brute- Force-Angriff das Cookie aus diesem Paket erhalten. Dazu geht er analog zu Algorithmus 1 vor. Der Angreifer erstellt MACs für das abgefangene Paket und verwendet als Cookie alle möglichen Werte von 0 bis Die Ergebnisse 11

15 vergleicht er jeweils mit dem MAC, der an das Paket angehängt wurde. Stimmen sie überein, hat der Angreifer das Cookie gefunden und kann sich dadurch wieder als Server ausgeben. Für jedes Cookie muss der Angreifer eine MD5- Berechnung durchführen um den dazugehörigen Autokey zu erhalten, den er anschließend mit dem 48 Byte langen NTP-Paket konkateniert und erneut hasht. Der Angreifer muss somit für jedes Cookie zwei MD5-Berechnungen durchführen, wodurch der Angriff etwa die doppelte Zeit im Vergleich zu dem Brute-Force-Angriff auf den Server Seed benötigt. Client Identitätsprüfung Eine weitere Sicherheitslücke stellt die fehlende Prüfung der Identität des Clients dar. Der Server führt keine Authentizitätsprüfungen durch, sondern er verlässt sich auf die IP-Adresse des Clients. Zusätzlich hat er keinen Zustand über den Client und kann nicht erkennen, wenn eine Anfrage gestellt wird, die außerhalb der Protokoll-Reihenfolge ist. Dies kann ein Angreifer ausnutzen um das Cookie eines Clients zu erhalten. Die einzige Vorraussetzung dafür ist, dass der Angreifer seine IP-Adresse zu der des Clients ändern (spoofen) kann, die Antworten zu dieser IP-Adresse erhält und sie nach Bedarf zum Client weiterleiten oder verwerfen kann. Dies ist bei dem angenommenen Man-in-the-Middle-Szenario der Fall. Um das Cookie zu erhalten, ändert der Angreifer seine IP-Adresse zu der des Clients und schickt eine Cookie-Anfrage zu dem Server. Diese enthält einen öffentlichen Schlüssel (den des Angreifers), den der Server zum Verschlüsseln des Cookies verwendet. Daraufhin sendet der Server das verschlüsselte Cookie an die IP des Clients zurück. Der Angreifer erhält dieses Paket, da er sich zwischen Server und Client befindet und kann das Cookie mit seinem privaten Schlüssel entschlüsseln. Nun ist er im Besitz des Cookies des Clients und kann sich fortan als Server ausgeben. Abbildung 2.1 zeigt ein Sequenzdiagramm dieses Angriffs. Identity Schemes Das Trusted Certificate Scheme bietet keinerlei Sicherheit gegen Angriffe. Der Client vertraut in diesem Scheme automatisch jedem Zertifikat, dass den Text trustroot in einem Erweiterungsfeld enthält. Ein Angreifer kann sich leicht solch ein Zertifikat erstellen und sich damit als beliebiger Server ausgeben. Die drei Challenge-Response Schemes (IFF, GQ und MV) bieten ebenfalls keine Sicherheit gegen einen Angreifer. Ein Man-in-the-Middle kann ein Challenge des Clients an den echten Server weiterleiten. Von der Antwort des Servers, die die valide Response enthält, schneidet er die Signatur ab und ersetzt sie durch seine eigene. Dadurch nimmt der Client an, dass der Angrei- 12

16 NTP-Client IP C Man-in-the-Middle (spoofed IP) Cookie Request [PubKey P_C, IP ] NTP-Server S Enc (Cookie, P_C) Cookie Request [PubKey P_M, IP ] Enc (Cookie, P_M) Time Request, [KeyID x, MAC] [Angreifer kennt das Cookie für ] Time Response, [KeyID x, MAC] Enc(Msg, P_X): Nachricht 'Msg' verschlüsselt mit dem öffentlichen Schlüssel P_X Abbildung 2.1.: Angriff auf NTP-Autokey durch Ausnutzung der fehlenden Prüfung der Identität des Clients. 13

17 fer das Challenge beantworten konnte und vertraut ihm. Zusätzlich besitzen alle drei kryptographischen Protokolle gravierende Sicherheitslücken, die ihre Anwendung überflüssig machen und einem Angreifer immer ermöglichen eine Response zu versenden, die vom Client akzeptiert wird. Diese Sicherheitslücken werden detailliert in AbschnittA erläutert. Von den im Standard genannten Identitiy Schemes gewährleistet einzig das Private Certificate Scheme die Authentizität des Servers. Allerdings verwendet es Pre-shared-Keys und bietet keinen Vorteil gegenüber dem NTP-symmetrickey-Verfahren [1]. Es ist nur durch die Verwendung von NTP Secure Groups möglich einen eindeutigen Schlüssel für jeden Client zu verwenden. Andernfalls wäre es Clients möglich, sich gegenüber anderen Clients als Server auszugeben. Obwohl bereits in RFC 5906 [2] beschrieben ist, dass das Trusted Certificate Scheme keine Sicherheit gegen Man-in-the-Middle-Angriffe bietet, lässt sich die Referenzimplementierung nicht konfigurieren, so dass dieser Modus als unsicher angesehen wird. Die Wahl des Identity Schemes wird beim Verbindungsaufbau vom Server bestimmt, selbst wenn der Client ihn für ein anderes Scheme konfiguriert hat. Auch gibt es keine Warnung, wenn der Server das unsichere Trusted Certificate Scheme verwendet, es lässt sich lediglich manuell mit dem Programm ntpq auslesen. Dort ist das 32 Bit Status Word, dass in der Assoziations-Nachricht zwischen Server und Client ausgetauscht wird, als Hexadezimalzahl angegeben, wovon 4 Bits das verwendete Identity Scheme identifizieren Symmetrischer Modus Im symmetrischen Modus synchronisieren zwei NTP-Server ihre Zeit zueinander. Dabei wird zwischen dem aktiven Peer, der die Verbindung initiiert, und dem passiven Peer unterschieden. Die Message Authentication Codes und Autokeys werden analog zum Client-Server-Modus berechnet. Allerdings unterscheidet sich die Berechnung des Cookies. Während es beim Client-Server-Modus vom Server für jedes Paket neu berechnet wird, merken sich im symmetrischen Modus beide Peers das Cookie. Daher kann einer der Peers das Cookie als zufällige Zahl wählen Schlüsselerzeugung Als zusätzliche Sicherheitsmaßnahme werden die KeyIDs nicht zufällig gewählt sondern nach einem One-Time-Password-Verfahren von L. Lamport [7] berechnet. Beide Peers berechnen eine Folge von KeyIDs nach diesem Verfahren 14

18 und übermitteln dem jeweils anderen auf sicherem Weg das erste Element dieser Folge, wodurch dieser beim Erhalt eines Pakets überprüfen kann, ob die enthaltene KeyID zu dieser Folge gehört. Dazu wählt ein Peer eine zufällige KeyID I 0 als Startwert und berechnet mit ihr und dem vorher ausgehandelten Cookie nach Formel 2.1 den ersten Autokey K 0. Als nächste KeyID I 1 verwendet er die ersten 32 Bit von K 0. Alle weiteren KeyIDs I j und Autokeys K j für j {1,..., n} werden analog berechnet: K j = H (Sender-IP Empfänger-IP I j Cookie) I j = MSBs 32 (K j 1 ) Diese Autokeys und KeyIDs werden nun in umgekehrter Reihenfolge verwendet. Der Peer sendet seinem Kommunikationspartern zuerst auf sicherem Weg I n zu. Für die Message Authentication Codes der folgenden Pakete, verwendet er nacheinander I n 1, I n 2,..., I 0 als KeyIDs. Der Kommunikationspartner merkt sich die KeyID I x des zuletzt empfangenen Pakets des Peers. Beim Empfang eines neuen mit der KeyID I y berechnet er I z = MSBs 32 (H (Sender-IP Empfänger-IP I y Cookie)) und akzeptiert das Paket nur falls I z = I x gilt. Dieses Verfahren soll verhindern, dass ein Dritter ohne undurchführbaren Rechenaufwand KeyIDs selbst errechnet, die vom Kommunikationspartner akzeptiert werden. Dazu müsste der Dritte in der Lage sein die Urbildresistenz 3 der verwendeten kryptographischen Hashfunktion zu brechen. Allerdings ist das Verfahren anfällig gegen einen Brute-Force-Angriff, da die verwendeten KeyIDs mit 2 32 Bit zu kurz sind. Der Nachteil des Verfahrens ist, dass die ersten 32 Bit eines jeden Schlüssels verraten werden, da sie mit der vorher verwendeten KeyID übereinstimmen. Die effektive Schlüssellänge sinkt somit von 128 Bit auf 96 Bit. Im Client-Server Modus (vgl. Abschnitt 2.1) generiert der Client seine KeyIDs ebenfalls nach diesem Verfahren. Dort entsteht dadurch jedoch keine erhöhte Sicherheit, da der Server keinen State über den Client behält und sich nicht die zuletzt empfangene KeyID merkt. Da nur der Client dieses Verfahren verwendet, könnte allenfalls der Server die KeyID der Anfragen überprüfen. Der kritischere Teil, dass der Client die KeyIDs des Servers überprüft, ist nicht gewährleistet, da dieser für seine Antworten einfach die KeyID der Anfrage verwendet. 3 Für einen gegebenen Hash h sollte es praktisch unmöglich sein eine Nachricht M zu finden, für die gilt: H (M) = h. 15

19 Protokollablauf Der Parameteraustausch läuft im symmetrischen Modus bidirektional ab. Jedes Antwortpaket eines Peers kann gleichzeitig auch eine eigene Anfrage beinhalten. Im Folgenden wird zwischen dem aktiven Peer, der die Verbindung initiiert, und dem passiven Peer unterschieden. 1. Die Verbindung wird analog zum Client-Server-Modus mit einem Association-Paket initiiert. Wie in Abschnitt beschrieben, beinhaltet es den Autokey-Hostnamen des Peers sowie ein Status-Feld mit unterstützten kryptographischen Algorithmen. Die Antwort des passiven Peers geschieht ebenfalls analog zum Client-Server-Modus. 2. Daraufhin werden, abhängig vom verwendeten Identity Scheme, Zertifikate ausgetauscht und ein Challenge-Response-Protokoll durchgeführt. Dies passiert bidirektional. Der Ablauf ist der gleiche wie im Client-Server- Modus, nur dass jeder Peer einmal in der Rolle des Servers und einmal als Client auftritt. 3. Der Peer, der zuerst als Client den Zertifikats-Austausch oder das Challenge- Response-Protokoll durchgeführt hat, sendet eine Cookie-Anfrage an seinen Kommunikationspartner. Die Anfrage beinhaltet einen zur Verschlüsselung verwendeten öffentlichen Schlüssel des Senders, die Antwort enthält das verschlüsselte Cookie, dass folgend als gemeinsames Geheimnis verwendet wird. Das Cookie wird, im Gegensatz zum Client-Server-Modus, zufällig gewählt und von beiden Peers gespeichert. 4. Beide Peers generieren sich, wie in Abschnitt beschrieben, eine Liste aus Autokeys und erfragen vom jeweils Anderen das letzte Element aus dieser Liste mit einem Extension-Feld vom Typ Autokey. Die Autokey- Anfrage beinhaltet keine Informationen, während die Antwort die KeyID des letzten Elements der Liste, sowie den dazugehörigen Index enthält. 5. Fortan können beide Peers ihre Zeit synchronisieren, indem sie normale NTP-Pakete mit angehängter KeyID und MAC versenden. Beim Erhalt eines solchen Pakets, prüft der Empfänger ob die KeyID in die Liste passt, indem er sie mehrmals hasht und das Ergebnis mit der im vorigen Schritt erhaltenen vergleicht (vgl. Abschnitt 2.2.1) und berechnet schließlich den zugehörigen Autokey und überprüft damit den an das Paket angehängten Message Authentication Code. 16

20 Schwachstellen/Sicherheitsanalyse Der symmetrische Modus hat, genau wie der Client-Server-Modus, einige Schwachstellen, die ein Angreifer ausnutzen kann, um die gesamte Authentifizierung zu umgehen. Die Schlüssel-Erzeugung nach dem One-Time-Password- Verfahren von Lamport schützt nur gegen das Erstellen von Paketen durch einen Angreifer, nicht jedoch gegen Veränderung. Ein Angreifer als Man-in-the- Middle muss somit Antworten eines Peers abfangen und verändern und kann keine eigenen Antworten erstellen. Da die KeyIDs allerdings nur 32 Bit lang sind, kann er, falls er im Besitz des Cookies ist, gültige KeyIDs durch einen Brute-Force-Angriff in maximal 2 32 Schritten berechnen. Im Gegensatz zum Client-Server-Modus ist es im symmetrischen Modus dem Angreifer nicht möglich das Cookie von einem Peer durch spoofen der IP- Adresse zu erfragen, da dieses bei jeder Anfrage als zufälliger Wert generiert wird. Der Peer kann entweder erkennen, dass die Anfrage außerhalb der Protokoll- Reihenfolge geschieht und sie ignorieren, oder er erstellt ein neues Cookie, dass dann von dem abweicht, dass sich im Besitz des anderen Peers befindet. Ebenfalls ist ein Brute-Force-Angriff auf den Server Seed nicht mehr möglich, da dieser nicht mehr für die Generierung des Cookies verwendet wird. Der in Abschnitt beschriebene Brute-Force-Angriff auf das Cookie ist, da es nur 32 Bit lang ist, jedoch weiterhin möglich. Zusätzlich bleiben die Probleme mit den Identity Schemes bestehen. Dadurch kann der Angreifer, falls er den Verbindungsaufbau abfängt, die komplette Authentifizierung umgehen und sich als beliebiger Host ausgeben. 17

21 3. Alternativen Zur Zeit gibt es neben dem Autokey-Verfahren kein standardisiertes Verfahren zur authentifizierten Zeitsynchronisation. Da das Autokey-Verfahren jedoch fehlerhaft ist und keine Sicherheit bietet, bleibt als alternative Lösung neben der Überarbeitung des Autokey-Verfahrens nur ein bestehendes Zeitsynchronisations-Verfahren zu verwenden und Authentifizierung auf einer niedrigeren Schicht des Netzwerk-Stacks durchzuführen. Eine Authentifizierung, die nicht im Anwendungsprotokoll stattfindet bringt bei der Zeitsynchronisation eine Reihe von Nachteilen mit sich, die in Ungenauigkeit resultieren. Diese Ungenauigkeit entsteht dadurch, dass Hin- und Rückweg der Zeitanfragen durch die Authentifizierungsprotokolle ungleichmäßig erhöht werden. Das NTP-Verfahren geht in seiner Fehlerkorrektur davon aus, dass Hin- und Rückweg die gleiche Zeit benötigen, da sie nur die Summe der beiden kennen. Die halbierte Differenz dieser Zeiten wirkt sich somit als Ungenauigkeit aus. Protokolle die Authentifizierung gewährleisten führen im Regelfall anfänglich einen Schlüsselaustausch durch. Die Zeit die dieser Schlüsselaustausch benötigt verlängert den Hinweg einer Zeitanfrage. Da die Anwendung keine Kenntnis bzw. keine Kontrolle über die Authentifizierung hat, können die Zeiten die für Signaturen benötigt werden nicht kompensiert werden. Ist die Authentifizierung im Anwendungsprotokoll umgesetzt, können die Zeiten die zur Erstellung der Signatur benötigt werden abgeschätzt und ausgeglichen werden, indem der Zeitstempel im Paket vordatiert wird. Die Authentifizierungs-Mechanismen eines dritten Protokolls sind nicht auf die Ansprüche der Zeitsynchronisation ausgelegt. Es werden oft zeitaufwendige Algorithmen zur Signatur verwendet und die meisten Protokolle verschlüsseln die Daten zusätzlich. Häufig sind Authentifizierungs-Protokolle verbindungsorientiert. Daher muss entweder eine dauerhafte Verbindung zwischen Server und Client aufrecht erhalten werden oder für jedes Paket erneut hergestellt werden. 18

22 Im zweiten Fall wird für jedes Paket eine neue Parameteraushandlung durchgeführt, wodurch die Zeit des Hinwegs verlängert wird. Im Folgenden werden verschiedene Protokolle betrachtet, die verwendet werden können um eine Authentifizierung der NTP-Kommunikation zu gewährleisten IPsec IPsec ist ein Protokoll auf der Netzwerkschicht, dass Veschlüsselung und Authentifizierung durch zwei voneinander unabhängige Header sicherstellt. Der Authentication Header (AH) schützt die Authentizität des Payload durch einen Message Authentication Code oder eine Signatur, während der Encapsulating Security Payload zusätzlich Vertraulichkeit durch Verschlüsselung schützt. Eine Übersicht über das Protokoll wird in RFC 4301 [8] gegeben, Authentication Header und Encapsulating Security Payload sind in RFC 4302 [9] bzw. RFC 4303 [10] spezifiziert. IPsec kann in zwei verschiednenen Modi betrieben werden. Der Transport-Modus stellt eine Ende-zu-Ende-Verbindung zwischen zwei Rechnern her und fügt dazu den IPsec-Header zwischen dem IP-Header und dem Header des Transportschicht-Protokolls ein. Im Tunnel-Modus wird hingegen die Verbindung auf einer Teilstrecke der Kommunikation gesichert. Dazu wird das IP-Paket als Ganzes in ein anderes IP-Paket inklusive IPsec- Header eingepackt und zum Tunnel-Endpunkt gesendet. Dieser entnimmt das ursprüngliche IP-Paket und leitet es weiter. Die Verwendung von IPsec für die Authentifizierung von NTP-Paketen hat den Vorteil, dass keine Veränderung an der Anwendung nötig ist. Zusätzlich ist die Verschlüsselung optional und verursacht somit keinen unnötigen Overhead. Auf der anderen Seite bietet die Platzierung auf der Netzwerkschicht einen Nachteil gegenüber den anderen Protokollen. Sie erfordert eine Integration in den Netzwerkstack des Betriebssystems, der üblicherweise im Kernel implementiert ist. Dadurch ist IPsec bei gängigen Betriebssystemen ebenfalls Teil des Kernels, während Protokolle auf höheren Schichten durch Bibliotheken im User-Modus umgesetzt werden können und somit keine Ansprüche an das Betriebssystem stellen. N. Fergusson und B. Schneier haben IPsec in einem Paper von 2003 [11] analysiert und konnten einige Schwachstellen aufdecken. Sie kommen zu dem Fazit, dass IPsec zwar das beste zu dem Zeitpunkt existierende Protokoll für die Absicherung von IP-Paketen ist, die hohe Komplexität jedoch leicht zu unsicheren Konfigurationen führen kann und es nicht für den Einsatz in sicherheitskritischen Bereichen zu empfehlen ist. Die Komplexität des Schlüsselaustauschs wurde allerdings 2005 durch eine neue Version des Internet-Key-Exchange-Protokolls (IKE) [12] reduziert. 19

23 3.2. TLS-Tunnel (z. B. OpenVPN) Transport Layer Security (TLS) ist der abwärtskompatible Nachfolger von Secure Sockets Layer (SSL). Das Protokoll wird in RFC 5246 [13] beschrieben und bietet Verschlüsselung und Authentifizierung der Daten oberhalb der Transportschicht. Ein TLS-Tunnel, beispielsweise OpenVPN, versendet IP- Pakete über eine TLS-Verbindung. Am Endpunkt des TLS-Tunnels werden diese dann entschlüsselt, auf Authentizität überprüft und zu ihrem Ziel weitergeleitet. Da TLS oberhalb der Transportschicht aufsetzt, kann das Protokoll durch eine Bibliothek im User-Modus bereitgestellt werden. Ein TLS-Tunnel benötigt darüber hinaus allerdings die Unterstützung des Betriebssystems für virtuelle Netzwerk-Interfaces, die als Endpunkt für die TLS-Verbindung dienen. Da wie bei IPsec ganze IP-Pakete übertragen werden, sind Verschlüsselung und Authentifizierung transparent für die Anwendung und es sind keine Änderungen an ihr notwendig. Zusätzlich ist TLS ein etablierter Standard, der häufig auf Sicherheitslücken hin untersucht wurde und als sicher gilt [14, 15, 16] DTLS Datagram Transport Layer Security (DTLS) ist eine Adaption des TLS- Protokolls auf verbindungslose Transportschicht-Protokolle wie das User Datagram Protocol (UDP) oder das Datagram Congestion Control Protocol (DCCP). DTLS wurde 2004 entworfen [17] und 2006 als RFC 4347 [18] unter Verwendung von UDP als Transportschicht-Protokoll veröffentlicht. Ein wichtiges Design-Kriterium war es, möglichst wenig Änderungen zum TLS-Protokoll vorzunehmen, um dessen Sicherheits-Eigenschaften nicht zu verletzen. Allerdings war es nötig Zuverlässigkeit 1 für Handshakes umzusetzen und es wurden Sequenz- und Epochennummern eingeführt, durch die der Verlust von Nachrichten für einen neuen Parameteraustausch sowie Replays von Paketen erkannt werden können. Die Verwendung von DTLS bringt den Vorteil mit sich, dass es komplett in der Anwendung durch die Verwendung einer Bibliothek umgesetzt werden kann und keinerlei Ansprüche an das Betriebssystem stellt. Dies stellt ebenfalls einen Nachteil dar, da die Anwendung somit verändert werden muss um DTLS zu verwenden. Da das Protokoll im Vergleich noch relativ jung ist, gibt es bisher keine Sicherheitsanalysen in der Literatur. Durch seine hohe Ähnlichkeit zu 1 Eine Verbindung heisst zuverlässig, falls Paketverluste kompensiert werden und für eine Ordnung der Pakete gesorgt wird. 20

24 TLS, gibt es jedoch wenig Ansatzpunkte für Sicherheitslücken, die nicht auch in TLS selbst vorhanden wären Fazit Die Authentifizierung der NTP-Daten kann entweder auf der Transportschicht oder als Tunnel für IP-Pakete erfolgen. Transportschicht-Protkolle haben den Vorteil, dass sie keine Ansprüche an das Betriebssystem stellen, dafür erfordern sie jedoch eine Integration in die Anwendung. Eine Änderung der Anwendung erhöht jedoch den Wartungsaufwand, da neue Versionen, die beispielsweise kritische Sicherheitsupdates beinhalten können, eine Anpassung der vorgenommenen Änderungen nötig macht. Das Transportschicht-Protokoll DTLS wurde zwar bisher keinen Sicherheitsanalysen unterzogen, da es jedoch auf dem als sicher geltendenen TLS-Protokoll basiert, kann es als Alternative in Betracht gezogen werden. Das DTLS durch seine Änderungen Sicherheitslücken mit sich bringt, die in TLS nicht vorhanden sind kann aber dennoch nicht ausgeschlossen werden. IP-Tunnel hingegen werden vom Betriebssystem aufgebaut und sind transparent für die Anwendung. Somit werden auch keine Änderungen an ihr benötigt. Im direkten Vergleich zwischen auf IPsec und TLS basierenden Tunnellösungen, ist TLS klar vorzuziehen. Während bei IPsec vor allem die Komplexität negativ bewertet wird, konnten bei TLS in mehreren Analysen keine kritischen Sicherheitslücken identifiziert werden. Zusätzlich ist IPsec üblicherweise im Kernel des Betriebssystems implementiert, wodurch man unter Umständen keinen Zugang zum Quelltext für eine Analyse hat und an die Implementierung des Betriebssystem-Herstellers gebunden ist. 21

25 4. NTP-Autokey Verbesserungen Wie in Abschnitt gezeigt wurde hat das Autokey-Protokoll eine Reihe kritischer Sicherheitslücken, durch die das Protokoll unwirksam wird und keine Authentizität gewährleisten kann. In diesem Abschnitt werden Änderungen zum Autokey-Protokoll vorgestellt, die die gefundenen Sicherheitslücken mitigieren: Da die Identity Schemes, wie gezeigt wurde, keine Authentizität gewährleisten können, werden sie durch eine auf X.509 Zertifikaten basierende hierarchische Public-Key-Infrastruktur ersetzt. Der zur Verschlüsselung verwendete Public Key des Clients wird in die Cookie-Berechnung mit einbezogen. Dadurch wird verhindert, dass ein Angreifer vom Server das Cookie eines Clients erhalten kann, da dieser nur verschlüsselt mit dem Public Key des Clients versendet wird und somit nicht vom Angreifer entschlüsselt werden kann. Stellt der Angreifer hingegen die Schlüssel-Anfrage mit seinem eigenen Public Key, so wird das Cookie das er vom Server erhält von dem des Clients abweichen. Um Brute-Force-Angriffe zu verhindern, werden die Längen des Cookies sowie des Server Seeds von 32 auf 128 Bit erhöht. Die in Extension-Feldern enthaltene Signatur deckt das gesamte NTP- Paket ab. Optional: Die Berechnung des Message Authentication Codes wird durch Keyed-Hash Message Authentication Code (HMAC) ersetzt Hash- und MAC-Algorithmen Die Berechnung des Message Authentication Codes wird durchgeführt, nachdem der Transmit-Zeitstempel t 3 vom Server in das Paket eingefügt wurde. Die Zeit die diese Berechnung dauert fliesst somit in die Zeit des Rückwegs ein und bewirkt Asymmetrie zwischen Hin- und Rückweg, die wiederum in 22

26 Ungenauigkeit der Synchronisation resultiert. Zwar ist es denkbar den Transmit- Zeitstempel vorzudatieren und nach der Berechnung des MACs abzuwarten bis der eingetragene Zeitpunkt erreicht wurde, dazu muss jedoch die Zeit der MAC-Berechnung abgeschätzt werden, die abhängig von der Auslastung des Servers stark variieren kann. Trotzdem kann diese Vorgehensweise die durch die MAC-Berechnung erzeugte Zeitungenauigkeit bei normaler Last ausgleichen. Die Wahl der verwendeten Hash- und MAC-Algorithmen wirkt sich somit primär auf die beim Server entstehende Last aus, während die Genauigkeit nur bedingt davon beinflusst wird. Im folgenden soll die Sicherheit von möglichen Algorithmen analysiert werden. An eine kryptologische Hash-Funktion H werden zwei Anforderungen gestellt. Sie muss eine Einwegfunktion sein. Das bedeutet es sollte praktisch unmöglich sein für einen Hash-Wert h einen Klartext M zu finden, so dass H (M) = h gilt. Diese Eigenschaft wird auch Urbild-Resistenz genannt. Zusätzlich sollte die Hash-Funktion kollisionsresistent sein. Das heisst es sollte praktisch unmöglich sein zwei verschiedene Klartexte M 1 und M 2 zu finden, für die gilt H (M 1 ) = H (M 2 ). Im NTP-Autokey-Verfahren kommt eine Hash-Funktion an drei Stellen zum Einsatz. Für die Berechnung des Cookies sowie der Autokeys wird jeweils das MD5-Verfahren verwendet. Zur Berechnung der Message Authentication Codes kann sich der Server zwischen dem SHA-1- und dem MD5-Verfahren entscheiden. Für beide Verfahren wurde durch Angriffe gezeigt, dass sie keine Kollisionsresistenz bieten. Für SHA-1 kann mit einer Komplexität von 2 69 Schritten eine Kollision gefunden werden [19], während es bei MD5 schon in 2 21 Schritten möglich ist [20]. Angriffe auf die Urbild-Resistenz sind bei beiden Verfahren jedoch nicht bekannt. Bei der Cookie- und Autokey-Berechnung spielen Kollisionen keine Rolle, da der zugehörige Klartext nicht von einem Angreifer gewählt werden kann. Ein Angriff auf die Urbild-Resistenz könnte unter Umständen dazu führen, dass das Cookie aus einem Autokey bzw. der Server Seed aus dem Cookie erlangt werden kann. Bei der Berechnung des Message Authentication Codes würde ein erfolgreicher Angriff auf die Kollisionsresistenz dazu führen, dass ein Server zwei Pakete erstellen kann, die denselben MAC besitzen. Da der Server ohnehin MACs für beliebige Pakete erstellen kann scheint dies keine Angriffsmöglichkeit zu eröffnen. Die Kollisionsresistenz ist eine kritische Eigenschaft, wenn ein Server Daten von einem Dritten signiert, da dieser die Daten so gewählt haben kann, dass die Signatur ebenfalls für andere Daten gültig ist. Stevens et al. [21] haben beispielsweise gezeigt, dass es möglich war, durch einen Angriff auf die Kollisionsresistenz von MD5 sich ein gültiges Certificate-Authority-Zertifikat ausstellen zu lassen. Ein Angriff auf die Urbild-Resistenz könnte hingegen 23

27 unter Umständen dazu führen, dass der der Autokey aus einem Message Authentication Code erlangt werden kann. Somit ist nur die Urbild-Resistenz der verwendeten Hash-Funktion kritisch, während die Kollisionsresistenz zu vernachlässigen ist. Wie gezeigt wurde reicht MD5 als verwendete Hash-Funktion in allen Bereichen des Autokey-Protokolls aus. Da die verwendete Hash-Funktion jedoch nicht die Synchronisations-Genauigkeit beeinflusst, ist es sinnvoll einen Algorithmus zu wählen, der vom Bundesamt für Sicherheit in der Informationstechnit (BSI) oder vom NIST empfohlen wird. Dazu existiert der Federal Information Processing Standard (FIPS) [22], in dem kryptographische Algorithmen aufgelistet sind, die vom NIST validiert wurden sowie eine Übersicht über geignete Algorithmen vom BSI [23]. Dazu zählt unter anderem SHA-256. Message Authentication Code Algorithmen zum Erzeugen von Message Authentication Codes basieren oft auf Hash-Funktionen oder Block-Chiffren. Der im Autokey-Protokoll verwendete Algorithmus verwendet den Hash-Wert aus der Konkatenation von Autokey und NTP-Paket als MAC. Diese Konstruktion ist im Allgemeinen keine gute Idee. Basiert die verwendete Hash-Funktion auf der Merkle-Damgård-Konstruktion 1 [24], wie es beispielsweise bei MD5 und den SHA-Algorithmen der Fall ist, kann ein Angreifer ein authentifiziertes Paket abfangen, eigene Daten anhängen und den neuen MAC als Hash der neuen Daten berechnen, wobei er den alten MAC als Initialisierungs-Vektor für die Hash-Funktion verwendet. Gegebenenfalls muss er zusätzlich ein von der Hash-Funktion verwendetes Padding in das Paket einfügen. Im NTP-Protokoll ist dieser Angriff jedoch nicht möglich, da die Pakete, bei denen der MAC zur Authentifizierung verwendet wird, immer die gleiche Länge haben. Trotzdem ist es sinnvoll, den MAC-Algorithmus durch einen in FIPS vorgeschlagenen, wie zum Beispiel Keyed-Hash Message Authentication Code (HMAC) [25] mit SHA-256, zu ersetzen. Denkbar ist ebenfalls Hash- und MAC-Algorithmen nicht im Protokoll vorzuschreiben, sondern die Wahl dem Server zu überlassen. Dazu könnten die verwendeten Algorithmen im Association-Extension-Feld kodiert werden, in dem 4 Bits durch den Wegfall der Identity Schemes frei geworden sind. Dadurch könnte der Server, falls keine FIPS Konformität verlangt wird, Algorithmen verwenden, die weniger Last verursachen. 1 Bei der Merkle-Damgård-Konstruktion werden Blöcke sequentiell verarbeitet und die Ausgabe des letzten Blocks wird als Eingabe für die Verarbeitung des nächsten verwendet. 24

28 4.2. Authentifizierung Durch die Erweiterung des Autokey-Protokolls trägt jedes NTP-Paket, dass ein Extension-Feld beinhaltet, eine Signatur. Diese wird jedoch über das gesamte Paket, statt wie vorher nur über die Daten des Extension-Feldes, berechnet. NTP-Pakete ohne Extension-Feld, die für die Zeitsynchronisation verwendet werden, verwenden, wie im ursprünglichen Protokoll, einen Message Authentication Code zur Authentifizierung. Für dessen Berechnung kommt ein von Server und Client geteiltes Geheimnis zum Einsatz, das Cookie, dass der Server bei jeder Anfrage des Clients neu berechnen kann. Das Cookie C berechnet der Server aus dem Server Seed S und einem für Verschlüsselung verwendeten öffentlichen Schlüssel P C des Clients. Der Server Seed ist ein zufällig gewählter 128 Bit Wert, der vom Server geheim gehalten wird. Das Cookie wird daraufhin wie folgt berechnet: C = H (S, P C ) Dabei ist H eine nach den Überlegungen aus Abschnitt 4.1 gewählte Hash- Funktion. Zusätzlich sollte die Ausgabe der Hash-Funktion mindestens eine Länge von 128 Bit haben, da bei zu kleinen Werten, wie in Abschnitt gezeigt wurde, das Cookie aus einem Abgefangenen NTP-Paket durch einen Brute-Force-Angriff erlangt werden kann. Da der Server keinen State über seine Clients behält und er somit das Cookie bei jeder Zeit-Anfrage neu berechnen muss, muss der Client seinen öffentlichen Schlüssel mit jeder Anfrage mitsenden. Die für die MAC-Berechnung verwendeten Autokeys A I werden nun aus einer öffentlichen 32 Bit langen KeyID I berechnet, die ebenfalls an die versendeten Pakete angehängt wird. A I = H (I, C) Die Länge des Autokeys ist wieder abhängig von der verwendeten Hash-Funktion und sollte mindestens 128 Bit betragen Protokollablauf Assoziations-Nachricht Analog zum ursprünglichen Autokey-Protokoll beginnt der Ablauf mit einem Paket, dass ein Extension-Feld vom Typ association enthält. Dieses Extension-Feld enthält in der Anfrage den Hostnamen des Clients sowie ein Status-Wort, dass die für Signaturen verwendeten Algorithmen sowie den Status der Verbindung beinhaltet. Die Antwort enthält entsprechend den Hostnamen des Servers sowie die Signatur-Algorithmen. Die Bits, die das verwendete Identity Scheme beschrieben hatten fallen nun weg und können 25