Pleroma

Sorgt für Aufsehen: „Windows 11 erfordert zwingend ein TPM“
Generell haben Sicherheitselemente als Vertrauensanker großes Potenzial, um IT-Systeme besser abzusichern. Gegen unerwünschte Nebenwirkungen helfen unter anderem offene Standards und .
Um sich in und außerhalb von Standardisierungsgremien für einsetzen zu können, ist das an allen Meinungen dazu interessiert: Wie sollte ein zukünftiges TPM ausgestaltet sein?

@bsi

> Wie sollte ein zukünftiges TPM ausgestaltet sein?

Möglichst einfach: Der Übergang von TPM 1.x zu 2.0 sieht nach typischem "Design by Committee" aus, wo jeder seine Lieblingsfeatures reinschmeißt und dafür das Lieblingsfeature des anderen akzeptiert, ohne zu gucken, wie das große Ganze denn aussieht.

Möglichst einfach, Teil 2: Auch wenn es 50 Cent mehr kostet, der TPM sollte in jedem Fall eine diskrete Komponente sein. Die ganzen firmwareTPM Lösungen, die es seit einigen Jahren gibt, packen eine kritische Komponente (den TPM) in ein komplexes Gesamtsystem (Management Engine und co), das viel zuviel kann - möglicherweise auch Daten aus dem TPM tragen, die eigentlich drin bleiben sollten.

Möglichst Meinungsstark: Algorithmen nachrüsten ist eh nicht drin, von daher sollte ein TPM den aktuellen "state of the art" anbieten, aber keine Möglichkeiten bieten, irgendwas zu "verbasteln", indem man ecdsa mit eigenen Kurven und MD4 als Hashfunktion oder ähnlichen Quatsch konstruieren kann. Weniger ist mehr, denn falls die gewählte Algorithmensuite gebrochen sein sollte, muss eh was ganz neues her. Hilft auch dabei, den TPM einfacher zu halten.

Möglichst offen: Also weiterhin eine passive Komponente, die von anderen Teilen des Systems für Dienstleistungen genutzt werden kann aber selbst keine Möglichkeit hat, die Nutzung des Computers einzuschränken. Die einzige Einschränkung, die ein TPM verursachen kann, darf die Verweigerung von darin gespeicherten Daten sein, wenn der Systemzustand (definiert als Measurements in PCRs) nicht stimmt.

Möglichst offen, Teil 2: Komplette Ownership, am besten bis hin zu Open Source Firmware im TPM. Die Firmware des Chips könnte pre-boot gehashed und dieser Hash als Schlüssel für den Datenspeicher genutzt werden, so dass man einen TPM zwar mit eigener Software betanken kann, aber immer noch nicht an dessen Daten von anderer Firmware herankommt. Wenn dieser Hash dann noch für Measurement und Sealing dienen kann ("Ich will diesen Datensatz, zB den Schlüssel für die Festplattencrypto, an einen bekannten OS- und TPM-Zustand binden"), umso besser.


Zuletzt eine regulatorische Anmerkung aus dem thematischen Umfeld:

Der TPM kann für tolle Sicherheitsdesigns eingesetzt werden, wird er aber oft nicht. Intel Boot Guard hat zum Beispiele verschiedene Betriebsarten: "Measured Mode", bei dem Boot Guard dem TPM den Systemzustand meldet, ist wunderbar eigentümerfreundlich (das System booted mit egal welcher Firmware, solange sie funktioniert, man bekommt den TPM nur nicht dazu, Daten herauszurücken, die auf einen Zustand gebunden sind, der mit einer anderen Firmware zustande kommt), kommt aber nur selten zum Einsatz.
Stattdessen ist der "Verified Mode" ohne TPM üblich geworden: Der Firmwarezustand wird mit einem in den Chipsatz gebrannten Schlüssel überprüft, so dass der Eigentümer nichts machen kann, weil der Schlüssel vom Gerätehersteller kontrolliert wird.

Wenn die Empfehlung (oder stärker) bezüglich solcher Features dahin gehen würde, dass für öffentliche Aufträge Measured Mode eingesetzt werden soll, hätten wir mehr Möglichkeiten, Systeme mit Open Source Firmware ans Laufen zu bekommen und damit auch Geräte über die Supportzeiten des Herstellers hinweg am Laufen zu halten: Mit dem ganzen Netzwerkstack-und-Cryptotralala-in-der-Firmware ist der Betrieb eines unsupporteten Geräts in einem zugänglichen Netzwerk eigentlich verantwortungslos, der Austausch alle 2 Jahre aber alles andere als nachhaltig oder bezahlbar.
replies
0
announces
0
likes
1

@bsi So, dass ich als Kunde weiter jedes Betriebssystem betreiben kann und die Keys nicht gnädig in Redmond signiert werden müssen.

@starborn @bsi Die Signaturen aus Redmond gehören zu UEFI Secure Boot und haben mit TPM nix zu tun: Secure Boot geht ohne TPM, TPM geht ohne Secure Boot.

@patrick @bsi Richtig. Hier ging es aber um die Frage der Zukunft von TPM.