Analyse des NTP-Autokey-Verfahrens

Größe: px
Ab Seite anzeigen:

Download "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

Informatik für Ökonomen II HS 09

Informatik für Ökonomen II HS 09 Informatik für Ökonomen II HS 09 Übung 5 Ausgabe: 03. Dezember 2009 Abgabe: 10. Dezember 2009 Die Lösungen zu den Aufgabe sind direkt auf das Blatt zu schreiben. Bitte verwenden Sie keinen Bleistift und

Mehr

FTP-Leitfaden RZ. Benutzerleitfaden

FTP-Leitfaden RZ. Benutzerleitfaden FTP-Leitfaden RZ Benutzerleitfaden Version 1.4 Stand 08.03.2012 Inhaltsverzeichnis 1 Einleitung... 3 1.1 Zeitaufwand... 3 2 Beschaffung der Software... 3 3 Installation... 3 4 Auswahl des Verbindungstyps...

Mehr

Multicast Security Group Key Management Architecture (MSEC GKMArch)

Multicast Security Group Key Management Architecture (MSEC GKMArch) Multicast Security Group Key Management Architecture (MSEC GKMArch) draft-ietf-msec-gkmarch-07.txt Internet Security Tobias Engelbrecht Einführung Bei diversen Internetanwendungen, wie zum Beispiel Telefonkonferenzen

Mehr

Netzsicherheit I, WS 2008/2009 Übung 12. Prof. Dr. Jörg Schwenk 20.01.2009

Netzsicherheit I, WS 2008/2009 Übung 12. Prof. Dr. Jörg Schwenk 20.01.2009 Netzsicherheit I, WS 2008/2009 Übung 12 Prof. Dr. Jörg Schwenk 20.01.2009 Aufgabe 1 1 Zertifikate im Allgemeinen a) Was versteht man unter folgenden Begriffen? i. X.509 X.509 ist ein Standard (Zertifikatsstandard)

Mehr

Verteilte Systeme. 10.1 Unsicherheit in Verteilten Systemen

Verteilte Systeme. 10.1 Unsicherheit in Verteilten Systemen Verteilte Systeme Übung 10 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 10.1 Unsicherheit in Verteilten

Mehr

Verteilte Systeme. Übung 10. Jens Müller-Iden

Verteilte Systeme. Übung 10. Jens Müller-Iden Verteilte Systeme Übung 10 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 10.1 Unsicherheit in Verteilten

Mehr

VIRTUAL PRIVATE NETWORKS

VIRTUAL PRIVATE NETWORKS VIRTUAL PRIVATE NETWORKS Seminar: Internet-Technologie Dozent: Prof. Dr. Lutz Wegner Virtual Private Networks - Agenda 1. VPN Was ist das? Definition Anforderungen Funktionsweise Anwendungsbereiche Pro

Mehr

Programmiertechnik II

Programmiertechnik II X.509: Eine Einführung X.509 ITU-T-Standard: Information Technology Open Systems Interconnection The Directory: Public Key and attribute certificate frameworks Teil des OSI Directory Service (X.500) parallel

Mehr

10.6 Authentizität. Geheimhaltung: nur der Empfänger kann die Nachricht lesen

10.6 Authentizität. Geheimhaltung: nur der Empfänger kann die Nachricht lesen 10.6 Authentizität Zur Erinnerung: Geheimhaltung: nur der Empfänger kann die Nachricht lesen Integrität: Nachricht erreicht den Empfänger so, wie sie abgeschickt wurde Authentizität: es ist sichergestellt,

Mehr

Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing.

Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing. www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Beschreibung und Bedienungsanleitung Werkzeug für verschlüsselte bpks

Mehr

Authentikation und digitale Signatur

Authentikation und digitale Signatur TU Graz 23. Jänner 2009 Überblick: Begriffe Authentikation Digitale Signatur Überblick: Begriffe Authentikation Digitale Signatur Überblick: Begriffe Authentikation Digitale Signatur Begriffe Alice und

Mehr

Guide DynDNS und Portforwarding

Guide DynDNS und Portforwarding Guide DynDNS und Portforwarding Allgemein Um Geräte im lokalen Netzwerk von überall aus über das Internet erreichen zu können, kommt man um die Themen Dynamik DNS (kurz DynDNS) und Portweiterleitung(auch

Mehr

Erste Vorlesung Kryptographie

Erste Vorlesung Kryptographie Erste Vorlesung Kryptographie Andre Chatzistamatiou October 14, 2013 Anwendungen der Kryptographie: geheime Datenübertragung Authentifizierung (für uns = Authentisierung) Daten Authentifizierung/Integritätsprüfung

Mehr

Bernd Blümel. Verschlüsselung. Prof. Dr. Blümel

Bernd Blümel. Verschlüsselung. Prof. Dr. Blümel Bernd Blümel 2001 Verschlüsselung Gliederung 1. Symetrische Verschlüsselung 2. Asymetrische Verschlüsselung 3. Hybride Verfahren 4. SSL 5. pgp Verschlüsselung 111101111100001110000111000011 1100110 111101111100001110000111000011

Mehr

Effizienten MAC-Konstruktion aus der Praxis: NMAC Idee von NMAC:

Effizienten MAC-Konstruktion aus der Praxis: NMAC Idee von NMAC: Effizienten MAC-Konstruktion aus der Praxis: NMAC Idee von NMAC: Hashe m {0, 1} auf einen Hashwert in {0, 1} n. Verwende Π MAC3 für Nachrichten fixer Länge auf dem Hashwert. Wir konstruieren Π MAC3 mittels

Mehr

11. Das RSA Verfahren und andere Verfahren

11. Das RSA Verfahren und andere Verfahren Chr.Nelius: Kryptographie (SS 2011) 31 11. Das RSA Verfahren und andere Verfahren Eine konkrete Realisierung eines Public Key Kryptosystems ist das sog. RSA Verfahren, das im Jahre 1978 von den drei Wissenschaftlern

Mehr

TCP SYN Flood - Attack. Beschreibung Auswirkungen Zuordnung zu Gefährdungskategorie und Attacken-Art Gegenmaßnahmen Quellen

TCP SYN Flood - Attack. Beschreibung Auswirkungen Zuordnung zu Gefährdungskategorie und Attacken-Art Gegenmaßnahmen Quellen TCP SYN Flood - Attack Beschreibung Auswirkungen Zuordnung zu Gefährdungskategorie und Attacken-Art Gegenmaßnahmen Quellen TCP SYN Flood - Beschreibung TCP SYN Flood Denial of Service Attacke Attacke nutzt

Mehr

Senden von strukturierten Berichten über das SFTP Häufig gestellte Fragen

Senden von strukturierten Berichten über das SFTP Häufig gestellte Fragen Senden von strukturierten Berichten über das SFTP Häufig gestellte Fragen 1 Allgemeines Was versteht man unter SFTP? Die Abkürzung SFTP steht für SSH File Transfer Protocol oder Secure File Transfer Protocol.

Mehr

Verschlüsselung. Kirchstraße 18 Steinfelderstraße 53 76831 Birkweiler 76887 Bad Bergzabern. 12.10.2011 Fabian Simon Bfit09

Verschlüsselung. Kirchstraße 18 Steinfelderstraße 53 76831 Birkweiler 76887 Bad Bergzabern. 12.10.2011 Fabian Simon Bfit09 Verschlüsselung Fabian Simon BBS Südliche Weinstraße Kirchstraße 18 Steinfelderstraße 53 76831 Birkweiler 76887 Bad Bergzabern 12.10.2011 Fabian Simon Bfit09 Inhaltsverzeichnis 1 Warum verschlüsselt man?...3

Mehr

E-Mail-Verschlüsselung mit S/MIME

E-Mail-Verschlüsselung mit S/MIME E-Mail-Verschlüsselung mit S/MIME 17. November 2015 Inhaltsverzeichnis 1 Zertifikat erstellen 1 2 Zertifikat speichern 4 3 Zertifikat in Thunderbird importieren 6 4 Verschlüsselte Mail senden 8 5 Verschlüsselte

Mehr

IT-Sicherheit Kapitel 11 SSL/TLS

IT-Sicherheit Kapitel 11 SSL/TLS IT-Sicherheit Kapitel 11 SSL/TLS Dr. Christian Rathgeb Sommersemester 2014 1 Einführung SSL/TLS im TCP/IP-Stack: SSL/TLS bietet (1) Server-Authentifizierung oder Server und Client- Authentifizierung (2)

Mehr

Datenempfang von crossinx

Datenempfang von crossinx Datenempfang von crossinx Datenempfang.doc Seite 1 von 6 Inhaltsverzeichnis 1 Einführung... 3 2 AS2... 3 3 SFTP... 3 4 FTP (via VPN)... 4 5 FTPS... 4 6 Email (ggf. verschlüsselt)... 5 7 Portalzugang über

Mehr

Möglichkeiten der verschlüsselten E-Mail-Kommunikation mit der AUDI AG Stand: 11/2015

Möglichkeiten der verschlüsselten E-Mail-Kommunikation mit der AUDI AG Stand: 11/2015 Möglichkeiten der verschlüsselten E-Mail-Kommunikation mit der AUDI AG Stand: 11/2015 Möglichkeiten der verschlüsselten E-Mail-Kommunikation mit der AUDI AG Vertrauliche Informationen dürfen von und zur

Mehr

Kryptographische Anonymisierung bei Verkehrsflussanalysen

Kryptographische Anonymisierung bei Verkehrsflussanalysen Kryptographische Anonymisierung bei Verkehrsflussanalysen Autor: Andreas Grinschgl copyright c.c.com GmbH 2010 Das System besteht aus folgenden Hauptkomponenten: Sensorstationen Datenbankserver Anonymisierungsserver

Mehr

Datenübertragungsportal

Datenübertragungsportal Datenübertragungsportal seite zwei Inhalt Inhalt seite zwei Datenübertragungsportal seite drei Erreichte Schutzziele seite acht seite drei Datenübertragungsportal Die Firmengruppe Melter stellt Ihren Kunden

Mehr

Nachrichten- Verschlüsselung Mit S/MIME

Nachrichten- Verschlüsselung Mit S/MIME Nachrichten- Verschlüsselung Mit S/MIME Höma, watt is S/MIME?! S/MIME ist eine Methode zum signieren und verschlüsseln von Nachrichten, ähnlich wie das in der Öffentlichkeit vielleicht bekanntere PGP oder

Mehr

Bedienungsanleitung für den SecureCourier

Bedienungsanleitung für den SecureCourier Bedienungsanleitung für den SecureCourier Wo kann ich den SecureCourier nach der Installation auf meinem Computer finden? Den SecureCourier finden Sie dort, wo Sie mit Dateien umgehen und arbeiten. Bei

Mehr

SSL Secure Socket Layer Algorithmen und Anwendung

SSL Secure Socket Layer Algorithmen und Anwendung SSL Secure Socket Layer Algorithmen und Anwendung Präsentation vom 03.06.2002 Stefan Pfab 2002 Stefan Pfab 1 Überblick Motivation SSL-Architektur Verbindungsaufbau Zertifikate, Certification Authorities

Mehr

Anleitung Thunderbird Email Verschlu sselung

Anleitung Thunderbird Email Verschlu sselung Anleitung Thunderbird Email Verschlu sselung Christoph Weinandt, Darmstadt Vorbemerkung Diese Anleitung beschreibt die Einrichtung des AddOn s Enigmail für den Mailclient Thunderbird. Diese Anleitung gilt

Mehr

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL 1 TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL Kleine Auswahl bekannter Sicherheitsprotokolle X.509 Zertifikate / PKIX Standardisierte, häufig verwendete Datenstruktur zur Bindung von kryptographischen

Mehr

Übersicht. Was ist FTP? Übertragungsmodi. Sicherheit. Öffentliche FTP-Server. FTP-Software

Übersicht. Was ist FTP? Übertragungsmodi. Sicherheit. Öffentliche FTP-Server. FTP-Software FTP Übersicht Was ist FTP? Übertragungsmodi Sicherheit Öffentliche FTP-Server FTP-Software Was ist FTP? Protokoll zur Dateiübertragung Auf Schicht 7 Verwendet TCP, meist Port 21, 20 1972 spezifiziert Übertragungsmodi

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

Konfiguration VLAN's. Konfiguration VLAN's IACBOX.COM. Version 2.0.1 Deutsch 01.07.2014

Konfiguration VLAN's. Konfiguration VLAN's IACBOX.COM. Version 2.0.1 Deutsch 01.07.2014 Konfiguration VLAN's Version 2.0.1 Deutsch 01.07.2014 In diesem HOWTO wird die Konfiguration der VLAN's für das Surf-LAN der IAC-BOX beschrieben. Konfiguration VLAN's TITEL Inhaltsverzeichnis Inhaltsverzeichnis...

Mehr

Powermanager Server- Client- Installation

Powermanager Server- Client- Installation Client A Server Client B Die Server- Client- Funktion ermöglicht es ein zentrales Powermanager Projekt von verschiedenen Client Rechnern aus zu bedienen. 1.0 Benötigte Voraussetzungen 1.1 Sowohl am Server

Mehr

Diffie-Hellman, ElGamal und DSS. Vortrag von David Gümbel am 28.05.2002

Diffie-Hellman, ElGamal und DSS. Vortrag von David Gümbel am 28.05.2002 Diffie-Hellman, ElGamal und DSS Vortrag von David Gümbel am 28.05.2002 Übersicht Prinzipielle Probleme der sicheren Nachrichtenübermittlung 'Diskreter Logarithmus'-Problem Diffie-Hellman ElGamal DSS /

Mehr

Version 2.0.1 Deutsch 03.06.2014. In diesem HOWTO wird beschrieben wie Sie Ihren Gästen die Anmeldung über eine SMS ermöglichen.

Version 2.0.1 Deutsch 03.06.2014. In diesem HOWTO wird beschrieben wie Sie Ihren Gästen die Anmeldung über eine SMS ermöglichen. Version 2.0.1 Deutsch 03.06.2014 In diesem HOWTO wird beschrieben wie Sie Ihren Gästen die Anmeldung über eine SMS ermöglichen. Inhaltsverzeichnis... 1 1. Hinweise... 2 2. Konfiguration... 3 2.1. Generische

Mehr

Man liest sich: POP3/IMAP

Man liest sich: POP3/IMAP Man liest sich: POP3/IMAP Gliederung 1. Einführung 1.1 Allgemeiner Nachrichtenfluss beim Versenden von E-Mails 1.2 Client und Server 1.2.1 Client 1.2.2 Server 2. POP3 2.1 Definition 2.2 Geschichte und

Mehr

WLAN und VPN im b.i.b. mit Windows (Vista Home Premium SP1) oder Windows 7

WLAN und VPN im b.i.b. mit Windows (Vista Home Premium SP1) oder Windows 7 WLAN Bei Windows Vista Home Premium mit Service Pack 1 wrd unten rechts im Tray angezeigt, wenn Drahtlosnetzwerke verfügbar sind, ebenso bei Windows 7. Solange keine Verbindung mit diesen Drahtlosnetzwerken

Mehr

Eine Open Source SSL VPN Lösung. Patrick Oettinger Deutsche Telekom AG 2. Ausbildungsjahr

Eine Open Source SSL VPN Lösung. Patrick Oettinger Deutsche Telekom AG 2. Ausbildungsjahr p Eine Open Source SSL VPN Lösung Patrick Oettinger Deutsche Telekom AG 2. Ausbildungsjahr Inhaltsverzeichnis Simon Singh über die Verschlüsslungen Facts about OpenVPN Hintergrund Funktionsweise inkl.

Mehr

vorab noch ein paar allgemeine informationen zur de-mail verschlüsselung:

vorab noch ein paar allgemeine informationen zur de-mail verschlüsselung: Kurzanleitung De-Mail Verschlüsselung so nutzen sie die verschlüsselung von de-mail in vier schritten Schritt 1: Browser-Erweiterung installieren Schritt 2: Schlüsselpaar erstellen Schritt 3: Schlüsselaustausch

Mehr

Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird.

Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird. Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird. Auch die Unternehmensgruppe ALDI Nord steht mit einer Vielzahl

Mehr

Symmetrische und Asymmetrische Kryptographie. Technik Seminar 2012

Symmetrische und Asymmetrische Kryptographie. Technik Seminar 2012 Symmetrische und Asymmetrische Kryptographie Technik Seminar 2012 Inhalt Symmetrische Kryptographie Transpositionchiffre Substitutionchiffre Aktuelle Verfahren zur Verschlüsselung Hash-Funktionen Message

Mehr

Das RSA-Verschlüsselungsverfahren 1 Christian Vollmer

Das RSA-Verschlüsselungsverfahren 1 Christian Vollmer Das RSA-Verschlüsselungsverfahren 1 Christian Vollmer Allgemein: Das RSA-Verschlüsselungsverfahren ist ein häufig benutztes Verschlüsselungsverfahren, weil es sehr sicher ist. Es gehört zu der Klasse der

Mehr

9 Schlüsseleinigung, Schlüsselaustausch

9 Schlüsseleinigung, Schlüsselaustausch 9 Schlüsseleinigung, Schlüsselaustausch Ziel: Sicherer Austausch von Schlüsseln über einen unsicheren Kanal initiale Schlüsseleinigung für erste sichere Kommunikation Schlüsselerneuerung für weitere Kommunikation

Mehr

Import des persönlichen Zertifikats in Outlook 2003

Import des persönlichen Zertifikats in Outlook 2003 Import des persönlichen Zertifikats in Outlook 2003 1. Installation des persönlichen Zertifikats 1.1 Voraussetzungen Damit Sie das persönliche Zertifikat auf Ihren PC installieren können, benötigen Sie:

Mehr

Voll homomorpe Verschlüsselung

Voll homomorpe Verschlüsselung Voll homomorpe Verschlüsselung Definition Voll homomorphe Verschlüsselung Sei Π ein Verschlüsselungsverfahren mit Enc : R R für Ringe R, R. Π heißt voll homomorph, falls 1 Enc(m 1 ) + Enc(m 2 ) eine gültige

Mehr

GnuPG für Mail Mac OS X 10.4 und 10.5

GnuPG für Mail Mac OS X 10.4 und 10.5 GnuPG für Mail Mac OS X 10.4 und 10.5 6. Nachrichten verschlüsseln und entschlüsseln mit Mail http://verbraucher-sicher-online.de/ 22.10.2009 Sie haben GPG installiert. Sie haben ein Schlüsselpaar und

Mehr

Benutzerzertifikate für Java Webstart

Benutzerzertifikate für Java Webstart Benutzerzertifikate für Java Webstart Benutzerdokumentation Wien 5. Dezember 2011 Florian Bruckner, Florian Heinisch 3kraft IT GmbH & Co KG Wasagasse 26/2 1090 Wien Österreich Tel: +43 1 920 45 49 Fax

Mehr

Sichere E-Mails. Kundeninformation zur Verschlüsselung von E-Mails in der L-Bank

Sichere E-Mails. Kundeninformation zur Verschlüsselung von E-Mails in der L-Bank Sichere E-Mails Kundeninformation zur Verschlüsselung von E-Mails in der L-Bank Version: 2.1 Stand: 18.07.2014 Inhaltsverzeichnis II Inhaltsverzeichnis 1 Einleitung... 1 1.1 Überblick... 1 1.2 Allgemeine

Mehr

Import des persönlichen Zertifikats in Outlook Express

Import des persönlichen Zertifikats in Outlook Express Import des persönlichen Zertifikats in Outlook Express 1.Installation des persönlichen Zertifikats 1.1 Voraussetzungen Damit Sie das persönliche Zertifikat auf Ihrem PC installieren können, benötigen

Mehr

Kundeninformationen zur Sicheren E-Mail

Kundeninformationen zur Sicheren E-Mail S Sparkasse der Stadt Iserlohn Kundeninformationen zur Sicheren E-Mail Informationen zur Sicheren E-Mail erhalten Sie bei Ihrem Berater, oder bei den Mitarbeiter aus dem Team ElectronicBanking unter der

Mehr

Benutzerhandbuch. bintec elmeg GmbH. Benutzerhandbuch. be.ip. Workshops. Copyright Version 1.0, 2015 bintec elmeg GmbH

Benutzerhandbuch. bintec elmeg GmbH. Benutzerhandbuch. be.ip. Workshops. Copyright Version 1.0, 2015 bintec elmeg GmbH Benutzerhandbuch Benutzerhandbuch Workshops Copyright Version 1.0, 2015 1 Benutzerhandbuch Rechtlicher Hinweis Gewährleistung Änderungen in dieser Veröffentlichung sind vorbehalten. gibt keinerlei Gewährleistung

Mehr

Abruf und Versand von Mails mit Verschlüsselung

Abruf und Versand von Mails mit Verschlüsselung Bedienungstip: Verschlüsselung Seite 1 Abruf und Versand von Mails mit Verschlüsselung Die folgende Beschreibung erklärt, wie man mit den üblichen Mailprogrammen die E- Mailabfrage und den E-Mail-Versand

Mehr

10. Kryptographie. Was ist Kryptographie?

10. Kryptographie. Was ist Kryptographie? Chr.Nelius: Zahlentheorie (SoSe 2015) 39 10. Kryptographie Was ist Kryptographie? Die Kryptographie handelt von der Verschlüsselung (Chiffrierung) von Nachrichten zum Zwecke der Geheimhaltung und von dem

Mehr

Network Time Protocol NTP

Network Time Protocol NTP Network Time Protocol NTP Autor: Luca Costa, HTW Chur, luca.costa@tet.htwchur.ch Dozent: Bruno Wenk, HTW Chur, bruno.wenk@fh-htwchur.ch Inhaltsverzeichnis 1 Network Time Protocol... 3 1.1 Einleitung...

Mehr

Stammtisch 04.12.2008. Zertifikate

Stammtisch 04.12.2008. Zertifikate Stammtisch Zertifikate Ein Zertifikat ist eine Zusicherung / Bestätigung / Beglaubigung eines Sachverhalts durch eine Institution in einem definierten formalen Rahmen 1 Zertifikate? 2 Digitale X.509 Zertifikate

Mehr

E-Mail-Verschlüsselung viel einfacher als Sie denken!

E-Mail-Verschlüsselung viel einfacher als Sie denken! E-Mail-Verschlüsselung viel einfacher als Sie denken! Stefan Cink Produktmanager stefan.cink@netatwork.de Seite 1 Welche Anforderungen haben Sie an eine E-Mail? Seite 2 Anforderungen an die E-Mail Datenschutz

Mehr

Umstellung des Schlüsselpaares der Elektronischen Unterschrift von A003 (768 Bit) auf A004 (1024 Bit)

Umstellung des Schlüsselpaares der Elektronischen Unterschrift von A003 (768 Bit) auf A004 (1024 Bit) Umstellung des Schlüsselpaares der Elektronischen Unterschrift von A003 (768 Bit) auf A004 (1024 Bit) 1. Einleitung Die Elektronische Unterschrift (EU) dient zur Autorisierung und Integritätsprüfung von

Mehr

Einrichten eines Postfachs mit Outlook Express / Outlook bis Version 2000

Einrichten eines Postfachs mit Outlook Express / Outlook bis Version 2000 Folgende Anleitung beschreibt, wie Sie ein bestehendes Postfach in Outlook Express, bzw. Microsoft Outlook bis Version 2000 einrichten können. 1. Öffnen Sie im Menü die Punkte Extras und anschließend Konten

Mehr

Virtual Private Network. David Greber und Michael Wäger

Virtual Private Network. David Greber und Michael Wäger Virtual Private Network David Greber und Michael Wäger Inhaltsverzeichnis 1 Technische Grundlagen...3 1.1 Was ist ein Virtual Private Network?...3 1.2 Strukturarten...3 1.2.1 Client to Client...3 1.2.2

Mehr

Security Associations Schlüsseltausch IKE Internet Key Exchange Automatischer Schlüsseltausch und Identitätsnachweis

Security Associations Schlüsseltausch IKE Internet Key Exchange Automatischer Schlüsseltausch und Identitätsnachweis Wie Interoperabel ist IPsec? Ein Erfahrungsbericht Arturo Lopez Senior Consultant März 2003 Agenda Internet Protokoll Security (IPsec) implementiert Sicherheit auf Layer 3 in OSI Modell Application Presentation

Mehr

Anti-Botnet-Beratungszentrum. Windows XP in fünf Schritten absichern

Anti-Botnet-Beratungszentrum. Windows XP in fünf Schritten absichern Windows XP in fünf Schritten absichern Inhalt: 1. Firewall Aktivierung 2. Anwendung eines Anti-Virus Scanner 3. Aktivierung der automatischen Updates 4. Erstellen eines Backup 5. Setzen von sicheren Passwörtern

Mehr

Sicherheit in Netzwerken. Leonard Claus, WS 2012 / 2013

Sicherheit in Netzwerken. Leonard Claus, WS 2012 / 2013 Sicherheit in Netzwerken Leonard Claus, WS 2012 / 2013 Inhalt 1 Definition eines Sicherheitsbegriffs 2 Einführung in die Kryptografie 3 Netzwerksicherheit 3.1 E-Mail-Sicherheit 3.2 Sicherheit im Web 4

Mehr

Collax VPN. Howto. Vorraussetzungen Collax Security Gateway Collax Business Server Collax Platform Server inkl. Collax Modul Gatekeeper

Collax VPN. Howto. Vorraussetzungen Collax Security Gateway Collax Business Server Collax Platform Server inkl. Collax Modul Gatekeeper Collax VPN Howto Dieses Howto beschreibt exemplarisch die Einrichtung einer VPN Verbindung zwischen zwei Standorten anhand eines Collax Business Servers (CBS) und eines Collax Security Gateways (CSG).

Mehr

Ist das so mit HTTPS wirklich eine gute Lösung?

Ist das so mit HTTPS wirklich eine gute Lösung? SSL/TLS und PKI im Internet Erik Tews erik@datenzone.de Ist das so mit HTTPS wirklich eine gute Lösung? 21.05.2012 Erik Tews 1 Was ist PKI Asymmetrische Kryptographie ist echt praktisch Schlüssel bestehen

Mehr

Technical Note 32. 2 ewon über DSL & VPN mit einander verbinden

Technical Note 32. 2 ewon über DSL & VPN mit einander verbinden Technical Note 32 2 ewon über DSL & VPN mit einander verbinden TN_032_2_eWON_über_VPN_verbinden_DSL Angaben ohne Gewähr Irrtümer und Änderungen vorbehalten. 1 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis...

Mehr

E-Mail Verschlüsselung

E-Mail Verschlüsselung E-Mail Verschlüsselung S/MIME Standard Disclaimer: In der Regel lässt sich die Verschlüsselungsfunktion störungsfrei in den E-Mail-Programmen einrichten. Es wird aber darauf hingewiesen, dass in einigen

Mehr

IRF2000 Application Note Lösung von IP-Adresskonflikten bei zwei identischen Netzwerken

IRF2000 Application Note Lösung von IP-Adresskonflikten bei zwei identischen Netzwerken Version 2.0 1 Original-Application Note ads-tec GmbH IRF2000 Application Note Lösung von IP-Adresskonflikten bei zwei identischen Netzwerken Stand: 27.10.2014 ads-tec GmbH 2014 IRF2000 2 Inhaltsverzeichnis

Mehr

Virtual Private Network

Virtual Private Network Virtual Private Network Allgemeines zu VPN-Verbindungen WLAN und VPN-TUNNEL Der VPN-Tunnel ist ein Programm, das eine sichere Verbindung zur Universität herstellt. Dabei übernimmt der eigene Rechner eine

Mehr

Ein Hinweis vorab: Mailkonfiguration am Beispiel von Thunderbird

Ein Hinweis vorab: Mailkonfiguration am Beispiel von Thunderbird Mailkonfiguration am Beispiel von Thunderbird Ein Hinweis vorab: Sie können beliebig viele verschiedene Mailkonten für Ihre Domain anlegen oder löschen. Das einzige Konto, das nicht gelöscht werden kann,

Mehr

Zeichen bei Zahlen entschlüsseln

Zeichen bei Zahlen entschlüsseln Zeichen bei Zahlen entschlüsseln In diesem Kapitel... Verwendung des Zahlenstrahls Absolut richtige Bestimmung von absoluten Werten Operationen bei Zahlen mit Vorzeichen: Addieren, Subtrahieren, Multiplizieren

Mehr

Online Schulung Anmerkungen zur Durchführung

Online Schulung Anmerkungen zur Durchführung Online Schulung Anmerkungen zur Durchführung 1.0 Einleitung Vielen Dank, dass Sie sich für die Online Schulung von SoloProtect entschieden haben. Nachfolgend finden Sie Informationen für Identicomnutzer

Mehr

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als

Mehr

Virtual Private Network

Virtual Private Network Virtual Private Network Unter einem Virtual Private Network (VPN) versteht man eine durch geeignete Verschlüsselungs- und Authentifizierungsmechanismen geschützte Verbindung zwischen 2 Rechnern ( und VPN-Gateway)

Mehr

EasyWk DAS Schwimmwettkampfprogramm

EasyWk DAS Schwimmwettkampfprogramm EasyWk DAS Schwimmwettkampfprogramm Arbeiten mit OMEGA ARES 21 EasyWk - DAS Schwimmwettkampfprogramm 1 Einleitung Diese Präsentation dient zur Darstellung der Zusammenarbeit zwischen EasyWk und der Zeitmessanlage

Mehr

Handbuch B4000+ Preset Manager

Handbuch B4000+ Preset Manager Handbuch B4000+ Preset Manager B4000+ authentic organ modeller Version 0.6 FERROFISH advanced audio applications Einleitung Mit der Software B4000+ Preset Manager können Sie Ihre in der B4000+ erstellten

Mehr

Leitfaden zur Nutzung von binder CryptShare

Leitfaden zur Nutzung von binder CryptShare Leitfaden zur Nutzung von binder CryptShare Franz Binder GmbH & Co. Elektrische Bauelemente KG Rötelstraße 27 74172 Neckarsulm Telefon +49 (0) 71 32-325-0 Telefax +49 (0) 71 32-325-150 Email info@binder-connector

Mehr

Verschlüsselte E-Mails: Wie sicher ist sicher?

Verschlüsselte E-Mails: Wie sicher ist sicher? Verschlüsselte E-Mails: Wie sicher ist sicher? Mein Name ist Jörg Reinhardt Linux-Administrator und Support-Mitarbeiter bei der JPBerlin JPBerlin ist ein alteingesessener Provider mit zwei Dutzend Mitarbeitern

Mehr

FTP-Leitfaden Inhouse. Benutzerleitfaden

FTP-Leitfaden Inhouse. Benutzerleitfaden FTP-Leitfaden Inhouse Benutzerleitfaden Version 1.4 Stand 08.03.2012 Inhaltsverzeichnis 1 Einleitung... 3 1.1 Zeitaufwand... 3 2 Beschaffung der Software... 3 3 Installation... 3 4 Konfigurieren der Firewall...

Mehr

Import des persönlichen Zertifikats in Outlook2007

Import des persönlichen Zertifikats in Outlook2007 Import des persönlichen Zertifikats in Outlook2007 1. Installation des persönlichen Zertifikats 1.1 Voraussetzungen Damit Sie das persönliche Zertifikat auf Ihren PC installieren können, benötigen Sie:

Mehr

Das Kerberos-Protokoll

Das Kerberos-Protokoll Konzepte von Betriebssystemkomponenten Schwerpunkt Authentifizierung Das Kerberos-Protokoll Referent: Guido Söldner Überblick über Kerberos Network Authentication Protocol Am MIT Mitte der 80er Jahre entwickelt

Mehr

Merkblatt: Sichere E-Mail-Kommunikation zur datenschutz cert GmbH

Merkblatt: Sichere E-Mail-Kommunikation zur datenschutz cert GmbH Version 1.3 März 2014 Merkblatt: Sichere E-Mail-Kommunikation zur datenschutz cert GmbH 1. Relevanz der Verschlüsselung E-Mails lassen sich mit geringen Kenntnissen auf dem Weg durch die elektronischen

Mehr

OP-LOG www.op-log.de

OP-LOG www.op-log.de Verwendung von Microsoft SQL Server, Seite 1/18 OP-LOG www.op-log.de Anleitung: Verwendung von Microsoft SQL Server 2005 Stand Mai 2010 1 Ich-lese-keine-Anleitungen 'Verwendung von Microsoft SQL Server

Mehr

Schulberichtssystem. Inhaltsverzeichnis

Schulberichtssystem. Inhaltsverzeichnis Schulberichtssystem Inhaltsverzeichnis 1. Erfassen der Schüler im SBS...2 2. Erzeugen der Export-Datei im SBS...3 3. Die SBS-Datei ins FuxMedia-Programm einlesen...4 4. Daten von FuxMedia ins SBS übertragen...6

Mehr

Sichere E-Mail Kommunikation mit Ihrer Sparkasse

Sichere E-Mail Kommunikation mit Ihrer Sparkasse Ein zentrales Anliegen der Sparkasse Rottal-Inn ist die Sicherheit der Bankgeschäfte unserer Kunden. Vor dem Hintergrund zunehmender Wirtschaftskriminalität im Internet und aktueller Anforderungen des

Mehr

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank

Mehr

Mobile Anwendungen Google Cloud Messaging

Mobile Anwendungen Google Cloud Messaging Mobile Anwendungen Google Cloud Messaging 1. Allgemeines zu Google Cloud Messaging (GCM): - 60% der Top 100 Apps nutzen Google Cloud Messagging - 200.000 Messages pro Sekunde = 17 Milliarden Messages pro

Mehr

8. Bintec Router Redundancy Protocol (BRRP) 8.1 Einleitung

8. Bintec Router Redundancy Protocol (BRRP) 8.1 Einleitung 8. Bintec Router Redundancy Protocol (BRRP) 8.1 Einleitung Im Folgenden wird die Konfiguration von BRRP gezeigt. Beide Router sind jeweils über Ihr Ethernet 1 Interface am LAN angeschlossen. Das Ethernet

Mehr

Sichere E-Mail Kommunikation mit Ihrer Sparkasse

Sichere E-Mail Kommunikation mit Ihrer Sparkasse Ein zentrales Anliegen der Sparkasse Freyung-Grafenau ist die Sicherheit der Bankgeschäfte unserer Kunden. Vor dem Hintergrund zunehmender Wirtschaftskriminalität im Internet und aktueller Anforderungen

Mehr

Benutzerhandbuch. Leitfaden zur Benutzung der Anwendung für sicheren Dateitransfer.

Benutzerhandbuch. Leitfaden zur Benutzung der Anwendung für sicheren Dateitransfer. Benutzerhandbuch Leitfaden zur Benutzung der Anwendung für sicheren Dateitransfer. 1 Startseite Wenn Sie die Anwendung starten, können Sie zwischen zwei Möglichkeiten wählen 1) Sie können eine Datei für

Mehr

ANYWHERE Zugriff von externen Arbeitsplätzen

ANYWHERE Zugriff von externen Arbeitsplätzen ANYWHERE Zugriff von externen Arbeitsplätzen Inhaltsverzeichnis 1 Leistungsbeschreibung... 3 2 Integration Agenda ANYWHERE... 4 3 Highlights... 5 3.1 Sofort einsatzbereit ohne Installationsaufwand... 5

Mehr

Lizenzen auschecken. Was ist zu tun?

Lizenzen auschecken. Was ist zu tun? Use case Lizenzen auschecken Ihr Unternehmen hat eine Netzwerk-Commuterlizenz mit beispielsweise 4 Lizenzen. Am Freitag wollen Sie Ihren Laptop mit nach Hause nehmen, um dort am Wochenende weiter zu arbeiten.

Mehr

So richten Sie Ihr Postfach im Mail-Programm Apple Mail ein:

So richten Sie Ihr Postfach im Mail-Programm Apple Mail ein: Seit der Version 3 von Apple Mail wird ein neuer E-Mail-Account automatisch über eine SSL-verschlüsselte Verbindung angelegt. Daher beschreibt die folgende Anleitung, wie Sie Ihr Postfach mit Apple Mail

Mehr

Beweisbar sichere Verschlüsselung

Beweisbar sichere Verschlüsselung Beweisbar sichere Verschlüsselung ITS-Wahlpflichtvorlesung Dr. Bodo Möller Ruhr-Universität Bochum Horst-Görtz-Institut für IT-Sicherheit Lehrstuhl für Kommunikationssicherheit bmoeller@crypto.rub.de 12

Mehr

Digital Rights Management (DRM) Verfahren, die helfen Rechte an virtuellen Waren durchzusetzen. Public-Key-Kryptographie (2 Termine)

Digital Rights Management (DRM) Verfahren, die helfen Rechte an virtuellen Waren durchzusetzen. Public-Key-Kryptographie (2 Termine) Digital Rights Management (DRM) Verfahren, die helfen Rechte an virtuellen Waren durchzusetzen Vorlesung im Sommersemester 2010 an der Technischen Universität Ilmenau von Privatdozent Dr.-Ing. habil. Jürgen

Mehr

Thunderbird Portable + GPG/Enigmail

Thunderbird Portable + GPG/Enigmail Thunderbird Portable + GPG/Enigmail Bedienungsanleitung für die Programmversion 17.0.2 Kann heruntergeladen werden unter https://we.riseup.net/assets/125110/versions/1/thunderbirdportablegpg17.0.2.zip

Mehr

ICS-Addin. Benutzerhandbuch. Version: 1.0

ICS-Addin. Benutzerhandbuch. Version: 1.0 ICS-Addin Benutzerhandbuch Version: 1.0 SecureGUARD GmbH, 2011 Inhalt: 1. Was ist ICS?... 3 2. ICS-Addin im Dashboard... 3 3. ICS einrichten... 4 4. ICS deaktivieren... 5 5. Adapter-Details am Server speichern...

Mehr

Sichere E-Mail für Rechtsanwälte & Notare

Sichere E-Mail für Rechtsanwälte & Notare Die Technik verwendet die schon vorhandene Technik. Sie als Administrator müssen in der Regel keine neue Software und auch keine zusätzliche Hardware implementieren. Das bedeutet für Sie als Administrator

Mehr

ISA Server 2006 - Exchange RPC over HTTPS mit NTLM-Authentifizierung

ISA Server 2006 - Exchange RPC over HTTPS mit NTLM-Authentifizierung Seite 1 von 24 ISA Server 2006 - Exchange RPC over HTTPS mit NTLM-Authentifizierung Die Informationen in diesem Artikel beziehen sich auf: Microsoft ISA Server 2006 Microsoft Windows Server 2003 SP1 Microsoft

Mehr

Betriebssysteme und Sicherheit Sicherheit. Signaturen, Zertifikate, Sichere E-Mail

Betriebssysteme und Sicherheit Sicherheit. Signaturen, Zertifikate, Sichere E-Mail Betriebssysteme und Sicherheit Sicherheit Signaturen, Zertifikate, Sichere E-Mail Frage Public-Key Verschlüsselung stellt Vertraulichkeit sicher Kann man auch Integrität und Authentizität mit Public-Key

Mehr