Crypto-Gram 15. Februar 2002

Crypto-Gram Newsletter 15. Februar 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: 25.02.2002

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

In dieser Ausgabe:

Microsoft und "Trustworthy Computing"
Beurteilung von Microsoft
Crypto-Gram Reprints
News
Counterpane News
Oracles "unknackbare" Datenbank
Leserkommentare

Microsoft und "Trustworthy Computing"

Bill Gates liegt mit der Aussage richtig, dass die gesamte Industrie sich auf das Erreichen des Trustworthy Computing (vertrauenswürdiger Computereinsatz) konzentrieren muss. Er hat Recht, wenn er sagt, dass es eine schwierige und langwierige Herausforderung ist, und ich hoffe er hat Recht, wenn er sagt, dass Microsoft sich dieser Herausforderung annimmt. Ich weiss es allerdings nicht sicher. Ich kann nicht sagen, ob die Gates-Notiz eine wirkliche Veränderung bei Microsoft repräsentiert, oder lediglich eine weitere Marketingstrategie. Microsoft hat so viele leere Behauptungen über ihre Sicherheitsprozesse gemacht -- und über die Sicherheit ihrer Prozesse --, dass ich mir beim Hören einer weiteren nicht helfen kann zu glauben, dass sie mehr desselben Kassenschwindels ist.

Erinnert sich jemand an letzten November, als Microsofts VP Jim Allchin in einem eWeek-Interview sagte, dass alle Buffer Overflows in Windows XP eliminiert wurden? Oder dass es sich auf eine minimalistische Installation beschränkt, mit Features, die per Default abgeschaltet sind? Die UPnP-Verwundbarkeit war nicht nur in einem unnötigen Feature, dass per Default aktiviert war; sie war ein Buffer Overflow. Erinnert sich jemand daran, wie sich Scott Culp darüber beklagte, wie die Leute "Informations-Anarchy" verursachen, indem sie Details über Sicherheitslücken bei Microsoft herausgeben, und wie er bewarb, wie schnell Microsoft beim Patchen von Problemen ist? Da ist eine neue Verwundbarkeit im IE, die Microsoft geschäftig ignoriert. Oder als Culp sagte, dass die UPnP-Verwundbarkeit "die erste Netzwerk-basierte Remote-Kompromittierung" war, und dabei bequemerweise Code Red, Nimda und die dutzende anderen vorher ignorierte?

Aber wir wollen hoffen, dass die Gates-Notiz mehr als ein Griff nach den Titelzeilen war und eine grundlegende Veränderung innerhalb Microsofts repräsentiert. Wenn das der Fall ist, dann applaudiere ich der Entscheidung dieser Firma. Sie ist eine schwierige. Es ist nicht einfach, Sicherheit über die Features zu stellen. Microsoft wird Dinge sagen müssen wie: "Wir legen die gesamte .NET-Initiative auf Eis, vielleicht für Jahre, während wir die Sicherheitsprobleme herausarbeiten." Sie müssen jegliche Entwicklung an Betriebssystemfeatures einstellen, während sie durch den existierenden Code gehen, Zeile für Zeile, Verwundbarkeiten beseitigen, unsichere Funktionalitäten eliminieren und Sicherheitsfeatures hinzufügen. Sicherheit funktioniert am besten, wenn es von Anfang an in das System hineindesignt wird, also muss eine Menge von dem, was bereits fertiggestellt ist, neu geschrieben werden.

Es wird Arbeit benötigen, um dies hinzubekommen. Microsoft hat ein Monopolgeschäft aufgebaut, indem sie Features in ihre Produkte werfen und die Probleme später behandeln. Es ist das, was sie normalerweise tun. Es ist das, was alle Softwareentwickler normalerweise tun. Es ist eine ziemlich starke Führung nötig, um diese Mentalität umzukehren: um den Zeitplan der Veröffentlichungen zu verzögen, die Funktionalität zurückzustutzen und möglicherweise kurzfristig Marktanteile zu verlieren.

Und sie werden ihre Mentalität umkehren müssen, Sicherheitsprobleme als Probleme der Public Relations zu handhaben. Ich würde von Microsoft gerne Ehrlichkeit über ihre Sicherheitsprobleme sehen. Nicht weiterhin vorgeben, dass Probleme nicht real wären, wenn sie nicht von Exploit-Code begleitet sind, und keine Angriffe auf den Sicherheitsexperten, wenn sie es sind. Nicht weiterhin vorgeben, dass Sicherheitsprobleme nicht in erster Linie von schlechtem Code verursacht werden. Keine weiteren Behauptungen, dass XP das sicherste Betriebssystem aller Zeiten ist, nur weil es das ist, das sie verkaufen wollen.

Während wir Microsoft zu dieser Änderung gratulieren, sollten wir nicht die beiden Kräfte vergessen, die sie zu dieser Entscheidung brachten. Man sollte nicht denken, dass es eine Art großmütige Geste für das Wohl des Internets ist; Microsoft ist zu gerissen, um all diese Ressourcen aus der Güte ihres Herzen heraus aufzuwenden. Hier sollte die Full Disclosure-Bewegung genannt werden, die wiederholt gezeigt hat, dass Microsofts Sicherheit sehr viel schlimmer ist als sie behaupten. Analysten wie Gartner haben empfohlen, dass Unternehmen vom Microsoft IIS wechseln und mit der Installation von Windows XP warten, beides wegen Sicherheitsbedenken. Es ist die Full Disclosure-Bewegung, die es Gartner und jedem anderen erlaubte, die Risiken von Microsoft-Software sorgfältig einzuschätzen. Microsoft weiss, dass sie keine Zukunft haben, solange sie die Öffentlichkeit nicht überzeugen können, dass Windows XP und .NET gesichert, sicher und vertrauenswürdig sind. Die Geheimhaltung von Verwundbarkeiten wird lediglich den Druck auf Microsoft reduzieren und ihnen erlauben, zur Vorspiegelung zurückzukehren, dass sie sicher sind wenn sie es in Wirklichkeit nicht sind.

Hier sollten ebenfalls die zunehmend lauteren Rufe für Software-Haftung genannt werden. Mehr und mehr Experten und Industriegruppen und Beratungsgremien unterstützen die Ansicht, dass Software denselben Haftungsregeln wie jedes andere Verbraucherprodukt auch unterliegen sollte. Es macht keinen Sinn, dass Firestone einen Reifen mit einem systematischen Fehler produzieren kann und dafür haftet, während Microsoft ein Betriebssystem produzieren kann, in dem jede Woche ein neuer systematischer Fehler entdeckt wird, und sie nicht dafür haften. Ich denke, Gates sieht diesen Haftungs-Moloch am Horizont und gibt sein bestes um ihn zu umgehen.

Sicherheit ist ein Prozess, kein Produkt. Es ist ein endloser, anstrengender, undankbarer Prozess. Ich habe keine Illusionen darüber, dass Microsoft seine Produkte mit Bekanntmachungen in der Presse und einem Monat Entwicklertraining sicher machen kann, aber es ist ein Anfang. Die technischen Schwierigkeiten sind immens -- es sind einige Dinge dabei, die Microsoft tun muss, die zur Zeit jenseits der Fähigkeiten der derzeitigen Wissenschaft liegen -- aber Microsoft hat die Ressourcen, um sie in Angriff zu nehmen. Und durch Microsofts Monopolstellung im Softwaremarkt können sich ihre Aktionen signifikant auf die Sicherheit im Internet auswirken. Während des Jahrzehnts, in dem sie Sicherheit ignoriert haben, wurde die Sicherheit stetig schlimmer. Wenn sie zumindest in die Richtung des Trustworthy Computing vorstossen, ist es wahrscheinlich, dass sie näher herankommen.

Gates-Notiz:
<http://zdnet.com.com/2100-1104-817343.html>

Craig Mundies (Microsoft VP) Kommentar:
<http://news.com.com/2010-1078-818543.html>

Kommentare und Analysen:
<http://www.infowarrior.org/articles/2002-02.html>
<http://www.securityfocus.com/columnists/54>
<http://zdnet.com.com/2100-1107-819752.html>
<http://www.zdnet.com/anchordesk/stories/story/0,10738,2840272,00.html>
<http://www.zdnet.com/anchordesk/stories/story/0,10738,2841275,00.html>
<http://www.pbs.org/cringely/pulpit/pulpit20020117.html>
<http://www.informationweek.com/story/IWK20020131S0004>

Fragen und Antworten mit Steve Ballmer, wo er demonstriert, dass er es noch nicht verstanden hat. Mein Lieblingszitat: "Ich denke der Core Code ist OK. Es ist nicht so, dass das Coredesign schlecht ist..." Mein Optimismus lässt nach.
<http://news.com.com/2008-1082-830229.html>

Auf der anderen Seite sind dies gute Neuigkeiten von Microsoft:
<http://www.theregister.co.uk/content/55/23922.html>

Bill Joys Kommentar:
<http://news.com.com/2010-1072-831385.html>

Und Microsoft stellt Scott Charney als ihren neuen Chief Security Officer an. Ich hatte gehofft, sie würden eher jemanden wählen, der etwas über Softwaresicherheit weiß, als einen ehemaligen Hacker-Ermittler und IP-Anwalt.
<http://www.securityfocus.com/columnists/59>

Dieses Essay erschien ursprünglich auf news.com:
<http://news.com.com/2010-1078-818611.html>

Eine große SNMP-Verwundbarkeit wurde bekanntgegeben, die Hunderte von Produkten betrifft. Diese Verwundbarkeit war in der Sicherheits-Community seit letzten Oktober bekannt, wurde aber so lange vor der Öffentlichkeit zurückgehalten, dass die Hersteller Zeit haben würden, ihre Produkte zu patchen. Ich werde nächsten Monat mehr darüber schreiben.
<http://www.counterpane.com/alert-snmp.html>
<http://www.cert.org/advisories/CA-2002-03.html>
<http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/snmpv1/>
<http://www.counterpane.com/pr-snmp.html>

Beurteilung von Microsoft

Letzten Monat veröffentlichte Bill Gates eine firmenweite Notiz, in der er eine neue strategische Richtung für Microsoft skizziert. Vergleichend mit der Änderung, als die Firma das Internet mit einbezog, gibt Gates der Sicherheit bei Microsoft höchste Priorität. Durch die Konzentration auf das von ihm so genannte "Trustworthy Computing" plant Gates die Umwandlung von Microsoft in eine Firma, die verfügbare, verlässliche und sichere Software produziert.

"Wir müssen die Industrie zu einer gänzlich neuen Stufe der Vertrauenswürdigkeit im Computereinsatz führen." --Bill Gates interne Notiz, 15. Januar 2002.

Vertrauen ist nicht etwas, dass ausgehändigt werden kann; es muss verdient werden. Und Vertrauenswürdigkeit ist ein ehrenwertes Ziel im Computereinsatz. Aber anders als bei Performance-Zielen und Feature-Listen ist der Fortschritt dahin schwer zu messen. Wie kann man bestimmen, ob ein Stück Software sicherer ist als ein anderes? Oder bessere Datenintegrität bietet als ein anderes? Oder mit geringerer Wahrscheinlichkeit unentdeckte Verwundbarkeiten enthält? Wie soll man wissen, ob Microsoft wirklich hinter der Sicherheit steht, oder ob dies lediglich eine weitere Vorführung für die Presse und die Öffentlichkeit ist? Es ist nicht so einfach wie die Messung von Taktgeschwindigkeiten oder der Vergleich von Feature-Listen; oftmals zeigen sich Sicherheitsprobleme nicht in Betatests.

Als Sicherheitsexperten mit langer Erfahrung würden wir gerne einige konkrete Wege zur Bewertung von Microsofts Fortschritt (und dem jedes anderen) hin zur Vertrauenswürdigkeit vorschlagen. Dies sind spezifische und messbare Änderungen, von denen wir gerne sehen würden, dass Microsoft sie durchführt. Dies ist nicht als erschöpfende Liste vorgesehen; die Entwicklung sicherer Software erfordert sehr viel mehr als wir hier skizzieren. Unser Ziel ist, eine Liste messbarer Empfehlungen zur Verfügung zu stellen, so dass die Community Microsofts Aufrichtigkeit beurteilen kann.

Einige dieser Empfehlungen sind einfacher zu implementieren als andere, aber wenn Microsoft die Sicherheit ernst nimmt und eine wirkliche Führungsposition einnehmen will, können sie sich um keine davon herumdrücken. Einige unserer Änderungen sind einfacher zu überprüfen als andere, aber es ist unser Ziel, dass sie alle unabhängig messbar sind. Am Schluss bedeuten die Ankündigungen und Presseveröffentlichungen gar nichts. In der Sicherheit zählen Resultate.

Wenn wir unsere Empfehlungen in ein einzelnes Paradigma destillieren können, dann ist dies Einfachheit. Komplexität ist der schlimmste Feind der Sicherheit, und Systeme die mit Features, Fähigkeiten und Optionen beladen sind, sind sehr viel unsicherer als einfache Systeme, die einige wenige Dinge zuverlässig tun. Eindeutig ist Windows ein komplexes Betriebssystem und wird es immer sein. Aber es gibt Dinge, die Microsoft machen kann, um selbst dieses komplexe System einfacher und sicherer zu machen. Microsoft muss seine Programmierer auf das Design sicherer Software konzentrieren, darauf die Dinge beim ersten Mal richtig zu entwickeln.

I. Trennung der Daten- und Kontrollpfade

"Sicherheitsmodelle müssen für Entwickler einfach zu verstehen und in ihre Anwendungen einfach einzubauen sein." --Bill Gates Notiz zu Sicherheit, 15. Januar 2002.

Er hat recht. Und eines der einfachsten, stärksten und sichersten Modelle ist es, die strikte Trennung von Daten und Code zu erzwingen. Die Zusammenmischung von Daten und Code ist für eine große Anzahl an Sicherheitsproblemen verantwortlich, und Microsoft war im Internet der schlimmste Täter. Hier ist ein Beispiel: Ursprünglich bestand E-Mail nur aus Text und E-Mail-Viren waren unmöglich. Microsoft änderte dies, indem ihre Mailclients in die E-Mail eingebettete Anweisungen automatisch ausführen konnten. Dies ebnete für E-Mail-Viren wie Melissa und LoveBug den Weg, die sich automatisch an Leute im Adressbuch des Opfers weiterverteilen. Microsoft muss diesen Schaden an der Sicherheit beseitigen, indem sie diese Funktionalität aus ihren E-Mail-Clients und vielen anderen ihrer Produkte entfernen. Diese strikte Trennung von Daten und Code muss in allen Produkten angewendet werden.

Microsoft hat das Problem durch die Verwischung der Unterscheidung zwischen dem Desktop und dem Internet herbeigeführt. Dies hat zu zahlreichen Sicherheitslücken geführt, die auf verschiedenen Teilen des Betriebssystems mit unterschiedlicher Nutzung der Systemressourcen basieren. Microsoft sollte diese Designentscheidungen noch mal aufgreifen.

Wir empfehlen die folgenden Modifikationen im nächsten Release dieser Microsoft-Produkte. In Kürze: Erläuterung der Aktionen und die Zurverfügungstellung einer Sandbox-Umgebung. Dies sollte ein Release sein, das sich nur auf die Entfernung der unsicheren Features und dem Zufügen von Sicherheit konzentriert.

Office: Makros sollten nicht in Office-Dokumenten gespeichert werden. Makros sollten separat gespeichert werden, als Vorlagen, welche nicht als Dokument zu öffnen sein sollten. Das Programm sollte ein visuelles Interface zur Verfügung stellen, das den Benutzer durch die Aktionen des Makros führt, sowie Einschränkungen dafür setzen, was Makros machen können, die nicht von der IT-Abteilung der Firma signiert wurden.

Internet Explorer: Der IE sollte eine vollständige Trennung von Daten und Kontrollelementen unterstützen. Java und JavaScript sollten so modifiziert werden, dass sie externe Programme nicht auf beliebige Weise nutzen können. ActiveX sollte alle Controls eliminieren, die als "Sicher für Scripting" markiert sind.

E-Mail: E-Mail-Anwendungen sollten Scripting nicht unterstützen. (Zuallermindest sollten sie die Unterstützung per Default unterlassen.) E-Mail-Scripte sollten als getrennter MIME-Anhang angehängt werden. Es sollten Einschränkungen dafür vorhanden sein, was Makros machen können, die nicht von der IT-Abteilung der Firma signiert wurden.

.NET: .NET sollte eine klare Skizzierung haben, was agieren kann und was nicht. Die Sicherheits-Community hat von Java eine Menge über die Sicherheit von mobilem Code gelernt. Mobiler Code ist sehr gefährlich, aber jetzt ist er da. Damit mobiler Code überlebt, sollte er mit Sicherheit als primärem Feature redesignt werden.

Die Implementierung von Microsoft SOAP, einem Protokoll, das zur Umgehung von Firewalls über HTTP läuft, sollte zurückgezogen werden. Gemäß der Dokumentation von Microsoft: "Weil SOAP sich auf HTTP als Transportmechanismus stützt, und die meisten Firewalls HTTP ungehindert durchlassen, werden Sie keine Probleme damit haben, SOAP-Endpunkte von beiden Seiten einer Firewall aufzurufen." Es ist exakt diese Feature-über-Sicherheit-Mentalität, die verschwinden muss. Es mag sein, dass SOAP ausreichende Sicherheitsmechanismen und eine saubere Trennung von Code und Daten bietet. Microsoft bewirbt es jedoch für seine Vermeidung von Sicherheit.

II. Default-Konfigurationen

"Unsere Produkte sollten Sicherheit direkt von Anfang an betonen." --Gates Notiz.

Microsoft-Software installiert sich per Default mit sehr viel mehr Features, als die meisten Benutzer benötigen oder wünschen. Dies macht die Software verwundbarer als notwendig. Hierfür gibt es viele aktuelle Beispiele. Die jüngsten Universal Plug-and-Play Bugs funktionieren, sogar wenn man nicht weiß, was UPnP macht, und egal ob man es benutzt oder nicht. Der SuperCookie-Bug im Windows Media Player funktioniert, sogar wenn man den WMP nicht benutzt. Code Red greift IIS-Installationen erfolgreich an, sogar in Windows-Konfigurationen, die nicht als Webserver benutzt werden.

Als Zusatz müssen Features jedes einzeln für sich installierbar sein. In UNIX zum Beispiel sind ein Webserver und ein FTP-Server voneinander getrennt und müssen auch getrennt installiert werden. Beim IIS installiert die Installation eines Webservers nicht nur einen Webserver, sondern ebenfalls einen FTP-Server, einen Gopher-Server, und Bill selbst weiss wahrscheinlich nicht was sonst noch.

Es ist nicht genug, den Benutzern die Möglichkeit zu geben, nicht benötigte Features abzustellen. Die Benutzer wissen nicht mal, welche Features aktiviert sind, noch weniger wie sie abzustellen sind, und die Features könnten zufällig wieder reaktiviert werden. Die beste Möglichkeit zur Vermeidung von Angriffen gegen ein Feature ist es, wenn das Feature nicht da ist.

Wir empfehlen für das nächste Release aller Microsoft-Produkte, dass sie Default-Installationen mit dem geringstmöglichen Satz an Features aufweisen, und das zusätzliche Features spezielle Installationsaktivitäten benötigen, um sie zu aktivieren. Wir empfehlen außerdem, dass diese Installationen für den Benutzer sichtbar ablaufen, so dass der Benutzer weiss, welche Features installiert sind. Wir empfehlen, dass Microsoft sicherstellt, dass alle Features voneinander getrennt installiert und deinstalliert werden können, wie auch in gemeinsamen Paketen. Wir empfehlen, dass nicht benötigte Features nicht installiert werden, anstatt installiert und deaktiviert zu werden. Es sollten zusätzliche Kontrollmechanismen implementiert werden, um der IT-Abteilung einer Firma die Möglichkeit zu geben, für bestimmte Features die Installation zu verbieten.

Wir empfehlen außerdem, dass .NET mit der Möglichkeit ausgestattet wird, Konfigurationen aus verschiedenen Quellen zu benutzen, einschließlich Microsoft, deren Mitbewerbern sowie öffentlichen Interessensgruppen und -vertretungen wie der Electronic Frontier Foundation.

III. Trennung von Protokollen und Produkten

"Da Software immer komplexer, voneinander abhängig und miteinander verbunden geworden ist, ist die Reputation unserer Firma im Gegenzug verwundbarer geworden." --Gates Notiz.

Heutzutage baut Microsoft große komplexe Dienste auf, die mit vielen kleineren Diensten vermischt sind. Das Microsoft Filesharing-Protokoll zum Beispiel beinhaltet Filesharing, Registrysharing, Remote Editing, Druckersharing, Passwort-Management und eine Masse anderer Dienste. Wenn ein Benutzer einen dieser Dienste nutzen möchte, muss er alle implementieren. Diese Dienste müssen in voneinander getrennte Dienste aufgeteilt werden, die auf voneinander getrennter Serversoftware laufen, so dass ein Benutzer auswählen kann, welche er wo installieren möchte. Abgesehen davon wächst die Komplexität der Software auf demonstrierbar unsichere Stufen.

Wir empfehlen, dass Microsoft die Funktionalitäten trennt, so dass der Benutzer lediglich die von ihm benötigten spezifischen Funktionen installieren kann. Wir empfehlen außerdem, dass Microsoft eine Anzahl von vorgebündelten Funktionen zur Verfügung stellt und dies auch anderen erlaubt.

IV. Die Entwicklung sicherer Software

"Also müssen wir jetzt, wenn wir mit der Wahl zwischen dem Hinzufügen von Features und der Auflösung von Sicherheitskonflikten konfrontiert werden, die Sicherheit wählen." --Gates Notiz.

Kommerzielle Software ist voller Bugs, und einige dieser Bugs beherbergen Sicherheitslücken. Dies ist nicht als Entschuldigung von Microsofts langandauernder Teilnahmslosigkeit gegenüber der Sicherheit gemeint; es ist lediglich eine Feststellung von Tatsachen. Diese Bugs werden durch schlechte Software-Spezifikation, schlechtes Design und schlechte Implementierung verursacht. Vieles von dem, was oben diskutiert worden ist (Trennung von Daten und Anweisungen, Default-Konfigurationen, getrennte Software für getrennte Protokolle) hat den Effekt der Minimierung der Effekte von Softwarebugs durch die Reduktion der Menge an Software auf einem Computer. Wie auch immer, es wird weiterhin eine große Menge an Software auf jedem Computer vorhanden sein, und diese Software muss Angriffen gegenüber widerstandsfähig sein. Dies bedeutet, dass die Software bei Angriffen nicht einfach versagt. Und wenn sie versagt, dass das System als Ganzes nicht auseinder fällt. Heutzutage können wir uns darüber sorgen, dass ein einzelner Bug in Windows einen Server vollständig unsicher zurücklässt, oder dass ein einzelner Bug im IIS alle Daten in .NET zugänglich macht. Heutzutage ist Microsoft-Software brüchig; sie muss widerstandsfähig werden.

Es gibt viel, das Microsoft machen kann, um die Software widerstandsfähiger zu machen, und unsere Empfehlungen könnten seitenweise fortgeführt werden. Aber allgemein gesagt sind bestimmte Features zerbrechlicher als andere. Wir empfehlen das Folgende:

Microsoft sollte alle Pläne für automatische Softwareupdates über das Internet auf Eis legen, bis sie sicher und verlässlich durchgeführt werden können. Heutzutage gibt es dabei zu viele Probleme mit Updates und Patches, als dass ihre Durchführung ohne das Wissen des Benutzers erlaubt werden könnte, und zu viele Probleme mit der Authentifizierung, um andere an der böswilligen Ausnutzung dieser Fähigkeiten für Systemangriffe zu hindern.

Microsoft sollte alle zentralisierten Kundendatenbanken in ihren .NET-Diensten entfernen. Diese Datenbanken sind zu gefährlich, um sie an einem Ort zu halten; die Auswirkungen eines Sicherheitsbruchs sind zu groß.

Microsoft ist bereits auf dem Weg, Codedateien zu signieren. Während wir empfehlen, dass Microsoft diese Praxis fortsetzt, empfehlen wir außerdem, dass Microsoft sich nicht auf die Codesignierung für die Sicherheit verläßt. Signierter Code ist nicht gleich vertrauenswürdiger Code, etwas dass die Sicherheits-Community durch die vielen ActiveX-Verwundbarkeiten graphisch demonstrierte. Microsoft sollte das Paradigma der Sicherheit durch Codesignierung zugunsten des Sandbox-Paradigmas fallenlassen.

Heutzutage laufen zu viele Microsoft Serverkomponenten als Administrator. Wenn ein Dienst als Administrator läuft, ist es wesentlich leichter, dass ein Sicherheitsfehler in einer vollständig kompromittierten Maschine resultiert. In UNIX sind Server oftmals für den Betrieb als normaler Benutzer ausgelegt. Dies sollte ebenso die Default-Konfiguration für Microsoft-Server sein.

Alle anderen Microsoft-Features sollten auf ihre Widerstandsfähigkeit geprüft werden. Alle diejenigen mit zu hohem Risiko sollten entfernt werden, bis sie neu geschrieben und gesichert werden können.

V. Transparenz und Kontrollierbarkeit

"Wenn es irgendeinen Weg gibt, wie wir wichtige Daten besser schützen und die Stillstandszeiten minimieren können, sollten wir uns auf diesen konzentrieren." --Gates Notiz.

Zu viel des Microsoft Betriebssystem arbeitet unsichtbar, ohne das Wissen des Benutzers. Zu viel davon funktioniert, ohne Aufzeichnungen über das Geschehen zurückzulassen. Mit jeder Folgeversion des Microsoft Betriebssystems ist es für einen Benutzer zunehmend schwieriger geworden, sein eigenes System zu kontrollieren oder zu untersuchen, was sein System macht. Dies hat katastrophale Auswirkungen auf die Sicherheit, und sollte rückgängig gemacht werden.

Wir empfehlen, dass Microsoft starke Kontrollmöglichkeiten in allen Produkten hinzufügt, sowohl Betriebssysteme als auch Anwendungssoftware. Wir empfehlen, dass Microsoft Konfigurationstools zusammen mit seinen Betriebssystemen zur Verfügung stellt, als auch Tools für eine IT-Abteilung zur Handhabung der Konfigurationen ihrer Computer.

Wir würden es außerdem gerne sehen, wenn Microsoft die Registry zugunsten eines weniger undurchsichtigen und benutzerfreundlicheren Systems aufgibt. Speziell die Benutzung von undokumentierten Registry-Schlüsseln, die sich bei ihrer Erzeugung auswirken; der verwirrende Punkt von Schlüsseln, die sowohl andere Schlüssel als auch Werte enthalten, macht die Entscheidung, was modifiziert werden soll, zu einer Herausforderung; und der Mangel an der Handhabung und der Rückverfolgung von Änderungen, welche es den Benutzern erlauben würden, Änderungen mit weniger Angst durchzuführen. Microsoft hat oftmals Systeme entworfen, die einladend und einfach zu benutzen sind; hier haben sie dies nicht gemacht.

VI. Veröffentlichung von Protokollen und Design im Voraus

"Es gibt viele Änderungen, die Microsoft als Firma durchführen muss, um sich des Vertrauens unserer Kunden auf jeder Stufe zu versichern und es zu erhalten - von der Weise wie wir Software entwickeln, über unsere Supportbemühungen, zu unseren Verfahrens- und Geschäftspraktiken." --Gates Notiz.

Wenn es eine Sache gibt, die Sicherheitsexperten über die Jahre gelernt haben, dann dass jedes System, wenn es erstmalig vorgestellt wird, Sicherheitsbugs haben wird. Das einzige verlässliche Gegenmittel ist es, Systemdetails früh zu publizieren und sie von der Sicherheits-Community untersuchen zu lassen. Microsoft muss Protokollspezifikationen im Voraus veröffentlichen und den öffentlichen Kommentar fördern. Dies ist doppelt wichtig für Sicherheitsprotokolle und -systeme. Wenn ein Teil der Software sicherheitskritisch ist, dann gibt es ohne Veröffentlichung keinen Weg zum Erreichen der Vertrauenswürdigkeit. Veröffentlichung garantiert nicht die Sicherheit, aber es ist im Prozess ein unausweichlicher Schritt. Wir schlagen nicht vor, dass Microsoft alle proprietären Rechte an seinen Protokollen und Schnittstellen aufgeben oder jedem die Implementierung oder Benutzung seiner Standards erlauben muss. Wir sagen, dass sie öffentlich sein müssen, nicht geheim.

Die veröffentlichten Spezifikationen müssen vollständig, lesbar und allgemein verfügbar sein. Es ist nicht ausreichend, die Spezifikationen für spezifische Forscher verfügbar zu machen, oder für Leute, die Non-Disclosures unterzeichnet oder für das Privileg bezahlt haben. Dies ist von einer Geschäftsperspektive her wiederum nicht leicht, aber wenn es Microsoft mit der Sicherheit an erster Stelle ernst ist, müssen sie die Sicherheits-Community engagieren statt sie zu ignorieren. Und Microsoft sollte warten, bevor diese Spezifikationen in Produkten implementiert werden.

Wir empfehlen, dass alle Protokolle und Schnittstellen, die in Microsoft Software benutzt werden, sofort veröffentlicht werden, und ein einjähriger Aufschub auf alle nicht die Sicherheit betreffende Modifikationen dieser Protokolle gelegt wird. Wir empfehlen außerdem, dass Microsoft alle neuen Protokolle oder Schnittstellen mindestens ein Jahr vor ihrer Implementierung in Produkten veröffentlicht.

Zusätzlich zur Veröffentlichung ihrer Protokolle und Schnittstellen schlagen wir vor, dass Microsoft die Veröffentlichung ihrer gesamten Quelltexte in Betracht zieht. Wir befürworten nicht, dass Microsoft alle seine Produkte zu Open Source macht, aber wenn sie jeden mit ihrer neugegründeten Sicherheitsreligion wirklich beeindrucken wollen, werden sie ihren Code für Untersuchungen verfügbar machen. Ehrlich gesagt erwarten wir nicht, dass Microsoft dies machen wird. Es ist ein viel zu großer Kulturwandel für sie, um es überhaupt in Betracht zu ziehen.

VII. Einbeziehung der Community

"Ausgleichspläne für Microsofts Produktingenieure, wie Gehaltserhöhungen und Sonderzulagen, werden auch davon abhängig sein, wie sicher ihre Produkte sind." --Artikel von Associated Press zur Gates Notiz, 15. Januar 2002.

Die Verknüpfung von Sicherheit an Ausgleichzahlungen ist der beste Weg, einen kulturellen Wandel innerhalb Microsofts zu bewirken. Wir finden, dass Microsoft noch weiter gehen und nicht nur Microsoft-Angestellte, sondern auch unabhängige Forscher belohnen muss. Microsoft kann unabhängige Forscher, die Verwundbarkeiten in Microsoft-Produkten finden, nicht länger bedrohen, beschimpfen oder herabsetzen.

Microsoft benötigt sowohl automatisierte Sicherheitsprüfungen als auch Bewertungen durch Sicherheitsexperten. Ein großer Teil an Arbeit auf diesem Gebiet wurde bereits außerhalb von Microsoft durchgeführt. Wir empfehlen, dass Microsoft Ressourcen für umfassende Sicherheitsprüfungen aufwendet, sowohl innerhalb als auch außerhalb der Firma. Wir empfehlen außerdem, dass Microsoft ein unabhängiges Gremium bildet, das die Sicherheitslücken bewertet, die von Forschern außerhalb der Firma gefunden werden.

Fazit

"Letztendlich sollte unsere Software dermaßen fundamental sicher sein, dass sich Kunden darüber niemals zu sorgen brauchen." --Gates Notiz.

Unsere Empfehlungen sind in keinster Weise umfassend. Es ist wesentlich mehr mit der Entwicklung sicherer Software verbunden als die sieben Punkte, die wir hier aufgezählt haben. Diese Punkte sind als kurzfristige Meilensteine gedacht; es sind mehr der Implementierung als der Architektur zugeordnete Empfehlungen. Buffer Overflows, jedermans liebster Prügelknabe, sind ein vergleichsweise einfach zu beseitigendes Problem auf der Implementierungsebene. Höherstufige Konstrukte, wie die Implementierung einer Scripting-Engine oder die Sicherung von Interprozess-Kommunikation, sind kompliziertere Probleme auf der Designebene. Aber wenn Microsoft nicht mit den einfacheren Sachen beginnt, werden sie niemals zu den schwierigen Sachen vorstoßen.

Sicherheit ist weder einfach noch ist es etwas, dass man nach den Fakten an einem Produkt anschrauben kann. Die Sicherheit zu Microsofts erster Priorität zu machen erfordert eine grundlegende Umstrukturierung der Art und Weise, wie die Firma Software produziert und vermarktet. Es wird einen schwierigen kulturellen Übergang innerhalb Microsofts beinhalten. Es wird beinhalten, dass Microsoft kurzfristige Erträge beiseite lässt, um langfristige Ziele zu erreichen. Es ist ein schwieriges Ziel, und wir glauben, dass Microsoft es erreichen kann. Wir hoffen, dass sie ihm verpflichtet bleiben.

Amüsante Kommentare:
<http://slashdot.org/comments.pl?sid=26890&cid=2901270>
<http://slashdot.org/comments.pl?sid=26890&cid=2901649>

Dieses Essay wurde zusammen mit Adam Shostack verfasst. Kommentare wurden von Steve Bellovin, Jon Callas, Crispan Cowan, Greg Guerin, Paul Lalonde, Gary McGraw, David Wagner und Elizabeth Zwicky zur Verfügung gestellt. Es erschien ursprünglich bei Security Focus:
<http://www.securityfocus.com/news/315>

Crypto-Gram Reprints

Hard-drive-embedded copy protection:
<http://www.schneier.com/crypto-gram-0102.html#1>

A semantic attack on URLs:
<http://www.schneier.com/crypto-gram-0102.html#7>

E-mail filter idiocy:
<http://www.schneier.com/crypto-gram-0102.html#8>

Air gaps:
<http://www.schneier.com/crypto-gram-0102.html#9>

Internet voting vs. large-value e-commerce:
<http://www.schneier.com/crypto-gram-0102.html#10>

Distributed denial-of-service attacks:
<http://www.schneier.com/crypto-gram-0002.html#DistributedDenial-of-ServiceAttacks>

Publicizing vulnerabilities:
<http://www.schneier.com/crypto-gram-0002.html#PublicizingVulnerabilities>

Recognizing crypto snake-oil:
<http://www.schneier.com/crypto-gram-9902.html#snakeoil>

News

Das Web wird immer verwundbarer gegen Angriffe und Viren. Sicherheitsmaßnahmen werden durch neue Bedrohungen ständig überholt.
<http://www.ananova.com/news/story/sm_501457.html>

Bestimmung der Sicherheitsrisiken im Internet:
<http://zdnet.com.com/2100-1105-819713.html>

Guter Artikel zu Überwachungsmaßnahmen im Kielwasser des 11.09.:
<http://www.latimes.com/news/nationworld/nation/la-011902techshift.story>

SatireWire zur Microsoft-Aufspaltung. Lustiger Stoff.
<http://www.satirewire.com/news/jan02/patchsoft.shtml>

Die Regierung als Angstverkäufer. Das FBI warnt Strafverfolger und High-Tech Firmen, vor möglichen terroristischen Aktivitäten auf der Hut zu sein, die das Internet benutzen oder betreffen könnten. Dies könnte zu einer zufälligen Zeit und an einem zufälligen Ort geschehen. Sinngemäß möchte das FBI, dass sich jeder Sorgen macht, aber sie sind nicht sicher über was.
<http://www.usatoday.com/life/cyber/tech/2002/01/17/net-warning.htm>

Langes und interessantes Interview mit Gene Spafford über die InfoSec-Bedrohungslandschaft; Privatsphäre; die Herausforderungen von digitalen Zertifikaten, CRLs, Public Key Infrastruktur-Standards und Interoperabilität; Schlüsselhinterlegung, -sicherung und -wiederherstellung; Identitätsbetrug; Vertrauen im Internet; und die Probleme der heutigen Sicherheitsausbildung. Beispielzitat: "Sicherheit funktioniert nicht als Zusatz. Sie muss wirklich von Anfang an mit eingebaut werden."
<http://pkiforum.com/books/interview_spafford.html>

12% aller Online-Datenbanken wurden 2001 gebrochen. Zumindest ist es von 12% bekannt, dass sie gebrochen wurden. Wer weiß was über die anderen?
<http://www.newsbytes.com/news/02/173832.html>

Sollte es ungesetzlich sein, unsichere Software-Produkte zu produzieren?
<http://news.bbc.co.uk/hi/english/sci/tech/newsid_1762000/1762261.stm>
<http://slashdot.org/articles/02/01/16/1534252.shtml>

Sollten Software-Firmen für unsichere Software-Produkte haften?
<http://news.com.com/2100-1023-821266.html>
<http://www.zdnet.com/anchordesk/stories/story/0,10738,2845286,00.html>

Das 2600 Magazin fechtet die DeCSS-Entscheidung an:
<http://zdnet.com.com/2110-1104-814246.html>

Sicherheitspatches von Microsoft verursachen manchmal mehr Probleme als sie lösen.
<http://www.eweek.com/article/0,3658,s%3D701%26a%3D21023,00.asp>
Dies ist etwas, von dem man in Microsofts neuem Sicherheitsschwerpunkt, möglichst sofort, die Beseitung erwarten sollte. Dies ist auch einer der Gründe, weshalb der automatische Download und die automatische Installation von Patches eine schlechte Idee ist.

Exzellentes Essay vom letzten Oktober über Microsoft und schlechtes (unsicheres) Softwaredesign. Der Autor teilt mir mit, dass der originale Titel "Arroganz der Entwickler und Buffer Overflows" lautete, der das Feeling des Essays ein wenig besser trifft.
<http://www.osopinion.com/perl/story/14306.html>

Letzten Sommer behauptete Microsoft, dass sie alle Buffer Overflows in Windows XP ausrotteten.
<http://www.pcweek.co.uk/News/1125281>
<http://www.theregister.co.uk/content/archive/21316.html>

Hier ist ein Beispiel eines Hacks, der eine Firma dazu bringt, ihr Geschäft aufzugeben. Cloud Nine, ein britischer ISP, stellte seine Tätigkeiten diese Woche ein, nachdem sie das Opfer eines DOS-Angriffs wurden. Das Netzwerk müsste als ein Ergebnis des Angriffs neu aufgebaut werden, und die Versicherung der Firma würde die Reparaturen nicht decken.
<http://www.ispreview.co.uk/cgi-bin/ispnews/viewnews.cgi?newsid1011696274,91619,>
<http://www.ispreview.co.uk/ispnews/comments/1011716173,95410,.shtml>
<http://www.wired.com/news/business/0,1367,50171,00.html>

Wirklich interessante Anekdote über die Verbreitung der Gelegenheitspiraterie bei Software:
<http://www.AmbrosiaSW.com/cgi-bin/ubb/newsdisplay.cgi?action=topics&number=14&article=000052>

Clevere Masche zum Identitätsdiebstahl. Das Opfer erhält eine E-Mail mit der "Bestätigung" einer eBay-Bestellung und dem Hinweis, dass die Kreditkarte des Opfers belastet wird, sofern es nicht storniert. Die Stornierungs-Webseite fragt nach allen möglichen persönlichen Informationen: Kreditkartennummer, Sozialversicherungsnummer, Bankname, Adresse, Telefon, etc. Es liegt eine andere Gerissenheit darin, wie die Daten geerntet werden.
<http://www.newsbytes.com/news/02/173962.html>

Gutes Essay zu Software-Sicherheit:
<http://www.securityfocus.com/infocus/1541>

Der Atlantic, im Allgemeinen ein gutes Magazin, veröffentlichte ein furchtbares Essay über unknackbare Verschlüsselung und ihre Auswirkungen auf eine Terroristen-gefüllte Welt. Der Autor verfehlt völlig den Punkt, dass Sicherheit mehr als mathematische Verschlüsselung ist und die Sicherheitsfehler öfter im Vorgehen als in der Mathematik liegen. Der Autor sagt es sogar an einer Stelle: "Signal Intelligence ist natürlich nicht völlig tot." Aber dann fährt er fort, ohne sich seiner Untertreibung bewußt zu sein.
<http://www.theatlantic.com/issues/2002/02/budiansky.htm>

"Ich habe niemals, jemals, gesagt dass ich total, oder zumindest meistens, ein komplett Unschuldiger war." -- Kevin Mitnick
<http://www.wired.com/news/politics/0,1283,50298,00.html>

Hier steht, wie die Erweiterung der elektronischen Identität den Terroristen hilft. Sie begehen ebenfalls Identitätsdiebstahl.
<http://www.boston.com/dailyglobe2/031/nation/Terror_link_seen_in_identity_thefts+.shtml>

Counterpane News

Bruce Schneier spricht auf einer Senatsanhörung zur CyberSicherheit am 14. Februar im US-Capitol. Die Öffentlichkeit ist eingeladen.
<http://www.counterpane.com/pr-briefing.html>

Bruce Schneier spricht auf der RSA Konferenz zu drei Zeiten:
Sein Hauptvortrag: "Fixing Network Security by Hacking the Business Climate" Mittwoch um 8:00 Uhr.
Schneier moderiert das Cryptographer's Panel, Dienstag um 10:45 Uhr.
Schneier nimmt an einem Ausschuss zur Sicherheitshaftung teil (dies wird interessant werden) am Freitag um 8:00 Uhr.

Schneier gibt eine Präsentation zu Counterpanes Managed Security Monitoring-Diensten in einigen Städten: San Jose (20.02.), DC (25.02.), Detroit (26.02.), Honolulu (08.03.), Phoenix (12.03.), San Diego (13.03.), Philadelphia (14.03.), Chicago (20.03.), New York (22.03.) und Boston (26.03.). Wenn Sie an der Teilnahme interessiert sind, besuchen Sie bitte:
<http://www.counterpane.com/seminars.html>

Counterpane vermeldet starken Umsatz für 2001:
<http://www.counterpane.com/pr-growth.html>

Counterpane hat einige neue Wiederverkäufer bekanntgegeben:
<http://www.counterpane.com/pr-cr.html>

Exzellentes Radiointerview mit CEO Tom Rowley:
<http://www.counterpane.com/pr-ceocast.html>

Oracles "unknackbare" Datenbank

Letzten November startete Oracle mit der Bewerbung ihrer Sicherheit in einer "Unknackbar"-Anzeigenkampagne und dem Slogan: "Oracle9i. Unknackbar. Sie kann nicht geknackt werden. Es kann nicht eingebrochen werden." Dies war eine aberwitzige Behauptung, aber ich entschied mich zu warten, bis sie tatsächlich geknackt war, bevor ich darüber schreibe.

Nun, sie ist geknackt worden. An mehreren Stellen. Unter der Benutzung einiger netter elementarer Angriffe. Unknackbar, das ist sie nicht.

Auf der einen Seite wußte ich (und die meisten, die diesen Newsletter lesen) das schon immer. Wir wußten, dass die Behauptungen übertrieben waren. Wir wußten, dass die Marketingabteilung von Oracle die Unwahrheit sagte. Aber es ist ein trauriger Kommentar über den Zustand des Sicherheitsdiskurses, dass Oracle nicht auf der Stelle aus dem Raum herausgelacht wurde. Oracle9i wird niemals unknackbar sein, solange die Firma keine größeren Änderungen an den Design- und Entwicklungsprozessen ihrer Software durchführt.

Auf der anderen Seite ist es vielleicht nicht nur Anmaßung. Vielleicht hatte das Oracle-Management tatsächlich geglaubt, dass ihr Produkt unknackbar war. Vielleicht sind sie in Sicherheitsfragen derart ohne Anhaltspunkte. Wenn das der Fall ist, dann liegen die Probleme tiefer als es den Anschein hat. Wenn man glaubt, das eigene Produkt ist unknackbar, dann ist das Problem, dass man sich nicht um die gründliche Sicherung kümmert. Wenn man glaubt, dass die eigenen Wände undurchdringbar sind, dann behelligt man sich nicht mit Wachen, Alarmanlagen und irgendwas anderem. Dies ist mit Oracle9i der Fall. Die Angriffe übernehmen die Datenbank komplett. Sobald der Angreifer die "unknackbare" Sicherheit geknackt hat, gibt es dort nichts mehr, das ihn stoppt.

Im Versuch zurückzurudern hat Oracle gesagt, dass "unknackbar" nicht bedeutete, was normale Leute diesem Wort an Bedeutung zumessen würden. Oracles Sicherheitschef, Mary Ann Davidson, führte an, dass die Kampagne vierzehn unabhängige Sicherheitsbewertungen "anspricht", die Oracles Datenbank bestand. Dies ist für mich hier die wirkliche Story. Wofür ist eine Sicherheitsbewertung gut, wofür sind VIERZEHN verschiedene Sicherheitsbewertungen gut, wenn keine von ihnen so etwas wie einen trivialen Buffer Overflow entdeckt? Sicherheit ist schwer. Das kann man sich als eine Kette vorstellen; jedes einzelne schwache Kettenglied kann die Kette auftrennen. Buffer Overflows sind ein offensichtliches Kettenglied: leicht zu vermeiden, leicht herauszutesten, leicht zu beseitigen. Die Beseitigung aller Buffer Overflows macht eine Software nicht sicher; es ist der Eintrittspreis. Die schweren Sachen sind wirklich schwer.

Also versuchte ich, die vierzehn unabhängigen Sicherheitsbewertungen zu finden. Ich wollte mich darüber lustig machen: "Guckt Euch diese vierzehn Sicherheitsbewertungen an, die nicht einmal Buffer Overflow-freien Code garantieren können." Bedauerlicherweise konnte ich nur fünf finden: TCSEC, ITSEC, Common Criteria, Russian Criteria und FIPS 140-1. Das Oracle Marketing hat fünf in vierzehn verwandelt, indem sie mehrere Stufen von TCSEC und ITSEC als unabhängige Sicherheitsbewertungen zählten, und identische Bewertungen von verschiedenen Oracle-Produkten als unabhängige Sicherheitsbewertungen zählten. Ich weiß nicht, wie es mit Ihnen ist, aber wenn ich "vierzehn verschiedene" höre, denke ich nicht, dass es "fünf verschiedene, einige von ihnen mehrfach mit verschiedenen Produkten oder verschiedenen Stufen" meint. Sieht so aus, dass Oracle Schwierigkeiten mit der Mathematik wie auch mit Englisch hat.

"Unknackbar" hat eine Bedeutung. Es bedeutet, dass es nicht geknackt werden kann. Es bedeutet nicht "Unknackbar, außer durch Leute die wissen wie man Dinge knackt." Es bedeutet nicht "Besteht fünf oder so fragwürdige Sicherheitsbewertungen, ist aber weiterhin durch Buffer Overflows verwundbar." Es ist mir egal, wer Larry Ellison ist; er kann nicht das Wörterbuch neu schreiben.

Die Bruchstellen:
<http://www.securityfocus.com/columnists/45>

Oracles Zurückrudern:
<http://www.securityfocus.com/news/309>
<http://www.businessweek.com/bwdaily/dnflash/jan2002/nf20020115_8894.htm>

Oracles "vierzehn" Sicherheitszertifikate:
<http://www.oracle.com/ip/deploy/database/oracle9i/index.html?se_dbcomp.html>

Leserkommentare

<http://www.schneier.com/crypto-gram-0202.html#7>

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.