Fragen? Antworten! Siehe auch: Alternativlos
Ich hätte mich da auch bewerben können, aber habe es nicht getan, weil ich lieber wollte, dass das jemand macht, der die ganzen Crypto-Details so gut versteht, wie ich typische C-Programmierfehler verstehe. Kurz: Ich habe mir Sorgen gemacht, dass wenn ich das mache, dass ich das dann nicht richtig abdecke. Sondern halt nur den Teil wirklich angucke, den ich halt besonders gut kann, und über den Rest im schlechtesten Fall gar nichts sagen kann oder im besten Fall zwar geguckt habe, aber möglicherweise nicht genug Hintergrundwissen oder Durchdringung der Materie mitbringe, so dass meine Aussage kein großes Gewicht hat am Ende.
Nun, der Audit hat stattgefunden.
Zu meiner großen Enttäuschung muss ich jetzt konstatieren, dass das dann halt andere Leute genau so gemacht zu haben scheinen, wie ich es bei mir vermeiden wollte. Die haben halt da geguckt, wo schon Lücken bekannt waren, und haben dann diese Lücken nicht mehr gefunden. Diesen Audit hätte man sich auch sparen können. Einen Black-Box-Audit auf den Zufallszahlengenerator? Soll das ein Scherz sein!? Und dann gnädigerweise auch mal kurz ein paar Zeilen Quellcode angeguckt?!?
Das war ein Reinfall. Das wäre ja sogar besser geworden, wenn ich mich beworben hätte. Und das ist keine starke Aussage, siehe oben.
Sehr schade. Eine vertane Chance.
Wobei ich meine Einschätzung jetzt natürlich auf diese Meldung bei Heise stütze. Vielleicht ist die ja falsch und es war besser als es sich da jetzt anhört.
Update: Einer der Auditoren hat mir eine Mail geschrieben:
Die Darstellung in deinem Blogeintrag bzw. Heise ist nicht korrekt (http://blog.fefe.de/?ts=a842a5a6).
Die Analyse des RNG war nur im ersten Schritt Black-Box (wodurch Schwächen gefunden wurden). Im zweiten, selbstverständlich aufwändigeren Teil haben wir uns den Source Code angeschaut, ein Modell des RNG-Algorithmus aufgebaut, den Lebenszyklus des RNGs und dessen Zustand angeschau, etc. Die Methodik ist im Bericht dokumentiert, ein Blick in das Inhaltsverzeichnis liefert schon Informationen dazu.
Bei der Schwachstellenanalyse wurde ähnlich vorgegangen. Es wurden Blackbox-Tests durchgeführt (durch die Schwächen gefunden werden konnten), sowie eine Code Review verschiedener wichtiger Komponenten durchgeführt. Wir mussten selbstverständlich den Scope einschränken (wen interessiert schon die GOST und SSL3.0-Implementierung?), aber denken, dass die wichtigen Komponenten in einem angemessenen Rahmen betrachtet wurden.
Nach meiner Einschätzung würde sich das BSI mit einer oberflächlichen Analyse nicht zufrieden geben. Da sitzen Leute, die sich mit der Thematik sehr gut auskennen.
Update: Hier ist das PDF des Berichtes.
Update: Oh, es gibt nicht nur ein PDF, sondern drei.