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