Das anonymisierende Linux Tails ist in Version 7.8.1 erschienen. Die Entwickler schließen darin Sicherheitslücken, die Angriffe gegen die Anonymisierung ermöglichen könnten.

Laut der Versionsankündigung zu Tails 7.8.1 handelt es sich um ein Notfall-Update. Es schließt ernste Sicherheitslücken im Linux-Kernel und Schwachstellen im Tor-Client, erklären die Maintainer. Der Debian-Linux-Kernel kommt nun in Version 6.12.90-2 mit, er korrigiert demnach die Schwachstelle CVE-2026-43503 (CVSS 8.8, Risiko „hoch“). Laut dem Ubuntu-Security-Team gehört die Lücke zu „Fragnesia“, mit einem weiteren CVE-Eintrag (das „Original“ wurde Mitte Mai mit CVE-2026-46300 bekannt). Apps in Tails könnten sich durch die Lücke Administratorrechte verschaffen.

Außerdem schließt das Update mehrere Sicherheitslücken im Tor-Client. Version 0.4.9.9 bessert Schwachstellen aus, die etwa das Umgehen von Prüfungen auf sogenannte „Kompressionsbomben“ (etwa als ZIP-Bomb bekannt) ermöglichen oder Speicherzugriffe außerhalb vorgesehener Speicherbereiche. Die Release-Notizen liefern weitere Details.

Angriffe denkbar – von potenten Akteuren

Angriffe seien eher unwahrscheinlich, könnten jedoch von „starken Angreifern“ wie staatlichen Akteuren oder „Hacking-Firmen“ ausgeführt werden. Wenn diese eine andere, bislang unbekannte Sicherheitslücke in Tails missbrauchen, können sie die volle Kontrolle über Tails übernehmen und User deanonymisieren. Solche Angriffe auf die Schwachstelle seien bislang in der Praxis jedoch noch nicht bekannt geworden, fügen die Tails-Macher hinzu.

Tails 7.8.1 steht als USB-Image zum Verfrachten auf USB-Sticks zum Herunterladen bereit. Außerdem gibt es ein ISO-Image etwa zum Brennen auf DVD oder zur Nutzung in einer VM.

Mit Tails auf USB-Stick lassen sich etwa fremde Rechner mit einer vertrauenswürdigen Umgebung starten. Interessierte können damit dann anonym im Netz agieren, ohne unnötige Spuren zu hinterlassen. Mit Tails lassen sich beispielsweise auch Zensurmaßnahmen umgehen.

Tails 7.8 erschien vor gerade einmal zwei Wochen. Darin war die auffälligste Änderung, dass der Mail-Client Thunderbird als Zusatzsoftware installiert wird, damit er stets auf aktuellem Stand ist.

(dmk)

Let’s Encrypt hat erstmals einen konkreten Fahrplan für quantensichere Zertifikate vorgelegt. Die Zertifizierungsstelle will dafür auf sogenannte Merkle Tree Certificates (MTCs) setzen, statt bestehende X.509-Zertifikate einfach mit größeren Post-Quantum-Signaturen zu versehen. Eine Testumgebung soll Ende 2026 starten, ein produktionsreifes Angebot 2027 folgen. Neu ist weniger das Bekenntnis zur Post-Quantum-Kryptografie als die Festlegung auf einen bestimmten technischen Weg.

Let’s Encrypt zählt zu den weltweit wichtigsten Zertifizierungsstellen für automatisiert ausgestellte TLS-Zertifikate. Die Debatte um quantensichere Kryptografie läuft seit Jahren, drehte sich bislang aber vor allem um den Schlüsselaustausch. Dahinter steht die Sorge, dass Angreifer verschlüsselten Datenverkehr heute mitschneiden und später mit Quantencomputern entschlüsseln könnten. Die Absicherung von Zertifikaten und Signaturen galt lange als weniger dringlich, weil ein Angreifer dafür schon während der laufenden Kommunikation einen leistungsfähigen Quantencomputer bräuchte. Mit den inzwischen vom US-Standardisierungsinstitut NIST verabschiedeten Verfahren und den Migrationsplänen von Google und Cloudflare rückt nun auch die Authentifizierung in den Vordergrund.

Festlegung mit Signalwirkung

Künftig sollen Merkle Tree Certificates der bevorzugte Weg sein, um das Web-PKI quantensicher zu machen. An den nötigen Standards arbeitet Let’s Encrypt bereits in der IETF-Arbeitsgruppe PLANTS mit – die Ausstellung der MTCs wird zudem über eine ACME-Erweiterung abgewickelt. Die Entscheidung wiegt schwer, denn mit Hunderten Millionen aktiven Zertifikaten prägt die Organisation die technische Entwicklung der Web-PKI maßgeblich.

Dabei steht Let’s Encrypt nicht allein. Cloudflare und Chrome testen MTCs bereits in einem Feldversuch gegen echten Internet-Traffic, und Chrome hat den Ansatz zu seinem bevorzugten Weg für quantensichere Zertifikate im öffentlichen Web erklärt.

Hinter der Wahl steckt ein handfestes Problem quantensicherer Signaturen: Sie brauchen deutlich mehr Platz als heutige Verfahren. Let’s Encrypt verweist auf ML-DSA-44, einen der NIST-Standards. Dessen Signaturen sind mit rund 2.420 Bytes etwa 38-mal größer als die heute verbreiteten ECDSA-P256-Signaturen (64 Bytes). Würde man Zertifikate und Zertifikatsketten unverändert auf solche Verfahren umstellen, würden einzelne TLS-Handshakes auf über 10 Kilobyte anschwellen. Das würde Verbindungen verlangsamen und in manchen Netzen sogar die Fehlerrate erhöhen.

Wie Merkle Tree Certificates funktionieren

Merkle Tree Certificates gehen deshalb einen anderen Weg: Statt jedes Zertifikat einzeln zu signieren, fasst die Zertifizierungsstelle viele Zertifikate in einem Merkle-Baum zusammen. Signiert wird nicht jedes einzelne Zertifikat, sondern nur die Wurzel des Baums. Clients erhalten anschließend einen kompakten Nachweis darüber, dass ein bestimmtes Zertifikat zu diesem Baum gehört.

Das Prinzip kennen viele Administratoren aus anderen Bereichen – etwa Git-Repositories, Certificate-Transparency-Logs oder Blockchains. Einzelne Objekte werden dort nicht jeweils separat abgesichert, sondern über einen Baum auf einen gemeinsamen kryptografischen Anker zurückgeführt.

Kleinere Handshakes trotz größerer Signaturen

Nach Angaben von Let’s Encrypt schrumpfen die Authentifizierungsdaten im TLS-Handshake dadurch deutlich. Browser sollen dafür regelmäßig sogenannte Landmarks aktualisieren, die als Referenzpunkte für die Prüfung dienen. Im Regelfall genügt dann eine Signatur, ein öffentlicher Schlüssel und ein Merkle-Nachweis. So lässt sich der zusätzliche Ballast quantensicherer Signaturen weitgehend vermeiden.

Auch die Certificate Transparency profitiert von dem Ansatz. Heute stellt eine Zertifizierungsstelle ein Zertifikat zunächst aus und veröffentlicht es danach in separaten Transparenzprotokollen. Bei MTCs gehört die Transparenz dagegen zum Zertifikatsmodell selbst: Weil jedes Zertifikat Teil eines veröffentlichten Merkle-Baums ist, kann es gar nicht erst außerhalb dieser Struktur existieren. Ausstellung und Protokollierung rücken damit zusammen.

Bekannte Technik, lange Übergangsphase

Neuland ist die Technik für Let’s Encrypt nicht. Die Organisation betreibt seit 2019 eigene Certificate-Transparency-Logs, die ebenfalls auf Merkle-Bäumen basieren. Mit dem Betrieb solcher Strukturen im großen Maßstab hat sie also bereits Erfahrung.

Für Nutzer ändert sich vorerst nichts. Bestehende Zertifikate stellt Let’s Encrypt weiterhin wie gewohnt aus und verlängert sie automatisch. Die Umstellung hängt zudem von mehreren Faktoren ab: Neben der Standardisierung durch die IETF müssen Browser, Kryptobibliotheken, ACME-Clients und die Root-Programme der Browserhersteller die neuen Verfahren unterstützen.

Beim Schlüsselaustausch drängt die Zeit

Bei der Authentifizierung lässt sich die Umstellung also noch in Ruhe vorbereiten – beim Schlüsselaustausch drängt Let’s Encrypt dagegen zur Eile. Hier greift das Szenario „heute mitschneiden, später entschlüsseln“ (auch „harvest now, decrypt later“ genannt), weshalb jede Verbindung ohne quantensicheren Schlüsselaustausch ein Risiko darstellt.

Server-Betreibern rät Let’s Encrypt deshalb, hybriden Post-Quantum-Schlüsselaustausch (X25519MLKEM768) zu aktivieren. Große Browser und Betriebssysteme unterstützen das Verfahren bereits; es auf dem Server einzuschalten, sei eine der wirkungsvollsten Maßnahmen, die man in diesem Jahr ergreifen könne.

Festlegung auf einen Migrationspfad

Die Ankündigung markiert damit weniger den Start quantensicherer Zertifikate als die Festlegung auf einen konkreten Migrationspfad. Setzt sich MTC durch, dürfte das eine der größten strukturellen Änderungen der Web-PKI seit Certificate Transparency und dem ACME-Protokoll werden. Die Details hat Let’s Encrypt in einem Blogeintrag zur Post-Quantum-Zukunft veröffentlicht.

(fo)

„Über Geld spricht man nicht“ heißt es hierzulande gerne. Außer mit dem Finanzamt natürlich. In der Steuerverwaltung landen Informationen über Einkünfte, in der Sozialverwaltung landen Informationen über Phasen von Arbeitslosigkeit oder Wohngeld-Auszahlungen, in der Gesundheitsverwaltung landen Informationen über Krankheitsverläufe. Sensible Informationen, die viel über unser Leben verraten.

Und was macht die öffentliche Verwaltung damit? Sie schiebt die Daten zunehmend in die Cloud. Die gehört meistens Microsoft, Google, Amazon oder Oracle. Ob direkt oder über einen Subunternehmer – Verwaltungen greifen meist auf Dienste US-amerikanischer Cloud-Anbieter zurück.

Sind die Daten in einer solchen Public Cloud sicher? Und sollten Behörden in Sachen digitale öffentliche Infrastruktur auf US-Big-Tech setzen? Diese Fragen sind drängender geworden, seitdem bekannt wurde, welchen Einfluss US-Präsident Donald Trump hier ausübt und ausüben kann.

Die „geopolitische Lage“ heißt Trump

Diese „geopolitische Lage“ sei dringlich, so die Vizepräsidentin und EU-Kommissarin Henna Virkkunen bei der gestrigen Pressekonferenz zum neuen Tech Sovereignty Package. Es umfasst den Chips Act 2.0, die Open-Source-Strategie der EU und den Fahrplan für Digitalisierung und KI im Energiesektor.

Welchen Zugriff die US-Regierung künftig auf europäische öffentliche Informationen haben kann, will die Kommission mithilfe des Cloud and AI Development Acts (CADA) regulieren; das vierte Element im Packet. Doch gerade CADA scheint ein sehr zaghaftes Instrument der EU für mehr Unabhängigkeit von US-Big-Tech zu werden. Denn für einen großen Teil staatlicher Daten schließt die Kommission US-Cloud-Anbieter nicht vom europäischen Markt aus.

Nach ihrer Rechnung könnten gut 99 Prozent, mindestens aber 70 Prozent, staatlicher Daten der EU-Mitgliedsländer auf Clouds von US-Anbietern landen. Diese Zahlen beruhen auf einer Schätzung der Kommission zur Risikobewertung staatlicher Daten. EU-Mitgliedstaaten sollen nach einem vorgegebenen Stufensystem die Risiken bei der Beschaffung von Cloud-Diensten prüfen.

Zugriff auf Daten durch US-Regierung

Auf der anderen Seite des Atlantiks stehen dem Pakt Gesetze wie der Foreign Intelligence Surveillance Act (FISA), der Patriot Act und der CLOUD Act (Clarifying Lawful Overseas Use of Data Act) gegenüber. Laut CLOUD Act sind Tech-Unternehmen mit Sitz in den USA wie Microsoft oder Google dazu verpflichtet, unter bestimmten Voraussetzungen Daten gegenüber US-Behörden offenzulegen.

Dazu zählen auch Daten aus der EU. Das ist unabhängig davon, ob die Daten eines US-Unternehmens auf einem Rechenzentrum innerhalb der EU gespeichert sind, so ein juristisches Gutachten der Universität Köln im Auftrag des Bundesinnenministeriums. Bestätigt hat das aber auch der Chefjustiziar von Microsoft Frankreich, Anton Carniaux. Vor gut einem Jahr erklärte er dem französischen Senat: Wenn französische Behörden Microsoft nutzen, kann die US-Regierung diese Daten einsehen. Dafür müssen die Behörden nicht einmal ausdrücklich zugestimmt haben.

Trump kann sogar öffentliche Angestellte und Beamt:innen daran hindern, ihrer Arbeit nachzugehen. Das zeigen die Fälle von Richter:innen und einem Chefankläger am Internationalen Strafgerichtshof. Trump veranlasste, dass sie Dienste von Microsoft, Paypal und Co. nicht mehr nutzen können; auch auf ihre Accounts und darin enthaltene Daten können sie nicht mehr zugreifen.

Womit hält die EU dagegen?

Anhand von vier Sicherheitsstufen, den sogenannten „Union Assurance Levels“, sollen EU-Mitgliedstaaten nun die Cloud-Dienste auf den Prüfstand stellen, die sie nutzen: Welches Risiko wäre gegeben, wenn Daten an Nicht-EU-Staaten abfließen? Oder wenn ein Dienst ausfallen würde? Für diese Risikobewertung sollen die Länder ein Jahr Zeit haben, dann müssen sie ihre Ergebnisse veröffentlichen.

Demnach müssen Cloud-Anbieter für ihre Dienste je nach Stufe bestimmte Kriterien erfüllen. Stufe 1 benötigt ein niedriges Maß an Souveränität, Stufe 4 ein hohes. Bei Daten, die weniger sensibel sind, reiche die Sicherheitsstufe 1 aus. Demnach müssten Behörden lediglich sicherstellen, diese Daten in europäischen Rechenzentren zu speichern statt in beispielsweise US-amerikanischen. Öffentliche Auftraggeber in den EU-Mitgliedstaaten sollen nur Cloud-Dienste beschaffen, die mindestens Stufe 1 erfüllen. Hier ändert sich für die großen Cloud-Anbieter aus den USA wie Amazon und Google nichts. Denn sie haben die dazu erforderlichen Niederlassungen in der EU und betreiben hier bereits eigene Rechenzentren.

Auch mit der zweiten Sicherheitsstufe würde sich für sie nichts ändern, das erklärte ein hochrangiger EU-Beamter. Die Kommission hat dabei das Risiko eines Kill Switch im Blick. Damit ist gemeint, dass Betreiber aus der Ferne das IT-System abschalten könnten. Der jeweilige Cloud-Anbieter muss bei Stufe 2 ausschließen, dass Nicht-EU-Länder wie die USA oder China den Kill Switch umlegen könnten.

Cloud-Anbieter aus den USA ausschließen?

Stufe 3 soll erfordern, dass sich Cloud-Anbieter innerhalb der EU befinden und von dort aus kontrolliert werden. Daneben sollen sie Mitarbeitende mit europäischer Staatsangehörigkeit beschäftigen. Einflussnahme durch Drittstaaten soll damit reduziert werden. Virkkunen erklärte auf der Pressekonferenz, dass es US-Cloud-Anbieter schwer haben würden, Stufe 3 zu erreichen.

Doch es gibt ein Schlupfloch: Nach Artikel 18 hat die Kommission die Möglichkeit „von den Anforderungen auf Stufe 3 abzuweichen und Drittstaaten für Cloud-Anbieter anzuerkennen“, so Denis-Kenji Kipker Research Director und Gründer des Frankfurter Cyberintelligence Institute gegenüber netzpolitik.org. Dazu dienen sogenannte Angemessenheitsbeschlüsse im Gesetz. Solche Beschlüsse beim Thema Datenschutz haben in der Vergangenheit gezeigt, dass die Kommission die USA trotz erheblicher Bedenken als vertrauenswürdigen Partner ansieht.

Die höchste Stufe soll nicht nur besonders für sicherheitssensible Bereiche gelten, sondern biete laut Kommission auch maximale Souveränität: EU-Länder sollen ihren gesamten Technologie-Stack von der Hardware bis zur Software vollständig kontrollieren. Das würde Nicht-EU-Anbieter ausschließen. Demnach dürften Cloud-Anbieter in dieser Stufe keiner Einflussnahme aus einem Drittland unterliegen.

Mitgliedstaaten entscheiden

Es bleibe „den Mitgliedstaaten vorbehalten“, wie sie bewerten, was „souveränitäts- und sicherheitskritisch“ ist. Die Kommission gibt also nicht vor, wie die EU-Länder das Stufensystem umsetzen sollen. Sie empfiehlt etwa die Bereiche Justiz, Polizei und Grenzschutz der Stufe 2 zuzuordnen. Das kritisiert die Grünenpolitikerin Alexandra Geese. „Wer akzeptiert, dass eine außereuropäische Regierung im Ernstfall Einfluss auf den Betrieb kritischer digitaler Infrastrukturen von Justiz, Polizei, nationale Sicherheit und Grenzschutz nehmen oder deren Verfügbarkeit gefährden kann, schafft institutionalisierte Abhängigkeit.“

Der Stufe 4 ordnet die Kommission den Bereich Verteidigung zu. Das würde nur etwa ein Prozent staatlicher Daten betreffen. Der Großteil von 70 Prozent sei weniger schutzbedürftig und falle damit unter Stufe 1, während 20 Prozent unter Stufe 2 und neun Prozent unter Stufe 3 fielen.

Inwieweit EU-Länder jedoch US-Cloud-Anbieter meiden und wie „das Ergebnis der Bewertung und Einordnung des Sicherheitsniveaus“ ausfällt, hänge wesentlich von ihrem „Risiko-Sicherheitskontext“ ab, so Kipker. Die Kommission spricht hier kein Vergabeverbot aus. Die Länder entschieden also selbst, ob „in einem besonders sensiblen Anwendungsfall die Wahl eines hohen Sicherheitsniveaus einen außereuropäischen Anbieter faktisch ausschließt“.

Die Kommission gibt auch nicht vor, wie die EU-Länder ihre Behörden von einem Cloud-Anbieter wie Amazon oder Microsoft zu einem europäischen Anbieter migrieren. Immerhin hätte CADA nach Inkrafttreten „unmittelbare Geltung und Anwendungsvorrang, und die Kommission könnte Verstöße über das Vertragsverletzungsverfahren nach AEUV durchsetzen“, erklärt Kipker.

Das Gesetzespaket geht nun an das europäische Parlament und die Mitgliedstaaten. Gerade von letzteren hängt ab, ob sich die Cloud-Landschaft für die Behördenarbeit in der EU tatsächlich verändert.