Was ist Code Signing?
Code Signing ist das digitale Signieren eines Softwareartefakts mit einem privaten Schlüssel; der zugehörige öffentliche Schlüssel ermöglicht die Prüfung auf Änderungen seit dem Signieren, eine akzeptierte Vertrauensbindung die Zuordnung zum Signierenden.
Technische Einordnung: Ausgewiesen wird der Signierende beziehungsweise die Identität, an die der Schlüssel innerhalb der akzeptierten Vertrauenskette gebunden ist. Das ist nicht automatisch der tatsächliche Entwickler des Codes.
Wie funktioniert Code Signing?
Der Signierprozess bindet kryptografische Prüfdaten des Artefakts an eine mit dem privaten Schlüssel erzeugte Signatur. Bei der Verifikation werden der korrespondierende öffentliche Schlüssel und, je nach Verfahren, Zertifikat, Zertifikatskette und Zeitstempel einbezogen. Wird der signierte Inhalt nachträglich verändert, scheitert seine Integritätsprüfung.
Signaturen können abhängig vom Format eingebettet oder getrennt vorliegen. Code Signing verschlüsselt den Code nicht und schafft keine Vertraulichkeit. Ein Zertifikat allein ist ebenfalls keine Artefaktsignatur: Es bindet einen öffentlichen Schlüssel an eine behauptete Identität.
Für wen und welche Artefakte ist Code Signing relevant?
Der Mechanismus ist insbesondere für Hersteller beziehungsweise Entwickler, Signierende, Verteiler und prüfende Empfänger verteilter Software relevant. Beispiele sind Firmware, Betriebssystemkomponenten, mobile Anwendungen, Container-Images und Updates.
Plattformpraxis: Plattform, Verteilweg und Vertrauensrichtlinie bestimmen, ob ein Format unterstützt, eine Signatur verlangt und ihr vertraut wird. Eine technisch gültige Signatur garantiert deshalb weder die Annahme noch die Ausführung eines Artefakts.
Welche Voraussetzungen müssen für eine belastbare Prüfung erfüllt sein?
Der Signierende benötigt den privaten Schlüssel; der Prüfende benötigt den korrespondierenden öffentlichen Schlüssel. Der private Schlüssel muss geheim bleiben. Soll zusätzlich die behauptete Identität bewertet werden, ist eine akzeptierte Bindung des Schlüssels an diese Identität erforderlich, typischerweise über ein Zertifikat und eine Vertrauenskette. Die kryptografische Prüfung allein belegt nicht, wem ein öffentlicher Schlüssel in der realen Welt gehört.
Was beweist eine gültige Codesignatur nicht?
Sie beweist weder Fehlerfreiheit noch Schadlosigkeit oder fachliche Vertrauenswürdigkeit. Schwachstellen und schädliche Funktionen, die bereits vor dem Signieren vorhanden waren, bleiben möglich. Wird ein privater Signierschlüssel kompromittiert, kann damit formal gültig signierte Schadsoftware entstehen. Zertifikatsstatus, Widerruf und Vertrauenskette sind daher gesondert zu bewerten.
Welche Fristen oder Schwellenwerte gelten?
Für Code Signing als allgemeinen technischen Mechanismus bestehen keine einheitliche Frist und kein universeller Schwellenwert. Zertifikatslaufzeiten, Widerrufsregeln und Zeitstempelwirkungen hängen vom Format und von der Prüfplattform ab.
Welche Wirkung hat ein Zeitstempel?
Ein von der jeweiligen Technik akzeptierter Zeitstempel kann plattformspezifisch die Prüfung unterstützen, dass die Signatur während der Gültigkeit des Signaturzertifikats bestand. Seine genaue Wirkung ist keine allgemeine Regel; sie hängt vom Signaturformat, dem Zertifikat und der Prüfplattform ab.
Häufige Fehlannahmen
- „Signiert bedeutet sicher.“ Nein. Die Signatur ersetzt weder Codeprüfung noch Schwachstellenmanagement.
- „Eine gültige Signatur nennt zwingend den Entwickler.“ Nein. Sie weist den Signierenden beziehungsweise die über die Vertrauensbindung zugeordnete Identität aus.
- „Ein Zertifikat signiert die Software bereits.“ Nein. Das Zertifikat bindet einen öffentlichen Schlüssel an eine Identität; die Artefaktsignatur muss gesondert erzeugt werden.
- „Eine technisch gültige Signatur wird überall akzeptiert.“ Nein. Formatunterstützung, Vertrauensanker und Annahmeregeln sind plattformabhängig.
- „Code Signing hält den Code geheim.“ Nein. Es unterstützt Integritäts- und Herkunftsprüfungen, bietet aber keine Vertraulichkeit.
Was die Geschäftsleitung tun sollte
Praxisempfehlung: Die folgenden Schritte sind risikobasierte technische Empfehlungen und keine allein aus dem Begriff Code Signing folgende allgemeine Pflicht.
- Rollen für Entwicklung, Prüfung, Signaturfreigabe und Signieren festlegen und angemessen trennen.
- Nur geprüfte und eindeutig zugeordnete Artefakte zur Signatur zulassen sowie private Schlüssel besonders schützen.
- Signaturprüfung, unterstützte Formate und Vertrauensanker in den tatsächlichen Zielplattformen und Verteilwegen testen.
- Verfahren für Schlüsselkompromisse, Zertifikatswiderruf, Schlüsselwechsel und Wiederherstellung vorbereiten.
- Mehrschlüssel- oder Quorum-Mechanismen und vertrauenswürdige Zeitstempel passend zu Bedrohungsmodell und Nutzungsdauer prüfen.
Für die Geschäftsleitung
Code Signing ist für veröffentlichte Software ein kontrollierbarer Integritäts- und Herkunftsmechanismus, aber kein Sicherheitsurteil über den Code. Zu entscheiden sind Verfahren, Rollen, Schlüssel- und Vertrauensmodell passend zu Plattform, Format, Verteilweg und Bedrohungsmodell. Als Nachweis sollten Freigaben, signierte Artefakte, Prüfergebnisse, verwaltete Vertrauensanker sowie Abläufe für Widerruf und Wiederherstellung nachvollziehbar dokumentiert werden.
Quellen
- NIST: Security Considerations for Code Signing, Abstract und Abschnitte 1–5.
- Oracle JDK 25: jarsigner, Description, JAR File Verification und Signature Time Stamp.
- Oracle: Understanding Signing and Verification.
- Microsoft: Authenticode.
- Microsoft: Time Stamping Authenticode Signatures, About Cryptographic Time Stamping.
- NIST SP 800-204D, Abschnitt 5.1.3.
