S E C U R I T Y
Vertrauen durch Mini-Zertifikate
„Meine Installation besteht aus einer Anwendung und vielen Bibliotheken. Ich möchte nicht, dass jemand einzelne Bibliotheken,
vor 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 Ver-
fahren werden meist verwendet, um Über-
tragungs- 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 krypto-
graphische Prüfsummen benötigt. Dabei gilt,
dass kleine Änderungen der Daten die Prüf-
summe 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
10
ihre Grenzen. Zum Prüfen werden die gleichen
Informationen benötigt wie zum Erzeugen
einer solchen Prüfsumme; dies sind das Ver-
fahren selbst und optional ein Salt-Wert, der als
gemeinsames Geheimnis dient. Diese Informa-
tionen müssen in der prüfenden Software hin-
terlegt 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 Biblio-
theken in den anderen Bibliotheken und der
Anwendung hinterlegt werden, was genau zu
der eingangs beschriebenen Auslieferungs-Pro-
blematik 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 Unter-
schrift 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 öffent-
lichen 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 (Biblio-
thek oder Anwendung) gebildet. Die Unter-
schrift 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 gebil-
det. Falls sich die Unterschrift in der Ressourcen-