Web-Bot-Auth-Schlüsselgenerator: Ed25519-Schlüssel für HTTP-Nachrichten-Signaturen erstellen

Jeder, der einen Web-Crawler oder KI-Agenten betreibt, kennt das Problem: Ein einfacher User-Agent-String oder eine IP-Adresse lässt sich leicht fälschen. Für Webseitenbetreiber wird es immer schwieriger, legitime Bots von Spam oder schädlichen Anfragen zu unterscheiden. Hier setzt Web-Bot-Auth an: ein noch im Entwurf befindlicher Standard des IETF, der auf HTTP Message Signatures (RFC 9421) basiert. Statt sich auf leicht manipulierbare Metadaten zu verlassen, signiert der Bot jede Anfrage mit einem privaten Schlüssel. Die Webseite prüft die Signatur gegen einen öffentlich hinterlegten Schlüssel und kann so sicherstellen, dass die Anfrage tatsächlich vom deklarierten Bot stammt.

Das Prinzip ist ähnlich wie bei TLS-Zertifikaten, nur dass es hier um die Identität des Absenders geht. Der Web-Bot-Auth-Schlüsselgenerator hilft dabei, die notwendigen Schlüsselpaare zu erstellen, direkt im Browser, ohne dass der private Schlüssel jemals übertragen wird. Besonders für deutsche Unternehmen, die KI-Agenten für Marktanalysen oder Datenaggregation einsetzen, bietet dies eine rechtssichere Möglichkeit, ihre Bots zu authentifizieren, ohne gegen Datenschutzbestimmungen zu verstoßen. Da die Schlüssel lokal generiert werden, bleibt die Kontrolle vollständig beim Betreiber.

Aktuell handelt es sich bei Web-Bot-Auth noch um einen Internet-Draft, nicht um einen fertigen Standard. Dennoch setzen bereits erste Projekte auf diese Technologie, da sie eine robuste Alternative zu herkömmlichen Methoden darstellt. Wer heute damit beginnt, ist für die Zukunft gut vorbereitet, besonders wenn immer mehr Webseiten auf signierte Anfragen umstellen.

Der Web-Bot-Auth-Schlüsselgenerator liefert ein vollständiges Starter-Kit für die Implementierung von HTTP Message Signatures. Nach der Eingabe der HTTPS-Origin (z. B. https://mein-bot.de) und der Auswahl einer Gültigkeitsdauer (keine, 30 Tage, 90 Tage oder 365 Tage) erzeugt das Tool im Browser ein Ed25519-Schlüsselpaar. Die Ausgabe besteht aus mehreren Komponenten, die jeweils einen spezifischen Zweck erfüllen:

1. Key-ID: Ein eindeutiger Bezeichner für den Schlüssel, berechnet als JWK-Thumbprint (SHA-256, base64url-codiert). Dieser Wert wird später im keyid-Parameter jeder Signatur verwendet.
2. Key-Directory-JSON: Eine öffentliche Schlüsseldatei im JWK-Format, die unter /.well-known/http-message-signatures-directory abgelegt wird. Sie enthält nur den öffentlichen Schlüssel sowie optional die Felder nbf (not before) und exp (expires) für die Gültigkeitssteuerung.
3. Directory-Response-Header: Ein Beispiel für die Antwort-Header der Key-Directory, inklusive einer 24-stündigen Signatur. Diese Signatur muss in der Praxis regelmäßig erneuert werden, um die Aktualität des Schlüssels zu bestätigen.
4. Privater Schlüssel: Wird als JWK (mit dem geheimen d-Parameter) und als PKCS#8-PEM-Datei ausgegeben. Dieser Schlüssel darf niemals veröffentlicht werden und sollte in einem sicheren Secrets-Manager gespeichert werden.
5. Öffentlicher Schlüssel: Als SPKI-PEM-Datei, falls eine Integration mit bestehenden Systemen erforderlich ist.
6. Signiertes Beispiel: Eine vollständige Beispielanfrage mit allen notwendigen Headern (Signature, Signature-Input, Signature-Agent) sowie einem curl-Befehl, der die Signatur demonstriert. Die Anfrage ist mit dem Tag web-bot-auth versehen und läuft nach 5 Minuten ab.
7. Signature-Base: Der exakte Text, der signiert wurde. Dies ist besonders nützlich, um eigene Signatur-Implementierungen zu debuggen, da bereits kleine Abweichungen (z. B. falsche Zeilenumbrüche) zu ungültigen Signaturen führen.

Alle Daten werden lokal im Browser generiert und nicht an einen Server übertragen. Ein Neuladen der Seite löscht alle Schlüssel. Das ist ein bewusster Schutzmechanismus, um versehentliche Offenlegungen zu verhindern.

Damit Webseiten die Signaturen Ihres Bots überprüfen können, müssen Sie die öffentliche Key-Directory unter einem standardisierten Pfad bereitstellen. Der Web-Bot-Auth-Schlüsselgenerator erzeugt das notwendige JSON, das Sie unter /.well-known/http-message-signatures-directory auf Ihrer HTTPS-Origin ablegen. Wichtig ist, dass die Datei mit dem korrekten Media-Type application/json ausgeliefert wird und über eine gültige HTTPS-Verbindung erreichbar ist.

Die Key-Directory selbst sollte regelmäßig aktualisiert werden, insbesondere wenn Sie eine begrenzte Gültigkeitsdauer für den Schlüssel gewählt haben. Der Generator liefert zwar eine 24-stündige Signatur für die Directory-Antwort mit, doch in der Praxis müssen Sie diese Signatur selbst neu erstellen, idealerweise automatisiert. Dafür können Sie die im Generator enthaltenen Beispiel-Header als Vorlage nutzen. Achten Sie darauf, dass die Felder nbf (not before) und exp (expires) korrekt gesetzt sind, falls Sie eine zeitliche Begrenzung wünschen. Ohne diese Felder bleibt der Schlüssel unbegrenzt gültig, was zwar praktisch ist, aber die Sicherheit beeinträchtigen kann.

Ein weiterer wichtiger Punkt ist die Key-Rotation. Selbst wenn Sie keine Gültigkeitsdauer festlegen, sollten Sie den Schlüssel regelmäßig wechseln, etwa alle 90 Tage. Der Generator unterstützt dies, indem er bei jedem Aufruf ein neues Schlüsselpaar erstellt. Planen Sie jedoch genug Zeit ein, um den alten Schlüssel parallel bereitzuhalten, damit bestehende Signaturen weiterhin validiert werden können. Für deutsche Unternehmen, die KI-Agenten im geschäftlichen Kontext einsetzen, ist dies besonders relevant, um Compliance-Anforderungen zu erfüllen.

Vergessen Sie nicht, die Key-Directory in Ihrer robots.txt oder llms.txt zu verlinken, falls Sie spezifische Regeln für Bots definieren. Der AI Crawler Robots.txt Generator kann Ihnen dabei helfen, eine passende Konfiguration zu erstellen.

Die Signatur einer HTTP-Anfrage nach RFC 9421 folgt einem klaren Schema, das der Web-Bot-Auth-Schlüsselgenerator anhand eines Beispiels veranschaulicht. Der Prozess lässt sich in drei Schritte unterteilen: die Auswahl der zu signierenden Komponenten, die Erstellung der Signature-Input-Parameter und die Berechnung der eigentlichen Signatur.

Zunächst werden die covered components festgelegt, also die Teile der Anfrage, die in die Signatur einfließen. Typische Komponenten sind @method (die HTTP-Methode, z. B. GET), @authority (die Domain, z. B. api.example.com), @path (der Pfad, z. B. /daten) und content-digest (ein Hash des Request-Bodys). Der Generator verwendet standardmäßig die Komponenten @method, @authority, @path und signature-agent, um eine Balance zwischen Sicherheit und Praktikabilität zu schaffen.

Im zweiten Schritt werden die Signature-Input-Parameter definiert. Dazu gehören: - created: Der Zeitpunkt der Signaturerstellung (Unix-Timestamp). - expires: Das Ablaufdatum der Signatur (meist 5 Minuten nach Erstellung). - keyid: Die Key-ID, die auf den öffentlichen Schlüssel in der Key-Directory verweist. - alg: Der verwendete Algorithmus, hier ed25519. - nonce: Eine zufällige Zeichenfolge, um Replay-Angriffe zu verhindern. - tag: Ein frei wählbarer Bezeichner, z. B. web-bot-auth.

Der entscheidende Teil ist die Signature-Base, die aus den ausgewählten Komponenten und Parametern zusammengesetzt wird. Jede Komponente wird in einer eigenen Zeile dargestellt, gefolgt von einem Doppelpunkt und dem Wert. Beispiel:

@method: GET
@authority: api.example.com
@path: /daten
signature-agent: https://mein-bot.de
created: 1712345678
expires: 1712346078
keyid: "abc123"

Diese Zeichenfolge wird mit dem privaten Schlüssel signiert, und das Ergebnis wird im Signature-Header übertragen. Der Web-Bot-Auth-Schlüsselgenerator liefert die exakte Signature-Base als Referenz, sodass Sie eigene Implementierungen leicht überprüfen können. Besonders wichtig ist, dass die Reihenfolge der Komponenten und die exakte Formatierung (inklusive Zeilenumbrüche) eingehalten werden. Selbst kleinste Abweichungen führen zu ungültigen Signaturen.

Der private Schlüssel ist das Herzstück der Web-Bot-Auth-Implementierung: Wer ihn besitzt, kann sich als Ihr Bot ausgeben. Der Web-Bot-Auth-Schlüsselgenerator erzeugt den Schlüssel lokal im Browser, ohne ihn jemals an einen Server zu übertragen. Dennoch liegt es in Ihrer Verantwortung, ihn sicher zu verwahren. Nach dem Neuladen der Seite ist der Schlüssel unwiederbringlich verloren, was zwar die Sicherheit erhöht, aber auch bedeutet, dass Sie ihn sofort sichern müssen.

Die einfachste Methode ist der Download als JWK- oder PKCS#8-PEM-Datei. Speichern Sie diese Datei in einem Secrets-Manager wie HashiCorp Vault, AWS Secrets Manager oder einem lokalen Passwort-Tresor. Vermeiden Sie es, den Schlüssel in Klartext in Konfigurationsdateien oder Versionskontrollsystemen abzulegen. Besonders kritisch ist der d-Parameter in der JWK-Darstellung. Dieser darf niemals veröffentlicht werden, da er den privaten Schlüssel enthält.

Für deutsche Unternehmen, die KI-Agenten im Rahmen der DSGVO betreiben, ist die sichere Speicherung des Schlüssels auch eine rechtliche Anforderung. Ein Verlust oder Diebstahl könnte nicht nur zu Missbrauch führen, sondern auch zu Bußgeldern, falls personenbezogene Daten betroffen sind. Planen Sie daher regelmäßige Key-Rotationen ein, um das Risiko zu minimieren. Der Generator unterstützt dies, indem er bei jedem Aufruf ein neues Schlüsselpaar erstellt. Achten Sie jedoch darauf, den alten Schlüssel noch für eine Übergangszeit bereitzuhalten, damit bestehende Signaturen weiterhin validiert werden können.

Falls Sie den Schlüssel in einer Cloud-Umgebung verwenden, sollten Sie ihn niemals im Klartext in Umgebungsvariablen speichern. Nutzen Sie stattdessen die nativen Secrets-Management-Funktionen Ihres Providers. Für lokale Tests können Sie den Schlüssel temporär in einer verschlüsselten Datei ablegen, die nach Gebrauch gelöscht wird. Denken Sie daran: Ein kompromittierter Schlüssel macht die gesamte Authentifizierung wertlos. Investieren Sie daher in eine robuste Schlüsselverwaltung.

Die traditionellen Methoden zur Bot-Erkennung (User-Agent-Strings und IP-Adressen) haben gravierende Schwächen. Ein User-Agent lässt sich mit einem einzigen Header manipulieren, und IP-Adressen sind entweder zu statisch (und damit leicht blockierbar) oder zu dynamisch (und damit unzuverlässig). Besonders in Deutschland, wo viele Unternehmen auf Cloud-Dienste mit wechselnden IP-Bereichen setzen, ist die IP-basierte Verifizierung oft unpraktikabel. Zudem führen strengere Datenschutzbestimmungen dazu, dass IP-Adressen zunehmend als personenbezogene Daten behandelt werden, was ihre Nutzung zusätzlich erschwert.

Web-Bot-Auth löst diese Probleme durch kryptografische Signaturen. Statt sich auf leicht fälschbare Metadaten zu verlassen, wird jede Anfrage mit einem privaten Schlüssel signiert. Die Webseite prüft die Signatur gegen einen öffentlich hinterlegten Schlüssel und kann so sicherstellen, dass die Anfrage tatsächlich vom deklarierten Bot stammt. Dies ist besonders für KI-Agenten relevant, die sensible Daten abrufen oder automatisierte Transaktionen durchführen. Ein weiterer Vorteil: Die Signatur enthält einen Zeitstempel (expires), der Replay-Angriffe verhindert.

Allerdings ist Web-Bot-Auth nicht ohne Aufwand. Die Implementierung erfordert die Einrichtung einer Key-Directory, die regelmäßige Aktualisierung der Signaturen und eine sichere Schlüsselverwaltung. Für einfache Crawler, die nur öffentliche Daten abrufen, mag dies übertrieben sein. Doch für Unternehmen, die auf zuverlässige und rechtssichere Bot-Identifikation angewiesen sind, bietet Web-Bot-Auth eine zukunftssichere Alternative. Kombiniert mit robots.txt und llms.txt lässt sich so ein umfassendes Regelwerk für Bots erstellen, das sowohl die Rechte der Webseitenbetreiber als auch die der Bot-Betreiber respektiert.

Für deutsche Unternehmen, die KI-Agenten im geschäftlichen Kontext einsetzen, ist Web-Bot-Auth die robustere Wahl, besonders wenn es um Compliance und Datenschutz geht.

Wie richte ich Web-Bot-Auth für meinen Bot ein? Generieren Sie zunächst ein Schlüsselpaar mit dem Web-Bot-Auth-Schlüsselgenerator. Laden Sie den öffentlichen Schlüssel als Key-Directory unter /.well-known/http-message-signatures-directory hoch und speichern Sie den privaten Schlüssel sicher ab. Signieren Sie anschließend jede Anfrage mit dem privaten Schlüssel und fügen Sie die notwendigen Header (Signature, Signature-Input) hinzu.

Ist der Generator kostenlos und brauche ich ein Konto? Ja, der Web-Bot-Auth-Schlüsselgenerator ist vollständig kostenlos und erfordert keine Registrierung. Alle Schlüssel werden lokal im Browser erzeugt und nicht an einen Server übertragen.

Was ist die Key-ID und wie wird sie berechnet? Die Key-ID ist ein eindeutiger Bezeichner für Ihren Schlüssel, berechnet als JWK-Thumbprint. Dabei wird der öffentliche Schlüssel mit SHA-256 gehasht und base64url-codiert. Dieser Wert wird im keyid-Parameter jeder Signatur verwendet, damit die Webseite den passenden öffentlichen Schlüssel in der Key-Directory finden kann.

Warum wird Ed25519 verwendet? Ed25519 ist der im Web-Bot-Auth-Standard empfohlene Algorithmus, da er kleine Schlüsselgrößen und schnelle, deterministische Signaturen bietet. Zudem wird er von modernen Browsern über die Web-Crypto-API unterstützt, was die lokale Generierung im Browser ermöglicht.

Was ist die Signature-Base und warum ist sie wichtig? Die Signature-Base ist der exakte Text, der signiert wird. Sie setzt sich aus den zu signierenden Komponenten (z. B. @method, @authority) und den Signature-Input-Parametern zusammen. Bereits kleine Abweichungen (etwa falsche Zeilenumbrüche oder fehlende Leerzeichen) führen zu ungültigen Signaturen. Der Generator liefert die Signature-Base als Referenz, um eigene Implementierungen zu debuggen.

Wird mein privater Schlüssel an einen Server gesendet? Nein. Der private Schlüssel wird ausschließlich lokal im Browser erzeugt und niemals übertragen. Selbst wenn Sie die Seite neu laden, ist der Schlüssel verloren. Das ist ein bewusster Schutzmechanismus.

Ich habe die Seite neu geladen und der Schlüssel ist weg. Was nun? Das ist beabsichtigt. Der Web-Bot-Auth-Schlüsselgenerator speichert nichts lokal. Generieren Sie einfach ein neues Schlüsselpaar und laden Sie die aktualisierte Key-Directory hoch. Achten Sie darauf, den neuen privaten Schlüssel sicher zu speichern.

Mein Browser kann keine Schlüssel generieren oder meine Origin wird abgelehnt. Woran liegt das? Ed25519 wird nur von aktuellen Browsern wie Chrome, Firefox oder Safari unterstützt. Stellen Sie sicher, dass Sie eine aktuelle Version verwenden. Die Origin muss zudem eine gültige HTTPS-URL ohne Pfad sein (z. B. https://mein-bot.de).

Sollte ich eine Gültigkeitsdauer für den Schlüssel festlegen oder keine? Das hängt von Ihrem Anwendungsfall ab. Eine Gültigkeitsdauer (30 Tage, 90 Tage oder 365 Tage) erzwingt eine regelmäßige Key-Rotation, was die Sicherheit erhöht. Allerdings erfordert dies mehr Wartungsaufwand. Ohne Gültigkeitsdauer bleibt der Schlüssel unbegrenzt gültig, was praktisch, aber weniger sicher ist. Für deutsche Unternehmen empfiehlt sich eine Rotation alle 90 Tage, um Compliance-Anforderungen zu erfüllen.