Fast alle Hacker weltweit machen begeistert bei dem Projekt distributed.net mit. Ich denke wir sollten uns eine kritischere Einstellung zu diesem Projekt aneignen.

Das distributed.net Projekt

distributed.net ist eine Aktion, um zu beweisen, daß die heute eingesetzten Verschlüsselungsverfahren unsicher sind. Primär wendet sich distributed.net gegen die Algorithmen DES und RC5. Der Beweis, das diese Verschlüsselungssysteme nicht hinreichend sicher ist, soll dadurch erreicht werden, daß einzelne, mit DES bzw. RC5 verschlüsselte Nachrichten, entschlüsselt werden. Dies geschieht, indem einfach alle Schlüssel durchprobiert werden, bis beim entschlüsseln eine sinnvolle Nachricht herauskommt. Ein nicht sonderlich intelligentes Verfahren, aber vermutlich bei einigen Verschlüsselungsalgorithmen die einzige Möglichkeit, an den Inhalt einer verschlüsselten Nachricht zu kommen.

Da ein einzelner Rechner sehr lange brauchen würde, um alle Schlüssel durchzuprobierten, müssen mehrere Rechner sich die Arbeit teilen. Und da es sich um sehr viel Arbeit handelt, müssen sich sehr viele Rechner die Arbeit teilen. Um diese Arbeitsteilung möglichst komfortabel zu machen, hat distributed.net eine Software entwickelt, die oft als rc5des bezeichnet wird.

Im groben sieht das Prinzip dieser Software so aus: Jeder, der teilnehmen will installiert eine sogenannte Client-Software auf seinem Computer. Dieser rc5des Client ist für sehr viele unterschiedliche Computer und Betriebssysteme erhältlich. Der Client verbindet sich dann zu einem distributed.net Server und meldet sich zum Arbeitsantritt. Er bekommt dann einen Block Schlüssel zugeteilt, die er auszuprobieren hat. Der Client probiert dann die im zugewiesenen Schlüssel durch, was einige Minuten bis viele Stunden dauern kann. Dabei läuft er im Hintergrund mit niedriger Priorität, so daß er die normale Arbeit an dem Computer, auf dem er läuft, kaum behindert. Praktisch arbeitet er nur, wenn der Computer nichts anderes zu tun hat. Den Windows Client kann man sogar so konfigurieren, daß man nicht sehen kann, daß er läuft.

Wenn der Client mit seinem Block Schlüssel durch ist, meldet er sich wieder bei einem der distributed.net Server, sagt daß er fertig ist und fordert einen neuen Schlüsselblock an. Um die Verbindung zum Server auch aus stark gesicherten Netzwerken zu ermöglichen, verfügt der rc5des Client zum einen über die Möglichkeit die Daten über allerlei esoterische Wege an Firewalls vorbeizutunneln, zum anderen gibt es einen Proxyserver, mit dem man auch an Firewalls und privaten IP-Adressbereichen vorbei arbeiten kann.

Was distributed.net da macht ist also ganz schön spannend: Die eh nicht genutzte Rechenzeit auf tausenden Rechnern weltweit für einen guten Zweck einsetzen. Meta-Computing wird das ganze auch genannt. Eins ihrer Mottos ist "Cryptographie sicherer machen, indem man sie bricht". Dadurch, daß bewiesen wird, daß manch Verschlüsselungssysteme gebrochen werden können, hoffen sie, die Industrie dazu zu bewegen, nur noch sicherere Algorithmen einzusetzen.

Probleme mit distributed.net

Also alles schön und gut? Nein, meiner Meinung nach ist distributed.net böse. Die Ziele, die distributed.net anstrebt sind sicher ehrenwert, aber die Methode die sie dazu anwenden ist falsch. Und das falsche läßt sich in einem Satz zusammenfassen: Die Software ist nicht im Quelltext erhältlich.

Warum das ein Problem sein soll? Jedem, der sich nochmal die Features des rc5des Clients oben ansieht, sollte klar sein warum das so ist. Da wird verlangt eine Software zu installieren, die mit irgendwelchen Servern im Internet kommuniziert und dabei in der Lage ist, an den meisten Firewalls und anderen Sicherheitssystemen vorbei Daten zu übertragen. Diese Software ist obendrein auch noch in der Lage, sich zumindest unter Windows einigermaßen wirkungsvoll vor dem Benutzer zu verstecken.
Und eine solche Software soll man installieren, ohne den Quellcode zu haben, um nachzuschauen, was dieses Programm wirklich macht?

Möglich wäre doch beispielsweise, das das Programm ungefragt und unentdeckt Informationen aus dem eigenen Computer herausschafft. Oder auch schlichtweg, daß es bei der Angabe, wer da rechnet manchmal etwas pfuscht. Schließlich gibt es einen bedeutenden Geldpreis für den, der den richtigen Schlüssel findet. Woher soll ich wissen, daß das Programm sich bei mir meldet und den Schlüssel nicht einfach klammheimlich 'rausschmuggelt und ich nichts von dem Gewinn abbekomme.
Und selbst wenn man davon ausgeht, das die Programmierer von rc5des integere Menschen sind, wer stellt sicher, daß sie keine Fehler bei der Programmierung gemacht haben, die dazu führen, daß der rc5des Client von dritten zu irgendwelchen bösen Zwecken eingesetzt wird?

Obskures Sicherheitsverständnis

Warum gibt distributed.net den Quellcode für ihren Client nicht heraus? Erstaunlicherweise wird das mit "der Sicherheit" begründet. Wenn jeder den Quellcode für den rc5des Client hätte, könnten böse Menschen rc5des so modifizieren, daß er gar nicht die ihm zugeteilten Schlüssel ausprobieren würde, sondern sie einfach als ausprobiert zurückmelden würde, ohne lange 'rumzurechnen. Das würde natürlich wesentlich schneller gehen, so dieser böse Mensch in der Statistik wesentlich weiter oben erscheinen würde. Er hätte allerdings nie die Chance zu gewinnen, da er ja nicht den richtigen Schlüssel finden kann, weil er gar nicht überprüft, ob unter den ihm zugeteilten Schlüsseln der richtige ist.
Das ganze könnte den Erfolg von distributed.net empfindlich gefährden, denn es wäre theoretisch möglich, daß zufällig in den dem Betrüger zugeteilten Blöcken der richtige Schlüssel lag. Da dieser die Schlüssel ja nicht ausprobiert, sondern sie einfach so als fertig zurückmeldet, würden sie in der distributed.net Datenbank als erfolglos getestet vermerkt und somit nicht weiter überprüft. Somit hätte distributed.net keine Chance, die richtigen Schlüssel zu finden.

Die Ängste, die bei distributed.net vorhanden sind, klingen zunächst plausibel und doch sind sie meiner Meinung nach böse. Sie sind derartig naiv und fördern eine ungemein falsche Denkweise, daß man sie nur als böse bezeichnen kann.

Warum? Die Denke der distributed.net Leute beruht auf der der Annahme, es gäbe "Security by Obscurity". Sie denken, wenn sie das ganze nur undurchschaubar genug machen, in dem sie den Quellcode nicht herausgeben, würde das ganze sicher werden. Dies ist ein auch in der Industrie sehr verbreiteter Irrglaube. Und dieser Irrglaube ist böse, weil er zunächst so ungemein einleuchtend klingen kann und daher schon sehr viel Schaden angerichtet hat. Denn praktisch bietet dieser Ansatz kaum zusätzliche Sicherheit.

Die Hackercommunity verbringt sehr viel Zeit und Nerven darauf, der Industrie beizubringen, daß sie offene Modelle nutzen muß, wenn sie wirklich sichere Produkte erstellen will. Über die letzten Jahre haben wir auf diesem Gebiet schrittweise Erfolge erzielen können.

Und jetzt gibt es da eine Gruppe daher, die beweisen will, daß man bessere Verschlüsselung nutzen muß und dabei ihren eigenen Code durch "Security by Obscurity" zu schützen versucht. Das wirft unser Bemühen, dieses windige Sicherheitskonzept ein für alle mal zurückzudrängen ein ganzes Stück zurück.

Pfuschen auch ohne Quellcode

Das der rc5des Client ohne Quellcode nicht wesentlich sicherer ist, als mit Quellcode, ist ein gutes Beispiel, wie "Security by Obscurity" versagt. Wenn er den Quellcode hätte, könnte ein Schuft diesen so modifizieren, daß nicht wirklich irgendwelche Keyblöcke berechnet werden, sondern diese einfach so als fertig gemeldet werden (s.o.). Dafür müßte er allerdings in der Lage sein, den hoch optimierten Code des rc5des Clients zu verstehen.

Was für Möglichkeiten bleiben einem Schuft, wenn er nicht den Quellcode besitzt? Er kann die Buffer-files, in denen rc5des seine Daten speichert, analysieren und dann zu seinen Gunsten modifizieren. Er könnte auch das Protokoll, über das der rc5des Client mit dem Server kommuniziert, analysieren und dann ein Programm schreiben, welches sich dem Server gegenüber als normaler Client tarnen, ohne jemals etwas zu berechnen.

Was für unseren Schuft aber sicher am leichtesten wäre, ist es, den rc5des Client so zu patchen, daß er einfach nicht mehr rechnet, sondern nur Blöcke als fertig meldet. Um dies zu erreichen muß er nur eine einzige Assembler-Anweisung patchen, nämlich die Schleife um die DES-Berechnung. Diese ist aufgrund des stark optimierten Codes in rc5des besonders einfach unter dem Debugger auszumachen. Für jeden, der sich schon mal ernsthaft an fremdem Code 'rumgepatcht hat, sollte das wirklich kein Problem sein.

Im c4 ist es uns in kürzester Zeit gelungen, diesen Patch durchzuführen. Wenn wir das können, können andere das auch. Es zeigt sich also, daß der rc5des Client auch ohne Quellcode ungemein anfällig gegen Manipulationen ist. Das Sicherheitsargument für die Nichtfreigabe des Quellcodes zieht also nicht.

Was tun?

Mit diesem Sachverhalt ist nicht einfach umzugehen. Generell sind die Ziele von distributed.net ja durchaus unterstützenswert. Soll man jetzt keine rc5des Clients mehr laufen lassen?
Ich denke, das Ziel darf nicht der Abbruch des distributed.net Projekts sein, sondern die Freigabe des Quellcodes. Um dies zu erreichen sollte man auf die Zugänglichkeit von distributed.net für rationale Argumente hoffen. Es bleibt nur zu hoffen, daß man nicht den einen Pfusch-Patch für rc5des als Argumentationshilfe freigeben muß.

Ich kann somit jeden, der einen rc5des Client betreibt, empfehlen, bei distributed.net den Quellcode einzufordern. For the sake of the code.

Doobee R. Tzeck