Nyckelgenerator för Web Bot Auth och RFC 9421

Traditionell identifiering av sökrobotar och automatiserade agenter har länge vilat på två metoder: strängen i HTTP-headern User-Agent samt listor över godkända IP-adresser. Båda mekanismerna har allvarliga brister. En User-Agent kan förfalskas av vem som helst på en bråkdel av en sekund, medan IP-validering kräver kontinuerlig omvänd DNS-uppslagning eller underhåll av statiska nätverksintervall som snabbt blir inaktuella när molninfrastrukturer förändras.

Web Bot Auth bygger på IETF-standarden RFC 9421 för HTTP Message Signatures. Standarden etablerar en kryptografisk modell där botoperatören signerar varje utgående HTTP-begäran med en privat nyckel. Webbservern som tar emot anropet hämtar motsvarande publika nyckel direkt från operatörens egen domän via en standardiserad katalog. Om signaturen stämmer finns ett matematiskt bevis på att anropet härstammar från den angivna källan.

Tekniken specificeras i pågående IETF Internet-Drafts och ger webbplatsägare möjlighet att selektivt tillåta verifierade AI-agenter och indexerare samtidigt som opålitliga aktörer blockeras. Genom att flytta verifieringen från godtyckliga textsträngar till asymmetrisk kryptografi minskar risken för identitetsstöld på webben avsevärt.

Vår Web Bot Auth-nyckelgenerator skapar ett komplett startpaket för att driftsätta kryptografisk signering enligt RFC 9421. Verktyget körs lokalt i din webbläsare med Web Crypto API och genererar ett asymmetriskt Ed25519-nyckelpar utan att skicka några uppgifter över nätverket.

Resultatet består av följande komponenter:

• Nyckel-ID (Key ID): Ett unikt tumavtryck beräknat via SHA-256 och base64url enligt RFC 7638 och RFC 8037.
• Nyckelkatalog i JSON-format: Den publika katalogstrukturen som ska placeras på din server under /.well-known/http-message-signatures-directory.
• Svarsheaders för katalogen: Ett komplett exempel på hur servern ska svara när katalogen efterfrågas, inklusive katalogens egen signatur med en giltighet på 24 tim.
• Privat nyckel: Den hemliga komponenten levererad i både JWK-format och PKCS#8 PEM-format för integrering i din applikationskod.
• Publik nyckel: Den öppna komponenten i SPKI PEM-format.
• Exempelanrop: Ett färdigt curl-kommando samt relevanta HTTP-headers som demonstrerar en korrekt signering med en giltighetstid på 5 min.
• Signaturbas: Den exakta textsträng som genereras internt och signeras av kryptomotorn.

För att mottagande servrar ska kunna validera dina anrop måste den publika nyckeln göras tillgänglig på ditt https-ursprung. Sökvägen är strikt standardiserad till /.well-known/http-message-signatures-directory och måste returneras med mediatypen application/json.

Enligt specifikationen ska själva katalogresponsen också vara kryptografiskt signerad av ursprunget. Detta förhindrar manipulation i mellanliggande proxyservrar och CDN-nätverk. Den exempelheader som verktyget tillhandahåller inkluderar parametern expires beräknad till 24 tim framåt i tiden. I produktionsmiljö måste denna signatur genereras dynamiskt eller förnyas via schemalagda jobb.

Katalogen stöder även tidsstyrning via fälten nbf (not before) och exp (expires). Dessa fält möjliggör planerad nyckelrotation. Vid rotation publiceras den nya publika nyckeln i katalogen parallellt med den gamla under en övergångsperiod, varpå botens anrop gradvis ställs om till det nya nyckel-ID:t innan den gamla nyckeln avregistreras.

Signeringsprocessen enligt RFC 9421 bygger på att specifika delar av HTTP-meddelandet sammanställs till en deterministisk textsträng som kallas signaturbas. Om en enda byte skiljer sig mellan klientens beräkning och serverns rekonstruktion blir signaturen ogiltig.

I Web Bot Auth omfattar signaturbasen vanligtvis målserverns auktoritet (@authority) samt parametern signature-agent. Klienten konstruerar headern Signature-Input som definierar vilka komponenter som ingår och bifogar metadata:

1. created: Unix-tidsstämpel för när signaturen skapades.
2. expires: Tidsstämpel då signaturen upphör att gälla, exempelvis efter 5 min.
3. keyid: Nyckelns tumavtryck som pekar ut rätt post i nyckelkatalogen.
4. alg: Den kryptografiska algoritmen ed25519.
5. tag: Strängen web-bot-auth som anger syftet med signaturen.

När signaturbasen har skapats körs den genom signeringsfunktionen med den privata Ed25519-nyckeln. Det resulterande binära värdet kodas med base64 och placeras i headern Signature. Mottagaren läser parametrarna, bygger upp exakt samma signaturbas och verifierar signaturen mot din publika nyckel.

Säkerheten i hela Web Bot Auth-ekosystemet bygger på att den privata nyckeln förblir strikt hemlig. Om en obehörig part får tillgång till nyckeln kan denne skicka godtyckliga anrop i din bots namn fram till dess att nyckeln roteras bort från katalogen.

Vår Web Bot Auth-nyckelgenerator är utformad med noll datainsamling som princip. Nyckelgenereringen sker helt asynkront i din lokala webbläsarsession via Web Crypto API. Ingen data skickas till externa servrar, och om du laddar om fliken raderas nyckeln permanent ur minnet.

När du har genererat ditt nyckelpar bör du omedelbart föra över den privata nyckeln till en säker hemlighetshanterare (Secrets Manager) eller krypterad miljövariabel i ditt produktionssystem. Den publika JSON-filen som placeras på webbservern får under inga omständigheter innehålla parametern d, eftersom d representerar själva nyckelhemligheten i JWK-strukturen.

Det är viktigt att skilja på identitetsverifiering och åtkomstregler. Web Bot Auth ger endast ett kryptografiskt svar på frågan om vem som skickar en begäran. Standarden styr inte vilka resurser boten har tillstånd att läsa eller bearbeta.

För att styra botens beteende på webbplatsen kombineras signaturen med etablerade instruktionsfiler. Webbplatsägaren kan använda ett verktyg för robots.txt för att specificera vilka kataloger olika sökrobotar och AI-modeller får indexera. Reglerna kan därefter kontrolleras med en testare för robots.txt för att säkerställa att inga känsliga sektioner exponeras oavsiktligt.

När en bot identifierar sig via Web Bot Auth kan mottagaren mappa den verifierade domänen mot sina lokala policyer. En webbplats kan exempelvis välja att ge full tillgång till verifierade sökmotorer och akademiska forskningsagenter, samtidigt som oidentifierad skrapning begränsas via strikta hastighetsbegränsningar.