Datenschutz & Sicherheit
Vorratsdatenspeicherung deutlich länger als drei Monate
Nachdem das Bundesjustizministerium Ende Dezember seine Pläne zu einer verpflichtenden Vorratsdatenspeicherung von Telekommunikationsdaten wie IP-Adressen, Portnummern und weiteren Informationen zur Internetnutzung öffentlich gemacht hatte, beteiligte sich eine ganze Reihe von Verbänden und Organisationen mit Stellungnahmen zum Referentenentwurf. Das Ministerium stellte vergangene Woche insgesamt 26 Stellungnahmen zu dem Entwurf online.
Der Entwurf soll Internetdiensteanbieter zu einer umfänglichen anlasslosen IP-Adressen-Vorratsdatenspeicherung sowie zu verschiedenen weiteren Speichervorgaben verpflichten. Mit einer „Sicherungsanordnung“ sollen Ermittler künftig verdachtsabhängig, aber ohne eine richterliche Einbindung Internetdiensteanbieter zwingen dürfen, Verkehrs- sowie Standortdaten aufzuheben.
Vorgesehen für die anlasslose IP-Adressen-Bevorratung ist eine dreimonatige Speicherfrist. Ob diese monatelange Frist dem Urteil des Europäischen Gerichtshofs aus dem Jahr 2024 genügt, ist strittig. Denn darin schrieb das hohe Gericht das Kriterium fest, den Zeitraum „auf das absolut Notwendige“ zu begrenzen. Allerdings führen die heutigen technischen Gegebenheiten dazu, dass es praktisch auf eine deutlich längere Speicherdauer von vielen Monaten oder gar Jahren hinausläuft. Das begründen die großen Netzbetreiber und Internetdiensteanbieter in ihren Stellungnahmen an das Ministerium.
Das Justizministerium führt eine Reihe ganz unterschiedlicher Straftaten auf, mit der sie das Vorhaben begründet. Etwa bei „der Kommunikation von Tatverdächtigen über Messengerdienste, der Verbreitung von Kinderpornographie, bei kriminellen Handelsplattformen, die Betäubungsmittel oder Cybercrime-as-a-Service anbieten, sowie bei echt wirkenden Onlineshops, die Waren verkaufen, die gar nicht existieren“, könnte eine Speicherung aller IP-Adressen nützlich sein.
Doch um einen solch weitreichenden Vorschlag wie die massenhafte Speicherung der IP-Adressen zu rechtfertigen, braucht es etwas mehr als nur einige Beispiele. Deswegen zweifeln Stellungnahmen von Juristenverbänden und Digital-NGOs bereits die Erforderlichkeit der riesigen verdachtslosen Datensammlung an.
Lange Speicherzeiten nicht mit EuGH-Urteil zu vereinbaren
Die gemeinsame Stellungnahme der großen Mobilfunknetzbetreiber Telefónica, Telekom, Vodafone und 1&1 weist auf technische Umstände hin, die sie als „datenschutzrechtlich kritisch“ erachten. Sie betreffen die vorgesehene Speicherdauer der zwangweise festzuhaltenden Datensätze für drei Monate. Die Netzbetreiber weisen darauf hin, dass der Referentenentwurf diese Speicherung „mit Beginn der Zuweisung und Löschung nach drei Monaten ab dem Zeitpunkt des Endes der Zuweisung“ vorsieht.
Diese „Zuweisung“ bezieht sich auf die vergebene IP-Adresse mit weiteren Begleitdaten, die einem Nutzeranschluss zugeordnet ist und künftig für alle Anschlüsse gespeichert werden soll. Die Netzbetreiber merken an, dass diese Regelung „zu einer Datenspeicherung deutlich über drei Monate hinaus“ führe. Das „verletzt somit die Vorgaben des EuGH“.
Denn der Europäische Gerichtshof hatte 2024 über eine IP-Adressenspeicherung entschieden, die zur Verfolgung von Urheberverwertungsrechtsverletzungen in Frankreich verwendet wird. Der Gerichtshof schrieb in dem Urteil vor, dass „die Dauer der Speicherung auf das absolut notwendige Maß beschränkt sein“ muss und keine detaillierten Profile der Nutzer erstellt werden dürfen.
Vorratsdatenspeicherung
Wir berichten seit zwanzig Jahren über die politischen Vorhaben rund um die Vorratsdatenspeicherung. Unterstütze unsere Arbeit!
Die Netzbetreiber machen ganz praktisch klar, warum die geplante Regelung die eigentlich vorgesehene dreimonatige Speicherdauer ganz erheblich verlängert: „In vielen Netzen, insbesondere bei modernen Glasfaseranschlüssen, gibt es keine Zwangstrennung mehr.“ Zwar gäbe es „selten“ Verbindungstrennungen, etwa wegen Wartungsarbeiten, aber „Verbindungszeiten von mehreren Wochen und Monaten sind die Regel“. Bestünde die Verbindung „beispielsweise über zehn Monate, führt dies zu einer Speicherdauer von insgesamt 13 Monaten bei der bislang im Gesetzestext formulierten Speicherzeit“.
Unzweifelhaft wären solch lange Speicherzeiten mit dem EuGH-Urteil nicht zu vereinbaren. Das sieht auch der Verband der Anbieter von Telekommunikations- und Mehrwertdiensten (VATM) in seiner Stellungnahme kritisch. Es bestünde die Gefahr, „dass Daten faktisch deutlich länger als die avisierte Speicherfrist von drei Monaten“ vorgehalten werden müssen. Das würde „die Vorgaben des EuGH überschreiten und damit unionsrechtswidrig“ sein.
In Bezug auf die fehlende Zwangstrennung rechnet auch der VATM vor, dass die „Verbindungszeiten mehrere Monate betragen“. Das stelle inzwischen „die Regel dar“. Eine Zuordnung einer IP-Adresse zu einem Endkunden sei durch die vorgesehene Regelung „nicht nur für drei Monate möglich, sondern faktisch für die gesetzliche Speicherfrist zuzüglich der Dauer der Session“. Die hier gemeinte „Session“ beginnt mit der Zuweisung der IP-Adresse zum Nutzer.
Keine „empirischen Grundlagen“ für dreimonatige Speicherfrist
Doch schon die eigentlich geplanten drei Monate Speicherpflicht sind weiterhin mit nichts begründet. Darauf weist die Bundesrechtsanwaltskammer (BRAK), die Interessenvertretung von rund 166.000 Rechtsanwältinnen und Rechtsanwälten in Deutschland. Es fehle an „empirischen Grundlagen“ für diese Frist.
Der Hinweis in der Begründung des Entwurfes auf „Praxiserfahrung“ verdeutliche, dass es sich nur um eine „unspezifizierte Erwartungshaltung“ handele. Warum eine Frist von vier Wochen nicht ebenso ausreichen könne, sei „nicht ersichtlich“, so die BRAK in ihrer Stellungnahme. Sie verweist auf die Aussage der BKA-Vizepräsidentin Martina Link in einer Bundestagsanhörung im Rechtsausschuss im Oktober 2023. Sie hatte aus Sicht der Ermittler aus der Praxis berichtet.
Link warf in der Anhörung selbst die Frage auf, wie lange Speicherfristen bemessen sein müssten, damit das BKA ihm vorliegende IP-Adressen noch einem Nutzer zuordnen könnte. Sie bezog sich auf Fälle des NCMEC (Nationales Zentrum für vermisste und ausgebeutete Kinder), einer US-Organisation, die das BKA in großer Zahl auf kinder- und jugendpornographische Inhalte hinweist. Link erklärte, eine „Speicherverpflichtung von 2 bis 3 Wochen“ wäre „schon ein signifikanter Gewinn“.
Referentenentwurf ohne Begründung der Erforderlichkeit
Neben der Kritik an der Länge der Speicherung verweist die BRAK auch in aller Deutlichkeit auf die Frage, womit der Gesetzgeber eine Vorratsdatenspeicherung eigentlich begründet:
Die Einführung neuer Ermittlungsmethoden, die einen Grundrechtseingriff darstellen, bedarf zunächst der Erforderlichkeit der Maßnahme. Im vorliegenden Entwurf fehlen jedwede Ausführungen hierzu, die jedoch im Hinblick darauf, dass nun seit de facto über 18 Jahren in Deutschland keine Vorratsdatenspeicherung durchgeführt wurde, sich förmlich aufdrängen.
Im Referentenentwurf der Vorgängerregierung hatte das Bundesjustizministerium sich eine solche Blöße nicht gegeben, sondern aus „empirischer Sicht“ erklärt, dass „trotz fehlender Vorratsdatenspeicherung in einer Vielzahl von Verfahren Verkehrsdaten erhoben werden können“. Für das Vorjahr war es damals gelungen, „auch ohne Anwendung der Vorschriften der Vorratsdatenspeicherung […] 90,8 Prozent der bekannt gewordenen Fälle der Verbreitung kinderpornographischer Inhalte“ aufzuklären, zitiert die BRAK das Ministerium.
Bei den Juristen bleiben „erhebliche Zweifel an der Erforderlichkeit“ der Vorratsdatenspeicherung. Insgesamt sieht die BRAK den Entwurf „mit erheblicher Skepsis“.
Datenschutz & Sicherheit
Fortinet stopft 18 Sicherheitslecks | heise online
Fortinet bezeichnet es nicht so, hat aber einen Patchday im April veranstaltet: Das Unternehmen veröffentlicht 18 Sicherheitswarnungen zu diversen Produkten gebündelt an einem Tag. Einige davon stuft Fortinet als kritisches Risiko ein.
Weiterlesen nach der Anzeige
Eine unzureichende Filterung von Elementen, die in einem Befehl ans Betriebssystem von FortiSandbox verwendet werden, ermöglicht Angreifern ohne Authentifizierung das Ausführen von nicht autorisiertem Code oder Befehlen mittels manipulierter HTTP-Anfragen (CVE-2026-39808, CVSS 9.1, Risiko „kritisch“). Zudem können bösartige Akteure an einer Path-Traversal-Schwachstelle in der JRPC-API von FortiSandbox ansetzen, um mit sorgsam präparierten HTTP-Anfragen die Authentifizierung zu umgehen (CVE-2026-39813, CVSS 9.1, Risiko „kritisch“). Betroffen sind die FortiSandbox-Versionszweige 4.4 und 5.0, die Fassungen 4.4.9 sowie 5.0.6 oder neuere bessern die Schwachstelle aus.
Fortinet: Auch hochriskante Sicherheitslücken entdeckt
In FortiDDoS-F 7.2.1 und 7.2.2 können angemeldete Angreifer eine SQL-Injection-Schwachstelle zum Einschleusen beliebiger SQL-Befehle mit manipulierten HTTP-Anfragen missbrauchen (CVE-2026-39815, CVSS 7.9, Risiko „hoch“). Version 7.2.3 und neuer korrigieren das. Angreifer aus dem Netz können außerdem ohne vorherige Authentifizierung mit speziell präparierten Anfragen im oftpd-Daemon von FortiAnalyzer Cloud und FortiManager Cloud 7.6 einen Heap-basierten Pufferüberlauf provozieren und in dessen Folge Schadcode oder beliebige Befehle einschleusen (CVE-2026-22828, CVSS 7.3, Risiko „hoch“). Die Version 7.6.5 oder neuere bessern das aus.
FortiClient EMS filtert bestimmte Elemente, die in SQL-Befehlen genutzt werden, unzureichend und reißt damit eine SQL-Injection-Lücke auf. Das können authentifizierte Angreifer zum Absetzen beliebiger SQL-Abfragen mit manipulierten Anfragen missbrauchen (CVE-2026-39809, CVSS 7.1, Risiko „hoch“). FortiClient EMS 7.0 muss zum Schließen der Lücke auf unterstützte Softwarestände migriert werden, die Fassungen 7.2.13 sowie 7.4.6 und neuere stopfen das Leck.
Fortinet hat noch zahlreiche weitere Sicherheitslücken in mehreren Produkten geschlossen. Deren Risiko stuft das Unternehmen jedoch als mittel oder niedrig ein. Admins mit Fortinet-Produkten in ihrer Umgebung sollten prüfen, ob sie verwundbare Softwarestände einsetzen, und die bereitstehenden Updates anwenden.
Die Fortinet-Patchsammlung im März versorgte ebenfalls 18 Sicherheitslücken mit Softwareflicken. Der höchste Schweregrad war da jedoch das Risiko „hoch“.
Weiterlesen nach der Anzeige
(dmk)
Datenschutz & Sicherheit
Überwachung weltweit: Bundesregierung winkt UN-Cybercrime-Konvention durch
Die Entscheidung im Bundeskabinett fiel am Mittwoch ohne großes Aufsehen, doch die Tragweite für den Datenschutz und die globale Menschenrechtslage ist groß. Die Bundesregierung hat offiziell grünes Licht für die Unterzeichnung des seit Jahren umstrittenen Übereinkommens der Vereinten Nationen gegen Computerkriminalität gegeben. Damit bekennt sich Deutschland zu einem Regelwerk, das die internationale Zusammenarbeit bei der Bekämpfung von IT-Straftaten auf eine neue Ebene heben soll.
Weiterlesen nach der Anzeige
Im Kern geht es Berlin um einen verbesserten Austausch von Beweismitteln in elektronischer Form (E-Evidence), um bei schweren Straftaten schneller und grenzüberschreitend agieren zu können. Doch was technisch sinnvoll klingt, betrachten zivilgesellschaftliche Organisationen als sicherheitspolitisches trojanisches Pferd.
Schon im Oktober, bei der Unterzeichnung in der vietnamesischen Hauptstadt Hanoi, schlugen Bürgerrechtsorganisationen Alarm. Ihre Sorge gilt dem ersten globalen Abkommen dieser Art, das unter dem Kürzel UNCC (United Nations Convention against Cybercrime) firmiert. Sie sehen darin weniger ein Instrument für mehr Cybersicherheit als einen rechtlichen Rahmen, der grenzüberschreitende Menschenrechtsverletzungen durch Kooperationspflichten begünstigt. Die Staatengemeinschaft betont die Notwendigkeit, der organisierten Kriminalität im Netz Herr zu werden. Die NGOs verlangen indes ein Ende des Ratifizierungsprozesses oder zumindest Nachbesserungen, um elementare Grundrechte zu wahren.
Zwischen Diplomatie und Datenschutz-Sorgen
Das Bundesjustizministerium verteidigt das Mitziehen. Ein Sprecher sagte heise online, dass Deutschland gemeinsam mit der EU und anderen gleich gesinnten Staaten nachdrücklich für die Gewährleistung von Menschenrechtsstandards und entsprechenden Schutzgarantien gekämpft habe. Es seien „entsprechende Mechanismen vorgesehen, um diese bei der Strafverfolgung und der internationalen Zusammenarbeit zu gewährleisten“. Insbesondere gebe es im Rahmen der Kooperation spezifische Zurückweisungsgründe, falls Standards nicht eingehalten werden. Die Bundesregierung bleibe diesem menschenrechtlichen Ansatz auch künftig verpflichtet.
Dennoch richtet sich die Kritik vor allem gegen den fast uferlosen Geltungsbereich der UN-Konvention. Sie beschränkt sich nicht auf klassische Cyberangriffe wie das Knacken von Datenbanken oder das Lahmlegen kritischer Infrastrukturen. Stattdessen verpflichtet sie die Teilnehmer zu einer umfassenden elektronischen Überwachung und zur Kooperation bei einer Vielzahl von Delikten, die oft keinen direkten Bezug zu Informationssystemen haben. Als schwere Straftat wird jedes Delikt eingestuft, das nach jeweiligem nationalem Recht mit mindestens vier Jahren Freiheitsentzug geahndet werden kann.
Ein Erbe von Russland und China
Weiterlesen nach der Anzeige
Diese vage Definition öffnet die Tür für Missbrauch. Was in einer Demokratie als legitimer Protest oder investigativer Journalismus gilt, kann in autoritären Regimen als schwere Straftat ausgelegt werden. Aktivisten befürchten, dass die Konvention zur Kriminalisierung von Regierungskritikern und Whistleblowern umgedeutet wird. Da das Abkommen Regierungen dazu auffordert, ohne ausreichende Schutzmechanismen digitale Beweise zu sammeln und diese mit ausländischen Behörden zu teilen, droht das Vertrauen in sichere Kommunikation untergraben zu werden. Die Kritiker warnen auch vor einer Kriminalisierung schutzbedürftiger Gruppen in repressiven Staaten.
Der Vertrag geht auf eine Initiative von Russland und China zurück. Dass ihn nun auch westliche Staaten unterstützen, empfinden Bürgerrechtler als fatale Weichenstellung. Das Justizressort verweist dagegen auf den formalen Charakter der aktuellen Entscheidung: Es handele sich „um einen üblichen vorbereitenden Schritt für die Unterzeichnung eines internationalen Abkommens“. Die eigentliche Ratifizierung werde später erfolgen.
(cku)
Datenschutz & Sicherheit
OpenSSL 4.0 verschlüsselt, was TLS bisher verraten hat
OpenSSL 4.0.0 ist erschienen und bringt tiefgreifende Änderungen an der weitverbreiteten Kryptobibliothek. Das Open-Source-Projekt entfernt veraltete Protokolle wie SSLv2 und SSLv3, schafft das Engine-Konzept ab, führt neue Datenschutzfunktionen im TLS-Handshake ein und erweitert die Bibliothek in Richtung Post-Quantum-Kryptografie. Gleichzeitig bereinigen die Entwickler die API und verschärfen sicherheitsrelevante Prüfungen.
Weiterlesen nach der Anzeige
OpenSSL gehört zu den zentralen TLS/SSL-Implementierungen und steckt in Webservern, Betriebssystemen, Netzwerkgeräten und unzähligen Anwendungen. Änderungen an der Bibliothek wirken sich unmittelbar auf die Absicherung von Netzwerkverbindungen, Zertifikatsprüfungen und kryptografische Operationen in großen Teilen der IT-Infrastruktur aus.
Neue Kryptografie: ECH, Post-Quantum und mehr
Zu den wichtigsten Neuerungen gehört die Unterstützung für Encrypted Client Hello (ECH) nach RFC 9849. ECH verschlüsselt Teile des TLS-Handshake – insbesondere die Server Name Indication (SNI). Bislang konnten Dritte wie Netzbetreiber anhand der SNI erkennen, welche Domain ein Client ansteuert. ECH verbirgt diese Information und verbessert so den Datenschutz auf Transportebene deutlich.
Neu sind außerdem hybride Schlüsselaustauschverfahren wie curveSM2MLKEM768. Sie kombinieren klassische elliptische Kurven mit Post-Quantum-Algorithmen und sollen Verbindungen schon heute gegen künftige Angriffe durch Quantencomputer absichern: Selbst wenn ein Angreifer eines der beiden Verfahren bricht, schützt das andere weiterhin die Verbindung.
Die Bibliothek ergänzt mehrere kryptografische Primitive und Standards. Dazu zählt die cSHAKE-Funktion nach SP 800-185 – eine flexiblere Variante von SHA-3, die domänenspezifische Hash-Berechnungen erlaubt. Hinzu kommen Unterstützung für den Signaturalgorithmus ML-DSA-MU sowie SM2/SM3 nach RFC 8998, die unter anderem in regulatorischen Kontexten eine Rolle spielen. Zudem führt OpenSSL 4.0.0 Key-Derivation-Funktionen (KDFs) für SNMP und das Secure Real-time Transport Protocol (SRTP) ein, die in Netzwerkmanagement- und VoIP-Szenarien zum Einsatz kommen. Für TLS 1.2 unterstützt OpenSSL nun außerdem standardisierte Finite-Field-Diffie-Hellman-Gruppen (FFDHE) gemäß RFC 7919. Das verbessert die Interoperabilität und vermeidet unsichere oder proprietäre Parameterwahl beim Schlüsselaustausch.
Strengere Validierung und FIPS-Anpassungen
Die Zertifikatsvalidierung wird an mehreren Stellen strenger. Im Strict-Modus prüft OpenSSL nun zusätzlich die Authority Key Identifier (AKID), und auch die CRL-Prüfung erhält weitere Checks. Im FIPS-Modus erzwingt die Bibliothek jetzt Mindestanforderungen bei PBKDF2 – etwa bei der Zahl der Iterationen –, um schwache Konfigurationen zu unterbinden.
Weiterlesen nach der Anzeige
Neu ist außerdem die Möglichkeit, FIPS-Selbsttests verzögert auszuführen. Das ist vor allem in containerisierten Umgebungen nützlich.
Entfernte Protokolle, APIs und Altlasten
Mit Version 4.0 räumt OpenSSL konsequent auf. Neben SSLv2 und SSLv3 fällt auch das Engine-Konzept weg. Hardwarebeschleunigung und externe Kryptomodule laufen künftig ausschließlich über die Provider-Architektur, die Engines bereits seit OpenSSL 3.0 ablöst. Ebenfalls entfernt: feste TLS-Versionsmethoden, ältere elliptische Kurven, diverse Low-Level-Funktionen und das Skript c_rehash. Stattdessen sollen Nutzer openssl rehash verwenden.
Bei der API gibt es mehrere Änderungen, die Anpassungen im Anwendungscode erfordern können. Zahlreiche Funktionssignaturen tragen jetzt const-Qualifier, der Datentyp ASN1_STRING ist nun vollständig gekapselt – Zugriff auf seine internen Felder ist nur noch über Zugriffsfunktionen möglich. Auch die Ausgabe von Hex-Dumps wurde standardisiert: Signaturen werden in 24-Byte-Blöcken dargestellt, alle anderen Daten in 16-Byte-Blöcken. Das soll die Lesbarkeit verbessern und die Ausgabe konsistenter machen. Und veraltete Funktionen zur Zeitprüfung von Zertifikaten weichen der neuen Funktion X509_check_certificate_times(). Auch beim Laufzeitverhalten gibt es Änderungen: OpenSSL verzichtet künftig auf automatisches Aufräumen globaler Daten über atexit() und setzt stärker auf Standardfunktionen der C-Laufzeitbibliothek, etwa bei snprintf.
Für Entwickler und Betreiber bedeutet das Release mehr Sicherheit und modernere Kryptografie – bei gleichzeitig erhöhtem Migrationsaufwand. Anwendungen, die direkt auf OpenSSL-APIs zugreifen oder ältere Funktionen nutzen, müssen angepasst werden. OpenSSL 4.0 legt damit die Grundlage für den Übergang zu post-quantenresistenten Verfahren und besseren Datenschutz im TLS-Handshake. Details zum neuen Release finden sich auf der zugehörigen GitHub-Projektseite.
Lesen Sie auch
(fo)
-
Künstliche Intelligenzvor 2 Monaten
Top 10: Die beste kabellose Überwachungskamera im Test – Akku, WLAN, LTE & Solar
-
Social Mediavor 1 MonatCommunity Management und Zielgruppen-Analyse: Die besten Insights aus Blog und Podcast
-
Social Mediavor 2 MonatenCommunity Management zwischen Reichweite und Verantwortung
-
UX/UI & Webdesignvor 3 MonatenEindrucksvolle neue Identity für White Ribbon › PAGE online
-
Entwicklung & Codevor 1 MonatCommunity-Protest erfolgreich: Galera bleibt Open Source in MariaDB
-
Künstliche Intelligenzvor 3 MonatenInterview: Massiver Anstieg der AU‑Fälle nicht durch die Telefon‑AU erklärbar
-
Künstliche Intelligenzvor 2 MonatenSmartphone‑Teleaufsätze im Praxistest: Was die Technik kann – und was nicht
-
Entwicklung & Codevor 3 MonatenKommentar: Entwickler, wacht auf – oder verliert euren Job
