Bewertung: 
/ 20
- Details
-
Veröffentlicht am Sonntag, 28. Juli 2013 15:03
-
Zugriffe: 60102
|
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.
|
|
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:
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:
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":
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:
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:
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":
Wenn dem so ist funktioniert auch die Hersteller-Verifikation bei Programmstart unter Windows:
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
StartSSL sollte sich schämen, so einen Schwachsinn zu verkaufen!
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.
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!
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.
Schade eigentlich. Bis auf dieses kleines Mankoi kann ich startssl nur empfehlen.
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