KEYnote 36 Deutsch - Ausgabe Herbst 2018 | Page 11

und „sicher“ im Sinn von „unvergänglich“. Experten empfehlen Ausdruck und digi- tale Speicherung an zwei verschiedenen Orten. Der private Wurzel-Schlüssel wird ab jetzt nur noch ganz selten benötigt. Sektion befindet, wird diese dabei natürlich aus- genommen. 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 An- forderungen 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 Sicherheitsthe- men immer auch an die Zukunft denken sollte. Stellen wir uns einfach die folgenden Fragen: 1. Wollen wir gewappnet sein, falls der priva- te Schlüssel gestohlen wird? 2. Wollen wir mehreren Entwicklern die Mög- lichkeit 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-Zer- tifikat 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 an- gelehnt, aber viel schlanker und durch ein von Ihnen definiertes Binärformat viel handlicher. Erste Schritte zum Mini-Zertifikat Sie erzeugen zuerst ein neues Schlüssel- paar. 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üssel- paars. Danach verstauen Sie den privaten Wurzel-Schlüssel an einem sicheren Ort. „Sicher“ in Form von „geschützt gegen fremden Zugriff“ Mit dem neuen privaten Schlüssel unterschreiben Sie nun im täglichen Arbeits- ablauf 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 – Zertifikatsketten Der eben geschilderte Fall umfasst zwei Stufen: Das Wurzel-Schlüsselpaar und das eigentlich verwendete Schlüsselpaar. Dies ist die emp- fohlene 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üs- sel 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 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 mehr- fach 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 vor- handen 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 „CodeMe- ter Protection Suite“ in dieser Ausgabe. 11