Meddelandeintegritet: kryptografiska hashfunktioner, HMAC och signaturer

Meddelandeintegritet innebär att mottagaren kan upptäcka om data har ändrats på vägen eller i lagring. Under de tidiga åren av nätverkskommunikation gällde sådana kontroller främst oavsiktliga fel från brus, dåliga kablar eller skadade lagringsmedier. Paritetsbitar, kontrollsiffror och CRC kunde avslöja många överföringsfel, men de var inte konstruerade för att stå emot en angripare som medvetet ändrar både data och kontrollvärde.

Kryptografiska hashfunktioner löser en annan del av problemet: de gör det praktiskt möjligt att upptäcka om ett meddelande, en fil eller ett datapaket har förändrats sedan ett känt värde beräknades. De ger däremot inte automatiskt autenticitet, konfidentialitet eller bevis på vem som skapade meddelandet. Den skillnaden är central i verkliga system, eftersom en hash som följer med samma oskyddade kanal som meddelandet kan bytas ut av en angripare.

Från felkontroll till kryptografisk integritet

En CRC eller kontrollsumma är användbar när hotet är slumpmässiga fel. Den kan till exempel upptäcka att en fil på disk har skadats eller att en överföring har blivit felaktig. En kryptografisk hashfunktion är däremot utformad för en miljö där någon kan försöka skapa ett annat meddelande med samma kontrollvärde, eller försöka räkna baklänges från hashvärdet till ett möjligt original.

En hashfunktion tar ett meddelande av godtycklig längd och producerar ett utdata av fast längd, ofta kallat digest, fingeravtryck eller hashvärde. En liten ändring i indata ska ge en oförutsägbar ändring i utdata; för moderna hashfunktioner brukar ungefär hälften av bitarna förändras i genomsnitt när en enda bit i meddelandet ändras. Denna avalanche-effekt gör hashvärden praktiska för att snabbt upptäcka förändringar, men effekten i sig är inte hela säkerhetsmodellen.

De tre egenskaper som oftast avgör om en hashfunktion är lämplig för säkerhetsbruk är kollisionsresistens, preimage-resistens och second-preimage-resistens. Kollisionsresistens betyder att det ska vara opraktiskt att hitta två olika meddelanden med samma hashvärde. Preimage-resistens betyder att det ska vara opraktiskt att utifrån ett hashvärde hitta något meddelande som ger detta värde. Second-preimage-resistens betyder att det, givet ett specifikt meddelande, ska vara opraktiskt att hitta ett annat meddelande med samma hash.

Det är här äldre algoritmer faller bort. MD5 och SHA-1 förekommer fortfarande i äldre system, men de ska inte väljas för nya implementationer där kryptografisk integritet spelar roll. Deras kollisionssvagheter innebär att angripare i vissa sammanhang kan konstruera olika data med samma hashvärde. SHA-2-familjen, exempelvis SHA-256 och SHA-512 enligt NIST FIPS 180-4, är fortfarande vanlig i moderna system. SHA-3, standardiserad i NIST FIPS 202 och baserad på Keccak, bör ses som ett standardiserat alternativ med annan konstruktion, inte som en generell tvångsersättare för SHA-2.

Varför en ensam hash inte stoppar en aktiv angripare

Det klassiska mönstret är enkelt: avsändaren beräknar en hash av meddelandet, skickar både meddelandet och hashvärdet, och mottagaren beräknar hashvärdet på nytt. Om värdena matchar har mottagaren stark indikation på att det mottagna meddelandet motsvarar det hashvärde som skickades.

Problemet uppstår när angriparen kan ändra båda delarna. Vid en man-in-the-middle-attack kan meddelandet bytas ut, en ny hash beräknas och båda skickas vidare. Mottagaren ser då en perfekt matchning mellan meddelande och hashvärde, trots att inget bevisar att hashvärdet kom från rätt avsändare. Hashen visar konsekvens mellan två objekt, inte tillit till ursprunget.

Detta är skälet till att integritet i säkerhetsarkitektur nästan alltid måste kopplas till autenticitet. En filhash på en nedladdningssida kan vara användbar om hashvärdet publiceras via en separat betrodd kanal. Om både filen och hashvärdet kan manipuleras på samma plats är skyddet svagt. Samma princip gäller API-anrop, webbhooks, containerbilder, programuppdateringar och meddelandeköer.

Length-extension och varför naiva konstruktioner är riskabla

En vanlig missuppfattning är att en hemlig sträng framför meddelandet räcker för att skapa en säker meddelandekod, till exempel genom att beräkna hash(secret || message). För hashfunktioner med Merkle-Damgård-konstruktion, däribland MD5 och flera SHA-2-varianter, kan sådana naiva konstruktioner vara sårbara för length-extension-attacker. Angriparen behöver inte känna till den hemliga nyckeln för att i vissa fall kunna förlänga meddelandet och beräkna ett giltigt nytt hashvärde.

Det praktiska felet är inte att SHA-256 som hashfunktion plötsligt är oanvändbar. Felet är att den används som meddelandeautentisering på ett sätt den inte är avsedd för. RFC 2104 definierar HMAC just för att hantera detta mönster säkert. För SHA-3-familjens ekosystem finns även KMAC definierat i NIST SP 800-185, vilket bygger på Keccak-baserade konstruktioner.

HMAC: integritet med delad hemlighet

HMAC kombinerar en kryptografisk hashfunktion med en hemlig nyckel enligt en definierad konstruktion. Mottagaren som känner samma nyckel kan beräkna samma kod och verifiera att meddelandet inte har ändrats av någon utan nyckeln. Det betyder att HMAC ger både integritet och autenticitet inom ramen för en delad hemlighet.

Skillnaden mot en vanlig hash är avgörande. En angripare kan beräkna en ny SHA-256-hash för ett manipulerat meddelande, men kan inte skapa en korrekt HMAC utan nyckeln. Därför används HMAC ofta för API-signering, webhook-verifiering, intern tjänst-till-tjänst-kommunikation och logik där båda parter redan kan hantera en gemensam hemlighet säkert.

HMAC passar särskilt väl när verifieringen sker i ett begränsat system där nyckeldistributionen är kontrollerad och snabb verifiering är viktig. Digitala signaturer passar bättre när många oberoende parter behöver verifiera ett meddelande utan att dela en hemlighet, eller när avsändaren behöver kunna hållas ansvarig i efterhand. Det enkla beslutsramverket är därför: använd HMAC eller KMAC när parterna kan dela en hemlig nyckel; använd digital signatur när verifiering ska fungera över organisationsgränser, över tid eller i större distributionskedjor.

Example — verifiera en HMAC i Python

Det här exemplet visar ett vanligt servermönster för att verifiera ett inkommande meddelande med HMAC-SHA-256. Poängen är inte syntaxen i sig, utan att jämförelsen sker i konstant tid och att bytes-representationen är entydig.

import hmac
import hashlib

shared_key = b"service-signing-key-rotated-2026"
message = b'{"invoice":"INV-2048","amount":"1250.00","currency":"SEK"}'
received_mac_hex = "0f4f6f0b2e7a4c51f0f40f5c3a0c3c9e6a5b2d51e2bb3c1dd0c0f6c780d5a37b"

calculated_mac = hmac.new(
    shared_key,
    message,
    hashlib.sha256
).hexdigest()

if hmac.compare_digest(calculated_mac, received_mac_hex):
    print("Meddelandet är oförändrat och kommer från en part med rätt nyckel.")
else:
    print("Verifieringen misslyckades.")

I en verklig implementation behöver nyckeln hämtas från en säker hemlighetshanterare, inte hårdkodas. Mottagaren måste även beräkna HMAC över exakt samma byteföljd som avsändaren använde; skillnader i JSON-kanonisering, radslut, teckenkodning eller sortering av fält kan annars ge falska fel.

Digitala signaturer, hashing och PKI

Digitala signaturer använder också hashfunktioner, men med en annan tillitsmodell. I stället för att två parter delar en hemlig nyckel skapar avsändaren en signatur med en privat nyckel, medan mottagaren verifierar signaturen med motsvarande publika nyckel. Själva meddelandet hashades vanligtvis först, eftersom det är effektivare och säkrare att signera ett fast digest än att direkt behandla hela meddelandet i signaturalgoritmen.

Den praktiska styrkan ligger i nyckelmodellen. Med HMAC kan alla som verifierar också skapa giltiga koder, eftersom samma hemlighet används på båda sidor. Med digital signatur kan många verifiera utan att kunna signera. Det gör signaturer lämpliga för programuppdateringar, kodsignering, dokumentflöden, certifikat, containerkedjor och paketdistribution.

PKI tillför bindningen mellan publik nyckel och identitet. Utan en betrodd mekanism för att veta vems publika nyckel som används kan en angripare ersätta nyckeln och genomföra en man-in-the-middle-attack. Certifikat, certifikatkedjor och betrodda rotcertifikat är därför inte dekorativa tillägg, utan en del av svaret på frågan om vem mottagaren faktiskt litar på.

Praktiska tillämpningar där detaljerna avgör

Filhämtningar med SHA-256-summor är ett tydligt exempel. Om en leverantör publicerar en fil och ett separat hashvärde kan mottagaren kontrollera att filen är oförändrad. Värdet är starkast när hashvärdet kommer från en kanal som angriparen inte kontrollerar, exempelvis en signerad release, en betrodd pakethanterare eller ett verifierat distributionssystem.

På webben används Subresource Integrity för att låta en webbläsare kontrollera att ett externt skript eller formatmall motsvarar ett väntat hashvärde. I pakethanterare kombineras hashvärden ofta med signaturer och metadata. I container- och mjukvarukedjor används digestvärden för att referera till exakt artefakt, medan signering och attestering hjälper till att besvara vem som skapade artefakten och under vilka villkor.

Implementeringsfällorna är ofta mer vardagliga än algoritmvalet. Ett system kan använda SHA-256 och ändå misslyckas om olika komponenter hashar olika representationer av samma information. JSON kan serialiseras med olika fältordning, text kan normaliseras olika i Unicode, radslut kan skilja mellan plattformar och Base64 kan blandas ihop med hexkodning. Därför bör protokollet definiera exakt vilka bytes som ska verifieras, inte bara vilket logiskt objekt som avses.

Jämförelsen av hemliga verifieringsvärden kräver också omsorg. Vanlig strängjämförelse kan i vissa miljöer läcka tidsinformation beroende på var den första skillnaden finns. Konstanttids-jämförelse är därför standardpraxis för HMAC- och tokenverifiering. Samtidigt behöver felmeddelanden hållas återhållsamma, så att en angripare inte får detaljer om huruvida format, nyckelidentifierare eller MAC-värde var närmast rätt.

En verifieringsprocess som håller i drift

En tekniskt korrekt hash- eller HMAC-funktion räcker inte om processen runt den är svag. Integritetskontroller behöver passa in i distribution, nyckelrotation, loggning och incidenthantering. Annars uppstår ett glapp mellan vad algoritmen kan garantera och vad systemet faktiskt bevisar.

1. Definiera först hotbilden och avgör om målet är felupptäckt, integritet, autenticitet eller signerbar distribution.
2. Välj därefter en modern mekanism, exempelvis SHA-256 för betrodd hashjämförelse, HMAC-SHA-256 för delad hemlighet eller en digital signatur för publik verifiering.
3. Specificera exakt kanonisering, teckenkodning och byteföljd innan värdet beräknas.
4. Skydda nycklar, rotationsrutiner och publika verifieringsnycklar med samma omsorg som själva verifieringskoden.
5. Verifiera med konstanttids-jämförelse där hemliga värden jämförs och logga misslyckanden utan att läcka verifieringsdetaljer.

Denna ordning minskar risken för ett vanligt misstag: att börja med algoritmnamnet och först senare upptäcka att systemet saknar en betrodd kanal, en tydlig nyckelmodell eller en stabil dataserialisering. I praktiken är dessa arkitekturbeslut ofta viktigare än skillnaden mellan två moderna hashfamiljer.

Att välja rätt skydd för meddelandeintegritet

Meddelandeintegritet börjar med en hashfunktion, men slutar sällan där. En hash kan bevisa att data matchar ett känt värde, HMAC kan visa att data kom från någon med rätt delade hemlighet, och digitala signaturer kan göra verifiering möjlig utan att verifieraren får förmågan att skapa nya giltiga meddelanden. Valet beror på hotbild, distributionsmodell och hur tillit ska etableras.

En praktisk väg framåt är att behandla hashvärden som byggstenar i ett protokoll snarare än som ett färdigt skydd. Den som vill sätta mekanismerna i en bredare säkerhets- och styrningskontext kan läsa vidare om CISSP-översikt och CISM-översikt, samt den äldre bakgrundssidan om Kevin Henry. Det viktigaste beslutet är ändå tekniskt: välj mekanism efter vem som ska kunna verifiera, vem som ska kunna skapa värdet och vilken kanal angriparen kan påverka.