Seite 2: Verwaltung der Signaturschlüssel

Inhaltsverzeichnis

Beim Einsatz von Signaturschlüsseln und Zertifikaten fehlen oft die erforderlichen Überwachungsmöglichkeiten über ihre Verteilung und Verwaltung. Ohne eine umfassende Kontrolle können Signaturschlüssel in schlecht gesicherten IT-Umgebungen in die Hände von Angreifern gelangen. Das taiwanesische Computerunternehmen ASUS beispielsweise geriet 2018 in den Fokus von Hackern, die unterschiedliche Code-Signing-Schlüssel von einem ASUS-Webserver stahlen.

Mit den erbeuteten Schlüsseln schleusten die Angreifer Malware in echte ASUS-Update-Paket ein, die über einen Zeitraum von sechs Monaten mehr als eine Million ASUS-Computer in Mitleidenschaft zogen.

Wiederverwendung von Zertifikaten und Schlüsseln

In vielen Fällen verwenden Organisationen dieselben Zertifikate für unterschiedliche Dateien, Produktlinien und Geschäftsfelder. Das ist bequemer als separate Schlüssel und Zertifikate für unterschiedliche Code-Signing-Anwendungsfälle generieren, verteilen und verwenden zu müssen. Das Vorgehen erhöht allerdings das Risiko, dass ein Eindringling auf einen Schlüssel oder ein Zertifikat zugreifen kann, um mit dem vermeintlich vertrauenswürdigen Nachweis im nächsten Schritt essenzielle Komponenten der Softwareprozesskette zu kompromittieren. Folge: Das Vertrauen in signierte Software im produktiven Einsatz sinkt, wenn Zertifikate widerrufen oder Schlüsselpaare geändert werden müssen.

Viele Unternehmen überwachen den Einsatz von Signaturschlüsseln und Zertifikaten nicht. Solche Nachlässigkeiten haben zur Folge, dass sie nicht wissen, wer welchen Schlüssel oder welches Zertifikat einsetzt – geschweige denn, wie und wo das erfolgt. Angesichts blinder Flecken bei der Sicht auf die eigenen IT-Prozesse steigt die Gefahr für Unternehmen, dass Dritte ihre IT-Assets richtlinienwidrig oder sogar unbemerkt nutzen.

Sichere Verwahrung von Code-Signing-Tools

Die privaten Schlüssel der Code-Signing-Zertifikate steuern den Zugriff auf die eigene Software. Falls Angreifer nur einen der Schlüssel in die Hände bekommen, können sie Malware als legitime Software verschleiern. Die Privatschlüssel sind grundlegend zum Absichern des gesamten Prozesses. Unternehmen müssen sie daher äußerst sorgfältig speichern, verwalten und überwachen. Am besten speichert man sie in einem geschützten Hardware-Sicherheitsmodul (Hardware Security Module, HSM) mit Signaturdiensten oder FIPs-fähigen Schlüsselverwaltungsdiensten (Key Management Services, KMS).

Noch sind die Anforderungen für den Schutz von Code-Signing-Schlüsseln zur Organisationsvalidierung (Organizational Validation, OV) weniger strikt als bei Extended-Validation-Zertifikaten. Mit softwarebasierten Ansätzen lässt sich der Schutz von Schlüsseln erhöhen, aber der Einsatz eines Hardware-Sicherheitsmoduls ist stets die bessere Option, da Software sich leichter kompromittieren lässt. Das CA/Browser-Forum wird die Richtlinien für OV-Schlüssel zukünftig ändern und ab Juni 2023 an EV-Zertifikate anpassen. Die Zeit drängt, sich auf die Änderungen vorzubereiten und einen sicheren Schutz für alle privaten Schlüssel der Codesignatur zu implementieren.

Kontrollierter Zugriff

Unternehmen müssen Kontrollrichtlinien für den Zugriff auf private Schlüssel erstellen, die sicherstellen, dass im Bedarfsfall nur autorisierte Parteien die jeweiligen Keys verwenden können. Die Schlüssel lassen sich mit kompatiblen SaaS-Codesignaturanwendungen oder Key-Management-Services (KMS) generieren, um zu verhindern, dass sie geteilt, verloren oder gestohlen werden.

Als Sicherheitsmaßnahme sollte der für die Generierung der Schlüssel verantwortliche Personenkreis von denjenigen Personen getrennt sein, die die Keys verwendet. Multi-Faktor-Authentifizierung (MFA) für die IT-Verantwortlichen, die Schlüssel signieren oder erstellen dürfen, verbessert die Sicherheit zusätzlich. Solche Zugriffsrechte sollten schnell widerrufbar sein, falls die mit dem Unterzeichnen oder dem Generieren von Schlüsseln betrauten Personen das Unternehmen verlassen oder aus anderen Gründen keinen Zugriff mehr benötigen.

Kontinuierlich zu überwachen, wie die Schlüssel verwendet werden, ist eine weitere wichtige Kontrollmaßnahme. Unternehmen sollten vollständig protokollieren, wer wann was unterschreibt, um Sicherheitsverletzungen untersuchen und beheben zu können. Das betrifft gleichermaßen den Einsatz von Schlüsselpaaren: das Generieren, die Zertifikatsoperationen sowie das Zuweisen von Schlüssel- und Signaturzugriff.

Durchsetzen kryptografischer Standards

Kryptografischen Standardverfahren müssen unternehmensweit durchgesetzt werden. Das schreiben die meisten Branchenstandards ohnehin vor. Das CA/Browser-Forum fordert für das RSA-Verfahren eine Schlüssellänge von mindestens 3072 Bit bei öffentlichen Code-Signing- und Zeitstempel-Zertifikaten. Entwicklerinnen und Entwickler mögen diese Anforderungen nicht immer kennen, aber Unternehmen müssen die Branchenstandards und die damit verbundenen kryptografischen Mindestanforderungen für das Erstellen von Schlüsseln und Zertifikaten einhalten.

Wichtig ist, nicht nur die Einzelkomponenten beim Code Signing zu schützen und überwachen, sondern den gesamten Prozess sorgfältig zu verwalten. Das kann die Freigabe der einzelnen Schritte ebenso betreffen wie die Genehmigung signierter und vorausgeplanter Releases. Für Code-Commits oder CI/CD-Pipeline-Kick-offs empfiehlt sich ebenfalls die Einführung eines Genehmigungsprozesses.

Automatisiertes Code Signing in SDLC

Das Code Signing sollte ein automatisierter Bestandteil des Software Development Lifecycle (SDLC) sein. Dadurch lassen sich menschliche Fehler während des Code-Signing-Prozesses vermeiden und es lässt sich sicherstellen, dass der Programmcode immer signiert wird.

Organisationen können die eingesetzten Build-Server daraufhin überprüfen, ob es auffällige Diskrepanzen oder potenzielle Anzeichen eines Angriffs gibt. Durch das Signieren der Software und den Vergleich unterschiedlicher Build-Server anhand der erzeugten Hashwerte lassen sich Abweichungen und mögliche Gefahren vor dem Release erkennen. Identische Builds können sicherstellen, dass kein bösartiger Code in die Software gelangt.

Widerruf kompromittierter Zertifikate

Stellt ein Unternehmen fest, dass ein Schlüssel kompromittiert wurde oder signierte Malware vorhanden ist, muss es umgehend die Zertifikate widerrufen und die Zertifizierungsstellen benachrichtigen. Damit verliert die Software ihre Gültigkeit und die Verbreitung von Malware wird unterbunden.

Im Regelfall sind öffentliche Code-Signing-Zertifikate ein bis drei Jahre gültig. Laufen sie ab, verfällt die Gültigkeit der von ihnen signierten Software. Eine Zeitstempelsignatur stellt sicher, dass die Gültigkeitsdauer für einen längeren Zeitraum erhalten bleibt. Im Durchschnitt beträgt sie damit elf Jahre, um Risiken beim Zertifikatswiderruf zu mindern. Müssen Zertifikate widerrufen werden, stellt der Zeitstempel sicher, dass der Widerruf nur die Softwarebestandteile betrifft, die nach dem Datum des Widerrufs veröffentlicht wurden.