Hvad er meddelelsesintegritet, og hvornår er hashing nok?

Meddelelsesintegritet handler om at opdage, om data er blevet ændret under transport eller lagring. Støj på kabler, fejl på disketter og beskadigede filer gjorde simple kontrolmekanismer nødvendige længe før moderne kryptografi blev en del af almindelige IT-systemer.

Meddelelsesintegritet handler om at kunne afgøre, om en besked, fil eller datastrøm er den samme, når den modtages eller verificeres, som da den blev sendt eller gemt. Det lyder enkelt, men den rigtige metode afhænger af trusselsbilledet: utilsigtede fejl kræver ikke samme beskyttelse som en aktiv angriber, der kan ændre både indhold og kontrolværdi.

Opdateret: 2026. Denne version præciserer forskellen mellem fejlregistrering og kryptografisk integritet, opdaterer algoritmeanbefalinger for MD5, SHA-1, SHA-2 og SHA-3 og tilføjer praktiske valg mellem hash, HMAC og digitale signaturer.

Fra paritet og CRC til kryptografisk integritet

Paritetsbits, kontrolcifre og Cyclic Redundancy Checks, ofte forkortet CRC, blev udviklet til at opdage fejl, der typisk opstår uden en modstander. Hvis en bit vendes på grund af støj, eller en fil beskadiges under lagring, kan en CRC ofte afsløre, at noget er galt. Det er værdifuldt i protokoller, filformater og hardwarekommunikation, hvor problemet primært er tilfældige fejl.

Den vigtige grænse er, at CRC og lignende checks ikke er designet til at modstå manipulation. En angriber, der kan ændre beskeden, kan i mange tilfælde også beregne en ny CRC, der passer til den ændrede besked. Derfor skal fejlregistrering og kryptografisk integritet behandles som to forskellige discipliner, selv om begge handler om at opdage ændringer.

Kryptografiske hashfunktioner løser en stærkere opgave. De beregner et fastlængdeaftryk af en hel besked, så selv små ændringer normalt giver et helt andet resultat. Hashen kaldes også en message digest, et fingeraftryk eller en checksum, men i sikkerhedssammenhæng bør ordet checksum bruges med omhu, fordi ikke alle checksums har kryptografiske egenskaber.

Hvad en kryptografisk hashfunktion skal kunne

En hashfunktion tager data af vilkårlig længde og producerer en værdi med fast længde. For SHA-256 er resultatet for eksempel altid samme størrelse, uanset om input er en kort API-besked eller en stor installationsfil. Modtageren kan beregne hashværdien igen og sammenligne den med den forventede værdi.

For sikkerhedsbrug er tre egenskaber centrale. Preimage-resistens betyder, at det skal være praktisk umuligt at finde en besked, der giver en bestemt hashværdi. Second-preimage-resistens betyder, at det skal være praktisk umuligt at finde en anden besked med samme hash som en kendt besked. Kollisionsresistens betyder, at det skal være praktisk umuligt at finde to forskellige beskeder med samme hash.

Det er især kollisionsresistens, der har gjort ældre algoritmer problematiske. MD5 og SHA-1 har kendte svagheder, som gør dem uegnede til sikkerhedsformål som certifikater, signaturer og integritetskontrol mod angribere. De kan stadig ses som ikke-sikkerhedsrelaterede checksums i ældre systemer, men de bør ikke vælges til nye sikkerhedsdesigns.

Hash alene beskytter ikke mod en aktiv angriber

En almindelig misforståelse er, at en hash ved siden af en besked automatisk beviser, at beskeden er ægte. Det gør den kun, hvis modtageren allerede har en betroet måde at kende den rigtige hashværdi på. Hvis besked og hash sendes sammen over en kanal, som en angriber kan ændre, kan angriberen ændre begge dele.

Et Man-in-the-Middle-angreb illustrerer problemet. Afsenderen sender en besked med en hashværdi. Angriberen ændrer beskeden, beregner en ny hash og sender begge videre. Modtagerens kontrol lykkes, fordi hashværdien passer til den ændrede besked, men kontrollen siger intet om, hvem der beregnede hashværdien.

Derfor er hash alene mest egnet, når hashværdien kommer fra en betroet kilde eller bruges i en lokal kontekst. Det kan for eksempel være en administrator, der kontrollerer, om en downloadet fil matcher en hashværdi offentliggjort via en separat, betroet kanal. Hvis samme kanal kan ændre både fil og hash, er kontrollen svag.

Hvornår HMAC er det rigtige valg

HMAC, beskrevet i RFC 2104, kombinerer en kryptografisk hashfunktion med en delt hemmelig nøgle. Det betyder, at en angriber ikke kan beregne en gyldig HMAC for en ændret besked uden at kende nøglen. Hvor en almindelig hash kun viser, at data passer til en bestemt værdi, viser HMAC også, at værdien blev beregnet af nogen med adgang til den fælles hemmelighed.

I praksis bruges HMAC ofte til API-kald, webhooks og intern servicekommunikation. Klienten beregner en HMAC over udvalgte dele af requesten, for eksempel metode, sti, timestamp og body. Serveren beregner samme værdi med den delte nøgle og afviser requesten, hvis værdierne ikke matcher eller timestampet er for gammelt.

HMAC passer bedst, når begge parter må kende samme hemmelighed, og hvor der ikke er behov for offentlig verificering. Det kræver god nøglehåndtering, rotation og beskyttelse af hemmeligheder i CI/CD, cloud secret stores og applikationskonfiguration. En hyppig fejl er at forsøge at opfinde sin egen MAC ved blot at sætte en nøgle foran eller bag en besked og hashe resultatet; HMAC findes netop for at undgå den type svage konstruktioner.

Hvornår digitale signaturer er bedre

Digitale signaturer bruger asymmetrisk kryptografi. Afsenderen signerer med en privat nøgle, og alle med den tilsvarende offentlige nøgle kan verificere signaturen. Det gør signaturer velegnede, når mange modtagere skal kunne kontrollere integritet uden at kende en fælles hemmelighed.

Softwareopdateringer er et godt eksempel. Leverandøren signerer pakken, og klienter kan kontrollere signaturen, før de installerer. Pakkehåndtering, dokumentworkflow og certifikatbaseret tillid i TLS bygger på samme grundlæggende idé: integritet skal knyttes til en nøgleidentitet, ikke kun til en beregnet hashværdi.

Signaturer er også relevante, når der er krav om ikke-benægtelse eller sporbar ansvarlighed. Det betyder ikke, at en signatur alene løser hele governance-problemet; private nøgler kan kompromitteres, certifikater kan udløbe, og tilbagekaldelse skal håndteres. Men signaturer giver en anden tillidsmodel end HMAC, fordi verifikation kan ske med en offentlig nøgle. En dybere forklaring af denne model findes i den oprindelige sikkerhedsserie.

Algoritmevalg i 2026

Til nye løsninger bør MD5 og SHA-1 undgås til sikkerhedsformål. Det er ikke nødvendigt at beskrive dem som værdiløse i alle sammenhænge; de kan stadig forekomme i ældre systemer og som simple identifikatorer uden sikkerhedskrav. Problemet opstår, når de bruges til at beskytte mod en modstander, fordi kendte svagheder gør dem utilstrækkelige til moderne integritets- og signaturbrug.

SHA-2-familien, herunder SHA-256 og SHA-512, er stadig almindeligt anvendt og understøttet bredt i standardbiblioteker, protokoller og cloudtjenester. SHA-3, standardiseret i FIPS 202 og baseret på Keccak-konstruktionen, er ikke en direkte opgradering af SHA-2, men en anden hashfamilie med en anden intern konstruktion. Valget mellem SHA-2 og SHA-3 bør derfor afhænge af platformunderstøttelse, krav, interoperabilitet og den standard, systemet skal følge.

NIST FIPS 180-4 beskriver SHA-1 og SHA-2-familien, mens NIST SP 800-107r1 giver vejledning om brug af hashfunktioner i kryptografiske applikationer. I mange organisationer er den praktiske anbefaling enkel: brug veldokumenterede biblioteker, vælg moderne algoritmer som SHA-256, SHA-512 eller SHA-3, og undgå specialbyggede kryptografiske konstruktioner uden en etableret standard.

Implementeringsfejl der ofte giver svage kontroller

Selv et korrekt algoritmevalg kan fejle i implementeringen. En klassisk årsag til falske mismatch er inkonsistent encoding. Hvis én komponent hasher UTF-8, mens en anden hasher en anden tekstkodning, eller hvis linjeskift normaliseres forskelligt på Windows og Linux, kan to logisk ens beskeder give forskellige hashværdier.

Normalisering er særlig vigtig ved JSON, XML og API-signering. Whitespace, feltrækkefølge, store og små bogstaver i headernavne og tidsformater kan ændre den byte-sekvens, der faktisk hashes eller signeres. Derfor bør systemet definere præcist, hvilke bytes der indgår i beregningen, og hvordan data serialiseres før verificering.

Store filer bør hashes som streams i stedet for at læses fuldt ind i hukommelsen. Det forbedrer robusthed og gør kontrollen mere egnet til pipelines, objektlagring og artefaktrepositories. Samtidig bør den gemte kontrolværdi altid ledsages af algoritme-ID, for eksempel SHA-256, så fremtidige migreringer ikke bliver afhængige af gæt eller uformelle navnekonventioner.

Et andet praktisk punkt er sammenligning af værdier. Ved sikkerhedsfølsom verifikation bør systemet bruge bibliotekernes sikre sammenligningsfunktioner, hvor de findes, så timingforskelle ikke afslører nyttig information. Det er især relevant for HMAC-baserede API-kontroller, hvor en angriber kan sende mange forsøg og observere svarmønstre.

En enkel beslutningsramme

Det mest nyttige spørgsmål er ikke, hvilken metode der er stærkest i abstrakt forstand, men hvilken trussel der skal håndteres. Hash, HMAC og digitale signaturer har forskellige tillidsmodeller, og det forkerte valg giver ofte en falsk følelse af sikkerhed.

• Brug hash alene, når der ikke er en aktiv modstander i kontrolkanalen, eller når hashværdien kommer fra en separat betroet kilde.
• Brug HMAC, når to systemer deler en hemmelig nøgle og skal opdage ændringer eller forfalskede beskeder.
• Brug digitale signaturer, når modtagere skal kunne verificere afsenderen uden at kende en hemmelig nøgle, eller når der er krav om offentlig verificering, PKI eller ikke-benægtelse.

Denne ramme dækker mange almindelige beslutninger. En lokal filintegritetskontrol kan ofte nøjes med en hash. Et webhook fra en betalingstjeneste bør typisk bruge HMAC eller en tilsvarende standardiseret signeringsmekanisme. En softwarepakke, der distribueres til mange kunder, bør signeres, så hver modtager kan verificere pakken uden adgang til leverandørens private nøgle.

Ofte stillede spørgsmål om meddelelsesintegritet

Er en hashværdi det samme som kryptering?

Nej. Kryptering er designet til at kunne dekrypteres af en autoriseret part, mens en hashfunktion er envejs. En hash bruges til sammenligning og integritetskontrol, ikke til at skjule indhold.

Kan en hash bevise, hvem der sendte en besked?

Ikke alene. En almindelig hash indeholder ingen hemmelighed og ingen privat nøgle. Hvis afsenderidentitet eller autenticitet er et krav, skal systemet normalt bruge HMAC, digitale signaturer eller en protokol, der allerede indeholder en integritets- og autenticitetsmekanisme.

Er SHA-3 bedre end SHA-2?

SHA-3 er en anden standardiseret hashfamilie, ikke blot en nyere version af SHA-2. SHA-2 er stadig bredt anvendt, mens SHA-3 kan være relevant, hvor krav, arkitektur eller standardvalg peger på Keccak-baserede funktioner.

Hvorfor bruges MD5 stadig nogle steder?

MD5 findes stadig i ældre systemer og i sammenhænge, hvor værdien bruges som en simpel ikke-sikkerhedsrelateret identifikator. Det bør ikke bruges til nye sikkerhedsfunktioner, fordi kollisionssvagheder gør det uegnet til at modstå en målrettet angriber.

At omsætte integritet til sikre systemer

Meddelelsesintegritet bliver først effektiv, når metoden matcher den virkelige risiko. Paritet og CRC opdager tilfældige fejl. Hashfunktioner bekræfter, at data matcher en kendt værdi. HMAC beskytter integritet mellem parter med en delt hemmelighed, mens digitale signaturer gør verifikation mulig med offentlige nøgler og understøtter bredere tillidsmodeller.

Den praktiske næste handling er at gennemgå, hvor systemer i dag bruger checksums, hashes eller signaturer, og vurdere om de faktisk passer til trusselsmodellen. Læsere, der arbejder med sikkerhedsledelse eller certificeringsforberedelse, kan bruge emnerne som bro til bredere sikkerhedsdomæner som CISSP-overblik og CISM-overblik; Readynez dækker disse områder i en uddannelseskontekst, men de tekniske valg bør altid forankres i systemets konkrete risiko, nøgler og standarder.