Die dunkle Seite der Kryptografie Kleptografie bei Black-Box-Implementierungen

Ordnungsmerkmale

erschienen in: <kes> 2010^#4, Seite 6

Zusammenfassung: Hardware-Security-Module (HSM) und andere Black-Box-Implementierungen sollen wichtige Krypto-Schlüssel sicher kapseln. Doch bei entsprechender Implementierung kann die Kryptografie selbst als verdeckter Kanal missbraucht werden, um vermeintlich Unkopierbares aus dem Schlüsselspeicher zu schmuggeln.

Autor: Von Bernhard Esslinger, Siegen

Obwohl bereits seit Mitte der Neunzigerjahre bekannt [1], wurde der Kleptografie bisher keine große Aufmerksamkeit geschenkt. Dabei handelt es sich keineswegs nur um eine theoretische Gefahr, sondern inzwischen wurden mehrere kleptografische Angriffe beispielhaft implementiert. Ein grundlegender Aspekt von Black-Box-Kryptosystemen wird hierbei zum Problem: Hardware-Security-Module (HSM), Smartcards oder auch Trusted-Platform-Modules (TPMs) sollen kryptografische Inhalte sicher versiegeln und ihren Inhalt vor jeglichem Zugriff von außen schützen. Somit bleibt aber auch der Besitzer ein Stück weit im Ungewissen und kann sich nicht sicher sein, ob die Black Box genau das macht, was sie soll – oder doch etwas mehr?!

Wenn die Manipulation eines solchen Kryptosystems von außen nicht erkennbar ist und auch die generierten Ausgaben keinen Verdacht auslösen, kann man letztlich nur auf den Hersteller vertrauen. Dabei können sich (nicht nur eingefleischte) Verschwörungstheoretiker auch die Einflussnahme von Regierungsorganisationen auf manche Hersteller vorstellen.

Kleptografie

Kleptografie ist das Studium vom sicheren und unterschwelligen Stehlen von Informationen ("study of stealing information securely and subliminally" [2]). Unter einem kleptografischen Angriff versteht man einen Angriff, bei dem ein böswilliger Entwickler eine kryptografische Hintertür implementiert, bei der er asymmetrische Verschlüsselung nutzt. Hier wird Kryptografie gegen Kryptografie eingesetzt – es geht also nicht um eine Hintertür, die außerhalb des Kryptosystems einen zusätzlichen Kanal oder zusätzliche Datenübertragungen eröffnet, sondern um "eingebaute" Missbrauchsmöglichkeiten innerhalb der vorgesehenen Kommunikation. Kleptografie gehört zum Themengebiet der Kryptovirolgie, die sich allgemein mit der Anwendung von Kryptografie in Schadsoftware beschäftigt [3,6,11] – bei der Kleptografie ist dann keine allgemeine Software, sondern ein Kryptosystem Ziel des Angriffes.

Das folgende Szenario beschreibt einen möglichen kleptografischen Angriff: Eine Black-Box generiert asymmetrische Schlüsselpaare, jeweils bestehend aus einem geheimen (Private Key) und einem öffentlichen Schlüssel (Public Key). Die geheimen Schlüssel, die zum Entschlüsseln und zur Signaturerstellung dienen, sollen ausschließlich in der Black Box verbleiben, um sie gegen missbräuchliche Nutzung und Kopie zu schützen – nur die öffentlichen Schlüssel werden exportiert. Wie allgemein bekannt, kann niemand aus den öffentlichen Schlüsseln die zugehörigen geheimen Schlüssel berechnen –oder doch?

Tatsächlich wird dies möglich, sofern bei der Schlüsselgenerierung entsprechende manipulative Schritte erfolgt sind. Bei der Implementierung könnte eine kryptografische Hintertür eingebaut worden sein, mit deren Hilfe der Angreifer im Nachhinein die erzeugten geheimen Schlüssel ermitteln kann – und niemand merkt etwas: weder sind die erzeugten öffentlichen Schlüssel irgendwie auffällig, noch gibt es irgendwelche unerwartete Kommunikation oder Fehler bei der Nutzung der kryptografischen Funktionen. Die Auswirkungen sind jedoch fatal: Mit dem "geklonten" geheimen Schlüssel kann der Angreifer Daten entschlüsseln oder Signaturen fälschen, obwohl der Kryptoschlüssel in der abgeschotteten Black Box generiert wurde und darin weiterhin vor unberechtigtem Zugriff geschützt ist.

In einem vereinfachten Angriff könnte eine Manipulation im Zufallszahlengenerator erfolgen (s. a. Abb. 1), sodass bei der Generierung von Schlüsseln statt echter Zufallszahlen eine Pseudozufallsfunktion mit einem – dem Angreifer bekannten – Startwert (Seed) benutzt wird: Durch das Wissen um die erzeugten Primzahlen könnte dieser dann "parallel" ebenfalls die geheimen Schlüssel berechnen. Eine derartige Manipulation kann im Prinzip durch Reverse-Engineering entdeckt werden, sofern keine Sicherheitsmechanismen (wie bei der Implementierung in dedizierter Kryptohardware) den Zugriff auf den Code unmöglich machen. Da der Startwert der Pseudozufallsfunktion im Code verankert ist, könnte dann auch der Entdecker die geheimen Schlüssel nachberechnen – bei "besseren" Angriffen (s. u.), ist dies jedoch nicht mehr der Fall.

Abbildung 1: Kleptografische Angriffe sind in allen dargestellten Komponenten eines Kryptosystems möglich – die Kapselung einer Black-Box-Implementierung schützt dabei gleichermaßen die gewünschte wie die missbräuchliche Implementierung gegen den Zugriff von außen.

SETUP-Angriff

Erstmals diskutiert wurde Kleptografie bereits 1996 auf der CRYPTO-Konferenz, als Adam Young und Moti Yung auf zahlreiche Angriffsmöglichkeiten gegen Kryptografie in Black-Box-Systemen aufmerksam machten [1]. Bereits damals wurde der Begriff "Secretly Embedded Trapdoor with Universal Protection" als SETUP-Angriff eingeführt und im Hinblick auf die RSA-Schlüsselerzeugung beschrieben. Charakteristisch ist, dass ein SETUP-Angriff (wenn überhaupt) nur durch Reverse-Engineering zu entdecken ist, aber der Entdecker den Angriff dennoch nicht selbst nutzen kann: Der Reverse-Engineer wird im Allgemeinen nur den öffentlichen Schlüssel, aber nicht den geheimen Schlüssel des Angreifers finden, sodass dieser auf asymmetrischer Kryptografie basierende Angriff als "sicher" bezeichnet werden darf – aus Sicht des Angreifers. Das mathematische Prinzip einer Version des SETUP-Angriffes auf die RSA-Schlüsselgenerierung ist im folgenden Kasten skizziert. Zum besseren "Kennenlernen" sind zudem mehrere kleptografische Angriffe im Lernprogramm JCrypTool implementiert (siehe Kasten "JCrypTool", vgl. Abb. 2).

Abbildung 2: Für das E-Learning-Werkzeug "JCrypTool" existiert ein Plugin, das die Möglichkeiten der Kleptografie verdeutlicht.

Im Laufe der Jahre wurde der SETUP-Angriff weiterentwickelt: Die ersten Attacken zielten auf Verfahren, die auf dem Problem der Primfaktorzerlegung (z. B. RSA) beruhen. Bald wurden jedoch auch Angriffe auf Verfahren veröffentlicht, die auf dem Diskreten-Logarithmus-Problem basieren: So wurde 2002 ein starker SETUP-Angriff auf den Diffie-Hellman-Schlüsselaustausch beschrieben [2]. Im Dezember 2009 wies Moti Yung auf dem 26. Chaos Communication Congress (26C3) mit seinem Vortrag "Yes We Can't!" [5] erneut auf die Problematik hin und betonte, dass Kleptografie das Vertrauen in den Hersteller einschränkt: "I will discuss some of the results and their influence on the limitation of the notion of 'trust' in systems...", so Yung in Berlin.

Gegenmaßnahmen

Doch warum wurde der Kleptografie bisher kaum Aufmerksamkeit geschenkt, obwohl der Einsatz von Hardware-Kryptosystemen doch gerade dort erfolgt, wo sehr hohe Sicherheitsanforderungen gestellt werden? Schließlich werden etwa HSMs benutzt, um besonders sensitive Infrastrukturschlüssel in Unternehmen zu schützen – also dort, wo der mögliche finanzielle und reputative Schaden bei einem erfolgreichen Angriff auf diese Schlüssel sehr hoch ist. Möglicherweise ist die grundlegende Problematik noch nicht hinreichend bekannt? Eine andere Erklärung könnte die Annahme der Nutzer sein, dass der Hersteller ein Interesse daran haben müsste, keine manipulierte Hardware zu verkaufen – denn er würde wohl vom Markt verschwinden, wenn so etwas "auffliegt".

Bei sicherheitsrelevanter Industriehardware in der EU wird zudem auf unabhängig voneinander durchgeführte Evaluationen in zwei verschiedenen EU-Staaten gesetzt, um eine möglichst hohe Transparenz über die gesamte Produktion zu erlangen. Zudem gibt es den Ansatz, Hardware verschiedener Hersteller kombiniert einzusetzen: So könnte man beispielsweise zwei Smartcards verschiedener (unabhängiger!) Hersteller benutzen und Dateien zweimal nacheinander verschlüsseln (Kaskadenverschlüsselung [6]). Somit könnte ein Hersteller allein, selbst wenn er die Schlüsselgenerierung manipuliert hätte, keine Daten entschlüsseln, da er den zweiten geheimen Schlüssel der anderen Smartcard nicht kennt. Doch mit diesen beiden Ansätzen kann man das Risiko lediglich minimieren – eine Garantie gegen Manipulationen bieten sie jedoch nicht und der erhöhte Aufwand macht sie eher unpraktikabel.

Da bei der Kleptografie ein verdeckter Kanal genutzt wird, um Informationen unentdeckt aus der Black Box zu schmuggeln, könnte man überdies versuchen, alle möglichen verdeckten Kanäle zu eliminieren. Erste Ideen dazu wurden 1984 von Gus Simmons [7] sowie später auch in weiteren Publikationen [8,9] vorgestellt, indem man etwa bei Authentisierungsprotokollen Zufallszahlen einbaut. Konkretere Ansätze wurden beispielsweise 2002 mit einem Verfahren vorgestellt, bei dem ein Dritter die RSA-Schlüsselgenerierung verifizieren kann [10]: Dabei kommt eine Art verteilte Schlüsselgenerierung zum Einsatz, wobei der geheime Schlüssel aber nur der Black Box bekannt ist – somit wäre sichergestellt, dass die Schlüsselgenerierung nicht modifiziert wurde und der Schlüssel nicht durch einen kleptografischen Angriff aufgedeckt werden kann. Zumindest die Forschung sucht also durchaus aktiv nach Möglichkeiten, um die Bedrohung durch Kleptografie zu bekämpfen.

Fazit

Kleptografie ist kryptografisch sehr interessant, aber in der Praxis nur eine von mehreren Bedrohungen im gesamten System: So ist es zumeist einfacher, nicht die Krypto-Implementierung selbst, sondern andere beteiligte Komponenten anzugreifen – etwa am Endpunkt. So könnte man zum Beispiel vertrauliche Daten auf einem PC mit einem Trojaner abfangen, bevor sie überhaupt mit einer Smartcard verschlüsselt werden. Ein System ist immer nur so sicher wie das schwächste Glied in der Kette – Kleptografie und ihre Abwehr werden daher vermutlich erst dann deutlich an Bedeutung gewinnen, wenn derartige Angriffe auf andere Komponenten zu schwer werden.

Man sollte aber nicht vergessen, dass sich bei besonders hohen Sicherheitsanforderungen möglicherweise schon heute der Aufwand lohnen könnte. Und auch wenn sich dieses Beispiel nicht 1:1 auf abgeschottete Black-Box-Systeme übertragen lässt, hat das Auftreten einer manipulationsanfälligen Firmwareupdatefunktion in einem sicherheitsevaluierten Chipkartenterminal ( http://colibri.net63.net/Smartcard-Reader%20von%20Kobil%20geknackt.pdf) im Frühsommer 2010 doch eindringlich gezeigt, dass es auch im stark regulierten Bereich nicht unbedingt der Hersteller sein muss, der Hintertüren einbaut und damit seine Existenz aufs Spiel setzt.

Prof. Bernhard Esslinger lehrt IT-Security und Kryptografie an der Uni Siegen und leitet das Open-Source-Projekt CrypTool.

zurück zum Inhalt
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2010^#4, Seite 6
tag:kes.info,2007:lp:2010-4-B