Tag Archives: Security

Passkeys, elliptische Kurven und das Vertrauen in Root-CAs

Immer noch sind Passwörter Standard und es stellt sich zunehmend die Frage, warum an ihrer Stelle nicht schon viel früher sicherere Verfahren zum Einsatz kamen. Während Linux-Administratoren auf SSH-Keys setzen, wurde das Web bislang kaum von diesem Modell profitiert. Erst mit der Einführung von Passkeys – auf Basis von WebAuthn und FIDO2 – zeichnet sich ein genereller Wechsel ab. Im Folgenden wird erläutert, wie Passkeys technisch funktionieren, weshalb elliptische Kurven eine zentrale Rolle spielen, welche Schwachstellen das PKI-Modell mit Root-CAs aufweist und warum die Kombination aus Enpass und Brave Browser in der Praxis überzeugt.

1. Historischer Rückblick: Von Passwörtern zu Kryptographie

Passwörter sind nahezu so alt wie die ersten Computer – erste Systeme der 1960er Jahre nutzten einfache Zeichenketten als Zugangsschutz. Im Enterprise-Umfeld und bei Unix-Systemen setzte sich bald das SSH-Key-Verfahren durch: Ein asymmetrisches Schlüsselpaar ersetzte dort bereits in den frühen 1990er Jahren das klassische Passwort.

Parallel dazu entstand 1977 mit RSA (benannt nach Rivest, Shamir und Adleman) eine der ersten Public-Key-Kryptosysteme, das auf der Schwierigkeit der Faktorisierung großer Zahlen beruhte. Trotz ihrer mathematischen Eleganz haben RSA-Authentifikatoren im Vergleich zu modernen Verfahren einen entscheidenden Nachteil: Die für vergleichbare Sicherheit nötigen Schlüssel (z. B. 2048 Bit) sind groß, rechenintensiv und auf mobilen Geräten nur eingeschränkt praktikabel.

Passwörter dagegen haben sich in den letzten fünf Jahrzehnten kaum weiterentwickelt – sie bleiben anfällig für Brute-Force-Angriffe, Phishing und Credential Stuffing. Dass das Web erst jetzt beginnt, Schlüssel statt Passwörter zu verwenden, mag überraschen. Der Grund liegt in der Komplexität: WebPlattformen benötigten einen einheitlichen Standard, robuste Browser-APIs und breit unterstützte Hardware-Authenticators. All dies ist erst in den letzten Jahren durch WebAuthn und FIDO2 zusammengewachsen.

2. Warum Passkeys erst jetzt durchbrechen

Mehrere Faktoren trugen dazu bei, dass Passkeys erst im Jahr 2024/25 auf breiter Basis verfügbar sind:

Standardisierung: WebAuthn (2018) und FIDO2 schufen ein offenes Framework für browser- und plattformübergreifende Authentifizierung.
Browser-Support: Alle großen Browser (Chrome, Firefox, Edge, Safari) bieten heute native WebAuthn-APIs, inklusive UI-Dialogs zur Geräteauswahl und Biometrieabfrage.
Betriebssystem-Integration: Secure Enclave (macOS/iOS), TPM (Windows), Android Keystore und vergleichbare Hardwaremodule ermöglichen die sichere Schlüsselspeicherung.
Synchronisation: Hersteller-übergreifende Passkey-Synchronisation (iCloud Keychain, Google Password Manager, aber auch plattformunabhängige Tools) beseitigt das Vendor-Lock-in.
Usability: Biometrische Freigabe oder Geräte-PIN ersetzt das Tippen langer Passwörter, gerade auf Mobilgeräten ein erheblicher Vorteil.

Diese Entwicklungen haben eine kritische Masse erreicht: Heute kann praktisch jede Web-Applikation Passkey-Anmeldung anbieten, ohne eigene Hardware-Token entwickeln zu müssen.

3. Technische Grundlagen der Passkeys

3.1 Schlüsselerzeugung und -speicherung

Schlüsselpaar: Beim Anlegen eines Passkeys generiert das Endgerät (Client) ein Schlüsselpaar.
Public Key: Wird zusammen mit einem Credential ID und Metadaten (z. B. Attestation Statement) an den Dienst übermittelt.
Private Key: Verbleibt in Secure Enclave, TPM oder im Password Manager (z. B. Enpass) und verlässt das Gerät nie.

3.2 Elliptische Kurven (ECC)

Primäralgorithmus: ECDSA über P-256 (COSE -7) – bietet mit 256 Bit Sicherheit vergleichbar zu 3 000 Bit RSA.
Vorteile:
Kurvenskepsis: Obwohl einige NIST-Kurven (P-256) wegen NSA-Herkunft kritisch betrachtet werden, gibt es transparentere Alternativen wie Ed25519 – deren Verfügbarkeit in WebAuthn jedoch noch nicht flächendeckend ist.

3.3 Ablauf einer Authentifizierung

Challenge: Server generiert Nonce und sendet sie an den Client.
Signatur: Client signiert die Challenge zusammen mit AuthenticatorData (Flags, Counter, RP-ID-Hash).
Verifikation: Server überprüft Signatur mit dem gespeicherten Public Key.

Dank Domain-Binding (RP-ID) ist eine Signatur nur für die exakte Domain gültig – Phishing-Versuche werden damit wirkungsvoll abgewehrt.

4. Die Achillesferse der PKI: Vertrauen in Root-CAs

Auch wenn TLS 1.3, Perfect Forward Secrecy und starke Cipher Suites eingesetzt werden, bleibt das hierarchische Root-CA-Modell angreifbar:

Blindes Vertrauen: Browser liefern hunderte Root-Zertifikate aus, denen automatisch vertraut wird. Ein kompromittiertes oder erzwungen ausgestelltes Zertifikat erlaubt MITM-Angriffe.
Regierungsdruck: Staaten können CAs zur Ausstellung von Zertifikaten für beliebige Domains zwingen. Selbst strenge TLS-Konfiguration nützt wenig, wenn der Client ein manipuliertes Zertifikat akzeptiert.

Passkeys adressieren nicht das Transportproblem, sie schließen jedoch die Lücke bei der Identifikation des Nutzers. In Kombination mit HSTS, Certificate Pinning oder alternativen Trust-Modellen (TOFU, DANE) lässt sich das Gesamtsicherheitsniveau deutlich steigern.

5. Praxisbeispiel: Enpass + Brave Setup

Für plattformübergreifende Passkey-Verwaltung nutze ich persönlich Enpass in Kombination mit Brave. Beim ersten Login auf einer Website mit Passkey-Support wird Enpass zur Auswahl des passenden Credentials aufgefordert. Biometrie, PIN-Eingabe oder Masterpasswort auf dem Gerät schalten den privaten Schlüssel frei, und die Anmeldung erfolgt mit einem Klick. Das Ergebnis: Einfache sichere Logins, mit einem Masterpasswort / Pin gesichert.

6. Fazit

Passkeys markieren einen überfälligen Schritt hin zu passwortlosen Authentifizierungslösungen. Sie verbinden starke asymmetrische Kryptographie (vorzugsweise ECC) mit hoher Benutzerfreundlichkeit und Phishing-Resistenz. Der noch immer angreifbare Teil bleibt die TLS-Infrastruktur auf Basis von Root-CAs – doch hier lassen sich mit ergänzenden Maßnahmen Schwachstellen reduzieren.

In der täglichen Praxis erweist sich das Setup aus Enpass und Brave als robust, plattformunabhängig und wartungsarm. Damit steht einer breiten Einführung passkeybasierter Logins nichts mehr im Wege – abgesehen von der alten Gewohnheit, weiterhin an Passwörtern festzuhalten.

In meinen Augen ist dieser Paradigmenwechsel längst überfällig.

Risiken durch Microsoft Entra ID & Microsoft 365 für deutsche Unternehmen mit besonderen Geheimhaltungspflichten und Behörden

In den vergangenen Jahren haben Cloud-Dienste wie Microsoft Entra ID (früher Azure AD) und Microsoft 365 ihren Siegeszug in deutschen Unternehmen und Behörden angetreten. Sie bieten attraktive Vorteile wie Skalierbarkeit, einfache Administration und umfassende Kollaborationstools. Doch gerade für deutsche Unternehmen und Behörden mit hohen Geheimhaltungspflichten, etwa im Bereich Steuern, Justiz, Gesundheitswesen oder kritischer Infrastruktur, entstehen hierdurch signifikante, oft unterschätzte Risiken.

Dieses Whitepaper erläutert, warum die Verwendung von Microsoft Entra ID sowie Microsoft 365 aus Sicht des Datenschutzes und der Datenhoheit kritisch bewertet werden sollte – insbesondere vor dem Hintergrund bestehender US-Gesetze wie dem CLOUD Act und FISA.

1. Ausgangslage: Rechtsgrundlagen in den USA

CLOUD Act

Der 2018 verabschiedete Clarifying Lawful Overseas Use of Data Act (CLOUD Act) verpflichtet US-Technologieanbieter wie Microsoft dazu, gespeicherte Kundendaten – auch wenn diese außerhalb der USA lagern – an US-Behörden herauszugeben. Ausschlaggebend ist hier nicht der Speicherort der Daten, sondern die Kontrolle durch den Anbieter.

Foreign Intelligence Surveillance Act (FISA)

FISA ermöglicht US-Geheimdiensten Zugriff auf Daten ausländischer Bürger und Institutionen, sofern die Informationen als relevant für die nationale Sicherheit eingeschätzt werden. FISA-Beschlüsse erfolgen geheim und ohne Kenntnis der Betroffenen.

National Security Letters (NSL)

US-Behörden wie das FBI nutzen NSLs, um bei Unternehmen Teilnehmerdaten (etwa Metadaten oder Zugangsinformationen) abzufragen – ohne richterliche Genehmigung und oftmals mit einer Geheimhaltungsverpflichtung (Gag Order) versehen.

2. Technische Implikationen für Entra ID und Microsoft 365

Die genannten US-Gesetze zielen auf Anbieter wie Microsoft, die sowohl vertraglich als auch technisch in der Lage sind, auf die Daten ihrer Kunden zuzugreifen. Dienste wie Microsoft Entra ID und Microsoft 365 werden vollständig unter Kontrolle von Microsoft betrieben. Daten werden zwar verschlüsselt gespeichert („Data at Rest“ und „Data in Transit“), jedoch hält Microsoft die Verschlüsselungsschlüssel selbst – eine Ende-zu-Ende-Verschlüsselung (Zero-Knowledge) besteht nicht.

Dies bedeutet konkret:

Microsoft verfügt jederzeit über die technischen Mittel, Kundendaten – inklusive Dokumente, Mails und Identitätsinformationen – auszulesen.
Ein Zugriff durch US-Behörden auf Basis von US-Gerichtsbeschlüssen oder geheimen Anordnungen ist technisch unkompliziert möglich.
Ein Schutz vor Zugriffen nach US-Recht erfolgt lediglich durch vertragliche Zusicherungen, nicht aber durch eine tatsächlich unabhängige technische Architektur.

3. Risiken durch politische Entwicklungen in den USA

Insbesondere unter einer US-Regierung, die nationale Sicherheitsinteressen expansiv definiert, steigt das Risiko deutlich. Bereits während der ersten Amtszeit der Trump-Regierung wurde sichtbar, wie schnell politische Veränderungen sich auf internationale Datenschutzstandards auswirken können.

Ein erneuter Politikwechsel in den USA hin zu einem expansiven Sicherheitsverständnis könnte dazu führen, dass:

Bestehende Rechtsinstrumente wie CLOUD Act und FISA noch intensiver genutzt werden, um Daten ausländischer Unternehmen, Behörden und deren Klienten oder Partnern einzusehen.
Unternehmen und Behörden, deren Daten in US-Clouds liegen, unmittelbar und ohne Vorwarnung betroffen wären.

4. Folgen für deutsche Unternehmen und Behörden

Für deutsche Unternehmen und Behörden, die besonderen gesetzlichen Geheimhaltungspflichten unterliegen, ist die Nutzung von Entra ID und Microsoft 365 mit erheblichen rechtlichen, wirtschaftlichen und reputativen Risiken verbunden:

Verstoß gegen EU-Datenschutzvorgaben (DSGVO):
Europäische Gerichte (insbesondere der EuGH) sehen den CLOUD Act und FISA als nicht kompatibel mit europäischem Datenschutz an.
Reputationsverlust und Kundenvertrauen:
Sollte bekannt werden, dass sensible Daten – z.B. Mandantendaten, Gesundheitsinformationen, Forschungsergebnisse – indirekt an US-Behörden gelangen, droht massiver Vertrauensverlust und wirtschaftlicher Schaden.
Rechtliche Konsequenzen:
Bußgelder der Datenschutzaufsicht sowie Klagen von betroffenen Kunden oder Partnern könnten folgen.

5. Warum Microsoft 365 Deutschland keine echte Souveränität bietet

Die 2016 gestartete „Microsoft Cloud Deutschland“ versprach ursprünglich echte Datenhoheit durch Betrieb durch T-Systems als Treuhänder. Microsoft selbst hatte keinerlei direkten Zugriff auf diese Daten. Diese Version wurde jedoch 2020 eingestellt.

Die neue Lösung („EU Data Boundary“) verspricht zwar eine Datenhaltung innerhalb der EU. Aber technisch und organisatorisch bleibt Microsoft alleiniger Betreiber der Infrastruktur. US-Behörden können weiterhin auf Grundlage des CLOUD Act und FISA Zugriff auf diese Daten verlangen.

Kurzum:
Die EU Data Boundary bietet lediglich eine vertragliche, keine technische Souveränität und keinen Schutz vor Zugriffen durch US-Behörden.

6. Empfehlungen für deutsche Unternehmen und Behörden

Um rechtlich und technisch sicher zu agieren, sollten Unternehmen und Behörden folgende Maßnahmen umsetzen:

Nutzung souveräner europäischer Clouds:
Alternativen wie IONOS Cloud, T-Systems Sovereign Cloud, Open Telekom Cloud, etc. Lösungen bieten echte Unabhängigkeit und europäische Kontrolle.
Zero-Trust-Architekturen:
Trennung von Authentifizierung (z.B. Entra ID als reiner Login-Provider) und Datenhaltung (getrennte Systeme mit Ende-zu-Ende-Verschlüsselung).
Customer Managed Encryption Keys:
Lokale Schlüsselverwaltung bei Verwendung US-amerikanischer Dienste reduziert Risiken und steigert Kontrolle.
Rechtliche und organisatorische Maßnahmen:
Verbindliche Prozesse zur Klassifizierung sensibler Daten und Auditierung der Cloud-Infrastrukturen.

Fazit und Handlungsaufforderung

Cloud-Dienste wie Microsoft Entra ID und Microsoft 365 bieten große Chancen, stellen aber gerade für Unternehmen und Behörden mit besonderen Geheimhaltungspflichten ein erhebliches Risiko dar. Angesichts der geltenden US-Gesetze und der ungewissen politischen Entwicklung in den USA sollten europäische Unternehmen und öffentliche Einrichtungen genau abwägen, welche Daten sie auf US-gehosteten Plattformen speichern.

Es gilt, technische, organisatorische und rechtliche Maßnahmen zu ergreifen, um sich effektiv zu schützen und die eigene Souveränität nachhaltig sicherzustellen.

Die Wahl der richtigen Infrastruktur ist dabei nicht nur eine technische Frage, sondern eine Entscheidung über Souveränität, Compliance und Vertrauen.

Support-Bots: Warum generative KI nie den Durchbruch schaffen wird, den wir uns erhoffen

Die Idee eines KI-gestützten Support-Bots ist faszinierend: Kundenanfragen schnell und effizient beantworten, rund um die Uhr erreichbar sein und gleichzeitig Kosten sparen. Doch wie viel Automatisierung ist wirklich möglich, ohne Sicherheitsrisiken einzugehen? Ein zentraler Punkt in dieser Diskussion ist die Frage nach den Rechten und Kompetenzen eines solchen Bots.

Der Kern des Problems: Rechte und Eskalation

Menschliche Supportmitarbeiter verfügen oft über erweiterte Rechte, um Aufgaben zu erledigen, die ein Kunde selbst nicht durchführen kann: Verträge anpassen, Gutschriften freigeben oder technische Probleme lösen. Ein Support-Bot müsste, um wirklich nützlich zu sein, ähnliche Befugnisse erhalten. Doch genau hier liegt die Herausforderung:

Missbrauchspotenzial: Generative Modelle wie ChatGPT können durch sogenannte „Prompt Injection“ manipuliert werden. Geschickte Eingaben könnten dazu führen, dass der Bot unautorisierte Aktionen ausführt.
Technische Grenzen: Selbst mit robusten Sicherheitsmechanismen gibt es keine absolute Garantie, dass ein KI-Modell nicht ausgetrickst wird. Das Risiko einer ungewollten Rechte-Eskalation bleibt bestehen.
Verantwortung und Haftung: Im Gegensatz zu einem Menschen kann ein Bot keine Verantwortung übernehmen. Fehler könnten weitreichende Konsequenzen haben, ohne dass jemand direkt zur Rechenschaft gezogen werden kann.

Eine neue Lösung: Zwei Bots und der Mensch als letzte Instanz

Ein vielversprechender Ansatz könnte darin bestehen, die Aufgaben des Bots in zwei Phasen zu teilen:

Erfassung durch den ersten Bot: Der Nutzer interagiert mit einem generativen Modell, das alle Parameter zur Lösung des Problems in natürlicher Sprache erfasst. Dieser Bot erstellt ein vollständiges Support-Ticket mit allen relevanten Informationen, um Missverständnisse zu minimieren.
Bearbeitung durch den zweiten Bot: Ein zweiter, hochspezialisierter Bot verarbeitet das Ticket und leitet die notwendigen Tätigkeiten ab. Wichtig: Dieser zweite Bot ist nicht direkt für den Nutzer zugänglich – idealerweise weiß der Nutzer nicht einmal, dass er existiert. Damit wird das Risiko von Manipulation deutlich reduziert.
Eingriff des Menschen bei riskanten Aufgaben: Alle Aktionen, die potenziell riskant oder hochsicherheitsrelevant sind, müssen von einem menschlichen Supporter freigegeben werden. So bleibt die Kontrolle in kritischen Momenten erhalten, während der Bot einfache Aufgaben eigenständig bearbeitet.

Authentifizierung und Nachvollziehbarkeit als Muss

Ein weiterer zentraler Punkt ist die Authentifizierung der Nutzer. Jeder, der mit dem Bot interagiert, sollte eindeutig identifiziert werden, um Missbrauch vorzubeugen. Falls jemand versucht, durch Prompt Injection den Bot zu manipulieren, muss aus dem Chatverlauf klar hervorgehen, wer diesen Angriff durchgeführt hat. Nur so kann man Angreifer zur Rechenschaft ziehen und die Sicherheit des Systems langfristig gewährleisten.

Warum der Nutzen eingeschränkt bleibt

Selbst mit ausgeklügelten Mechanismen bleibt ein generativer Support-Bot in seiner Nützlichkeit begrenzt, wenn er keine erweiterten Rechte hat. Die Balance zwischen Sicherheit und Effizienz wird zum entscheidenden Dilemma:

Ohne erweiterte Rechte: Der Bot kann keine komplexen Probleme lösen, die über die Möglichkeiten des Kunden hinausgehen. Dies reduziert den Mehrwert erheblich.
Mit erweiterten Rechten: Das Risiko von Sicherheitsvorfällen steigt erheblich, da generative Modelle durch gezielte Manipulationen missbraucht werden können.

Lösungsansätze und Ausblick

Wie kann ein Unternehmen diesen Konflikt lösen? Hier sind einige Ansätze:

Granulare Rechtevergabe: Der Bot könnte für bestimmte Aktionen erweiterte Rechte erhalten, während kritische Prozesse immer einer menschlichen Verifikation bedürfen. Dies erfordert jedoch eine komplexe Rollenverwaltung.
Transparente Audit-Trails: Jede Aktion des Bots wird protokolliert und könnte im Nachhinein überprüft werden. Dies bietet retrospektive Sicherheit, löst jedoch nicht das akute Risiko.
Hybride Modelle: Der Bot übernimmt einfache Anfragen vollständig und leitet komplexere Fälle an den menschlichen Support weiter. Dies sorgt für Sicherheit, setzt aber klare Prozesse voraus.
Erweiterte Ticket-Erfassung: Durch den ersten Bot werden Support-Tickets erstellt, die alle Parameter enthalten. Der zweite Bot oder ein Mensch bearbeitet diese Tickets gezielt und effizient.
Klare Kommunikation: Unternehmen müssen Kunden und Mitarbeitenden transparent machen, welche Aufgaben der Bot übernimmt und wo die Grenzen liegen. Vertrauen ist hier ein entscheidender Faktor.

Fazit: Der Mensch bleibt unverzichtbar

Ein KI-Support-Bot kann eine wertvolle Ergänzung sein, aber er wird den menschlichen Support nicht vollständig ersetzen. Die Kombination aus generativer KI und menschlichem Fachwissen bleibt der effizienteste und sicherste Weg. Letztlich geht es nicht darum, den Menschen überflüssig zu machen, sondern ihn durch intelligente Automatisierung zu unterstützen.

Was denkst du? Würdest du einem Bot mit erweiterten Rechten vertrauen, oder siehst du den Menschen weiterhin als unersetzlich im Support?

Googles Quantenchip „Willow“ und die Grenzen der Quantenmechanik: Was bedeutet das für KI und Sicherheit?

Google hat kürzlich seinen neuen Quantenchip „Willow“ vorgestellt, der mit 105 supraleitenden Qubits eine beeindruckende Leistungsfähigkeit zeigt. Berechnungen, die selbst die schnellsten klassischen Computer Milliarden von Jahren bräuchten, werden in nur fünf Minuten erledigt. Besonders bemerkenswert: Willow demonstriert eine innovative Quantenfehlerkorrektur, bei der zusätzliche Qubits die Fehler nicht erhöhen, sondern sie exponentiell reduzieren. Das ist ein entscheidender Schritt auf dem Weg zu skalierbaren Quantencomputern.

Solche Durchbrüche sind beeindruckend, doch sie rufen auch die Debatten aus der frühen Quantenmechanik wieder ins Gedächtnis. Die Auseinandersetzung zwischen Werner Heisenberg und Albert Einstein über die Grundlagen der Quantenwelt hat nicht nur die Physik geprägt, sondern zeigt uns, warum Quantencomputer keine „schnelleren Computer“ sind, sondern etwas völlig anderes.

Heisenberg vs. Einstein: Der philosophische Konflikt

Werner Heisenberg erkannte mit seiner Unschärferelation, dass Ort und Impuls eines Teilchens niemals gleichzeitig exakt bestimmbar sind. Dies war mehr als nur eine technische Einschränkung – es stellte das klassische, deterministische Weltbild auf den Kopf. Die Quantenwelt ist probabilistisch: Ereignisse passieren nicht mit Sicherheit, sondern mit bestimmten Wahrscheinlichkeiten.

Albert Einstein konnte diese Vorstellung nicht akzeptieren. Für ihn bleibt die Quantenmechanik eine Übergangstheorie, welche die Welt zwar sinnvoll beschreibt, aber unvollständig ist. Sein berühmtes Zitat „Gott würfelt nicht“ fasst seine Überzeugung zusammen, dass die Welt letztlich durch klar definierte Regeln gesteuert wird, auch wenn wir sie noch nicht vollständig verstehen. Besonders kritisch sah er die „spukhafte Fernwirkung“ der Quantenmechanik, bei der Teilchen scheinbar ohne direkten Kontakt miteinander interagieren. Diese Verschränkung ist heute einer der Grundpfeiler von Quantencomputern.

Einsteins Zweifel sind auch heute noch relevant – vor allem, wenn wir versuchen, die praktischen Konsequenzen der Quantenmechanik zu begreifen. Googles Fortschritte mit Willow basieren auf den Prinzipien, die Heisenberg beschrieben hat, und zeigen, wie weit diese Ideen mittlerweile in die Technologie vorgedrungen sind.

Warum Quantencomputer keine schnelleren Computer sind

Quantencomputer arbeiten nicht wie klassische Computer. Sie nutzen drei zentrale Prinzipien der Quantenmechanik:

Superposition: Ein Qubit kann sich gleichzeitig in mehreren Zuständen befinden (0 und 1). Das erlaubt es, viele Berechnungen parallel durchzuführen.
Verschränkung: Qubits können miteinander „verbunden“ sein, sodass der Zustand eines Qubits den eines anderen beeinflusst, unabhängig von der Entfernung.
Unschärferelation: Die inhärente Unvorhersehbarkeit in der Quantenwelt wird gezielt genutzt, um komplexe Probleme zu lösen.

Diese Prinzipien machen Quantencomputer für spezifische Aufgaben extrem effizient, wie etwa die Simulation von Molekülen oder die Optimierung komplexer Systeme. Für Alltagsanwendungen wie Textverarbeitung oder einfache Datenanalysen sind sie jedoch weder schneller noch besser geeignet. Sie sind keine bessere Version eines klassischen Computers – sie sind etwas völlig anderes.

Warum RSA gefährdet ist

Ein Bereich, in dem Quantencomputer weitreichende Konsequenzen haben könnten, ist die Kryptografie. Verfahren wie RSA basieren darauf, dass es extrem schwierig ist, große Zahlen in ihre Primfaktoren zu zerlegen. Mit klassischen Computern dauert das so lange, dass es praktisch unmöglich ist. Ein Quantenalgorithmus wie Shor’s Algorithmus hingegen könnte diese Aufgabe in realistischer Zeit bewältigen.

Die Bedrohung ist real: Viele der aktuellen Verschlüsselungsmethoden wären in einer Welt mit leistungsfähigen Quantencomputern nicht mehr sicher. Google’s Willow zeigt, dass diese Zukunft schneller kommt, als viele erwartet haben. Unternehmen und Regierungen müssen sich dringend mit quantensicheren Alternativen auseinandersetzen.

Quantensichere Kryptografie: Lösungen für eine neue Ära

Eine vielversprechende Alternative ist die gitterbasierte Kryptografie. Sie basiert auf mathematischen Gittern, also regelmäßigen Anordnungen von Punkten im mehrdimensionalen Raum. Die Sicherheit dieser Verfahren liegt in der Schwierigkeit, bestimmte Probleme in diesen Gittern zu lösen, etwa:

Shortest Vector Problem (SVP): Den kürzesten Vektor in einem Gitter zu finden, ist selbst für Quantencomputer extrem aufwendig.
Learning With Errors (LWE): Ein gestörtes Gleichungssystem zu lösen, bleibt auch mit Quantenalgorithmen unlösbar.

Ein bekanntes Verfahren aus diesem Bereich ist Kyber, ein Schlüsselkapselungsverfahren, das von der NIST als Standard für die Post-Quanten-Kryptografie ausgewählt wurde. Gitterbasierte Verfahren ermöglichen nicht nur sichere Kommunikation, sondern auch spannende Anwendungen wie vollständig homomorphe Verschlüsselung. Damit könnten Berechnungen direkt auf verschlüsselten Daten durchgeführt werden, ohne diese jemals zu entschlüsseln.

Warum Quantencomputer KI (noch) nicht revolutionieren

Trotz ihres Potenzials haben Quantencomputer derzeit wenig direkten Einfluss auf generative KI. Die Gründe dafür sind einfach:

Optimierte Hardware: KI-Modelle wie GPT laufen auf GPUs und TPUs, die speziell für neuronale Netze entwickelt wurden. Diese Hardware ist effizienter als Quantencomputer für diese Aufgaben.
Spezialisierung von Quantencomputern: Quantencomputer sind extrem leistungsfähig für spezifische Probleme wie Optimierung oder Simulation. KI erfordert jedoch allgemeinere Rechenleistung.
Fehlende Algorithmen: Es gibt bisher keine Algorithmen, die die Prinzipien der Quantenmechanik direkt für maschinelles Lernen nutzen.

Das bedeutet nicht, dass Quantencomputer für KI irrelevant bleiben. Doch aktuell gibt es keinen direkten Einfluss auf die Fortschritte in der generativen KI. Klassische Systeme dominieren diesen Bereich weiterhin.

Fazit: Zwei Technologien, zwei Welten

Googles Fortschritte mit Willow zeigen, dass Quantencomputer unser Verständnis von Berechnung und Sicherheit grundlegend verändern werden. Doch ihre Auswirkungen sind spezifisch und konzentrieren sich auf Bereiche wie Kryptografie und Simulation. Für KI, insbesondere generative Modelle, bleiben klassische Systeme der Standard.

Quantencomputer sind keine besseren klassischen Computer – sie sind eine völlig andere Technologie. Sie zwingen uns, unsere Annahmen über Rechenleistung, Sicherheit und sogar die Natur der Realität zu überdenken. In dieser Hinsicht erinnern sie an die fundamentalen Fragen, die Einstein und Heisenberg einst beschäftigten. Was bleibt, ist die Herausforderung, diese neue Technologie verantwortungsvoll und klug zu nutzen, bevor sie die Grenzen dessen verschiebt, was wir heute für sicher und beherrschbar halten.

Ich hoffe, ich konnte euch die Auswirkungen verständlich und einfach beschreiben. Wer sich bezüglich Quantencomputer und Verschlüsselung weiter informieren möchte, empfehle ich die Videos von Veritasium zu diesem Thema:

Leaked-Api Keys mit Abusix und Proxmox verhindern

Wenn du einen DNSBL-Dienst wie Abusix in deinem Proxmox Mail Gateway nutzt, kann es passieren, dass Spammer den API-Key durch direkte DNS-Anfragen auslesen. Um dies zu verhindern, kannst du PowerDNS verwenden, um die DNSBL-Abfragen zu anonymisieren und gleichzeitig sicherzustellen, dass dein Mail Gateway weiterhin korrekte Antworten erhält.

Problemstellung

Proxmox Mail Gateway fragt DNSBL-Dienste wie Abusix direkt ab. Dabei enthält die Anfrage oft einen API-Key (z. B. 1234abcd.abusix.zone). Falls ein Spammer versucht, diese Anfrage direkt nachzuvollziehen, wird der API-Key möglicherweise geleaked.

Lösung

Durch PowerDNS und ein Lua-Skript kannst du Anfragen an DNSBL-Dienste wie *.abusix. anonymisieren. Das Skript leitet alle Anfragen mit der Domain-Endung .abusix. automatisch auf die API-Key-Domain (z. B. <API-KEY>.combined.mail.abusix.zone.) um. Der Spammer sieht nur, dass er auf einer Blacklist steht, ohne jemals den API-Key zu sehen.

Voraussetzungen

PowerDNS Recursor ist installiert.
Lua-Skripting ist aktiviert.

Schritt 1: Lua-Skript erstellen

Speichere folgendes Skript in /etc/powerdns/resolve.lua:

function preresolve(dq)
    -- Alte und neue Domain-Endungen
    local old_suffix = ".abusix."
    local new_suffix = ".<API-KEY>.combined.mail.abusix.zone."

    -- Den angefragten Domainnamen holen und prüfen
    local qname = dq.qname:toString()

    -- Prüfe, ob die Domain mit der alten Endung endet
    if qname:sub(-#old_suffix) == old_suffix then
        -- Alte Endung durch die neue ersetzen
        local new_domain = string.sub(qname, 1, -string.len(old_suffix) - 1) .. new_suffix

        -- Debug-Log (optional)
        pdnslog("Rewriting domain: " .. qname .. " -> " .. new_domain, pdns.loglevels.Info)

        -- CNAME hinzufügen und Weiterverfolgung aktivieren
        dq:addAnswer(pdns.CNAME, new_domain)
        dq.rcode = 0
        dq.followupFunction = "followCNAMERecords"

        return true  -- Anfrage wurde verarbeitet
    end

    return false  -- Anfrage wird normal weitergeleitet
end

Dieses Skript ersetzt alle Anfragen an .abusix. durch die API-Key-Domain <API-KEY>.combined.mail.abusix.zone. und stellt sicher, dass nur dein Mail Gateway korrekte DNSBL-Antworten erhält.

Schritt 2: PowerDNS konfigurieren

Bearbeite die Datei recursor.conf und füge Folgendes hinzu:

lua-dns-script=/etc/powerdns/resolve.lua

Speichere die Datei und starte den Recursor neu:

bashCode kopierensudo systemctl restart pdns-recursor

Schritt 3: Konfiguration im Proxmox Mail Gateway

Öffne die DNSBL-Einstellungen in deinem Proxmox Mail Gateway.
Trage als DNSBL-Domain nur noch abusix ein, ohne API-Key:Code kopieren
abusix

Durch das Lua-Skript werden alle Anfragen an .abusix. automatisch umgeleitet. Der API-Key bleibt sicher verborgen.

Schritt 4: Funktion prüfen

Teste mit dig, ob die Umleitung funktioniert:

dig @127.0.0.1 1.2.3.4.abusix.

Wenn alles korrekt eingerichtet ist, sollte PowerDNS die Anfrage umleiten. In den Logs kannst du sehen, wie die Domain umgeschrieben wird:

sudo journalctl -u pdns-recursor

Beispielausgabe:

Rewriting domain: 1.2.3.4.abusix. -> 1.2.3.4.<API-KEY>.combined.mail.abusix.zone.

Warum diese Lösung?

API-Key-Schutz: Dein API-Key bleibt geheim, selbst wenn Spammer versuchen, ihn durch DNS-Abfragen zu ermitteln.
Proxmox bleibt funktional: Das Mail Gateway erhält weiterhin die korrekten DNSBL-Antworten.
Flexible Erweiterung: Du kannst das Skript anpassen, um weitere Dienste oder Endungen zu anonymisieren.

Zusammenfassung

Mit PowerDNS und Lua kannst du sensible API-Keys vor unbefugten Zugriffen schützen. Dieses Skript sorgt dafür, dass DNSBL-Anfragen dynamisch umgeleitet werden, ohne dass dein Mail Gateway beeinträchtigt wird. Eine elegante Lösung für ein häufiges Sicherheitsproblem.

Diversität in IT-Systemen als Antwort auf Single Points of Failure: Eine Lektion aus dem CrowdStrike-Vorfall

Ein kürzliches fehlerhaftes Update von CrowdStrike, einem führenden Anbieter von Sicherheitssoftware, führte zu globalen Störungen. Dieses Update verursachte Bluescreens bei vielen Windows-Systemen und beeinträchtigte kritische Infrastrukturen wie Flughäfen, Krankenhäuser und Apotheken. Dieses Ereignis verdeutlicht die Risiken von Single Points of Failure in IT-Systemen.

Risiken einer homogenen IT-Landschaft

Die Abhängigkeit von einer einzigen Technologie oder Plattform erhöht die Anfälligkeit für Ausfälle. Ein Fehler, ein Update oder ein Sicherheitsvorfall kann weitreichende Konsequenzen haben, wenn alle Systeme auf dieselbe Technologie setzen. Diese Homogenität schwächt die Resilienz und erhöht das Risiko signifikanter Störungen.

Theoretisches Beispiel: IT-Strategien im Vergleich

Unternehmen A setzt ausschließlich auf VMware als Hypervisor, nutzt eine einzige Backup-Technik und verlässt sich für die IT-Sicherheit auf ein einziges Produkt, wie CrowdStrike. Diese Strategie kann kurzfristig Kostenvorteile und eine vereinfachte Verwaltung bieten. Jedoch erhöht sie das Risiko eines Ausfalls und macht das Unternehmen anfällig für technische Probleme und Preisschwankungen.

Unternehmen B verteilt seine Anwendungen auf verschiedene Hypervisoren wie VMware, Hyper-V und KVM, verwendet unterschiedliche Backup-Technologien und integriert Sicherheitsprodukte verschiedener Anbieter. Diese Diversifizierung reduziert das Risiko eines Totalausfalls und erhöht die Flexibilität bei Ausfällen einzelner Komponenten. Sie schützt auch vor finanziellen Abhängigkeiten von einzelnen Anbietern.

Finanzielle Abhängigkeit und Verhandlungsmacht

Unternehmen, die stark auf eine Schlüsselsoftware angewiesen sind, verlieren ihre Verhandlungsmacht und werden anfällig für Preisänderungen und Lizenzanpassungen. Die tiefe Integration solcher Software in die Unternehmensprozesse macht einen Wechsel kostspielig und aufwändig, was zu einer prekären finanziellen Lage führen kann.

Technische Diversität und Sicherheit

Technische Diversität bedeutet die Nutzung verschiedener Betriebssysteme, Cloud-Plattformen und Softwarelösungen. Beispielsweise können verschiedene Datenbanktechnologien wie Oracle und MongoDB eingesetzt werden, um die Resilienz gegen spezifische Sicherheitslücken oder Leistungsprobleme zu erhöhen. Eine diversifizierte IT-Infrastruktur schafft mehrere Verteidigungslinien und Redundanzen, die die Sicherheit und Stabilität verbessern.

Geografische Diversifizierung von Cloud-Diensten

Anstatt sich auf ein Rechenzentrum an einem einzigen Standort zu verlassen, können Daten und Anwendungen über mehrere Regionen und Anbieter verteilt werden. Dies schützt vor technischen Ausfällen, regionalen Katastrophen und politischen Risiken.

Globale Abhängigkeiten und Risiken

Die Abhängigkeit von wenigen Anbietern wie Microsoft oder Google birgt Risiken. Politische Entscheidungen, rechtliche Veränderungen oder wirtschaftliche Sanktionen können die Verfügbarkeit dieser Dienste beeinträchtigen. Unternehmen, die auf eine diversifizierte Anbieterlandschaft setzen, sind besser gegen solche Unwägbarkeiten geschützt.

Ein Beispiel sind Handelsstreitigkeiten und Sanktionen, die die Verfügbarkeit bestimmter Technologien einschränken können. Unternehmen, die ausschließlich auf amerikanische Software und Cloud-Dienste setzen, könnten von solchen Maßnahmen stark betroffen sein. Eine diversifizierte IT-Strategie, die auch Anbieter aus anderen Regionen einbezieht, kann diese Risiken mindern.

Paradigmenwechsel: Förderung der Diversität in IT-Systemen

Es ist entscheidend, IT-Infrastrukturen zu überprüfen, Single Points of Failure zu identifizieren und Strategien zur Risikominimierung zu entwickeln. Ein Paradigmenwechsel hin zu mehr Diversität kann die Sicherheit, Stabilität und Innovationskraft digitaler Umgebungen stärken.

Technologische Vielfalt ist notwendig, um die Zukunftsfähigkeit und Resilienz digitaler Infrastrukturen zu gewährleisten. Ein proaktiver Ansatz kann Ausfälle verhindern und die Wettbewerbsfähigkeit eines Unternehmens steigern. Aus Fehlern lernen und widerstandsfähige Systeme entwickeln ist der Schlüssel, um kritische Infrastrukturen auch in Krisenzeiten funktionstüchtig zu halten. Diversität in IT-Systemen bietet nicht nur Schutz vor technischen Ausfällen, sondern auch strategische Vorteile in einer global vernetzten Welt.