Wie bereits angekündigt werde ich in den nächsten Wochen einige Aspekte asymmetrischer Kryptographie beschreiben. Der vorliegende Artikel erläutert einige Kernaspekte des Code Signing unter anderem mit Blick auf die Verifikation dieser Signaturen in unterschiedlichen Betriebssystemen und Laufzeitumgebungen.

Code Signing ist ein interessanter Fall der Anwendung elektronischer Signaturen: Elektronische Signaturen haben je nach Anwendungsfall unterschiedliche Lebenszeiten. Das Besondere hieran ist, dass Signaturen ohne weitere Vorkehrungen ungültig sind, sobald die Lebenszeit des Zertifikats abgelaufen ist, das zu der Digitalen Identität gehört, deren Schlüssel zur Erzeugung der Signatur benutzt wurden. Speziell beim Code signing ist es aber so, dass die Signatur erst lange nach dem Ende der Lebenszeit des erzeugenden Zertifikats geprüft wird. Für diesen Fall - Prüfung einer Signatur nach Ablauf der Lebenszeit des Zertifikats - existiert ein standardisiertes Vorgehen: Elektronische Signaturen haben keine Angabe darüber, wann sie erstellt wurden. Hätte man diese Information, dann könnte man die Prüfung anders gestalten: Statt zu fragen: Ist das Zertifikat gültig? kann man jetzt fragen: War das Zertifikat gültig, als die Signatur erstellt wurde und war das Zertifikat zu diesem Zeitpunkt gültig? Falls diese Fragen mit ja beantwortet werden ist die Signatur gültig und diese Prüfung kann noch lange nach Ende der Lebenszeit des Zertifikates erfolgen. Zur beweisfewsten Langzeitarchivierung hatte ich ja im Rahmen dieser Serie ja bereits etwas geschrieben. Daher muss man sich für jeden Anwendungsfall die Frage stellen, ob relying Parties die Signaturen prüfen müssen, nachdem die Lebenszeit der Zertifikate abgelaufen ist - in diesem Fall sind kryprographische Zeitstempel vorzusehen. Dabei ist sehr wichtig, dass diese Zeitstempel beziehungsweise die digitalen Identitäten zu ihrer Erstellung von einer unabhängigen CA ausgestellt werden - unabhängig von der PKI, von der die digitale Identität zur Erstellung des Signatur beglaubigt wurde.

Code Signing ist zwar seit langem ein probates Mittel zur Sicherung der Integrität von Software, jedoch bleibt auch hier die Zeit nicht stehen: RFC9809 hat zum Beispiel Mitte disen Jahres neue Key Usages eingeführt, die es erlauben, die Verwendung digitaler Identitäten dafür feiner steuern zu können. Die Expect Dialog CA unterstützt diese neuen Key Usages. Aber es stellt sich immer wider die Frage: wie genau und wann und von wem werden diese Signaturen eigentlich geprüft? Prinzipiell ist es natürlich immer möglich, eine solche Validierung der Signatur in die eigene Applikation zu integrieren - das widerspricht aber dem Grundsatz, nie eigene Crypto zu implementieren.

Welche Möglichkeiten existieren also sonst noch? Hier muss man unterscheiden zwischen Möglichkeiten, die das Betriebssystem bereitstellt und solchen, die von der Sprache/dem Framework zur Verfügung gestellt werden.

Java ist hier vorbildlich: alle signierten Java-Anwendungen werden vor dem Start einer Validierung der Signaturen unterzogen und der Start schlägt fehl, sobald die Signaturen ungültig oder die Zertifikate ungültig, abgelaufen, zurückgezogen oder nicht vertrauenswürdig sind oder aus einem anderen Grund nicht validiert werden können.

Mit AppLocker existiert in Wiondows eine Möglichkeit, Anwendungen nur dann auszuführen, wenn sie signiert sind und die Prüfung der Integrität der Signatur und die Gültigkeit unbd Vertrauenswürdigkeit der benutzten Zertifikate erfolgreich durchgeführt werden konnte.

Unter Linux scheint es bis zum heutigen Tag keine Möglichkeit zu geben, die Verifikation und Validierung von signed Code durch das Betriebssystem oder den Kernel automatisch erledigen zu lassen.

Es sei hier noch erwähnt, dass sich Code Signing natürlich nicht auf Executables oder Bibliotheken beschränkt. Oben habe ich bereits darauf hingewiesen, dass es jetzt sogar eigene Key Usages für zum Beispiel Konfigurationsdateien gibt.

Unter Code Signing zähle ich auch Secure Boot. Dabei ist es mir wichtig, zu betonen, dass mit Secure Boot nicht gemeint ist, nur die CheckBox in UEFI/BIOS anzuhaken - Echtes Secure Boot steht und fällt mit der Möglichkeit, eigene Schlüssel zu benutzen und eigene Zertifikate im UEFI/BIOS zu hinterlegen - nur damit wird es können nur valide signierte Betriebssysteme gestartet weren zu es kann nur mein Betriebssystem gestartet weren. Dafür existieren zum Beispiel für Linux komplette Toolchains. Interessant ist hierbei, dass für Secure Boot Signing keinerlei Vorgaben hinsichtlich der Key Usages existieren!

Abschließend hier noch ein Link zum (proprietären) Signieren einer Binärdatei und dem manuellen Verifizieren einer Signatur.

Artikel, die hierher verlinken