Signerade URL:er gör länken själv kontrollerbar

En kryptografiskt signerad URL bär med sig ett bevis på vem som skapade den. Adressen innehåller, utöver den vanliga sökvägen, en signatur som en mottagare kan räkna om och jämföra. Stämmer den inte är länken ändrad eller påhittad och det kan avgöras innan någon klickar. Idén är inte ny i sig: molntjänster använder redan signerade URL:er för tidsbegränsad filåtkomst. Det nya i diskussionen är att använda samma princip för att bekämpa phishing i mejl och sms.

Problemet den ska lösa är enkelt att beskriva. En länk i ett mejl säger ingenting om vem som skrev den. Domänen kan vara snarlik, klartexten kan visa en annan adress än den som ligger i `href` och användaren har ingen möjlighet att verifiera avsändaren utan att undersöka mejlets tekniska huvuden.

Signaturen räknas fram med en privat nyckel och kontrolleras med en publik

Tekniken bygger på asymmetrisk kryptografi, samma familj av metoder som ligger bakom HTTPS och e-legitimationer. Avsändaren har ett nyckelpar. Den privata nyckeln används för att skapa en signatur över URL:ens innehåll och den publika nyckeln kan vem som helst hämta för att kontrollera signaturen.

I praktiken ser det ut ungefär så här: en bank vill skicka en länk till sitt kundmeddelande. Servern tar hela adressen, kör den genom en hashfunktion som SHA-256 och signerar hashvärdet med sin privata nyckel. Resultatet läggs till som en parameter i adressen. Vill du själv leka med hashfunktioner går det att testa i vårt hash- och kryptoverktyg och se hur ett enda ändrat tecken ger ett helt annat värde.

När mejlklienten eller webbläsaren möter länken hämtar den den publika nyckeln, räknar om hashen på adressen och kontrollerar att signaturen matchar. Ändrar en angripare en enda bokstav i sökvägen faller kontrollen. Det är precis det som händer när en phishare byter ut måldomänen, signaturen är beräknad över den gamla adressen och blir ogiltig i samma sekund.

Signeringen döljer ingenting. Adressen är fortfarande läsbar för människor och den fungerar även för klienter som inte förstår signaturen. De ignorerar bara den extra parametern.

Fyra sätt att verifiera en länk, med olika svaga punkter

Signerade URL:er är ett av flera verktyg. Det som skiljer dem åt är vad de faktiskt bevisar och vem som ska göra jobbet.

Tabellen visar också varför metoderna inte ersätter varandra. DMARC gäller mejlkanalen. Signerade URL:er följer med länken vidare, även när den klipps in i ett sms eller vidarebefordras i en chatt.

Nyckeldistributionen är det verkliga hindret

En signatur är värdelös om mottagaren inte kan avgöra vilken publik nyckel som är den rätta. Det är samma problem som certifikatutfärdare löser för HTTPS och det löste sig inte gratis. Antingen behövs en central lista över godkända avsändare och deras nycklar eller så publiceras nycklarna i DNS på det sätt DKIM redan gör.

Båda vägarna har kända svårigheter. En central lista blir en aktör som måste förvaltas, granskas och kunna spärra nycklar som läckt. DNS-baserad publicering fungerar bara om domänen i sig är betrodd och en angripare som registrerat `svenskabanken-inloggning.se` kan självklart lägga en helt giltig nyckel i sin egen DNS. Signaturen bevisar då att adressen kommer från den som äger den falska domänen. Det är sant men värdelöst.

Signering flyttar frågan från ”är länken ändrad” till ”litar jag på den som signerade”. Den andra frågan är svårare och den kräver en organisation, inte bara matematik. I Sverige finns redan ett regelverk för den typen av tillit. Post- och telestyrelsen har tillsyn över betrodda tjänster enligt EU:s eIDAS-förordning, vilket omfattar elektroniska signaturer och tillhörande certifikat. Ett system för signerade URL:er skulle rimligen behöva bygga på samma tillitsstruktur för att betyda något i praktiken.

Tidsstämplar gör länken färskvara

En detalj som ofta ingår i signerade adresser är en giltighetstid. Servern signerar inte bara sökvägen utan också en tidsstämpel och verifieringen avvisar länkar som är för gamla. Det ger ett skydd mot återanvändning: en länk som fångats upp i ett gammalt mejl fungerar inte längre.

Nackdelen märks direkt: länken slutar fungera även för legitima användare. Bokmärker du en signerad adress i mars och klickar i augusti får du ett fel. För engångsmeddelanden som kvitton och inloggningslänkar är det rätt avvägning. För dokumentation och publika sidor är det fel avvägning.

Klientstödet avgör om något av detta betyder något

Ingen del av tekniken är svår. Signeringen görs med bibliotek som finns i alla vanliga språkmiljöer och verifieringen är en handfull rader kod. Det som saknas är att mejlklienterna, mobiloperativsystemen och webbläsarna faktiskt visar resultatet för användaren.

Utan visning i gränssnittet hamnar hela bördan på mottagaren, som inte kommer att klistra in adresser i verifieringsverktyg. Historiken för PGP i e-post visar vad som händer när en säkerhetsfunktion kräver att användaren gör jobbet, den används av en liten grupp entusiaster och ingen annan.

MSB, som numera heter Myndigheten för civilt försvar, publicerar vägledningar om säkerhetsåtgärder i sitt metodstöd för informationssäkerhet. Sådana ramverk får betydelse först när tekniken finns i verktygen organisationerna redan använder.

För dig som utvecklare finns däremot ingenting som hindrar att signera länkar i egna system i dag. Interna verktyg, API-anrop mellan tjänster och tidsbegränsade nedladdningslänkar är fall där både avsändare och mottagare är under din kontroll. Det är där signerade URL:er redan fungerar och det är antagligen därifrån bredare stöd kommer att växa.

FAQ

Är en signerad URL krypterad?

Nej. Adressen är fullt läsbar, precis som en vanlig URL. Signaturen är ett extra fält som bevisar att innehållet inte ändrats, inte ett sätt att dölja innehållet.

Hjälper signerade länkar mot phishing där angriparen använder en egen domän?

Bara delvis. Signaturen bevisar vem som skapade adressen men en angripare kan signera länkar till sin egen falska domän med sin egen giltiga nyckel. Skyddet kräver att klienten också kontrollerar att signeraren finns i en lista över betrodda avsändare, vilket är den svåra delen.

Hur signerar jag URL:er i mitt eget projekt utan externa tjänster?

Ja. Använd ett standardbibliotek för HMAC eller Ed25519, signera hela adressen inklusive en tidsstämpel och verifiera på mottagarsidan. Så länge både avsändare och mottagare är dina egna system behöver du ingen central nyckeldistribution.

Varför räcker inte HTTPS?

HTTPS bevisar att anslutningen till en server är krypterad och att servern äger det certifikat som hör till domänen du besöker. Det säger ingenting om hur du fick tag på adressen eller om avsändaren av meddelandet var den du tror.