[HaBo]

hummel

Anzeige

Hallo zusammen!

Ich bin hier zwar noch ganz neu, wende mich aber schon mit einem ziemlich speziellen Problem an euch Cracks:

Seit einiger Zeit bin ich daran, ein Konzept für ein neuartiges anonymes P2P-Netzwerk auszuarbeiten und spiele sogar mit der Idee, es eines Tages zu implementieren. Letzeres ist allerdings aufgrund meiner doch eher bescheidenen Programmierkenntnisse (als ehemaliger Hobby-TB/Delphi-Programmierer) noch recht utopisch. Aber mal sehen.

Da meine Idee ziemlich komplex und noch nicht bis ins letzte Detail ausgearbeitet ist, erspare ich mir hier eine Beschreibung des Systems und verweise auf meine Posts unter http://board.planetpeer.de/index.php....msg25108.html ab #msg25108. Es ist aber überhaupt nicht nötig, sich da hineinzulesen, denn meine Frage betrifft nur einen Aspekt des ganzen.

Das Problem ist ein grundsätzliches und stellt sich eigentlich bei jeder Anonymisierungs-/Verschlüsselungsalgorithmus: Ein System sollte nämlich opensource sein, um von den Benutzern/Experten akzeptiert zu werden. Jedoch ist es viel schwieriger, hohe Anonymität/Sicherheit herzustellen, wenn der Angreifer die Möglichkeit hat, den gesamten Quellcode einzusehen.

Mein Konzept lässt sich, wie auch andere aP2P-Systeme, im Grunde genommen auf zwei Arten angreifen:
1) man bricht die Anonymität der Teilnehmer
2) man legt das System lahm, ohne jedoch die Identität der Teilnehmer aufzudecken

Mich interessiert hier nur Problem 2), welches seinerseits in zwei Varianten auftreten kann:
a) simple DDos-Attacke: der Feind verwendet zwar den Original-Client, aber auf missbräuchliche Art. Er setzt also z.B. eine Vielzahl von (virtuellen) Knoten auf und bricht die Verbindung zu den anderen Knoten in regelmässigen Abständen ab, um diese aus dem Rhythmus zu bringen
b) Attacke mit manipuliertem Client: Der Feind verwendet manipulierte Clients, um gefälschte Messages verschicken usw.

b) ist natürlich viel gefährlicher als a), und bereitet mir daher mehr Kopfzerbrechen.

Als Lösung habe ich mir folgendes ausgedacht; ich bin mir aber nicht sicher, ob es wirklich etwas bringt:

- Anstatt den Client komplett opensource zu veröffentlichen, wird dieser nur zu 99% offengelegt. D.h. der eigentliche Client ist zwar komplett offen, das verwendete Protokoll wird in einem Punkt aber verdunkelt: Jedes Kommando/Message, welches zwischen zwei Knoten versendet wird, erhält eine eindeutige Signatur (Hashwert).
Dieser Hashwert ist aber nicht einfach ein SHA-1 oder MD5-Wert, sondern eine möglichst diffuse Kombination von verschiedenen Hashverfahren (inkl. XOR mit Zufallswerten). Der Empfänger-Knoten, dem der gleiche Hashgenerator ebenfalls zur Verfügung steht, akzeptiert nur Messages/Kommandos, deren so generierte Signatur zum Inhalt passt.

- Der Hashgenerator wird nun in eine separate Anwendung ausgelagert, die zuerst gestartet werden muss. Der dazugehörige Sourcecode bleibt natürlich geheim. Am besten wird die ausführbare Datei noch mit EXECryptor und dgl. zusätzlich verschleiert. (Gibt es hierfür bessere Alternativen?)

- Der Hashgenerator kennt den Hashwert der ausführbaren Client.Exe-Datei und führt letzere nur dann aus, wenn diese der genauen Vorgabe entspricht. Nur wenn der unveränderte Client-Sourcecode auf die exakt vorgegebene Weise mit dem vorgegebenen Compiler kompiliert worden ist, wird der Client also ausgeführt.

- Beim Start übergibt der Hashgenerator dem Client einen Zufallswert (z.B. via lpCommandLine der CreateProcess()-Funktion)

- Der Client erstellt unter Zufallswert.msg eine Datei und hält sie dauernd für den Schreib- und Lesezugriff offen. Besteht schon eine solche Datei (konkret: hat der Hacker/Angreifer den Zufallswert abgefangen und die Datei zuerst erstellt), killt sich der Client selbst.
Ansonsten, also im Normalfall, schreibt der Client die zu verschickenden Messages in die Datei, wo sie vom Hashgenerator ausgelesen werden können.

- Der Hashgenerator erzeugt die Signatur der jeweiligen Message und sendet diese dem Client (über interprocess communication), der daraufhin die signierte Message dem Empfängerknoten sendet.

- Ausserdem prüft der Hashgenerator in regelmässigen Abständen, ob der Client noch am Laufen ist (mit GetExitCodeProcess() ). Ist der Client tot (resp. durch den Angreifer lahmegegt worden), killt sich der Hashgenerator selber.

Nun meine Frage: Ist dieses Vorgehen (einigermassen) sicher und überhaupt sinnvoll?

Oder ist es für einen richtigen Hacker ein leiches, eine Anwendung (d.h. den Client) während der Laufzeit so zu manipulieren resp. blockieren, dass diese sich nicht mehr selber terminieren kann, sollte der Angreifer die besagte Cache-Datei zuerst erstellt haben. (Dazu muss der Angreifer aber zuerst mal die interprocess communication abhören können. Was bietet sich da als besonders abhörsicher an?)

Manipulationen, die der Angreifer allenfalls unter Durchbrechung der Datenzugriffsrechte an der Cache-Datei vornehmen könnte, spielen hier keine Rolle. Denn der Client könnte ja den Inhalt immer kontrollieren und sich bei Unregelmässigkeiten wiederum selber terminieren. Da stellt sich aber letztlich wieder dasselbe Problem: Ist es möglich, Anwendungen zur Laufzeit so zu manipulieren, dass sie von Aussen her immer noch als lauffähig erkannt werden? Oder wird dies durch den Protected Mode wirksam verhindert?

fetzer

Anonymität hat nichts mit Sicherheit zu tun. Schau dir Tor als Beispiel an: Der Anfangs- und Endknoten können Plaintextpakete ohne Probleme mitschneiden. Bei Anonymität geht es nur darum, den Empfänger und den Sender zu verbergen und nicht die Daten zu verifizieren oder für Dritte zu verschlüsseln. Sollten Geschäftsdaten verschickt werden, die vor anderen geschützt werden müssen, können sich die beiden Parteien ja kennen, hier ist es ja nicht schlimm. Letztendlich entsteht durch die Verschlüsselung nur weiterer Ressourcenverbrauch, sofern es sich um "unwichtige" Daten handelt.

Ach quatsch. Auch Windows ist von genügend Benutzerun und Experten angesehen und legt seinen Code nicht frei.
OpenSSH und Co sind ja auch relativ unsicher

Dein Problem sehe ich gerade, beim Überfliegen der Beschreibung, eher in (1) als in (2).:
Direkter Download der Datenblöcke heisst für mich, dass eine direkte Verbindung von Interessierten zum Anbieter hergestellt wird. Hier reicht ein einfaches netstat ausserhalb deiner Anwendung um die Anonymität beider Parteien zu brechen. Genauso kannst du zwischen zwei DSL-Usern keine hohen Geschwindigkeiten herstellen. Sollte der eine dir 5kb/s Geschwindkeit zur Verfügung stellen wirst du nicht schneller als 5kb/s downloaden.

Gefälschte Pakete wirst du immer in einem Netz haben. Die Frage ist, wie du damit umgehst. Wenn du dein Protokoll auf TCP aufbaust wirst du zwar einen recht großen Overhead bekommen, allerdings hast du schon von Haus aus ein recht wirksames Mittel gegen Spoofing, nämlich die Sequenznummern. Wer welche Messages senden darf solltest du auch vorher bestimmen und etwa von anderen Knoten speichern lassen. Dadurch entstehen redundante Datenbanken (d.h. diese werden auch nicht zerstört, sollte ein Knoten offline gehen), in denen Rechte oder beispielsweise auch Tickets gespeichert werden können.

Zufallswerte, die auf beiden Rechnern gleich erzeugt werden? Eine plumpe Aneinanderreihung von Hashverfahren ist nur unnötig verbrauchte Rechenleistung und bringt meines Wissens keinerlei Sicherheitsgewinn (korrigiert mich bitte, sollte das nicht stimmen...)
Ich hätte eine andere Möglichkeit hier vorzuschlagen: Da ja die Dateien auf versch. Knoten ausgelagert werden könnte man eine MD5 oder Sha-1-Signatur von einem anderen Knoten anfordern und die empfangenen Daten damit vergleichen. Dann musst du entscheiden, ob du den Teil noch einmal anforderst, oder ihn von einem anderen Knoten beziehen willst. Sollte dies bei einem Clienten mehrere Male vorkommen kannst du ihn als potentiellen Störfaktor identifizieren.

Viel zu viel Arbeit

Alte Clienten passen so nicht mehr mit dem Hashgenerator zusammen - Probleme vorprogrammiert.

Ich muss jedoch zugeben: Letztendlich verstehe ich dein ganzes System nicht, bzw. kenne mich auch nicht wirklich damit aus.

CDW

da es schon spät ist und fetzer mittlerweile (während ich es las) schon geantwortet hat:
kommt auf die Methode an - i.R schon. Vor allem da der Client OpenSource ist, wird man auch ausgeklügelte "Frage-Anwort" Spiele zwischen dem Hashgenerator und dem Client schnell erkennen. Wobei solche "komplexen" Handlungen nicht nötig sein sollten ->

so wie ich es verstehe, basiert das ganze darauf, dass der Hashgenerator "sicher" bleibt.
Hier kann ich Dir sagen: es bringt nichts. Du darfst alles was Du magst darauf anwenden (ExeCrypter usw). Es läuft aber auf 2 Möglichkeiten hinaus:

1)Hashgenerator durch EigencodE/ExeCrypter&Co geschützt (Schutz also nur auf Anwendungsebene). Die Anwendung arbeitet also letzendlich immer noch mit API Funktionen -> ruft Funktionen aus Systemdlls auf. Demnach wird es mit relativ wenig Mühe möglich sein, entweder dem Create/OpenFile oder CreateProzess Aufruf einen falschen Dateipfad unterzujubeln.Dazu wird man sich nur wenig bis gar nicht mit dem jeweiligen Schutz der Anwendung und der Hashverschleierung auseinandersetzen müssen. Eine DLL Injektion mit einem Hook auf CreateFile/OpenFile/CreateProcess oder schon ein simpler Loader, der ein wenig rumpatcht, sollten reichen. Dabei wird man nicht direkt die Anwendung manipulieren, sondern die jeweilige SystemDLL Kopie (hier: KERNEL32.DLL) im Speicher der Anwendung, wo der Schutz nicht mehr greift.
Der Hashgenerator wird also die Originaldatei prüfen, aber eine falsche/manipulierte starten. Der Trick ist nicht neu und wurde schon langer z.B bei Patches von ASPro/ExeCrypter/usw geschützen Anwendungen verwendet (ist relativ naheligend, falls CRC Checks der Anwendung gut versteckt sind).

2) abartiger Treiberschutz, der entweder tief im Kernel wühlt (viel Aufwand+noch mehr Testaufwand für XP/2k/2k3/Vista) oder direkt auf die Festplatte zugreift (noch vieel mehr Aufwand wegen NTFS Format+die üblichen Tests ). Kann mit etwas Fantasie wohl immer noch umgangen werden (vielleicht nicht mehr ganz so einfach ) - aber die meisten User würden sowas wohl eher nicht akzeptieren (Systemstabilität/Datensicherheit gefährdet ). Dann kann man die Idee mit OpenSource auch gleich lassen.

__________________
Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf!
Selig, wer nichts zu sagen hat und trotzdem schweigt.

hummel

Danke @fetzer und CDW für die schnelle Antwort!

Das stimmt schon. Allerdings geht es mir hier nicht um Sicherheitsprobleme wegen unachtsamer Benutzer, die ihre persönlichen Daten preisgeben. Mich interessiert vielmehr, wie man ein anonymes Netz ausfallsicher machen kann.

Betriebssysteme und anonyme Netze sprechen ganz verschiedene Klientele an. Letztere werden vor allem von paranoiden Internetusern gesucht, die nicht einfach jedem vertrauen. Das Netz könnte sich genauso gut als honeypot erweisen. Freenet, TOR, MUTE und Co. sind denn alle auch open-source.
Paradoxerweise ist Share/Perfect Dark, das grösste (angeblich) anonyme P2P-Netzwerk, closed-source. Vielleicht liegt das aber auch an Mentalitätsunterschieden (Japan vs. Europa/Amerika).

#msg25108 war nur eine grob vereinfachte Darstellung des Konzepts. In meinem nächsten Post habe ich auf Reaktion eines planetpeer-Users aber einiges klargestellt.

Ich habe mich da wohl unklar ausgedrückt: Es geht mir hier nicht um gefälschte Absenderadressen, sondern um gefälschte Paketinhalte. Das Problem ist nämlich, dass die Anonymität grösstenteils darauf beruht, dass ein Ticket für sich genommen keine verwertbaren Informationen beinhaltet. Nur die XOR-Kombination einer gewissen Anzahl von Tickets enthält die Adressinformation und den Schlüssel zum jeweiligen Datenblock. Weil ein Ticket aber wie eine Zufallsfolge aussieht, kann niemand feststellen, ob und ggf. welcher der benötigten Tickets gefälscht wurde. Durch gefälschte Tickets könnte ein Angreifer das System also problemlos lahmlegen.
Zwar habe ich mir schon ein Modell überlegt, welches redundant arbeitet und Fehler selbständig korrigieren kann, doch führt dieses letztlich wieder zu mehr Verwaltungsoverhead.
So kam ich überhaupt auf die Idee mit der Signatur der Pakete.

Zum Beispiel. Oder hardcodierte (aber verschleierte) Zufallsmuster, die mit dem Paketinhalt verknüpft werden.

Ich glaube, hier muss man zwei Dinge auseinander halten:
- Secure Hashfunktion gelten als unumkehrbar und kollisionssicher, und zwar eben auch dann, wenn das Verfahren offengelegt ist. Siehe http://de.wikipedia.org/wiki/Kerckho...80%99_Prinzip. Hier gibt es meines Wissens auch keinen wirklichen Sicherheitszuwachs, wenn man verschiedene Verfahren aneinanderreiht.

- Bei meinem Vorschlag geht es aber gerade um security through obscurity: Der Hashgenerator führt irgendwelche vordefinierte, aber möglichst diffuse Operationen mit dem Paketinhalt durch, um schliesslich einen eindeutigen Signaturwert zu generieren. Da kann natürlich nicht ein SHA-1-Wert berechnet werden, denn dann wäre das ganze völlig nutzlos.

Für jede neue Client-Version wird ein neuer Hashgenerator ausgeliefert, welcher eben nur diese einzige Client-Version akzeptiert. Der Mehraufwand sollte sich in Grenzen halten.

Das ist nicht Dein Fehler, denn meine Beschreibung ist noch ziemlich unvollständig.
Irgendwann werde ich aber eine genaue Beschreibung liefern. Das kann jedoch noch Wochen, wenn nicht Monate dauern.

So etwas in der Art habe ich leider schon befürchtet. Also wird das wohl nichts mit meiner Idee.

Aber gibt es denn keine wirksamen Alternativen?

Was wäre zum Beispiel, wenn nicht der Hashgenerator den Client aufrufen würde, sondern umgekehrt der Client den Hashgenerator.
Könnte der Hashgenerator in diesem Fall den vom Client beanspruchten Speicherbereich überprüfen und sich vergewissern, dass es sich dabei um den Originalclient handelt und ansonsten einfach den Dienst verweigern?

Oder ganz allgemein formuliert: Kann man gewährleisten (auf welche Weise auch immer), dass eine Anwendung nur mit der Originalversion einer anderen Anwendung zusammenarbeitet?

Und gibt es Methoden der interprocess communication, die als abhörsicher gelten, bzw. nur von allfälligen Exploits des Betriebssystems abhängen?

------------------------------------------------------------------------------------------------
Vielleicht kann man das Problem aber auch auf eine ganz andere Art lösen:

Anstatt einen Hashgenerator, könnte man eine Art "Schattenclient" verwenden, welcher dem quelloffenen Client vorgeschaltet ist.
Der Schattenclient erledigt die gesamte externe Netzwerkkommunikation zwischen den Nodes, indem er einerseits die vom eigenen Client abgegebenen Messages signiert und verschickt, andererseits die Signatur der eingehenden Messages überprüft.

Anstatt dass der Schattenclient die Integrität des Clients überwacht, führt er Buch über sämtlichen durch ihn durchgeleiteten Traffic.
Sollte ein manipulierter Client also ein empfangenes Ticket falsch verarbeiten, so merkt dies der Schattenclient spätestens vor dem Absenden des Tickets und verweigert die Signatur oder fügt sogar eine Warnmeldung zur Message hinzu, damit die anderen Knoten auf den manipulierten Client aufmerksam werden.

Im Prinzip ist der Schattenclient also nichts anderes als ein Abbild des normalen Clients, weil er über dessen gesamte Funktionalität verfügen muss, um sämtliche Verarbeitungsschritte des Clients nachvollziehen und allfällige Manipulationen aufdecken zu können.

Natürlich sollte die Binary des Schattenclients wiederum verschleiert sein, damit sie nicht selber manipuliert werden kann.

Diese Lösung böte doch eine recht hohe Sicherheit, oder täusche ich mich?

CDW

Hier wäre das Problem wieder erstmal herauszufinden "was will der Hashgenerator von mir?". Das kann man aber i.R noch mit Monitoringtools erledigen, die API Zugriffe Protokollieren. Man muss sich also immer noch nicht wirklich mit der geschützten Anwendung beschäftigen, um herauszufinden, dass der Hashgenerator sein Vaterprozess öffnen möchte - hat man das erstmal klar, verfährt man wie vorher - nur hookt man diesesmal OpenProcess und lässt diesen das Original öffnen (welches man entweder nebenbei betreibt oder nach dem starten "freezt". Aber ich gleite hier ab in "alles kann geknackt werden bla".
Jedoch
kann ich Dir auf Anhieb nicht sagen - normalerweise ist die Anwort "nein", aber irgendwann ist der Aufwand einfach zu hoch. Siehe z.B Skype. Wobei man hier gerne auf die kommerziellen Protektoren veweisen kann, die es immer noch nicht wirklich schaffen . Ein weiteres Problem - beide Anwendungen laufen auf dem Benutzerrechner.

Sagen wir mal so: den Aufwand für die Originalmethode (Hashgenerator prüft den Clienten und startet diesen) würde ich je nach verwendetem Protektor auf ~4 Std. schätzen. Diese zweite Version (Client startet Hashgenerator) könnte etwas mehr Zeit kosten - ca. 6-7.
Die 3 Methode - das kommt wieder darauf an. Jedoch wird man bei diesen Ansätzen auch gleich OpSource sein lassen können - der Gedanke ist ja auch nicht zu letzt, dass man weiß, was auf dem Rechner ausgeführt wird - dies ist jedoch bei einem Hashgenerator/Schattenclient nicht gegeben.

was meinst Du eigentlich bei b) mit der Attake durch manipulierte Messages? Irgendwie klingt das zu abstrakt
Vielleicht solltest Du den Ansatz verfolgen, dass die Nachbarn einen Knoten bewerten und gegebenfalls aus dem Netz ausschließen. Z.B wenn der Knoten zu viele Messages generiert (kommt jetzt auf das Protokoll an). Beim Überschreiten eines Schwellenwertes wird der Knoten z.B entfernt.
Eine Erweiterung wäre, dass dabei auch alle direkten Nachbarn darüber informiert werden, dass der Knoten (ID) "Mist" baut. Bekommt ein Knoten mehrere unabhängige "beschwerden" über einen seiner Nachbarn, schließt er diesen Nachbarn aus dem Netz aus. Zusätzlich könnte man die Initiailsierungsphase etwas langsamer gestalten - in den ersten 2-3 Sekunden die Bandbreite stark begrenzen. Als "Normaluser" wird man das in Kauf nehmen können - die Effektivität einer DoS Attake sollte dabei aber stark verringert werden (wer "dost" wird disconnected, wenn er sich neu einwählt und sich am Anfang nicht an das niedrige Limit hält, wird wieder "ausgeschlossen").

__________________
Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf!
Selig, wer nichts zu sagen hat und trotzdem schweigt.

fetzer

Würde ich so nicht sagen. Serverbetreiber achten auch auf Sicherheit. Kann man einem closed-Source-Programm nicht vertrauen, wird es auch nicht eingesetzt. Ich denke, es verhält sich hier ähnlich wie bei anonymen Netzen. Nur, kann man sich selbst bei einem closed-Source sicher sein, dass es funktioniert und nicht doch irgendwelche Lücken hat, so wird auch diesem Programm vertrauen geschenkt.
Desweiteren denke ich, dass die Sicherheit in einer Anoymitätsapplikation nicht vom Programm, sondern von den verwendeten Techniken ( Algorithmen zu Anonymisierung, Verifizierung, usw.. ) abhänig sein sollte. Tor ist beispielsweise auch nur an 2 Stellen angreifbar, der Datenstrom innerhalb der Nodes nur verschlüsselt abläuft. Security by Obscurity war noch nie eine tolle Idee

Ticketsignaturen um die Integrität herzustellen? Ich hab von der Materie wie gesagt keine Ahnung, aber das war jetzt die erste Idee, der mir in den Sinn kam.

hummel

Das ist so eine Sache. Auf den ersten Blick mag ein solches Blackbox-Tool tatsächlich sehr obskur erscheinen. Aber wenn man es nur an unproblematischen Stellen einsetzt und dies entsprechend (kontrollierbar) offenlegt, sollte es hinnehmbar sein.

Aber zunächsts muss ich zu meinem Konzept ein paar Worte verlieren.
Stellen wir uns folgende Situation vor: Die Benutzer wollen anonym Dateien veröffentlichen und stellen einander zu diesem Zweck Festplattenplatz zur Verfügung (wie bei Freenet). Gäbe es eine Person/Instanz, der alle vertrauen könnten, wäre das ein Kinderspiel. Diese zentrale Instanz müsste nur einen Index über sämtliche Datenblöcke führen, die verschlüsselt auf den Clients abgelegt würden. Ausserdem würde sie die dazugehörigen Schlüssel besitzen.

Da böswillige Clients aber ein Log über die Datentranfers (z.B. Absender der Datenblöcke) führen können, ist dieses System noch nicht wirklich anonym. Um eine hohe Anonymität zu erreichen, braucht es ein gewisses Mass an Routing. Ein effizientes Routingverfahren habe ich unter #msg25112 versucht aufzuzeigen. Wird nämlich das Routing nämlich von einer Drittinstanz kontrolliert und werden die Datenblöcke unter Umständen bei den Zwischengliedern ebenfalls abgespeichert, lässt sich im Vergleich zu I2P ein deutlicher Perfomancegewinn erzielen. Nur schon aus der Tatsache, dass die Routen nicht aus zwei Teilstrecken zusammengesetzt werden müssen (Inbound- und Outbound-Tunnels), sondern von einer trusted party gemanaged werden, ergibt sich eine erhebliche Leistungssteigerung.

Nun sind trusted third parties meiner Meinung nach eine Illusion. Die einzige Möglichkeit, Vertrauen zu schaffen, ist das Vertrauen auf möglichst viele Einzelpersonen zu verteilen, so dass eine Enttarnung z.B. nur bei (n-1) kompromittierten aus n Nodes möglich ist. Agieren bspw. 5 Nodes als Zentralinstanz für einen Datenblock, so müssen mindestens 4 Nodes vom Feind kontrolliert werden, damit die generierte Route gezielt manipuliert werden kann. Denn die Routen sollten natürlich möglichst zufällig gewählt werden.

Langer Rede, kurzer Sinn:
Mein Konzept besteht aus zwei Teilnetzen...
1) aus einer auf Chord DHT basierenden Verwaltungsebene
2) aus einem "Chaos-Lagersystem"

In 1) werden Teams mit einer konstanten Mitgliedzahl gebildet, welche für die die Tickets für die jeweiligen Blöcke verwalten. Um für eine gewisse Redundanz zu sorgen, braucht man nur c aus n Tickets, um einen Datenblock zu adressieren. Ausserdem basiert das Chord-Netz auf dem Hash der Node IPs, damit man nicht gezielt Ticketinhaber-Teams infiltrieren kann.

Die Datenblöcke werden andererseits jedoch völlig beliebig auf die Knoten verteilt. Hier herrscht ein Chaos-Lagersystem vor. Allenfalls werden Performance-Erwägungen (wie Bandbreite/Speicherplatz der Knoten) berücksichtigt.

Die Verwaltungsebene wird über lange Tunnels (Onion-Routing) angesprochen, denn die Tickets sind jeweils ein paar Hundert Bytes gross, so dass hier die Performance kaum ins Gewicht fällt.

Um die Tickets und die Ticketverwaltungs-Teams aktuell zu halten und die Anonymität trotzdem zu gewährleisten, müssen die Tickets unter gewissen Umständen neu randomisiert werden. Das hierzu verwendete Verfahren ist eine Abwandlung des Dining Cryptographer-Protokolls.
Das Problem ist aber, dass Tickets, die Zufallseigenschaften aufweisen, ganz einfach gefälscht werden können. Denn es kann später nicht mehr festgestellt werden, ob die Tickets falsch sind oder aber der Knoten, auf dem der adressierte Block sein müsste, gerade offline ist. (Die Tickets enthalten nämlich nicht den genauen Hash der Node IPs, sondern einen Hashwert des Datenblocks. Der Block wird also beim jeweils Hamming-nächsten Node abgelegt. Um sie später wieder aufzufinden, wird also ein kleiner Suchlauf innerhalb eines bestimmte n Hamming-Radius durchgeführt)
Aus diesem Grund würde auch ein Karma/Rating-System nichts bringen, wenn nicht mal versteht, dass gefälscht wurde (ganz geschweige, wer der Fälscher war).

Zwar habe ich eine Lösung gefunden, die nicht bloss Redundanz für verloren gegangene (d.h. Node geht abrupt offline, ohne das Abmelderitual zu befolgen -> Attacke mit Originalclient möglich), sondern auch für gefälschte Tickets bietet, doch ist diese erstens ziemlich kompliziert und zweitens der Anonymität nicht gerade förderlich.
Deshalb bin ich auf der Suche nach einer Alternative mit closed-source Komponenten!

Der Schattenclient würde also nur auf Ebene 1) zum Zuge kommen. Auf Ebene 2) dient die in den Tickets enthaltene Checksumme als Intigritätskontrolle für die Nutzdatenblöcke.
Ebene 1) ist jedoch völlig autonom, d.h. die Operationen laufen dort unabhängig vom Verhalten des Nutzers ab. Selbst wenn also der Schattenclient böswillige Software enthielte, wäre dies in Bezug auf die Anonymität (und auf die kommt es für den Benutzer letztlich an) unschädlich. Denn der Schattenclient zertifiziert jeweils nur die Transaktionen mit den Tickets, welche ja vom System verwaltet werden. Auch wenn der Schattenclient diese dem BKA/BND senden würde und die Tickets dazu noch auf illegale Dateien verwiesen, wäre die Anonymität gewahrt.

Bei den sensitiven Operationen, d.h. Tunnelaufbau zu den Tickets und Transfer der eigentlichen Datenblöcke, wird der Schattenclient nicht eingesetzt.
Dies wird jedermann leicht kontrollieren können, indem er sich den Sourcecode des Clients ansieht.
Aus diesen Gründen bin ich der Meinung, dass in diesem speziellen Fall eine teilweise security-by-obscurity durchaus hinnehmbar ist. Zumindest wer den Durchblick hat, muss keine Angst haben. Man könnte zusätzlich mit einem Netzwerksniffer kontrollieren, ob der Schattenclient wirklich nur eine Signatur zur Nachricht hinzufügt oder darüber hinaus irgendwelche bösen Spässe treibt.

Deshalb wäre es natürlich sehr interessant zu wissen, wie leicht ein Schattenclient, der nicht bloss den Hash des Clients kontrolliert, sondern die gesamte Ebene 1) überwacht, zu knacken wäre. Denn hier müsste man schon sehr tief in den Programmablauf eingreifen und sämtliche Variablen manipulieren, damit auch "illegale" Transaktionen signiert werden könnten.
Oder aber man dekompiliert den Schattenclient und knackt den Signatur-Algorithmus.