Das Jahr 2024 geht zu Ende und ich möchte die Gelegenheit nutzen, mich herzlich bei allen Lesern zu bedanken, die in diesem Jahr meinen Blog verfolgt, meine Artikel gelesen oder ihn durch Kommentare und Zuschriften bereichert haben.

Zu Beginn des Jahres bin ich zum Institut für sichere mobile Kommunikation (ISMK) gewechselt und habe den Podcast Risikozone mitgenommen, sodass ich die Episoden nun im Rahmen meiner Tätigkeit dort produziere. Viele IT-Sicherheitsthemen, die ich im Blog veröffentlicht hätte, fließen nun zwei Mal im Monat in die Episoden dort ein. Über das vergangene Jahr des Podcasts haben wir in Episode 63 gesprochen.

Mein Blog begleitet mich nun schon seit 2016. Im neunten Jahr seines Bestehens habe ich mit 14 Artikeln den Schnitt der vergangenen Jahre gehalten. Wie gewohnt möchte ich zum Jahresende auf einige Highlights und bedeutende Themen des vergangenen Jahres im Blog zurückblicken.

Rückblick auf 2024

Eines der herausragendsten Ereignisse in der IT-Sicherheits- und Open-Source-Welt war zweifellos die xz-Lücke. Über diese Backdoor habe ich sowohl hier im Blog als auch in den Risikozone-Episoden 45 und 46 berichtet.

Ein weiteres bemerkenswertes Sicherheitsproblem war die OpenSSH-Sicherheitslücke RegreSSHion. Zudem wurden in der glibc zwei Lücken entdeckt, deren besondere Bedeutung in ihrem Alter lag: Die verwundbaren Versionen wurden seit 1992 ausgeliefert.

Beim Durchsehen des Blogarchivs fiel mir zudem auf, dass die Veröffentlichung von KDE Plasma 6 ebenfalls in dieses Jahr fiel. Die neue Version der Desktopumgebung, die erstmals nun auf Qt 6 aufbaut, fühlt sich schon so vertraut an, dass es schwer zu glauben ist, dass sie erst 2024 erschienen ist.

Pläne für 2025

Das Thema Künstliche Intelligenz, insbesondere im Bereich der Large Language Models (LLMs), hat sich 2024 stabilisiert. Nach dem anfänglichen Hype zeichnet sich nun eine Phase der Konsolidierung ab. Für das kommende Jahr plane ich, die LLM Timeline wieder zu aktualisieren, um die Entwicklungen der letzten Monate zu dokumentieren.

Auch technisch wird sich auf dem Blog einiges tun. Ich arbeite an einer Erweiterung der Blogsoftware, um die Unterstützung für mehrere Sprachen zu verbessern und das Design speziell für Infografiken zu optimieren.

Guten Rutsch

Ich wünsche euch allen einen guten Rutsch in das Jahr 2025 und freue mich darauf, euch auch im neuen Jahr mit spannenden Artikeln, Podcast-Episoden und technischen Updates begleiten zu dürfen! Danke für eure Unterstützung und euer Interesse!

Der Fakespot Deep Fake Detector ist eine neue Firefox-Erweiterung von Mozilla, welche es dem Nutzer ermöglichen soll, mutmaßliche KI-Inhalte von Inhalten zu unterscheiden, die von echten Menschen geschaffen wurden.

Download Fakespot Deep Fake Detector

Künstliche Intelligenz (KI) erlebt in den letzten Jahren einen extremen Aufschwung – sowohl qualitativ als auch, was die Nutzung betrifft – und das längst auch im Mainstream-Bereich. Heute fällt es teilweise schwer, überhaupt noch zu erkennen, welche Inhalte von einer KI erzeugt worden sind und was das Werk echter Menschen ist.

Mozilla möchte dieses Problem angehen – und zwar mit Hilfe Künstlicher Intelligenz. Der Fakespot Deep Fake Detector ist eine neue Browser-Erweiterung für Firefox, welche es erlaubt, markierten Text dahingehend zu analysieren. Alternativ kann Text auch ohne Browser-Erweiterung auf der dazugehörigen Website eingegeben werden.

Zu diesem Zeitpunkt werden ausschließlich englischsprachige Texte unterstützt. Bei Text soll es dabei nicht bleiben: In Zukunft soll der Fakespot Deep Fake Detector auch Videos und Bilder analysieren können.

Für eine bessere Zuverlässigkeit verlässt sich Mozilla nicht auf ein einzelnes Modell. Mit ApolloDFT, Binocular, UAR sowie ZipPy kommen derzeit gleich vier Modelle mit unterschiedlichen Stärken und Schwächen zum Einsatz, die auch beschrieben werden. Wenn es Unstimmigkeiten in der Bewertung gibt, erfährt der Nutzer, welches Modell zu welchem Ergebnis kam. Bei allen diesen Modellen handelt es sich um Open Source-Modelle, wobei ApolloDFT ein eigenes Modell von Fakespot ist.

Fakespot war ursprünglich ein eigenständiges KI-Unternehmen, welches sich auf die Erkennung sogenannter „Fake-Inhalte“ spezialisiert hat und im Mai 2023 von Mozilla übernommen worden ist. Am besten bekannt ist Fakespot für die Erkennung falscher Produktbewertungen beim Online-Shopping. Mittlerweile ist diese Funktionalität für Amazon, BestBuy und Walmart nativ in Firefox integriert.

Der Beitrag Fakespot Deep Fake Detector: Neue Erweiterung von Mozilla erkennt Inhalte von KI vs. echten Menschen erschien zuerst auf soeren-hentzschel.at.

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.

Zum zünftigen Einläuten des neuen Jahres braucht es einen Countdown. Dieser lässt sich einfach in HTML, CSS und etwas JavaScript erstellen.

The FSFE promotes freedom of software, hardware, and data

The ZOOOM (3Os) Initiative promotes innovation based on freedom of software, hardware, and data. With its recent conclusion, the FSFE hopes to inspire broader use and effective application of Free Software by business, academia, and the public sector.

Free Software, Open Data and Open Hardware are essential building blocks for a sustainable and trustworthy industrial and commercial ecosystem. Nevertheless, business, academia, and the public sector sometimes lack important fundamental understandings of these topics, and as a result many industries often develop systemic problems by matching business models with inappropriate licensing frameworks, or even without sufficient frameworks at all.

To help solve these problems, the FSFE became a partner of the ZOOOM Initiative (3Os – Open Source Software, Open Data, Open Hardware), that started in 2022. This European project funded by the European Commission aimed to build competence and raise awareness on the importance of proper management of these three open assets (Software, Hardware, and Data). The FSFE contributed specifically in the research and the development of educational materials on various topics related to Free Software, tailored for industrial and commercial needs. We are pleased to share the outcomes of our collaborative work with our ZOOOM partners over the past 2 years.

Innovative research involving open assets

Together with our ZOOOM consortium partners, we have conducted innovative research to understand commonalities and interactions on the issues faced when dealing collectively with Free Software, Open Hardware, and Open Data. The results have been documented in a report that assists stakeholders with understanding the 3Os and proposes strategies to align their business models with the complexities characterizing each of these open ecosystems.

To support this reporting, the FSFE also conducted extensive research and analysis on Free Software legal issues for business and innovation. As a result of this work, we have contributed to a review of legal cases on issues related to the 3Os, specifically on legal cases related to Free Software. Those interested in an overview of legal issues in open hardware and open data will also find this review useful.

The ZOOOM project broke AI down into its most fundamental elements, so research involving Free Software licensing is facilitated.

Recommendations on Free Software AI licensing

Another significant outcome of this European project was the creation of a comprehensive paper on Free Software and openness in the area of artificial intelligence development. This paper examined the convergence of Free Software and AI focusing on the legal aspects of licensing

In the paper, we considered the necessity to promote openness in a manner that respects the principles of Free Software, especially in light of the various challenges in achieving such openness in AI licensing. In particular, we highlighted the uncoordinated growing proliferation of licenses claiming to be “free and open source” in the AI scene, but that actually impose extra limitations on software freedom and that may lead to license incompatibility.

To improve the situation, we proposed three important recommendations:

1. Preserving openness in AI by safeguarding the Four Freedoms of Free Software;
2. Keeping licensing of AI technologies cohesive and interoperable with Free Software licenses;
3. Encouraging engagement with civil society actors in initiatives aimed to make AI more open, accessible, transparent, and auditable.

The drafting of these papers with our ZOOOM consortium partners has also enabled us to raise awareness among the academic community about the importance of Free Software and open concepts, as they relate to software, hardware, and data.

The hybrid nature of AI, involving data and code, poses challenges for licensing. The ZOOOM project analysed this in detail from the perspective of Free Software.

Development of training materials

In addition to these research activities, we contributed to the development of training materials intended for any organisation – private or public – to equip users with the knowledge and skills needed to navigate Free Software, open hardware, and open data. The training toolkit can be especially useful for small and medium enterprises (SMEs) across Europe with the necessary skills to adopt strategies and evaluate business modules that relate to open technologies.

Check out our Legal Education Day playlist

Successful outreach in Europe for Free Software

The ZOOOM project also engaged in an extensive awareness campaign to promote our work, and general awareness of the principles of Free Software, Open Hardware, and Open Data. As part of this campaign, more than 40 events were organised. The FSFE spoke at various conferences and events across Europe, including at FOSDEM 2024, DORS/CLUC 2024, and SFSCon 2022

Additionally, the ZOOOM consortium organized exclusive meetups and events involving a broad range of stakeholders (academia, public sector and business), to further promote Free Software in Ljubljana, Trento, and Brussels.

The ZOOOM project allowed the FSFE to reach university students, academics, and science folks to raise awareness for the importance of Free Software.

Sustainability goal: open science

In only two years, the ZOOOM project produced comprehensive research merging aspects of Free Software, Open Data and Open Hardware. Focusing on the importance of these assets for the future of AI, the initiative not only produced scientific materials tackling legal and business issues regarding Free Software, but also developed a series of recommendations. The next steps are to deploy further the material produced, engaging with organisations and individuals interested in reusing and developing further the materials.

If you are interested in knowing more about the wealth of knowledge produced by ZOOOM, feel free to reach out!

Support FSFE

Ich wünsche allen Lesern ein erfolgreiches Jahr 2025, aber zunächst einmal einen guten Rutsch. Und danke für das Interesse an diesem Blog.

Quelle

Schnappszahl bei den veröffentlichten Kommentaren. Bei der Anzahl der blockierten Kommentare freue ich mich, dass die Antispam Bee so gut funktioniert.

Wie habe ich das erste Jahr im CORE-Team erlebt und was beschäftigte uns 2024? Ein Jahresrückblick.