Ich traue es mich fast nicht, aber ich muß Ralf in einem entscheidenden Punkt widersprechen.
Für Deine Prüfung, ob die Gegenstelle die ist, die sie sein sollte/will, reicht es aus, den
definitiv richtigen Public-Key der Gegenstelle (oder meinetwegen auch einen kryptographisch sicheren Hash des Schlüssels) zu kennen.
Ein Zertifikat für einen solchen Schlüssel kann jeder ausstellen, das ist ja gerade das, was da zertifiziert wird: "Der im Zertifikat enthaltene öffentliche Schlüssel gehört zu dieser Adresse/Institution (was auch immer da im "subject" steht)."
Allerdings nutzt (darauf beruht ja die asymmetrische Verschlüsselung mit privaten und öffentlichen Schlüsseln) der öffentliche Schlüssel einem Angreifer ja nur dann etwas (den kann schließlich jeder aus dem Zertifikat lesen), wenn er auch den zugehörigen privaten Schlüssel hat.
Die ganze Zertifizierung löst ja eigentlich nur das Problem, den öffentlichen Schlüssel auf einem sicheren Weg zum Client zu bringen und weil das eben nicht für jeden beliebigen öffentlichen Schlüssel möglich ist, gibt es die CAs, die attestieren, daß der öffentliche Schlüssel zusammen mit einem Identitätsnachweis des Inhabers bei ihnen vorgelegen hat ... das unterschreiben sie mit ihrem eigenen privaten Schlüssel. (Die zusätzliche oder alternative Aufnahme in irgendwelche Schlüsselverzeichnisse macht in einem begrenzten Szenario wie einer Firma noch Sinn (z.B. im AD oder einem anderen LDAP-Server), im globalen Web ist das Utopie.)
Wenn man den öffentlichen Schlüssel also - wie in Deinem Falle - auf einem
gesonderten sicheren Kanal übertragen kann (indem man ihn einfach vor Ort aus der FRITZ!Box ausliest - per Dateisystem oder - mit gewissen Einschränkungen, der Browser darf eben keinesfalls schon manipuliert sein - per GUI/Browser (Schloß in der Adressleiste)) und den vom Server im Zertifikat angebotenen öffentlichen Schlüssel direkt (oder über einen sicheren Hash) mit diesem vergleichen kann, kann man
sogar wesentlich sicherer sein als bei der Auswertung des restlichen Zertifikatinhalts ... der könnte durchaus von einer - eben nicht so vertrauenswürdigen - CA fälschlicherweise als "getestet und für richtig befunden" ausgewiesen werden. Im Firefox sähe der Public-Key dann so aus:
Anhang anzeigen 78802
Das ist zwar (bei meinem 4096-Bit-Schlüssel) ein Monster (512 Byte), aber wenn man das direkt in eine Software integriert, geht das i.d.R. auch ... man muß halt nur beachten, daß dann beim Schlüsselwechsel auch die Software geändert werden muß (diese Erpressungtrojaner arbeiten ja genauso, sie verschlüsseln den HDD-Inhalt mit einem fest einprogrammierten Public-Key und den zugehörigen Private-Key hat dann der Erpresser). Die Alternative, den Public-Key (ohne weitere Sicherungsmaßnahmen, wie eine eigene symmetrische Verschlüsselung) einfach in einer Datei abzulegen, ist dann wieder keine gute Idee ... man muß ja irgendwie die Manipulation des zum Vergleich dienenden Schlüssels verhindern (das gilt allerdings auch für einen "einkompilierten" Schlüssel, wenn man das Programm in fremde Hände geben will). Wenn ich AVM in einem Telefonat richtig verstanden habe (es ging um die MyFRITZ!App), wird auch das Schlüsselpaar von der Box nicht neu generiert, wenn das (selbst generierte) Zertifikat wegen der Änderung von (Dyn-)DNS-Einstellungen neu erstellt wird ... der Public-Key der Box wäre also "fest".
Wenn der öffentliche Schlüssel hingegen einen direkten Rückschluß auf den verwendeten privaten Schlüssel zuläßt - das hatten wir früher mal bei einem Fehler in Debian zwischen 2006 und 2008 -, dann krankt das nicht am Prinzip der asymmetrischen Verschlüsselung, sondern an der richtigen Umsetzung. Insofern muß man also darauf vertrauen (können), daß ein mit einem öffentlichen Schlüssel verschlüsselter Klartext nur mit dem richtigen privaten Schlüssel wieder in den Klartext übersetzt werden kann ... deshalb ist die Geheimhaltung des privaten Schlüssels auch so essentiell.
Wie sicher die von der FRITZ!Box automatisch generierten Schlüssel sind, ist dann noch ein weiteres Thema ... wenn Du wirklich sicher gehen willst, generierst Du für die FRITZ!Box einen eigenen Schlüssel und lädst ihn in die Box.
Angesichts fehlender Entropie beim Start einer "unkonfigurierten" Box, da die FB ja keine Echtzeituhr und auch weder Keyboard noch Maus hat, ist es wahrscheinlich mehr als fraglich, ob die von der Box selbst generierten Schlüssel die notwendige Vielfalt aufweisen. Das kann man allerdings nur mit einer großen Anzahl von FRITZ!Boxen (oder als Hersteller beim MyFRITZ!-Dienst) feststellen ... wenn es bei den von der Box selbst generierten Schlüsselpaaren nur wenige (sagen wir mal < 1024) gibt, ist das Anlegen einer entsprechenden Datenbank nur eine Frage der Zeit bzw. der Zugriffsmöglichkeiten auf verschiedene Boxen.
Da der öffentliche Schlüssel ja bekannt ist und zu diesem öffentlichen Schlüssel zwingend der entsprechende private gehören
muß, ist das Belauschen von Verbindungen ohne PFS dann wieder kein Kunststück.
Die Problematik der fehlenden Entropie der PRNGs bei Embedded Devices wurde auch schon vor geraumer Zeit
thematisiert, wie das bei AVM-Boxen im Kernel (also für /dev/random und /dev/urandom) ist, sollte eigentlich nicht unklar sein, da die betreffenden Kernel-Quellen ja offenliegen. Eine mögliche weitere Entropie-Quelle (das berühmte .rnd-File) ist bei einer FRITZ!Box auch nicht vorhanden, da sie dort schlicht nicht gespeichert wird.
Wenn also AVM da nicht im Closed-Source-Code eigene Vorkehrungen bei der Initialisierung des PRNG getroffen hat, dann reduzieren sich die zufälligen Einflüsse auf das generierte Schlüsselpaar soweit, daß man von einer entsprechend kleinen Zahl an Schlüsseln ausgehen kann, die nur deshalb noch nicht aufgefallen sind, weil sie niemand aktiv vergleicht.
Angesichts der Zeichenkette "string to make the random number generator think it has entropy", die 1:1 aus den OpenSSL-Testprogrammen stammt und sich z.B. bei AVM in der libikeossl.so genauso wiederfindet, bin ich da ehrlich gesagt etwas skeptisch und würde sogar von der überwiegenden Benutzung von /dev/urandom ausgehen, wenn ich nur mal die Suche in der Firmware als Anhaltspunkt nehme:
Code:
# grep -r "/dev/random" *
Binary file lib/libpthread-0.9.33.2.so matches
Binary file lib/libuuid.so.1.3.0 matches
Binary file lib/libmount.so.1.1.0 matches
Binary file lib/libcrypto.so.1.0.0 matches
Binary file lib/libblkid.so.1.1.0 matches
Binary file lib/libuClibc-0.9.33.2.so matches
grep: nohup.out: No such file or directory
# grep -r "/dev/urandom" *
Binary file bin/busybox matches
Binary file lib/libewnwlinux.so.2.0.0 matches
Binary file lib/libpthread-0.9.33.2.so matches
Binary file lib/libuuid.so.1.3.0 matches
Binary file lib/libikecrypto.so.1.0.0 matches
Binary file lib/libmount.so.1.1.0 matches
Binary file lib/libsamba.so matches
Binary file lib/libcrypto.so.1.0.0 matches
Binary file lib/libblkid.so.1.1.0 matches
Binary file lib/libuClibc-0.9.33.2.so matches
Binary file lib/libavmcsock.so.2.0.0 matches
Binary file lib/libsqlite3-3.7.14.1.so.0.8.6 matches
Binary file lib/libosipparser2.so.4.0.0 matches
Binary file lib/libacfg.so matches
Binary file lib/libwlanparams.so matches
grep: nohup.out: No such file or directory
Binary file sbin/ftpd matches
Binary file sbin/wpa_supplicant matches
Binary file sbin/hostapd matches
Binary file usr/bin/ctlmgr matches
urandom hat aber nun mal den Nachteil, daß es bei "mangelndem Zufall" nicht blockiert und ein identisch geseedeter PRNG liefert eben deterministische Ergebnisse. Das ist also alles noch kein Beinbruch, wenn der Seed (bei anderen Prozessen) irgendwann mal paßt ... basiert der dann aber in erster Linie auf der seit dem Start vergangenen Zeit, weil das Gerät keine Echtzeituhr hat und immer am 01.01.1970 startet, dann wird es eben doch schnell wieder finster mit der Vielfalt. So groß ist die Streuung der Hardware dann auch wieder nicht, daß da nicht bei verschiedenen Boxen in hohem Maße identische "Zufallszahlen" aus dem Generator kommen und das ergibt am Ende dann eben identische Schlüsselpaare. So groß ist die Varianz beim Start einer FRITZ!Box nun mal nicht und die bis zum Start des ctlmgr (und damit zur Generierung des Schlüsselpaars, wenn dieses nicht vorhanden ist) vergehende Zeit dürfte (da dabei solche Sachen wie USB-Peripherie noch außen vor sind) weitgehend identisch sein. Man braucht nur mal die PIDs von laufenden ctlmgr-Instanzen vergleichen, auch daran kann man einen weitgehend immer gleichen Ablauf des Starts der Box ja festmachen.
Die vom BSI in Auftrag gegebene Untersuchung des Linux-PRNG aus 2013 beschäftigt sich erst mit dem Kernel 3.8, aber auch da wurden eben für das Prädikat "sicher" einige Randbedingungen definiert.
Ich würde am liebsten selbst mal eine Datenbank aufsetzen, wo FRITZ!Box-Besitzer in einer Webseite per Button eine Überprüfung ihres FRITZ!Box-Schlüsselpaars auf Dubletten durchführen können. Aber die damit verbundene Arbeit hält mich davon ab ... außerdem interessiert sich nach meiner Erfahrung am Ende kein Schw*in dafür, ob die FRITZ!Boxen nun sicher sind oder nicht, am wenigsten AVM selbst. :-(
