Mir hat grad mein Freund Till Argumente für eine Verteidigung gegen Trusting Trust per DDC geschrieben
Till bezieht sich dabei auf einen Text Schneiers (es geht um diesen Blogartikel). Theoretisch hat Till (und mit ihm Schneier) recht. Allerdings seh ich eines immer noch anders:
Die Verteidigung ist insofern besser als nichts, dass man damit erfolgreich testen kann, wenn man noch einen korrekten Compiler hat – man muss nicht wissen, welcher kompromittiert ist und welcher nicht. Auch tun's zwei verschiedenartig kompromittierte. Jedoch bleibt das m.E. praxisfern.
Der Grund dafür ist, dass wenn ich solche Angriffe fürchte, dann hab ich als Gegner die Schlapphüte, namentlich die NSA. Und die kennen DDC. Das ist keine sichere Abwehr, und das bedeutet, wenn man sie kennt, kompromittiert man die Compiler gleichartig, oder man lässt's. DDC ist dadurch wirkungslos.
Neben solcherart Angreifern spielt Trusting Trust in der Praxis kaum eine Rolle. Der Grund ist, dass Büchsenöffnen meist viel einfacher zu haben ist – owne ich die Entwicklerkiste oder die für's Deployment, dann heisst's “scheiss auf den Compiler”. Man denke an die aktuelle Firmwarebackdoor für Festplatten oder die kompromittierten Schlüssel für Chipkarten. Trusting Trust ist also praxisrelevant dort, wo es um Angreifer der Schlapphutkategorie geht, die zusätzlich zum Büchsenöffnen noch eine Backdoor implementieren (oder um geniale Spielkinder mit einem Hang zu dunklem Humor ;-)
Kurz: Till hat recht. Aber das überzeugt mich leider nicht ;-) Den “Bullshit” nehm ich jedoch zurück. Netter Versuch, ob's in der Praxis taugt, wage ich zu bezweifeln. Übrigens geht's auch nur für Compiler, die ihre eigene Sprache übersetzen.
publiziert Tue, 24 Feb 2015 22:31:21 +0100 #security