20 Ja-Stimmen und 12 Enthaltungen gegen die Ablehnungen von Deutschland und China in allen vier Teilabstimmungen. So sieht das Ergebnis einer Abstimmung zu einer Revision des „Trusted Platform Module“-Standards im technischen Ausschuss der International Organization for Standardization (ISO) und der International Electrotechnical Commission (IEC) aus.
Das, und warum das so ist, zeigen Abstimmungsdokumente und Kommentierungen der jeweils nationalen Standardisierungsorganisationen, die wir an dieser Stelle gesammelt veröffentlichen und erklären.
Trusted Platform Module und Trusted Computing
Ein Trusted Platform Module (TPM) ist ein Chip, der erweiterte Sicherheitsmechanismen auf einem Computer umsetzt. Das kann zum Beispiel die sichere Verwahrung von Schlüsseln sein, mit denen Daten verschlüsselt werden. Oder mit denen festgestellt werden kann, ob die erwartete Hardware im Einsatz ist und nur zugelassene Programme installiert sind und ausgeführt werden. Was als fürsorgliche Unterstützung des Nutzers beim Vermeiden von Risiken daherkommt, stellt sich jedoch schnell als ganz eigenes Risiko heraus.
Denn natürlich kann nicht nur vermeintlich schädliche Software davon abgehalten werden, auf einem System mit TPM zu laufen, sondern auch schlichtweg unerwünschte. Konkurrenzprodukte beispielsweise. Professor Dr. Rüdiger Weis von der Beuth-Hochschule in Berlin beschäftigt sich schon seit langem mit Trusted Computing. Er kommentiert:
Rein privatwirtschaftlich betrachtet sind natürlich die Angebote von Mitbewerbern nicht unbedingt erwünscht. Hardwareunterstützte Lösungen bieten Firmen Sicherheit gegen wechselde Kunden.
Das wir besonders interessant, wenn man sich anschaut, wer in der Trusted Computing Group (TCG) vertreten ist, die an den Spezifikationen arbeitet. Prominent vertreten sind unter anderem Microsoft, Intel, IBM.
TPM ist kein neues Phänomen. Schon 2003 existierte die Spezifikation TPM 1.2, die 2009 in der ersten Version des TPM-Standards ISO/IEC 11889 veröffentlicht wurde. Schon seit Jahren bauen viele Hersteller TPM-Chips in ihre Hardware ein. Mittlerweile finden sich TPM-Chips in beinahe jedem Gerät und ein neuer Standard ist auf dem Weg. Die Spezifikationen zu TPM 2.0 wurden von der TCG veröffentlicht und sollen nun zu einem internationalen Standard werden.
Warum 2.0 hier nicht besser ist
Die Revision des ISO-Standards hin zu Version TPM 2.0, die sich derzeit im Abstimmungsprozess befindet, ist zweifelsohne notwendig geworden. Denn seit Beginn der Entwicklung von Trusted Platform Modules hat sich technisch einiges verändert. Beispielsweise sind einige der Algorithmen, die für Sicherheit sorgen sollten, längst nicht mehr als sicher anzusehen – etwa der Hashalgorithmus SHA1. In TPM 2.0 reagierte man auf dieses Problem, allerdings auf wenig zufriedenstellende Art und Weise. Man strich SHA1 nicht etwa aus der Liste der zugelassenen Hashalgorithmen. Man erweiterte die Liste lediglich und fügte SHA2 als sicherere Alternative hinzu. SHA1 wird weiterhin unterstützt. In kommentierten Auflistungen zu jedem der vier Teildokumente des angestrebten Standards äußern die Vertreter Deutschlands folgende Bedenken:
Da die SHA1-Hashfunktion seit mehreren Jahren gebrochen ist, haben alle führenden Standardisierungsorganisationen gefordert, SHA1 nicht weiter zu nutzen. Leider ist die Trusted Computing Organisation diesem Rat nur teilweise gefolgt. Der vorliegende Vorschlag erlaubt immer noch die Nutzung von SHA1. Da der Wechsel zu einer sichereren Hashfunktion einen zusätzlichen Aufwand darstellt ist es nicht unwahrscheinlich, dass manche Implementierungen weiterhin unsichere Kryptoalgorithmen nutzen werden, da dies im vorgeschlagenen Dokument nicht verboten ist.
Weiterhin bestand bei TPM 1.2 das „Problem“, dass die TPM-Chips zwar in einem Großteil der am Markt befindlichen Hardware verbaut waren, genutzt wurden sie jedoch nur selten – sehr zum Ärgernis der Hersteller. Der Nutzer hatte die Kontrolle darüber, ob er den Chip aktivieren wollte und für welche Funktionen. In TPM 2.0 „löst“ die TCG dieses Problem, indem sie den Nutzer größtenteils übergeht, den Chip von Haus aus anschaltet und auch eine nachträgliche vollständige Deaktivierung unmöglich macht.
Kombiniert mit der Einführung von Windows 8 vergrößern sich die Konsequenzen: Microsoft bestimmt, welche Programme auf einem Rechner ausgeführt werden dürfen, das TPM wird zur Umsetzung dieser Einschränkungen genutzt. Wenn der Chip also nicht mehr ausschaltbar sein soll, befindet sich ein Nutzer vollkommen in der Abhängigkeit des Wohlwollens eines Betriebssystemherstellers. Darf er die Open-Source-Alternative eines kommerziellen Programmes nutzen, an dem Microsoft sonst mehr verdienen würde?
Doch nicht nur, wenn man Microsoft (und den anderen Beteiligten) böse Absichten unterstellt, ist die Situation ein Horrorszenario. Wenn man sich einige der zahlreichen Patchdebakel der letzten Monate ansieht, die mitunter zum Ausfall oder der Unbenutzbarkeit von Systemen und Systemkomponenten geführt haben, bekommt man Bauchschmerzen. Auch Rüdiger Weis sieht eine Gefahr:
Ein ungefragt eingespielter, fehlerbehafteter Windowspatch könnte große Teile der Wirtschaft lahm legen. Die Patchdebakel der letzten Monate war besorgniserregend nahe an diesem Schreckensszenario.
Der Fehler eines einzigen Marktgiganten kann so zum unkontrollierbaren Ausfall unzähliger Computersysteme führen – nicht „nur“ privater PCs. Deutschland fordert:
Das TPM muss vollständig ausgeschaltet sein, wenn ein IT-Gerät an den Käufer ausgeliefert wird und darf nur durch eine ausdrückliche, bewusste und informierte Entscheidung des jeweiligen Besitzers angeschaltet werden. […] Es ist die Freiheit des Gerätenutzers, ob er und welche Funktionen des TPMs er nutzen möchte. Das gilt dementsprechend auch für Untersysteme, die TPM-Funktionalitäten nutzen.
Dazu kommt der Faktor des unmöglichen „Vertrauens“ in die Funktionsweise der Chips, die durch die Intransparenz der Herstellung erforderlich wäre. Im August 2013 ging die Meldung „BSI warnt vor Windows 8″ durch die Medien, deren Überschrift jedoch kurz darauf auf Anordnung einer Einstweiligen Verfügung abgeschwächt wurde. Darin wird das Problem der Vertraulichkeit und Integrität eines Systems aufgegriffen, dessen Intransparenz Hintertüren zu einschlägigen Geheimdiensten mehr als nur möglich erscheinen lässt. Deutschland redet davon, dass die Erfüllung des „Grundrechts auf die Vertraulichkeit und die Integrität informationstechnischer Systeme“ unter diesen Umständen nicht garantiert werden könne und die Plattform sich nicht mehr unter voller Kontrolle des Besitzers befinde.
Deutsche Interessen könnten betroffen sein, zum Beispiel die von deutschen Regierungssystemen, die unter Fremdkontrolle stehen.
Das Vertrauen in die Funktionsweise sinkt weiter, wenn man sich die weiteren Kommentare Deutschlands zu dem Entwurfsverfahren des neuen Standards durch die Trusted Computing Group (TCG) ansieht.
ISO/IEC International Standards sollen spätestens fünf Jahre nach ihrer Veröffentlichung überprüft werden. […] Im Falle von ISO/IEC 11889–3:2009 gab es keine systematische Abstimmung, trotzdem hat die Trusted Computing Group ein Fast-Track-Verfahren einer anderen PAS-Einreichung gestartet, um die aktuelle Version von ISO/IEC 11889–3 zu ersetzen. Allein aus formalen Gründen kann das vorgestellte Dokument nicht als Revision akzeptiert werden.
Deutschland lehnt den Standardisierungsvorschlag auf allen Ebenen ab, sowohl was das Verfahren an sich als auch die technischen Spezifikationen angeht. Und verweist dabei auch darauf, dass sie unvereinbar mit dem „Eckpunktepapier der Bundesregierung zu Trusted Computing und Secure Boot“ seien. Das 2013 zurückgenommene „Vor Windows 8 wird gewarnt“ ist damit wieder präsent und – dank der hier veröffentlichten Dokumente mit eindeutigen Aussagen – nicht ohne Weiteres wieder zu relativieren, spätestens mit folgendem Fazit der DIN:
Eine Standardisierung der aktuellen TPM‑2.0‑Specifikation in ISO/IEC JTC 1 ist mindestens verfrüht und auch davon abgesehen nicht empfehlenswert, betrachtet man die Weitgefasstheit dieser Spezifikation und den Mangel an Sicherheitsgarantieen.
Warum Deutschland und China? Warum nicht alle?
Die obigen Gründe, den von US-Wirtschaftsinteressen dominierten TPM-Standard zurückzuweisen, sind so vielfältig wie einleuchtend. Warum wehren sich also nicht noch mehr Länder gegen diese Sackgasse der technologischen Souveränität? Besonders bizarr scheint das, wenn man die Kommentierungen anderer Standardisierungsorganisationen liest, beispielsweise Frankreichs AFNOR (alle Dokumente und Kommentare gesammelt im tar-Archiv). Dort werden zum Großteil die gleichen Argumente gegen die Standardisierung vorgebracht wie von Deutschland und anderen, trotzdem stimmen die Vertreter in der Abstimmung für die Norm. Von den USA gibt es leider keinen Kommentar zur Zustimmung zum Standard, der Kommentar Chinas ist nicht besonders ausführlich und konzentriert sich auf die Forderung, einen spezifischen, in China verbreiteten Signaturalgorithmus mit in den Standard aufzunehmen.
Die Free Software Foundation Europe, die Entwicklungen rund um Trusted Computing schon seit einiger Zeit begleitet, sieht in der Abnickhaltung der meisten Länder den Verlust staatlicher Souveränität:
Bei Trusted Computing geht es um die Frage, kontrollieren wir unsere Computer, oder werden wir durch Computern kontrolliert. Wollen wir uns von privaten Unternehmen vorschreiben lassen, welche Funktionen auf deutschen Regierungscomputern, geschäftlichen Laptops sowie privaten Router, Kühlschränken, Autos oder Herzschrittmachern erlaubt und welche verboten sind? Für einen souveränen Staat ist es notwendig, dass Eigentümer von IT-Geräten selbst die Kontrolle über ihre IT-Geräte haben.
Glückwunsch an die Deutsche Bundesregierung, dass sie eine klare Position vertritt! Doch nun müssen wir Politikern in anderen Ländern bewußt machen: ein „Ja“ zu TPM 2.0 bedeutet das Ende des souveränen Staates.
Was bringt Deutschland und China dazu, sich als einzige halb-öffentlich gegen die Dominanz US-amerikanischer Unternehmen zu bekennen? Oder noch spannender: Wer lobbyiert eigentlich die ganzen Standardisierungsorganisationen? Hinweise gern über die üblichen Kanäle.