--- title: "Vertraulichkeit existiert nicht" subtitle: "Der vertrauenswürdige Dritte, den Sie vergessen wollten" meta_title: "Vertraulichkeit existiert nicht: vertrauenswürdige Dritte" meta_description: "TPM, Ende-zu-Ende-Verschlüsselung und Build-Kette: Jede Sicherheitsschicht verschiebt das Vertrauen auf einen Dritten, den Sie nicht kontrollieren." date: 2026-06-05 author: JAS theme: "SICHERHEIT" keywords: ["Sicherheit", "Vertraulichkeit", "Quanten", "Governance"] image: https://ik.imagekit.io/l2lkwahet/199A/gouverner-avec-un-retroviseur-la-donnee-le-bouclier-et-la-confiscation-des-futurs_zuz6hDR0c.jpg slug: vertraulichkeit-existiert-nicht status: published faq: [{"q":"Was bedeutet die Aussage, dass absolute Vertraulichkeit nicht existiert?","a":"Absolute Vertraulichkeit würde erfordern, die gesamte Verarbeitungskette vom Silizium bis zur Anwendung zu beherrschen, was die Informatik nie erreicht hat. In der Praxis umfasst jede Kette mindestens einen Prozessor mit nicht kontrollierbarem Mikrocode, einen Compiler mit schwer prüfbarer Integrität und Hardwarekomponenten mit proprietärer Firmware. Reale Sicherheit ist daher keine Abwesenheit von Dritten, denen man vertraut, sondern eine begründete Wahl über deren Natur und Position im Bedrohungsmodell."},{"q":"Welche Schwachstelle zeigte die Grenzen des Vertrauens in TPM-Chips?","a":"Im Jahr 2017 wurde die Schwachstelle ROCA (CVE-2017-15361) in Infineon-TPMs entdeckt: Die RSA-Schlüsselgenerierung in der Firmware erzeugte Schlüssel mit reduzierbarem Primfaktorenmuster, was die Faktorisierung von RSA-2048 praktisch angreifbar machte. Millionen Chips in Laptops, Smartcards und Authentifizierungstokens waren betroffen, obwohl der Chip nach Common Criteria EAL4+ zertifiziert war. Die Behebung erforderte Firmware-Updates über die Laptop-Hersteller, mit je nach Hersteller unterschiedlichen Fristen."},{"q":"Warum garantiert Ende-zu-Ende-Verschlüsselung keine vollständige Vertraulichkeit?","a":"Die Ende-zu-Ende-Verschlüsselung schützt nur den Nachrichteninhalt auf dem Transportweg zwischen zwei Clients, nicht das, was der Client nach der Entschlüsselung damit macht. WhatsApp nutzt zwar das Signal-Protokoll, doch Kontakt- und Nutzungsfrequenz-Metadaten fließen an Meta, was eine bewusste Designentscheidung darstellt. Bei Signal werden verschlüsselte Backups auf Google Drive über einen in einem Signal-HSM gespeicherten Schlüssel geschützt, sodass man Signal vertrauen muss."},{"q":"Was besagt Ken Thompsons „Reflections on Trusting Trust“ von 1984?","a":"Thompson zeigte, dass ein Trojaner so in einen Compiler eingeschleust werden kann, dass das erzeugte Binärprogramm kompromittiert ist, selbst wenn der Quellcode sauber ist, und dass der Compiler sich bei seiner Neukompilierung selbst wieder einfügt. Das Lesen des Quellcodes verrät dann nichts, nur die Analyse des Binärprogramms erlaubt es, die Anomalie zu erkennen. Dieses Problem verschwindet auch mit reproduzierbaren Builds nicht, es wird nur eine Ebene weitergeschoben."},{"q":"Welche Konsequenzen hatte der SolarWinds-Angriff von 2020 für die Build-Kette?","a":"Bei SolarWinds wurde 2020 die Build-Kette von Orion kompromittiert, wodurch mit dem legitimen Unternehmenszertifikat signierte Binärdateien mit Backdoor entstanden. Tausende Organisationen installierten die Software nach korrekter Signaturprüfung, und eine Auditierung des Quellcodes hätte nichts ergeben, da die Änderung während des Builds erfolgte. Als technische Antwort gilt der reproduzierbare Build, den Debian seit 2013 verfolgt und den Bitcoin Core übernommen hat, dessen Abdeckung im Ökosystem aber partiell bleibt."},{"q":"Wie kann 199A Consulting Organisationen dabei unterstützen, ihre Vertraulichkeit und ihre vertrauenswürdigen Dritten richtig einzuordnen?","a":"199A Consulting begleitet Organisationen mit über 20 Jahren Erfahrung bei der strategischen Rahmung (Audit, Governance, Risiken) und der Umsetzung (Architektur, Build, Integration, Schulung), um vertrauenswürdige Dritte explizit zu kartieren und das Bedrohungsmodell ehrlich zu bewerten. Dabei verbinden wir technische Rigorosität mit dem Anspruch digitaler Souveränität, damit Sie genau wissen, wo Ihre Abhängigkeiten liegen und was Sie verlieren, wenn einer dieser Dritten kompromittiert wird. Kontakt: business@199a.agency"}] --- *Moderne Sicherheit beruht auf einem selten explizit formulierten Paradoxon: Jede Schutzschicht, die Sie hinzufügen, verschiebt das Vertrauen auf einen Akteur, den Sie nicht kontrollieren, ohne es zu beseitigen. Diesen Verschiebungsprozess zu verstehen, ist die Voraussetzung für jede ehrliche Betrachtung von Vertraulichkeit.* --- ## Der Mythos der Kette ohne schwaches Glied Ein Ingenieur, der ein sicheres System entwirft, denkt natürlich in Schichten: Ende-zu-Ende-Verschlüsselung, starke Authentifizierung, sichere Schlüsselspeicherung, Boot-Integrität. Jede Schicht wird auditiert, dokumentiert, begründet. Das Endergebnis erweckt den Eindruck einer Festung. Genau dieser Eindruck ist gefährlich. Absolute Vertraulichkeit würde eine Eigenschaft erfordern, die die Informatik nie erreicht hat: Herr über die gesamte Verarbeitungskette zu sein, vom Silizium bis zur Anwendung. In der Praxis umfasst diese Kette mindestens einen Prozessor, dessen Mikrocode Sie nicht kontrollieren, einen Compiler, dessen Integrität Sie nicht bei jedem Build überprüfen können, und eine oder mehrere Hardwarekomponenten, deren Firmware proprietär ist. Reale Sicherheit ist nicht die Abwesenheit von Dritten, denen man vertraut; sie ist eine begründete Wahl über die Natur und die Position dieser Dritten in Ihrem Bedrohungsmodell. Drei Punkte veranschaulichen diese Verschiebung konkret und überprüfbar. --- ## Das TPM versiegelt Ihre Geheimnisse in einer Blackbox, die Sie nicht öffnen können Das Trusted Platform Module ist zum Eckpfeiler der sicheren Schlüsselspeicherung auf modernen Architekturen geworden. Sein Prinzip ist solide: ein dedizierter Chip, vom Hauptprozessor isoliert, der nicht extrahierbare Schlüssel erzeugen und ihre Verwendung an den gemessenen Systemzustand über die PCR (Platform Configuration Registers) knüpfen kann. Ubuntu Core nutzt es explizit, um LUKS2-Schlüssel beim Booten direkt im TPM zu versiegeln: Wenn die Fingerabdrücke von Firmware, Bootloader und Kernel dem aufgezeichneten Zustand entsprechen, wird der Schlüssel automatisch freigegeben. Andernfalls bleibt die Festplatte ohne Ausweg verschlüsselt. Das ist elegant. Es ist zugleich eine vollständige Vertrauensdelegation an den Chiphersteller. Im Jahr 2017 wurde eine kritische Schwachstelle namens ROCA (Return of Coppersmith's Attack, CVE-2017-15361) in Infineon-TPMs entdeckt. Die in der Firmware eingebettete RSA-Schlüsselgenerierungsbibliothek erzeugte Schlüssel, deren Primfaktoren einem reduzierbaren Muster folgten, was die Faktorisierungskomplexität von RSA-2048 auf ein praktisch angreifbares Niveau senkte. Millionen von Chips in Laptops, Smartcards und Authentifizierungstokens waren betroffen. Der Fehler lag in geschlossenem, nicht auditierbarem Code auf einem nach Common Criteria EAL4+ zertifizierten Chip. Die Zertifizierung hatte das Problem nicht erkannt. Die Behebung erforderte ein Firmware-Update, das von den Laptop-Herstellern verteilt wurde, nicht direkt von Infineon, mit je nach Hersteller unterschiedlichen Fristen. Während dieses Fensters hatte jedes System, das auf der Nicht-Extrahierbarkeit der von diesen TPMs erzeugten RSA-Schlüssel beruhte, eine Sicherheitsgarantie, die nichts wert war. Das ist kein Argument gegen das TPM. Es ist ein Argument gegen die Illusion, das TPM beseitige die Abhängigkeit von einem Dritten. Es konzentriert sie. Sie haben die diffuse Schwäche eines menschlichen Passworts durch eine präzise Abhängigkeit von Infineon, STMicroelectronics, Nuvoton oder AMD ersetzt, je nach Ihrer Hardware, Unternehmen, die Jurisdiktionen, rechtlichen Zwängen und kommerziellen Imperativen unterliegen, die Sie nicht beherrschen. AMD fTPM und Intel PTT sind Firmware-Implementierungen, die direkt in den Hauptprozessor integriert sind: Die Grenze zwischen „isoliertem dediziertem Chip“ und „Code, der auf der Haupt-CPU läuft“ wird fließend. Googles OpenTitan-Projekt ist die strukturell kohärente Antwort auf dieses Problem: ein Root-of-Trust, dessen Hardware-Design und Firmware öffentlich und auditierbar sind. Es ist auf einigen neueren Chromebooks verfügbar. Für den Rest des Marktes hat sich die Lage nicht grundlegend geändert. --- ## Ende-zu-Ende-Verschlüsselung verschlüsselt nur, was die Anwendung nicht sehen will Signal ist die Referenzimplementierung der Ende-zu-Ende-Verschlüsselung für Messaging. Das Signal-Protokoll (Double Ratchet + X3DH) ist öffentlich, auditiert und von unabhängigen Kryptografen formal verifiziert. Die kryptografischen Eigenschaften sind real: Forward Secrecy, Authentifizierung, Schutz gegen die Kompromittierung langfristiger Schlüssel. Die häufige Verwechslung besteht darin, die Eigenschaften des Protokolls mit den Eigenschaften der Anwendung zu verwechseln. Die Ende-zu-Ende-Verschlüsselung schützt den Inhalt der Nachrichten auf dem Transportweg zwischen zwei Clients. Sie sagt nichts darüber aus, was der Client nach der Entschlüsselung mit dem Inhalt macht. Auf Android läuft die Signal-App in einem Prozess, der einer Speicherextraktion durch das Betriebssystem ausgesetzt werden kann, wenn dieses kompromittiert ist. Die verschlüsselten Signal-Backups auf Google Drive verwenden einen vom Benutzer-PIN abgeleiteten Schlüssel, der in einem von Signal verwalteten HSM gespeichert ist: Sie vertrauen Signal, keinen ausnutzbaren Zugang zu diesem HSM zu haben. Die Metadaten (wer wen kontaktiert, wie häufig) werden nicht auf dieselbe Weise verschlüsselt wie der Inhalt, und Signal erhebt ein Minimum, erhebt aber dennoch etwas. Ein direkteres Beispiel: WhatsApp implementiert das Signal-Protokoll für die Verschlüsselung der Nachrichten. Kontakt- und Nutzungsfrequenz-Metadaten fließen an Meta. Die Verschlüsselung ist real. Die Vertraulichkeit gegenüber Meta ist es nicht. Das ist kein technischer Fehler, sondern eine bewusste Designentscheidung, aber es veranschaulicht genau den Punkt: Das kryptografische Protokoll und die Anwendung sind zwei verschiedene Objekte mit unterschiedlichen Vertrauensmodellen. TerminalPhone, das Bash-Projekt für verschlüsselte Kommunikation über Tor, das wir in der Einleitung erwähnt haben, treibt diese Logik auf ihren logischen Endpunkt: kein Drittserver, kein Konto, keine zentralisierten Metadaten, die .onion-Adresse als einzige Identität. Das Vertrauensmodell wird auf ein Minimum reduziert: Tor Project, OpenSSL und das zugrunde liegende Betriebssystem. Das ist kohärent. Es ist zugleich ein Zeichen dafür, dass die Reduzierung der Vertrauensfläche Ergonomiekompromisse erfordert, die wenige Nutzer akzeptieren wollen. --- ## Der Compiler, den Sie nicht auditiert haben, kompiliert den Code, den Sie auditiert haben Im Jahr 1984 veröffentlichte Ken Thompson „Reflections on Trusting Trust“, einen Text, der zu den beunruhigendsten Beiträgen der Informatikgeschichte zählt. Die Demonstration: Es ist möglich, einen Trojaner so in einen Compiler einzuschleusen, dass das erzeugte Binärprogramm kompromittiert ist, selbst wenn der Quellcode vollkommen sauber ist. Der modifizierte Compiler schleust sich bei seiner eigenen Neukompilierung selbst wieder ein. Das Lesen des Quellcodes verrät nichts. Nur die Analyse des erzeugten Binärprogramms erlaubt es, die Anomalie zu erkennen. Das ist keine veraltete akademische Übung. Die Kompilierungskette eines modernen Systems umfasst: einen Compiler (GCC, Clang/LLVM), dessen jede Version Sie nicht selbst aus den Originalquellen kompiliert haben, Systembibliotheken (glibc, OpenSSL), deren Distributionsbinärdateien von Dritten erzeugt werden, einen Kernel, dessen Build-Prozess von den Teams der Distribution beherrscht wird, und eine UEFI-Firmware, deren Quellcode nur teilweise verfügbar ist (EDK2 ist Open Source, die Blobs der Hersteller nicht). Der SolarWinds-Angriff von 2020 materialisierte genau diese Bedrohung in großem Maßstab: Die Build-Kette von SolarWinds Orion wurde kompromittiert, wodurch Binärdateien erzeugt wurden, die mit dem legitimen Zertifikat des Unternehmens signiert waren, aber eine Backdoor enthielten. Tausende Organisationen installierten diese Software, nachdem sie die Signatur überprüft hatten, die korrekt war. Die Auditierung des Quellcodes hätte nichts ergeben, da die Änderung während des Builds erfolgte. Die technische Antwort auf dieses Problem heißt reproduzierbarer Build (reproducible builds): ein deterministischer Kompilierungsprozess, bei dem aus denselben Quellen und derselben Umgebung jeder bit für bit dasselbe Binärprogramm erhält. Debian führt dieses Projekt seit 2013. Bitcoin Core hat es übernommen. Die Abdeckung bleibt im gesamten Ökosystem partiell. Und selbst mit reproduzierbaren Builds bleibt das Vertrauen in den Bootstrap-Compiler notwendig: Thompsons Trusting Trust verschwindet nicht, er wird eine Ebene weitergeschoben. --- ## Was diese Analyse für das Design bedeutet Vertraulichkeit ist keine binäre Eigenschaft. Sie ist eine Funktion Ihres Bedrohungsmodells, der Position Ihrer vertrauenswürdigen Dritten in der Kette und der Wahrscheinlichkeit, dass diese Dritten in Ihrem operativen Kontext kompromittiert oder unter Druck gesetzt werden. Ein Ingenieur, der ein wirklich sensibles System entwirft, muss seine vertrauenswürdigen Dritten explizit kartieren: TPM-Hersteller, Zertifizierungsstelle, Bootstrap-Compiler, Distributionsanbieter, Cloud-Anbieter, falls zutreffend. Bei jedem Dritten lautet die Frage nicht „Ist er vertrauenswürdig?“, sondern „Was kostet eine Kompromittierung dieses Dritten, und umfasst mein Bedrohungsmodell einen Gegner, der ihn kompromittieren oder unter Druck setzen kann?“. Für ein Standard-Bedrohungsmodell (Schutz vor einem opportunistischen Angreifer, regulatorische Konformität, Schutz der Nutzerdaten) ist TPM + LUKS2 + auditiertes Protokoll eine vernünftige und vertretbare Wahl. Für ein staatliches oder hochwertiges Bedrohungsmodell ist jeder Dritte der vorstehenden Liste ein potenzieller Vektor, und die geeigneten Antworten (OpenTitan, reproducible builds, Air Gap, manuelle Passphrase anstelle der TPM-Versiegelung) stellen erhebliche operative Einschränkungen dar, die wenige Systeme vollständig übernehmen. Absolute Vertraulichkeit existiert nicht außerhalb eines Systems, dessen gesamte Kette Sie beherrschen, vom Silizium bis zur Anwendung. Diese Beherrschung ist ein Horizont, kein unter realen Produktionsbedingungen erreichbarer Zustand. Die Rigorosität besteht darin, genau zu wissen, wo Sie Ihre vertrauenswürdigen Dritten platziert haben, warum, und was Sie verlieren, wenn einer von ihnen kompromittiert wird. --- *Technische Referenzen: CVE-2017-15361 (ROCA, Infineon TPM) ; K. Thompson, „Reflections on Trusting Trust“, CACM 1984 ; Reproducible Builds project, reproducible-builds.org ; Google OpenTitan, opentitan.org ; NIST SP 800-155 (BIOS integrity measurement) ; SolarWinds supply chain attack, CISA Advisory AA20-352A.*