Bruce Schneier, Peter Mudge
e-mail: {schneier, mudge} @counterpane.com

Viele Organisationen sind zentralisiert nicht. Die Filialen, die virtuellen Gesellschaften und die den Platz wechselnden Mitarbeiter machen eine Idee der Bildung des gewählten Kanals zu einem beliebigen geforderten Punkt logisch unmöglich. Die Konzeption der virtuellen Netze gewährleistet die Lösung des entstehenden Problems mittels der Tunnelung des vereinigten Netzraumes nach anderen, Zwischen- und nicht ungefährlichen Netzen (zum Beispiel, das Internet), dadurch позвол den entfernten Punkten, lokal zu werden. Die gegebene Lösung fordert die Einlagen auf die Durchführung der abonnierten oder gewählten Linien in einen beliebigen Punkt nicht. Solche Weise manchmal nennen ' den Tunnel '.

Je nach der Lösung von den virtuellen Netzen der Probleme der nicht zentralisierten Wagen ist anderes Problem entstanden. Der Verkehr, der sich in den Grenzen der Gesellschaft früher befand, ist für die neugierigen Augen mit ganz der Welt jetzt geöffnet. Für die Versorgung nicht nur отказоустойчивости, sondern auch der Sicherheit der Informationen muss man die Mechanismen аутентификации und der Chiffrierung verwenden. Daraufhin haben die virtuellen Netzvereinigungen mit криптографической vom Schutz vereinigt, und das Finalprodukt haben die Virtuellen Privaten Netze (VPN) genannt.

Die Sicherheit VPN wird auf der Sicherheit der Protokolle аутентификации und der Chiffrierung gegründet. Wenn die Kryptographie VPN schwach ist, so ist die Stufe des Schutzes höher, als in jedem nicht privaten Netz der Sendung der Informationen auf dem Internet. Da die Gesellschaften hoffen, dass VPN das Perimeter der inneren Sicherheit bis zum entfernten Büro ausdehnen wird, entspricht der Durchbruch des Systems des Schutzes des Tunnels der Vernichtung aller Systeme des Schutzes des inneren Perimeters. Der Durchbruch in VPN bedeutet tatsächlich selb, dass auch den Durchbruch für firewall.

Das Protokoll PPTP (das Tunnelprotokoll des Typs der Punkt-Punkt) war für die Lösung der Aufgabe der Bildung und der Verwaltung VPN über das öffentliche Netz TCP/IP mit der Nutzung des standardmäßigen Protokolles РРР vorbestimmt. Obwohl das Protokoll den Raum für alle möglichen Typen der Chiffrierung und аутентификации reserviert, wird in der Mehrheit der kommerziellen Lebensmittel die Version des gegebenen Protokolles für Windows NT verwendet. Gerade diese Realisierung ist der Analyse im vorliegenden Artikel eben untergezogen.

Мы haben aufgedeckt, dass das Protokoll аутентификации Microsoft mittels des Angriffes nach dem Wörterbuch schwach und verwundbar ist; die Mehrheit der Parolen kann man im Laufe von einigen Stunden öffnen. Wir haben aufgedeckt, dass die Weisen der Chiffrierung mit der Nutzung 40 und 128-Entladungsschlüssel identisch schwach sind und haben die Reihe der unvernünftigen in die Realisierung gelegten Ideen geöffnet, die zulassen andere Angriffe auf die vorliegende Chiffre zu verwirklichen. Wir kann die Vereinigungen durch firewall öffnen, die Regeln der Verhandlungen РРTР verletzend, und können wir verschiedene Angriffe der Absage in der Bedienung darauf durchführen, wer Microsoft PPTP verwendet.

Оставшаяся ist der Teil der Arbeit auf folgende Weise geteilt: Im Paragrafen 2 wird РРТР, wie der Standard des Protokolles, als auch die Realisierung Microsoft betrachtet. Im Paragrafen 3 werden zwei Funktionen хэширования der Parolen in Microsoft PPTP und die Weisen des Angriffes auf ihnen betrachtet. Im Paragrafen 4 wird криптоанализ des Protokolles аутентификации Microsoft, und im Paragrafen 5 - криптоанализ des Protokolles der Chiffrierung Microsoft durchgeführt. Andere Angriffe auf Microsoft РРТР sind im Paragrafen 6 betrachtet. Endlich, im Paragrafen 7 werden einige Schlussfolgerungen.

РРТР - das Protokoll, das zulässt, die Tunnelung der rrr-Vereinigungen nach dem IP-Netz mittels der Bildung VPN zu erfüllen. So kann der entfernte Computer im Netz Х туннелировать der Verkehr auf die Schleuse im Netz Bei und, das Anschließen, mit der inneren IP-Adresse imitieren, zum Netz U.Schljuss bekommt den Verkehr für die innere IP-Adresse und übergibt seinem entfernten Wagen im Netz C.Suschtschestwujuts zwei Hauptweisen der Nutzung РРТР: auf dem Internet und nach den geschalteten Vereinigungen. Настояща ist der Artikel auf der Nutzung РРТР wie VPN beim unmittelbaren Anschließen des Kunden zu das Internet ausgerichtet.

Das Funktionieren РРТР besteht in инкапсулировании der Pakete des virtuellen Netzes in die Pakete РРР, die seinerseits инкапсулируются in die Pakete GRE (Generic Routing Incapsulation), übergeben nach IP vom Kunden zur Schleuse - dem Server РРР und zurück. Zusammen mit dem Kanal инкапсулированных der Daten existiert die verwaltende Sitzung auf Grund von TCP. Die Pakete der verwaltenden Sitzung lassen zu, den Status anzufordern und, die Signalinformationen zwischen dem Kunden und dem Server zu begleiten. Der Kanal der Verwaltung wird vom Kunden auf dem Server auf dem tsr-Hafen 1723 eingeleitet. Meistens ist es der doppelgerichtete Kanal, nach dem der Server die Anfragen auf den Server und umgekehrt schickt.

РРТР behält die konkreten Algorithmen аутентификации und der Protokolle nicht vor; stattdessen gewährleistet er die Grundlage für die Erörterung der konkreten Algorithmen. Die Verhandlungen sind nur РРТР nicht eigen, sie verhalten sich zu den existierenden Varianten der Verhandlungen РРР, die in ССР enthalten sind, СНАР sowohl andere Erweiterungen als auch die Verbesserungen РРР.

2.1 РРТР von Microsoft

Microsoft РРТР ist ein Teil der Wespen Windows NT Server, die gegebene Software kann man umsonst von der Web-Webseite Microsoft bekommen. Das Anschließen verwirklicht sich mit Hilfe des Paneels der Verwaltung und des Redakteurs der Liste. Die vorliegende Realisierung РРТР wird in den kommerziellen Anwendungen VPN, zum Beispiel, Aventail und Freegate breit verwendet gerade deshalb, weil die Wespen Microsoft bildet.

Der Server Microsoft РРТР kann nur für Windows NT existieren, obwohl die Kundensoftware für Windows NT, einiger Versionen Windows und Windows 98 existiert. Die Realisierung Microsoft unterstützt drei Varianten аутентификации:

1. Die Textparole: der Kunde übergibt dem Server die Parole in der offenen Art.
2. Die cheschirowannyj Parole: der Kunde übergibt dem Server хэш der Parole (siehe den Paragrafen 3).
3. Der Aufruf/Antwort: Аутентификация des Servers und des Kunden mit der Nutzung des Protokolles MS-CHAP (dem Aufruf/Antwort), was im Paragrafen 4 beschrieben ist.

Die dritte Variante heißt in der Dokumentation für die Benutzer "Autentifikazi Microsoft", für die Chiffrierung der Pakete РРТР es muss man erlauben. Bei der Auswahl eines jedes zwei anderer Varianten ist die Chiffrierung unerfüllbar. Außerdem wird die Möglichkeit der Chiffrierung (40 oder 128-entladungs-) nur garantiert, falls der Kunde Windows NT verwendet. Einige Kunden Windows 95 können die chiffrierten Sitzungen nicht unterstützen.

In die Wespen Microsoft Windows NT für den Schutz der Parolen werden zwei einseitige chesch-Funktionen verwendet: хэш Lan Manager und хэш Windows NT. Die Funktion хэша Lan Manager war Microsoft für das Betriebssystem IBM OS/2 entwickelt, sie war in Windows for Workgroups integriert und ist in Windows 3.1 teilweise. Die vorliegende Funktion wird in einigen Protokollen аутентификации vor Windows NT verwendet. Хэш Windows NT war speziell für die Wespen Microsoft Windows NT entwickelt. Die Funktion хэша Lan Manager ist auf dem Algorithmus DES gegründet; die Funktion хэша Windows NT ist auf der einseitigen chesch-Funktion MD4 gegründet. Beide diese Funktionen werden in vielen Protokollen аутентификации Windows NT, und nicht nur in РРТР verwendet.

Die Funktion хэша Lan Manager wird auf folgende Weise ausgerechnet:

Die Umwandlung der Parole in der 14-symbolischen Zeile mittels oder отсечки der längeren Parolen, oder der Ergänzung der kurzen Parolen von den Nullelementen.

1. Der Ersatz aller Symbole des unteren Registers auf die Symbole des oberen Registers. Die Zahlen und die speziellen Symbole bleiben ohne Veränderungen.
2. Разбиение der 14-Byte- Zeile auf zwei Siebenbyte- Hälften.
3. Die Nutzung jeder Hälfte der Zeile in der Rolle des Schlüssels DES, die Chiffrierung der fixierten Konstante mit Hilfe jedes Schlüssels, das Erhalten zwei 8-Byte- Zeilen.
4. Die Verschmelzung zwei Zeilen für die Bildung einer 16-Entladungsbedeutung der chesch-Funktion.

Die Wörterbuchangriffe auf die Funktion хэша Lan Manager erreichen den Erfolg aus den folgenden Gründen leicht:

Die Mehrheit der Menschen wählen die leicht erratenen Parolen.

• Alle Symbole werden ins obere Register umgewandelt werden, was und ohne das die kleine Zahl der möglichen Parolen beschränkt.
• Es gibt keine individuelle Anpassung (salt); zwei Benutzer mit den identischen Parolen werden die identischen Bedeutungen der chesch-Funktion immer haben. So kann man im Voraus das Wörterbuch хэшированных der Parolen bilden und, die Suche der unbekannten Parole darin verwirklichen. Bei solchem Herangehen vom Gesichtspunkt der Beziehung die Zeit/Gedächtnis kann die Prüfung der Parole выполнятьс mit Geschwindigkeit der Scheibeneinführung/Schlussfolgerung.
• Zwei Siebenbyte- "Hälften" der Parole хэшируются unabhängig voneinander. So können zwei Hälften von der Methode der groben Auslese unabhängig voneinander ausgewählt werden, und die Komplexität des Angriffes übertritt die Komplexität des Angriffes gegen die Siebenbyteparole nicht. Die Parolen, deren Länge sieben Symbole übertritt, sind nicht stärker, als die Parolen mit der Länge sieben Symbole. Außerdem jene Parolen, deren Länge sieben Symbole sehr einfach nicht übertritt zu erkennen, da die zweite Hälfte хэша eine ein und derselbe fixierte Konstante wird: die Chiffrierung der fixierten Konstante mit Hilfe des Schlüssels aus sieben Nullen.

Die Funktion хэша Windows NT wird auf folgende Weise ausgerechnet:

1. Die Umgestaltung der Parole, der Länge bis zu 14 Symbolen, mit dem Unterscheiden der Register in Unicode.
2. Хэширование der Parole mit Hilfe MD4, das Erhalten der 16-symbolischen Bedeutung der chesch-Funktion.

Хэш Windows NT verfügt über den Vorteil im Vergleich zur Funktion хэша Lan Manager - es werden die Register unterschieden, die Parolen können als 14 Symbole länger sein, хэширование der Parole insgesamt anstelle разбиения es in die kleinen Teile - obwohl fehlt die Individualität nach wie vor. So werden die Menschen, die die identischen Parolen haben, identisch хэшированные die Parolen Windows NT immer haben. Der Vergleich der Datei хэшированных der Parolen mit dem im Voraus berechneten Wörterbuch хэшированных der Parolen kann ein sehr wirksamer Angriff sein.

Außerdem ist das Problem der Realisierung wesentlich ernster erleichtert das Öffnen der Parolen. Sogar obwohl хэш Lan Manager nach den Gründen der Vereinbarkeit in den vorhergehenden Versionen aufgenommen war, es ist in den Netzen Windows NT nicht erforderlich, beide Bedeutungen der chesch-Funktionen werden zusammen immer übergeben. Also kann man die grobe Auslese der Parole mit Hilfe der schwächeren chesch-Funktion Lan Manager erfüllen und dann, die Prüfung unter Berücksichtigung des Registers für die Auslese der Bedeutung der chesch-Funktion Windows NT erfüllen^.

РРР enthält verschiedene Weisen der Bearbeitung аутентификации. Eine der Weisen ist das Protokoll аутентификации der Aufruf-Händedruck (СНАР). Die Realisierung PPP СНАР von der Gesellschaft Microsoft (MS-CHAP) stimmt mit der Methode аутентификации, verwendet für аутентификации der Kunden in den Windows-Netzen fast überein.

MS-CHAP Funktioniert auf folgende Weise:

1. Der Kunde fordert den Aufruf des Netznamens an.
2. Der Server gibt der zufällige Achtbyteaufruf zurück.
3. Der Kunde rechnet die chesch-Funktion Lan Manager aus, ergänzt fünf Nullen für die Bildung der 21-Byte- Zeile und teilt die Zeile in drei Siebenbyte- Schlüssel. Jeder Schlüssel wird für шифрации des Aufrufs verwendet, was zum Erscheinen der chiffrierten 24-Entladungsbedeutung bringt. Es kehrt dem Server wie die Antwort zurück. Der Kunde erfüllt selb mit der chesch-Funktion Windows NT.
4. Der Server sucht die Bedeutung der chesch-Funktion in der Datenbank, chiffriert die Anfrage mit Hilfe der chesch-Funktion und vergleicht es mit den bekommenen chiffrierten Bedeutungen. Wenn sie übereinstimmen, geht аутентификация zu Ende.
   Der Server kann den Vergleich nach der chesch-Funktion Windows NT oder nach der chesch-Funktion Lan Manager erfüllen; die Ergebnisse sollen übereinstimmen. Хэш, verwendet vom Server, hängt von der konkreten Fahne im Paket ab. Wenn die Fahne bestimmt ist, so erfüllt der Server die Prüfung mit Hilfe der chesch-Funktion Windows NT; andernfalls wird die Prüfung mit Hilfe der chesch-Funktion Lan Manager erfüllt.

Das Protokoll des Aufrufs/Antwort ist standardmäßig; die Nutzung des zufälligen Aufrufs des Namens macht unmöglich die Wörterbuchangriffe auf MS-CHAP und die Datei der aufgezeichneten chesch-Funktionen von den Parolen. Gleichzeitig, da sogar in Windows die NT-Netze beide Bedeutungen der chesch-Funktion verwendet werden, man kann in jedem Fall die schwächere chesch-Funktion Lan Manager angreifen. Da die Antwort des Kunden in drei Teile müde ist, und wird jeder Teil unabhängig von anderen chiffriert, kann man das Protokoll MS-CHAP angreifen.

Die Letzten acht Byte der chesch-Funktion Lan Manager stellen die Konstante dar, falls die Länge der Parole sieben Symbole nicht übertritt. Es ist treu, ungeachtet des zufälligen Aufrufs. Also werden die Letzten acht Byte der Antwort des Kunden den Aufruf darstellen, der mit Hilfe der vorliegenden Konstante chiffriert ist. Es ist leicht, zu prüfen, ob die Länge der Parole sieben Symbole übertritt., Nachdem angreifend die Bedeutung der chesch-Funktion Lan Manager findet, kann er diese Informationen für die Wiederherstellung der chesch-Funktion Windows NT verwenden.

Der Angriff kann auf Kosten von der aktiven Nutzung der vorläufigen Berechnungen und der sorgfältigen Forschung der Schwächen der chesch-Funktion Lan Manager und des Protokolles MS-CHAP wesentlich beschleunigt sein. Weiter werden die Einzelheiten des optimisierten Angriffes gebracht:

Р₀-Р₁₃ - Die Bytes der Parole. Н₀-Н₁₅ - die Bytes der chesch-Funktion Lan Manager, die in den 21-Byte- Schlüssel К₀-К₂₀ umgewandelt werden wird. S - die fixierte Konstante, die in den chesch-Funktionen Lan Manager verwendet wird. Der Aufruf Mit und die 24-Byte- Antwort R_o-R₂3. Der Übeltäter kann C und R wissen und will Р finden

1. Probieren Sie alles Mögliche der Kombination К₁₄, К₁₅. Die richtige Bedeutung hebt sich heraus, wenn sich Mit in R₁₆ verwandelt..., R₂₃ mit dem Schlüssel К₁₄, К₁₅, 0,0,0,0,0. Auf es gehen ungefähr 2¹⁵ Operationen weg.
2. Probieren Sie die wahrscheinlichen Bedeutungen Р₇..., Р₁₃. Die falschen Bedeutungen kann man schnell mittels der Chiffrierung S und der Prüfung des Zusammenfallens zwei letzte Byte der bekommenen Bedeutung mit К₁₄ und К₁₅ zurückwerfen. (So bleibt nur eine Variante von jeden 2¹⁶). Jede bleibende Variante Р₇..., Р₁₃ gewährt die Bedeutung-Kandidat für К₈..., К₁₃. Um die Bedeutung-Kandidat zu prüfen, prüfen Sie alles Mögliche der Bedeutung К₇, um zu sehen, ob es solches gibt, bei dem Mit in R₈ chiffriert wird..., R₁₅ bei der Bedeutung-Kandidaten К₈..., К₁₅. Wenn es solches К₇, so die Vermutung für Р₇ gibt..., Р₁₃ ist fast sicher richtig. Wenn gibt es, so muss man andere Bedeutung für Р₇ wählen..., Р₁₃. Wenn N der wahrscheinlichen Varianten Р₇ existieren..., Р₁₃, so kann man die Auslese der richtigen Bedeutung für N prüfungs- шифрований durchführen.
   Werden beachten, dass es da im Protokoll keine individuelle Abstimmung gibt, dieser Angriff kann mit Hilfe des Ersatzes die Zeit/Gedächtnis wesentlich beschleunigt sein. Wenn N im Voraus ausgerechnet prüfungs- шифрований, so die Wiederherstellung der richtigen Bedeutung Р₇ ist..., Р₁₃ wird N/2¹⁶ die Operationen fordern.
3. Nach dem Verbleib Р₇..., Р₁₃, die Wiederherstellung Р₀..., Р₆ fordert m der Versuche, wo m - die Zahl der wahrscheinlichen Bedeutungen Р₀..., Р₆. Wieder es, da keine individuelle Abstimmung gibt, der Angriff kann für N/2⁸ der Versuche bei m die vorläufig ausgerechneten Bedeutungen erfüllt sein.

Кроме jenen, lässt das vorliegende Protokoll zu, аутентификацию nur den Kunden zu erfüllen. Angreifend, erfüllend die Auswechselung der Vereinigung, kann unter den Server trivial maskiert werden. Wenn die Chiffrierung erlaubt wird, kann angreifend nicht schicken und, übernehmen die Mitteilungen (wird bis die Chiffre aufbrechen), die alte Bedeutung des Aufrufs er jedoch verwendend kann zwei Tagungen des Textes, die vom einem Schlüssel chiffriert sind (bekommen siehe die Angriffe weiter).

5.1 Beschreibung МРРЕ

Das Protokoll der Chiffrierung in одноранговых die Netze (МРРЕ) gewährleistet die Methodologie für die Chiffrierung der Pakete РРТР. Er vermutet die Existenz des geheimen Schlüssels, beide Teilnehmer bekannter Vereinigung, und verwendet die Fliesschiffre RC4 mit 40 oder dem 128-Entladungsschlüssel. Solche Methode der Anlage der Nutzung МРРЕ ist eine der Funktionen des Protokolles der Verwaltung der Kompression РРР (ССР) und ist in der Anlage S.Posles der Anlage des Regimes der Arbeit beschrieben fängt die Sitzung РРР nach der Sendung der Pakete der chiffrierten Daten an. Es ist wichtig, zu bemerken, dass nur jene Pakete РРР chiffriert werden, deren Nummern der Protokolle im Umfang 0x0021-0x00fa liegen. Alle übrigen Pakete werden ohne Chiffrierung übergeben, selbst wenn die Chiffrierung erlaubt wird. Die Typen der Pakete, deren Chiffrierung sich verwirklicht/nicht verwirklicht sich, werden vom Dokument RFC 1700 reglementiert. Für beliebige Pakete wird аутентификация nicht gewährleistet.

In МРРЕ klärt sich der 40-Bit- Schlüssel RC4 auf folgende Weise:

1. Die Erzeugung des bestimmenden 64-Bit- Schlüssels aus der chesch-Funktion Lan Manager der Parole des Benutzers (bekannt dem Benutzer und dem Server) mit Hilfe SHA.
2. Die Anlage das ältere 24 Bit des Schlüssels in die Bedeutung 0xD1269E.

Der 128-Bit- Schlüssel RC4 klärt sich auf folgende Weise:

1. Die Vereinigung хэша Windows NT und der 64-Bit- zufälligen Bedeutung, die vom Server bei der Arbeit laut des Protokolles MS-CHAP ausgestellt ist. Die gegebene Zahl wird dem Kunden laut des Protokolles des Austausches geschickt, weil es sowohl dem Kunden, als auch dem Server bekannt ist.
2. Die Erzeugung des bestimmenden 128-Bit- Schlüssels aus den Ergebnissen der vorhergehenden Etappe mit Hilfe SHA.

Der resultirujuschtschi Schlüssel wird für den Initialization RC4 in der gewöhnlichen Weise, und dann für die Chiffrierung das Datenbyte verwendet. Nach jeden 256 Pakete - МРРЕ unterstützt den Zähler, in dem die Zahl der Pakete fixiert wird - es wird der neue Schlüssel RC4 nach den einhaltenden Regeln generiert:

1. Die Erzeugung des bestimmenden Schlüssels - 64-Bit- für die 40-Bit- Chiffrierung und 128-Bit- für die 128-Bit- Chiffrierung - den Weg хэширования des vorhergehenden Schlüssels und des Ausgangsschlüssels mit Hilfe SHA.
2. Wenn der 40-Bit- Schlüssel, so die Anlage das ältere 24 Bit des Schlüssels in die Bedeutung 0xD1269E gefordert wird.

Die Länge des typischen Paketes РРТР bildet 200 Byte, einschließlich den Titel.

Beim Verlust der Synchronisation geschieht реинициализация RC4 mit der Nutzung des laufenden Schlüssels. Es existiert auch die Möglichkeit der Erneuerung des Schlüssels RC4 nach jedem Paket; diese Möglichkeit verringert die Effektivität der Chiffrierung ungefähr halb, da auf die Ausführung der planmässigen Veränderungen des Schlüssels RC4 die Zeit gefordert wird.

5.2 Wiederherstellung des Schlüssels

In МРРЕ übertritt die Stufe des Schutzes des Schlüssels die Stufe des Schutzes der Parole nicht. Der große Teil der Parolen hat wesentlich weniger als 40 Bit der Sicherheit und werden mit Hilfe der Wörterbuchangriffe geöffnet. Die chesch-Funktion Lan Manager noch боле ist verwundbar: unter Berücksichtigung der maximalen Länge der Portion, des begrenzten Alphabetes und der Abwesenheit der Symbole des unteren Registers, es ist unmöglich, den 128-Bit- Schlüssel zu erzeugen, selbst wenn der Benutzer es machen will. In der Dokumentation nach МРРЕ wird die Fahne für die Berechnung des 40-Bit- Schlüssels RC4 aufgrund der chesch-Funktion Windows NT beschrieben, und nicht Lan Manager, aber ist diese Funktion noch nicht realisiert. Es gibt keine Weisen der Berechnung des 128-Bit- Schlüssels RC4 aufgrund der chesch-Funktion Windows NT, obwohl solche Variante sicherer (obwohl wesentlich weniger sicher, als den 128-Bit- zufälligen Schlüssel wäre.)

Auf jeden Fall, die allgemeine Stufe des Schutzes bildet nicht 40 oder 128 Bit, und die Zahl das Bit der Entropie der Parole. Aufgrund der experimentalen Daten ist es bekommen, dass dem Englische die Entropie die 1,3 Bits auf das Symbol eigen ist. Die Veränderungen des Registers, die Zahlen und die speziellen Symbole erhöhen diese Bedeutung wesentlich. Ein beliebiger Angriff, der das Wörterbuch der schwachen Parolen verwendet, kann fähig sein, chiffriert МРРРЕ den Verkehr zu lesen. Außerdem erleichtern die stilisierten Titel im Paket РРР die Gebühr der bekannten Texte und der Basis für die Prüfung des erratenen Schlüssels.

Der 40-Bit- Algorithmus RC4 ist ernster уязвимостям unterworfen. Da die individuelle Abstimmung nicht vorgesehen ist, kann angreifend das Wörterbuch der chiffrierten Titel РРР vorbereiten, und dann ist es schnell, den vorliegenden chiffrierten Text im Wörterbuch zu finden. Bei der Suche der Stellen in den Paketen МРРЕ, wo der nicht chiffrierte Text enthalten sein kann, angreifend kann eine Menge der Beziehungen nach SMB und NetBIOS ausnutzen, die bei den standardmäßigen Vereinigungen Microsoft geschehen.

Außerdem, der selbe 40-Bit- Schlüssel RC4 wird jedees Mal generiert, wenn der Benutzer das Protokoll РРТР initialisiert. Da RC4 die Weise der Chiffrierung mit der Rückkopplung nach dem Ausgang darstellt, so ist es einfach, die Chiffre für zwei Sitzungen aufzubrechen. Die ernste Verwundbarkeit wird in большей die Teile der frischen Spezifikationen МРРЕ bemerkt, obwohl sie aus der vorhergehenden Version verlorengegangen ist. In einer Version der Dokumentation Microsoft wird es angewiesen, dass ein und derselbe Schlüssel wie in gerade verwendet wird, als auch in entgegengesetzter Richtung, dass garantiert, dass für die Chiffrierung zwei verschiedener Texte ein und derselbe Strom der Schlüssel verwendet wird.

128-Bit- RC4 verwendet im Laufe der Erzeugung der Schlüssel die 64-Bit- Zufallsgröße. Solches Herangehen macht unpraktisch den Wörterbuchangriff. Nach wie vor, die Methode der groben Auslese der Parole ist wirksamer, als die Methode der groben Auslese des Raumes der Schlüssel. Die Zufallszahl bedeutet auch, dass für zwei Tagungen mit einer Parole verschiedene 128-Bit- Schlüssel RC4 verwendet sein werden, obwohl für die Chiffrierung des Textes in beiden Richtungen ein und derselbe Schlüssel verwendet sein wird.

5.3 Angriffe der Umdrehung der Bits

RC4 - Wird die Weise der Fliesschiffrierung mit der Rückkopplung nach dem Ausgang, аутентификация des Stroms des chiffrierten Textes dabei nicht gewährleistet. Da es in МРРРЕ anderer Weise аутентификации nicht vorgesehen ist, kann angreifend die Bedeutungen das Bit in der Chiffre unmerklich tauschen. Wenn das Protokoll des unteren Niveaus gegen die Veränderung der Bedeutung konkret das Bit - die Lösung/Verbot irgendwelcher Funktionen, die Auswahl der Varianten empfindlich ist, kann die Ableitung der Parameter - dieser Angriff genug wirksam sein. Werden beachten, für die Durchführung dieses Angriffes angreifend muss man den Schlüssel der Chiffrierung oder die Parole des Kunden nicht wissen. Natürlich, solche Angriffe können sich oder verhindert werden von den Protokollen des oberen Niveaus herausstellen.

5.4. Der Angriff mittels ресинхронизации

Wenn sich im Laufe der Sendung das Paket verliert, oder es kommt das Paket mit der falschen Nummer im Titel МРРЕ, so geschieht ресинхронизация des Schlüssels. Die Seite, die das falsche Paket übernahm, schickt dem Absender die Anfrage auf ресинхронизацию. Nach der Annahme der gegebenen Anfrage, der Absender реинициализирует die Tabellen RC4 stellt das Bit eben fest ist (flushed) im Titel МРРЕ "gestürzt". Wenn das System im Paket das bestimmte Bit aufdeckt ist "gestürzt", stellt sie реинициализирует die Tabellen RC4 und den Zähler der Pakete entsprechend der bekommenen Bedeutung fest.

So entsteht das Problem, wenn der Angreifende oder die Anfragen auf ресинхронизацию reichen kann, oder, die Pakete МРРЕ mit den falschen Bedeutungen des Zählers der Pakete einwerfen. Wenn es zu erfüllen ist vor dem Austausch vom 256. Pakt ständig, wenn der Wechsel сеансового des Schlüssels geschieht, so kann der Angreifende des Erfolges erzielen - wird сеансовый der Schlüssel nicht geändert sein.

Obwohl die Angriffe auf die Protokolle MS-CHAP und МРРЕ zur vollen Negation der Nützlichkeit und der Sicherheit MS PPTP bringen, muss man über einige interessante Angriffe erwähnen.

6.1 Passives Monitoring

Die ergreifende Zahl der Informationen kann man bekommen, wenn es einfach ist, den Verkehr der Sitzung РРТР, die nach den Netzen übergeben werden zu beobachten. Solche Informationen sind für die Analyse des Verkehres wertlos, sie ist nötig es zu schützen. Nichtsdestoweniger, der Server gibt allen Interessierten solche Nachrichten, wie das Maximum der zugänglichen Kanäle aus. Diese Informationen kann man für die Anlage des entsprechenden Umfanges des Servers РРТР und der Kontrolle seiner Belastung verwenden. Wenn angreifend die Pakete PPTP_START_SESSION_REQUEST regelmäßig übergibt, so kann er die Bildung der neuen Vereinigungen und die Schließung der existierenden Vereinigungen beobachten. Der auf diese Weise Angreifende kann die Informationen über das System und die Schablonen ihrer Nutzung einziehen, dabei muss er Reihe nicht sein.

Mittels der Anlage der standardmäßigen Mittel der Durchsicht und des Entzifferns der öffentlichen Verbindungsleitungen von den Servern Microsoft PPTP waren die nächsten Informationen bekommen:

• Die IP-Adresse Kunden
• Die IP-Adresse Servers
• Die Zahl der virtuellen auf dem Server zugänglichen Kanäle RRTR
• Die Version RAS des Kunden
• Der Name des Kunden NetBIOS
• Die Identifizierung des Produzenten des Kunden
• Die Identifizierung des Produzenten des Servers
• Die IP-Adresse Kunden im inneren virtuellen Tunnel
• Inner des DNS-Servers, bedienend den Kunden
• Der Name des Benutzers auf dem Kunden
• Es ist genug Informationen für das Erhalten der Bedeutungen der chesch-Funktionen der Parolen der Benutzer
• Es ist genug Informationen für das Erhalten der Anfangsbedeutung МРРЕ
• Die laufende Bedeutung des chiffrierten Paketes für den Kunden vor реинициализацией RC4
• Die laufende Bedeutung des chiffrierten Paketes für den Server vor реинициализацией RC4

Auf jeden Fall, wenn der Kanal der Verbindung auch der Benutzer chiffriert wird vermutet einiges Niveau der Vertraulichkeit, die obengenannten Informationen sollen so leicht nicht zugänglich sein. Für Microsoft PPTP gibt es keine leichte Weise, diese Informationen zu chiffrieren, da die Ausfließen außer dem Kanal geschehen, der МРРЕ kontrolliert wird. In einigen Fällen, diese Pakete stellen die Konfigurations- und Einstelpakete für die Chiffrierung im Rahmen МРРЕ dar, und sie sollen передаватьс bis zum Anfang der Chiffrierung. Eine einzige Lösung ist die Chiffrierung des Kanals der Verwaltung oder die heftige Verkleinerung der Zahl der nach seiner übergebenen Informationen.

6.2 Abfangen der Verhandlungen РРР

Die Pakete der Verhandlungen РРР werden bis zum Anfang der Chiffrierung und nach seinem Abschluss übergeben. Da sich die Methode ресинхронизации der Schlüssel mit der Nutzung der Pakete RRR ССР verwirklicht, können diese Kanäle der Verbindung auf dieselbe Weise nicht chiffriert werden. Wir werden ergänzen, dass ein reale аутентификация der gegebenen Pakete nicht erfüllt wird. Die Etappe der Konfiguration ist für den Angriff vollständig geöffnet.

Die Auswechselung des Konfigurationspaketes, das den DNS-Server beschreibt, lässt zu, das ganze System der Erkennung der Namen auf den falschen Server der Namen zu richten.

Genauso, die Auswechselung des Paketes, das die innere Tunnel-IP-Adresse enthält, lässt zu, файрволы, verwirklichend die Filtrierung der Pakete nach den Regeln umzugehen, da der Kunde an die äusserlichen Wagen aus dem inneren geschützten Netz angeschlossen werden wird.

6.3 Kanäl der Verwaltung und die Absage in der Bedienung auf dem Server

Im vorliegenden Artikel dem Kanal der Verwaltung РРТР ist der nicht allzu große Teil gewidmet. Teilweise es, weil unverständlich ist, warum existiert dieser Kanal. Aller, was mit Hilfe dieses zusätzlichen Kanals realisiert ist, man kann nach den Kanälen RRR verwirklichen oder, die ungenutzten Fragmente des Titels GRE einsetzen.

Anderer Grund war die Realisierung Microsoft des Kanals der Verwaltung. Wir haben schnell aufgedeckt, dass es einfach ist, die Arbeitsfähigkeit des Wagens Windows NT mit dem Server РРТР zu verletzen, manchmal brachte es zum Erscheinen "des blauen Bildschirmes". In Wirklichkeit, es ist schwierig, die Prüfung des Kanals der Verwaltung nicht zu verletzen die Arbeit des Servers РРТР durchzuführen. Es ist so schwierig, dass der große Teil der Angriffe, предпринимавшихс für das Studium der theoretischen Probleme der Sicherheit des Kanals der Verwaltung, zum Verstoß der Arbeit des Servers früher als die Angriffe brachte konnten ansprechen. Es ist der kleine Teil Prüfungen, die zum Verstoß der Arbeit Windows NT Server mit bestimmten Service Pack 3 brachten weiter beschrieben:

• Der Zyklus nach den Paketen PPTP_CLEAR_CALL_REQUEST, um den 16-Entladungsraum der Bezeichner des Aufrufs zu gehen.
• Die Übergebühr aller möglichen und unmöglichen Bedeutungen, die im Feld der Typ des Paketes des Titels des Paketes РРТР enthalten sein können.
• Die Sendung der unzulässigen Bedeutungen im Titel des Paketes der Verwaltung РРТР.

Alle obengenannten Pakete können sich auf den Server РРТР wegen файрвола, ohne jede аутентификации begeben. Es wird angenommen, dass es keine Konfiguration файрвола, zulassend gibt, РРТР auf den Server РРТР von bestimmten IP-Adressen oder den Netzen zu übergeben. Jedoch wenn die Benutzer eine Möglichkeit haben, an den Server РРТР aus einem beliebigen Punkt der Welt zu behandeln, so soll angreifend die Möglichkeit auch haben, die Anfrage aus einem beliebigen Punkt der Welt zu schicken.

6.4. Die potentiellen Ausfließen der Informationen auf dem Kunden.

Der Kunde Windows 95 erfüllt die geforderte Reinigung der Puffer nicht, und deshalb wird das Ausfließen der Informationen in den Mitteilungen des Protokolles zugelassen. Obwohl es in der Dokumentation РРТР gesagt ist, dass im Paket PPTP_START_SESSION_REQUEST die Symbole nach dem Namen des Computers und des Produzenten in 0х00 gestürzt sein sollen, macht Windows 95 es nicht.

080: 0000 6c6f 6361 6c00 0000 3e1e 02c1 0000. local...>.....

096: 0000 85c4 03c1 acd9 3fc1 121e 02c1 2e00........?.......

112: 0000 2e00 0000 9c1b 02c1 0000 0000 0000................

128: 0000 88ed 3ac1 2026 02c1 1049 05c1 0b00....:. &...I....

144: 0000 3978 00c0 280e 3dc1 9c1b 02c1 041e. 9x. (. =.......

160: 02c1 0e00 0000 121e 02c1 2e00 0000 2e00................

176: 0000 3dad 06c1 74ed 3ac1 1c53 05c1 9c1b. =... t.:. S....

192: 02c1 041e 02c1 0e00 0000 121e 02c1 2e00................

208: 0000.

Höher sind die Symbole gezeigt, die nach dem Namen des Computers und der Zeile des Produzenten enthalten sind. In den Bytes 82-86 ist der Name des Computers enthalten, der sich für den Kunden Windows 95 "local" immer gleichstellt. Das Byte 113 - jene Stelle, wo содержатьс die Zeile des Produzenten soll. Bei der Durchsicht des ähnlichen Paketes Windows NT ist es aufgedeckt, dass alle Symbole des "Mülls" in 0х00 gestürzt sind.

Существует die offensichtliche Möglichkeit des Ausfließens der Informationen je danach, wie auch wo verwendet werden und werden die Strukturen der Daten und aufgestellt was auf dem Kundensystem geschieht. Für die Einschätzung des vorliegenden Ausfließens der Informationen muss man die weitere Analyse des Kodes Windows 95 durchführen.

Die Realisierung РРТР von Microsoft ist vom Gesichtspunkt der Realisierung verwundbar, und verfügt über die ernsten Mängel vom Gesichtspunkt des Protokolles. Das Protokoll аутентификации hat bekannt der Verwundbarkeit, auf die nicht nur hier, sondern auch in den Gruppen, zum Beispiel, L0pht bezeichnet wurde. Die Chiffrierung ist falsch erfüllt, in der vorliegenden Realisierung wird die Fliesschiffre mit der Rückkopplung nach dem Ausgang verwendet, obwohl блоковый die Chiffre "die Chiffre-Blockkette" (CBC) passender wäre. Um schwach аутентификацию mit der schlechten Chiffrierung Microsoft zu verbinden hat den Schlüssel der Chiffrierung wie die Funktion von der Parole des Benutzers anstelle der Nutzung des starken Algorithmus des Austausches von den Schlüsseln als Diffi-Chellmana oder ЕКЕ aufgegeben. Endlich, der Kanal der Verwaltung nicht аутентифицируется ist nicht stark geschützt.

Wir haben viel Zeit auf das Studium der Mechanismen der Versorgung der lokalen IP-Adressen Kunden und nicht ausgegeben, wie Microsoft versuchte und ob er die Verwundbarkeit der Vorstellung des Kunden mit zwei Adressen berücksichtigen konnte. Nichtsdestoweniger, wir haben die Probleme mit den nicht standardmässigen Masken подсети und dem inneren Verkehr des Tunnels, der von РРТР den Server abgesandt ist aufgedeckt. Die Hersteller, seien Sie aufmerksam!

Endlich, man will betonen, dass криптоанализ das Protokoll РРТР (?), aber nur die Realisierung des Protokolles von Microsoft nicht in Zweifel stellte. Obwohl Microsoft die eigenen Erweiterungen verwendet (fordert MS-CHAP, МРРЕ, МРРС) in РРР die Sektionen РРТР, der Standard РРТР es nicht. Die Produzenten können die Erweiterungen Microsoft in die Lebensmittel nach den Gründen der Vereinbarkeit aufnehmen, aber sie sind ограничиватьс von ihrer Nutzung nicht verpflichtet und wahrscheinlich realisieren die sichereren Lösungen. Natürlich, die neuen Erweiterungen für die korrekte Arbeit sollen wie vom Kunden, als auch dem Server unterstützt werden.

¹В den Lauf der Experimente hat es sich herausgestellt, dass einige Kunden Windows 95 аутентификацию Microsoft unterstützen, und es gibt einige - nicht. Wir konnten den Unterschied nicht bewerten oder, die Weisen, zulassend bestimmen, zu verstehen, ob das vorliegende System Windows 95 аутентификацию Microsoft unterstützt. Wenn das Protokoll nicht unterstützt wird, so ist der Punkt im Dialogfenster unzugänglich. Diese Beschränkung entspricht der Erklärung Microsoft, dass Windows 95 die Sicherheit nicht gewährleistet, und dass jene Benutzer, denen sie nötig ist, auf NT übergehen sollen. Nichtsdestoweniger, Microsoft erklärte, dass Windows 95 хэш Windows NT nicht bearbeitet, und verwendet хэш Lan Manager. Jedoch übergeben die Kunden Windows 95 beide chesch-Funktionen. Aus unserer Analyse des Kodes Windows 95 ist unklar, warum darf man nicht die Chiffrierung in den Kunden Windows 95 realisieren.

²В die Dokumentationen Microsoft ist es gesagt, dass die Länge der Parolen Windows NT 128 Symbole erreichen kann, und die chesch-Funktion Windows NT übernimmt die Parolen solcher Länge. Jedoch beschränkt der Dispatcher der Benutzer die Länge der Parolen bis zu 14 Symbolen. In der Dokumentation MS-СНАР wird diese Beschränkung auch erwähnt, die im Verlauf der Experimente bestätigt wurde.

³ das Mittel Bekannte Hacker, L0pthcrack, automatisiert der Prozess der Auslese der Parole nach seiner chesch-Bedeutung. Auf Pentium Pro 200, L0phtcrack 2.0 kann die Datei mit 200 Parolen in einer Minute mit der Nutzung 8 мегабaйтного des Wörterbuches der Parolen prüfen.

⁴ Wir untersuchten weder den Generator der Pseudozufallszahlen, noch seiner криптографическую die Standhaftigkeit.

[Ave98] Aventail Corp., 1998. http://www.aventail.com.

[BV98] L. Blunk and J. Vollbrecht, ` ` PPP Extensible Authentication Protocol (EAP), "Network Working Group, RFC 2284, Mar 1998. ftp://ftp.isi.edu/in-notes/rfc2284.txt.

[CK78] T.M. Cover and R.C. King, ` ` A Convergent Gambling Estimate of Entropy, "IEEE Transactions on Information Theory V. EDV-24, n. 4, Jul 1978, pp. 413 - 421.

[Fre98] FreeGate Corp., 1998. http://www.freegate.com.

[HLFT94] S. Hanks, T. Li, D. Farinacci, and P. Traina, ` ` Generic Routing Encapsulation (GRE), "Network Working Group, RFC 1701, Oct. 1994. ftp://ftp.isi.edu/in-notes/rfc1701.txt.

[Hob97] Hobbit, ` ` CIFS: Common Insecurities Fail Scrutiny, "Avian Research, Jan 1997.

[HPV+97] K. Hamzeh, G.S. Pall, W. Verthein, J. Taarud, and W.A. Little, ` ` Point-to-Point Tunneling Protocol, "Internet Draft, IETF, Jul 1997.

[KSWH98] J. Kelsey, B. Schneier, D. Wagner, and C. Hall, ` ` Cryptanalytic Attacks on Pseudorandom Number Generators, "Fast Software Encryption: 5th International Workshop, Springer-Verlag, 1998, pp. 168-188

[Kle90] D.V. Klein, ` ` Foiling the Cracker: A Security of, and Implications to, Password Security, "Proceedings of the USENIX UNIX Security Workshop, Aug 1990, pp. 5 - 14.

[Kli98] S. Klinger, ` ` Microsoft PPTP and RRAS for Windows NT Server 4.0, "LAN Times, Feb??, 1998.

[L97a] L0pht Heavy Industries Inc, L0phtcrack, 1997.

[L97b] L0pht Heavy Industries Inc, ` ` A L0phtCrack Technical Rant, "Jul 1997. http://www.l0pht.com/l0phtcrack/rant.php.

[LS92] B. Lloyd and W. Simpson, ` ` PPP Authentication Protocols, "Network Working Group, RFC 1334, Oct 1992. ftp://ftp.isi.edu/in-notes/rfc1334.txt.

[Mey96] G. Meyer, ` ` The PPP Encryption Control Protocol (ECP), "Network Working Group, RFC 1968, Jun 1996. ftp://ftp.isi.edu/in-notes/rfc1968.txt.

[Mic96a] Microsoft Corpotation, Advanced Windows NT Concepts, New Riders Publishing, 1996. Relevent chapter at http://www.microsoft.com/communications/nrpptp.html.

[Mic96b] Microsoft Corporation, ` ` Pont-to-Point Tunneling Protocol (PPTP) Frequently Asked Questions, "Jul 1996.

[Mic97] Microsoft Corporation, ` ` Response to Security Issues Raised by the L0phtcrack Tool, "Apr 1997.

[Mic98] Microsoft Corporation, ` ` Clarification on the L0phtcrack 2.0 Tool. "Mar 1998.

[MB97] P. Mudge and Y. Benjamin, ` ` Deja Vu All Over Again, "Byte, Nov 1997.

http://www.byte.com/art/9711/sec6/art3.html.

[NBS77] National Bureau of Standards, NBS FIPS PUB 46, ` ` Data Encryption Standard, "National Bureau of Standards, U.S. Department of Commerce, Jan 1977.

[NIST93] National Institute of Standards and Technology, ` ` Secure Hash Standard, "U.S. Department of Commerce, May 93.

[Pal96a] G.S. Pall, ` ` Microsoft Point-to-Point Compression (MPPC) Protocol, "Network Working Group Internet Draft, Jul 1996.

[Pal96b] G.S. Pall, ` ` Microsoft Point-to-Point Encryption (MPPE) Protocol, "Network Working Group Internet Draft, Jul 1996.

[PZ98] G.S. Pall and G. Zorn, ` ` Microsoft Point-to-Point Encryption (MPPE) Protocol, "Network Working Group, Internet Draft, IETF, Mar 1998.

[Ran96] D. Rand, ` ` The PPP Compression Control Protocol (CCP), "Network Working Group, RFC 1962, Jun 1996. ftp://ftp.isi.edu/in-notes/rfc1962.txt.

[RP94] J. Reynolds and J. Postel, ` ` Assigned Numbers, "Networking Group, Std 2, RFC 1700, Oct 1994. ftp://ftp.isi.edu/in-notes/rfc1700.txt.

[Riv91] R.L. Rivest, ` ` The MD4 Message Digest Algorithm, "Advances in Cryptology - - CRYPTO ' 90 Proceedings, Springer-Verlag, 1991, pp. 303 - 311.

[Sch96] B. Schneier Applied Cryptography, 2nd Edition, John Wiley UND Sons, 1996.

[Sim94] W. Simpson, ` ` The Point-to-Point Protocol (PPP), "Network Working Group, STD 51, RFC 1661, Jul 1994. ftp://ftp.isi.edu/in-notes/rfc1661.txt.

[Sim96] W. Simpson, ` ` PPP Challenge Handshake Authentication Protocol (CHAP) "Network Working Group, RFC 1334, Aug 1996. ftp://ftp.isi.edu/in-notes/rfc1994.txt.

[ZC98] G. Zorn and S. Cobb, ` ` Microsoft PPP CHAP Extensions, "Network Working Group Internet Draft, Mar 1998.