PostQuantumGefahr
DER STILLE STURM: WIE SIE DIE POST-QUANTUM-KRYPTOGRAPHIE-GEFAHR MEISTERN
In der digitalen Welt halten wir unsere „Verschlüsselung“ – die Algorithmen, die unsere Banküberweisungen, Staatsgeheimnisse und privaten Nachrichten sichern – oft für unüberwindbar. Jahrzehntelang war dies auch der Fall. Doch am Informatik-Horizont braut sich ein stiller Sturm zusammen: das Aufkommen von kryptoanalytisch relevanten Quantencomputern.
Die Quantenbedrohung: Das Unknackbare knacken
Aktuelle kryptografische Standards wie RSA und Elliptic Curve Cryptography (ECC) basieren auf mathematischen Problemen, deren Lösung für klassische Computer unmöglich ist (z. B. die Faktorisierung großer Primzahlen). Ein Quantencomputer, der die Prinzipien der Superposition und Verschränkung nutzt, kann Informationen auf eine Weise verarbeiten, die für klassische Maschinen unmöglich ist.
Insbesondere ermöglicht der Shor-Algorithmus einem ausreichend leistungsfähigen Quantencomputer, diese asymmetrischen „Schlösser” innerhalb von Minuten zu knacken. Daraus entsteht ein Risiko, das man mit der Bezeichnung „jetzt ernten, später entschlüsseln” beschreibt: Angreifer könnten heute verschlüsselte Daten erfassen, bzw. einsammeln und darauf warten, dass die Technologie ausgereift ist, um sie in Zukunft zu entschlüsseln.
Lehren aus der Geschichte: Die Qualen des Übergangs
Wir haben das schon einmal erlebt, allerdings noch nie mit so hohen Einsätzen. Historische Übergänge bieten jedoch eine warnende Lehre:
- DES zu AES: Als der Data Encryption Standard (DES) Ende der 90er Jahre geknackt wurde, dauerte die Umstellung auf den Advanced Encryption Standard (AES) fast ein Jahrzehnt.
- SHA-1-Abkündigung: Die Abkehr vom SHA-1-Hashing-Algorithmus (nachdem er als anfällig erkannt wurde) wurde durch „Zombie“-Systeme erschwert, die den unsicheren Standard noch jahrelang weiterverwendeten, was zu weit verbreiteten Schwachstellen führte.
- Der Y2K-Vergleich: Wie bei Y2K gibt es auch bei der PQC-Migration eine „Frist“, die durch den Fortschritt der Hardware vorgegeben ist. Im Gegensatz zu Y2K kennen wir jedoch nicht das genaue Datum, an dem die Uhr „12“ schlägt. Eine Näherung s.bspw. Quantum doom clock.
Die größte Herausforderung bei diesen historischen Veränderungen war nicht die neue Mathematik, sondern die Sichtbarkeit. Unternehmen wussten oft nicht, wo ihre Kryptografie „fest codiert” war, was Updates zu einem manuellen, fehleranfälligen Albtraum machte, bei dem man sich durch Legacy-Code und Hardware kämpfen musste.
Die Lösung: Kryptografische Agilität
Globale Sicherheitsexperten, Kryptografie-Wissenschaftler und inzwischen auch das US-Kriegsministerium in einem Memo an seine Führung im vergangenen November fordern einen pro-aktiven Ansatz: Kryptografische Agilität.
Krypto-Agilität ist die Fähigkeit eines Informationssystems, zwischen kryptografischen Algorithmen zu wechseln, ohne dass dafür erhebliche Änderungen an der Infrastruktur oder umfangreiche Code-Neuprogrammierungen erforderlich sind. Anstatt „angeschraubt“ zu sein, wird Sicherheit modular. Dieser Ansatz ist aus folgenden Gründen unerlässlich:
- Algorithmen entwickeln sich weiter: Da das NIST PQC standardisiert, müssen die ersten Versionen möglicherweise aktualisiert werden, wenn neue Schwachstellen entdeckt werden.
- Hybridisierung: Bei der Migration müssen während einer Übergangsphase häufig ältere und quantenresistente Algorithmen parallel ausgeführt werden.
- Zukunftssicherheit: Ein agiles System kann sich an die nächste Bedrohung anpassen, ohne dass ein mehrjähriger „Rip-and-Replace“-Zyklus erforderlich ist.
Um dies zu erreichen, müssen Unternehmen zunächst ein umfassendes Kryptografie-Inventar erstellen und dabei jede Instanz der Verschlüsselung in nationalen Sicherheitssystemen, Cloud-Assets und IoT-Geräten identifizieren.
„ Seien Sie der Zeit voraus. Sichern Sie noch heute Ihre digitale Zukunft
Machen Sie den nächsten Schritt mit TrustSource
Die Umstellung auf Post-Quantum-Kryptografie (PQC) muss keine Reise ins Ungewisse sein. TrustSource bietet die Tools und das Fachwissen, um sicherzustellen, dass Ihre Software Lösungen widerstandsfähig bleiben.
- TrustSource Cryptographic Discovery Services:
Wir helfen Ihnen dabei, Ihre aktuelle kryptografischen Algorithmen zu identifizieren, zu inventarisieren und zu bewerten, um einen Risiko-orientierten Weg zur Quantenresistenz zu entwerfen. - TrustSource SBOM-Bestands- und Compliance-Workflows:
Speichern Sie Ihre SBOMs im TrustSource-Bestand oder nutzen Sie die Genehmigungs-Workflows, um die Risiken vor der Veröffentlichung Ihrer Software zu verwalten. Dokumentieren Sie die Existenz und Verwendung von Kryptoalgorithmen auf der Grundlage unseres Komponenten-Know-hows, sei es für Exportkontrollen oder Ihre Krypto-Agility-Implementierungen. - TrustSource Crypto Reporting:
Profitieren Sie von der Portfolio-weiten Analyse der verwendeten Kryptoalgorithmen und definieren Sie Migrationsstrategien auf der Grundlage von Komponenten und Portfolio-Risiken. - TrustSource Crypto Policies:
Verwenden Sie Richtlinien, um die Implementierung und/oder Verwendung schwacher Algorithmen im gesamten Unternehmen direkt in beim Bau der Software zu verhindern.
Wollen Sie mehr zu dem Thema erfahren?
Cyber Resilience Act veröffentlicht
EU Cyber Resilience Act veröffentlicht
Heute wurde der EU Cyber Resilience Act (CRA) veröffentlicht. Damit sind seine Gültigkeit und der Zeitplan festgeschrieben, da sich aus dem Veröffentlichungsdatum die entsprechenden Daten für die Umsetzung ergeben: Beginn der tatsächlichen Gültigkeit – also der Zeitpunkt, ab dem jeder Software-Hersteller oder Vertreter eines solchen, der in der EU eine Software auf den Markt bringt, sich konform verhalten muss – ist der 11. Dezember 2027.
Genauer: Die Regelungen, insbesondere Art. 13 sowie Anhang I und II, gelten für alle Produkte mit digitalen Elementen, die ab diesem Termin in der EU auf den Markt kommen. Für Produkte, die vor diesem Termin auf den Markt kommen oder gebracht wurden, gelten die Anforderungen, sobald sie nach dem Termin wesentliche Änderungen erfahren, s. Art. 69 II CRA. Die Berichtserfordernisse aus Art. 14 sind jedoch für alle Produkte bereits ab dem 11. September 2026 zu bedienen, unabhängig vom Termin des Markteintritts (Art. 69 III CRA).
Von jetzt an zählt die Übergangsfrist, bis zu der sich Software-Anbieter mit den neuen Anforderungen auseinandersetzen, bzw. diese umsetzen müssen. Die Umsetzung ist stellenweise nicht trivial und erfordert einiges an organisationalem Wandel, bspw. die Aufnahme ggf. noch nicht vorhandener Risikoanalysen und -bewertungen in den Release-Prozess, die Deklaration von Unterstützungszeiträumen oder den Aufbau geeigneter Schwachstellen-Management-Prozesse.
– soweit nicht anders dargestellt, beziehen sich im Folgenden alle Verweise auf den Text des CRA –
Sie wollen klären, welche Anforderungen der CRA an Ihre Organisation stellt?
Sprechen Sie unverbindlich mit unserem Experten!
Für wen ist der Cyber Resilience Act von Bedeutung?
Der CRA betrifft grundsätzlich alle, die ein Produkt mit digitalen Elementen, also einer Software-Unterstützung bereitstellen. Allerdings schränkt er seine Gültigkeit auch gegenüber bereits anderweitig regulierten Gruppen ein. So werden Produkte, die sich nur im Automotive-Bereich, im Marine- oder Aviation-Umfeld bewegen oder der Medical Device Regulation unterliegen, ausgenommen. Es ist jedoch anzunehmen, dass eine Dual-Use-Möglichkeit, also eine Nutzbarkeit in anderen, nicht regulierten Bereichen, die Gültigkeit auch wieder herstellen wird.
Rollen der Akteure
Weiterhin ist die Rolle des Handelnden relevant für die Beurteilung der Gültigkeit. Konzeptuell versucht die Regulierung den Nutznießer der wirtschaftlichen Transaktion in die Verantwortung zu nehmen, der innerhalb der EU das Geschäft abbildet. Was bedeutet das?
Im einfachen Fall stellt ein europäischer Anbieter ein Produkt mit digitalen Elemente her, welches in den regulierten Bereich (s.o.) fällt. Somit steht der Anbieter direkt in der Pflicht, die CRA-Anforderungen für sein Produkt zu erfüllen, beispielsweise ein Hersteller für Stereoanlagen oder Musikboxen, die Musik-Streaming unterstützen oder eine Werkzeugmaschine, welche per Fernüberwachung gewartete werden kann.
Sitzt der Hersteller des Produktes außerhalb der EU, gehen diese Pflichten an seinen Stellvertreter über, den „Inverkehrbringer“. Dies kann ein Händler, ein Partner oder ein Implementierungspartner sein, eben der nächste wirtschaftliche Nutznießer. Interessant ist, dass dieser auch für die Einhaltung der Pflichten bei der Herstellung bürgen muss. Das bringt eine komplett neues Haftungsregime für bspw. Lizenzverkäufer amerikanischer Software mit sich!
Open Source
Sobald Open Source ins Spiel kommt, wird die Kette etwas unklarer. Aber der CRA kennt und berücksichtigt das Open Source Konzept. Der eigentliche Urheber einer Open Source Lösung bleibt von den Anforderungen verschont. Nimmt ein Akteur jedoch eine Open Source Lösung und nutzt sie wirtschaftlich, sei es durch Support-Verträge, treffen ihn die Regelungen analog zu denen eines Anbieters. Beispielsweise ist eine SUSE im Sinne des CRA verantwortlich für die von ihr bereitgestellte Distribution.
Ausnahmen gibt es nur für sogenannte Stewards. Diese haben weniger scharfe Anforderungen zu erfüllen. Diese Rolle wurde für die sogenannten Foundations (Eclipse, Cloud native, etc.) geschaffen, da sie zwar eine Form des Inverkehrbringers darstellen, jedoch keine mit einem herkömmlichen Software-Anbieter vergleichbaren, wirtschaftlichen Vorteile aus der Bereitstellung und Verbreitung ziehen. Um als Steward zu gelten, ist eine Anerkennung erforderlich.
Was sind die wesentlichen Neuerungen?
Der leitende Gedanke hinter dem CRA ist die Verbesserung der Sicherheitslage für die Konsumenten von Software. Da heutzutage fast alles von und mit Software gesteuert wird, bzw. ausgestattet ist, sind Cyber-Angriffe fast überall möglich. Jede Komponente, die durch eine Internetverbindung, ein WLan oder auch eine Near-Field-Kommunikation wie ZigBee oder Bluetooth zählt zur potentiellen Angriffsoberfläche – neu-deutsch: Attack Surface- und ist daher mit Bedacht zu nutzen, bzw. bereitzustellen.
Der Anbieter einer Software im europäischen Markt hat daher zukünftig folgende Anforderungen zu erfüllen:
- Bereitstellen eines Software Bill of Materials (SBOM), s. Anhang I
- Regelmäßiges Durchführen einer Risikobetrachtung der Sicherheitsrisiken sowie deren Aufnahme in die Dokumentation, s Art. 13, III und IV
- Erstellen einer Konformitätserklärung, s. Art. 13 XII, bzw. Art. 28 I sowie Anhang IV
- Bereitstellen einer CE-Kennzeichnung, s. Art. 12 XII, bzw. Art. 30 I
- Definition einer zu erwartenden Lebensdauer des Produktes und die Bereitstellung kostenloser Sicherheits-Updates innerhalb dieses Zeitraumes, s. Art. 13 VIII ff
- Einfordern umfangreicher Meldepflichten (gem. Art. 14)
- Mitteilung aktiv ausgenutzter Schwachstellen innerhalb von 24h an die European Network and Information Security Agency (ENISA) über eine noch zu schaffende Meldeplattform (vermutlich analog der bereits im Telekom-Umfeld bestehenden Lösung)
- Ergänzend hierzu eine Präzisierung der Einschätzung sowie der Maßnahmen innerhalb von 72h
- Information der Nutzer des Produktes sowie die von diesen zu ergreifenden Maßnahmen, s. Art. 14 VIII.
Wie kann TrustSource helfen?
- Einheitliche Plattform für Software Analyse, Compliance & Release-Management
- Integriertes Risiko-Management
- Automatisiertes Schwachstellen-Management
- Durchgängige, CRA-konforme Dokumentation
- CSAF-konforme Meldungen
- Einheitlicher Schwachstellen-Meldeprozess
- Umsetzungsunterstützung
Was sind die Auswirkungen der Nicht-Einhaltung?
Jedes Gesetz ist zunächst nur die Deklaration einer Verhaltensvorgabe. Was ist jedoch die Folge, wenn man sich nicht der Vorgabe gemäß verhält? Welche Risiken drohen den Anbietern?
Mit Veröffentlichung werden die Mitgliedsstaaten beauftragt, eine Stelle zu benennen, die für die Aufsicht in dem jeweiligen Land verantwortlich ist. In Deutschland wird dies nach aller Voraussicht das BSI sein. Dieses wiederum kann dann im Verdachtsfall entsprechende Prüfungen durchführen, bzw. beauftragen. Werden dabei Missstände festgestellt, führt dies in der Regel zur Aufforderung der Nachbesserung, kann jedoch auch entsprechend sanktioniert werden. Der CRA sieht folgende, mögliche Sanktionen vor:
- Bei Verstoß gegen grundlegende Sicherheitsanforderungen (Anhang I) bis zu 15 Mil. EUR oder, bei Unternehmen, bis zu 2,5% des weltweiten Jahresumsatzes im vorangegangenen Geschäftsjahr. (s. Art. 64 II)
- Bei Verstoß gegen Pflichten, die der CRA auferlegt, bis zu 10 Mil. EUR oder – für Unternehmen – bis zu 2% des ww Umsatzes (Vorjahr) (s. Art. 64 III)
- Für unrichtige, unvollständige oder irreführende Meldungen gegenüber den Behörden, bis zu 5 Mil. EUR, bzw. 1% des Jahresumsatzes für Unternehmen (s. Art. 64 IV)
Darüber hinaus besteht die Möglichkeit, bei nachhaltiger Nicht-Konformität die Verbreitung des Produktes einzuschränken, bzw. es vom Markt zu nehmen, s. bspw. Art. 58 II.
Sie sind sich nicht sicher, was das für Ihre Organisation bedeutet?
Sprechen Sie unverbindlich mit einem unserer Experten!