Code Signing

Vorteile von Code Signing

Da Software hauptsächlich über das Internet verteilt wird, steht der Verwender vor einem grundlegenden Problem: Wie kann er sicher sein, dass eine heruntergeladene Programmdatei tatsächlich vom angegebenen Hersteller stammt und auf dem Weg zu ihm nicht manipuliert wurde?

Genau hier setzt Code Signing an. Wenn ein Entwickler seine Software mit einem Code Signing Certificate signiert, erhält der Anwender beim Ausführen der Datei eine verlässliche Auskunft über zwei entscheidende Dinge: Erstens, wer die Software erstellt und veröffentlicht hat, und zweitens, dass die Datei seit ihrer Signierung unverändert geblieben ist.

Der praktische Nutzen ist erheblich. Ohne Signierung zeigt Windows beim ersten Ausführen einer aus dem Internet heruntergeladenen Datei einen deutlichen Warnhinweis: Der Herausgeber sei unbekannt, und die Software könnte den Computer gefährden. Für technisch weniger versierte Anwender ist das oft ein unüberwindbares Hindernis. Mit einer gültigen Signatur hingegen erscheint entweder gar keine Warnung oder lediglich ein dezenter Hinweis mit dem Namen des Herausgebers.

Besonders wichtig ist dabei der Schutz vor Manipulation auf dem Transportweg. Würde ein Angreifer eine Website hacken und die dort angebotene Programmdatei durch eine manipulierte Version ersetzen, würde die Signaturprüfung sofort fehlschlagen. Die ausgetauschte Datei hätte keine gültige Signatur des legitimen Entwicklers, da dafür der private Schlüssel des Entwicklers benötigt würde - den der Angreifer nicht besitzt. Windows würde die Datei als ungültig signiert erkennen und den Anwender warnen.

Man sollte jedoch verstehen, was Code Signing nicht leistet: Es garantiert nicht, dass eine Software frei von Schadsoftware ist. Auch ein Entwickler mit gültigem Zertifikat könnte theoretisch bösartige Software veröffentlichen. Code Signing beantwortet ausschließlich die Fragen nach Herkunft und Unversehrtheit - nicht nach der Vertrauenswürdigkeit des Inhalts. Es ist wie ein Einschreiben per Post: Man weiß, dass das Paket ungeöffnet und unverändert angekommen ist und wer es abgeschickt hat. Aber was sich darin befindet, sagt das Einschreiben nicht.

Dennoch ist dieser Schutz im Alltag äußerst wertvoll. In einer Zeit, in der Schadsoftware häufig durch manipulierte Downloads verbreitet wird, gibt die Kombination aus bekanntem Herausgeber und gültiger Signatur dem Anwender eine sinnvolle und verlässliche Orientierung.

Wie ein Entwickler ein Zertifikat erwirbt

Der Weg zu einem Code Signing Certificate führt über sogenannte Certificate Authorities, kurz CAs - also Zertifizierungsstellen, die von Microsoft und Apple offiziell anerkannt sind. Nur Zertifikate von diesen anerkannten Stellen werden von Windows und macOS als vertrauenswürdig akzeptiert.

Grundsätzlich gibt es zwei Arten von Code Signing Certificates: OV-Zertifikate (Organization Validation) und EV-Zertifikate (Extended Validation). Bei OV-Zertifikaten wird die Identität des Antragstellers geprüft, jedoch weniger streng. Sie bauen das sogenannte SmartScreen-Vertrauen bei Windows erst mit der Zeit auf - je öfter eine signierte Software heruntergeladen und ausgeführt wird, ohne dass Probleme gemeldet werden, desto mehr Vertrauen gewinnt sie im SmartScreen-System. EV-Zertifikate hingegen genießen sofortiges volles Vertrauen, da die Identitätsprüfung hier besonders gründlich ist.

Der Erwerbsprozess beginnt damit, dass der Entwickler einen Antrag bei einer CA stellt. Dabei muss er seine Identität nachweisen - bei Privatpersonen beispielsweise durch einen Personalausweis, bei Unternehmen durch Handelsregisterauszüge und weitere Dokumente. Die CA prüft diese Angaben, was bei EV-Zertifikaten mehrere Tage dauern kann.

Ein wichtiger Aspekt, der seit etwa 2023 zunehmend zur Pflicht wird: EV-Zertifikate dürfen nicht mehr als reine Datei ausgeliefert werden. Der private Schlüssel muss auf einem zertifizierten Hardware-Token gespeichert sein - einem speziellen USB-Stick, der als Hardware Security Module (HSM) fungiert. Die CA sendet diesen Token physisch per Post zu. Der Vorteil: Der private Schlüssel verlässt das Gerät technisch nie, was ihn vor Diebstahl schützt. Nachteilig ist, dass der Entwickler diesen Stick bei jedem Signiervorgang angeschlossen haben muss.

Als Alternative zu physischen Tokens haben sich Cloud-basierte Signing-Dienste etabliert. Anbieter wie DigiCert KeyLocker, SSL.com eSigner oder SignPath.io verwahren den privaten Schlüssel in einem gesicherten Cloud-HSM. Der Entwickler signiert seine Software über eine API oder ein Kommandozeilen-Tool, ohne einen physischen Stick zu benötigen. Gerade für automatisierte Build-Prozesse ist das deutlich praktischer.

Zu den bekanntesten CAs gehören DigiCert als Marktführer, Sectigo als günstigere Alternative, GlobalSign mit Fokus auf Unternehmenskunden sowie Certum aus Polen, das oft als günstigste Option für Einzelentwickler gilt. Die Preise liegen je nach Anbieter und Zertifikatstyp zwischen etwa 90 und über 600 Euro pro Jahr.

Die technischen Einzelheiten

Hinter Code Signing steckt ein elegantes kryptographisches Verfahren, das auf asymmetrischer Verschlüsselung basiert. Das Grundprinzip ist dabei dasselbe wie bei anderen Public-Key-Verfahren: Es gibt einen privaten Schlüssel, der geheim bleibt, und einen öffentlichen Schlüssel, den jeder kennen darf.

Beim Signieren einer ausführbaren Datei läuft der Prozess vereinfacht wie folgt ab: Zunächst wird ein kryptographischer Hash über den Inhalt der Datei berechnet. Ein Hash ist dabei eine Art digitale Quersumme - eine Zeichenkette fester Länge, die den gesamten Dateiinhalt repräsentiert. Ändert sich auch nur ein einziges Byte der Datei, ändert sich der Hash vollständig. Heutzutage wird dafür typischerweise SHA-256 verwendet.

Dieser Hash wird anschließend mit dem privaten Schlüssel des Entwicklers verschlüsselt. Das Ergebnis - der verschlüsselte Hash zusammen mit dem Zertifikat des Entwicklers - wird in einem speziellen Bereich der ausführbaren Datei eingebettet, dem sogenannten Authenticode Signature Block. Dabei wird der Signaturbereich selbst beim Berechnen des Hashes ausgespart, um das offensichtliche Henne-Ei-Problem zu vermeiden.

Wenn Windows die Datei prüft, kehrt es diesen Prozess um: Es liest die eingebettete Signatur, entnimmt das Zertifikat und entschlüsselt damit den gespeicherten Hash - denn der öffentliche Schlüssel aus dem Zertifikat kann entschlüsseln, was mit dem zugehörigen privaten Schlüssel verschlüsselt wurde. Gleichzeitig berechnet Windows selbst einen neuen Hash über den aktuellen Dateiinhalt. Stimmen beide Hashes überein, ist die Datei unverändert und die Signatur gültig. Stimmen sie nicht überein, wurde die Datei manipuliert.

Zusätzlich prüft Windows, ob das Zertifikat selbst vertrauenswürdig ist - also ob es von einer CA ausgestellt wurde, die im Windows Root Store eingetragen ist. Dieser Root Store ist eine Liste von CAs, der Microsoft grundsätzlich vertraut und die mit Windows vorinstalliert ist. Ist die Zertifikatskette nicht bis zu einer vertrauenswürdigen Root-CA nachvollziehbar, gilt das Zertifikat als ungültig.

Eine wichtige Rolle spielen auch die Zeitstempel. Zertifikate haben ein Ablaufdatum, typischerweise nach einem oder zwei Jahren. Beim Signieren wird üblicherweise auch ein kryptographischer Zeitstempel eines unabhängigen Zeitstempeldienstes eingebettet. Dieser belegt, dass die Signatur zu einem Zeitpunkt erstellt wurde, als das Zertifikat noch gültig war. Damit bleibt eine einmal erstellte Signatur auch nach Ablauf des Zertifikats gültig - eine praktisch wichtige Eigenschaft, denn Software wird oft noch Jahre nach ihrer Veröffentlichung verwendet.

Was die Prüfhäufigkeit angeht, unterscheidet Windows nach Art der Datei. Bei normalen Desktop-Anwendungen erfolgt die strenge Signaturprüfung hauptsächlich beim ersten Ausführen einer aus dem Internet heruntergeladenen Datei. Browser und der Windows-Explorer setzen dabei ein verstecktes NTFS-Dateiattribut, den sogenannten Mark of the Web, der Windows signalisiert, dass die Datei aus dem Internet stammt. SmartScreen wertet dieses Attribut aus. Bei Treibern hingegen prüft der Windows-Kernel die Signatur bei jedem Laden streng und wiederholt, da Treiber im privilegierten Kernelmodus laufen und ein besonders hohes Sicherheitsrisiko darstellen.

Vergleich zu Linux

Linux verfolgt beim Thema Vertrauen und Softwareintegrität einen grundlegend anderen Ansatz, der sich aus der Geschichte und Philosophie des Systems ergibt. Anstatt das Vertrauen beim einzelnen Entwickler zu verankern, liegt es beim Ökosystem als Ganzem.

Das klassische Linux-Modell basiert auf Paketverwaltungssystemen wie apt unter Debian und Ubuntu oder dnf unter Fedora. Dabei signiert nicht der Entwickler seine ausführbare Datei direkt, sondern die Distribution signiert ihr gesamtes Repository mit einem GPG-Schlüssel. Wenn ein Entwickler Software in eine Distribution einbringen möchte, durchläuft das Paket einen Prüfprozess der Distribution. Wird es akzeptiert, wird es von der Distribution selbst signiert und über deren offizielle Server verteilt. Der Anwender vertraut also nicht dem Entwickler direkt, sondern der Distribution als Mittelsmann und Prüfinstanz.

Neuere universelle Paketformate wie Flatpak und Snap gehen einen ähnlichen Weg. Flatpak signiert jedes Paket kryptographisch, und die zentrale Plattform Flathub übernimmt die Vertrauensrolle ähnlich wie ein App Store. Snap läuft komplett über die Infrastruktur von Canonical, dem Ubuntu-Hersteller, der als zentrale Kontrollinstanz fungiert.

Die Schwachstelle dieses Ansatzes zeigt sich beim direkten Download. Wer unter Linux eine Binärdatei, ein AppImage oder ein Skript direkt von einer Website herunterlädt, hat keine standardisierte Möglichkeit zu prüfen, ob die Datei authentisch und unverändert ist. Manche Entwickler veröffentlichen auf ihrer Website manuell einen SHA-256-Hash der Datei - doch das löst das Problem nur unvollständig. Wie bereits deutlich wurde: Wird die Website gehackt und die Datei ausgetauscht, kann der Angreifer ebenso einfach den veröffentlichten Hash ersetzen. Beide Angaben liegen auf demselben kompromittierten Server. Nur wenn der Hash über einen völlig unabhängigen Kanal - eine andere Domain, ein Social-Media-Profil, ein GitHub-Release - veröffentlicht wird, entsteht echte Sicherheit.

Ein weiterer Unterschied liegt im Verhalten des Systems. Windows und macOS reagieren auf unsignierte Software mit aktiven Warnhinweisen oder sogar Blockaden, die den Anwender direkt ansprechen. Linux hingegen vertraut dem Anwender grundsätzlich mehr Eigenverantwortung zu - es gibt keine systemweite Instanz, die beim Starten einer unsignierten Binärdatei warnt. Das passt zur Linux-Philosophie, ist aber für weniger technisch versierte Anwender potenziell riskanter.

Kritik an dem teuren System

Der offensichtlichste Kritikpunkt am Code-Signing-System sind die Kosten. Für einen großen Softwarekonzern sind einige hundert Euro pro Jahr für ein EV-Zertifikat eine vernachlässigbare Betriebsausgabe. Für einen Hobbyentwickler, einen Studenten oder ein kleines unabhängiges Studio kann es jedoch eine erhebliche finanzielle Hürde darstellen - insbesondere wenn die Software kostenlos oder als Open-Source-Projekt angeboten wird und keinerlei Einnahmen generiert. Das System benachteiligt strukturell genau jene Entwickler, die oft die innovativsten und am Gemeinwohl orientiertesten Beiträge leisten.

Noch grundlegender ist die Frage nach der Marktstruktur. Microsoft und Apple kontrollieren jeweils ihren eigenen Root Store - die Liste der CAs, deren Zertifikate als vertrauenswürdig gelten. Diese Kontrolle schafft eine künstliche Markteintrittsbarriere. Neue CAs, die günstigere oder gar kostenlose Zertifikate anbieten wollten, müssten erst die Aufnahme in den Root Store beantragen und genehmigt bekommen - ein Prozess, der von den Plattformbetreibern kontrolliert wird, die selbst kein Interesse an sinkenden Preisen haben. Das Ergebnis ist ein Oligopol mit wenigen etablierten Anbietern und kaum echtem Wettbewerbsdruck nach unten.

Die Frage, ob Microsoft oder Apple direkt an den Zertifikatsverkäufen verdienen, ist nicht eindeutig zu beantworten, da keine öffentlichen Zahlen vorliegen. Bekannt ist jedoch, dass CAs jährliche Gebühren für die Teilnahme am Root-Store-Programm und für die notwendigen Audits zahlen müssen. Diese Kosten geben die CAs selbstverständlich an ihre Kunden weiter. Ob man das als versteckte Provision bezeichnen will oder als legitime Verwaltungskosten, ist eine Frage der Perspektive - das Ergebnis für den Entwickler ist dasselbe.

Besonders augenfällig wird die Ungerechtigkeit des Systems, wenn man es mit dem Bereich der HTTPS-Zertifikate für Webseiten vergleicht. Dort hat die Non-Profit-Organisation Let's Encrypt bewiesen, dass vollständig kostenlose, automatisierte und dennoch verlässliche Zertifizierung möglich ist. Let's Encrypt wird von großen Organisationen wie Mozilla, Google, der Electronic Frontier Foundation und anderen finanziert und hat innerhalb weniger Jahre die Mehrheit aller aktiven Webseiten mit kostenlosen HTTPS-Zertifikaten versorgt. Ein analoges Projekt für Code Signing existiert bisher nicht - obwohl es technisch ohne weiteres machbar wäre. Es fehlt schlicht der politische und finanzielle Wille der großen Akteure, die vom bestehenden System profitieren oder zumindest kein Interesse an dessen Disruption haben.

Schließlich ist auch die Zwangslage zu kritisieren, in die Entwickler gedrängt werden. Da Windows durch seine Warnhinweise und SmartScreen-Mechanismen faktisch dafür sorgt, dass unsignierte Software vom durchschnittlichen Anwender gemieden wird, haben Entwickler keine echte Wahl. Wer seine Software über das Internet verteilen will, muss zahlen. Microsoft hat damit eine Position geschaffen, in der sie durch die Gestaltung ihrer eigenen Betriebssystem-Warnungen den Markt für Drittanbieter-Zertifikate am Leben erhalten - einen Markt, von dem sie zumindest indirekt profitieren. Für Einzelentwickler und kleine Teams ist das eine unbefriedigende und schwer zu rechtfertigende Situation, an der sich ohne externen Druck oder eine Initiative vergleichbar mit Let's Encrypt in absehbarer Zeit wenig ändern dürfte.