Vertrauen durch Mini-Zertifikate

„Meine Installation besteht aus einer Anwendung und vielen Bibliotheken. Ich möchte nicht, dass jemand einzelne Bibliotheken, or allem nicht die license.dll, darin austauschen kann. Ich überlege daher, eine Prüfsumme zu implementieren, aber das Problem ist dann, dass ich immer meine ganze Installation neu kompilieren und ausliefern muss.“ Diese und ähnliche Aussagen von Softwareentwicklern stehen oft am Anfang einer Diskussion, deren weiterer Verlauf zu einem Mini-Zertifikat als Lösung führt. Auch andere Anforderungen wie das sichere Auslesen einer Seriennummer führen zu einer ähnlichen Lösung. Mini-Zertifikate sind ein mächtiges Werkzeug für viele Anwendungsfälle, doch betrachten wir dies der Reihe nach.

Einfache Prüfsummen

Eine Prüfsumme ist das Ergebnis eines Verfahrens, welches beliebig lange Daten auf eine Zahl abbildet. Ändern sich die Daten, dann ändert sich die Prüfsumme. Bekannte Beispiele sind CRC- und Modulo-Verfahren. Diese Verfahren werden meist verwendet, um Übertragungs- oder Eingabefehler zu verhindern bzw. deren Wahrscheinlichkeit zu reduzieren. So haben zum Beispiel Kreditkartennummern oder die IBAN eine Prüfsumme, so dass eine Anwendung Eingabefehler bereits erkennen kann, bevor die Daten überhaupt an die Bank oder den Dienstleister übermittelt werden.

Kryptographische Prüfsummen

Einfache Prüfsummen helfen natürlich nicht gegen böswilligen Betrug. Hier werden kryptographische Prüfsummen benötigt. Dabei gilt, dass kleine Änderungen der Daten die Prüfsumme stark ändern. Es ist nicht möglich, Daten so zu manipulieren, dass sie immer noch zu einer gegebenen Prüfsumme passen. So wird zum Beispiel verhindert, dass Daten so lange mit Leerzeichen aufgefüllt werden, bis sie zu einer vorgegebenen Prüfsumme passen. Ein bekanntes aktuelles Verfahren ist SHA256. Das in der Vergangenheit sehr häufig eingesetzte MD5-Verfahren gilt heute als nicht mehr sicher.

Auch kryptographische Prüfsummen haben ihre Grenzen. Zum Prüfen werden die gleichen Informationen benötigt wie zum Erzeugen einer solchen Prüfsumme; dies sind das Verfahren selbst und optional ein Salt-Wert, der als gemeinsames Geheimnis dient. Diese Informationen müssen in der prüfenden Software hinterlegt werden. Wenn nur ein einziger Angreifer diese Daten extrahiert und veröffentlicht, ist damit das komplette System kompromittiert. Es könnten gültige Prüfsummen für Bibliotheken erzeugt werden, die nicht vom Original zu unterscheiden wären.

Dies führt zu abenteuerlichen Konstrukten, bei denen die Prüfsummen der verschiedenen Bibliotheken in den anderen Bibliotheken und der Anwendung hinterlegt werden, was genau zu der eingangs beschriebenen Auslieferungs-Problematik führt.

Asymmetrische Kryptographie

Hier hilft die asymmetrische Kryptographie mit der Verwendung von Schlüsselpaaren: ein privater Schlüssel, der geheim gehalten wird, und ein öffentlicher Schlüssel, den jeder kennen darf. Mit dem privaten Schlüssel wird etwas unterschrieben. Diese Operation kann nur der Besitzer dieses Schlüssels durchführen. Mit dem öffentlichen Schlüssel wird die Unterschrift (Signatur) geprüft; diese Operation kann von vielen durchgeführt werden. Und das Beste ist: Aus dem Wissen des öffentlichen Schlüssels kann keine gültige Unterschrift erzeugt werden.

Da asymmetrische Kryptographie in der Regel sehr langsam ist und Daten einer entsprechenden Größe erwartet, kombiniert man die Unterschrift mit einer kryptographischen Prüfsumme. Es wird zuerst die Prüfsumme der Daten gebildet und diese dann signiert. Beim Prüfen erfolgen die gleichen Schritte. Die Prüfsumme wird erneut gebildet und gegen den öffentlichen Schlüssel und die Unterschrift geprüft. Bekannte Verfahren sind ECDSA und RSA.

Die Grundausrüstung

Damit haben wir das Grundwerkzeug, um unsere Bibliotheken und die Anwendung zu unterschreiben. Zuerst wird während der Entwicklung der öffentliche Schlüssel in der Software hinterlegt.

Nach dem Kompilieren wird mit dem privaten Schlüssel die Unterschrift jedes Moduls (Bibliothek oder Anwendung) gebildet. Die Unterschrift wird mit jedem Modul ausgeliefert. Dies kann eine extra Datei sein oder die Unterschrift kann an einen dafür vorgesehenen Platz in der Ressourcen-Sektion eingefügt werden.

Beim Prüfen wird die Prüfsumme erneut gebildet. Falls sich die Unterschrift in der Ressourcen-Sektion befindet, wird diese dabei natürlich ausgenommen. Danach wird die Prüfsumme gegen Unterschrift und öffentlichen Schlüssel geprüft.

Wenn eine Unterschrift nicht ausreicht

Hier könnte der Artikel schon zu Ende sein, wenn wir uns nicht um mögliche zukünftige Anforderungen dieser Lösung Gedanken machen. Doch entgegen den Clean-Code-Prinzipien, die zum Beispiel besagen, dass man keine zukünftigen Anforderungen betrachten soll, bin ich der Meinung, dass man bei Sicherheitsthemen immer auch an die Zukunft denken sollte. Stellen wir uns einfach die folgenden Fragen:

1. Wollen wir gewappnet sein, falls der private Schlüssel gestohlen wird?
2. Wollen wir mehreren Entwicklern die Möglichkeit geben, Module zu unterschreiben?
3. Sollen Module von Partnerfirmen in unserem Universum zugelassen werden?
4. Sollen Test- und Produktionssysteme sauber voneinander getrennt sein?

Dies ist ein Fall für Mini-Zertifikate. Ein Mini-Zertifikat enthält im Wesentlichen einen öffentlichen Schlüssel, von Ihnen definierte Berechtigungen (Flags) und eine Unterschrift des öffentlichen Schlüssels. Sie sind an X.509-Zertifikate angelehnt, aber viel schlanker und durch ein von Ihnen definiertes Binärformat viel handlicher.

Erste Schritte zum Mini-Zertifikat

Sie erzeugen zuerst ein neues Schlüsselpaar. Dies ist das Wurzel-Schlüsselpaar, im englischen „Root“ genannt. Den öffentlichen Wurzel-Schlüssel implementierten Sie in Ihre Software. Parallel zu der Implementierung des öffentlichen Schlüssels erzeugen Sie ein weiteres Schlüsselpaar. Mit dem privaten Wurzel-Schlüssel erzeugen Sie dann das Mini-Zertifikat für den öffentlichen Schlüssel des neuen Schlüsselpaars. Danach verstauen Sie den privaten Wurzel-Schlüssel an einem sicheren Ort. „Sicher“ in Form von „geschützt gegen fremden Zugriff“ und „sicher“ im Sinn von „unvergänglich“. Experten empfehlen Ausdruck und digitale Speicherung an zwei verschiedenen Orten. Der private Wurzel-Schlüssel wird ab jetzt nur noch ganz selten benötigt.

Mit dem neuen privaten Schlüssel unterschreiben Sie nun im täglichen Arbeitsablauf Ihre Module. Neben der Unterschrift fügen Sie noch das Mini-Zertifikat des neuen öffentlichen Schlüssels zu dem Modul hinzu. Beim Prüfen wird zuerst das Zertifikat gegen den öffentlichen Wurzel-Schlüssel geprüft und dann die Unterschrift der zu prüfenden Daten gegen den öffentlichen Schlüssel im Mini-Zertifikat.

Mehrere Stufen – Zertifikats-Ketten

Der eben geschilderte Fall umfasst zwei Stufen: Das Wurzel-Schlüsselpaar und das eigentlich verwendete Schlüsselpaar. Dies ist die empfohlene Minimalauslieferung. Prinzipiell kann dieses Verfahren auch mehr als zwei Stufen umfassen. Dann wird mit dem zweiten privaten Schlüssel der öffentliche Schlüssel eines dritten Schlüsselpaars unterschrieben. Es können damit Bäume aufgebaut werden. Je nach den von Ihnen gewählten Flags können Berechtigungen vererbt werden, zum Beispiel das Ausstellen weiterer Mini-Zertifikate.

Weitere Schlüssel

Den privaten Wurzel-Schlüssel benötigen Sie nur noch, wenn weitere Schlüssel zum System hinzukommen oder alte Schlüssel entfernt werden sollen. Bei einem mehr als zweistufigen Prozess benötigen Sie ihn sogar noch seltener, wenn die Schlüssel der zweiten Ebene diese Funktionen bereits übernehmen. Dann wird der Wurzel-Schlüssel nur benötigt, wenn ein Schlüssel der zweiten Ebene wegfällt oder hinzukommt.

Wegfall von Schlüsseln

Für den Wegfall von Schlüsseln gibt es zwei Strategien:

• Eine Sperrliste (Revokation List)
• Der automatische Ablauf der Zertifikate

Eine Sperrliste beinhaltet ungültige Zertifikate. Geräte, die diese nicht kennen, weil sie zum Beispiel nicht online sind, verwenden weiterhin die alten Zertifikate, auch wenn diese gesperrt wurden. Der automatische Ablauf erfordert eine Möglichkeit, Zertifikate zu erneuern. Als Quintessenz kann man sagen, dass der Wegfall von Schlüsseln eine Übertragung von Daten auf die betroffenen Geräte erfordert. Über die beiden vorgestellten Strategien können Sie zwischen „Reliability First“ oder „Security First“ entscheiden.

Sicheres Auslesen einer Seriennummer

Ein weiterer Anwendungsfall für Mini-Zertifikate ist das sichere Auslesen einer Seriennummer. Ein CmDongle wird mit einem Schlüsselpaar versehen. Für den öffentlichen Schlüssel wird ein Mini-Zertifikat mit dem privaten Wurzel-Schlüssel erzeugt. Dies wird dann mit dem CmDongle an den Anwender ausgeliefert, zum Beispiel als Extended Protected Data im CmDongle.

Die prüfende Instanz erzeugt eine Herausforderung (Challenge), die der CmDongle mit dem privaten Schlüssel unterschreibt. Genaugenommen erzeugen prüfende Instanz und die zu prüfende Seite jeweils einen Teil der Challenge. Die prüfende Instanz erhält die Antwort (Response) auf die Challenge und das Mini-Zertifikat. Mit dem öffentlichen Wurzel-Schlüssel prüft sie das Mini-Zertifikat und mit dem darin enthaltenen Schlüssel, ob die Response zur Challenge passt. Falls ja, gilt die Identität des CmDongles als kryptographisch bewiesen.

Dieses Verfahren wird heute bereits mehrfach in der Praxis verwendet, um Identitäten sicherzustellen. Beispiele sind Hersteller, die Flexnet mit einer sicheren ID ausstatten oder Laser-Maschinen, die sich im Service-Netzwerk authentifizieren.

Anwendungsfälle für Integritätsschutz

Neben dem genannten Einsatz als sichere ID findet dieses Verfahren vor allem Verwendung, um Module gegen Veränderung und Austausch zu schützen. Damit kann zum Beispiel sichergestellt werden, dass die am Anfang erwähnte license.dll unterschrieben ist und nicht gegen eine Fake-Dll ausgetauscht werden kann – speziell eine Fake-Dll, die behauptet, dass alle Lizenzen vorhanden sind. Dies ist eine elegante Möglichkeit, eine Lizenzierung zu kapseln und somit einfach zu implementieren. Dennoch ist die Empfehlung von Wibu-Systems, die einzelnen Module mittels CodeMeter Protection Suite automatisch zu schützen und die Lizenzabfragen dort direkt zu implementieren. Dies erhöht die Sicherheit, vor allem beim Einsatz von CodeMeter Protection Suite. Mehr dazu finden Sie in Artikel „CodeMeter Protection Suite“ in dieser Ausgabe.

 

KEYnote 36 – Herbstausgabe 2018