aber als klon-"hindernis" hat es sich ja schon mal bewährt.
Dafür würde es halt auch ausreichen, wenn man nur den privaten Schlüssel (die meisten können halt nur nicht zwischen "Zertifikat" und "privatem Schlüssel" unterscheiden und auch diejenigen, die das können, verwenden es oft genug synonym, um sich weitere Erklärungen zu sparen) entsprechend sichert - ohne den kann man zwar das Zertifikat auslesen/klonen, aber da das CMTS seine eigenen Antworten ja dann mit dem - in diesem Zertifikat enthaltenen - öffentlichen Schlüssel "unkenntlich" macht, kann man dessen Antworten ohne den passenden privaten Schlüssel nicht lesen.
Aber wenn man das anders implementiert hat ... auch gut. Ist das nicht einfach nur ein TPM, was da im Chipset implementiert ist und was den Key für die Verschlüsselung dieses "trusted store"-Formats dann liefert bzw. die Daten auch gleich ver- bzw. entschlüsselt, damit der Key das TPM nicht verläßt?
Dann wäre eine "komplette Verschlüsselung" halt merkwürdig/unnötig für den gesamten "store" (wie auch immer der aussieht), weil dann schon jeder Zugriff auf das Zertifikat ja eine TPM-Operation erfordert - es sei denn, man speichert das dann doch wieder nach dem (einmaligen) Entschlüsseln irgendwo im RAM (für die Laufzeit des Systems) als entschlüsselte Daten.
Das würde natürlich den Sinn und Zweck der Verschlüsselung wieder konterkarieren ... ob ich das aus dem Filesystem oder aus "/dev/(k)mem" auslese, macht keinen echten Unterschied (wenn der Zugriff auf das Device möglich ist). Sicher ist das Ganze nur dann, wenn ich die tatsächlich schützenswerten Daten (hier eben den PrivKey) nur dann entschlüsseln lasse, wenn ich sie gerade akut benötige und sie ansonsten auch nicht im RAM speichere oder nur mit einer zusätzlichen Sicherung (eben auch wieder verschlüsselt, ggf. mit einem "runtime key") und sogar den Speicherplatz für einen entschlüsselten PrivKey wieder explizit lösche (damit das auf dem Stack/Heap oder in irgendeinem Page-File nicht doch noch zum "leak" kommt).
Auch bei DOCSIS 3.1 ist ja der private Schlüssel des CM nur zum Dekodieren der Antwort mit dem "Authorization Key" (im Rahmen von BPI+) erforderlich (iirc) ... alles danach arbeitet mit "derived keys" und da wird dann eigentlich gar kein Zugriff auf den privaten Key mehr benötigt. Ob/wie zusätzliche Zugriffe auf das CM-Zertifikat erforderlich sind (nach der "authorization phase"), weiß ich gerade nicht ... möglicherweise gibt es das tatsächlich auch nicht und dann wäre das "jeder Zugriff" halt auch kein echter Nachteil (da schwächelt die Argumentation gg. die Verschlüsselung des Zertifikats dann etwas).
Gerade bei der Nutzung eines solchen TPM gäbe es ja aber eigentlich keinen (plausiblen) Grund, die Implementierung irgendwie "geheimzuhalten" (da sorgt ja dann das TPM für die Sicherheit der Daten) ... ich habe mich bisher für den Puma7 nicht wirklich interessiert, aber findet man nicht da auch die Patches von Intel irgendwo im Internet?
Denn das ist ja wohl immer noch ein Linux-Kernel und auch wenn AVM wohl mal wieder eigene Wege beschreitet, werden andere Hersteller ja vermutlich deutlich näher an den Intel-Quellen arbeiten. Wobei das ganze NvramDB-Zeug ja ohnehin Userland ist und vermutlich auch beim Puma7 weiterhin verwendet wird (reine Vermutung, ich habe noch nicht mal das AVM-OpenSource-Paket bei mir entpackt) ... das fällt dann halt nicht mehr unter die GPL.
Aber auch für ein ggf. vorhandenes TPM benötigt man ja Treiber und selbst wenn die als LKM ausgeführt sind, müßte es irgendwo im Kernel doch ein paar "Verbindungen" dahin geben, so daß ich nicht glaube, daß das wirklich alles ohne Patches für den Vanilla-Kernel auskommt.
