Empirische Untersuchung zur M2M-Authentifizierung

Die M2M-Authentifizierung (Machine-to-Machine) ist ein entscheidender Aspekt in der Internet der Dinge (IoT), da sie es Geräten ermöglicht, sichere Kommunikation miteinander zu führen. In dieser empirischen Untersuchung wurden verschiedene Authentifizierungsprotokolle untersucht, darunter LDAP, SAML, OAuth2 und Kerberos.

Code-Teile für dieses Projekt können auf GitLab gefunden werden.

LDAP

LDAP (Lightweight Directory Access Protocol) ist ein weit verbreitetes Verzeichnisdienstprotokoll, das zum Speichern und Abrufen von Informationen verwendet wird. Es kann jedoch komplex sein, insbesondere wenn es um die Einrichtung geht. Trotzdem bietet es eine robuste und flexible Lösung für die Authentifizierung.

Zum Aufsetzen des LDAP Servers wurde diese Anleitung verwendet. Da allerdings das Anlegen einer Gruppe beziehungsweise eines Nutzers mit .ldif-Dateien sehr fehleranfällig ist, ist es empfehlenswert einen Apache2 Server zu installieren und die Accounts über die GUI zu managen (siehe Link). Einem Nutzeraccount kann über die GUI kein Passwort hinzugefügt werden, weshalb zusätzlich ein weiters CLI-Tool notwendig ist. Bei diesem führt die Standardkonfiguration leider zu vielen Bugs, weshalb diese durch diese ersetzt werden muss.

• Hinweis: Wenn .ldif-Dateien mit dem Befehl ldapadd -x -D cn=admin,dc=example,dc=com -W -f example.ldif eingelesen werden sollen und die Fehlermeldung "" ausgegeben wird, sind die vermeidlich leeren Zeilen zwischen den Einträgen das Problem. Ein Leerzeichen oder mehrere Lehrzeichen führen hier zu diesem Problem. Stattdessen sind zwischen den Accountkonfigurationen \n\n vorgesehen.

Um die Public Key Authentication zu nutzen, muss zunächst ein Schlüsselpaar generiert werden. Dies kann mit dem ssh-keygen Befehl erreicht werden. Nachdem das Schlüsselpaar erzeugt wurde, kann es mit dem ldapadd Befehl zum LDAP-Server hinzugefügt werden. Der private Schlüssel bleibt auf dem Gerät, während der öffentliche Schlüssel auf dem LDAP-Server hinterlegt wird. Bei der Authentifizierung wird dann der öffentliche Schlüssel gegen den privaten Schlüssel auf dem Gerät geprüft.

In LDAP gibt es drei verschiedene Arten der Authentifizierung:

• Anonymous Authentication Mechanism of Simple Bind dient zur anonymen Authentifizierung eines Clients. Dies kann nützlich sein, wenn Daten für alle Benutzer:innen zugänglich sein sollen. Mit dem Befehl ldapsearch -x -LLL -H ldap://ldap.wfp2.example.com -b dc=wfp2,dc=example,dc=com dn können beispielsweise alle Einträge des LDAP Servers abgerufen werden, wodurch die Struktur der Gruppen und der Nutzer einsehen werden kann. Hier muss angemerkt werden, dass ein DNS Server mit der Domaine wfp2-example.com aufgesetzt wurde.

ldapsearch

• Im Gegensatz zu dem oben angeführten Befehl kann mit ldapwhoami -x -H ldap://ldap.wfp2.example.com -D "cn=ubuntumachine1001,ou=people,dc=wfp2,dc=example,dc=com" -W ein User in der CLI authentifiziert und anschließend autorisiert werden. Bei diesem Befehl ist zusätzlich anzumerken, dass der Parameter -W eine Eingabe des Passwortes in extra anfordert. Wird stattdessen -w verwendet, so kann das Passwort direkt in dem Befehl angegeben werden (-w <Passwort>). Diese Authentifizierung wird "Name/Password Authentication Mechanism of Simple Bind" genannt.

• Die dritte Gruppe "Unauthenticated Authentication Mechanism of Simple Bind" ermöglicht es nur einen Benutzernamen einzugeben. Das Passwortfeld bleibt in diesem Fall leer.

ldapwhoami

Mit dem Befehl ldapsearch -x -H ldap://ldap.wfp2.example.com -D "cn=ubuntumachine1001,ou=people,dc=wfp2,dc=example,dc=com" -W -b "dc=wfp2,dc=example,dc=com" fragt der User ubuntumachine1001 alle verfügbaren LDAP Accounts ab. Anzumerken ist hier, dass ubuntumachine1001 kein Admin-User ist.

ldapsearch

Eine M2M Authentifizierung mittels LDAP mithilfe eines Passwortes ist also möglich, ist allerdings nicht zu empfehlen. LDAP bietet auch die Möglichkeit einen User mithilfe eines asymmetrischen Schlüssels zu authentifizieren. Ebenfalls unterstützt das Protokoll Challenge-Response-Verfahren.

Bezüglich der Sicherheit von LDAP ist anzumerken, dass mit hoher Wahrscheinlichkeit der Apache2 Server die größte Schachstelle aufweist. Da Usernamen unautorisiert ausgelesen werden können, kann hier mit Brute-Force-Verfahren gearbeitet werden.

SAML

SAML (Security Assertion Markup Language) ist ein XML-basiertes Standard, der zur Authentifizierung und Autorisierung verwendet wird. Es wurde festgestellt, dass SAML schwer einzurichten ist, besonders wenn es darum geht, einen eigenen SAML Identity Provider zu erstellen. Da dies auch mithilfe von diversen Online-Anleitungen nicht funktioniert hat wurde als Alternative Auth0 verwendet. Auth0 ist ein Cloud-basierter Identitätsverwaltungsdienst, welcher eine benutzerfreundliche Oberfläche bietet und alle gängigen Authentifizierungsmethoden (Passwort, Token, Challenge-Response, Public-Key-Crypto) unterstützt.

Für die Public Key Authentication in SAML wird ein X.509-Zertifikat verwendet. Der private Schlüssel bleibt (wie üblich) auf dem Client-Gerät, während das Zertifikat vom SAML Identity Provider ausgestellt und anschließend hinterlegt wird. Bei der Authentifizierung wird dann das Zertifikat gegen den privaten Schlüssel auf dem Gerät geprüft

Anmerkung 1: Bei einer Token basierten Authentifizierung müssen verschiedene Parameter (client_id, client_secret, audience, grant_type) übermittelt werden. Da diese - wie ein Passwort - auf der Maschine gespeichert werden müssen, ist neben der höheren Sicherheit gegenüber Brute-Force-Angriffen kein Mehrwert vorhanden.

SAML settings

Anmerkung 2: Die Konfiguration von SAML ist langwierig, da durch die verschiedenen Schlüssel und Endpoints sehr viele Fehlerquellen vorhanden sind. Zusätzlich werden in jedem Request beziehungsweise in jedem Response sehr viele Daten mitgegeben, welche in einer Produktions-Umgebung aus Sicherheitsgründen verarbeitet werden sollten.

SAML response

OAuth2

OAuth2 ist ein Autorisierungsframework, das Benutzern ermöglicht, ihren Zugang zu ihren Daten auf sichere Weise mit Drittanbieter-Anwendungen zu teilen. In diesem Kontext wurden GitHub und Auth0 als Autorisierungsserver verwendet. Es war nicht möglich, den Autorisierungsserver lokal zu hosten, da keine Open-Source-Bibliotheken verfügbar waren. Im Vergleich zu SAML ist OAuth2 sehr benutzerfreundlich. Das Aufsetzen des Servers hat bei GitHub sowie Auth0 sehr schnell und einfach funktioniert.

GitHub hat jedoch den Nachteil, dass nur die Zugangsdaten für bestehende GitHub-Konten verwendet werden können. Dies bedeutet für eine Machine-to-Machine (M2M) Authentifizierung, dass nur eine Passwort-Authentifizierung möglich ist. Bei Auth0 können, wie bei SAML, alle gängigen Authentifizierungsmöglichkeiten verwendet werden.

In OAuth2 wird die Public Key Authentication durch die Verwendung von JWT (JSON Web Tokens) erreicht. Ein JWT enthält einen Header, der Informationen über den verwendeten Algorithmus enthält, und einen Body, der die tatsächlichen Daten enthält. Der Header und der Body werden dann mit dem privaten Schlüssel des Geräts signiert. Beim Überprüfen der Gültigkeit des Tokens wird das Token mit dem öffentlichen Schlüssel des Geräts überprüft.

mTLS

mTLS (Mutual Transport Layer Security) ist eine Methode für gegenseitige Authentifizierung, die sicherstellt, dass beide Parteien, die Informationen austauschen, wer sie behaupten zu sein, tatsächlich sind, indem überprüft wird, ob sie beide den richtigen privaten Schlüssel haben.

Im Detail funktioniert mTLS sehr ähnlich wie das TLS-Protokoll. Es gibt jedoch einen zusätzlichen Schritt vor dem Schlüsselaustausch. Der Client sendet seinen öffentlichen Schlüssel und Zertifikat an den Server, der diese vom Server aus identifiziert, um zu bestätigen, dass die Anfrage von einem bekannten Client kommt und den privaten Schlüssel besitzt, der zum geteilten öffentlichen Schlüssel des Clients entspricht.

Um mTLS zu implementieren, wird im Gegensatz zu TLS eine interne Zertifizierungsstelle benötigt. Diese stellt die X.509 Zertifikate für alle Clients und Server aus, wodurch jedes Zertifikat das gleiche Stamm-Zertifikat besitzt. Anhand dieser Übereinstimmung findet die Authentifizierung statt. Das Stamm-Zertifikat ist in diesem Fall selbstsigniert. Der Vorteil von mTLS ist, dass diverse Angriffe wie zum Beispiel On-Path-Angriffe, Credential Stuffing, erfolglos verlaufen.

mTLS bietet mehr Sicherheit als TLS, da es sowohl die Identität des Servers als auch des Clients überprüft. Es ist jedoch rechenintensiver als TLS, was es weniger geeignet für Szenarien macht, in denen eine geringere Latenz Priorität hat als Zero Trust-Sicherheit.

Kerberos

Kerberos ist ein Netzwerkauthentifizierungsprotokoll, das auf einem Ticket-Granting-Ticket-System basiert und ursprünglich für das Windows Active Directory entwickelt wurde. Kerberos kann einfach in Ubuntu eingerichtet und verwendet werden. Es ist jedoch wichtig zu beachten, dass Kerberos die Verwendung von Domain-Namen (für eine "einfache" Konfiguration) erfordert, weshalb zusätzlich ein DNS-Server eingerichtet werden muss. Für eine Konfiguration ohne DNS-Server siehe Link (nicht getestet).

Für die Konfiguration vom Kerbers Server wurden die Schritte in dieser Anleitung durchgeführt. Der Client benötigt diese Library, um ein Ticket beantragen zu können. Mit dem Befehl kinit <username> kann ein Ticket vom Kerberos Key Distribution Center (KDC) beantragt und mit klist angezeigt werden.

Offiziell unterstützt Kerberos nur eine Passwort-Authentifizierung. Mit zusätzlichen "Plug-In"s lässt sich dies um ein Challenge-Response-Verfahren oder eine Public-Key Cryptography erweitern.

Bezüglich Kerberos ist auch zu erwähnen, dass es das Tool Kerbrute gibt, welches Kerberos Account auslesen und mithilfe von beispielsweise Dictionary-Attacks Passwörter auslesen kann. Allerdings kann Kerberos so konfiguriert werden, dass nach einer bestimmten Anzahl an Falscheingaben der Account gesperrt wird.

Schließlich ist es wichtig zu beachten, dass Kerberos nur zur Authentifizierung verwendet wird und nicht zur Verwaltung von Benutzergruppen, Linux-UIDs und GIDs, Home-Verzeichnissen usw. Daher wird normalerweise eine weitere Netzwerkquelle für diese Informationen verwendet, wie z.B. ein LDAP- oder Windows-Server. Darüber hinaus müssen Kerberos-Benutzerprinzipale manuell zum Kerberos-Server hinzugefügt werden, damit sie sich anmelden können. Dies kann mit den kadmin.local-Befehlen erfolgen.

Fwknop

Fwknop (Firewall Knocking Operation) ist ein Tool, das es ermöglicht, den Zugriff auf einen Server zu steuern, indem es "knocks" an den Server sendet, um einen temporären Port öffnen zu lassen. Dies ist besonders nützlich in Umgebungen, in denen Zero Trust-Prinzipien angewendet werden. fwknop ist im Gegensatz zu vielen anderen Servicen ein Programm, welches keinen Port benötigt, weshalb es gegenüber Schwachstellen von außen sehr gut geschützt ist.

Der sogenannte "knock" besteht dabei aus genau einem IPv4 Packet, welches zum Server geschickt und von diesem gedroppt wird, da keine entsprechende FW-Regel vorhanden ist. fwknop nimmt dieses gedroppte Packet und überprüft, ob die zur Verfügung gestellten Schlüssel gültig sind. Sind diese gültig, wird eine IP-Tables Regel für eine bestimmte Zeit (z.B. 5sec) geöffnet, in welcher der Client Zeit hat sich mit dem Service zu verbinden. Der Nachteil von fwknop ist, dass durch die begrenzte Anzahl an Byte in einem IPV4 Packet Schlüssel wie RSA4096 neben den anderen Parametern keinen Platz haben.

Für die M2M Kommunikation ist dieses Tool grundsätzlich eine tolle Idee. Allerdings muss auch gesagt werden, dass fwknop nicht mehr weiter entwickelt wurde, weshalb es nur auf Ubuntu16 Maschinen funktioniert.

Zusammenfassung

Diese empirische Untersuchung hat gezeigt, dass es viele verschiedene Möglichkeiten zur Authentifizierung in M2M-Umgebungen gibt, jede mit ihren eigenen Vor- und Nachteilen. Es ist wichtig, die spezifischen Anforderungen und Bedingungen Ihrer Umgebung zu berücksichtigen, um die beste Lösung für Ihre Bedürfnisse zu finden.

Protokoll	Einrichtungskomplexität	Sicherheitslücken	Benutzerfreundlichkeit	Authentifizierungsmethoden	Kommentare
LDAP	Mittel	nmap <LDAP Server> hat ausschließlich Schwachstellen beim Apache Server (2.4.52) gefunden	CLI ist nicht benutzerfreundlich / Weboberfläche ist benutzerfreundlich	Passwörter, Challenge/Response-Verfahren, Public-Key-Kryptografie	Funktioniert gut, wenn es einmal funktioniert
SAML	Mittel	Nicht relevant	Hohe Benutzerfreundlichkeit	Passwörter, Challenge/Response-Verfahren, Public-Key-Kryptografie	Einrichtung des Identity Providers über Auth0 hat schnell und problemlos funktioniert
	Hoch	N/A	N/A	N/A	der Versuch den Identity Provider lokal zu hosten wurde nach vielen Fehlversuchen aufgegeben
OAuth2	Niedrig	Nicht relevant	Benutzerfreundlich	Passwörter, Challenge/Response-Verfahren, Public-Key-Kryptografie	Einfache Einrichtung, wenn GitHub oder Auth0 als Autorisierungsserver verwendet werden
Kerberos	Niedrig	Kerbrute (Brute-Force-Angriffe)	Benutzerfreundlich	Passwörter	Einfache Einrichtung, aber speziell für Windows Active Directory entwickelt
Fwknop	Mittel	N/A	Benutzerfreundlich	Passwörter, Public-Key-Kryptografie mit Schlüsseln bis 2048 Bit	Einfache Einrichtung, aber nur in Ubuntu16 funktioniert

Felder, welche mit "Nicht relevant" markiert wurden, bedeuten, dass die Verantwortung bei den externen Identity Providern und nicht bei den internen Service Providern liegt.

Use-Case 1 - alle Maschinen haben die gleichen Rechte und werden von einer Gruppe verwaltet

Die Verwendung von mTLS (Mutual TLS) für die Authentifizierung zwischen den Maschinen ist eine gute Idee, solange keine externen Dienste verwendet werden. Wenn jedoch externe Dienste verwendet werden, müssen die Zertifikate kompatibel sein, um eine erfolgreiche Kommunikation zu gewährleisten.

Das Zero Trust-Prinzip und das Port Knocking sind ebenfalls geeignete Methoden zur Steuerung des Zugriffs auf die Maschinen. Hierbei wird der Zugriff auf die Maschinen erst nach erfolgreichem Durchlaufen eines bestimmten Sicherheitsprozesses ermöglicht.

Use-Case 2 - Maschinen sind an unterschiedlichen Standorten und werden von unterschiedlichen Gruppen verwaltet

Für diesen Fall ist die Verwendung von SAML oder OAuth2 empfehlenswert, um die Identität und Zugriffsrechte der Maschinen zu verwalten. Beide Protokolle ermöglichen eine feingranulare Konfiguration der Rechte.

Während SAML aufgrund seiner XML-basierten Struktur und seines breiten Einsatzes oft als sicherer gilt, kann OAuth aufgrund seiner Einfachheit und Benutzerfreundlichkeit Vorteile bieten, insbesondere wenn es um die Verwaltung von Benutzerprivilegien geht.

Die Wahl zwischen SAML und OAuth2 hängt also von den spezifischen Anforderungen und der vorhandenen Ressourcen ab.