In der letzten Episode des Risikozone-Podcasts habe ich ganz kurz das Thema der verkürzten Hashwerte und auftretenden Kollisionen angesprochen. Jetzt gibt es ein Proof of Concept zu der Thematik.

Worum es geht

Ein kurzer Refresher, worum es in der Thematik überhaupt geht: Als Git entwickelt wurde, musste ein Weg gefunden werden, wie man die Referenzen auf Commits, die Dateien und die Dateibäume realisiert. In vielen Systemen wie z. B. Issue-Trackern werden aufsteigende Indizes verwendet. In einem verteilten System wie Git ist das aus verschiedenen Gründen der Synchronisation nicht so einfach möglich, da sonst Kollisionen, also gleiche IDs für unterschiedliche Objekte entstehen könnten. Eine Alternative wäre UUIDs, da die IDs einen randomisierten Anteil haben und die Wahrscheinlichkeit für Kollisionen gesenkt wird.

Noch besser als UUIDs ist allerdings Content-adressable Storage, bei dem Inhalte einzig durch ihren Inhalt adressiert werden. Das ist so, als würde man den gesamten Inhalt der Datei nochmal in den Dateinamen schreiben. Der Clou dabei ist jedoch, dass der gesamten Dateiinhalt gar nicht in den Dateinamen geschrieben werden muss, um die Datei durch ihren Inhalt identifizierbar zu machen.

Mit kryptographischen Hashfunktionen wie SHA-1 oder SHA-256 existiert ein Mittel, um einen beliebig langen Dateiinhalt zu einem immer gleich langen Wert, dem Hash, umzuwandeln. Dabei sind kryptographische Hashfunktionen so konstruiert, dass die Wahrscheinlichkeit für Kollisionen durch verschiedene Mechanismen stark minimiert wird. Ein SHA-1-Hash für den Dateiinhalt "Hallo Welt" wäre z. B. 28cbbc72d6a52617a7abbfff6756d04bbad0106a. Ein netter Nebeneffekt ist, dass Dateien mit gleichem Inhalt im Content-adressable Storage auch nur einmal abgespeichert werden, wodurch sogar Deduplikation ermöglicht wird.

Git nutzt dieses Verfahren, um die eingechekten Dateien abzuspeichern. Diese Dateien werden dann in Trees zusammengebunden und in Commits mit den jeweiligen Vorgänger-Commits (parents) in einem sog. Merkle-Tree verheiratet.

Commits werden somit auch durch einen SHA-1-Hash identifiziert, der im hexadezimalen Format 40 Zeichen lang ist.

Das Problem

Das Problem bei dem Verfahren liegt jetzt darin, dass dieser Hash üblicherweise noch weiter abgekürzt wird, um ihn benutzerfreundlicher in Oberflächen oder E-Mails darzustellen. Damit wird natürlich die Wahrscheinlichkeit für Kollisionen erhöht.

Habe ich einen Hash 28cbbc72d6a52617a7abbfff6756d04bbad0106a und nutze nur 28cbbc zur Referenz, reicht das in den meisten kleinen Repositories aus, um einen Commit eindeutig zu referenzieren. In großen Repositories mit vielen Dateien und Commits kann es auf einmal passieren, dass ein weiterer Commit 28cbbcc00aa8ef4e80596c16ecfdb4bc92656cd3 auftaucht, sodass 28cbbc nicht mehr eindeutig einen Commit beschreibt.

Um das Risiko zu verringern, sollte die Mindestanzahl der Zeichen für einen abgekürzten Commit erhöht werden.

Das Kernel-Repository

Genau darum geht es in der aktuellen Diskussion. Aktuell nutzen die Linux-Entwickler zur Referenz von Commits in ihren E-Mails 12 Zeichen lange Hashes. Die Diskussion dreht sich um die Frage, ob die Zahl weiter erhöht werden sollte. Linus Torvalds ist bisher dagegen, weil er das Risiko für Kollisionen gering sieht und er die Position vertritt, dass ein Commit immer mit dem Commit Message Title angegeben werden sollte, was ungewollte Kollisionen ausreichend verhindere.

Gestern veröffentlichte Kees Cook einen Blogpost, indem er eine Commit-Kollision mit dem Werkzeug lucky-commit bewusst herbeiführte, um darauf aufmerksam zu machen, dass die Git- und Kernel-Entwicklungstools mit solchen Situationen klarkommen sollten. Es ist unwahrscheinlich, dass solche Kollisionen bei 12 Zeichen versehentlich entstehen, aber ein Angreifer könnte dies ausnutzen.

Dies sollte ein Apell an alle Entwickler sein, deren Tooling auf abgekürzte Commit-Hashes setzt. Schauen wir mal, wie sich das weiterentwickelt.

Ein Kommentar zu SHA-1

Abschließend ein Kommentar noch zu SHA-1. Wie viele von euch wissen, ist SHA-1 selbst nicht mehr vertretbar kollisionssicher. Das bedeutet, es kann passieren, dass auf einmal zwei Dateiinhalte sich doch den gleichen Hash teilen könnten, wenn ein Angreifer es drauf anlegt.

Da dies natürlich Git massiv stören könnte, gibt es schon Bestrebungen, das Verfahren auf SHA-2 zu aktualisieren, wodurch sich die Hashlänge auch vergrößert. Das ist aber gar nicht so einfach, da SHA-1 an vielen Stellen in die Struktur eines Git-Repos hartkodiert wurde.

Hier geht es aber nicht um das unsichere SHA-1. Durch die Abkürzung des Hashes von 40 auf 12 Zeichen wird die Kollisionssicherheit bewusst und massiv zugunsten der Benutzerfreundlichkeit geschwächt. Und das erfordert immer eine regelmäßige Evaluation, welches Niveau noch vertretbar ist.

Am heutigen 30. November jährt sich die Veröffentlichung von ChatGPT zum zweiten Mal. Die zwei Jahre fühlen sich wie vier an, wenn man bedenkt, was alles passiert ist. Blicken wir auf einige Entwicklungen zurück.

ChatGPT hat die Forschung im Bereich der künstlichen Intelligenz (KI) auf den Kopf gestellt. KI wurde in der Öffentlichkeit bis 2022 mit verschiedenen Teilbereichen wahrgenommen, z. B. Spamfilterung, Bilderkennung, Texterkennung, Klassifikation von Bildern und Texten oder Vorhersagen. Generative Modelle waren eine Nische und vielen eher durch Anwendung des Deepfakes bekannt, bei denen es darum geht, (bewegte) Bilder so gut wie möglich hochrealistisich zu approximieren und nach Belieben anzupassen.

Veränderte Forschungslandschaft

Mittlerweile könnte man annehmen, dass in der Öffentlichkeit KI, ML und LLM synonym betrachtet werden (was zum Glück nicht so gilt). Über diese Vereinfachung könnte man sich jetzt aufregen, sollte es aber differenziert betrachten. Einerseits lernen viel mehr Menschen KI kennen als vorher. Wenn diese Anwender auch nur eine der Technologien, sei es LLM, einsetzen, ist es gewissermaßen eine Bereicherung. Andererseits versuchen viele, bestehende Verfahren und Technologien auf LLMs anzuwenden. Zum Beispiel kann eine Klassifikation (z. B. Spam oder nicht Spam?) entweder mit einem spezialisierten Modell (z. B. Bayes) durchgeführt werden – oder ChatGPT kann einfach nach der Einordnung gefragt werden. Dieser Einsatz ist kritischer zu hinterfragen, weil Nebeneffekte wie Halluzinationen bisher zuverlässige Aufgaben verwässern: wenn ein Klassifikator mit der Softmax-Funktion zwischen 4 Kategorien entscheiden soll, kann er sich nur für eine Kategorie entscheiden. LLMs hingegeben können mit einer neuen Kategorie antworten.

An dieser Stelle sollte erwähnt werden, was ChatGPT eigentlich ist: Es war, ist und bleibt wohl vorerst eine aufgepumpte Textvervollständigungsmaschine. Dabei können die Modelle zum jetzigen Forschungsstand weder das Gesagte konzeptionalisieren, noch einen inneren Sinn anwenden. Die Modelle wurden darauf trainiert, kohärente Texte für Eingaben auszugeben. So kann eine Anfrage wie "Was ist 2+2?" sicherlich durch Training mit 4 beantwortet werden. Das Modell ist jedoch an sich nicht in der Lage, beliebige Rechenaufgaben mit der Präzision eines Taschenrechners zu beantworten.

Das Spannende ist aber der Zusatz "an sich", den ich der Vollständigkeit halber erwähnen muss. Denn die Forscher und Entwickler haben begonnen, diese Schwäche mit Tricks zu kompensieren. Beim Toolformer-Ansatz wird das LLM darauf optimiert, anstatt einer direkten Antwort einen Funktionsaufruf an der passenden Stelle möglichst syntaktisch korrekt auszugeben, z. B. Das Ergebnis von 2+2 ist [Calculator(2+2)]. Die LLM-Ausgabe kann dann anschließend einem Interpreter übergeben werden, der für vorgegebene Funktionen deterministisch korrekt die Berechnung durchführt und das Ergebnis an der Stelle einfügt.

Es lässt sich erahnen, dass LLMs mittlerweile mehr als das reine Modell sind. Die Ausgaben werden technisch durch gezielte Fragestellung, das Prompt Engineering, in eine bestimmte Richtung gelenkt und anschließend angereichert. Diese Schritte können beliebig oft wiederholt werden. Baut man dieses Verfahren so aus, dass in der Antwort bestimmte Aktionen benannt werden, auf die dann wieder Eingaben folgen, kann man Agenten bauen. Das ist ein jahrzenhntealter Ansatz, der jetzt wieder in Mode kommt.

Dieses Ökosystem ist umfangreich und wächst immer weiter. Nur, weil ich ein Large Language Model habe, habe ich noch kein funktionierenden ChatGPT-Klon. Vielmehr gilt es, operative und technische Herausforderungen im Backend zu lösen (Stichwort GPUs und Clustering) und das Modell in eine Pipeline einzubetten. Das Training allein reicht somit nicht mehr aus – bildet aber auch keine Voraussetzung mehr, wie wir später sehen.

Grundsätzlich ist es gut, wenn mehr Aufmerksamkeit der Erforschung künstlicher Intelligenz und maschinellem Lernen gewidmet wird. Die durch die hohen Trainingskosten notwendig gewordene Kommerzialisierung zur Finanzierung hat allerdings auch umfangreiche Auswirkungen gehabt. Die Start-up-Welt verschob sich nicht nur von Blockchain, Metaversum und Fintech hin zu AI, sondern wurde getrieben vom Ziel, das beste Modell zu trainieren. Rückblickend ein Himmelfahrtskommando, wenn man sieht, wie schnell neue Modelle veröffentlicht wurden und wie gering der Return-on-Invest ausfallen kann.

Das Jahr 2023 fühlte sich an, als würde jedes KI-Labor eines jeden größeren Konzerns die Zwischenergebnisse seiner LLM-Leute veröffentlichen. Jede Woche gab es neue Papers, die nicht mehr in jährlichen begutachteten Konferenzen, sondern als Preprint auf arXiv veröffentlicht wurden. LLMs gibt es schon seit über 5 Jahren, aber die Zuverlässigkeit und verbundene Aufmerksamkeit wurde erst mit dem Durchbruch von InstructGPT ermöglicht, was die Basis von ChatGPT in der ersten Version bildete. In 2023 habe ich aktiv eine LLM-Timeline gepflegt und es wurde deutlich, dass "jeder" es einmal versuchen wollte, Beispiel BloombergGPT. Jeder einzelne Beitrag war dabei wertvoll, es war jedoch schwer, den Überblick zu behalten.

Der Gewinner: Open Source

Der Gewinner der letzten zwei Jahre war jedoch nicht nur OpenAI, das letztes Jahr um diese Zeit mit Machtkämpfen (wired.com) beschäftigt war. Vielmehr hat mit Meta (Facebook) ein Unternehmen das Ruder an sich gerissen, von dem man es am wenigsten erwartet hätte, und einen Beitrag geleistet, den man sich noch weniger hätte vorstellen können. Der zeitlich passende Shift von Metaverse zu AI war die Überraschung der letzten Jahre, wie man auch im Aktienkurs sehen konnte.

Die Problematik war, dass die bereits erwähnte Kommerzialisierung zu proprietären Modellen geführt hat, bei denen weder die Gewichte als Basisdaten veröffentlicht noch die Mitbenutzung erlaubt wurde. Durch das aufwändige Training und die hohe Anpassungsfähigkeit an neue Aufgaben hatte auf einmal das Modell an sich einen Wert. Davor war es entweder die Methodik, wie man ein solches Modell trainiert und einsetzt (das - und nur das - ist im Übrigen in der Regel auch nur wissenschaftlich publikationfähig) oder der Datensatz selber, auf dem trainiert wurde. Das Modell konnte man sich früher einfach selber erzeugen und so die Experimente reproduzieren.

Meta AI war nun einer der ersten großen Anbieter, die mit LLaMA im Februar 2023 ein Modell aufwändig trainiert und dann zum Download freigegeben haben. Das geschah allerdings noch unter einer recht restriktiven Lizenz und mit persönlicher Voranmeldung, war aber eines der ersten Modelle, das an die Leistung von OpenAI im entferntesten herankam. Interessanterweise war es auch die ausbleibende Klagewelle, die zur Verbreitung und Weiterentwicklung der Modelle führte, die rechtlich mindestens in einem Graubereich geschah und fast schon an die Einführung der Kartoffel in Deutschland erinnerte.

Spätere Versionen wie Llama 3 wurden unter freizuzügigeren Lizenzen veröffentlicht. Bei diesen lässt sich streiten, ob man sie als Open Source bezeichnen kann. Fest steht, dass für den Einsatz somit Modelle bereitstehen, an denen man lokal testen und sie ggfs. auf eigene Trainingsdaten anpassen kann. Bei der Bilderkennung wurde hierbei üblicherweise der Begriff Transfer Learning verwendet, bei LLMs wurde das Verfahren als Finetuning bekannt. Somit war auch die Bezeichnung von Foundation Models geboren, die die Basis für Finetuning bilden.

Aus Europa stammt ein zwischenzeitlich ähnlich leistungsstarkes Modell mit dem Namen Mistral, das mit der Apache-2.0-Lizenz auch eine echte, anerkannte Open-Source-Lizenz trägt. Der Trend geht somit Richtung Open Source. Zieht man die Parallele zu den Betriebssystemen mit Windows und Linux, ist es schon sehr überraschend, dass in einer solchen Massentechnologie mit technsichen und finanziellen Hürden tatsächlich so schnell der Gedanke der Open-Source-Kultur keimt.

Gesellschaft und Regulierung

Eine weitere Parallele ist die gesellschaftliche Akzeptanz. Diese ist verglichen mit dem Jahr 2000 überraschend hoch. Während Wikipedia als Konkurrenz zur gedruckten Enzyklopädie zu meiner Schulzeit mindestens verachtet wurde, ist ChatGPT als Alternative zur eigenen Arbeitsleistung überraschend salonfähig. Es gilt vielmehr ein "Es geht nicht weg, wir müssen damit klarkommen!" als ein "Wir müssen es unbedingt bekämpfen!".

Bleibt zum Schluss noch der Blick auf die Regulierung. Die Veröffentlichung von ChatGPT kam in dieser Hinsicht zu einem ungünstigen Zeitpunkt. Die Europäische Kommission hat sich in den vergangenen Jahren vorgenommen, den Einsatz in bestimmten Bereichen der künstlichen Intelligenz im Hinblick auf z. B. Scoring-Systemen für Kredite oder Gesichtserkennung zu regulieren. Also typische Einsatzbereiche, die man sich zu der Zeit vorstellte. Ein erster Gesetzesentwurf wurde Anfang 2021, also ein halbes Jahr vor ChatGPT, vorgelegt. Mit ChatGPT kam dann in dem Gesetzgebungsverfahren so richtig Fahrt auf, sodass einerseits die Gegner von KI-Systemen mit einem großen Verbotshebel in der Verhandlung antraten, die Befürworter die Verordnung nicht aus den Augen verloren und die Investitionsträger von KI-Start-ups ihre wirtschaftliche Position bewahren wollten. Das Ergebnis war, dass Foundation Modelle in die Verordnung aufgenommen wurden, aber ab einer Grenze, die scheinbar ihren geistigen Ursprung interessanterweise in der einer zeitgleich entwickelten Executive Order 14110 des US-Präsidenten Joe Biden hat. Zwischenzeitlich ging es darüber hinaus um die strikte Regulierung jeglicher statistischer Methoden. Dies wurde glücklicherweise aber noch abgeschwächt.

Mittlerweile ist der AI Act von der EU in Kraft. So unnötig ich die Regulierung zu einem solch frühen Zeitpunkt halte, so halte ich die Ausnahme großer Teile der Forschung von der Regulierung als wichtige Errungenschaft. Dass man heute aber für Dinge kämpfen muss, die gestern noch selbstverständlich wären (Forschungsfreiheit), ist auch ein Zeichen gesellschaftlicher Umwälzungen.

Interessanterweise gibt es aber mit der TDM-Schranke auch EU-Voragben, die im in dieser Thematik nicht zu unterschätzenden Urheberrecht dem Training von LLMs zuträglich sein können. Ob und inwiefern diese Schranke für Wissenschaft und Wirtschaft anwendbar ist, wird aktuell durch Gerichtsverfahren und Gutachten geklärt.

Fazit

Ich nutze ChatGPT regelmäßig und sehr gerne und finde daher die Veröffentlichung vor zwei Jahren einen wichtigen Meilenstein, zumal es sehr gut bei Übersetzung oder Grammatikoptimierung hilft (dieser Text ist aber menschengeschrieben). Tatsächlich habe ich knapp ein Jahr vorher schon begonnen, mit GPT-3 zu arbeiten, weil es zu der Zeit schon recht populär war, aber noch viel manuelle Arbeit für gute Ergebnisse erforderte. Mit ChatGPT hat sich die Zugänglichkeit und Qualität von LLMs deutlich vereinfacht, weswegen ich den kometenhaften Aufstieg des Produktes gerechtfertigt sehe.

2023 befand sich allerdings die gesamte Techindustrie regelrecht in einem Wahnzustand. Die anfangs hohen Erwartungen, die in die Werkzeuge gesteckt wurden, konnten teilweise erfüllt werden. Wie hoch die Erwartungen allerdings tatsächlich waren, zeigt sich erst, wenn die Investments realisiert werden.

LLMs sind der Hammer, mit dem jedes Problem wie ein Nagel aussieht. Für die Zukunft wünsche ich mir mehr Differenzierung, da es mehr als LLMs in der KI-Welt gibt. Dabei blicke ich gespannt auf die Robotik, weil sich hier ein weiterer großer Anwendungszweck der KI befindet, der auf seinen Durchbruch wartet. Schauen wir, was uns die nächsten Jahre bringen.

Die letzten wichtigen verbleibenden Bausteine für den Realtime-Support für Linux wurden in den Mainline-Zweig aufgenommen. Das bedeutet, dass Linux 6.12 voraussichtlich in einem echtzeitfähigen Modus betrieben werden kann, wenn der Kernel entsprechend kompiliert wird.

Echtzeitfähigkeit wird insbesondere in Embedded-Szenarien benötigt, wenn auf eine Eingabe innerhalb einer vorhersagbaren Zeit eine Antwort erwartet wird. Speziell in der Robotik, aber auch in der Multimediaproduktion gibt es solche Anforderungen. Dabei kommt es nicht darauf an, dass eine Aufgabe schnell abgearbeitet wird, sondern, dass sie in einer deterministischen Zeit begonnen wird.

Ein Beispiel für Echtzeit

An dieser Stelle mag sich die Frage stellen, was diese Echtzeitfähigkeit, von der hier geredet wird, überhaupt ist. Das lässt sich gut am Beispiel eines Line-following Robot klären. Was ein solcher Roboter tut, kann man sich z. B. in diesem YouTube-Video ansehen. Technisch besteht so ein Roboter aus zwei (oder mehr) Kameras als Sensoren, zwei Motoren für jeweils ein Rad als Aktoren und einem Controller zur Steuerung. Die Kameras sollen den Kontrast ermitteln, damit festgestellt werden kann, ob sie noch auf die schwarze Linie zeigen. Bemerkt eine der Kameras beim Fahren, dass sie den Sichtkontakt zur Linie aufgrund z. B. einer Kurve verliert, müssen die Motoren durch eine leichte Drehung nachsteuern, um auf der Linie zu bleiben.

Diese Kameras lösen üblicherweise entsprechend ihrer Abtastfrequenz auf dem Controller für die Steuerung einen Interrupt aus. Das führt zur Abarbeitung der Steuerungsroutine, die für beide Motoren die Geschwindigkeit berechnet, mit der sie sich drehen sollen.

Entscheidend ist, dass nicht beide Kameras den Sichtkontakt verlieren, damit der Roboter weiterhin weiß, in welche Richtung er nachsteuern muss. Üblicherweise wird das beim Testen funktionieren, aber es kann in bestimmten Randbedingungen bei normalen Betriebssystemen, wenn der Controller z. B. mit vielen anderen Aufgaben zufälligerweise beschäftigt ist, passieren, dass auf einmal nicht schnell genug die Routine aufgerufen wird. Der Roboter verliert dann den Sichtkontakt.

Der Entwickler eines solchen Roboters kann nun eine Echtzeitanforderung formulieren, dass z. B. auf ein Interrupt von den Kameras innerhalb von 1 Millisekunde reagiert werden muss. Er kann mit dieser Anforderung jetzt die maximale Geschwindigkeit des Roboters so wählen, dass der Roboter langsam genug fährt, um nicht die Linie – trotz der Latenz von im worst-case 1 Millisekunde – nicht zu verlieren.

Diese 1 Millisekunde muss aber auch vom Controller, seinem Betriebssystem und schließlich seinem Kernel garantiert werden. Der Kernel muss also in jeder Situation in der Lage sein, auf eine Anforderung innerhalb einer vorbestimmten Zeit zu reagieren. Unabhängig von der zwingenden Fähigkeit, präemptiv zu arbeiten, also jederzeit anderer Prozesse unterbrechen zu können, darf der Kernel auch nicht mit sich selber unvorhersehbar lange beschäftigt sein, wenn z. B. eine Synchronisation hängt.

20 Jahre Arbeit

Und genau hierum geht es beim grob gesagt beim PREEMPT_RT-Patch. Der Kernel muss so nachgebessert werden, dass keine Komponente sich unnötig lange aufhängt und somit die Abarbeitung von Aufgaben behindert, für die eine garantierte Ausführungszeit festgelegt wurde.

Die ursprüngliche Arbeit begann bereits im Jahr 2004 auf einem getrennten Zweig und hatte viele Verbesserungen in den Kernel gebracht, zuletzt an der printk()-Infrastruktur. Jetzt sollten die Arbeiten so weit sein, dass Realtime nicht mehr auf einem getrennten Zweig, sondern im Hauptzweig entwickelt werden kann.

Die Echtzeitfähigkeit gab es somit in speziell präparierten Kernels schon lange. Neu ist, dass der Code im Hauptzweig gepflegt wird und somit besser mit Änderungen anderer Maintainer abgestimmt werden kann. Denn eine Änderung an einer anderen Komponente reicht schon aus, um die Echtzeitfähigkeit zu unterminieren.

Linux echtzeitfähig zu machen, ist somit ein großer Aufwand gewesen, weil man solche Fähigkeiten oft nur in spezialisierten Betriebssystemen (sogenannten Real-time operating systems, RTOS) vorfindet. Insbesondere Thomas Gleixner und John Ogness haben hier große Anstrengungen unternommen. Jetzt, nach knapp 20 Jahren Arbeit, dürfte das Vorhaben einen wichtigen Meilenstein erreichen.

Wer sich für einen tieferen Einblick in die Linux-RT-Welt interessiert, kann einerseits den Artikel von Thomas Leemhuis auf Heise Online von letzter Woche lesen oder sich auf LWN durch das Artikelarchiv zu der Thematik arbeiten.

Ich hatte es geahnt, aber dann ging es doch schneller als gedacht. Mit der Entscheidung des Europäischen Gerichtshofes Ende April wurde in einem Fall in Frankreich die Speicherung von IP-Adressen seitens des ISPs auf Vorrat nicht nur für den Bereich schwerer Straftaten, sondern auch für Urheberrechtsverstöße für zulässig erachtet. Damit ist eine Diskussion wieder auf dem Tisch, die seit 20 Jahren regelmäßig aufflammt, aber bisher durch Urteile gegen die erlassenen Gesetze eingefangen wurde.

Mit diesem Thema haben wir uns vergangene Woche mit Professor Dr. Stephan G. Humer in der 48. Episode des Risikozone-Podcasts beschäftigt, den ich euch wärmstens empfehlen kann.

Die klassische VDS in Deutschland wird momentan nicht praktiziert, da sie nach einem älteren Urteil des EuGH, das konkret das deutsche Gesetz betraf, als rechtswidrig eingestuft wurde. Nichtsdestotrotz ist die Diskussion wieder eröffnet und alle Möglichkeiten für Vorhaben zur Wiedereinführung werden wieder eingebracht. Das Thema wird uns also weiterhin noch eine ganze Weile verfolgen.

Klar, im Urteil des EuGH wird als Bedingung gestellt, dass Maßnahmen getroffen werden müssen, damit die Privatsphäre der einzelnen Nutzer gewahrt bleibt, aber das ändert nichts daran, dass die Daten grundsätzlich erstmal erhoben werden. Die "Neuerung" in diesem Urteil zu der Thematik ist, dass IP-Adressen und Identitäten getrennt gespeichert werden müssen. Mir ist allerdings noch nicht einleuchtend, was im Urteil mit der "Verknüpfung nur unter Verwendung eines leistungsfähigen technischen Verfahrens [...], das die Wirksamkeit der strikten Trennung dieser Datenkategorien nicht in Frage stellt" gemeint ist. Sollen die Datenbanken mit einem anschließend zu verwerfenden Schlüssel verschlüsselt werden, der bei der Verknüpfung erst geknackt werden muss? Am Ende kann ein technisches Verfahren doch gar nicht feststellen, ob ein Gesuch den formellen juristischen Anforderungen genügt oder nicht.

Technisch reden wir hier im Übrigen von zwei Teilaspekten: einerseits die Speicherung, welche Stationen (mit welchen IP-Adressen) miteinander kommunizieren und andererseits, wer hinter welcher IP-Adresse steckt. Diese ganze letzte Thematik haben wir allerdings nur, weil die ISPs einerseits ungern Privatkunden feste IP-Adressen vergeben und andererseits mitunter gar nicht so viele IP(v4)-Adressen wie Kunden haben und dann zu Tricks wie CG-NAT greifen müssen. Hämisch könnte man jetzt fragen, warum in dem Zusammenhang die Politik noch nicht alle zu IPv6 verpflichtet hat. Auf der anderen Seite wird deutlich, wie sehr sich das Internet verändert hat, nachdem es ein Massenmedium wurde.

Früher wurden feste IP-Adressen genutzt und die Zuordnung größtenteils öffentlich hinterlegt. Die Teilnehmer des Internets kannten sich mehr oder weniger sowieso alle untereinander. Als das Internet mehr und mehr ein Massenmedium wurde, ging es allerdings nicht mehr um den wissenschaftlichen oder beruflichen Austausch, sondern auch vorrangiger um das private Leben, wodurch auf einmal Grundrechte tangiert wurden und das Thema der Anonymität im Netz aufkam.

Gespeichert werden die Zuordnungen wohl auch weiterhin noch, aber sichtbar sind sie nur noch für Behörden und ähnliche Organisationen. Spätestens mit dem breiten Ausrollen der DSGVO wurde z. B. der whois-Dienst der DENIC für die Öffentlichkeit geschlossen. Wer einen Webseitenbetreiber ermitteln möchte, der kein Impressum auf der Seite stehen hat, schaut seitdem in die Röhre.

Vorratsdatenspeicherung ist und bleibt somit ein netzpolitisches Thema und lässt sich somit nicht auf der rein technischen Ebene erklären. Von da aus kann man sich oft an den Kopf fassen, was da alles von der Technik erwartet wird. Solche Themen sind auch ein Abbild der Gesellschaftspolitik, was daran deutlich wird, dass im Wesentlichen Deutschland eines der wenigen kritischen Länder diesbezüglich ist.

Die Never-ending-Story geht jetzt also in die nächste Runde. Weitere Probleme, Risiken und Lösungsansätze könnt ihr gerne euch in unserem Podcast anhören und in den Kommentaren mitdiskutieren.

Heute erscheint die 46. Episode des Risikozone-Podcasts und die zweite Episode, in der es um die xz-Lücke geht. Während es in der vorangegangenen Folge um die technischen Details ging, haben wir uns diesmal der Frage gewidmet, wie so ein Eingriff gegen ein Open-Source-Projekt überhaupt möglich werden konnte. Antwort: Es war umfangreiche psychische Manipulation im Spiel.

Deswegen haben wir den Social-Engineering-Experten Stephan G. Humer eingeladen. Er hat eines der ersten regelmäßigen Social-Engineering-Seminare in Deutschland etabliert und erläutert, was Social Engineering eigentlich ist, welche Methoden angewendet werden und wie man sich davor schützen kann.

Mit der heutigen Episode versuchen wir unserem ganzheitlichen Slogan "Der Podcast über Sicherheit und Zuverlässigkeit moderner Technologien" gerecht(er) zu werden und reden nicht nur über technische Details, sondern auch über sozialwissenschaftliche Aspekte und Kultur. Open-Source-Projekte bestehen nämlich nicht nur aus Code, sondern auch aus vielen zwischenmenschlichen Interaktionen, die eine - wie wir mit der Lücke sehen - auch im Bezug auf Sicherheit nicht zu vernachlässigende Rolle einnehmen.

Um dem knapp zweistündigen Interview in einem Punkt vorwegzugreifen: es gibt keine Patentlösung. Social Engineering ist unvermeidbar und wer glaubt, er wäre dem gefeit, ist umso verwundbarer gegenüber Angriffen. Ein entscheidender Punkt ist aber Gelassenheit und damit verbunden Verantwortungsbewusstsein. Wer ein Projekt beginnt und damit wächst, sollte sich als Maintainer in der heutigen Welt umso mehr Gedanken machen, wie man die Last verteilt, wieder aussteigt und Entscheidungen nicht auf eine Person konzentriert. Die Situation, als Maintainer wenig Zeit für ein Projekt zu haben, ist zwar im Einzelfall natürlich menschlich verständlich, aber ein Warnsignal.

Wir werden auf Zeiten keine zufriedenstellende Lösung finden und mit vereinfachten Lösungsansätzen arbeiten. Trotzdem ist es wichtig, ob solcher Angriffe zu wissen und wenigstens eine gesunde Skepsis an den Tag zu legen.

Wie seht ihr das? Wir freuen uns auf euer Feedback!

Seit 1,5 Jahren produziere ich den Podcast Risikozone, in dem es um Themen der IT-Sicherheit und Open-Source-Software geht. Die xz-Backdoor ist natürlich ein heißes Thema, weswegen es in der heute veröffentlichten Episode 45 genau darum geht.

Die knapp einstündige Podcastepisode ist für alle interessant, die nochmals einen technisch orientierten Überblick über die Geschehnisse suchen. Da die Thematik recht komplex ist und aus verschiedenen Blickwinkeln beobachtet werden kann, können weitere Podcastepisoden hierüber noch folgen. Ich möchte aber darauf eingehen, dass man diese Backdoor nicht nur auf den Code beschränken sollte. Es gibt es viele verschiedene Ebenen, die allesamt jeweils Beachtung finden sollten:

• die technische "Exploit"-Ebene
• die zwischenmenschliche Ebene
• die Ökosystem-Ebene

Technisch ist der Exploit ausgeklügelt: Die Backdoor beschränkt sich nicht nur auf die bloße Möglichkeit einer Remote-Code-Execution, sondern verwendet darüber hinaus noch ein eigenes Protokoll, mit dem die Befehle signiert und verschlüsselt innerhalb des unscheinbaren N-Wertes im Zertifikat eines SSH-Handshakes übermittelt werden. Durch die Signatur können nur Befehle ausgeführt werden, die mit einem (wahrscheinlich nur dem Angreifer bekannten) ED448-Schlüssel signiert wurden. Die Verschlüsselung erfolgt zwar mit einem statischen Schlüssel, der aus dem ED448-PubKey abgeleitet wird, erfüllt jedoch trotzdem seinen Zweck: Obfuskierung. Mit anderen Worten: wäre die Lücke nie aufgefallen, hätte man sie in der freien Wildbahn nahezu unmöglich durch Traffic-Analysen finden können.

Das ist allerdings nur die erste von drei Ebenen: die Art und Weise, wie die Lücke hereingeschummelt wurde, weist Komponenten des Social Engineering auf. Die Mühe, über mehrere Jahre eine Identität in verschiedenen Projekten mit teils anfangs legitimen Beiträgen aufzubauen, zeugt auch von einem Plan und Ausdauer.

Schlussendlich sollte man auch nicht vergessen, dass hier eine besondere Konstellation im Ökosystem ausgenutzt wurde. Am einfachsten (und auffälligsten) wäre es, eine solche Lücke in OpenSSH unterzubringen. Es wurde aber auf eine deutlich unbeachtetere und einfacher zu infiltrierende Variante ausgewichen. Die xz-Bibliothek wurde zudem nicht zum Einfallstor, weil OpenSSH darauf zurückgreift (das tut es nämlich nicht), sondern weil einige Distros systemd-notify reinpatchen, was wiederum auf die xz-Lib zurückgreift. Außerdem rüttelt dieser Fall an einem Grundpfeiler der IT-Sicherheits-Praktiken: Updates. Diese Hintertür fand geradezu durch die (häufigen) Updates der Rolling-Release-Distros Einzug - die stabilen Versionen waren noch verschont geblieben. Ist also (zu) häufiges Updaten nun auch nicht mehr richtig? Bringen bald Updates mehr Lücken als sie schließen?

Das alles macht es vor allem noch schwieriger, solche Angriffe zuverlässig zu erkennen. Zudem ist davon auszugehen, dass die Angreifer sich die Verteidigungsstrategie jetzt ganz genau anschauen. Die zukünftige Diskussion sollte sich also darauf konzentrieren, wie man diese Art von Angriffen detektiert und frühzeitig eindämmt.

Seit September letzten Jahres produziere ich den Risikozone-Podcast. Über das vergangene halbe Jahr sind auf diese Weise schon 19 Episoden entstanden, die üblicherweise zwischen 40 und 60 Minuten lang sind. Ein besonderes Highlight war die Sonderepisode 6, wo wir Sönke Huster interviewt haben, der über die Erfahrungen beim Auffinden von Sicherheitslücken im WLAN-Stack des Linux-Kernels berichten konnte.

In weiteren Episoden haben wir bereits über Grundlagen der IT-Sicherheit gesprochen, darunter E-Mail-Hosting, VPNs, Mastodon, symmetrische Kryptosysteme oder asymmetrische Kryptosysteme. Ein immer stärkerer Fokus wird allerdings auch auf Machine-Learning-Modelle gerichtet, wie schon im Dezember über ChatGPT angesprochen.

In der heutigen Risikozone-Episode Nr. 19 geht es um eine ganze Reihe von Themen und aktuellen Nachrichten, die wir gestern aufgegriffen haben. Dabei ist ein konkretes Open-Source-Thema dabei, was ich euch nicht vorenthalten möchte.

Open Source wird bei KI-Systemen und hier den oft angesprochenen Large-Language-Models (LLMs) eine besondere Rolle spielen, denn bisher gibt es wenige große Anbieter, die in ihrer Rolle gleichzeitig auch als Gatekeeper fungieren. Gatekeeper, da sie einerseits proprietär die Gewichte bzw. Parameter für sich behalten möchten, aber andererseits auch eine Sicherheitsfunktion einnehmen.

Hier steht Sicherheit dem Open-Source-Gedanken gegenüber. Wer allerdings jetzt nach Verboten von "ungeprüfter" Open-Source-KI ruft, verkennt in meinen Augen allerdings die Bedeutung für die IT-Sicherheit. Es muss immer davon ausgegangen werden, dass "bad actors", also bösartige Akteure, alle technischen Möglichkeiten ausnutzen. Das umfasst auch das eigenständige Beschaffen von Trainingsdaten, Architekturspezifikationen und Rechenressourcen. Sich also nun auf Verbote und Moratorien zu verlassen, bringt im Ergebnis wenig. Ob die Open-Source-Modelle nun verfügbar oder verboten sind, hat auf bösartige Akteure keinen Einfluss und hemmt zudem noch die Weiterentwicklung "gutartiger" Modelle.

Indirekt lässt sich auch hier Kerckhoff's Prinzip anwenden, welches eigentlich eher aus der Welt der Kryptographie kommt:

Es darf nicht der Geheheimhaltung bedürfen und soll ohne Schaden in Feindeshand fallen können.

— Auguste Kerckhoffs: La cryptographie militaire 1883

Heißt also: Software resilient und sicher gestalten, Schutzmaßnahmen ausbauen, sich Gefahren nicht schönreden. Ein Beispiel ist da die Absicherung von BGP durch RPKI, wie sie von der niederländischen Regierung vorangetrieben wird. Auch das wird heute in der Episode kurz besprochen.

Auch wenn viele LLMs momentan frei ausgetauscht werden, sind sie oftmals nicht frei lizenziert, insbesondere, wenn sie von Meta AIs LLaMa abstammen. Das ist so ein bisschen wie das Unix von früher. Ausprobieren: jaein, selber verteilen: nein. Ein Auge richte ich momentan auf das Projekt Open Assistant, hier soll diesen Samstag das erste eigene, größere frei lizenzierte LLM veröffentlicht werden. Es bleibt also spannend.

Die Shownotes und das automatisiert erstellte Transkript befinden sich auf der Episodenseite, Informationen zum RSS-Feed auf der eigens dafür eingerichteten Unterseite. Feedback könnte ihr gerne als E-Mail oder Kommentar hier oder auf risikozone.de geben.