KEYnote 36 Deutsch - Ausgabe Herbst 2018 - Page 10

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-