Ich habe den Tag mit Felix Domkes Vortrag „Distributed FPGA Number Crunching for the masses“ begonnen. Felix will DES (56bit) knacken und das möglichst preisgünstig. Nach Evaluierung aller Optionen (CPU, GPU, Cell Processor, FPGA) hat er sich für FPGAs entschieden. Leider sind die mitunter recht teuer, daher hat er auf ebay gebrauche Hardware ersteigert auf der FGPAs verbaut sind. Die Methode ist echt abenteuerlich, man muss bei einem unbekannten Board erstmal herausbekommen, welche Spannungsversorgung notwendig ist und wo die JTAG-Pins sitzen. Jedoch hat er pro FPGA nur $50 ausgegeben, statt $2000 (Listenpreis 2006). Sein Prototyp hat drei Boards á drei FPGAs, die einen 56bit Key in einer Woche berechnen können. Der Protyp verbraucht etwa 80 Watt, das ist weit mehr, als im „Normalbetrieb“.
Interessant finde ich, dass so ein Projekt mit ein paar Mannmonaten Arbeit möglich ist. Was wird möglich sein, wenn man extrem hohe finanzielle Resourcen zur Verfügung hat? Brute-Force Angriffe skalieren linear, je mehr Geld man auf das Problem wirft, desto größere Schlüssel können in zumutbarer Zeit geknackt werden. Welche Schlüssellängen kann man noch als sicher ansehen?
Die weiterführende Idee von Felix ist es, brach liegender FPGA-Power in einem verteilten Community Netz verfügbar zu machen, also ein distributed.net für FPGAs. Viel mehr als die Idee und ein paar Sourcecodefragmente existieren (noch) nicht, aber irgendwo muss man ja anfangen und ich bin gespannt, was wir auf dem nächsten Kongress von dem Projekt hören werden.
Ich habe dann ein paar Vorträge geskipt um mich in „Is the SSLiverse a safe place?“ zu setzen. Jesse und Peter von der EFF haben in drei Monaten das gesamte IPv4 Internet auf https-Server gescannt und die Zertifikate in eine Datenbank heruntergeladen. Die Datenbank gibt es per BitTorrent und man kann die Ergebnisse selbst auswerten – sofern man die Monster SQL-Queries entsprechend formulieren kann 😉
Soweit sind die Erkenntnisse aber nicht neu, EV-Zertifikate sind Geldschneiderei, die Browser vertrauen automatisch 1400 CAs, viele davon machen Fehler und dass das ssh-Security Modell „tofu“ (trust on first usage) im Browser implementiert werden soll, fordert fefe schon lange…
Trotzdem ein ganz interessanter Talk, Respekt vor der Leistung „das Internet“ zu scannen. Es gab auch gleich den Hinweis, dass es in Zukunft schwieriger werden wird. Etwa, weil dank SNI jetzt hinter einer IP mehrere SSL-Zertifikate lauern können. Und mit IPv6 werden es nicht weniger Hosts, die man scannen muss. Die EFF arbeitet an einem verteilten Ansatz, damit künftig User am Scan mitwirken können und so ein regelmäßiges Update der Datenbank möglich ist. Das impliziert natürlich auch eine zeitliche Nachverfolgung der Änderungen in der Zertifikatslandschaft.
Die Techniken zur Identifizierung von Netzwerk-Protokollen sind ein statistischer Ansatz um Netzwerkverkehr zu klassifizieren. Florian hat den SPID-Algorithmus in C++ re-implementiert – die Referenzimplementierung ist in C# realisiert – und schafft es damit auf einem Plastikrouter Traffic in Echtzeit zu klassifizieren. Der Ansatz ist von daher interessant, weil er ohne die sonst üblichen Deep Packet Inspection Techniken auskommt, die Paketweises Pattern Matching betreiben. Er schaut eher auf der Metaebene (Paketgröße, Richtungswechsel, Hash der ersten 4 Bytes des Paketes) und erlangt damit für die 17 untersuchten Netzwerkprotokolle eine sehr hohe Trefferrate – auch auf einem 40 Euro Plastikrouter.
Den Rest des Tages habe ich mir gesundheitsbedingt zu hause als Stream angeschaut. Klares Highlight war Daniel J. Bernstein Vortrag „High-speed high-security cryptography: encrypting and authenticating the whole Internet„. Der Vortrag ist sehr unterhaltsam, schaut Euch die Aufzeichnung an.
Im Prinzip mixt DJB ein paar bekannte und erprobte Elemtente um eine Art VPN aufzubauen. Er will HTTP-Traffic in UDP kapseln. DIe UDP-Pakete sollen einzeln verschlüsselt und signiert sein. Dank elliptischer Kurven mit vertretbaren Aufwand. Beim Client wird im Browser ein Proxy eingestellt, der Webserver nimmt die UDP-Pakete auf Port 53 an und leiten den entschlüsselten Verkehr an den richtigen Webserver weiter. Die Public-Key infrastruktur soll über DNS realisiert werden, nur dass die Public Keys im CNAME-Feld einer Domain untergebracht werden und nicht als TXT-Records wie bei DNSSEC (über das er ziemlich hergezogen ist, mangels Fachwissen kann ich nicht beurteilen, wie viel davon FUD und wieviel davon fundierte Kritik ist).
Mein Eindruck von seiner Lösung ist, dass er sich wirklich Gedanken gemacht hat. Er möchte gerne eine Art IPSEC möglichst simpel implementieren. Allerdings ist die Vorgestellte Lösung erstmal „nur“ für HTTP tauglich. Sicher lassen sich auch andere TCP-Protokolle tunneln, aber das steigert den Aufwand auf Clientseite (installation zusätzlicher Proxies), obwohl ich mir vorstellen kann, dass ein Browser diese Verschlüsselung nativ implementieren könnte.
Nachtrag: Siehe auch fefes Artikel dazu, heise berichtet ebenfalls.