Krypto-Agilität: Der Weg von der Bedrohung zur Handlungsfähigkeit

Quantencomputer bedrohen die Grundlagen unserer digitalen Sicherheit. Holger von Rhein hat in seinem Beitrag die Hintergründe beleuchtet: Harvest Now, Decrypt Later, Moscas Theorem und die historische Einordnung kryptografisch relevanter Quantencomputer zeichnen ein klares Bild – wir müssen handeln. Dieser Artikel widmet sich dem „Wie“.

Die unbequeme Wahrheit: Kryptografie ist kein „Set and Forget“. Wer Holgers Artikel gelesen hat, kennt die Ausgangslage: Die Frage ist nicht mehr ob, sondern wann ein kryptografisch relevanter Quantencomputer Realität wird. Die NIST hat mit FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) bereits 2024 die ersten Post-Quantum-Standards finalisiert. Das BSI positioniert sich klar an der Seite der EU und empfiehlt, die Migration zeitnah einzuleiten. Die Werkzeuge liegen auf dem Tisch.

Und trotzdem wird das Thema in vielen Organisationen nicht mit der gebotenen Dringlichkeit behandelt, ähnlich wie in den frühen Tagen der DSGVO oder aktuell mit der NIS-2-Einführung. Man hat vielleicht davon gehört, aber unterschätzt, wie groß der Berg tatsächlich ist. In der Konsequenz bleibt der erste Schritt aus. Dabei offenbart die Post-Quanten-Herausforderung ein weit tieferliegendes, strukturelles Problem: Die meisten Organisationen wissen schlicht nicht, wo und wie sie Kryptografie einsetzen. Keine Inventare, keine zentrale Governance, keine Agilität. Kryptografie wurde über Jahrzehnte als unsichtbare Selbstverständlichkeit behandelt – eingebettet in Bibliotheken, Protokolle und Appliances, über die niemand eine Gesamtübersicht hat.

Genau hier setzt Krypto-Agilität an. Und nein, das ist kein bloßes Buzzword. Es beschreibt die Fähigkeit einer Organisation, kryptografische Algorithmen, Protokolle und Schlüssel systematisch, zeitnah und möglichst unterbrechungsfrei austauschen zu können – nicht nur einmal, sondern kontinuierlich. Denn selbst Post-Quanten-Algorithmen sind nicht für die Ewigkeit gemacht. Wer heute eine starre PQC-Migration durchführt, ohne dabei Agilität als Designprinzip zu verankern, schafft die nächste Altlast.

Bin ich überhaupt betroffen? Die kurze Antwort: Ja. Wenn eine Organisation digitale Kommunikation betreibt, Daten speichert oder Software entwickelt, nutzt sie Kryptografie. TLS, VPN, PKI, Festplattenverschlüsselung, Signaturverfahren, API-Authentifizierung: All das basiert auf kryptografischen Bausteinen, den sogenannten Primitiven,, die durch Quantencomputer bedroht sind.

Die differenziertere Antwort ergibt sich aus zwei Aspekten – dem Zeitdruck und der Komplexität der eigenen kryptografischen Landschaft. Dabei stehen Organisationen mit langfristig schützenswerten Daten unter dem höchsten Zeitdruck. Moscas Theorem gibt uns die entscheidende Formel an die Hand: Wenn die Summe aus der Geheimhaltungsdauer der Daten und der benötigten Migrationszeit größer ist als die Zeit bis zur Verfügbarkeit eines kryptografisch relevanten Quantencomputers, dann sind die Daten bereits jetzt im Risiko.

Für Organisationen, deren Daten über Jahrzehnte hinweg vertraulich bleiben müssen (etwa in der Verteidigung, der Forschung oder dem Gesundheitswesen), hätte die Migration bereits beginnen müssen. Doch mittlerweile geht die Gleichung für „normale“ Betriebe nicht mehr auf. Schon gesetzliche Aufbewahrungsfristen von zehn Jahren, etwa beim Handels- und Steuerrecht, reichen in Kombination mit realistischen Migrationszeiten aus, um das Zeitfenster von Moscas Theorem zu sprengen. Wenn ein Angreifender heute verschlüsselten Datenverkehr abfängt (Harvest Now, Decrypt Later), ist der Schaden bei der Verfügbarkeit eines kryptografisch relevanten Quantencomputers bereits eingetreten – unabhängig davon, wann das sein wird.

Das betrifft zum Beispiel:

  • Behörden und Verteidigung: Staatliche Kommunikation, die über Dekaden geheim bleiben muss.
  • Gesundheitswesen: Patientendaten unterliegen strengstem Schutz – und zwar dauerhaft.
  • Forschung und geistiges Eigentum: Forschungsergebnisse, deren wirtschaftlicher Wert auf Jahre hinaus kritisch ist.
  • Finanzsektor: Langfristige Vertragsdaten, Transaktionshistorien, strategische Planungen
  • Konzerne: Hochkomplexe IT-Landschaften, Patente, Firmengeheimnisse und strategische Planungen

Regulatorische Rahmenwerke verschärfen den Druck zusätzlich. Wer unter NIS-2, den Cyber Resilience Act (CRA), ISO 27001, IT-Grundschutz oder branchenspezifische Regelungen wie DORA oder TISAX fällt, wird sich bald mit der Frage konfrontiert sehen, ob die eigene kryptografische Praxis den Anforderungen noch genügt. Diese Regularien fordern üblicherweise bereits heute explizit den Einsatz „dem Stand der Technik entsprechender“ Kryptografie. Das BSI empfiehlt explizit klassisch eingesetzte Kryptografie für hohe Schutzbedarfe nur bis Ende 2030 und für die restlichen Anwendungen bis Ende 2031. Demnach ist die Definition vom „Stand der Technik“ klar: Die Nutzung von quantensicheren Verfahren.

Organisationen mit komplexen, historisch gewachsenen IT-Landschaften – typischerweise im Mittelstand und in Konzernen – stehen vor einer besonderen Herausforderung: Kryptografie steckt nicht nur in den offensichtlichen Punkten (TLS-Zertifikate, VPN-Gateways), sondern tief in der Lieferkette, in eingebetteten Systemen, in OT-Umgebungen und in selbst entwickelter Software. Die Migrationszeit kann hier besonders groß sein, was das von Mosca beschriebene Zeitfenster weiter verengt.

Selbst wenn ihre Daten keine jahrzehntelange Geheimhaltung erfordern und sie keiner strikten Regulatorik unterliegen: Krypto-Agilität ist eine architektonische Eigenschaft, die sich nicht über Nacht herstellen lässt. Wer heute beginnt, verschafft sich strategischen Spielraum. Wer wartet, wird irgendwann unter Zeitdruck und einem erhöhten Risiko sowie höheren Kosten migrieren müssen.

Der Weg zur Krypto-Agilität

Krypto-Agilität entsteht nicht durch ein einzelnes Projekt, sondern durch einen strategischen Aufbauprozess, der sich in klar abgrenzbare Phasen gliedern lässt. Im Folgenden skizzieren wir unseren erprobten Ansatz, der sich an der Realität mittelständischer und großer Organisationen orientiert.

Phase 1: Standortbestimmung – Wo stehen wir?

Bevor man irgendetwas migriert, muss man verstehen, was es zu migrieren gilt. Und genau hier liegt bei den meisten Organisationen die größte Lücke.

Unser Crypto-Basis-Check ist der erste, entscheidende Schritt. Er umfasst die Sichtung der kryptografischen Landschaft. Das bedeutet eine systematische Erfassung über alle relevanten Domänen hinweg, von der Zusammenarbeit, Vendor- & Supply-Chain-Readiness bis zum internen Wissen. Dabei betrachten wir alle kryptografischen Kategorien:

  • Operative Kryptografie: PKI-Infrastrukturen, Schlüsselmanagement, Konfigurationen, At-Rest-Verschlüsselung, OT-Umgebungen, …
  • Software-Kryptografie: Kryptografische Bibliotheken, Abhängigkeiten, hartcodierte Schlüssel oder Algorithmen …
  • Netzwerk-Kryptografie: Protokolle, Cipher Suites, In-Transit-Verschlüsselung, Firewall- und VPN-Konfigurationen, …
  • Managed und Hardware-basierte Kryptografie: Verwaltete Schlüssel, HSMs, …

Außerdem gilt klar: Nicht jede Kryptografie ist gleich kritisch. Die zentrale Frage lautet daher:

„Wie lange müssen welche Daten vertraulich, integer oder authentisch bleiben?“

Diese Frage speist direkt in Moscas Theorem ein und liefert die Grundlage für jede sinnvolle Priorisierung. Aus alldem entsteht ein Lagebild, das sich in einem Krypto-Reifegrad-Modell verdichten lässt – von Ad hoc (keine Sichtbarkeit, keine Strategie) bis Optimierend (automatisierte Inventarisierung, abgeschlossener PQC-Rollout für Hochrisikosysteme, kontinuierliche Verbesserung). Dieses Modell dient als KPI-Framework: messbar, nachvollziehbar und steuerungsrelevant. Ein solcher Basis-Check ist – je nach Größe der Organisation – in wenigen Tagen bis zu wenigen Wochen durchführbar und liefert die Entscheidungsgrundlage für alles Weitere.

Phase 2: Inventarisierung und Risikoanalyse – Was haben wir und was davon ist kritisch?

Auf dem Crypto-Basis-Check aufbauend folgt die systematische, unternehmensweite Inventarisierung kryptografischer Assets. Hier gelten einige Grundprinzipien, die wir aus der Praxis ableiten:

  • Vollständigkeit: Das Inventar wird nie vollständig sein – und das ist in Ordnung. Wer auf Vollständigkeit wartet, wird nie fertig. Wichtiger als Perfektion ist ein belastbarer Prozess, der kontinuierlich verbessert wird. Dennoch muss die Erfassung ambitioniert sein.
  • Automatisierung: Netzwerk-Scans, TLS-Checks, Dependency-Analysen in CI/CD-Pipelines – vieles lässt sich toolgestützt erfassen. Wo Scanner nicht hinkommen (OT, Legacy, Blackbox-Appliances), braucht es halbautomatisierte oder manuelle Erfassung.
  • Standardisierung durch CBOM: Die Cryptographic Bill of Materials (CBOM) hat sich als Standardformat für kryptografische Inventare etabliert. Wer sein Inventar heute auf dem CBOM-Standard aufbaut, schafft Anschlussfähigkeit für zukünftige Automatisierung und Tool-Ökosysteme.
  • Erweiterung des bestehenden Asset-Managements: In vielen Organisationen existieren bereits CMDB- oder Asset-Management-Systeme. Die Frage ist nicht, ob man ein neues System braucht, sondern wie sich das bestehende um kryptografische Attribute erweitern lässt.
  • Dokumentation: Was nicht erfasst werden kann, muss dokumentiert werden. Wenn ein System sich einer kryptografischen Inventarisierung entzieht – etwa eine proprietäre Appliance ohne Einsicht in die verwendete Kryptografie – ist das kein Grund, es zu ignorieren. Es ist ein Grund, es als Risiko zu behandeln und den Hersteller in die Pflicht zu nehmen.

Auf Grundlage des Inventars erfolgt die Risikoanalyse. Hierbei empfiehlt sich eine Dreistufung:

KategorieBeschreibung
Akutes Risikobereits heute unsichere Kryptografie (z.B. TLS 1.0, SHA-1, RSA < 2048 Bit)sofortiger Handlungsbedarf, unabhängig von der Quantenbedrohung
Quantum-Risikoheute noch sichere Kryptografie, in Zukunft durch Quantencomputer knackbarPriorisierung über Moscas Theorem
Kein (akutes) Risikokurzlebige Daten mit niedrigem Schutzbedarf und geringer Migrationszeit

Die Ergebnisse lassen sich in einer Risiko-Heatmap verdichten, die sowohl dem operativen Team als auch dem Management als Steuerungsinstrument dient. Assets, die sich der Inventarisierung entzogen haben, sollten mindestens als PQC-Risiko eingestuft werden, denn wo Unklarheit herrscht, muss das Vorsichtsprinzip gelten.

Ein nicht zu unterschätzender Nebeneffekt: Die kryptografische Risikoanalyse fördert häufig akute Schwachstellen zutage, die mit der Quanten-Bedrohung gar nichts zu tun haben. Veraltete Protokolle, abgelaufene Zertifikate, unsichere Konfigurationen – die „Krypto-Hygiene“ ist oft der erste sogenannte No-Regret-Move.

Phase 3: Governance – Richtlinien, Prozesse, Verantwortlichkeiten

Technische Migration ohne organisatorische Verankerung ist Sisyphusarbeit. Deshalb ist die Etablierung einer kryptografischen Governance ein essenzieller Baustein – und einer, der oft unterschätzt wird. Viele Organisationen verfügen über eine Krypto-Richtlinie und seltener über ein Krypto-Konzept. Für die vorhandene Richtlinie gilt allerdings oft, dass sie seit Jahren nicht aktualisiert wurde, ausschließlich auf die ungelesene TR-02102 des BSI für Details verweist und PQC nur indirekt berücksichtigt. Eine zeitgemäße Krypto-Richtlinie muss folgende Aspekte abdecken:

  • Zuverlässige Verfahren: Klare Vorgaben für zulässige Algorithmen, Schlüssellängen und Protokolle, inklusive einer Positionierung zu PQC und hybriden Verfahren
  • Regulatorischer Bezug: Ausrichtung an einschlägigen Standards und Vorgaben (BSI TR-02102, NIST SP 800-131A, branchenspezifische Regelwerke)
  • Reaktionsfähigkeit: Finden von Antworten auf die Fragen: Was passiert, wenn morgen ein Algorithmus gebrochen wird? Wer entscheidet? In welcher Zeit? Über welche Meldewege?

Kryptografie betrifft nicht nur die IT-Abteilung. Einkaufsprozesse müssen kryptografische Anforderungen an Produkte und Dienstleister stellen. Softwareentwicklungsprozesse müssen kryptografische Prüfungen einschließen. Und im Lieferantenmanagement müssen PQC-Roadmaps eingefordert und bewertet werden, denn Ihre Krypto-Agilität ist immer nur so gut wie die Ihrer schwächsten Abhängigkeit. Wenn Ihr VPN-Anbieter, Ihr Cloud-Dienstleister oder Ihr HSM-Hersteller keine PQC-Roadmap hat, wird Ihre eigene Migration an genau dieser Stelle blockiert. Der Dialog mit dritten Parteien muss frühzeitig und strukturiert geführt werden.

Phase 4: Proof of Concept und Pilotprojekte – Kontrolliertes Lernen

Bevor eine unternehmensweite Migration beginnt, braucht es kontrollierte Erfahrungsräume. PoC- und Pilotprojekte sind keine optionale Kür, sondern eine notwendige Risikominderung.

Warum Pilotprojekte unverzichtbar sind:

  • Wissensaufbau: PQC-Algorithmen verhalten sich anders als ihre klassischen Vorgänger. Signaturgrößen von ML-DSA oder SLH-DSA sind zum Teil erheblich größer als bei RSA oder ECDSA. Schlüsselgrößen bei ML-KEM unterscheiden sich von ECDH. Dieses Wissen muss in der Organisation ankommen. Nicht nur theoretisch, sondern durch praktische Erfahrung.
  • Interoperabilitätstests: Legacy-Systeme und Middleware kommen mit größeren Schlüsseln und Signaturen nicht immer zurecht. Paketgrößen können MTU-Grenzen überschreiten, Zertifikatsketten können Parser überfordern, Handshakes können Timeouts auslösen. All das will vor dem Produktiv-Rollout entdeckt werden.
  • Hybride Verfahren validieren: Der empfohlene Migrationspfad führt über hybride Kryptografie – also die Kombination klassischer und PQC-Algorithmen. Damit bleibt die Sicherheit auch dann gewährleistet, wenn sich einer der beiden Algorithmen als schwächer herausstellt als erwartet.

Phase 5: Migration und kontinuierliche Verbesserung

Die eigentliche Migration ist kein Sprint, sondern ein priorisierter, phasenweiser Marathon. Dabei müssen Abhängigkeiten der Assets untereinander, technische Einschränkungen und Work-Arounds sowie Kritikalität berücksichtigt werden. Außerdem können PQC-Algorithmen – je nach Parametersatz – signifikant größere Schlüssel, Signaturen und Ciphertexte erzeugen. Das hat Auswirkungen auf Netzwerkbandbreite, Speicher, CPU-Last und Latenz. Eine vorgelagerte Kapazitätsplanung verhindert böse Überraschungen im Produktivbetrieb.

PQC ist komplex. Entwickelnde und Administrierende müssen verstehen, was sich ändert, warum es sich ändert und wie die neuen Algorithmen korrekt eingesetzt werden. Falsch konfigurierte PQC-Kryptografie ist nicht besser als gar keine. Schulungen sind also zu Beginn von Migrationsbestrebungen besonders sinnvoll.

Nach Abschluss der Migrationsschritte sollte der Krypto-Reifegrad erneut erhoben werden. Das macht Fortschritte sichtbar, identifiziert verbleibende Baustellen und gibt dem Management eine belastbare Grundlage für weitere Investitionsentscheidungen.

Krypto-Reifegrad: Wo stehen Sie?

Um die eigene Position auf dem Weg zur Krypto-Agilität greifbar zu machen, hat sich ein fünfstufiges Reifegradmodell bewährt:

StufeBezeichnungCharakteristik
1Ad hocKeine Sichtbarkeit über die eigene kryptografische Landschaft. Kryptografie wird reaktiv und ohne zentralen Plan implementiert. Kein Bewusstsein für PQC-Risiken.
2SensibilisiertWichtige Stakeholder sind informiert. Erste isolierte Assessments finden statt. Pläne werden entwickelt, um Erwartungen und Erkenntnisse mit relevanten Stakeholdern zu teilen.
3StrukturiertUnternehmensweite Krypto-Inventare sind erstellt. Risiko-Heatmaps und Strategiedokumente liegen vor. Tools und Ressourcen für die Migration sind identifiziert und zugewiesen.
4OperativPrinzipien der Krypto-Agilität sind in der Architektur verankert. PQC-Piloten laufen. Kryptografische Metriken werden überwacht (z. B. Alerts bei Richtlinienverstößen, Certificate-Lifecycle-Monitoring, Anomalie-Erkennung in hybriden Prozessen).
5OptimierendVollständig automatisierte Inventarisierung und Krypto-Überwachung. PQC-Rollout für Hochrisikosysteme ist abgeschlossen. Prozesse zur kontinuierlichen Verbesserung sind etabliert. Die Organisation kann schnell auf neue Standards oder Bedrohungen reagieren.

Die meisten Organisationen, mit denen wir sprechen, befinden sich derzeit irgendwo zwischen Stufe 1 und 2. Das ist keine Schande – es ist der Normalzustand. Entscheidend ist, dass der Weg nach oben jetzt beginnt.

Der nächste Schritt

Die Post-Quanten-Migration ist aktuell eine der größten Herausforderungen für die IT-Sicherheit. Sie betrifft jede Schicht des Technologie-Stacks, jede Branche und jede Organisationsgröße. Aber sie kann bewältigt werden, wenn man sie strukturiert angeht. Der beste Zeitpunkt, mit Krypto-Agilität zu beginnen, war gestern. Der zweitbeste ist heute.

Weitere News im April

BrowserGate: Clientseitige Telemetrie trifft Compliance

Die Webseite BrowserGate der Organisation Fairlinked wirft LinkedIn vor, beim Aufruf der Website systematisch auf installierte Browser-Erweiterungen zu prüfen und dabei zusätzliche Browser- bzw. Geräteinformationen zu erfassen und daraus ein weitreichendes Nutzerprofil abzuleiten. BleepingComputer hat wesentliche Teile der technischen Praxis unabhängig nachvollzogen. Demnach wurde beim Seitenaufruf ein Script geladen, das in Tests 6.236 Extensions per Resource-Probing prüfte und weitere Merkmale wie CPU-Kerne, Speicher, Bildschirmauflösung, Zeitzone, Spracheinstellungen und Batteriestatus erfasste. Nicht unabhängig verifiziert wurden dagegen die von Fairlinked behauptete konkrete Weitergabe der Ergebnisse an Dritte oder deren spezifische Nutzung.

LinkedIn bestreitet die Missbrauchs- bzw. „Spionage“-Deutung und erklärt, die Erkennung bestimmter Extensions diene dem Schutz der Plattform, der Durchsetzung der Nutzungsbedingungen, der Abwehr von Scraping sowie der Stabilität des Dienstes. Das Unternehmen erklärte außerdem, die Daten nicht zur Ableitung sensibler Eigenschaften von Mitgliedern zu verwenden.

In Europa wird in diesem Zusammenhang vor allem die Frage aufgeworfen, ob LinkedIn nach dem Digital Markets Act als „Gatekeeper“, also als Technologiekonzern mit besonderer Marktmacht, einzustufen ist, für den besondere regulatorische Vorgaben gelten. Diese Einordnung stammt bislang insbesondere aus dem Fairlinked/BrowserGate-Umfeld. Ob und in welchem Umfang daraus formelle Verfahren oder weitergehende Klagen entstehen, geben die Quellen nicht her.

Aus Compliance- und Security-Sicht zeigt der Fall, dass Extension-Scanning und Browser-Fingerprinting auch dann erhebliche Privacy-, Transparenz- und Governance-Risiken erzeugen können, wenn sie technisch mit Anti-Abuse-Zielen begründet werden. Ähnliche Techniken können zur Profilbildung und zum Tracking beitragen.

https://browsergate.eu

https://www.bleepingcomputer.com/news/security/linkedin-secretly-scans-for-6-000-plus-chrome-extensions-collects-data

https://www.linkedin.com/pulse/linkedin-accused-extensive-browser-surveillance-pdfze

https://www.msn.com/en-us/news/technology/browsergate-report-alleges-linkedin-scans-extensions-and-devices/ar-AA20kK5c

https://pipelab.org/blog/linkedin-browsergate-agent-fingerprinting

Quanten-Computer: Der Wendepunkt für Public-Key-Kryptografie ist erreicht

Noch vor wenigen Jahren galt der „quantum break of ECC“ als theoretisches Langzeitrisiko. Diese Einschätzung hat sich im März und April 2026 grundlegend geändert.

Auslöser ist eine ungewöhnlich dichte Abfolge belastbarer Signale aus Forschung und Industrie, zusammengefasst und klar eingeordnet von Filippo Valsorda (Kryptografie-Pionier und Betreuer der Kryptografie-Standardbibliothek der Programmiersprache Go). Seine zentrale Botschaft ist unmissverständlich: Die Migration zu Post‑Quantum‑Kryptografie ist kein strategisches Planungsprojekt mehr, sondern ein akutes Shipping‑Problem.

Nach Einschätzung von Filippo Valsorda erleben wir einen Risikokipppunkt. Selbst wenn sich einzelne Prognosen im Rückblick als zu pessimistisch erweisen sollten, ist Untätigkeit inzwischen die riskantere Entscheidung. Post‑Quantum‑Kryptografie ist seit 2026 weder Forschungs‑ noch Vorbereitungsthema – sie ist operative Sicherheitsarbeit.

https://words.filippo.io/crqc-timeline

Aktive Ausnutzung der Langflow-Schwachstelle CVE-2026-33017

In der Open-Source-Plattform Langflow, einem weitverbreiteten Werkzeug zum visuellen Erstellen und Betreiben von KI-Agenten und KI-Workflows, wurde im März 2026 eine kritische Sicherheitslücke unter der Kennung CVE-2026-33017 öffentlich bekannt. Die Schwachstelle ermöglicht es Angreifenden, ohne jegliche Authentifizierung beliebigen Programmcode auf betroffenen Servern auszuführen – ein Szenario, das in der Informationssicherheit als unauthentifizierte Remote Code Execution (RCE) klassifiziert wird und die höchste Risikostufe darstellt. Die US-amerikanische Cybersicherheitsbehörde CISA hat die Schwachstelle in ihren Katalog der nachweislich aktiv ausgenutzten Sicherheitslücken (Known Exploited Vulnerabilities, KEV) aufgenommen, was bedeutet, dass reale Angriffe in freier Wildbahn beobachtet wurden, und nicht lediglich ein theoretisches Risiko besteht.

Der technische Kern der Schwachstelle liegt in einem fundamentalen Design- und Implementierungsfehler im Zusammenspiel zwischen öffentlich zugänglichen Funktionen und der internen Code-Ausführung. Langflow bietet einen sogenannten „Public Flow Build“-Endpunkt an, der bewusst ohne Anmeldung erreichbar ist, damit öffentliche Flows – also vorgefertigte KI-Workflows – von externen Nutzern angestoßen werden können. Der Endpunkt ist absichtlich öffentlich gestaltet, weil er eine legitime Geschäftsfunktion – das Teilen und Ausführen öffentlicher Flows – bedient. Das eigentliche Versäumnis liegt darin, dass eine öffentlich zugängliche Funktion ausführbare, von außen kontrollierbare Definitionen annimmt und diese ohne ausreichende Validierung oder Isolation zur Ausführung bringt. Es handelt sich also um ein architektonisches Problem an der Schnittstelle zwischen Offenheit und Sicherheit.

Öffentlich zugängliche Funktionen, die „Code als Daten“ entgegennehmen und verarbeiten, stellen ein inhärent hohes Risiko dar. Die Kombination aus einem unauthentifizierten Endpunkt, der Annahme ausführbarer Definitionen von außen und einer fehlenden Sandbox bei der Code-Ausführung bildet genau jenes toxische Muster, das CVE-2026-33017 so gefährlich und so einfach ausnutzbar macht.

https://www.heise.de/news/Jetzt-patchen-Schadcode-Attacken-auf-KI-Tool-Langflow-beobachtet-11226852.html

https://www.cve.org/CVERecord?id=CVE-2026-33017

https://github.com/langflow-ai/langflow/security/advisories/GHSA-vwmf-pq79-vjvx

https://github.com/advisories/GHSA-rvqx-wpfh-mfx7

Iranische Hacker veröffentlichen private E-Mails von FBI-Direktor Kash Patel

Eine dem iranischen Staat zugerechnete Hackergruppe hat private E-Mail-Konten von FBI-Direktor Kash Patel kompromittiert und Teile der erbeuteten Korrespondenz öffentlich ins Netz gestellt. Das FBI hält technische Details zum konkreten Vorfall bislang zurück. Das US-Außenministerium reagierte mit einer öffentlichen Auslobung einer Belohnung von bis zu zehn Millionen US-Dollar für Hinweise, die zur Identifizierung oder Lokalisierung der verantwortlichen iranischen Cyber-Akteure führen.

Der Vorfall unterstreicht, wie staatlich gesteuerte Hackergruppen zunehmend persönliche Kommunikationskanäle hochrangiger Beamter ins Visier nehmen, um politischen Druck auszuüben. Selbst private Accounts von Entscheidungsträgern sind inzwischen ein erstrangiges Ziel geopolitisch motivierter Cyberoperationen.

https://therecord.media/fbi-confirms-theft-of-directors-personal-emails-iran-group

https://therecord.media/iran-hackers-state-department-reward

EU Top Officials & Signal

Politico berichtet, dass die Kommission eine Signal‑Gruppe hochrangiger Beamter auflösen ließ – präventiv, ohne bestätigte Kompromittierung.

Doch warum ist ausgerechnet Signal ein Problem – ein Messenger, der für seine starke Verschlüsselung bekannt ist? Die Antwort gilt nicht nur für Signal, sondern für nahezu alle privaten Messenger-Apps: Sie wurden für den persönlichen Gebrauch entwickelt und optimiert. Für den Einsatz in institutionellen Umgebungen – insbesondere in Regierungen und Behörden – fehlen ihnen entscheidende Funktionen:

  • zentrales User Management – Es gibt kein Onboarding/Offboarding durch IT-Administratoren.
  • Audit Trail – Es besteht keine nachvollziehbare Protokollierung von Aktivitäten.
  • Compliance-Archivierung – Es existiert keine rechtskonforme Aufbewahrung dienstlicher Kommunikation.
  • MDM-Integration – Private Messenger-Apps lassen sich als App per MDM verteilen, bieten aber keine nativen Enterprise‑Admin‑Funktionen wie zentrales User‑Management, Audit/Archive oder eDiscovery.
  • Geräte-Policy-Enforcement – Private Messenger-Apps selbst erzwingen keine institutionellen Richtlinien. Diese lassen sich nur über Geräte‑ und App‑Policies der MDM/EMM‑Plattform abbilden.
  • Sicherheitsfreigabe-Verknüpfung – Es erfolgt keine Kopplung an Freigabestufen oder Berechtigungskonzepte.
  • Kontrollierte Gruppenverwaltung – Es liegt keine abgesicherte Steuerung von Gruppenmitgliedschaften vor.
  • Forensische Auditierbarkeit – Es fehlt eine zentrale Auditierbarkeit/Archivierung. Forensik ist auf Endpoint‑Ebene möglich, aber stark vom Gerät und den Governance‑Rahmenbedingungen abhängig.

Kurz gesagt: Das Signal-Protokoll ist nicht das Problem. Das Problem ist, dass ein Werkzeug, das Einzelpersonen vor Überwachung schützen soll, für die gesteuerte und rechenschaftspflichtige Kommunikation einer Institution schlicht nicht vorgesehen ist.

https://www.politico.eu/article/top-eu-officials-signal-group-chat-hacking-fears

Wann lohnt sich der Quantensprung? Post-Quanten-Kryptographie 

Asymmetrische Kryptographie ist heute weit verbreitet. Algorithmen, die heute noch als sicher gelten, können von den Quantencomputern von morgen gebrochen werden. 

Asymmetrische Kryptographie-Algorithmen basieren auf mathematischen Problemen (Primfaktorzerlegung oder Berechnung des diskreten Logarithmus), die als schwer zu lösen gelten. Bereits Anfang der 90er-Jahre hat Peter Shor den nach ihm benannten Algorithmus entwickelt, mit dem die genannten mathematischen Probleme auf einem Quantencomputer effizient berechnet werden können. Um das zu verdeutlichen: Um eine n-Bit Zahl zu faktorisieren, sind etwa 2n Qubits nötig. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) fordert bei der Verwendung von RSA eine Schlüssellänge von mindestens 2000 Bit, für den Einsatzzeitraum über das Jahr 2022 hinaus sogar mindestens 3000 Bit. Das bedeutet, dass man bei der Verwendung von RSA mit einer Schlüssellänge von 2048 Bit schon theoretisch einen Quantencomputer mit über 4000 Qubit braucht. Praktisch sind wegen technischer Herausforderungen beim Bau von Quantencomputern wesentlich mehr Qubits notwendig. Der Physikforscher Michele Mosca schätzt, dass es mit einer Wahrscheinlichkeit von 50 % einen effizienten Quantencomputer bereits ab 2030 geben wird. 

Aber nicht nur asymmetrische Verschlüsselungs- und Signaturverfahren sind gefährdet, sondern auch symmetrische Verschlüsselungsverfahren und Hashfunktionen. Denn mit dem ebenfalls in den 90er-Jahren entwickelte Such-Algorithmus „Grover“ kann die Komplexität von Suchproblemen auf ungeordnete Daten auf die Wurzel der klassischen Komplexität reduziert werden. Infolgedessen müssen die Schlüssellängen angepasst werden. Es wird heute schon bei Neuentwicklungen davon abgeraten, AES-128 zu verwenden. Stattdessen sollte AES-256 genutzt werden, da davon ausgegangen wird, dass die Verwendung einer Schlüssellänge von 256 Bit langfristig einen hinreichenden Schutz gegen Quantencomputer-Angriffe bietet. 

Auch wenn der Durchbruch in der Quanteninformatik noch einige Jahre auf sich warten lässt, müssen sich Organisationen rechtzeitig auf den reibungslosen Übergang zu quantensicheren Systemen vorbereiten. Die Auswahl geeigneter Algorithmen sowie das Umstellen auf quantensichere Systeme kann eine besondere Herausforderung für viele Organisationen sein. In den letzten Jahren wurden enorme Fortschritte in der Quanteninformatik erzielt, so dass der erste Quantencomputer, der in der Lage ist, asymmetrische Kryptographie-Verfahren zu brechen, in wenigen Jahren zur Verfügung stehen könnte. Organisationen, die die gefährdeten Verfahren verwenden, um Daten mit langen Lebenszyklen zu schützen, müssen sich am besten jetzt schon um eine geeignete Alternative kümmern. Dazu zählen z. B. Gesundheitsdaten, die 10 Jahre sicher aufbewahrt werden müssen. Wenn 2030 der erste Quantencomputer zur Verfügung stehen sollte, könnten die Angreifer die verschlüsselten Daten bereits jetzt abfangen und dann entschlüsseln (hack now – decrypt later). Für Signaturen drängt die Zeit noch weniger, denn Angriffe auf frühere Kommunikation sind nicht möglich. 

Die US-Bundesbehörde National Institute of Standards and Technology (NIST), die bereits in der Vergangenheit für den Standardisierungsprozess bekannter kryptographischer Verfahren (wie z. B. AES) zuständig war, ist bereits seit 2016 auf der Suche nach neuen kryptographischen Standards, die gegen Quantencomputer resistent sind.  

Das NIST hat bereits im Juni 2022 erste Post-Quanten-Kryptographie-Verfahren zur öffentlichen Kommentierung standardisiert. Als Beispiel wurde CRYSTALS-Kyber ausgewählt, das auf dem Learning with Error (LWE) Problem basiert, welches auf Probleme in mathematischen Gittern zurückzuführen ist. Dieses Forschungsfeld ist jedoch noch recht jung. 

Ebenfalls im Juni 2022 hat die Runde 4 des Auswahlprozesses bei NIST begonnen. Einer der Finalisten ist das codebasierte Verfahren McEliece, welches auf fehlerkorrigierenden Codes basiert. Im Gegensatz zu den gitterbasierten Verfahren wurde das McEliece-Verfahren bereits im Jahr 1973 entwickelt und konnte somit bereits lange ausgiebig erforscht werden. Jedoch ist die Schlüsselerzeugung mit einem hohen Aufwand verbunden, da große Matrizen verarbeitet werden müssen. Dafür sind die Ver- und Entschlüsselungsalgorithmen extrem schnell und der Ciphertext ist bisher der kleinste aller NIST-Post-Quanten-Kryptographie-Kandidaten. 

Auch das BSI hat bereits erste Empfehlungen ausgesprochen. Dazu zählen z. B. die Entwicklung von kryptoagilen Lösungen und die Verwendung von Post-Quanten-Kryptographie Algorithmen in hybrider Form, also in Kombination mit klassischen kryptographischen Algorithmen, da viele Verfahren noch sehr jung und wenig erforscht sind. Dies führt zu den nächsten Herausforderungen. Kryptographische Protokolle müssen weiterentwickelt werden und die Public-Key-Infrastruktur muss in der Lage sein, Zertifikate zu verarbeiten, die sowohl die längeren klassischen Schlüssel als auch die quantensicheren Schlüssel enthalten. 

Unsere Experten der HiSolutions AG analysieren für Sie Ihre spezifischen Systeme, die kryptographische Verfahren verwenden, um die notwendigen Änderungen für die Migration zu Post-Quanten-Kryptographie-Lösungen unter Berücksichtigung spezifischer Anforderungen zu identifizieren. Dabei entwickeln wir für Sie geeignete Migrations- und Übergangslösungen. Ebenfalls möchten wir das Bewusstsein für die Problematik schärfen, die sich aus der Entwicklung der Quanteninformatik ergeben. 

Für mehr Informationen zum Quantencomputer und den Gefährdungen wie Lösungsmöglichkeiten, siehe auch dieses Dokument des BSI

NIST Post Quantum Cryptography Wettbewerb geht in die vierte Runde

Beim US-amerikanischen NIST ist am 5. Juli 2022 die dritte Runde des öffentlichen Wettbewerbs zur Auswahl von Verfahren für quantencomputersichere kryptographische Verfahren, Post Quantum Cryptography (PQC), zu Ende gegangen.

Nachdem bereits in den vorangegangen Runden kräftig aussortiert worden war, wurde nun ein einziges Schema (CRYSTALS-Kyber) für Verschlüsselung & Schlüsselaustausch ausgewählt. Für digitale Signaturen schafften es immerhin drei Verfahren – CRYSTALS-Dilithium, FALCON und SPHINCS+ – in die Standardisierung, die nun etwa zwei Jahre in Anspruch nehmen soll.

UPDATE 5. August 2022: Dazu sind nach dem Ausscheiden von SIKE noch drei weitere Verfahren auf dem Prüfstand.

Da dies jedoch auch im besten Fall zu wenige Verfahren sind, um sicherzustellen, dass mindestens eines pro Anwendungsfall auch die nächsten Jahre der Forschung und Kryptoanalyse überleben wird, gibt es nun zusätzlich einen neuen Aufruf zu einer vierten Runde, in der weitere Verfahren eingebracht und diskutiert werden sollen.