Zum Inhalt

47-Tage-Zertifikate sind im Anmarsch. Sind Sie bereit?

Jetzt handeln →

Grundlegendes zu den Code-Signierungsanforderungen des CA/Browser-Forums  

Codesignatur

Im Juni 2023 veröffentlichte das CA/Browser Forum eine wichtige Aktualisierung seiner Anforderungen an die Codesignatur. Diese betrifft Entwickler, DevOps-Teams und Unternehmen, die auf öffentlich vertrauenswürdige Zertifizierungsstellen (CAs ) angewiesen sind, um ihre Software zu signieren und zu sichern. Die Aktualisierungen, die am 1. Juni 2023 in Kraft traten, schreiben vor, dass private Schlüssel für die Codesignatur sicher in einem zertifizierten Hardware-Sicherheitsmodul (HSM) gespeichert und geschützt werden müssen. Diese Änderung betrifft sowohl Zertifikate mit erweiterter Validierung (EV) als auch Nicht-EV-Zertifikate.

Eine zweite verbindliche Anforderung folgte: Mit der Abstimmung CSC-31 wird die Gültigkeitsdauer von Code-Signatur-Zertifikaten ab dem 1. März 2026 auf 460 Tage begrenzt. Damit werden die zuvor von einigen Zertifizierungsstellen angebotenen mehrjährigen Ausstellungszeiträume ersetzt. Zusammen bilden diese beiden Vorgaben – die HSM-Anforderung und die Gültigkeitsbegrenzung – die derzeit verbindliche Grundlage des CA/B-Forums für öffentlich vertrauenswürdige Code-Signatur-Zertifikate.

Kurz gesagt: Ab dem 1. Juni 2023 müssen private Schlüssel für die Codesignierung in einem FIPS 140-2 Level 2 (oder Common Criteria EAL 4+) HSM generiert und gespeichert werden; ab dem 1. März 2026 ist die Gültigkeitsdauer von Zertifikaten auf 460 Tage begrenzt. Beides sind zwingende Vorgaben, keine Empfehlungen, und nicht konforme Ausstellungsanträge werden von den Zertifizierungsstellen, die die Mindestanforderungen durchsetzen, abgelehnt.

Wichtige Erkenntnisse

  • Die HSM-Vorgabe (1. Juni 2023) und die Gültigkeitsdauerbegrenzung von 460 Tagen (1. März 2026) sind beides zwingende Anforderungen, die von den Zertifizierungsstellen bei der Ausstellung durchgesetzt werden, und keine internen Best-Practice-Empfehlungen, die eine Organisation ignorieren kann.
  • Die Begrenzung auf 460 Tage bedeutet, dass die Erneuerung nun etwa jährlich und nicht mehr alle 1-3 Jahre erfolgt, was die operative Bedeutung der HSM-Integration und der CI/CD-Automatisierungsherausforderungen, die weiter unten behandelt werden, erhöht, da Reibungsverluste bei der Erneuerung nun viel häufiger auftreten.

Checkliste für Compliance-Audits

  1. Stellen Sie sicher, dass der Signaturschlüssel innerhalb eines HSM generiert und niemals von einem solchen exportiert wurde, das nach FIPS 140-2 Level 2 oder Common Criteria EAL 4+ zertifiziert ist.
  2. Bitte bestätigen Sie, dass die Gültigkeit des Zertifikats bei Ausstellung oder Verlängerung 460 Tage nicht überschreitet.
  3. Stellen Sie sicher, dass jede Signatur einen vertrauenswürdigen Zeitstempel enthält, damit die Signatur auch nach Ablauf des Zertifikats selbst gültig bleibt.
  4. Es muss sichergestellt werden, dass ein dokumentiertes Widerrufsverfahren existiert und getestet wurde, nicht nur schriftlich festgehalten.
  5. Die Bestätigung der Verlängerung erfolgt spezifisch anhand des 460-Tage-Zeitraums und nicht anhand einer veralteten, mehrjährigen Annahme, die aus der Zeit vor der Abstimmung CSC-31 stammt.

Warum die HSM-Anforderung?

Die neuen Anforderungen ergeben sich aus dem Bedarf an strengeren Sicherheitsmaßnahmen in der Softwareentwicklung. Angesichts immer ausgefeilterer Cyberangriffe ist es entscheidend, die Integrität der Software ab dem Zeitpunkt ihrer Signierung zu gewährleisten. Der Schutz der privaten Schlüssel für die Codesignierung in einem HSM reduziert das Risiko einer Schlüsselkompromittierung drastisch , da HSMs manipulationssicher konzipiert sind und eine sichere Umgebung für kryptografische Operationen bieten.

Ab dem 1. Juni 2023 müssen alle Zertifikatsanforderer ein HSM verwenden, das die folgenden Standards erfüllt:

Diese Zertifizierungen gelten allgemein als Industriestandards für sichere kryptografische Module und stellen sicher, dass private Schlüssel in einer Hardwareumgebung geschützt sind, die nicht umgangen oder manipuliert werden kann.

Wichtige Herausforderungen im Rahmen der neuen Code Signing-Anforderungen

Die Umstellung auf HSMs für die Codesignierung ist zwar ein positiver Schritt für die Sicherheit, bringt aber auch einige technische Herausforderungen mit sich, die bewältigt werden müssen:

  1. Nachweis der Einhaltung der HSM-Anforderung

    Die erste Hürde für Unternehmen besteht darin, nachzuweisen, dass ihre privaten Schlüssel sicher in einem HSM gespeichert sind. Dieser Nachweis ist notwendig, um Codesignaturzertifikate von Zertifizierungsstellen ( CAs) zu erhalten . Viele CAs bieten zwar USB-basierte HSMs als Lösung an, dies kann jedoch für Unternehmen, die in der Cloud arbeiten oder umfangreiche Codesignatur-Anforderungen haben, umständlich sein. USB-HSMs sind nicht optimal für Teams, die über verschiedene Regionen verteilt sind, oder für solche, die schnelle und umfangreiche Signaturvorgänge benötigen.

    Eine skalierbarere Option ist die Verwendung netzwerkbasierter HSMs, die entweder vor Ort installiert oder von Cloud-Anbietern gemietet werden können. Lösungen wie AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM und nShield as a Service sind allesamt praktikable Optionen. Es ist jedoch wichtig sicherzustellen, dass das von Ihnen gewählte HSM die von Ihrer Zertifizierungsstelle geforderten Verifizierungsmethoden unterstützt, wie z. B. die Schlüsselbeglaubigung (d. h. die Bestätigung, dass sich der private Schlüssel im HSM befindet).

  2. Verwalten von Schlüssel- und Zertifikatsvorgängen

    Sobald Ihre privaten Schlüssel in einem HSM gesichert sind, wird deren Verwaltung komplexer. HSMs sind so konzipiert, dass sie private Schlüssel in ihrer sicheren Umgebung aufbewahren. Das bedeutet, dass Sie Schlüssel nicht direkt für die Verwendung in Software exportieren können. Stattdessen müssen Sie über eine Zwischenschicht mit dem HSM interagieren, beispielsweise:

    Diese Vorgänge erfordern spezielle Software und kryptografische Tools. Darüber hinaus müssen Sie sicherstellen, dass die Zugriffsberechtigungen für die Schlüssel streng kontrolliert werden. Jede am HSM ausgeführte Aktion (z. B. Schlüsselverwendung, Zertifikatsausstellung) muss protokolliert und geprüft werden, um den Best Practices für Sicherheit zu entsprechen.

  3. Integration der Code-Signierung mit HSMs

    Eine der größten technischen Herausforderungen besteht darin, HSMs in die verschiedenen plattformübergreifenden Code-Signatur-Tools zu integrieren. Die meisten Unternehmen nutzen Tools von Drittanbietern für die Code-Signatur, beispielsweise:

    • Signtool (Windows)
    • Jarsigner (Java)
    • Codesign und Produktentwicklung (macOS)
    • rpmsign und debsign (Linux)
    • Mitunterzeichnen (Container)

    Bei Verwendung eines HSM erfordert die Integration dieser Tools den Einsatz plattformspezifischer Kryptografiedienstanbieter (CSPs). Beispiel:

    • Windows: Verwendet KSP (Key Storage Providers) oder CSP (Cryptographic Service Providers).
    • Java: Verwendet JCE (Java Cryptography Extension)-Anbieter.
    • Linux: Basiert auf PKCS#11-Bibliotheken für hardwarebasierte Kryptografie.
    • macOS: Verwendet CTK (Cryptographic Toolkit).

    Diese Integrationen können knifflig sein, da die Signaturtools für die Interaktion mit dem HSM über den entsprechenden Dienstanbieter konfiguriert werden müssen. Dies erfordert oft eine individuelle Konfiguration und Tests, um einen reibungslosen Betrieb zu gewährleisten.

  4. Leistungsoptimierung in CI/CD-Pipelines

    In modernen DevOps-Umgebungen stehen Geschwindigkeit und Effizienz an erster Stelle. Die Einführung eines HSM in Ihren Code-Signaturprozess kann die Pipeline verlangsamen, wenn es nicht richtig konfiguriert ist. Viele Teams verfolgen zunächst einen gängigen Ansatz: Sie laden die zu signierenden Daten hoch, führen den Signiervorgang durch und laden anschließend das signierte Ergebnis herunter. Diese Methode kann jedoch ineffizient sein, erhebliche Bandbreite verbrauchen und Verzögerungen verursachen.

    Um diesen Prozess zu optimieren, wechseln viele Organisationen zum clientseitigen Hashing. Dabei wird der Code clientseitig gehasht, bevor er zur Signierung an das HSM gesendet wird. Dies reduziert die übertragene Datenmenge und beschleunigt den Signierungsprozess. Diese Methode erfordert jedoch, dass sowohl Ihr Kryptografiedienstanbieter als auch Ihre Signaturinfrastruktur diese Funktion unterstützen.

Enterprise Code-Signing-Lösung

Holen Sie sich mit unserer Code-Signing-Lösung eine Lösung für alle Ihre kryptografischen Software-Code-Signing-Anforderungen.

Wie kann Verschlüsselungsberatung Sie auf Ihrem Weg zur Compliance unterstützen?

Wir von Encryption Consulting sind darauf spezialisiert, Unternehmen bei der Erfüllung der Anforderungen des CA/Browser Forums für die Codesignierung zu unterstützen. So können wir Sie bei diesem Übergang begleiten:

  • HSM-Integration: Unabhängig davon, ob Sie sich für USB-basierte oder netzwerkbasierte HSMs entscheiden, können wir Sie bei der Auswahl der besten Lösung für Ihre Anforderungen unterstützen und Sie durch den Integrationsprozess führen.
  • Schlüsselverwaltungslösungen: Wir bieten Fachwissen zur sicheren Verwaltung Ihrer privaten Schlüssel innerhalb von HSMs und stellen sicher, dass alle Schlüssel- und Zertifikatsvorgänge sicher und in Übereinstimmung mit Industriestandards ausgeführt werden.
  • Code Signing-Optimierung: Unser Team kann Ihnen dabei helfen, Ihren Code-Signaturprozess mit den erforderlichen kryptografischen Dienstanbietern zu integrieren und so sicherzustellen, dass der Prozess auf allen Plattformen reibungslos und sicher abläuft.
  • CI/CD-Pipeline-Optimierung: Wir können Sie bei der Implementierung effizienter Code-Signaturstrategien in Ihrer CI/CD-Pipeline unterstützen, um Leistungseinbußen zu minimieren.

Wir stellen CodeSign Secure vor: Die Lösung, die Sie brauchen

Um Ihren Codesignierungsprozess noch sicherer und effizienter zu gestalten, empfehlen wir CodeSign Secure . Unsere Lösung bietet einen nahtlosen und automatisierten Ansatz für die Codesignierung, der sich vollständig in HSMs integriert und Ihnen hilft, die neuesten Anforderungen von Zertifizierungsstellen und Browserforen ohne unnötige Komplexität zu erfüllen. CodeSign Secure vereinfacht die Schlüsselverwaltung, verbessert die Compliance und gewährleistet, dass Ihre Signaturvorgänge auch in großen DevOps-Umgebungen schnell und effizient bleiben.

Mit CodeSign Secure erhalten Sie:

  • Sichere Integration mit Hardware-Sicherheitsmodulen
  • Optimierte Verwaltung von Code Signing-Zertifikaten
  • Verbesserte Leistung für CI/CD-Pipelines
  • Vollständige Einhaltung der Code-Signaturanforderungen des CA/Browser-Forums

Mit CodeSign Secure sorgen wir für sichere, konforme und schnelle Software . Kontaktieren Sie Encryption Consulting noch heute, um zu erfahren, wie wir Ihren Codesignierungsprozess optimieren können.

Verlängerung, Zeitstempelung und Widerruf gemäß der neuen Basislinie

Die 460-Tage-Grenze verändert den operativen Ablauf der Codesignierung stärker als einzelne technische Schritte. Daraus ergeben sich drei direkte Konsequenzen:

  • Erneuerung: Ein Zertifikat, das im Rahmen eines älteren mehrjährigen Gültigkeitszeitraums ausgestellt wurde, läuft weiterhin planmäßig ab. Jede Verlängerung oder Neuausstellung nach dem 1. März 2026 ist jedoch auf 460 Tage begrenzt, unabhängig von den vorherigen Angeboten der Zertifizierungsstelle. Die Verlängerungsintervalle sollten anhand dieser Begrenzung genau überwacht und nicht anhand historischer Zertifikatslaufzeiten abgeleitet werden.
  • Zeitstempel: Ein vertrauenswürdiger Zeitstempel auf einer Signatur belegt, dass das Zertifikat zum Zeitpunkt der Unterzeichnung gültig war. Da Zertifikate heutzutage etwa jährlich ablaufen, ist die Zeitstempelung jeder Signatur wichtiger denn je: Ohne sie ist die Vertrauenswürdigkeit eines signierten Dokuments an die nun kürzere Gültigkeitsdauer des Zertifikats gebunden, und die Signatur verliert mit dem Zertifikat ihre Gültigkeit, selbst wenn sich sonst nichts daran geändert hat.
  • Widerruf: Die HSM-Anforderung schränkt zwar die Möglichkeiten zur Kompromittierung eines Schlüssels ein, ersetzt aber nicht die Notwendigkeit eines getesteten Widerrufsverfahrens. Ein dokumentierter, aber nie geübter Plan stellt eine Lücke dar, die bei einem Audit aufgedeckt werden sollte; häufigere Erneuerungszyklen bieten zudem mehr Gelegenheiten, die vollständige Funktionsfähigkeit des Widerrufsprozesses zu überprüfen.

Fazit

Die aktualisierten Anforderungen des CA/Browser Forums zur Codesignierung markieren einen entscheidenden Wandel hin zu stärkeren Sicherheitspraktiken im Softwareentwicklungszyklus. Die Umstellung auf HSM-basierte Codesignierung bringt zwar technische Herausforderungen mit sich, die Vorteile hinsichtlich verbesserter Sicherheit und Integrität sind jedoch unbestreitbar. Durch effektives Management der HSM- Integration, optimierte Schlüsselverwaltungs-Workflows und eine reibungslose Performance Ihrer CI/CD-Pipeline können Sie die neuen Standards erfüllen und gleichzeitig die Entwicklungseffizienz beibehalten.

Encryption Consulting begleitet Sie durch jeden Schritt des Prozesses und stellt sicher, dass Ihre Code-Signatur-Praktiken sicher sind und den neuesten Industriestandards vollständig entsprechen.

Häufig gestellte Fragen

Handelt es sich bei der Gültigkeitsdauerbegrenzung von 460 Tagen um eine Empfehlung oder eine zwingende Vorgabe?

Eine zwingende Vorgabe. Gemäß Wahlvorschlag CSC-31 beträgt die maximale Gültigkeitsdauer für öffentlich vertrauenswürdige Code-Signaturzertifikate, die am oder nach dem 1. März 2026 ausgestellt oder verlängert werden, 460 Tage. Zertifizierungsstellen, die die CA/B-Forum-Grundlage anwenden, stellen keine Zertifikate mit längerer Gültigkeitsdauer aus.

Gilt die HSM-Anforderung auch für interne, nicht öffentlich vertrauenswürdige Zertifikate?

Die Richtlinien des CA/B-Forums regeln öffentlich vertrauenswürdige Zertifizierungsstellen und die von ihnen ausgestellten Zertifikate. Intern ausgestellte Zertifikate sind nicht direkt an die Vorgaben des CA/B-Forums gebunden, dennoch wenden viele Organisationen intern denselben HSM-gestützten Schlüsselschutz an, da sich die zugrunde liegende Sicherheitsstrategie nicht ändert, unabhängig davon, wer das Zertifikat ausgestellt hat.