KI-Werkzeuge in der Softwareentwicklung

In der Softwareentwicklung existierten schon immer Werkzeuge und Vereinfachungen wie Autocompletion oder Syntax-Highlighting, die den Entwicklungsprozess effizienter und weniger fehleranfällig machen sollten. Diese Werkzeuge haben es Entwicklern ermöglicht, sich stärker auf die Logik und Funktionalität ihres Quellcodes zu konzentrieren, anstatt sich mit den Details der Syntax oder der Strukturierung von Quellcode herumzuschlagen.

In den vergangenen Jahren hat sich die Landschaft der Softwareentwicklung weiterentwickelt und neue Technologien und Methoden haben Einzug gehalten. Beispielsweise haben Versionskontrollsysteme wie Git die Zusammenarbeit in Teams wesentlich verbessert und Continuous-Integration-/Continuous-Deployment-Pipelines ermöglichen es, Änderungen effizienter in Produktionsumgebungen zu bringen.

KI-Werkzeuge sollen die Entwicklungsarbeit vereinfachen

Aktuell finden immer mehr Werkzeuge, die mit maschinellem Lernen oder großen Sprachmodellen (Large Language Models) arbeiten, ihren Weg in die Praxis. Assistenten wie GitHub Copilot oder Tabnine nutzen hierbei große Mengen an Trainingsdaten, um Entwicklern kontextbezogene Vorschläge anzubieten, die weit über einfache Autocompletion hinausgehen. So können komplexere Code-Snippets vorgeschlagen oder ganze Methoden und Funktionen auf Basis kurzer Beschreibungen generiert werden.

Im Idealfall soll dies die Produktivität erhöhen, auch wenn das letzte Wort hierbei noch nicht gesprochen ist. Doch welche Werkzeuge existieren? Im Rahmen des Artikels soll ein Blick auf spezialisiertere Lösungen zur Entwicklung abseits von ChatGPT und Co. geworfen werden.

Arten von Werkzeugen

Auf dem Markt der KI-Werkzeuge zur Softwareentwicklung existieren Werkzeuge unterschiedlicher Couleur. Neben Integrationen für eine Anzahl von IDEs, existieren Standalone-Tools und auch webbasierte Tools. Viele KI-Werkzeuge sind als Plugins oder Erweiterungen für IDEs wie Visual Studio Code oder IntelliJ IDEA verfügbar. Diese Integrationen ermöglichen es, KI-gestützte Funktionen direkt in der gewohnten Entwicklungsumgebung zu nutzen, was den Arbeitsablauf verbessert.

Einige dieser Werkzeuge bieten spezialisierte Funktionen, die auf bestimmte Aspekte der Softwareentwicklung abzielen, wie Code-Generierung, Fehlererkennung, Optimierung, Review oder Testautomatisierung.

Code-Assistenten

Einer der häufigsten neuen Werkzeug-Typen sind Code-Assistenten, welche es ermöglichen Quellcode zu generieren und diese Fähigkeit in einer Entwicklungsumgebung einzusetzen. Daneben können Fragen zum Quellcode gestellt, Dokumentationen erzeugt, oder Vorschläge für ein Refactoring erzeugt werden.

Bei diesen Code-Assistenten finden sich etliche Schwergewichte der IT, wie Amazon oder Microsoft wieder.

Amazon Q

Als Antwort auf GitHub Copilot stellte Amazon CodeWhisperer vor. Mittlerweile ist dieses Werkzeug in Amazon Q aufgegangen.

Für Entwickler dürfte das Teilprodukt Amazon Q Developer interessant sein. Für dieses sind unter anderem Integrationen für die JetBrains IDEs, VS-Code und Visual Studio verfügbar. Auch eine Version für die Kommandozeile wird geboten.

Amazon Q in einer Jetbrains IDE

Für den Assistenten wird eine AWS Builder ID benötigt. Im begrenztem Rahmen kann der Assistent, damit kostenlos ausprobiert werden.

Sinnvolle Ergebnisse liefert der Assistenz nur bei Anfragen in englischer Sprache. Interessant ist die Möglichkeit, Quelltext zu generieren, der über mehrere Dateien reicht. Hier haben andere Assistenten meist ihre Probleme und erzeugen nur Quellcode an einem Stück.

Gesteuert wird der Assistent über Befehle wie /dev mit einem darauffolgenden Prompt. Angeboten wird neben der kostenlosen Variante, ein Business Lite und ein Business Pro Abonnement.

Insgesamt fühlt sich Amazon Q als generisches KI-Werkzeug zur Entwicklung unzureichend an, allerdings könnte es anders aussehen, wenn eine engere Verzahnung mit AWS und die Nutzung eigener Geschäftsdaten gewünscht wird.

Codeium

Codeium ist ebenfalls ein Code-Assistent, welcher sich in unterschiedlichste IDEs integriert.

Codeium unterstützt eine Reihe von IDEs

Das Plugin verfügt über eine Chat-Funktionalität, welche es ermöglicht Anforderungen bzw. Prompts zu definieren. Negativ fällt auf, dass hier die aktuell genutzte Programmiersprache nicht automatisch erkannt wird, sondern explizit angegeben werden muss.

Auch das Antworten auf bereits erzeugte Nachrichten muss separat erledigt werden. Wird stattdessen direkt im Chatfenster geantwortet, wird eine neue unabhängige Konversation gestartet. Soll auf einen vorherigen Chat Bezug genommen werden, so muss der Continue this chat-Button genutzt werden.

Die Chat-Funktionalität nutzt die falsche Programmiersprache

Interessanter ist die Möglichkeit, relativ unkompliziert Unit-Tests für ausgewählte Methoden zu generieren. Hierfür wird eine Methode ausgewählt und entsprechende Testfälle werden ermittelt und anschließend in Code umgesetzt.

Codium erzeugt Testfälle

Anschließend können die Testfälle in eine Datei übernommen werden. Auch hier fehlt wieder der Kontext, da die Datei standardmäßig einfach im Hauptverzeichnis des Projektes abgelegt wird, zumindest bei der JetBrains-IDE-Integration.

Genutzt werden für Codium die OpenAI-Modelle der GPT-3 und GPT-4 Reihe. Interessant ist Codium für Plattformen, bei denen sonst keine IDE-Integration vorliegt, da Codium hier mit Vielfalt glänzt.

Neben dem Codeassistenten bietet Codium mit Forge auch eine Lösung für das Review von Quellcode an.

Cody

Mit Cody existiert ein KI-gestützter Assistent zur Softwareentwicklung. Nicht verwechselt werden sollte der Assistent mit Cody AI, das sich mehr als KI-unterstützte Suche auf Basis einer Firmen-Wissensbasis versteht.

Neben der Webvariante von Cody werden primär die Entwicklungsumgebungen VS Code und die JetBrains-IDEs unterstützt. Daneben existiert eine experimentelle Unterstützung für Neovim. Andere IDEs wie Eclipse und Emacs sollen in Zukunft folgen.

In der JetBrains-Variante wirkt die Integration ausgereift. So ist nicht nur ein Fenster verfügbar, in dem ein Chat angezeigt wird, sondern es existiert auch eine Integration im Code-Editor.

Anhand des Methodennamens wurde der Inhalt der Methode generiert

Während im Chatfenster der Kontext, wie die aktuell verwendete Programmiersprache nicht erkannt wird, sieht dies im Code-Editor anders aus. Hier wird der Code in der verwendeten Sprache generiert.

Die Modellauswahl im Chat-Fenster

Ein Merkmal, mit dem sich Cody von anderen KI-Assistenten unterscheidet, ist die transparente Auswahl der genutzten Modelle. Das passende Modell kann hierbei einfach ausgewählt werden.

Neben den Möglichkeiten zur Codegenerierung bietet Cody auch die Möglichkeit vorgefertigte Kommandos zu nutzen und mit diesen das Dokumentieren von Quellcode oder Unit-Test zu automatisieren.

CodeSquire

CodeSquire ist eine spezialisierte KI-Assistent-Lösung in Form einer Erweiterung für den Browser Chrome. CodeSquire ist ein Tool für Datenwissenschaftler, das Kommentare in Code umwandelt, SQL-Anfragen aus natürlicher Sprache erstellt, intelligente Codevervollständigung bietet und komplexe Funktionen generiert.

Unterstützt werden aktuell Plattformen wie Google Colab, BigQuery und JupyterLab.

Diese Plattformen zählen zu IDEs, die meist speziell für interaktive Datenanalyse und wissenschaftliches Rechnen genutzt werden. Diese speziellen IDEs kombinieren viele Funktionen, die in traditionellen IDEs zu finden sind, wie Code-Editoren, Terminals und Dateibrowser, mit speziellen Werkzeugen für die Arbeit mit Daten und interaktiven Notebooks.

CodeWP

Ebenfalls zu den spezialisierten Lösungen zählt CodeWP, welches einen Assistenten darstellt, welcher auf WordPress spezialisiert ist.

CodeWP

Die dahinterliegenden Modelle sind darauf trainiert, Code in PHP und JavaScript im Kontext von WordPress zu generieren. So kann mit einem einzelnen Prompt ein einfaches Plugin generiert werden.

Die CodeWP-Website

CodeWP erweckt mit Aussagen wie Proprietary AI und More accurate than ChatGPT sowie der Aussage:

Our Al models are trained to output the best, most modern, secure, simple code for WordPress. So no need to worry about common bugs or issues.

den Eindruck, dass ein eigenes Sprachmodel verwendet wird, ohne auf Mitbewerber wie OpenAI angewiesen zu sein.

Cursor

Cursor versteht sich, im Gegensatz zu den bisher vorgestellten Assistenten, als dedizierte IDE mit einer KI-basierten Unterstützung für Entwicklung.

Technisch handelt es sich um einen Fork von VS Code. Der Grund hierfür, ist nach Aussage des Herstellers, in der besseren Anpassbarkeit der IDE zu finden.

Der Onboarding-Prozess von Cursor

Nach der Installation wird der Nutzer durch einen kleinen Onboarding-Prozess geführt. Dieser führt in die Möglichkeiten ein, Bugs zu identifizieren, spezifische Codestellen zu lokalisieren oder Code von einer Programmiersprache in eine andere zu übersetzen.

Cursor kann natürliche Sprache verstehen und darauf reagieren, was es erleichtern soll, direkt im Code-Editor mit der KI zu interagieren. So können Fragen zu Codebasis gestellt werden, Vervollständigungen angefordert werden oder Code-Snippets generieren werden.

Die Freemium-Version unterliegt einigen Einschränkungen, welche in den kostenpflichtigen Tarifen aufgehoben werden.

Fraglich ist, ob hierfür eine neue IDE benötigt, und warum nicht auf Integrationen für bestehende Systeme gesetzt wurde. In den meisten Fällen werden Entwickler doch meist auf ihre angestammten Werkzeuge setzen wollen.

GitHub Copilot

Zu den bekannteren Lösungen auf dem Markt zählt sicherlich GitHub Copilot. Dieses Werkzeug ist in allen Varianten (bis auf die Trial-Version) kostenpflichtig.

Neben der Nutzung über die Kommandozeile, existieren eine Reihe von IDE-Integrationen, insbesondere für Visual Studio, VS Code und die JetBrains IDEs. Daneben werden Vim und Neovim, sowie Azure Data Studio unterstützt.

GitHub Copilot in einer JetBrains-IDE

Positiv fällt die Autovervollständigung bzw. die Geschwindigkeit derselben auf. Allerdings ist sie in einigen Fällen auch relativ nervig, da sie bei der Entwicklung zu unnötiger Ablenkung führen kann.

Eine Methode wird generiert

Zumindest in den JetBrains-IDEs gibt es keine Integration über die Quick-Fixes-Funktionalität. Dafür stehen eine Reihe von Kommandos wie /tests, /simplify, /fix oder /explain zur Verfügung.

Diese können in der eingebauten Chat-Funktionalität genutzt werden. Die Ergebnisse werden im Chat angezeigt, können allerdings nicht automatisch ins Projekt übernommen werden, sondern müssen kopiert und wieder eingefügt werden. Besonders nervig ist dies bei der Generierung von Dokumentation für Methoden, wie sich im Vergleich zum Assistenten JetBrains AI zeigt.

Positiv hervorzuheben ist die automatische Übernahme des Kontexts, wenn Themen im Chat angesprochen und genutzt werden.

JetBrains AI

Das tschechische Unternehmen JetBrains ist primär für seine unterschiedlichen IDEs bekannt und bietet mit JetBrains AI einen Assistenten für KI-unterstütze Entwicklung. Auch JetBrains AI muss über ein Abonnement freigeschaltet werden. Wenig verwunderlich ist die Integration von JetBrains AI in die jeweiligen IDEs der Firma sehr gelungen.

Entwicklung mit der JetBrains AI

Neben der bei vielen KI-Assistenten gegebenen Möglichkeiten des Chats mit dem Sprachmodell, bietet JetBrains AI die Möglichkeit von Quick-Fixes in Form von AI Actions, welche unter anderem das Schreiben von Dokumentation oder das Generieren von Unit-Tests vereinfachen sollen.

Neben den vorgefertigten Prompts können eigene Prompts hinterlegt und diese dann ebenfalls über die AI Actions genutzt werden. Angenehm an JetBrains AI ist die Möglichkeit Dokumentation wie Javadoc automatisch für eine Methode generieren und antragen zu können.

Die Einstellungen für JetBrains AI

Automatische Codevorschläge während der Entwicklung sind so gestaltet, dass sie nicht unnötig ablenken und können über die Einstellungen konfiguriert werden.

Daneben findet sich der KI-Assistent noch in anderen Integrationen wieder, wie bei der Umbenennung bzw. der Namensfindung, hier werden neben den klassischen Vorschlägen auch KI-Vorschläge angezeigt.

Durch ein kleines Symbol wird transparent gezeigt, welche Vorschläge von der KI stammen und welche nicht. Grundsätzlich zieht sich diese Transparenz durch JetBrains AI bzw. dessen Implementation.

Auch Fragen zu bestimmten Teilen des Quellcodes können schnell und bequem gestellt werden, indem an der gewünschten Stelle über eine Quick-Action ein KI-Chat zum aktuellen Quellcode gestartet wird.

Weitere Kleinigkeiten sind die Generierung von Commit-Nachrichten, welche ebenfalls von JetBrains AI bereitgestellt werden.

Während im Standard-Abonnement von JetBrains AI nicht gewählt werden kann, welche Sprachmodelle verwendet werden, soll dies später in den Enterprise-Varianten auswählbar sein. Je nach genutzter Funktionalität scheinen im Moment unterschiedliche Modelle genutzt werden.

Neben JetBrains AI, verfügen einige IDEs wie IntelliJ IDEA Ultimate mittlerweile auch über Möglichkeiten zur Codevervollständigung über ein lokales Sprachmodell, welches ohne externe Zugriffe auskommt.

Die IDE-Integration von JetBrains AI wirkt insgesamt sehr ausgereift, insbesondere im Vergleich zu anderen KI-basierten Assistenten. Dafür steht JetBrains AI nur für die entsprechenden IDEs der Firma zur Verfügung.

Tabnine

Die Firma hinter Tabnine existiert schon länger als der aktuelle KI-Hype und hat seit längerem Code-Assistenten zur Unterstützung in der Entwicklung angeboten.

Ursprünglich bekannt als Codota, hat sich das Unternehmen auf die Entwicklung von KI-basierten Werkzeugen für Entwickler spezialisiert. Im Gegensatz zu vielen anderen Lösungen wird bei Tabnine, über Tabnine Enterprise, auch das Selbst-Hosting angeboten.

Interessant ist bei Tabnine die Wahl der Modelle zur Verarbeitung der Anfragen. Hier werden Modelle wie Tabnine Protected angeboten, welche nur mit Quellcodes trainiert wurden, welche eine entsprechende Lizenz besitzen und somit idealerweise z. B. keine Codeschnipsel unter GPL replizieren.

Auch werden je nach Modell gewisse Garantien gegeben, was Themen wie Datenschutz und die Weiterverwendung der Prompts angeht. Daneben werden die Modelle über Tags sinnvoll kategorisiert, sodass die Wahl des passenden Modells aufgrund dieser getätigt werden kann.

Die Auswahl der Modelle

Bei den IDEs unterstützt Tabnine eine Reihe von IDEs, angefangen bei VS Code über die JetBrains-IDEs, bis hin zu Neovim.

Die Fix-Funktionalität von Tabnine

In Bezug auf die IDE-Integration wirkt Tabnine in JetBrains-IDEs recht gut integriert. Dadurch können kontextbasierte Operationen wie das Beheben von Fehlern oder das Dokumentieren von Quellcode effizient durchgeführt werden.

Im Tabnine-Chat wird dabei eine Antwort generiert und dessen Ergebnis kann mit in den Quellcode übernommen werden.

Das manuelle Einfügen fühlt sich allerdings immer etwas umständlich an und aktiviert oft die automatische Codeformatierung nicht, was im schlechtesten Fall immer einen zusätzlichen Bearbeitungsschritt bedeutet.

Die Generation eines Tests schlägt fehl

Andere Operationen, wie die Erstellung eines Testplans, können unter Umständen scheitern, da eine vom Plugin generierte Datei möglicherweise nicht befüllt werden kann, was auf einen Bug hinzudeuten scheint.

Die Testplan-Ideen von Tabnine

Auch wenn die Ideen für den Testplan von Tabnine interessant sind, fühlt sich hier die Integration durch das manuelle Einfügen komplex und fehleranfällig an.

Analyse-Werkzeuge

Neben den allgemeinen Code-Assistenten existieren einige Werkzeuge, welche sich auf die Analyse von Quellcode spezialisiert haben, z. B. für das Review von Quellcode bzw. Pull Requests.

Amazon CodeGuru

Ein von Amazon angebotenes Analyse-Werkzeug ist Amazon CodeGuru. Dieses Werkzeug versteht sich als Scanner, um Sicherheitslücken und Schwachstellen im Code zu finden. Daneben werden auch Vorschläge erstellt wie Anwendungen optimiert bzw. beschleunigt werden können.

Gedacht ist dieses Werkzeug nicht für die direkte Nutzung, sondern eher für die Integration in entsprechende Pipelines.

Neben der Nutzung in AWS CodeCommit (das demnächst eingestellt wird) wird auch die Nutzung von BitBucket- und GitHub-Repositories unterstützt.

Sourcery AI

Sourcery AI versteht sich als Werkzeug für automatisches Reviewing. Verknüpft werden kann dieses Werkzeug unter anderem mit GitHub oder GitLab. Wenn gewünscht, wird so bei jedem Pull-Request ein entsprechender Kommentar hinterlassen.

Sourcery AI erstellt Kommentare zu einem Pull Request

Während die Nutzung für kommerzielle Projekte mit einem Abonnement verbunden ist, können Open-Source-Projekte Sourcery AI ohne weitere Kosten einsetzen.

Neben der Kommentierung des Pull-Requests werden auch Hinweise für den Reviewer und eine Zusammenfassung erstellt.

Snyk

Neben Werkzeugen, die sich auf normale Entwicklungsarbeiten konzentrierten, existiert mit Snyk ein Analyse-Werkzeug, welches Verwundbarkeiten und Sicherheitsprobleme im Code aufdecken soll.

Snyk in einer JetBrains IDE

Snyk positioniert sich als Werkzeug, das durch den Einsatz von maschinellem Lernen sowie dynamischen und statischen Analysen den Quellcode auf diese Problemklasse hin untersucht.

Dabei werden eine Reihe von Produkten angeboten, welche diese Technologie zur Anwendung bringen soll.

WhatTheDiff

Ähnlich wie Sourcery AI ist auch WhatTheDiff ein Werkzeug für automatisierte Code-Reviews.

Im Gegensatz zu Sourcery AI muss die GitHub-Integration vor der Nutzung konfiguriert und aktiviert werden.

Die Repositories müssen aktiviert werden

Nach der Aktivierung werden für Pull Requests automatisch Kommentare erzeugt.

What The Diff erzeugt automatisch Kommentare zu den Pull Requests

Wie bei Sourcery AI werden hier auch Kommentare zur Zusammenfassung und Review-Kommentare am Pull Request erstellt, welche dann bearbeitet werden können.

Weitere Werkzeuge

Neben den größeren Klassen wie Code-Assistenten und Analysewerkzeuge, existieren weitere Werkzeuge, welche KI-basiert einen Mehrwert in der Entwicklung bringen können.

bloop.ai

Unter bloop.ai werden verschiedene Services rund um KI-gestützte Codegenerierung und Nutzung angeboten.

So wird ein Dienst angeboten, welcher COBOL-Programme in lesbare Java-Applikationen umwandeln soll. Ein weiterer Dienst befasst sich mit einem Sprachmodell, welches direkt COBOL-Quellcode schreiben kann.

bloop indiziert ein Repository

Für den alltäglichen Gebrauch interessanter war die Understand-Funktionalität, die es ermöglicht, Repositories zu laden und anhand dieser Repositories Fragen zum Quellcode zu stellen.

Bloop wird zum Bevy-Projekt befragt

Diese existierte in einer freien Variante sowie in einer kostenpflichtigen Personal-Variante. In der kostenpflichtigen Variante wurde unter anderem die Indizierung mehrerer Branches ermöglicht.

Nach der kürzlich erfolgten Einstellung steht nur noch die freie Variante dieser Funktionalität zur Verfügung. Für den alltäglichen Gebrauch, vorwiegend mit unbekannteren Codebasen, kann dieses Werkzeug eine wertvolle Ergänzung sein.

GitFluence

Wer in der Softwareentwicklung arbeitet, wird oft auch mit Versionskontrollsystemen wie Git arbeiten. Auch hier existieren mittlerweile KI-Tools, welche unterstützen sollen.

GitFluence

Eines dieser Werkzeuge ist GitFluence, das unter der Haube mit der OpenAI-API arbeitet. Gedacht ist das Werkzeug für den Fall, dass eine Git-Aktion beschrieben wird und automatisch ein Git-Kommando dafür erstellt wird.

Dies wirkt allerdings in einigen Fällen eher unausgegoren und lieferte unbrauchbare Ergebnisse, während es sporadisch sinnvolle Antworten liefert.

Grit.io

Der Dienst Grit.io spezialisiert sich auf Code-Migration und automatische Dependency Upgrades. Aktuell ist er nur über eine Warteliste verfügbar, sodass hier eine genauere Beurteilung schwerfällt.

Eines der Beispiele von der Grit.io-Seite

Durch die automatische Aktualisierung von Abhängigkeiten und die Durchführung größerer Migrationen soll eine allgemeine Verbesserung der Codequalität stattfinden.

Mutable AI

Neben Code-Assistenten, die sich auf die Entwicklung spezialisieren, existieren auch solche Assistenten, die sich der Dokumentation und Schaffung einer Wissensbasis zur entwickelten Software verschrieben haben. Zu diesen Diensten gehört Mutable AI.

Eine Mutable AI-Wiki

Nach Abschluss eines Abonnements ist es möglich zu einem Repository ein automatisches Wiki zur Dokumentation zu erstellen. Neben dieser Art der Dokumentation kann die Codebasis auch über einen KI-Assistenten befragt werden.

Die Dokumentation wird automatisch bei Änderungen des Repositories aktualisiert.

SQLAI.ai

Für die Arbeit mit SQL und Datenbanken existieren eine Reihe von KI-Werkzeugen wie SQLAI.ai. Mithilfe dieser Werkzeuge können Abfragen erzeugt, überprüft und auf Fehler untersucht werden.

SQLAI

Im Wesentlichen generieren die meisten dieser Werkzeuge, häufig unter Einbeziehung zusätzlicher Informationen wie des Datenbankschemas, passende Eingaben für das verwendete Sprachmodell. Zusätzliche Metainformationen wie das Datenbankschema, helfen hierbei sinnvolle Ausgaben für die eigenen Projekte zu erzeugen.

Ein ähnliches Werkzeug ist AI Query, das ebenfalls über Werkzeuge zur SQL-Prüfung und Bearbeitung verfügt. Daneben existieren eine Vielzahl anderer Werkzeuge dieser Art wie TEXT2SQL oder AI2sql.

Über den Tellerrand

Neben all diesen Werkzeugen existieren weitere Ansätze und Möglichkeiten, welche die Entwicklung und Prozesse der Softwareentwicklung vereinfachen sollen.

So existiert mit Stepsize AI ein Werkzeug, welches Sprint Reports im Kontext der agieren Softwareentwicklung erzeugen soll oder mit Bugasura ein Bug-Tracker mit KI-Unterstützung.

Neben kommerziellen Lösungen, welche auf entsprechende Modelle von OpenAI und Co. setzen, existieren auch freie Modelle zur Entwicklung von Software.

Eines dieser Modelle ist PolyCoder, welches auf Basis von GPT-2, mit einem Korpus von über zwölf Programmiersprachen trainiert wurde. Ähnliches vermag CodeGeeX zu leisten, welches aus dem asiatischen Raum stammt.

Allerdings lassen sich diese Systeme nicht so einfach nutzen wie die vorkonfektionierten Angebote, kommerzieller Anbieter. Es muss ein entsprechender Setup-Aufwand geleistet werden, bevor die Modelle genutzt werden können. Darüber hinaus ist die Performanz lokal ausgeführter Modelle, aufgrund der genutzten Hardware, oft unzureichend.

Fazit

Sprachmodelle konnten für die Entwicklung bereits genutzt werden, bevor es spezielle Integrationen dafür gab. Dafür musste der Entwickler Prompts definieren und diese mit dem Quelltext in das Modell geben.

Viele Integrationen nehmen dem Entwickler das Schreiben des Prompts in vielen Fällen ab und ermöglichen so eine schnellere Nutzung der Modelle. Bedingt durch die zugrundeliegenden Sprachmodelle werden viele Programmiersprachen auch von den vorgestellten Werkzeugen unterstützt.

Damit können in der Theorie viele Standardaufgaben, wie die Dokumentation, Unit-Tests oder auch komplexere Dinge wie die Konvertierung zwischen zwei Programmiersprachen mehr oder weniger vereinfacht werden. Allerdings sollten die Ergebnisse dieser KI-basierten Assistenzfunktionen immer bewertet und analysiert werden und nicht einfach ungeprüft übernommen werden. Spätestens bei komplexeren Problemen, welche ein umfassenderes Verständnis über die Codebasis benötigen, versagen die KI-Assistenten in vielen Fällen.

Aktuell existieren auf dem Markt eine unzählige Anzahl von KI-Werkzeugen und jeden Tag werden es mehr. Einige dieser Werkzeuge werden wieder verschwinden, während andere Werkzeuge erhalten bleiben. Auch in Zukunft sollen KI-Assistenten weiter integriert werden, wie in XCode von Apple.

Für Code-Assistenten sowie zahlreiche andere Werkzeuge gilt, dass sie im Wesentlichen auf ähnliche Weise funktionieren: Ein beliebiger Prompt wird erstellt, an ein Sprachmodell übermittelt und von diesem verarbeitet.

Hier stechen am Ende nur Lösungen hervor, welche eine gute Integration bieten und es somit dem Entwickler nicht unnötig schwer machen, die Assistenzfunktionen im Arbeitsalltag anzuwenden.

Positiv haben neben der Integration der JetBrains AI die Codesuche über Bloop überrascht, bei welcher zu einer Codebasis Fragen gestellt werden können und diese Codebasis damit genauer und schneller kennengelernt werden kann.

Neben den praktischen Aspekten sollte auch beachtetet werden, dass ein Großteil der aktuellen KI-Lösungen kostenpflichtig sind und ihren Gegenwert einspielen müssen.

Abgesehen von den monetären Aspekten gilt es auch den Datenschutz zu beachten, schließlich werden in vielen Fällen vertrauliche Daten an Drittservices gesendet und dort verarbeitet.

Daneben ist die Datenbasis prinzipbedingt immer leicht veraltet. So können Informationen zu neuen Versionen einer Software z. B. zur Game Engine Bevy über viele Sprachmodelle nicht bezogen werden, da ihr Trainingsdatum vor dem Erscheinungsdatum der neuen Softwareversion liegt.

Ob sich die Technologie in Zukunft einen wirklichen Mehrwert in der Entwicklung bringt, wird sich zeigen. Gegenwärtig scheint es so, dass sich ein Teil der KI-Werkzeuge sich dem Plateau der Produktivität im Hype-Zyklus nähert.

Bei einer guten und niederschwelligen Integration kann damit vielleicht das ein oder andere KI-basierte Werkzeug seinen Weg in den Werkzeugkasten der Softwareentwicklung finden.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Wetterwarnungen unter iOS aktivieren

Viele Assistenzsysteme wie z.B. Alexa verfügen über die Möglichkeit bei Wetterwarnungen zu informieren. Auch Apple bietet unter iOS diese Funktionalität. Dazu muss im ersten Schritt in den Einstellungen unter Datenschutz & Sicherheit im Punkt Ortungsdienste für die App Wetter die Berechtigung auf Immer gestellt werden.

Die Einstellungen zur Aktivierung der Wetterwarnungen

Anschließend müssen die Warnungen in der Wetter-App aktiviert werden. Dort muss die Wetterliste aufgerufen werden und dort über den Button mit den drei Punkten der Punkt Mitteilungen aufgerufen werden. Anschließend können die Wetterwarnungen für die gewünschten Orte aktiviert werden.

Cookie-Banner im Firefox automatisch ablehnen

Seit einigen Versionen ist es möglich im Firefox Cookie-Banner automatisch abzulehnen. Um dieses Feature zu aktivieren, müssen die Einstellungen geöffnet werden.

Die entsprechende Einstellung im Firefox

Dort findet sich unter Datenschutz & Sicherheit der Punkt Websites anweisen, meine Daten nicht zu verkaufen oder weiterzugeben. Wird dieser aktiviert, werden Cookie-Banner in den meisten Fällen automatisch abgelehnt.

DNS-Technologien im Überblick

Das altehrwürdige Domain Name System ist seit mittlerweile fast vierzig Jahren einer der Grundpfeiler des Internets. Daneben erblicken neue Technologien rund um das DNS das Licht der Welt und entsprechende Unterstützung zieht in die Betriebssysteme ein.

Einleitung

Damit Pakete für das Internetprotokoll in Version 4 und 6 durch das Internet versendet werden können, sind Endpunkte, wie Clients und Server, mit Adressen versehen.

Über diese Adressen können die Dienste eines Servers abgerufen werden, so z. B. der Aufruf einer Webseite. Während IPv4-Adressen wie 192.168.15.15 noch übersichtlich scheinen, sieht es bei IPv6-Adressen wie der Adresse 2001:0db8:3c4d:0015:0000:1507:1503:1a2b anders aus.

Menschen sind nicht sonderlich gut darin, sich Zahlen zu merken, sodass eine andere Adressierung für die entsprechenden Endpunkte geschaffen werden musste. Gelöst wurde das Problem durch das Domain Name System, welches gerne als Telefonbuch des Internets bezeichnet wird.

Damit können Domains wie example.org auf eine entsprechende IP-Adresse abgebildet werden. Durch dieses Mapping vereinfacht sich die Nutzung und Adressierung im Internet.

Hierarchie im System

Wird eine Domain wie example.org aufgerufen, so wird ein DNS-Server abgefragt, der einem daraufhin den Domainnamen zu einer IP-Adresse auflöst.

Das gesamte Domain Name System ist hierarchisch aufgebaut. Auf der obersten Ebene befinden sich die autoritativen Nameserver für die Root-Zone. Diese sind dreizehn an der Zahl und tragen die Namen A bis M. Sie liefern die entsprechende Root-Zone aus, bei welcher es sich um einen knapp 2 MB großen Datenblob handelt.

In diesem enthalten ist eine Liste der autoritativen Nameserver für jede Top-Level-Domain. Damit verweist die Root-Zone auf DNS-Server, welche für einzelne Top-Level-Domains wie .de, .org oder .net zuständig sind.

Die Hierarchie im Domain Name System

Die Nameserver für die einzelnen Top-Level-Domains verweisen für eine angefragte Domain wiederum auf autoritative Nameserver, welche für diese Domain zuständig sind. In der Theorie kann diese Hierarchie mit jeder Ebene einer Domain, wie z. B. Subdomains, fortgesetzt werden.

Autoritative und cachende Nameserver

Besagte autoritative Nameserver sind dafür verantwortlich, verbindliche Aussagen zu einer Zone, wie einer Domäne oder einer ganzen Top-Level-Domain zu treffen. Was der autoritative Nameserver mitteilt, ist die objektive Wahrheit im Domain Name System.

Da es aus Gesichtspunkten wie der Lastverteilung und der Antwortgeschwindigkeit eher unpraktikabel ist, alle Anfragen zu einer bestimmten Zone nur von den autoritativen Nameservern beantwortet zu lassen, existieren cachende Nameserver.

Diese Nameserver, stehen z. B. beim Internet Service Provider und beantworten die DNS-Anfragen der Kunden. Kann eine solche DNS-Anfrage nicht aus dem Cache beantwortet werden, so wird wiederum der autoritative Nameserver angefragt und das Ergebnis für weitere Anfragen im Cache gehalten.

Nach Ablauf der Time to Live (TTL), welche in der Zone definiert ist, wird der Cache invalidiert und bei der nächsten Anfrage wieder der autoritative Nameserver befragt.

Zonen im Detail

In einer Zone können unterschiedlichste sogenannte Resource Records, kurz Records angelegt werden. Eine Zone, welche die entsprechende Konfiguration enthält, könnte wie folgt aussehen:

$ORIGIN example.org.
$TTL 3600
; SOA Records
@		IN	SOA	dns.example.org. 2022061900 86400 10800 3600000 3600
; NS Records
@		IN	NS	ns-1.example.org.
@		IN	NS	ns-2.example.org.
@		IN	NS	ns-3.example.org.
; MX Records
@		IN	MX	10 mail.example.org.
; A Records
@		IN	A	10.1.1.1
; AAAA Records
@		IN	AAAA	2001:db8:123:4567::1
; CNAME Records
api		IN	CNAME	www
www		IN	CNAME	example.org.

In der Zonen-Datei sind eine Reihe von Resource Record-Typen definiert, welche bestimmten Zwecken dienen. Von diesen Typen ist eine größere Anzahl definiert, von denen hier ein auszugsweiser Überblick gegeben werden soll.

A

Der A-Record definiert die IPv4-Adresse des Hosts. Mit diesem wird der Hostname schlussendlich der entsprechenden IPv4-Adresse zugeordnet.

AAAA

Wie beim A-Record ordnet auch der AAAA-Record dem Host eine IP-Adresse zu. In diesem Fall wird allerdings eine IPv6-Adresse zugeordnet.

CNAME

Bei CNAME handelt es sich um die Abkürzung für Canonical Name record. Mit diesem Record kann einer Domain ein weiterer Name zugeordnet werden. Dies kann genutzt werden, um Subdomains wie api.example.org anzulegen.

In einer beispielhaften Konfiguration würde dies dann wie folgt aussehen:

$ORIGIN example.org.
info    IN	CNAME	www
www		IN	A	192.168.1.1
www		IN	AAAA	2a01:4f8:262:5103::1

Hier wird die Subdomain info.example.org per CNAME auf die Subdomain www.example.org verwiesen, welche wiederum per A- und AAAA-Record auf die entsprechenden IP-Adressen des Hosts verweist.

MX

Der MX-Record ist ein wichtiger Record-Typ im Domain Name System, weil er dafür sorgt, dass E-Mails den entsprechenden Empfänger erreichen. Dazu definiert er den entsprechenden Mailserver, welcher für eine Domain zuständig ist:

; MX Records
@		IN	MX	10 mail.example.org.

Damit kann per DNS ermittelt werden, wie der Mailserver erreichbar ist und die entsprechende E-Mail zugestellt werden.

NS

Der NS-Record bzw. die NS-Records definieren die für die Domain zuständigen Nameserver. Bei einem bei Hetzner gehosteten Server, könnte das Ganze wie folgt aussehen:

; NS Records
@		IN	NS	helium.ns.hetzner.de.
@		IN	NS	hydrogen.ns.hetzner.com.
@		IN	NS	oxygen.ns.hetzner.com.

Die dort angegebenen Server sind die autoritativen Nameserver, da die entsprechenden Auskünfte, die diese Server erteilen, für die konfigurierte Domain verbindlich sind.

PTR

Ein PTR-Record, kurz für Pointer record, dient dazu, ein Reverse DNS Lookup zu ermöglichen. Das bedeutet, dass zu einer IP-Adresse der entsprechende DNS-Name ermittelt wird.

Wichtig ist diese Art der Konfiguration unter anderem bei der Bereitstellung von Mailservern.

SOA

SOA-Records, welche ein Kürzel für Start Of Authority darstellen, dienen der Darstellung bestimmter Informationen wie der primären Nameserver oder der Bereitstellung von Informationen, wie der TTL, für andere DNS-Server.

; SOA Records
@		IN	SOA	hydrogen.ns.hetzner.com. dns.hetzner.com. 2022121602 86400 10800 3600000 3600

TXT

Der TXT-Record ist ein relativ universeller Record im Domain Name System, mit welchem maschinenlesbare Daten im DNS hinterlegt werden können:

; TXT Records
@		IN	TXT	"v=spf1 redirect=example.org"

Genutzt wird diese Möglichkeit für unterschiedliche Techniken, wie im E-Mail-System mit DMARC oder dem Sender Policy Framework (SPF).

Probleme im Domain Name System

Das Domain Name System funktioniert in den Grundzügen, so wie es seit 1983 definiert wurde. Allerdings wirft diese Architektur auch einige Probleme auf.

In der klassischen DNS-Variante über UDP oder TCP, findet die komplette Kommunikation unverschlüsselt statt und stellt somit auch aus Sicht des Datenschutzes bzw. der Privatsphäre ein Problem dar.

Daneben sind die DNS-Responses nicht vor Änderungen geschützt und können somit ohne Wissen des Empfängers manipuliert werden.

Auch DDoS-Attacken in Form einer DNS Amplification Attack lassen sich bedingt durch die Gegebenheiten im Domain Name System durchführen. Hierbei wird die Zieladresse mit Datenverkehr von DNS-Servern belastet. Dies funktioniert, da der Angreifer eine DNS-Anfrage mit einer gefälschten IP-Adresse stellt und die Antwort somit beim eigentlichen Ziel der Attacke aufläuft. Der Angreifer benötigt in einem solchen Fall wenig Bandbreite, da die Antwort des DNS-Servers meist wesentlich größer ausfällt, als die Anfrage.

Ein weiteres Problem sind sogenannte Broken Resolvers. Dies ist insbesondere bei einigen Internet Service Providern der Fall, bei denen Dinge wie die TTL, also die Gültigkeit einer DNS-Antwort nicht berücksichtigt werden. Daneben existieren auch solche Resolver, die bei nicht vorhanden Domains nicht mit NXDOMAIN antworten, sondern stattdessen auf eine eigene Webseite umleiten.

Dieses Problem kann schon mit dem ursprünglichen Domain Name System verhindert, werden, indem alternative DNS-Server genutzt werden. Grundsätzlich erschweren solche Broken Resolvers die Fehlerfindung und beeinflussen die Funktionalität des Domain Name System.

Eine Fehlermeldung in Chrome, welche auf Probleme mit der DNS-Konfiguration hinweist

Interessant ist hier die Unterstützung durch Browser, wie Chrome, welcher bei Inkonsistenzen mit dem DNS-Server entsprechende Hinweise in Form einer spezifischen Fehlermeldung gibt.

Verbesserungen am System

Die Schwächen des Domain Name Systems sind nicht unberücksichtigt geblieben und so gab es im Laufe der Zeit immer wieder Verbesserungen, um das eine oder andere Problem zu beseitigen und das Domain Name System zu verbessern.

Dies fing schon in der Frühzeit des DNS an, als neben der ursprünglichen Möglichkeit per UDP Anfragen zu stellen, dies auch per TCP abgewickelt werden sollte. Hintergrund war es hier unter anderem DNS-Responses, welche größer als 512 Byte sind, versenden zu können.

Daneben wurde zur Erweiterung der DNS-Responses über UDP der Extension Mechanismus for DNS, kurz EDNS, definiert. Über diesen Mechanismus ist es möglich, mehr als 512 Byte per UDP zu übertragen. Genutzt wird dies unter anderem bei DNSSEC.

Bei der gewöhnlichen Nutzung wird in den meisten Fällen, aufgrund des geringeren Overheads, UDP genutzt. Nur in Fällen, in denen z. B. größere Datenmengen im Spiel sind, wird TCP genutzt.

TSIG und DNSSEC

Eine Sicherheitstechnologie in Bezug auf DNS ist TSIG, welches mit der RFC 2845 spezifiziert wurde. Das Kürzel steht für Transaction Signatures und ist ein Verfahren zur Absicherung von DNS-Updates z. B. bei dynamischem DNS.

Eine weitere Erweiterung des DNS sind die Domain Name System Security Extensions kurz DNSSEC. Mittels DNSSEC soll die Authentizität und Integrität von DNS-Daten gewährleistet werden.

Das bedeutet bei DNSSEC, dass die Übertragung selbst nicht verschlüsselt ist, sondern nur sichergestellt wird, dass die enthaltenden Daten korrekt und unverändert sind. Die Verbreitung von DNSSEC hat dabei in den vergangenen Jahren zugenommen.

Technologien für neue Anforderungen

Während Technologien wie DNSSEC und TSIG, bestimmte Anwendungszwecke im Auge haben, ist das Bewusstsein für Datenschutz und Privatsphäre im Laufe der letzten Jahre und Jahrzehnte gewachsen, sodass Lösungen entwickelt wurden, welche unverschlüsseltes DNS ersetzen oder ergänzen sollen.

Die neu entwickelten Protokolle und Technologien, welche in den vergangenen Jahren entwickelt wurden, hören auf so illustre Kürzel wie DoT, DoH oder DoQ.

Die unterschiedlichen DNS-Varianten im Laufe der Zeit

Interessant ist hier ein kurzer Rückblick auf die Geschichte des DNS-Protokolls. Als dieses ursprünglich zum Einsatz kam, setzte das Protokoll auf UDP auf, sodass die erste DNS-Version als DNS over UDP bezeichnet werden kann.

Mit der RFC 1123 aus dem Jahre 1989 wurde schließlich begonnen TCP für DNS-Anfragen zu nutzen, sodass DNS over TCP geboren war. Sowohl die UDP als auch die TCP Variante nutzen den Port 53.

DNS over TLS

DNS over TLS, kurz DoT, wurde im Mai 2016 im Rahmen der RFC 7858 standardisiert und wird genutzt, um DNS-Abfragen mittels TLS zu verschlüsseln. Es handelt sich hierbei nur um eine Transport- und um keine Ende-zu-Ende-Verschlüsselung.

DNS über TLS

Bei DoT wird zu dem DNS-Server eine Verbindung über TCP aufgebaut und diese mittels TLS abgesichert. Bedingt durch die Transportverschlüsselung können die DNS-Einträge nicht mehr zwischen den Knoten manipuliert werden. Der standardmäßig vorgesehene Port für DoT ist 853.

Wie auch bei DNS over HTTPS, werden bei dieser Variante DNS-Verstärkungsangriffe weitestgehend unterbunden.

Gegenüber unverschlüsseltem DNS erzeugt die Verschlüsslung per TLS einen gewissen Overhead, welcher sich auf die Geschwindigkeit der DNS-Anfrage auswirkt.

Im Gegensatz zu DNS über HTTPS soll diese Variante in der Praxis schneller sein. Allerdings gibt es je nach Implementierung unter Umständen Probleme, die meist von einem nicht korrekt implementierten Standard herrühren.

Bedingt durch den fest definierten Standardport für DoT (853), lässt sich dieses Protokoll relativ einfach blockieren. In einem solchen Fall kann auf andere DNS-Protokolle geschwenkt oder alternativ auf unverschlüsseltes DNS gesetzt werden.

DNS over HTTPS

Eine weitere Variante, welche ähnlich dem DNS over TLS funktioniert, ist DNS over HTTPS. Dieses wurde in der RFC 8484 standardisiert.

DNS über HTTPS

DoH läuft über den gleichen Port, wie gewöhnliches HTTPS, den Port 443. Damit kann von Außen keine Unterscheidung getroffen werden, ob es sich um DNS-Anfragen oder normalen HTTPS-Datenverkehr handeln.

Der Grund hierfür ist darin zu suchen, dass der Datenverkehr bzw. die Informationen der DNS-Abfrage über das Hypertext Transfer Protocol gesendet werden.

Damit wird eine Blockierung entsprechender DNS-Abfragen über dieses Verfahren erschwert. Allerdings leidet auch hier wieder die Performanz im Vergleich zu gewöhnlichem unverschlüsselten DNS.

Eine Spielart von DNS over HTTPS ist das relativ neue DNS-over-HTTP/3 kurz DoH3, welches wie HTTP/3 als Transportprotokoll QUIC anstatt von TCP nutzt. Dies darf allerdings nicht mit DNS over QUIC verwechselt werden.

DNS over QUIC

Zu den neueren Ideen bzw. Technologien bei der DNS-Abfrage gehört DNS over QUIC. Ziel von DoQ ist es, die Latenzen zu verringern, bei gleichzeitiger Nutzung einer verschlüsselten Verbindung.

DNS über QUIC

Definiert ist DoQ in der RFC 9250. Grundlage für das Protokoll ist QUIC, welches als Transportschicht TCP ersetzt und in dieser Form auch bei HTTP/3 genutzt wird.

Ziel von DoQ ist, dass dieses Protokoll auch für autoritative Nameserver verwendet werden kann. Damit soll eine möglichst breite Anzahl an Nutzungsmöglichkeiten im Zusammenhang, mit dem Domain Name System abgebildet werden können.

Da DoQ über den zugewiesenen Port 853 läuft, ist auch hier technisch gesehen eine einfache Blockierung möglich. Allerdings definiert die RFC hier im Abschnitt Port Selection:

In the stub to recursive scenario, the use of port 443 as a mutually agreed alternative port can be operationally beneficial, since port 443 is used by many services using QUIC and HTTP-3 and is thus less likely to be blocked than other ports

Unterstützung auf Serverseite

Damit DNS-Dienste, über welche Protokolle auch immer, im Internet genutzt werden können, muss die entsprechende Server-Software die gewünschten Protokolle unterstützen.

Neben BIND, dem Platzhirsch unter den DNS-Server, existieren noch weitere DNS-Server von denen bezüglich ihrer Fähigkeiten noch Unbound und der Windows Server kurz beleuchtet werden sollen.

DNS over TLS DNS over HTTPS DNS over QUIC
BIND ab Version 9.17 ab Version 9.17 –
Unbound ab Version 1.7.3 ab Version 1.12.0 –
Windows Server (DNS) – ab Windows Server 2022 –

Bei BIND zogen mit der Version 9.17, welche im Jahr 2020 erschien, der Support für DoT und DoH (in einer experimentellen Version) ein. Eine Unterstützung für DNS over QUIC, steht im Moment noch aus.

Unbound liefert seit der im Juni 2018 erschienen Version 1.7.3 eine Unterstützung für DNS over TLS aus. Mit der im Oktober 2020 erschienen Version 1.12.0 wurde die Unterstützung für DNS over HTTPS implementiert. An der Umsetzung von DNS over QUIC in Unbound wird im Moment noch gearbeitet.

Ab dem Windows Server 2022 wird DNS over HTTPS offiziell unterstützt. Bei DNS over TLS und DNS over QUIC ist bisher keine Unterstützung im Windows Server vorhanden.

Linux

Neben der Unterstützung auf Serverseite ist auch die Unterstützung auf Client-Seite, in Form von Betriebssystemen auf dem Desktop, als auch im Bereich der mobilen Betriebssysteme wichtig.

In den meisten Linux-Distributionen, welche Systemd nutzen, kann dies über systemd-resolved erledigt werden. Dieser unterstützt ab der Version 239 opportunistisches DNS over TLS und ab der Version 243 striktes DNS over TLS.

Hier kann z. B. unter Ubuntu in der Konsole die entsprechende Konfigurationsdatei editiert werden:

nano /etc/systemd/resolved.conf

Dort sollte die Einstellung:

DNSOverTLS=yes

hinzugefügt werden. Anschließend können über den normalen Netzwerkdialog, DoT-fähige DNS-Server eingetragen werden:

9.9.9.9, 149.112.112.112

In diesem Fall sind es die DNS-Server von Quad9. Anschließend laufen die DNS-Abfragen per DoT über die gewählten DNS-Server.

macOS

Seit macOS 11, welches mit dem Namen Big Sur auf den Markt kam, unterstützt macOS neben DNS over TLS auch DNS over HTTPS.

Aktiviert werden können die gewünschten Einstellungen über Konfigurationsprofile. Dazu muss ein entsprechendes Profil heruntergeladen und anschließend installiert werden.

Das Profil unter macOS

Die Konfigurationsprofile befinden sich in den Systemeinstellungen unter macOS. Nach der Aktivierung kann über das Terminal überprüft werden, ob die entsprechenden Einstellungen aktiv sind:

sudo tcpdump -i any "port 853 and host 9.9.9.9 or host 149.112.112.112"

Bei der Nutzung von DoH sollte der Port im Befehl auf 443 geändert werden. Nachdem der Befehl abgesetzt wurde, sollte Netzwerkverkehr zu dem Quad9-DNS-Server im Dump auftauchen.

Windows

Unter Windows 10 wird, seit dem Build 19628, DNS over HTTPS unterstützt. Dazu muss in der Registry der Pfad:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters

aufgerufen werden und dort ein Parameter vom Typ DWORD erstellt werden. Dieser trägt den Namen EnableAutoDoh sowie den Wert 2. Anschließend sollte ein Neustart des Rechners durchgeführt werden.

Die Einstellungen im Registrierungs-Editor

Nun können in den Einstellungen für den jeweiligen Netzwerkadapter die passenden DNS-Server mit einer entsprechenden Unterstützung für DoH eingestellt werden:

9.9.9.9, 149.112.112.112

Unter Windows 11 können die Einstellungen für DoH bequem über die Netzwerkeinstellungen eingestellt werden, nachdem dort die passenden DNS-Server hinterlegt sind, kann dort unter DNS over HTTPS das Feature aktiviert werden.

Neben DoH unterstützt Windows 11 auch DNS over TLS. Dazu werden in den Netzwerkeinstellungen die entsprechenden DNS-Server hinterlegt und das DNS over HTTPS-Feature deaktiviert.

Nun muss die Kommandozeile geöffnet werden und dort müssen die Befehle:

netsh dns add global dot=yes​
netsh dns add encryption server=9.9.9.9 dothost=: autoupgrade=yes
netsh dns add encryption server=149.112.112.112 dothost=: autoupgrade=yes

eingegeben werden. Das Kommando:

netsh dns add encryption

muss hierbei für jeden DNS-Server für die IPv4- und IPv6-Adresse wiederholt werden. Abgeschlossen wird das Prozedere mittels:

ipconfig /flushdns
netsh dns show global

Der letztere Befehl zeigt an, ob die Einstellungen für DNS over TLS aktiviert wurden. DNS over QUIC wird unter Windows vom System selbst bisher noch nicht unterstützt.

Android

Während seit Android 9 (Pie) DNS over TLS bereits verfügbar ist, ist DNS over HTTPS ab Android 11 enthalten und teilweise auch auf einigen Geräten mit Android 10 verfügbar.

Die teilweise Verfügbarkeit unter Android 10 erklärt sich dadurch, dass das entsprechende DNS Resolver Modul unter Android 10 noch optional, aber unter Android 11 verpflichtend zum System dazu gehört. Installiert werden diese Änderungen über ein Google Play-Systemupdate.

In den Einstellungen kann DoT bzw. DoH aktiviert werden

Zur Aktivierung unter Android genügt es in den Systemeinstellungen, die Netzwerkeinstellungen aufzurufen und dort im Punkt Privates DNS, die entsprechenden DNS-Server zu hinterlegen. Hierbei wird, je nach Android-Version, DNS over HTTPS (in der Variante DoH3) gegenüber DNS over TLS bevorzugt, zumindest bei den dem System bekannten DNS-Servern.

iOS

Seit iOS 14, also knapp 2 Jahre später als unter Android, zog in iOS die Unterstützung für DNS over TLS ein. Ebenfalls ab iOS 14 wird DNS over HTTPS unterstützt.

Wie unter macOS, kann die Einstellung über entsprechende Konfigurationsprofile vorgenommen werden. Dazu muss ein Profil auf dem iOS-Gerät heruntergeladen und installiert werden.

Die Installation des Profils erfolgt über die Einstellungen unter iOS

Nachdem das Profil bestätigt und installiert worden ist, wird der DNS-Server in der im Profil hinterlegten Konfiguration genutzt.

Unter iOS existiert die Besonderheit, dass DNS-Abfragen für den Appstore und die Terminalbefehle dig und nslookup per Design nicht über die im Profil hinterlegten DNS-Server abgefragt werden.

Das Profil kommt nicht immer zur Anwendung

Auch gelten die Einstellungen nicht, wenn z. B. iCloud Privat Relay oder eine VPN-Verbindung aktiv sind.

Browser

Neben der betriebssystemseitigen Unterstützung liefern auch die meisten Browser mittlerweile eine Unterstützung für DNS over HTTPS aus. Diese Unterstützung ist unabhängig vom darunterliegenden Betriebssystem.

Die Einstellungen für DNS over HTTPS im Firefox

Im Firefox kann DNS over HTTPS in den Einstellungen unter Allgemein und dort in den Verbindungs-Einstellungen aktiviert werden. Dort kann dann der Punkt DNS über HTTPS aktiviert mitsamt eines Servers ausgewählt werden.

Die Einstellungen zu DoH unter Chrome

Unter Chrome kann DoH über die Einstellungen unter dem Punkt Datenschutz und Sicherheit aktiviert werden. Dort findet sich unter dem Unterpunkt Sicherheit der Punkt Sicheres DNS verwenden.

Router

Auch Router bieten in vielen Fällen Funktionalitäten zur besseren Absicherung von DNS-Abfragen.

So können in der FRITZ!Box entsprechende DNS-Server, welche DoT unterstützen hinterlegt werden. Auf Wunsch kann die FRITZ!Box auch einen Fallback auf unverschlüsseltes DNS durchführen, falls die entsprechenden DoT-Server nicht erreicht werden können. Dies kann zum Beispiel durch entsprechende Firewalls oder beim technischen Ausfall der Server passieren.

Andere Verfahren

Neben den oben beschriebenen Varianten existieren noch weitere DNS-Varianten wie Oblivious DNS bzw. Oblivious DoH, DNS over TOR und DNSCrypt, welche allerdings im weiträumigen Praxiseinsatz eher seltener zu finden sind.

Nachteile der neuen Lösungen

Bei den neuen Lösungen, wie DoT, DoH und DNS over QUIC, existieren eine Reihe von Problemen bzw. Kritikpunkten.

Viele beziehen sich dabei auf gewünschte Eigenschaften der Verfahren, wie die Verschlüsselung, welche es unter anderem erschwert, den DNS-Verkehr zu überwachen. Genutzt wird eine solche Überwachung z. B. in Kinderschutzsoftware, oder im geschäftlichen Umfeld, um den Netzwerkverkehr zu überwachen und entsprechende Policen durchzusetzen.

Je nach Lösung wird dann versucht, die neueren Verfahren zu deaktivieren bzw. dessen Nutzung nicht zuzulassen oder aber eigene Server für die entsprechenden Protokolle zu betreiben, welche wiederum die entsprechen Sperrmöglichkeiten anbieten.

Auch sind die, bei den Verfahren wie DoT oder DoH genutzten, meist zentralen DNS-Server von Google, Cloudflare oder Quad9 ein Problem, da sich dort ein Großteil des DNS-Verkehrs sammelt und dies Begehrlichkeiten wecken oder der Profilbildung dienen kann.

Daneben sollte beachtet werden, dass je nach Implementation bzw. Betriebssystem die Nutzung der verschlüsselten DNS-Varianten nicht immer garantiert ist. Sei es durch ungewollte Downgrades auf unverschlüsseltes DNS oder aber Applikationen wie der Appstore unter iOS, welcher von den DNS-Einstellungen des Systems unabhängig funktioniert. Daneben gibt es in bestimmten Versionen von Android den Fall, dass die Private-DNS-Einstellungen nach dem Aufwachen des Gerätes erst wieder nach einigen Sekunden angewendet werden.

Fazit

DNS-Abfragen müssen heute nicht mehr unverschlüsselt erfolgen, da es eine Reihe von neuen Ideen und Transportprotokollen gibt, welche neben der jeweiligen Vorteile teilweise auch spezifische Nachteile haben.

Mittlerweile findet sich für die Verfahren DNS over TLS und DNS over HTTPS eine breitere Unterstützung in den Betriebssystemen. Dort, wo diese noch nicht verfügbar ist, kann auf DNS-Proxies oder im Spezialfall Browser auf dessen Möglichkeiten zurückgegriffen werden.

DNS over TLS DNS over HTTPS DNS over QUIC
Linux über systemd-resolved (ab Version 239 bzw. 243) – –
macOS ab macOS 11 (Big Sur) ab macOS 11 (Big Sur) –
Windows ab Windows 11 (Build 25158) ab Windows 10 (Build 19628), Windows 11 –
Android ab Android 9 (Pie) ab Android 11 –
iOS ab iOS 14 ab iOS 14 –

Neben der gewöhnlichen DNS Auflösung haben aktuell vorwiegend die Technologien DoT und DoH eine größere Verbreitung erlangt. Spannend wird in Zukunft auch die Entwicklung von DoQ, welches zumindest das Potenzial hat, bestehende Technologien rundum DNS-Abfragen abzulösen.

Allerdings stellt sich bei vielen dieser Protokolle die Frage, welchen DNS-Servern vertraut werden soll, denn das bestehende DNS-System ist ein dezentrales System ohne übermächtige Gatekeeper, während bei Diensten wie DoT und DoH eine Zentralisierung zu beobachten ist.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Matter im Überblick

Im Laufe der letzten Jahre und Jahrzehnte sind einige Smart Home-Standards auf den Markt gekommen. Mit Matter ist nun ein neuer Standard angetreten, welcher den Smart Home-Markt aufrollen möchte.

Doch abseits der für den Endnutzer gedachten Versprechen, welche Vorteile er bringen soll, wird erstaunlich wenig über die technischen Hintergründe gesprochen.

Allerdings helfen diese Hintergründe Matter und seine Möglichkeiten zu verstehen. In diesem Artikel sollen die Hintergründe von Matter beleuchtet und gezeigt werden, wie Matter abseits der Marketingversprechen funktioniert.

Bestehende Standards

Matter ist beileibe nicht der erste Standard, welcher sich mit dem Thema Smart Home beschäftigt. Vor ihm gab und gibt es Standards wie Z-Wave, EnOcean und Zigbee. Letzterer spielt bei Matter organisatorisch eine besondere Rolle.

Je nach Standard werden unterschiedlichste Technologien und Funksysteme genutzt, wie das vermaschte Netzwerk, welches Z-Wave-Geräte untereinander aufbauen.

Das Problem an diesen Systemen ist, dass sie meist zueinander inkompatibel sind. Über Lösungen wie Home Assistant oder Homee können diese unterschiedlichen Systeme zur Zusammenarbeit gebracht werden.

Allerdings wird auch hier in vielen Fällen nur eine begrenzte Anzahl an Hardware unterstützt. Eine allumfassende Lösung stellt dies meist nicht dar.

Auch ins heimische Funknetz eingebundene Geräte werden gerne für die Smart Home-Anwendungen genutzt, welche auch durch ihren günstigen Preis bestechen können.

Aus Sicht von Entwickler sind unterschiedlichste Standards ein Problem. Je nach Firmengröße kann sich nur für einen Standard entschieden werden, da zusätzlich zu unterstützende Standards mehr Entwicklungsaufwand und damit am Ende mehr Kosten bedeuten.

Daneben sind die unterschiedlichen Standards zwar mehr oder weniger gleichwertig, allerdings gibt es eine gewisse Fragmentierung bei den Geräteklassen, so sind Leuchtmittel vorwiegend mit dem Zigbee-Standard verheiratet oder werden über teils obskure Wi-Fi-Lösungen angebunden.

Zwar existieren auch Beleuchtungslösungen für Z-Wave, allerdings sind diese in ihrer Auswahl beschränkt und der Preis ist in vielen Fällen höher als bei den Zigbee-Varianten.

Es gibt es Hersteller, welche mehrere Systeme unterstützen und die gleichen Produkte wie schaltbare Steckdosen in unterschiedlichen Varianten, je nach Smart Home-System, anbieten.

Für den Kunden bedeutet diese Auswahl und die damit verbundenen Probleme wie die Berücksichtigung der Kompatibilität, dass er meist zögerlich zu Smart Home-Produkten greift. Aus Sicht der Hersteller und der Kunden ist dies eine suboptimale Situation: voneinander abgeschirmte Ökosysteme und Geräte, die nur unter Umständen miteinander genutzt werden können.

Smart Home-Markt

Für das Jahr 2022 wird von einem Umsatz im Smart Home-Markt von über einhundert Milliarden Euro ausgegangen.

Allerdings bedingt durch die Fragmentierung des Marktes, entspricht dieser Umsatz nicht dem, der vor einigen Jahren erwartet wurde. So wurde unter anderem von einer höheren Durchdringung des Marktes ausgegangen.

Aktuell nutzen knapp 15 % aller Haushalte, weltweit gesehen, Smart Home-Technik in ihrem Haus oder ihrer Wohnung. Bedingt durch die Vorteile, welche Matter bieten soll und die damit einhergehende Vereinheitlichung, soll dem Smart Home-Markt neues Leben eingehaucht werden.

Das Matter-Versprechen

Matter will die bestehenden Probleme anderer Standards lösen. Der Standard sieht sich als Smart Home-Interoperabilitätsprotokoll und definiert sich als Anwendungsschicht, welche existierende Protokolle wie Thread und Wi-Fi nutzt, um seine Aufgabe, eine Smart Home-Umgebung darzustellen und zu verwalten, zu erfüllen.

Im Grundsatz geht es darum, dass der neue Standard unabhängig von den einzelnen Herstellern sein soll. Auch soll es jedem Hersteller von Hardware möglich sein, den neuen Standard zu implementieren.

Dem Endnutzer wird die Kompatibilität, aller Matter-Geräte untereinander, versprochen. Daneben soll in Zukunft auf proprietäre Bridges und Hubs, welche zur Anbindung bestimmter Systeme genutzt werden, verzichtet werden können.

Eine weitere wichtige Eigenschaft von Matter ist, dass die Steuerung zwar in der Theorie an Cloud-Systeme angebunden werden kann, aber immer lokal funktionieren muss.

Aus Sicht des Datenschutzes und der Betriebssicherheit ist dies eine erfreuliche Entwicklung, da Steuersignale nun nicht mehr die halbe Welt umrunden müssen, bevor sie wieder im eigenen Zuhause ankommen. Auch die Zuverlässigkeit stärkt dies in der Theorie, da auch beim Wegfall der Internetverbindung das eigene Smart Home noch funktioniert.

Für die Einrichtung von Matter-Geräten werden nicht mehr unbedingt die Third-Party-Apps der jeweiligen Hersteller benötigt, sondern diese können zentral über Apps z. B. der Home-App unter iOS hinzugefügt werden.

Connectivity Standards Alliance

Organisatorisch wird der Matter-Standard von der Connectivity Standards Alliance (CSA) betreut. Diese ging aus der Zigbee Alliance, welche 2002 gegründet wurde, hervor, welche sich für den gleichnamigen Zigbee-Standard verantwortlich zeichnet.

Mittlerweile sind über 500 Firmen unter dem Dach der Connectivity Standards Alliance vereint. Dazu gehören Unternehmen wie Amazon, Apple, Comcast, Google, IKEA, Infineon, LG, Nordic Semiconductor und Samsung.

Von der Idee zum Standard

Erste Lebenszeichen des Matter-Standards gab es im Dezember 2019. Damals kündigten unter anderem Amazon, Apple und Samsung sowie die Zigbee Aliance an, dass eine Zusammenarbeit für das Projekt Connected Home over IP beschlossen wurde.

Knapp anderthalb Jahre nach der ersten Ankündigung wurde aus Connected Home over IP schließlich Matter. Im gleichen Zuge wurde durch eine Umbenennung aus der Zigbee Alliance die Connectivity Standards Alliance.

Nach etwa drei Jahren Zeit der Planung und Entwicklung erschien im Oktober 2022 mit der Version 1.0 die erste Iteration des Standards. Hier wurden neben der eigentlichen Standardbeschreibung unterschiedliche Produktkategorien wie Beleuchtungslösungen, Sicherheitssensorik, Thermostate, Türschlösser und einige andere spezifiziert.

Während der Entwicklung gab es bedingt durch Faktoren wie die Coronapandemie und Verzögerungen bei den Gerätetests einige Verschiebungen, welche dann schlussendlich zum Veröffentlichungstermin im Oktober 2022 führten. Im November 2022 wurde Matter offiziell auf einem Launch-Event in Amsterdam vorgestellt.

In der nächsten Iteration des Standards, der Version 2.0, welche im März bzw. April 2024 erscheinen soll, sollen unter anderem die unterstützten Geräte um Klassen wie Staubsauger-Roboter, Rauchmelder, Kameras und einige andere erweitert werden.

Architektur

Aus architektonischer Sicht betrachtet ist Matter ein Applikationsprotokoll, welches auf bestehenden Technologien aufsetzt. Grundlage für das Matter-Protokoll bildet IPv6.

Matter setzt als Applikationsprotokoll auf vorhandenen Technologien auf

Der Matter-Protokollstack selbst besteht aus unterschiedlichsten Schichten, welche jeweils bestimmte fachliche Anforderungen erfüllen.

Die Schichten des Matter-Protokollstack

Die Anwendungsschicht (Application Layer) innerhalb des Matter-Protokollstacks implementiert die dem Gerät eigene Businesslogik. Im Falle einer schaltbaren Steckdose wäre dies die Logik, um das Gerät ein- und auszuschalten. Aktionen in der Anwendungsschicht führen zur Änderung im Datenmodell (Data Model).

Im Datenmodell werden die Daten für das entsprechende Gerät gehalten, z. B. ob das Gerät aktuell angeschaltet ist oder bei einem Leuchtmittel, die aktuell ausgewählte Leuchtfarbe.

Für die Interaktion von Außen werden im Interaction Model bestimmte Interaktionen definiert, welche von Außen geschrieben oder gelesen werden können. Eine solche Interaktion löst dann eine Logik in der Anwendungsschicht des Gerätes aus, um die entsprechenden Aktionen auszulösen.

Über das Interaction Modell kann eine Aktion definiert werden und über die Action Framing-Schicht wird sie schließlich in ein binäres Format serialisiert und dieses an die Security-Schicht übergeben.

In dieser wird die Nachricht verschlüsselt und ein Message Authentication Code angehangen. Damit soll sichergestellt werden, dass die Daten sicher und verschlüsselt zwischen den Instanzen bzw. Geräten übertragen werden.

Damit sind die Daten für die Nachricht serialisiert, verschlüsselt und kryptografisch signiert und werden an die Message Framing-Schicht übergeben, in welcher die endgültige Payload, welche schlussendlich über das Netzwerk verschickt wird, erzeugt wird. In Rahmen dieses Prozesses werden Headerfelder ergänzt, welche unter anderem Routing-Informationen enthalten können.

Anschließend wird das Ganze an die Transportschicht übergeben und findet so seinen Weg durch das Netzwerk, bis es beim definierten Empfänger ankommt. Dort angekommen wird der Matter-Protokollstack in umgekehrter Reihenfolge durchlaufen, bis schlussendlich wieder die eigentliche Nachricht in der Anwendungsschicht verarbeitet werden kann.

Fabric, Nodes und Controller

Im Matter-Standard werden einige Begriffe definiert, deren Wissen um die Bedeutung ein Verständnis des Standards erleichtert.

Ein zentraler Begriff im Matter-Standard ist die Fabric. Bei einer Fabric handelt es sich um einen logischen Verbund von Knoten (Nodes), welche eine gemeinsame Vertrauensbasis (Common Root of Trust) und einen gemeinsamen verteilten Konfigurationsstatus besitzen.

Ein Knoten (Node) ist im Matter-Standard definiert als eine Entität, welche den Matter Protokollstack unterstützt und nach der Kommissionierung über eine Operational Node ID und Node Operational Credentials verfügt.

Eine schaltbare Steckdose

Dabei ist ein Node nicht unbedingt gleichzusetzen mit einem Gerät. Ein Gerät, wie eine schaltbare Steckdose kann in der Theorie mehrere Knoten beinhalten, welche wiederum zu mehreren Fabrics gehören können.

Daneben gibt es im Matter-Standard den Begriff des Controllers. Dieser ist definiert als ein Matter-Knoten, welcher die Berechtigung hat einen oder mehrere Knoten zu kontrollieren. Dies kann z. B. das Smart Home-System sein oder ein iPhone mit der entsprechenden Home-App. Matter unterstützt per Design unterschiedlichste Controller in einem Matter-Netzwerk. Dieses Feature wird als Multi-Admin bezeichnet.

Kerntechnologien

Für Matter-Netzwerke, sind einige Kerntechnologien definiert, welche im Rahmen des Standards genutzt werden.

Für die Kommunikation der Geräte untereinander wird Wi-Fi, Ethernet oder Thread benutzt, für die Kommissionierung Bluetooth LE.

Bluetooth LE

Bluetooth LE wird im Matter-Standard genutzt, allerdings nicht für die Kommunikation der Geräte untereinander. Stattdessen wird Bluetooth LE für Kommissionierung (commission, im Matter-Standard) der Geräte genutzt.

Nach der Definition des Matter-Standards wird bei der Kommissionierung ein Node in die Fabric eingebracht, also das Gerät dem Matter-Netzwerk hinzugefügt.

Im Rahmen dessen werden die Zugangsdaten des Netzwerkes und andere für die Kommissionierung benötigten Informationen auf das Gerät übertragen.

Im Anwendungsfall würde dies so aussehen, dass der Nutzer einen QR-Code scannt, welcher die Informationen über das Gerät enthält und anschließend die Kommissionierung mittels Bluetooth LE durchgeführt wird.

Diese Informationen müssen nicht unbedingt als QR-Code geliefert werden. In der Theorie kann auch NFC als Technologie benutzt werden oder die enthaltenen Informationen einfach als kodierte Zeichenkette auf dem Gerät aufgedruckt sein oder dem Handbuch beiliegen.

Dies ermöglicht eine einfache Konfiguration und Einbindung der Geräte aus Sicht des Endbenutzers. Ist die Kommissionierung abgeschlossen und das Gerät damit in das Matter-Netzwerk eingebunden, nutzt das Gerät Bluetooth LE nicht mehr.

Anbindung der Smart Home-Geräte

In den meisten praxisnahen Fällen wird die Anbindung von Geräten meist auf die Anbindung per Thread und Wi-Fi hinauslaufen. Bei Wi-Fi im Heimbereich sind alle Geräte mehrheitlich mit einem Access Point verbunden. Bei Thread hingegen handelt es sich um ein vermaschtes Netz, welche über Border-Router mit dem Rest des Netzwerkes verbunden ist.

Thread

In einem Smart Home sind eine Reihe von Aktoren, wie schaltbare Steckdosen und Ähnliches verbaut. Daneben gibt es dann noch Sensorik, z. B. in Form von Temperatur- und Bewegungssensoren.

Sensoren, wie Temperatur oder Bewegungssensoren, laufen mehrheitlich mit Batteriestrom und eignen sich damit nicht für energieintensive Techniken wie Wi-Fi, um ihre Daten von A nach B zu transportieren.

Ein batteriebetriebener Sensor

Hier kommt das Protokoll Thread ins Spiel. Dieses ist darauf ausgelegt, Geräte miteinander zu verbinden, welche eine geringe Datenrate benötigen und möglichst wenig Energie verbrauchen sollen. Das Protokoll besticht durch sein simples Design und ermöglicht geringe Latenzen.

Das Netzwerkprotokoll Thread versteht sich als selbstheilendes Mesh-Netzwerk. Ein Designziel war es unter anderem, dass es keinen Single Point of Failure in einem solchen Netzwerk geben soll, die Übertragung zuverlässig und die Reichweite durch das Routing innerhalb des Thread-Netzwerkes gegeben ist.

Im Rahmen von Matter sollen hunderte bis tausende Produkte über Thread in einem Netzwerk unterstützt werden.

Entwickelt wird das Protokoll seit 2014 von der Thread Group welcher unter anderem ARM Limited, Nest Labs, Samsung und Qualcomm angehören. Die Entwicklung ist seit dem nicht stehen geblieben und so wurden mit Thread 1.3 Funktionalitäten wie vollumfängliches IP-Routing und Service-Discovery hinzugefügt. Diese Funktionalitäten werden für die Nutzung von Thread im Zusammenhang mit Matter benötigt.

Thread setzt auf IEEE 802.15.4 auf, bei welchem es sich um ein Standard für kabellose Netzwerke mit geringen Datenraten handelt. In IEEE 802.15.4 ist die Bitübertragungsschicht (Physical Layer) und die Data-Link-Schicht definiert.

Neben Thread setzt unter anderem auch Zigbee auf IEEE 802.15.4 auf, was ein Update solcher Geräte, hin zu Thread, perspektivisch möglich macht.

Das OSI-Modell

Darüberliegende Schichten, welche z. B. das Routing übernehmen können, müssen dann von anderen Protokollen übernommen werden. An dieser Stelle setzt Thread ein.

Per Thread angebundene Geräte können per IPv6 adressiert werden. Wichtig ist es festzuhalten, dass es sich bei Thread nicht um Matter handelt, sondern Thread ein eigenständiges Funkprotokoll ist, welches wie Wi-Fi der Anwendungsschicht agnostisch gegenübersteht.

Rollenspiele

Bei Thread kann jedes Gerät unterschiedliche Rollen annehmen. So gibt es in einem Thread-Netzwerk, einen Leader, einen oder mehrere Router und die Rolle des Endgerätes.

Jedem Gerät wird mindestens die Rolle des Endgeräts zugewiesen. Das sind solche Geräte, welche einen Befehl in Form eines Datenpaketes erhalten, um diesen auszuführen.

Ein Leader ist eine Rolle, welche nur einmal vergeben wird. Dieser koordiniert das Thread-Netzwerk. Fällt ein Leader aus, so wird automatisch ein neuer Leader bestimmt. Dazu ist es notwendig, dass jederzeit andere Geräte für den bestehenden Leader einspringen können. Die Zustandsinformationen müssen also im Netzwerk aktuell gehalten werden.

Router, leiten Datenpakete im Thread-Netzwerk weiter. Diese Rolle wird dynamisch von den jeweiligen Geräten aktiviert bzw. wieder deaktiviert, wenn z. B. zu viele Router in der Umgebung unterwegs sind. Daneben bieten die Router Funktionalität, wie Security Services, für andere Geräte, die dem Netzwerk beitreten wollen.

Normalerweise nehmen Thread-Geräte nur die Rolle als Endgerät wahr. Wird mehr Reichweite im Netzwerk benötigt, werden einige dieser Geräte automatisch Router in diesem. Das passiert z. B. dann, wenn ein Endgerät keinen Router findet, aber ein Endgerät in der Theorie eine solche Rolle einnehmen kann.

Auf der anderen Seite funktioniert dies auch, wenn sich zu viele Router in einem Bereich befinden und damit zu viel Redundanz vorhanden ist. In diesem Fall stufen sich Geräte in wieder zurück und geben die Router-Rolle auf. Dies ist z. B. dann der Fall, wenn ein Gerät nur noch mit anderen Geräten verbunden ist, welche ebenfalls die Router-Rolle wahrnehmen.

Damit ist das Routerkonzept, im Gegensatz zu Technologien wie Bluetooth Mesh oder Zigbee dynamisch.

FTDs und MTDs

Thread kennt unterschiedliche Typen von Geräten. Einerseits gibt es sogenannte Full Thread Devices (FTD) und sogenannte Minimal Thread Devices (MTD).

Bei den FTDs handelt es sich um autonome Geräte im Thread-Netzwerk, welche Rollen, jenseits der Endgeräte-Rolle, wahrnehmen. Im Normalfall haben diese Geräte entsprechende Hardwareressourcen, wie genügend Speicher et cetera. Im Gegensatz zu den MTDs sind FTDs immer mit dem Thread-Netzwerk verbunden. Infolgedessen sind FTDs meist solche Geräte, welche direkt am Stromnetz angeschlossen sind.

Ein einfaches Thread-Netzwerk

MTDs hingegen sind für solche Geräte gedacht, welche größtenteils über eine Batterie betrieben werden. In diese Kategorien fallen Geräte wie Sensoren und Ähnliche. Diese müssen mit ihren Ressourcen entsprechend haushalten. Sie treten deswegen nur sporadisch mit dem Thread-Netzwerk in Kontakt und befinden sich den Großteil ihrer Betriebszeit im Schlafmodus.

MTDs senden alle ihre Nachrichten zu einem sogenannten Parent-Device und nehmen nur die Rolle als Endgerät im Thread-Netzwerk wahr.

Border-Router

Da im Rahmen von Matter Informationen aus dem Thread-Netzwerk heraus in den Rest des Netzwerkes gelangen müssen, werden hier wieder Router, sogenannte Border-Router benötigt. Diese routen die Informationen aus und in das Thread-Netzwerk.

Im Gegensatz zu anderen Systemen unterstützt Thread mehrere Border-Router, um auch hier wieder einen Single Point of Failure zu vermeiden. Die Funktionalität solcher Border-Router wird und kann von unterschiedlichsten Geräten wahrgenommen werden. Beispiele für solche Geräte sind z. B. Alexa-Geräte oder der HomePod mini von Apple.

Während bei Bridges eine Übersetzung der jeweiligen Daten vorgenommen wird, damit sie vom anderen System verstanden werden, werden bei den Border-Routern nur die entsprechenden Daten vom Thread-Netzwerk in das andere Netzwerk geroutet. Eine Übersetzung derselben findet nicht statt.

Wi-Fi

Neben Thread können Geräte im Matter-Standard auch über Wi-Fi eingebunden werden. Als Übertragungstechnik bietet sich Wi-Fi für Smart Home-Geräte an, welche eine höhere Bandbreite benötigen und meist auch über ein entsprechendes Energiebudget verfügen und zumeist direkt an das Stromnetz angeschlossen sind.

In diese Kategorie fallen unter anderem Videokameras und Türklingeln mit Videoverbindung. Allerdings ist Wi-Fi bzw. ein einzelner Access Point nicht unbedingt dafür gedacht, eine große Menge an Geräten gleichzeitig zu bedienen.

Mit Wi-Fi 6 sind Verbesserungen eingeflossen, um mehr Geräten in einem Netzwerk entsprechende Daten simultan senden zu können, sodass die Nutzung für Smart Home-Geräte auch hier in Zukunft sinnvoller ist.

Distributed Compliance Ledger

Ein interessantes Detail an Matter ist der Distributed Compliance Ledger. In dieser verteilten Datenbank bzw. Blockchain befinden sich kryptografisch abgesicherte Daten über die Geräteherkunft, den Status der Zertifizierung sowie wichtige Einrichtungs- und Betriebsparameter.

Eingesehen werden kann die Datenbank unter anderem über eine entsprechende Weboberfläche. Die verwendete Software dafür kann auf GitHub ebenfalls eingesehen werden.

Gelesen werden kann die Datenbank von jedermann während Schreibzugriffe nur Herstellern im Rahmen ihrer Produkte gestattet sind.

In dieser Datenbank, können Hersteller von Produkten Informationen über diese hinterlegen, damit sie von jedermann gelesen werden können. Auch die Ergebnisse von Compliance Tests werden in diese Datenbank geschrieben. Dasselbe gilt für die Compliance Confirmation der CSA.

Für den Nutzer wird der Distributed Compliance Ledger interessant, um zu erfahren, ob ein Gerät als mit dem Standard konform zertifiziert wurde oder um Modellinformationen wie Firmware- und Hardware-Versionen auszulesen. Auch Zertifikate können über die Datenbank bezogen werden, um lokale Zertifikate zu überprüfen.

Die Netzwerktopologie des Distributed Compliance Ledger

Im Kontext des Ledgers existieren unterschiedliche Knoten. Einer dieser Knoten sind Validator-Knoten welche eine komplette Kopie der Datenbank vorhalten. Nicht jeder Knoten kann ein Validator-Knoten sein, er benötigt hierfür eine Erlaubnis. Auch die Anzahl der Validator-Knoten sollte beschränkt sein.

Ein weiterer Knoten ist der Observer-Knoten. Auch dieser enthält eine komplette Kopie der Datenbank und jeder darf einen solchen Observer-Knoten aufsetzen. Daneben existieren noch andere Knoten wie Sentry-Knoten, welche vor Validator-Knoten stehen können und ein Weg des DDoS-Schutzes sind.

Der Client kann sich nun mit einem dieser Knoten verbinden und die benötigten Informationen erfragen. Die Responses sind kryptografisch abgesichert, sodass es keine Rolle spielt, ob sie von einem Observer– oder einem Validator-Knoten kommen.

Technisch setzt das System auf Tendermint bzw. dem Cosmos SDK auf, welches ein Framework für Blockchains zur Verfügung stellt.

Unterstützung

Matter an sich ist noch ein relativ junger Standard und im Moment ist es noch schwierig kompatible Geräte zu finden, auch wenn teilweise schon Updates und Geräte ausgeliefert worden sind. Dies betrifft z. B. einige Geräte von Eve Systems oder Produkte von Nanoleaf mit Matter-Unterstützung.

Interessant ist die Unterstützung auch vonseiten der Betriebssystemanbieter für mobile Systeme, wie iOS und Android. Mit iOS 16.1 lieferte Apple die Unterstützung für Matter aus. Bei Android lieferte Android 13 die ersten Integrationen für Matter.

Auch Smart Speaker wie die Alexa-Serie von Amazon unterstützen mittlerweile Matter, so wurden bereits Updates für einige Modelle ausgerollt, weitere Modelle sollen Anfang 2023 folgen. Einige Geräte fungieren dann auch als Thread-Border-Router und ermöglichen so die Integration von Smart Home-Geräten. Das Gleiche gilt für HomePod minis und den Apple TV 4K, welche ebenfalls Thread unterstützten.

Auch auf Produktseite fangen immer mehr Hersteller an Support für Matter in ihre Produkte einzubauen, so können Entwickler z. B. mit den Philips Hue-Hubs und Geräten in Verbindung mit Matter erste Tests durchführen.

Lizenz

Wer sich Matter anschauen möchte, kann sich die Spezifikation herunterladen, nachdem einige Daten bei CSA hinterlegt worden sind. Ein frei verfügbarer Download existiert nicht.

Ähnlich sieht es auch beim Thread-Standard aus. Hier werden auch entsprechende Hinweise in der E-Mail gegeben:

Please also note, as per the Thread 1.1 Specification EULA, you are prohibited from sharing the document.

Grundsätzlich handelt es sich bei Matter um einen proprietären Standard, der genutzt werden kann, nachdem eine Zertifizierung durchgeführt und die Mitgliedsgebühren für die Connectivity Standards Alliance gezahlt wurden. Offizieller Quellcode rund um Matter ist auf GitHub zu finden und unter der Apache-Lizenz lizenziert.

Problematisch wird das Lizenzierungsmodell des Matter-Standards für GPL-Software, bedingt durch die jährlich zu leistenden Zahlungen an die Connectivity Standards Alliance, welche mit der GPL nicht vereinbar sind.

Migration auf Matter

Interessant wird es auch, wenn ein bestehendes Smart Home auf Matter umgerüstet werden soll. In einem solchen Fall sind bereits Systeme wie Zigbee oder Z-Wave installiert und die Frage stellt sich, wie diese Systeme umgestellt werden können.

Der einfachste Weg wäre es natürlich alle bestehenden Altgeräte auszubauen und anschließend neue kompatible Matter-Geräte einzubauen. Dies wird, ist den meisten Fällen aus Kostengründen und mangels fehlender Praktikabilität kein Weg sein, der gegangen werden kann.

Im Matter-Standard selbst sind für diesen Fall Bridges vorgesehen, mit welchen diese „Altsysteme“ angebunden werden können. Ein Bridge definiert sich im Matter-Standard dadurch, dass sie ein Matter-Knoten darstellen, welcher eines oder mehrere Nicht-Matter-Geräte darstellt.

Ein komplexes Matter-Netzwerk

Über solche Bridges können schlussendlich bestehende Netzwerke eingebunden werden. Daneben lassen sich einige Produkte, welche z. B. Hardware nach dem 802.15.4-Standard verbaut haben oder aber bereits Thread unterstützen per Softwareupdate so upgraden, dass sie mit dem Matter-Netzwerk kompatibel werden.

Problematisch an solchen Bridge-Lösungen ist, dass die Geräte nicht direkt integriert sind und somit unter Umständen parallele Mesh-Systeme im Smart Home existieren. Aber über solche Bridge-Lösungen ist möglich, Stück für Stück in die neue Matter-Welt zu migrieren und so den Migrations-Big-Bang zu vermeiden.

Ausblick und Fazit

Matter hat sich als neuer Standard aufgestellt, um den Smart Home-Markt aufzurollen. Dass mit neuen Standards die alten Standards nicht unbedingt obsolet werden, hatte schon XKCD in einem seiner bekannteren Comics gezeigt.

Doch wie könnte die Zukunft von Matter aussehen? Da sich praktisch jeder größere Smart Home-Anbieter und andere Firmen wie Apple, Amazon, Google und Samsung an Matter beteiligen, könnte Matter das Potenzial haben, den Markt aufzurollen.

Schlussendlich stellt sich hier die Frage nach den Produkten, die mit Matter-Unterstützung auf den Markt gebracht werden und ob diese die Kundenwünsche erfüllen können.

Auch muss der Standard, der in der Theorie übergreifend unterstützt wird und dessen Geräte unabhängig vom Hersteller genutzt werden können, dies noch in der Praxis beweisen. Im schlimmsten Fall ist der Kunde hier wieder der Leidtragende, weil er kleine und größere Inkompatibilitäten ertragen muss.

Im besten Fall führt der neue Standard zu einer Migration alter Lösungen in Richtung Matter. Der Zigbee-Standard ist praktisch ein Legacy-Standard geworden und Z-Wave wird im schlimmsten Fall einen langsamen Tod sterben, da viele Nutzer zu Matter abwandern werden und Z-Wave es schwer haben wird, gegen diesen Standard zu bestehen.

Auch wenn Z-Wave aufgrund der genutzten Funkfrequenzen kleinere technische Vorteile hat, sind dies wahrscheinlich keine Faktoren, welche sich auf Kundenseite auswirken werden. Auch wenn dies in der Z-Wave Alliance anders gesehen wird:

Matter is bringing a lot of attention to the smart home. This makes it easy to overlook Z-Wave as the most established, trusted, and secure smart home protocol, that also happens to have the largest certified interoperable ecosystem in the market. We firmly expect that Z-Wave will play a key role in connecting devices and delivering the experience users really want.

Im Rahmen des Artikels wurde einige Hintergründe von Matter erläutert, trotzdem wurde Matter nur angerissen, da der Standard auf über achthundert Seiten, viele Details definiert und unterschiedlichste Verfahren im Detail erläutert.

Wenn Matter seine Versprechen halten kann und die Nutzung für den Kunden einfacher ist, könnte es ein Standard sein, der ein Großteil der Nutzer und Hersteller in Zukunft hinter sich vereinen könnte.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.