Crypto-Gram 15. Maerz 2002

Crypto-Gram Newsletter 15. März 2002

von Bruce Schneier
Gründer und CTO
Counterpane Internet Security, Inc.
schneier@counterpane.com
<http://www.counterpane.com/>

Ein kostenloser monatlicher Newsletter mit Zusammenfassungen, Analysen, Einsichten und Kommentaren über Computersicherheit und Kryptographie.

Ältere Ausgaben und die Möglichkeit des Abonnements stehen hier zur Verfügung:
<http://www.schneier.com/crypto-gram.html>

Deutsche Übersetzung von Holger Hasselbach, galad.com
mit freundlicher Erlaubnis der Counterpane Internet Security, Inc.
h.hasselbach@galad.com
<http://www.galad.com/>

Dies ist keine vollständige Übersetzung des Newsletters. Nicht übersetzte Teile enthalten einen Link auf das Original.
Stand: 21.03.2002

Alle Übersetzungen stehen hier zur Verfügung:
<http://archiv.galad.com/cg/cg.htm>

In dieser Ausgabe:

SNMP-Verwundbarkeiten
IETF-Dokument zur "Verantwortungsvollen Offenlegung"
Crypto-Gram Reprints
Terroristen, Kryptographie und Exportgesetze
News
Counterpane News
Bernsteins Faktorisierungs-Durchbruch?
Richard Clarke über die Lektionen vom 11.09.
Leserkommentare

SNMP ist das Simple Network Management Protocol, das populärste Protokoll zum Management von Netzwerkgeräten. Hunderte, möglicherweise Tausende Produkte benutzen es. Letzten Herbst entdeckte eine Gruppe finnischer Forscher mehrfache Verwundbarkeiten im SNMP. Mit der Ausnutzung dieser Verwundbarkeiten könnte ein Angreifer einen Denial-Of-Service-Angriff durchführen, und in einigen Fällen die Kontrolle über das System übernehmen.

Die Verwundbarkeiten betreffen die SNMP-Funktionen zur Trap- und Request-Behandlung und stammen von Problemen im Referenzcode, der (vermutlich) in der Abstract Syntax Notation (ASN.1) und den Basic Encoding Rules (BER) verwendet wurde. Die SNMP-Verwundbarkeiten betreffen Hunderte verschiedener Geräte: Betriebssysteme, Netzwerkausrüstung, Software, sogar Dinge wie digitale Kameras. Es ist ein GROSSES Problem.

Es ist tatsächlich ein größeres Problem als berichtet worden ist. ASN.1 wird in vielen anderen Applikationen wie z.B. OpenSSL benutzt. Diese Verwundbarkeiten sind nicht auf SNMPv1 beschränkt; das ist lediglich das einzige, das an diesem Punkt in Veröffentlichungen ausreichend behandelt worden ist. (Die vor kurzem berichteten Probleme in mod_ssl und Apache hängen damit offenbar ebenfalls zusammen.)

Die Geschichte der Entdeckung und Veröffentlichung dieser Verwundbarkeit ist eine interessante Story und illustriert das Spannungsfeld zwischen der Geheimhaltung von Fehlern und dem Full Disclosure. Eine Forschergruppe der Oulu University Secure Programming Group in Oulu, Finnland, entdeckte dieses Problem zuerst im Oktober 2001 und entschied sich, es wegen seiner Ausmaße nicht zu veröffentlichen. CERT übernahm die Aufgabe, die Bereinigung mit den großen Softwareherstellern zu koordinieren, und hat als Grund für die lange Verzögerung der Veröffentlichung die große Zahl der Hersteller angegeben, die es zu kontaktieren galt. CERT hatte sogar Probleme mit Herstellern, die das Problem nicht ernst nahmen, und musste einen erheblichen Einsatz aufwenden, um die Aufmerksamkeit der richtigen Leute zu erregen. Lektion #1: Wenn Fehler geheim sind, werden sich viele Hersteller nicht um das Patchen ihrer Systeme bemühen.

Die Verwundbarkeit wurde am 12. Februar veröffentlicht. Vermutlich war dies zwei Wochen früher als geplant und weil die Story sich zu sehr verbreitete. CERT befand, dass eine frühe Veröffentlichung besser war als weitverbreitete Gerüchte. Einige Firmen wurden überrascht. Obwohl sie Monate zum Patchen ihrer Systeme hatten, waren sie nicht fertig und benötigten diese beiden Extrawochen. Einige Firmen sorgten sich nicht um das Problem, bis die Veröffentlichung unmittelbar bevorstand. Lektion #2: Es ist nur die Drohung der Veröffentlichung, die viele Hersteller zum Patchen ihrer Systeme veranlasst. (Fairerweise muss gesagt werden, dass viele Firmen im proaktiven Patchen ihrer Systeme eine grossartige Leistung vollbracht haben. Und in vielen Fällen waren die Patches nicht trivial. Einige Hersteller wurden von der bloßen Anzahl verschiedener Produkte und Releases überfordert, die sie zu patchen und zu testen hatten. Und ich betone "testen", weil das Patchen von fertigem Code eine hohe Wahrscheinlichkeit mit sich bringt, dass entweder das Problem nicht beseitigt wird oder neue Probleme eingebaut werden.)

Als CERT schließlich veröffentlichte und die Oulu-Website online ging, gab es alle möglichen Reaktionen. Einige versuchten, die Ankündigung hochzuspielen, um ihre Produkte zu verkaufen; andere versuchten sie herunterzuspielen. Viele Hersteller hatten keine Ahnung, ob sie verwundbar waren oder nicht. Aber weil die Veröffentlichung mit dem PROTOS-Tool Demonstrationscode beinhaltete, waren Hersteller und Sicherheitsfirmen in der Lage, Netzwerke und Ausrüstung zu testen. Lektion #3: Eine Veröffentlichung muss genügend Informationen beinhalten, um die Verwundbarkeit zu reproduzieren; anderenfalls gibt es für niemanden einen Weg, um den Ernst der Bedrohung herauszufinden. Und Lektion #4: Wenn es keinen Weg zur unabhängigen Überprüfung der Verwundbarkeit gibt, sind die Organisationen gezwungen, sich auf Informationen aus möglicherweise befangenen Quellen zu verlassen.

Zum Zeitpunkt des Verfassens dieses Artikel hat es noch keine verlässlichen Berichte über einen Exploit dieser Verwundbarkeit in freier Wildbahn gegeben. Counterpanes Monitoring hat bei keinem unserer Kunden einen Angriff über diese Verwundbarkeit aufgespürt. Das heißt nicht, dass es noch niemand getan hat -- die Entwicklung eines Angriffstools ist eine einfache Programmieraufgabe -- aber niemand hat ein solches Tool veröffentlicht und in die Hände der Script Kiddies gelegt. Lektion #5: Die Veröffentlichung bedeutet nicht automatisch, dass die Verwundbarkeit ausgenutzt wird.

So weit haben wir Glück gehabt. Aber ein Tool könnte jederzeit auftauchen, deshalb wäre es nicht sehr geschickt, sich auf das Glück zu verlassen. Und obwohl jeder zum Patchen seiner Systeme und Produkte gedrängt wurde, werden es einige nicht machen. Selbst wenn es Monate dauert bevor jemand ein Angriffstool entwickelt, wird es gegen eine überraschend große Teilmenge der Systeme funktionieren. Lektion #6: Die Veröffentlichung vergrößert die Wahrscheinlichkeit, dass eine Verwundbarkeit ausgenutzt wird.

Und es gibt eine große Zahl an Systemen, für die niemals Patches verfügbar sein werden. In den letzten paar Jahren haben viele Router-Hersteller ihr Geschäft aufgegeben, und nicht jede Tante Emma Softwarefirma da draussen hat das Geld oder einen Anhaltspunkt, um ihre Hardware zu ersetzen, weil deren Code ein Problem hat. Lektion #7: Weil viele, viele Systeme ungepatcht bleiben werden, wird diese Verwundbarkeit auf Jahre hinaus ein Risiko bleiben.

Bei Counterpane waren wir in der Lage, den öffentlichen Demonstrationscode zur schnellen Entwicklung von Filtern für unsere Sentry zu benutzen und diese in den Netzwerken unserer Kunden einzubinden. Wir schafften dies innerhalb von Stunden, so dass wir die Netzwerke auf Beweise für eine Ausnutzung untersuchen können, selbst wenn sie ihre Systeme nicht gepatcht hatten. Wir patchten unsere eigene Sentry. Dies war nicht perfekt -- in einigen Systemen tauchte der Angriff nicht in deren Überwachungslogs auf -- aber es läßt uns wissen, welche Systeme von anderen Sicherheitstools profitieren würden, wie IDS-Signaturen, die für das Aufspüren des PROTOS-Tools angepasst werden. Wir haben eine Liste von IDS-Signaturen für Snort, RealSecure, CiscoIDS, Network Flight Recorder, etc. gesammelt und gepflegt, die speziell auf das Einsammeln der Testpakete des PROTOS-Tools abgestimmt sind.

Wir haben ausserdem ein Gutachten an unsere Kunden geschickt -- eine Stimme der Vernunft zwischen den leicht hysterischen News-Artikeln -- und stellten unsere Network Intelligence-Gruppe in einer Konferenzschaltung zur Verfügung, um sie zu beruhigen. Wir stellten unsere Forschungen dem FBI und anderen Sicherheitsorganisationen zur Verfügung. Lektion #8: Umsichtiges Monitoring stellt eine weitere Sicherheitsstufe zur Verfügung, ob und wenn Produkte und Patches versagen.

Obwohl diese Verwundbarkeiten ernst sind, sollte die Tatsache, dass SNMP verwundbar ist, nicht für jeden überraschend kommen. Verwundbarkeit "U7" in den SANS Top 20 spricht über SNMP. SANS Empfehlungen: "Wenn Sie SNMP nicht wirklich benötigen, deaktivieren Sie es." Dies war ein guter Rat, als die Liste erschien, und es ist jetzt ein guter Rat.

CERT Gutachten:
<http://www.cert.org/advisories/CA-2002-03.html>
<http://www.cert.org/tech_tips/snmp_faq.html>

Counterpane Gutachten:
<http://www.counterpane.com/alert-snmp.html>

Oulus Analyse und die PROTOS-Testsuite:
<http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/snmpv1/>

Analysen and Artikel:
<http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2847924,00.html>
<http://www.theregister.co.uk/content/4/24167.html>
<http://www.infoworld.com/articles/op/xml/02/03/04/020304opsecurity.xml>

IETF-Dokument zur "Verantwortungsvollen Offenlegung"

Das IETF-Dokument zur sogenannten "Verantwortungsvollen Offenlegung" (Responsible Disclosure) ist als Entwurf veröffentlicht worden. Trotz einiger Texte, die das Gegenteil behaupten, ist es keine Blaupause für Firmen, ihre Verwundbarkeiten geheim zu halten. Es ist eine Sichtweise, wie Verwundbarkeiten bekannt gegeben werden sollten: zuerst an den Hersteller und dann, nach dem Verstreichen einer angemessenen Frist, an die allgemeine Öffentlichkeit.

Generell stimme ich mit der Philosophie des Dokuments überein. Ich möchte, dass die Hersteller Zeit zur Bereitstellung der Patches haben, bevor die Verwundbarkeiten veröffentlicht werden. Gleichzeitig möchte ich nicht, dass die Veröffentlichung in irgendeiner Weise beschränkt wird. Dieses Dokument unternimmt den Versuch, eine Balance zu finden, und ich denke dass es gut gelingt.

Ich beklage deshalb eher das Vorgehen als den Inhalt. Ich denke nicht, dass dies als ein IETF-Dokument irgendeinen Sinn macht. Die IETF ist ein Standardisierungsgremium; sie sind gut in der Spezifikation, welches Bit wohin gehen soll, aber es liegt nicht in ihrem Aufgabenbereich, politische Vorschläge zu machen.

Ich mag die Art nicht, wie das Dokument geschrieben ist: darin sind so viele Ratschläge und so wenig Anforderungen, dass jemand nahezu alles machen und dabei behaupten kann, er folge dem Dokument. Und ich glaube, dass das Dokument von Firmen dazu benutzt werden könnte, die Zurückhaltung von Informationen zu Verwundbarkeiten und das Ignorieren von Sicherheitsproblemen zu rechtfertigen. In meiner Abrechnung zur SNMP-Verwundbarkeit oben kann man sehen, wie die Drohung des Full Disclosure das ist, was die Firmen zum Patchen ihrer Systeme zwingt. Im gleichen Ausmaß wie die Befolgung des IETF-Dokuments diese Drohung reduziert, reduziert sie auch unsere Sicherheit.

Und ich denke, dass der Titel falsch ist. Es handelt sich um "Eingeschränkte Offenlegung" oder vielleicht "Langsame Offenlegung." Ob es verantwortungsvoll ist oder nicht, ist weiterhin zu diskutieren.

Ich weiss, dass es einige alternative Vorschläge als Entwurf gibt. Ich würde am Ende dieses Prozesses gerne eine Art einzelnes Konsens-Dokument sehen, aber ich denke nicht, dass das IETF der Ort ist, an dem dieser Konsens erreicht werden kann.

Entwurf
<http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-00.txt>

<http://zdnet.com.com/2100-1105-842656.html>
<http://www.computerworld.com/storyba/0,4125,NAV47_STO68558,00.html>
<http://www.eweek.com/article/0,3658,s=712&a=23200,00.asp>

Crypto-Gram Reprints

Security patch treadmill:
<http://www.schneier.com/crypto-gram-0103.html#1>

Insurance and the future of network security:
<http://www.schneier.com/crypto-gram-0103.html#3>

The "death" of IDSs:
<http://www.schneier.com/crypto-gram-0103.html#9>

802.11 security:
<http://www.schneier.com/crypto-gram-0103.html#10>

Software complexity and security:
<http://www.schneier.com/crypto-gram-0003.html#SoftwareComplexityandSecurity>

Why the worst cryptography is in systems that pass initial cryptanalysis:
<http://www.schneier.com/crypto-gram-9903.html#initial>

Terroristen, Kryptographie und Exportgesetze

Jahrelang haben wir Kryptographen gesagt, dass die Exportbeschränkung für Kryptographie auf 40 Bits ineffektiv ist, weil Terroristen nicht dumm genug sind, um 40 Bit Schlüssel zu benutzen. Stellen Sie sich also meine Überraschung vor, wenn wir lernen, dass ein Terrorist dumm genug ist, 40 Bit Schlüssel zu benutzen.

Es sieht so aus, dass der Richard Reid, der verhinderte "Schuhbomber"-Terrorist, seine PC-Dateien mittels 40 Bit Schlüsseln verschlüsselte. Und sie wurden mit Brute Force geknackt.

Dies kann leicht fehlinterpretiert werden. Die Lektion besteht hier nicht darin, dass alle Terroristen dumm sind, sondern lediglich darin, dass mindestens ein dummer Terrorist existiert. Trotz dieser delikat-ironischen Anekdote wiegen die Vorteile, die allgegenwärtige starke Verschlüsselung der Gesellschaft bringt, die Nachteile aus der Unfähigkeit auf, Festplatten von gefangenen Terroristen nicht entschlüsseln zu können.

<http://www.newscientist.com/news/news.jsp?id=ns99991804>
<http://news.independent.co.uk/world/americas/story.jsp?story=114885>
<http://slashdot.org/articles/02/01/18/146229.shtml>

News

Eine DoD-Studie zeigt, dass Gesichtsabtastung unter den besten Bedingungen nur 50% der Zeit funktioniert:
<http://www.wired.com/news/politics/0,1283,50470,00.html>

EPIC's Ressourcenseite zu nationalen ID-Karten:
<http://www.epic.org/privacy/id_cards/>

Lauschangriff auf das Internet in einer massiven Größenordnung. Es kam heraus, dass Comcast die Surfgewohnheiten -- jede besuchte Webseite -- ihrer Millionen Kunden mit High-Speed Anbindung heimlich aufgezeichnet hat. Sie haben dies aus Performance-Gründen gemacht, aber diese Daten würden per Gerichtsbeschluss der Polizei und dem FBI zur Verfügung stehen, sowie Anwälten in Zivilprozessen.
<http://www.siliconvalley.com/mld/siliconvalley/2661735.htm>
Mindestens ein Kongressabgeordneter, Rep Markey, möchte diese Praxis illegalisieren:
<http://www.usatoday.com/life/cyber/tech/2002/02/13/comcast-privacy.htm>
Einige Tage nach Erscheinen dieser Story sagte Comcast, dass sie dies nicht länger durchführen würden:
<http://www.nytimes.com/2002/02/14/technology/14PRIV.html>

Gute Story über die Sicherheitsrisiken des SOAP-Protokolls:
<http://www.prescod.net/rest/security.html>

Sicherheitslöcher in einem Programm zum anonymen Websurfen, Safeweb:
<http://www.wired.com/news/politics/0,1283,50371,00.html>
<http://www.theregister.co.uk/content/6/24105.html>
<http://www.cs.bu.edu/techreports/pdf/2002-003-deanonymizing-safeweb.pdf>

Interessante Story über Flugsicherheit. Flugbegleiter haben die Kontrolle über ein Flugzeug unterwegs nach Salt Lake City übernommen, und ein skeptischer Passagier hatte ihnen nicht geglaubt. Wie sollen die Berechtigungsnachweise in einer Situation wie dieser überprüft werden?
<http://www.salon.com/people/feature/2002/02/20/bizzaro/index.html>

Sicherheits-Outsourcing: Was man tun sollte, was man nicht tun sollte, und Ratschläge:
<http://www.networknews.co.uk/Analysis/1129412>

Nettes Essay über die Full Disclosure-Debatte:
<http://www.infosecnews.com/opinion/2002/02/27_02.htm>

Scarfo plädiert auf schuldig, also wird es keine Berufungsgerichtlichen Entscheidungen zum Keylogger des FBI und dessen Einsatzanforderungen geben.
<http://story.news.yahoo.com/news?tmpl=story&u=/ap/20020228/ap_on_re_us/mobster_s_son_2>

Interessante Verwundbarkeit des Macintosh. Dies sind Kaskaden von recht unschuldigen Features, die sich zur Verursachung von Problemen kombinieren.
<http://homepage.mac.com/vm_converter/mac_autoexec_vuln.html>

Guter Artikel über Ermittlungstechniken zum Lösen von Cybercrimes und die Probleme.
<http://www.osopinion.com/perl/story/16502.html>

Eine Studie von Oracle kommt zum Schluss, dass Insider schlimmer als Hacker sind. Dies sollte keine Überraschung sein.
<http://www.networknews.co.uk/News/1129574>
<http://www.theregus.com/content/55/24212.html>
<http://oraclepressoffice.bulletonline.com/showrelease.php?id=128>

Der aktuellste falsche Sicherheits-Wettbewerb. Sogar für das Doghouse zu dumm:
<http://biz.yahoo.com/bw/020301/12094_1.html>

Exzellentes (und langes) Referat über einen Risiko-Management-basierten Ansatz zur Computersicherheit:
<http://cisac.stanford.edu/docs/soohoo.pdf>

Microsoft verzögert .NET und zitiert Sicherheitsbedenken als einen der Gründe. Unter der Annahme, dass dies ein wirklicher Grund und kein für die Presse vorgeschobener ist, ist dies eine gute Neuigkeit. Möglicherweise ist es sogar ein Vorbote eines neuen Wegs der Geschäftspraxis in Redmond.
<http://www.pcmag.com/article/0,2997,s=1582%26a=23449,00.asp>
Ich bin weiterhin skeptisch, aber hoffnungsvoll.
<http://news.zdnet.co.uk/story/0,,t269-s2105503,00.html>

Zwei verschiedene Referate über optische Informationslecks, eines von CRT-Bildröhren und das andere von Leuchtdioden. Informationen können ohne physikalischen Kontakt zum Zieldisplay über eine Distanz gelesen werden. Diese Sache ist analog zur elektrischen Abstrahlung (TEMPEST).
<http://www.cl.cam.ac.uk/~mgk25/ieee02-optical.pdf>
<http://applied-math.org/optical_tempest.pdf>
Einige Reporter haben mich gefragt, für wie schwerwiegend ich dies halte. Kurze Antwort: Nicht sehr. Ich habe keinen Weg, um mich selbst gegen solcherart gut motivierte und mit Mitteln ausgestattete Angreifer zu verteidigen. Sie können bereits einen Van ausserhalb meines Hauses parken und meinen Computer abhören. Sie können bereits während meiner Abwesenheit in mein Haus einbrechen und Dutzende an Abhörgeräten und Tastaturloggern und wer weiss was noch installieren. Also haben sie jetzt einen weiteren Weg, wie sie mich abhören können. Ich kann weiterhin nichts gegen irgendeinen davon unternehmen. Zumindest nicht, ohne eine GANZE Menge Geld auszugeben.

Network Associates hat PGP umgebracht:
<http://www.zdnet.com/anchordesk/stories/story/0,10738,2852437,00.html>
<http://www.computerworld.com/storyba/0,4125,NAV47_STO68885,00.html>
Wohlgemerkt, dies bedeutet nicht, dass PGP tot ist. Der OpenPGP-Standard und GPG werden weiterhin bedeutsamer.
<http://www.theregister.co.uk/content/54/24336.html>
<http://www.openpgp.org/>

Ein wirklich cleverer Social-Engineering-Hack. Hat nichts mit Computern zu tun, aber sehr lesenswert.
<http://seattletimes.nwsource.com/html/localnews/134416347_scam07m.html>

Exzellentes Dokument über Software-Haftung, geschrieben von einer Gruppe Rechtsanwälte und jemandem von CERT. Erforderliche Lektüre.
<http://www.cert.org/archive/pdf/Downstream_Liability.pdf>

Counterpane News

Schneier wird Counterpanes Managed Security Monitoring Dienste in den folgenden Städten präsentieren: Austin, Boston, Dallas, Chicago, Minneapolis, New York und Tallahassee. Besuchen Sie diese Seite für die Daten und um sich anzumelden:
<http://www.counterpane.com/seminars.html>

Hier gibt es einige neue Fallstudien von Counterpane-Kunden:
<http://www.counterpane.com/experiences.html>

Gemischte Presseveröffentlichungen von Counterpane-Partnern und -Kunden:
<http://www.counterpane.com/pr-neccisco.html>
<http://www.counterpane.com/pr-dyntek.html>

Bernsteins Faktorisierungs-Durchbruch?

Letzten Herbst brachte der Mathematiker Dan Bernstein ein Dokument in Umlauf, in dem er Verbesserungen bei der Integer-Faktorisierung durch die Benutzung spezialisierter paralleler Hardware diskutierte. Das Dokument erhielt nicht viel Aufmerksamkeit, bis vor kurzem Diskussionen über die Ergebnisse auf SlashDot und anderen Internetforen aufkamen. Ein unbefangenes Lesen des Dokuments impliziert, dass Faktorisierung durch den Einsatz der in dem Dokument beschriebenen Maschine jetzt erheblich einfacher ist, und dass Schlüssel mit einer Länge von bis zu 2048 Bits jetzt geknackt werden können.

Dies ist nicht der Fall. Für die in Bernsteins Dokument beschriebenen Verbesserungen ist es unwahrscheinlich, dass sie die beanspruchten Geschwindigkeits-Verbesserungen für praktisch nutzbare Zahlen erbringen.

Zur Zeit ist das Number Field Sieve (NFS), das das Quadratic Sieve vor einigen Jahren verdrängte, der schnellste Algorithmus zur Faktorisierung. Im wesentlichen hat das NFS zwei Phasen. Die erste ist eine Suche nach Gleichungen, die bestimmte mathematische Eigenschaften erfüllen. Dieser Schritt ist hochparallelisierbar und wird heutzutage mit tausenden Computern routinemäßig ausgeführt. Der zweite Schritt ist eine große Matrix-Kalkulation, die letztendlich die Primfaktoren der Zielzahl produziert.

Bernstein versucht, die Effizienz beider Schritte zu verbessern. Dabei werden einige gute Beobachtungen gemacht, die zu einigen geringfügigen Beschleunigungen bei der Faktorisierung führen werden, aber die behaupteten enormen Verbesserungen sind eher ein Ergebnis der Neudefinition von Effizienz als von allem anderen. Bernstein stellt seine Ergebnisse als Effekt der massiven Parallelisierung dar. Für mich ist dies irreführend. Eine parallele Maschine kann immer auf einem einzelnen Computer durch die Benutzung einer Zeitscheiben-Architektur simuliert werden. In seinem Modell sind die "Kosten" der Faktorisierung ein Produkt aus Zeit und Raum, und er behauptet, dass er die Kosten der parallelen Sortierung von einem Faktor m^4 auf m^3 reduzieren kann. Bernstein begründet seine Annahmen mit der Ausführung, dass ein einzelner Prozessor m^2 Speicher benötigt, wohingegen ein Array aus m^2 Prozessoren lediglich konstanten Speicher benötigt. Dies mag stimmen, vernachlässigt aber die Einberechnung der Kosten, die durch die Verbindung dieser Prozessoren entsteht: die Zusammenbindung einer Million einfacher Prozessoren ist sehr viel teurer als die Benutzung eines einzelnen Prozessors desselben Designs mit einem Speicher aus einer Million Bits. Wiederrum ist es nicht klar, dass diese Technik für Zahlen einer praxisrelevanten Größe irgendwelche Vorteile bringt.

Selbstverständlich behauptet Bernstein nichts anderes. (Tatsächlich muss ich ihn dafür loben, dass er kein Teil des Hypes ist.) Sein Ergebnis ist asymptotisch. Dies bedeutet, dass es letztendlich stimmt, wenn die Größe der faktorisierten Zahlen gegen Unendlich strebt. Dies sagt nichts darüber aus, wieviel effizienter Bernsteins Algorithmus ist oder ob er überhaupt effizienter als aktuelle Techniken ist oder nicht. Bernstein selbst sagt dies in einem seiner Postings: "Der Schutz gegen [diese Techniken] bedeutet den Wechsel von n-Bit-Schlüsseln zu f(n)-Bit-Schlüsseln. Ich möchte hervorheben, dass an diesem Punkt sehr wenig über die Funktion f bekannt ist. Es ist klar, dass f(n) für *sehr* große n ungefähr (3,009...)n ist, aber ich weiss nicht, ob f(n) für *benutzbar* große n größer als n ist." Was er meint: ab einer bestimmten Bitlänge werden diese Techniken sinnvoll sein, aber wir haben keine Ahnung, welche Bitlänge dies ist.

Ich glaube nicht an den Faktor n - 3n für die Längenverbesserung. Jede praktische Implementierung dieser Techniken hängt stark von komplizierten technologischen Annahmen und Kompromissen ab. Paralleles Rechnen ist sehr viel leichter gesagt als getan, und es gibt dabei immer versteckte Komplexitäten. Ich denke, wenn die gesamte Mathematik gesagt und getan ist, werden diese anderen Komplexitäten die Steigerungen ausgleichen.

Dies soll Bernsteins Arbeit nicht herunterspielen. Dies ist gute Forschung. Ich mag seinen neuartigen Weg, Sortiertechniken zur Durchführung des Teils der linearen Algebra einzusetzen. Dies kann in einigen anderen Kontexten sinnvoll einsetzbar sein und wird wahrscheinlich neue Forschungsrichtungen im Design effizienterer Sortier-Netzwerke und effektiver Matrizen-Algorithmen eröffnen. Es gibt in diesem Dokument weitere Geschwindigkeitsverbesserungen der NFS, und sie werden definitiv weiter erforscht werden.

Über die vergangenen Jahrzehnte ist die Faktorisierung beständig einfacher geworden, und sie ist schneller einfacher geworden, als jeder geglaubt haben würde. Verbesserungen der Geschwindigkeit sind aus vier Quellen gekommen: Eins, Prozessoren sind schneller geworden. Zwei, Prozessoren sind billiger geworden und einfacher in Netzwerken zur parallelen Berechnung einsetzbar. Drei, es hat einen beständigen Fluss an kleineren Verbesserungen der Faktorisierungsalgorithmen gegeben. Und vier, es hat fundamentale Fortschritte in der Mathematik der Faktorisierung gegeben.

Ich glaube, dass Bernsteins Arbeit in die dritte Kategorie fällt und dabei Vorteile aus zusätzlichen Verbesserungen in der zweiten Kategorie zieht. Und wenn aus der Geschichte Lehren gezogen werden können, dann wird es Jahre dauern bis jemand exakt weiss, ob und wie sich diese Arbeit auf die gegenwärtige Faktorisierung praktischer Zahlen auswirken wird.

Bernsteins Dokument:
<http://cr.yp.to/papers/nfscircuit.ps>

Richard Clarke über die Lektionen vom 11.09.

Auf der diesjährigen RSA-Konferenz sprach Richard Clarke in seiner Keynote über Cybersicherheit in der Nachfolge des 11. Septembers. Der Anfang seiner Rede war exzellent: er zählte sechs Lektionen aus den terroristischen Angriffen auf. Es begann auseinanderzufallen, als er ausführte, dass die Unternehmen aus der Güte ihres Herzens und aus Sorge um ihren Lebensweg sicherere Produkte produzieren und benutzen sollten. Und es brach weiter zusammen, als er eine neue Ausnahme zum Freedom of Information Act verfocht, den jeder, der sich mit dem Problemkreis auseinander gesetzt hat, als unnötig und schädlich bezeichnet. Aber seine Eröffnung war gut.

Hier sind Clarkes sechs Lektionen. Sie treffen nicht nur auf die Bekämpfung von Cyberterrorismus zu, und ich werde sie in Begriffen der alltäglichen Netzwerksicherheit erklären.

1. "Wir haben Feinde." Jeder hat welche. Firmen haben Mitbewerber. Menschen haben andere, die sie nicht mögen. Einige Feinde greifen uns direkt an, andere wollen lediglich jemanden ausrauben, wer ist ihnen egal. Zu viele Firmen rechtfertigen ihre Unaufmerksamkeit in Sicherheitsfragen, indem sie sagen: "Wer würde uns angreifen wollen?" Das ergibt einfach keinen Sinn.

2. "Unterschätze sie nicht." Mach es nicht. Sei es ein DVD-Pirat, der in einem Land ohne Copyrightgesetze lebt, oder ein Hacker-Kid, das Tage mit den Versuchen verbringt, in ein Netzwerk einzubrechen: Angreifer aus dem Cyberspace haben sich als besser ausgestattet, gerissener und hartnäckiger erwiesen, als jeder vermutet hat. Wenn Sie annehmen, dass Ihre Feinde nicht in der Lage sein werden, Ihre Verteidigungen herauszufinden und zu umgehen, dann geben Sie nicht acht.

3. "Sie werden unsere Technologie gegen uns verwenden." Dies ist insbesondere im Cyberspace wahr. Fast alle Angriffe beinhalten die Benutzung des angegriffenen Netzwerks selbst. Vielleicht ist es eine Verwundbarkeit in der Software; vielleicht ist es ein Feature, das niemals hätte entwickelt werden sollen. Hacken ist Judo: Die Benutzung von Netzwerksoftware, um Dinge zu tun, für die sie niemals vorgesehen war.

4. "Sie werden die Nahtstellen unserer Technologie angreifen." So schlecht die meiste erhältliche Kryptographie sein mag, es ist so gut wie immer einfacher, ein System auf eine andere Weise zu brechen. Angriffe auf die Nahtstellen -- die Orte, an denen verschiedene Technologien zusammenkommen -- sind ergiebiger. Man denke an das FBI, das PGP-verschlüsselte Mails durch die Installation eines Tastatur-Sniffers gelesen hat, oder an Leute, die Kopierschutzmechanismen umgehen, indem sie diese Nachahmen statt sie zu knacken. Diese Lektion ist für jeden offensichtlich, der Sicherheitssoftware geknackt hat.

5. "Unsere Technologie ist überraschend voneinder abhängig." Das ist sicherlich klar. Wir haben Verwundbarkeiten im IIS gesehen, die sich auf alle möglichen Systeme auswirken. Wir haben böswilligen Code gesehen, der Features von Microsoft Word und Outlook zur Verbreitung benutzt. Eine einzelne SNMP-Verwundbarkeit betrifft Hunderte von Produkten. Über die gegenseitige Abhängigkeit arbeitet das Internet. Sie ist auch das, woran es versagt.

6. "Der einzige Weg zur Lösung dieses Problems ist die Zusammenarbeit von Regierung und Industrie." Dies ist mehr subjektiv, aber ich stimme dem zu. Ich denke nicht, dass die Industrie es alleine kann, vor allem weil sie keinen Ansporn dazu hat. Ich denke nicht, dass die Regierung es alleine kann, weil sie nicht die Fähigkeiten dazu hat. Clarke scheint zu denken, dass es die Aufgabe der Regierung ist, einige Mittel, Koordination auf höherer Ebene und eine allgemeine Anfeuerung bereitzustellen. Ich denke, dass es die Aufgabe der Regierung ist, den Firmen einen finanziellen Anreiz zu geben. Wenn man die Netzwerksicherheit in Ordnung bringen will, muss das Geschäftsmodell gehackt werden. Die Haftungsausnahmen für Software müssen entfernt werden. Es muss eine regelmässige Berichterstattung verlangt werden, wie es für Y2K erforderlich war. Der Geschäftsführer muss sich kümmern.

Clarke verbringt viel Zeit mit dem Besuch von Firmen und dortigen Gesprächen über Sicherheit. Ich bin sicher, dass die Geschäftsführer ihm einen warmen Zuspruch geben, und ihm sagen, dass sie ihre Sachen sicherer machen werden. Aber was passiert einen Monat später, wenn das Budget eng ist und sich ein Freigabetermin abzeichnet? Wird sich der Geschäftsführer an sein Versprechen an Clarke erinnern, oder wird er auf die Erfordernisse des Marktes hören? Wenn die Regierung wirklich will, dass sich der Geschäftsführer kümmert, muss sie die Sicherheit zu einem Marktdruck machen.

Ich sehe keinen anderen Weg.

Leserkommentare

<http://www.schneier.com/crypto-gram-0203.html#8>

Crypto-Gram ist ein kostenloser monatlicher Newsletter mit Zusammenfassungen, Analysen, Einsichten und Kommentaren über Computersicherheit und Kryptographie. Ältere Ausgaben und die Möglichkeit des Abonnements stehen hier zur Verfügung:
<http://www.schneier.com/crypto-gram.html>

Die deutschen Übersetzungen stehen hier zur Verfügung:
<http://archiv.galad.com/cg/cg.htm>

Die deutsche Übersetzung von Crypto-Gram darf an interessierte Kollegen und Freunde weiterverteilt werden. Die Erlaubnis zum Nachdruck der deutschen Übersetzung von Crypto-Gram ist gewährt, solange die Wiedergabe als Gesamtheit erfolgt. Die LinkMap kann selbstverständlich entfernt werden.

Bruce Schneier ist der Verfasser von Crypto-Gram. Schneier ist der Gründer und CTO der Counterpane Internet Security Inc., der Autor von "Secrets and Lies" und "Applied Cryptography", und ein Erfinder der Blowfish-, Twofish- und Yarrow-Algorithmen. Er ist ein Mitglied des Beraterboards des Electronic Privacy Information Centers (EPIC). Er ist ein regelmäßiger Autor und Dozent über Computersicherheit und Kryptographie.

Deutsche Übersetzung von Holger Hasselbach, galad.com, mit freundlicher Erlaubnis der Counterpane Internet Security, Inc.