07 - 10 - 2024

Code Signing - Eine Anleitung

Bewertung:  / 20
SchwachSuper 
Die meisten Programmierer kennen die folgende Meldung bei Start einer Applikation unter Windows, die über eine fehlende Signierung der eigenen Applikation informiert. Diese Anleitung beschreibt in 3 Schritten, wie man die eigene Applikation im Visual Studio digital signieren kann.
HelloWorld-ManufacturerUnknown

Es gibt durchaus legitime Beispiele für erhöhte Administratoren-Rechte, wie zum Beispiel die Installation neuer Software. Aber es gibt auch Schadcode der so versuchen könnte Zugriff auf den Computer zu erhalten. Bei unbekannten Hersteller muss man entweder der Software vertrauen (z.B. weil sie von einem engen Bekannten stammen) oder das Risiko einer Infektion des Computers eingehen.

Um dem Benutzer zu signalisieren von wem die Software wirklich stammt, können Applikations-Entwickler ihre Applikationen digital signieren mit sogenannten Code Signing Zertifikaten. Ganz nebenbei ist damit nicht nur sichergestellt, von wem die zu startende Applikation wirklich stammt, sondern auch, dass es sich um das unveränderte Original vom Entwickler handelt.

Code Signing Zertifikate müssen käuflich erworben werden, aber heute kosten diese Zertifikate nicht mehr die Welt und lassen sich auch recht einfach in ein Visual Studio Projekt integrieren wenn man denn weiß wie es geht. In der nachfolgenden Anleitung beschreibe ich deshalb in 3 Schritten, wie man die eigene Applikation im Visual Studio digital signieren kann:

Schritt 1. Einen eigenen Schlüssel erzeugen

Bevor Sie sich einen eigenen digitalen Schlüssel erzeugen können müssen Sie erst einmal die dafür nötige Software OpenSSL herunterladen und installieren. Ich nutze hierfür OpenSSL:

Anschließend wird dann ein eigener neuer digitaler Schlüssel erzeugt mit folgenden Script:

c:
cd /OpenSSL-Win32
set PATH=%PATH%;c:/OpenSSL-Win32/bin
set OPENSSL_CONF=c:/OpenSSL-Win32/bin/openssl.cfg
openssl req -newkey rsa:4096 -keyout codesign.key -out codesign.csr

Das Programm fragt nun nach Passwort, Länderkürzel, Bundesland, Stadt, Name der Organisation, Abteilung, Namen, E-Mail-Adresse sowie zwei optionalen Angaben. Wenn Sie alles mit Enter bestätigt haben, erstellt OpenSSL im Ordner "c:\OpenSSL-Win32" die Dateien "codesign.key" und "codesign.csr".

Schritt 2. Zertifizierung des Schlüssel bei einer Zertifizierungsstelle im Internet (kostenpflichtig)

Mit dem Code Signing Request (Datei "codesign.csr") ausgestattet wenden Sie sich jetzt an eine Zertifizierungsstelle im Internet. Am Beispiel der Zertifizierungsstelle StartSSL (http://www.startssl.com) würde das wie folgt ablaufen:

Wenn Sie das Zertifikat als Privatperson anfordern, müssen Sie vorab zwei der folgenden drei Dokumente in Form eingescannter Dateien bereit halten:

  • Personalausweis (Vorder- und Rückseite)
  • Reisepass (Alle Seiten)
  • Führerschein (alle Seiten)

 

Außerdem wird eine auf ihren Namen ausgestellte aktuelle Telefonrechnung benötigt. Die eingescannten Bilddateien dürfen keine höhere Auflösung als 1440x1440 Pixel und nicht mehr als 1MB Größe haben.

Nach der kostenlosen Registrierung und Anmeldung bei StartSSL (https://www.startssl.com) wird im geschlossenen Bereich der Validierungs-Assistent für die Class 2 Validierung gestartet:

StartSSL-Class2Validation

Während des Validierungsvorgangs werden die oben angegebenen Dokumente angefordert und müssen hochgeladen werden. Wenn der Validierungs-Assistent durchgelaufen ist und es fehlen noch Dokumente werden Sie ggf. noch per E-Mail (auf Englisch) von einem StartSSL-Mitarbeiter kontaktiert und aufgefordert die fehlenden Dokumente nachzureichen. Sobald der Mitarbeiter alle erforderlichen Angaben geprüft hat, wird er Sie persönlich anrufen und stellt ihnen mehrere individuelle Fragen. In meinem Fall war das die Nachfrage nach dem Geburtstag und Geburtsort. Keine Ahnung wie der StartSSL-Mitarbeiter das nachprüfen will aber er war dann zufrieden und schloss den Validierungsvorgang damit ab.

Diese Class 2 Validierung kostet bei StartSSL 60 USD und muss alle 2 Jahre wiederholt werden. Für die Abrechnung bietet StartSSL mehrere Zahlungsmöglichkeiten an.

Erstellen des Zertifikats

Nach der erfolgreichen Validierung können Sie Zertifikate entsprechend ihrer Validierungs-Klasse (Class 2) erstellen. Rufen Sie dafür den Zertifizierungs-Assistent auf und wählen Sie als Option (Drop-Down Liste): Object Code Signing Certificate:

StartSSL-CertificateWizard-CodeSignCertificate

 

Nach Klick auf "Continue" werden Sie aufgefordert ihren Zertifikat-Request per Copy+Paste einzufügen. Dazu öffnen Sie die in Schritt 1 bereits erzeugte Datei "codesign.csr" (z.B. in Notepad) und kopieren den kompletten Inhalt in die Zwischenablage. Achten Sie bitte darauf wirklich vollständig  zu kopieren inklusive Leerzeichen und Leerzeilen! Aus der Zwischenablage können Sie nun den Zertifikat-Request in die Textbox der Website kopieren.

Nach Bestätigung erhalten Sie von StartSSL das begehrte Zertifikat in einer neuen Textbox angezeigt. Kopieren Sie es sich bitte wieder genau so per Copy+Paste heraus, wie Sie bereits zuvor den Zertifikat-Request hineinkopiert hatten und speichern den kopierten Inhalt in eine Datei "codesign.crt".

Das Code Signing Zertifikat besteht nun aus dem privaten Schlüssel in "codesign.key" und dem Zertifikat "codesign.crt". Den Zertifikat-Request "codesign.csr" dagegen benötigen Sie nun nicht mehr.

Umwandeln in PFX-Format

Beide Dateien wurden in dem sogenannten PEM-Format abgespeichert, welches in Visual Studio nicht unterstützt wird. Deshalb muss es noch umgewandelt werden durch ein zweites Script via OpenSSL:

c:
cd /OpenSSL-Win32
set PATH=%PATH%;c:/OpenSSL-Win32/bin
set OPENSSL_CONF=c:/OpenSSL-Win32/bin/openssl.cfg
openssl pkcs12 -export -out codesign.pfx -keysig -inkey codesign.key -in codesign.crt

Im Ordner "c:\OpenSSL-Win32" entsteht nun eine weitere Datei "codesign.pfx", welche das begehrte Zertifikat inklusive des privaten Schlüssels in einer für das Visual Studio brauchbaren Form enthält.

Wenn Sie dieses Zertifikat ansehen wollen müssen Sie es zunächst in den Windows-eigenen Zertifikat-Store installieren indem Sie das Zertifikat mit einem Doppelklick z.B. im Windows Explorer starten und den Anweisungen des Installations-Assistenten folgen. Anschließend wird das Zertifikat-SnapIn "certmgr.msc" von Windows gestartet. Darin findet sich dann das installierte Zertifikat unter "Eigene Zertifikate":

CertificateManager
CertificateGeneral  CertificatePath 

Schritt 3. Integration des Zertifikats in Visual Studio

Um nun eine selbst erstellte Applikation mit dem neuen Zertifikat digital signieren zu können hat Microsoft in Windows-Betriebssystemen ein Verfahren mit dem Namen Authenticode entwickelt. Leider bietet das Visual Studio (in Version 2010) keinen integrierten Support dafür an. Es gibt zwar in den Projekt Properties beispielsweise eines C-Sharp-Projektes einen eigenen Reiter "Signing", der ist aber gedacht für die digitale Signierung von Code welcher in den Global Assembly Cache integriert werden soll und hat nichts mit Microsoft's Authenticode zur Hersteller-Verifikation zu tun.

Das Zertifikat "codesign.pfx" kann deshalb nur manuell durch das Microsoftsche Tool “signtool.exe” verwendet werden. Allerdings wird "signtool.exe" als Bestandteil des Windows SDK bereits seit Visual Studio 2003 mitinstalliert und sollte so auf einem Computer mit halbwegs aktuellem Visual Studio bereits unter C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\signtool.exe zu finden sein.

Für den eigentlichen Signaturvorgang (hier als Beispiel die Applikation "Hello World.exe") sieht dann der Aufruf wie folgt aus:

signtool.exe sign /f codesign.pfx /p PASSWORD -tr "http://www.startssl.com/timestamp" "Hello World.exe"

Sowohl für das Tool "signtool.exe", das Zertifikat "codesign.pfx" und auch die Applikationsdatei "Hello World.exe" sollten möglichst die voll qualifizierten Dateinamen verwendet werden. Ich habe diese in dem Beispiel oben nur der Übersichtlichkeit halber weggelassen.

Durch die Verwendung von /tr “http://www.startssl.com/timestamp als Parameter werden aktuelles Datum und Uhrzeit durch StartSSL signiert und in die ausführbare Datei geschrieben. Der Sinn liegt darin, dass eine Datei auch dann gültig signiert sein soll, wenn das verwendete Zertifikat selbst abgelaufen ist – solange nur der Signaturvorgang innerhalb des Gültigkeitszeitraums des Zertifikats durchgeführt wurde.

Außer in der Express Version von Visual Studio können Sie die Signierung ihres Programmes via Authenticode anschließend automatisieren, indem Sie das oben beschriebene Kommando in die Befehlszeile für das Postbuild-Ereignis der Projekt-Properties aufnehmen:

VS-PostbuildEvent

 

Damit wird "signtool.exe" jedes Mal nach einem erfolgreichen Compilerlauf ausgeführt und die eigene Applikation ist von nun an immer signiert.

Für das digitale Signieren wird immer ein Internet-Zugang benötigt um bei der Zertifizierungsstelle den korrekten Timestamp abzuholen. Wer einen Proxy betreibt sollte sicherstellen, dass die Timestamp-URL zur Zertifizierungsstelle (Im Beispiel oben http://www.startssl.com/timestamp) erreichbar ist.

4. Prüfen ob die selbst erstellte Applikation digital signiert ist

Ob die eigene Applikation nun korrekt digital signiert ist, lässt sich mit einen Blick in die Properties der signierten Datei prüfen. Dort findet sich jetzt ein neuer Reiter "Digitale Signaturen":

HelloWorld-Properties  HelloWorld-PropertiesDetails 

 

Wenn dem so ist funktioniert auch die Hersteller-Verifikation bei Programmstart unter Windows:

HelloWorld-ManufacturerVerified

5. Was gibt es noch Wissenswertes?

Microsoft's Authenticode erlaubt die Signierung von Code, weshalb alle Dateitypen die typischerweise Code enthalten via Authenticode digital signiert werden können. Also das wären z.B. Dateien mit der Endung .exe, .cab, .dll, .ocx, .msi, .xpi oder .xap und weitere. Möglich ist das digitale Signieren von Dateien im 32-Bit- und 64-Bit-Benutzermodus. Digital signiert werden können auch Powershell-Scripte. Nicht digital signiert werden können dagegen z.B. Dokumente mit der Endung .txt, .chm, alle Office-Formate und andere.

Die Dateien codesign.key, codekey.crt und codesign.pfx sollten Sie sich jetzt auf einem Backup-Medium (z.B. ein USB-Stick) speichern sowie vor unbefugten Zugriff sichern.

Ebenso sollten Sie auch das während ihrer Registrierung bei StartSSL in ihrem Web-Browser installierte Zertifikat sichern. Aufgrund dieses Zertifikats funktioniert die Anmeldung bei StartSSL sehr komfortabel ohne Benutzername und Passwort; allerdings können Sie sich ohne dieses Zertifikat dann auch nicht mehr bei StartSSL anmelden, sondern müssen eine neue (kostenlose) Registrierungsprozedur durchlaufen.

Code Signing Class 2 Zertifikate von StartSSL sind mit dem Attribut "Lifetime Signing" markiert. Damit verlieren diese Zertifikate am Ende ihrer Lebenszeit ihre Gültigkeit - und zwar auch in bereits signierten Dateien. Die Benutzung der Dateien wird dadurch nicht beeinträchtigt, allerdings zeigt die Hersteller-Verifikation von Windows nun wieder "Hersteller unbekannt" an. Wenn Sie sicherstellen wollen/müssen, dass ihre einmal signierten Dateien zeitlich unbegrenzt gültig sind, sollten Sie eher "Extended Validation"-Zertifikate verwenden. Diese sind allerdings erheblich teurer, die Identifikations-Prozedure ist aufwendiger und StartSSL ist hier auch nicht unbedingt der günstigste Anbieter. Ich persönlich neige zu Comodo - so wie der Besucher Mark, dem ich für diesen Hinweis danke.

 

Kommentare  

 
# Mark 2015-02-21 22:45
StartSSL Zertifikate haben die OID "Lifetime Signing". Das bedeutet, dass die Signatur ungültig wird, sobald die Lebensdauer des Zertifikats erreicht wird - trotz time-stamping. Stell mal die Uhr vor...

StartSSL sollte sich schämen, so einen Schwachsinn zu verkaufen!
Antworten | Antworten mit Zitat | Zitieren
 
 
# Matthias 2015-02-22 10:56
Soweit ich das Konzept verstanden habe ist das keine Besonderheit von StartSSL sondern des Code Signings an sich.

Eben weil Zertifikate systembedingt nun einmal ein definiertes Lebensende haben; Code jedoch zeitlich unbegrenzt funktionieren soll, sollte der zu signierende Code mit einem Timestamp signiert werden.
Microsoft's Authenticode prüft bei jedem Start nicht ob das Zertifikat gültig ist sondern ob der signierte Timestamp sich innerhalb des Gültigkeitsbere iches des Zertifikates befindet.

Als Entwickler kann ich das Zertifikat für das Signieren meines Codes nur innerhalb des Gültigkeitszeit raums verwenden
(und muss dann ein neues kaufen :-| ).
Der einmal erfolgreich signierte Code dagegen bleibt auch nach dem Lebensende des Zertifikats gültig.
Antworten | Antworten mit Zitat | Zitieren
 
 
# Mark 2015-02-22 14:09
Das Problem sind nicht die Zertifikate, die ungültig werden (das ist natürlich immer so), es sind die Signaturen, die ungültig werden. Das Time-Stamping kannst dir schenken, da Windows den Timestamp der Signatur gar nicht prüft - wegen besagter OID. Ich kenne keinen anderen Anbieter, der solche Zertifikate ausstellt.

Wie gesagt, stell die Uhr mal zwei Jahre vor, und prüfe dann die Signatur einer von dir signierten Datei. Sie wird ungültig sein - trotz Timestamp!
Antworten | Antworten mit Zitat | Zitieren
 
 
# Matthias 2015-02-22 14:55
Ja, du hast Recht! Für die Datei wird nach Ablauf des Zertifikats dann wieder ein unbekannter Hersteller angezeigt.

Kennst du einen anderen Anbieter der Code Signing mit Class 2 Level Zertifikate anbietet?
Die meisten Anbieter die ich so finde bieten für Code Signing nur Extended Level Zertifikate an, die dann gleich mal um den Faktor 10 teurer sind.
Antworten | Antworten mit Zitat | Zitieren
 
 
# Mark 2015-03-02 18:38
AFAIK, bleibt dir nur der Gang zu einem etabliertem Cert (bin selbst zu Comodo via ksoftware), und dann deutlich mehr Geld hinzulegen - plus den ganzen Ärger mit Notar, Rechnungen präsentieren, öffentlichem Telefonbucheint rag, etc.
Antworten | Antworten mit Zitat | Zitieren
 
 
# Jürgen 2015-04-02 18:21
Nur zur Info (fairerweise): Man bekommt die Extended Organization Validation auch bei StartSSL. Damit hast du das erreicht was du möchtest. Siehe https://www.startssl.com/?app=40
Antworten | Antworten mit Zitat | Zitieren
 
 
# Ulrich 2015-06-23 22:40
Ja das stimmt, allerdings ist die Extended Validation nicht für Personen verfügbar, sondern nur für firmen mit DUNS eintrag etc etc.
Schade eigentlich. Bis auf dieses kleines Mankoi kann ich startssl nur empfehlen.
Antworten | Antworten mit Zitat | Zitieren
 
 
# Martin Bernhardt 2016-06-21 12:52
Hallo!

vielen Dank für diese Beschreibung, sehr hilfreich! Wirklich traurig, dass das bei Microsoft nicht besser beschrieben, geschweige denn Plug&Play implementiert ist.

Eine ergänzende Bemerkung: wie im Beitrag zu sehen, wird das Class 2 Certificate auf die ausgestellt.

Ich hatte zwar die Firma bei Erstellung des Schlüssels Schritt 1 unter "Name der Organisation" angegeben, das wird aber anscheinend ignoriert.

Ich habe dann im certmgr.msc "Dynamic Applications" als Anzeigename eingetragen. Denke aber, das wird im Setup.exe nicht zu sehen sein.

Wie auch immer, dann stehe ich im Setup.exe halt persönlich als Herausgeber.

Ich gebe noch einen Screenshot bei und denke, die Leute werden es schon verstehen.

Viele Grüße,


Martin Bernhardt.
www.dynamic-applications.com
Antworten | Antworten mit Zitat | Zitieren