Fritzbox 6490 Cable Firmware Update?

[Pokemon20021]

Zugriff auf Cable-Router durch Provider sowie Update/Downgrade durch KNB:

Der KNB DARF nicht auf die Box zugreifen, geschweige denn ein Update machen.

Bisher weiß ich nur von Unity wo das passiert ist oder?

BTW: es gibt auch User, die dies von Primacom Provider berichten:

Soeben mit AVM telefoniert... die können das gar nicht glauben, dass PrimaCom hier ein Firmware-Downgrade vollzogen hat ohne deren oder meines Einverständnisses!

EDIT:

[FONT=&amp]heute mit einem Techniker über die SIP Problematik geredet - er hat einen Reset durchgeführt.... - und jetzt kommt das krasseste... - Meine FritzBox hat nun die 6.50 drauf und wurde komplett zurückgesetzt![/FONT]

 

[scuros]

@Pokemon20021

Ja da gab es wohl ein Problem in einer Konstellation die nicht berücksichtig wurde.
Da wurde ein Downgrade vollzogen (kein Update), diese Kunden bekommen den Kaufpreis ihrer Retail Box oder eine neue Retail Box zugesandt nach Wahl.
In dem Forum nachzulesen, betrifft glaube 2 Leute.

Eben ein Anruf der Primacom-Technik erhalten. Die Box kann nicht mehr auf 6.60 zu ihrem Ursprung zurückgesetzt werden. Entweder wird der Kaufpreis erstattet oder eine neue aus dem Fachhandel wird zugesandt.

 

[PeterPawn]

Wo wurde ich "vorher mehrfach gewarnt"? Bitte nichts behaupten, was du nicht sicher weißt bzw. nicht stimmt.

Ich habe nicht geschrieben, daß "der_Gersthofer" vorher mehrfach gewarnt wurde ... Du bist nun auch nicht erst seit gestern hier registriert und das Thema "6490 vom Provider" wird hier so lange diskutiert, wie es die 6490 bei KDG schon gibt. Wenn diese Diskussionen vollkommen an Dir vorbeigegangen sein sollten, dann bin ich gerne bereit, die Formulierung auf "@der_Gersthofer hätte es wissen können, denn hier wurde mehrfach davor gewarnt, die Erwartungen von anderen (DSL-)Boxen (und auch die 7270 ist im Prinzip eine solche) 1:1 auf die DOCSIS-Boxen zu projizieren." zu ändern ... außer rein semantischen Änderungen ergibt das in der Grundaussage aber dasselbe.

Die Ausführungen zum "Geschäftsmodell" kommentiere ich jetzt nicht weiter ... für eine "offiziell" gekaufte Retail-Box wird das sicherlich nicht passieren, daß deren Zertifikat gesperrt wird bzw. dann wird sicherlich der Hersteller auch für Abhilfe sorgen (müssen).

Wenn Du bei anderer Hardware (z.B. Festplatten oder RAM) "OEM-Ware" kaufst, weißt Du auch von Beginn an, worauf Du Dich da einläßt ... daß der Hersteller da in aller Regel andere Garantiebedingungen hat oder bestimmte Leistungen der Retail-Produkte von Beginn an nicht in der Kalkulation hat, ist "normal" - dazu gehören ggf. auch Updates.

Hier gibt es eben keinen Anspruch gegen den Hersteller und auch keinen gegen den "OEM" - bei Dir wohl die ehemalige "Kabel Deutschland GmbH". Du hast einen Anspruch gegen Deinen Verkäufer ... woher der seine Ware bezogen hat und welche Ansprüche der nun wieder gegen seinen Distributor hätte, weiß man schlicht nicht.

Und wenn Deine Box tatsächlich ein CM-Zertifikat haben sollte, das mit dem nunmehr gesperrten AVM-Zertifikat signiert wurde, dann ist da auch kein einfaches Update über CVC-Dateien machbar ... vermutlich könnte AVM da mit einer Art Recovery-Programm etwas machen, welches dann das Bootloader-Image gegen eines austauscht, das ein neues Zertifikat enthält. Da dieses Zertifikat aber wieder eindeutig für Deine 6490 sein müßte, kommt da auch kein "allgemeines Recovery-Programm" in Betracht ... das müßte also ein genau auf Deine Box zugeschnittenes Programm sein. Für wie wahrscheinlich hältst Du es, daß AVM diesen Weg für Dich gehen wird?

Dein KNB kann da jedenfalls nichts machen ... das wäre nun wirklich ein dicker Hund, wenn ein einfaches Firmware-Update das Zertifikat im Urlader (das steht da seit der Finalisierung der Box in der Produktion und ist so etwas wie der "genetische Fingerabdruck" der Box) ersetzen würde. Mit ein wenig Pech könnte man das vermutlich aus dem System heraus tatsächlich sogar schreiben ... wenn da keine Schreibsperre für den betreffenden SPI-Bereich eingerichtet ist.

Der Prozess beim Signieren so eines Zertifikats ist genau derselbe, wie bei jedem anderen X.509-Zertifikat auch ... es wird ein geheimer privater Schlüssel generiert und dessen öffentlicher Teil wird von einer "Meldebehörde" unterschrieben, zusammen mit den Angaben, für wen das Zertifikat ausgestellt wurde und bei der FRITZ!Box wird da eben die CM-MAC als "common name" verwendet, die nun mal für jede Box eineindeutig sein sollte.

Zwar kann man so ein Zertifikat auch auf der Basis eines CSR (certificate signing request) ausstellen, aber dieser CSR muß dann wieder auf dem Gerät selbst erstellt werden (denn der private Schlüssel soll/darf das Gerät nicht verlassen). Wie kriegt man den jetzt zusammen mit nicht zu fälschenden Informationen über die Identität des Absenders so zu AVM, daß dort mit deren Schlüssel (der ist auch wieder geheim) der CSR der Box signiert werden kann? Wenn Du das Problem auf sinnvollem Weg lösen kannst, hat AVM ja vielleicht ein Einsehen ... das ist aber eines der Grundprobleme der Kryptographie, wie man vor einem Schlüsselaustausch die Identität der Gegenstelle sicher überprüft (und dafür wurden die Zertifikate und PKIs erdacht). Solltest Du dieses "Münchhausen-Problem" lösen, wird Dein Name sicherlich in einer Reihe mit "Diffie", "Hellman" und "Merkle" genannt werden.

 

[Pokemon20021]

Thema: Zertifikate

Tja, solche Datei ist nicht vorhanden...
Und jetzt?

wie PeterPawn in diesem Thread schreibt, benötigt die Box die neuen gültigen Zertifikate;
dazu müsste Dir AVM die neuen gerätespezifischen Zertifikate (d.h. abhängig von Deiner MAC-Adresse) inkl. private Key bereitstellen
und dann müßten die neuen Zertifikate in die Urlader-Partition eingepflegt werden.

ob der Hersteller gewillt ist dies zu tun, das kann ich nicht sagen;
aufgrund der Erfahrungen div. User im IPPF Forum (ASWO, lockex10, der_Gersthofer, ...) wird die CRL-Prüfung (certificate revocation list) seitens Provider (z.B. KDG, Primacom) spontan und ohne Vorwarnung aktiviert, was die Box als Kabelrouter unbrauchbar macht.
Fehlermeldung im Systemlog: "auth reject - permanent authorization failure"

 

[scuros]

@PeterPawn

Danke du kannst das einfach mal verdammt gut ausdrücken und hast das Wissen darüber.
Achja und könntest du mir vielleicht mal deine Email schicken wenn es ok wäre? Ich hätte nur eine Informative Frage die mich interessieren würde.
...
Zwecks Update über CVC Images von der DOCSIS Seite kann ich bestätigen das es schlichtweg unmöglich ist eine Box mit alten Zertifikat auf die 6.50 zu hiefen. Dies ginge nur wenn der eRouter gestartet ist und eine Verbindung hat um sich das neue Zertifikat zu ziehen.
Da hat man aber die Unterschiede der Update Mechanismen. Bie DOCSIS geht der eRouter nicht online mal so gesagt. Wenn müsste es über TR069 gemnacht werden und auch dann müsste die Box bei AVM bekannt sein.
Da es bei dir 9 Monate her ist ahne ich leider das du nur das alte hast. Ab einem Gewissen Zeitpunkt den ich leider selber nciht genau weiß waren beide auf der Box. Ab da ginge dann ein Update über DOCSIS, aber diese Möglichkeit halte ich für recht unwahrscheinlich und auch nur bei einem Provider der jede Box einfach updatet.

Edit:
Zwecks Zertifikatsprüfung, alle KNB hätten die alten Zertifikate wohl auch eher gesperrt, das hat nicht mal etwas mit der Einführung der Routerfreiheit zu tun.

 

[fesc]

Und wenn Deine Box tatsächlich ein CM-Zertifikat haben sollte, das mit dem nunmehr gesperrten AVM-Zertifikat signiert wurde, dann ist da auch kein einfaches Update über CVC-Dateien machbar ... vermutlich könnte AVM da mit einer Art Recovery-Programm etwas machen, welches dann das Bootloader-Image gegen eines austauscht, das ein neues Zertifikat enthält. Da dieses Zertifikat aber wieder eindeutig für Deine 6490 sein müßte, kommt da auch kein "allgemeines Recovery-Programm" in Betracht ... das müßte also ein genau auf Deine Box zugeschnittenes Programm sein. Für wie wahrscheinlich hältst Du es, daß AVM diesen Weg für Dich gehen wird?

Vielleicht stehe ich ja auf dem Schlauch, aber was machen die Provider mit ihren ganzen Mietboxen die auch noch das alte Zertifikat haben? Firmware update reicht ja nicht, d.h. werden die alle ausgetauscht? Immerhin ist die Firmware auf diesen Boxen ja auch potentiell verwundbar oder schon veraendert ...
(Was nicht heissen soll das neuere Firmware nicht auch irgendwann "geknackt" werden wird, das ist sogar zeimlich sicher. Was zur Frage führt, wozu das ganze überhaupt ...).

 

[PeterPawn]

Wenn die alten Zertifikate jetzt gesperrt sind (also das Zertifikat für die "intermediate CA"), dann kann man ja auch mal etwas weiter ausholen ... AVM hatte (wie man auf die Idee kam, weiß ich auch nicht) in der Firmware tatsächlich eine Möglichkeit eingebaut, ein solches Zertifikat "on the fly" zu erzeugen, dazu diente das Kommando /bin/cmcertgen. Das war von Beginn an in den 6490 so (seit der 06.08 in meiner "Ersten" zumindest und da war der Build am 17.07.2014) und spielte - solange es praktisch keinen Markt für gebrauchte Boxen gab - auch nur eine untergeordnete Rolle, weil man zwar eine defekte 6490 (mit passender Änderung der MAC-Adresse) auf diesem Weg durch eine andere ersetzen konnte, aber kein Provider eine beliebige Box eines Kunden irgendwie in seinem Netz provisioniert hätte (jedenfalls nicht freiwillig).

Jetzt müssen die Provider aber konforme Geräte auch provisionieren ... und damit ist ein privater Schlüssel, der außerhalb der Hersteller-Firma zugänglich ist, ein absolutes "no go" (der pervertiert die PKI-Prinzipien ja praktisch) und AVM hat das wohl auch vor längerer Zeit schon erkannt, was da für ein Bock geschossen wurde (ich rate mal, daß das bei der Zertifizierung bei CableLabs "rauskam") und hat sich das neue Hersteller-Zertifikat besorgt.

Das ist jedenfalls (steht hier irgendwo vorher schon) vom März 2015 und irgendwann gingen dann wohl die ersten Boxen in Produktion, die im Urlader ein Zertifikat hatten, das mit dem neuen signiert war und trotzdem in der Firmware noch das alte Zertifikat (inkl. des privaten Schlüssels für das Hersteller-Zertifikat) enthielten ... inkl. des erwähnten Programms "/bin/cmcertgen", womit diese Boxen dann wohl auch noch ein Zertifikat generieren konnten, das mit dem "alten" Hersteller-Zertifikat signiert war.

Das ist aber auch ein ziemlich klarer Verstoß gegen den Standard (so eine "dynamische" Generierung eines Zertifikats) und wenn die Provider jetzt im Zuge der "Routerfreiheit" in ihren Schnittstellenbeschreibungen strikte DOCSIS3-Kompatibilität einfordern (für solche Boxen, die der Kunde selbst bereithält), dann erfüllen die alten Modelle diese Forderung wohl nicht (nach meiner Lesart des Standards).

AVM war also vermutlich eher gezwungen, den Schritt zur neuen Artikelnummer für die Retail-Modelle zu gehen ... angesichts des damit verbundenen Zusatzaufwands würde ich unterstellen, daß das nicht unbedingt freiwillig war und nur mit dem Blick auf den möglichen Absatz "neuer" Cable-Boxen erfolgte.

Wenn man eine Box eines Kunden so "klonen" kann, daß man ein gültiges Zertifikat für die identische CM-MAC hat, dann kann der Provider diese Boxen nicht auseinanderhalten und sie könnten zumindest in unterschiedlichen Kabelsegmenten parallel eingesetzt werden.

Da diese CM-MAC auch die Basis für die "Zuteilung" der gebuchten Bandbreite und eigentlich sogar für die Provisionierung der gesamten Box (hinsichtlich der IP-Konfiguration) ist, wäre damit wirklich dem Mißbrauch von Leistungen Tür und Tor geöffnet ... auch wenn jetzt vielleicht alle mit den Schultern zucken und "Na und ..." denken mögen, ist das mit einiger Wahrscheinlichkeit nichts, was man selbst in seinem Kabelsegment haben möchte.

Wenn dort nämlich die Hälfte der Kunden nur einen "kleinen Anschluß" gebucht hat und sich eine höhere Bandbreite im US/DS (bzw. mehr Kanäle für das Bonding) "erschleicht", dann leidet darunter das gesamte Segment, wenn die das auch ausnutzen (ansonsten bräuchten sie das auch nicht machen).

Der Provider geht (sicherlich zurecht) davon aus, daß 100 Anschlüsse mit 32 MBit/s eben mit einer definierten Bandbreite auskommen werden (daß es keine 100% bereitgehaltene Kapazität gibt, ist auch klar und bekannt) und wenn davon 80% ihre CM-Konfiguration so manipulieren, daß sie 200 MBit/s anstelle der gebuchten 32 haben, dann ist bei nur 16 "Power-Saugern" dieselbe Bandbreite "in Benutzung" (rein rechnerisch, wie gesagt gibt es keine 100% Abdeckung für den theoretischen Peak in der Nutzung, wie man auch immer wieder hören kann, wenn ein Provider lieber sein Netz weiter segmentieren sollte). Wenn sich dann die "rechtschaffenen Kunden" aus so einem Segment beschweren, würde der Provider beim Zusammenrechnen der nominellen Werte für das Segment wohl immer noch keinen Handlungsbedarf oder die Berechtigung solcher Beschwerden sehen.

Was mich wirklich interessiert, ist die Frage, wie die KNB nun mit den alten Boxen umgehen, die sie selbst noch in ihren Netzen verwenden (das meint die, welche noch kein CM-Zertifikat mit dem neuen Hersteller-Zertifikat haben) ... wenn das Hersteller-Zertifikat gesperrt wurde, sollte das auch für diese Boxen gelten. Haben die da vielleicht einen Austausch der älteren Boxen vorgenommen? Wenn das Mfg-Zertifikat erst seit dem 13.03.2015 gültig ist, müßten zumindest alle vor diesem Datum produzierten Boxen kein passendes Zertifikat haben ... nun war das vermutlich fast ausschließlich KDG, wo es solche älteren Boxen im Netz gab oder gibt, denn UM (LGI) hat m.W. erst später mit der 6490 begonnen.

Das oben Geschriebene ist jetzt in dem Punkt, wo es um den privaten Schlüssel und das Programm "cmcertgen" in der Firmware geht, nachweisbar ... die Motivation und die zeitlichen Abläufe (inkl. des Wechsels auf ein CM-Zertifikat im Urlader-Config-Bereich, das mit dem neuen Herstellerzertifikat signiert ist) bei AVM sind aber nur "Spekulationen" auf der Basis von Beobachtungen von außen und Rückschlüsse aus Datumsangaben von verschiedenen Quellen.

EDIT:
@fesc ... das weiß ich eben auch nicht - ich würde aber auf einen Austausch tippen oder auf ein drittes Zertifikat, das dann in einem "Zwischenupdate" bei diesen Providern enthalten war (bzw. wieder der "private key", vielleicht auch deshalb die "Spezialfirmware" für KDG) und anstelle des "verbrannten" Zertifikats ein neues generierte, das dann an einer anderen Stelle im nicht-flüchtigen Speicher der Box (z.B. weiß ich nicht, was in der Datei "docsis.nvram" im TFFS (Minor-ID 66) stehen sollte) abgelegt wurde. Das Zurücksetzen auf Werkseinstellungen würde dieser TFFS-Node wieder schadlos überstehen und ein Recovery-Programm liegt ja ohnehin nicht vor bzw. könnte sicherlich über die "provider"-Variable im Urlader-Environment wieder von der Box ferngehalten werden (wie bei den "provider additive"-Konfigurationen). Hat die Box dann über so ein "Zwischenupdate" erst einmal für sich selbst ein neues Zertifikat generiert, könnte man durch ein weiteres Update mit einer Firmware, die den privaten Schlüssel dann nicht enthält, das auch wieder "sicher" machen.

Wenn man diesen Vorgang vielleicht auch gleich in das /var/install-Skript einbaut und mal davon ausgeht, daß so eine Box beim Online-Update dann auch eine Online-Verbindung hat, könnte man sogar auf die Idee kommen, tatsächlich einen CSR zu erzeugen und den dann vom Hersteller signieren zu lassen im Rahmen einer Online-Verbindung. Ich hätte so ein Binary vermutlich "cm_dl_cert" genannt und es dann aufgerufen, wenn die Box noch keinen Bootloader mit einem passenden Konfigurationsbereich hatte. Dann wird eben das CM-Zertifikat nicht im Urlader, sondern an einer anderen Stelle gespeichert. Das wäre zumindest eine denkbare Möglichkeit ... wobei man natürlich auch da wieder den privaten Schlüssel mitsenden könnte, wenn man es nicht ganz so genau nimmt und davon ausgeht, daß die Verbindung ohnehin mit TLS gesichert ist.

 

[scuros]

@fesc

Deswegen hat es solange gedauert bis es gesperrt werden konnte, Lagerbestände mussten berücksichtigt werden und viele Faktoren mit Lieferzeiten usw.
Es sind bei fast allen Providern die Boxen auf die 6.50 gebracht wurden. Alle "neuen" Boxen hatten schon beide Zertifikate auch wenn sie eine 6.23 Firmware hatten, nutzen allerdings erst das alte und mit der 6.50 das neue.
Bei Boxen die nur das alte haben ist es komplizierter und das Update geht nur über TR069 und die Boxen müssen AVM bekannt sein und eine Verbindung zu AVM haben.

- - - Aktualisiert - - -

Was mich wirklich interessiert, ist die Frage, wie die KNB nun mit den alten Boxen umgehen, die sie selbst noch in ihren Netzen verwenden (das meint die, welche noch kein CM-Zertifikat mit dem neuen Hersteller-Zertifikat haben) ... wenn das Hersteller-Zertifikat gesperrt wurde, sollte das auch für diese Boxen gelten. Haben die da vielleicht einen Austausch der älteren Boxen vorgenommen? Wenn das Mfg-Zertifikat erst seit dem 13.03.2015 gültig ist, müßten zumindest alle vor diesem Datum produzierten Boxen kein passendes Zertifikat haben ... nun war das vermutlich fast ausschließlich KDG, wo es solche älteren Boxen im Netz gab oder gibt, denn UM (LGI) hat m.W. erst später mit der 6490 begonnen.

Es wird wohl bei jedem Provider Einzelfälle geben wo das noch vorkommt, aber es wurde überall mit Hochdruck daran gerarbeitet alle auf die 6.50 zu hiefen.
Edit: Konkreter hier, die Boxen mussten eine Verbindung zu AVM haben also Update nur über TR069.
Der Rest wird tatsächlich getauscht, da es keine Möglichkeit gibt Ausnahmen zu machen nachdem man das Zertifikat gesperrt hat.
UM kann ich schlecht beurteilen da dort echt noch kuriose Firmwares auf den Kundenboxen sind was man in den Foren so ließt.

 

[Aux]

was machen die Provider mit ihren ganzen Mietboxen die auch noch das alte Zertifikat haben?

Na was wohl? Die werden auch bei e..y verklopft oder sonstwo "In der Natur geht nichts verloren, es wechselt nur den Besitzer"...

 

[scuros]

Na was wohl? Die werden auch bei e..y verklopft oder sonstwo "In der Natur geht nichts verloren, es wechselt nur den Besitzer"...

Wird ganz normal ein Hardwaretausch gegen eine neue Box vollzogen, die alte geht in die Aufbereitung und wird neu ausgeliefert.

 

[fesc]

nicht-flüchtigen Speicher der Box (z.B. weiß ich nicht, was in der Datei "docsis.nvram" im TFFS (Minor-ID 66) stehen sollte) abgelegt wurde. Das

Da steht nur der filename des zugrundeliegenden cvc images (bei mir HW213a.141.06.10.120308002013.cvc).

 

[PeterPawn]

Da steht nur der filename des zugrundeliegenden cvc images (bei mir HW213a.141.06.10.120308002013.cvc).

Und Du hast auch ein Update auf der Box, das sich (damals/rechtzeitig) ein neues Zertifikat vom c4.avm.de geholt hatte? Oder ist Deine Box nun auch von der Revocation des alten Zertifikates betroffen?

 

[fesc]

Die box laeuft jetzt mit version 6.50, und ist (noch?) nicht ausgesperrt. Ob sie sich je ein neues Zertifikat geholt hat weiss ich nicht, wobei ich nicht wueste wie sie das selbstaendig tun sollte (c4.avm.de kommt nirgends im root filesystem vor). Was vorhanden ist:

# cd /nvram/1/security
# ls -l
-rw-r--r--    1 root     root           760 Jan  1  1970 cm_cert.cer
-rw-r--r--    1 root     root           633 Jan  1  1970 cm_key_prv.bin
drwxr-xr-x    2 root     root             0 Jan  1  1970 download
lrwxrwxrwx    1 root     root            38 Jan  1  1970 mfg_cert.cer -> /etc/docsis/security/euro_mfg_cert.cer
lrwxrwxrwx    1 root     root            41 Jan  1  1970 mfg_key_pub.bin -> /etc/docsis/security/euro_mfg_key_pub.bin
lrwxrwxrwx    1 root     root            42 Jan  1  1970 root_pub_key.bin -> /etc/docsis/security/euro_root_pub_key.bin

Im urlader ist kein ZERTIFIKATE feld:

# cat /proc/sys/urlader/config
WLAN
DECT
WLAN2
DOCSIS

 

[Aux]

Im urlader ist kein ZERTIFIKATE feld:

# cat /proc/sys/urlader/config
WLAN
DECT
WLAN2
DOCSIS

Genau, so sieht's auch bei mir aus.

Doch die zweite Ausgabe sieht etwas anders aus:

# ls -l
rwxrwxrwx    1 root     root            38 Apr 26 02:36 cm_cert.cer -> /nvram/1/security/download/cm_cert.cer
lrwxrwxrwx    1 root     root            41 Apr 26 02:36 cm_key_prv.bin -> /nvram/1/security/download/cm_key_prv.bin
drwxr-xr-x     2 root     root             0 Apr 26 02:36 download
lrwxrwxrwx    1 root     root            38 Jan  1  1970 mfg_cert.cer -> /etc/docsis/security/euro_mfg_cert.cer
lrwxrwxrwx    1 root     root            41 Jan  1  1970 mfg_key_pub.bin -> /etc/docsis/security/euro_mfg_key_pub.bin
lrwxrwxrwx    1 root     root            42 Jan  1  1970 root_pub_key.bin -> /etc/docsis/security/euro_root_pub_key.bin

 

[PeterPawn]

Wobei (die Neugierde ließ mich nicht los) inzwischen auch klar ist, wo die neuen Zertifikate wirklich abgelegt werden bei den Boxen, die sie noch nicht im Urlader haben.

Beim Zurücksetzen auf Werkseinstellungen wird ein weiterer (nicht-flüchtiger) Speicherbereich nicht komplett gelöscht (nur nach Recovery - ähnlich wie beim TFFS), dort werden dann nur die Dateien gelöscht, die nicht in einer Ausnahmeliste aufgeführt sind und in dieser stehen auch die Verzeichnisse für die Speicherung der Zertifikate.

Da das auch wieder die Stelle ist, wo die Zertifikate aus dem Urlader ebenfalls landen (wenn sie sich geändert haben sollten), greift dann der restliche Code wohl auf diesen weiteren persistenten Speicher zu und die unterschiedlichen "Voraussetzungen" der Boxen spielen ab da keine Rolle mehr.

Wenn jedoch so eine alte Box jemals einem Recovery-Programm über den Weg laufen sollte, müßten aber auch diese Zertifikate neu eingespielt werden - in meinen Augen ein weiterer Punkt, der gegen die zeitnahe Verfügbarkeit eines "allgemein verfügbaren" Recovery-Programms spricht.

Aber das braucht es ja ohnehin nicht wirklich ... wenn ich mich richtig erinnere, warst ja auch Du (@fesc) ein (unfreiwilliger) Tester für ein neues TFFS-Image. Wobei bei diesem Vorgehen dann auch bereits in der Box befindliche Zertifikate nicht gelöscht würden ... aber das vorher von Dir probierte Setzen von "recovered=n" in "firmware_info" hätte event. vorhandene neue Zertifikate "gekillt" (und würde das auch erneut machen).

Damit ist das (im Lichte der Speicherung der Zertifikate dort) ab jetzt ganz klar ein "no go" (bei den ganz alten Boxen, wo der Urlader kein neues CM-Zertifikat enthält) ... aber daß damit auch Speicherinhalte zurückgesetzt würden, hatte ich schon damals in dem anderen Thread betont, als ich noch keine Ahnung hatte, daß es diese "Ausnahmeregelung" bei den Werkseinstellungen gibt (bzw. die "Anlagen" dafür gab es tatsächlich schon länger, aber die Datei mit den Ausnahmen war damals noch leer) - eigentlich war das Löschen ja sogar der Sinn dieser Aktion.

EDIT: Na gut, da war ich mit "ein weiterer nicht-flüchtiger Speicher" dann zu vorsichtig in der Aussage ... ja, es ist genau dieser Bereich unterhalb von /nvram und welche Verzeichnisse dort nicht gelöscht werden, steht in der /etc/docsis/nvramdontremove.

- - - Aktualisiert - - -

Wenn Du schon weißt, wo Dein CM-Zertifikat liegt, kannst Du ja auch nachsehen, womit das signiert wurde. Die denkbaren Hersteller-Zertifikate (zumindest zwei davon) habe ich ja vorher hier schon irgendwo stehen.

 

[Aux]

Also ich kann nicht wirklich nachschauen weil:

-rw-rw-r--    1 root     root             [COLOR=#ff0000]0[/COLOR] Aug 17 15:32 cm_cert.cer
-rw-rw-r--    1 root     root             [COLOR=#ff0000]0[/COLOR] Aug 17 15:32 cm_key_prv.bin

 

[PeterPawn]

@Aux:
Bliebe die Frage, von wem die Box wann von welcher Version auf welche aktualisiert wurde ... bei jemand anderem dürften da ebenfalls 0 Byte große Dateien stehen.

Wer ein Update aus einer zweiten Telnet-Sitzung macht, weil ihm auf der ersten Session in der Ausgabe auf /dev/console zuviele Nachrichten vorbeifliegen, der wird auch die im verlinkten Beitrag gezeigten Zeilen im Rahmen einer "manuellen Installation" nie zu Gesicht bekommen haben.

 

[OzZy_HH]

Bei mir sieht die urlader/config etwas anders aus:

# cat /proc/sys/urlader/config
WLAN
DECT
WLAN2
ZERTIFIKATE
DOCSIS
# ls -lR /nvram/1/security/
/nvram/1/security/:
lrwxrwxrwx    1 root     root            38 Jan  1  1970 cm_cert.cer -> /nvram/1/security/download/cm_cert.cer
lrwxrwxrwx    1 root     root            41 Jan  1  1970 cm_key_prv.bin -> /nvram/1/security/download/cm_key_prv.bin
drwxr-xr-x    2 root     root             0 Jan  1  1970 download
lrwxrwxrwx    1 root     root            38 Jan  1  1970 mfg_cert.cer -> /etc/docsis/security/euro_mfg_cert.cer
lrwxrwxrwx    1 root     root            41 Jan  1  1970 mfg_key_pub.bin -> /etc/docsis/security/euro_mfg_key_pub.bin
lrwxrwxrwx    1 root     root            42 Jan  1  1970 root_pub_key.bin -> /etc/docsis/security/euro_root_pub_key.bin


/nvram/1/security/download:
-rw-r--r--    1 root     root           775 Jan  1  1970 cm_cert.cer
-rw-r--r--    1 root     root           634 Jan  1  1970 cm_key_prv.bin
-rw-r-----    1 root     root          1013 Jan  1  1970 mfg_cert.cer
-rw-r-----    1 root     root           294 Jan  1  1970 mfg_key_pub.bin

Hat das irgendwas zu bedeuten
Box ist eine 6.26 kdg jetzt mit 6.50 avm

 

[Aux]

@Aux:
Bliebe die Frage, von wem die Box wann von welcher Version auf welche aktualisiert wurde ... bei jemand anderem dürften da ebenfalls 0 Byte große Dateien stehen.

Update von OS 06.26 (lgi) auf 06.50 manuell mit freundliche Hilfe von @fesc und ja, zweite Telnet Sitzung...

 

[fesc]

Wenn Du schon weißt, wo Dein CM-Zertifikat liegt, kannst Du ja auch nachsehen, womit das signiert wurde. Die denkbaren Hersteller-Zertifikate (zumindest zwei davon) habe ich ja vorher hier schon irgendwo stehen.

Du meinst cm_cert.cer?

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            XX:XX:XX:XX:XX:XX:XX:XX:XX
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=DE, ST=Berlin, L=Berlin, O=AVM GmbH, OU=Euro-DOCSIS, OU=Germany, CN=AVM GmbH Cable Modem Root Certificate Authority
        Validity
            Not Before: Jul 30 00:00:10 2009 GMT
            Not After : Jul 29 23:59:49 2029 GMT
        Subject: C=DE, O=AVM GmbH, OU=Euro-DOCSIS, CN=XX:XX:XX:XX:XX:XX
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption

Serial Number ist 8c:95:b4:83:77:cc:44:3d

Von mfg_cert.cer (/etc/docsis/security/euro_mfg_cert.cer) ist die serial number tatsaechlich die von Dir erwaehnte 18:d9:3d:04:72:8f:ce:2f:ba:a7:81:a8:1f:92:6a:43