AES i korte træk

AES (Advanced Encryption Standard) er en udbredt standard for symmetrisk kryptering. Det betyder, at den samme hemmelige nøgle bruges til både at kryptere og dekryptere data. AES er en blokciffer: den behandler data i blokke med fast størrelse, i stedet for at kryptere hele en fil eller en lang datastrøm på én gang.

I praksis møder du ofte AES ved beskyttelse af data i transit og på lager. Men selve “AES” beskriver kernen i krypteringsalgoritmen; hvordan du bruger den i et system (fx til lange meddelelser, gentagne beskeder og registrering af manipulation) afhænger af de omkringliggende byggesten som driftstilstand og integritetsmekanismer.

Et simpelt modelbillede af hvordan AES arbejder

Forestil dig en blok som en række bits, der skal omdannes til en uigenkendelig form. AES tager en blok og en nøgle og udfører et antal beregningsrunder, der omformer dataen ved hjælp af nøglen. Resultatet er en krypteret blok (ciphertext). Når du vil dekryptere, anvendes samme nøgle og AES’ omvendte proces til at genskabe den oprindelige blok.

Vigtige grundbegreber:

  • Nøglestørrelse: AES findes i varianter med forskellige nøglelængder. I konkrete systemer er det afgørende, at den nøgle du bruger, matcher den valgte AES-variant.
  • Blokstørrelse: AES arbejder på blokke af fast størrelse, så input der ikke passer helt, må håndteres (typisk via padding, eller ved at bruge en mode der håndterer længde).
  • Runder (rounds): AES’ sikkerhed bygger bl.a. på et veldefineret antal transformationer, der gør output svært at knække uden nøgle.

Det centrale er, at AES i sig selv ikke “løser” alle problemer alene. Hvis man bare krypterer rå blokke uden korrekt mode og uden integritetsbeskyttelse, kan et system stadig få svagheder.

Driftstilstande og implementering på lange data

Når data ikke kun er én blok, skal AES kobles til en driftstilstand (cipher mode). Driftstilstanden bestemmer, hvordan blokkryptering kombineres, og hvilken rolle en tilfældig værdi (fx IV/nonce) spiller.

Typisk udfordringer ved implementering:

  • Længde og padding: Hvis længden ikke er et helt antal blokke, skal du håndtere resten. Nogle modes kan undgå klassisk padding ved at bruge konstruktioner, der matcher længde, men mange løsninger involverer en eller anden form for padding. Den skal bruges korrekt; forkert padding kan give lækage af oplysninger.
  • Gentagelser: Hvis du krypterer den samme besked med samme nøgle på en måde der genbruger for meget struktur, kan det i nogle scenarier give mønstre, som en angriber kan udnytte.
  • IV/nonce-håndtering: Mange driftstilstande kræver en startværdi (IV) eller nonce, som ofte skal være tilfældig eller på anden måde ikke-genbruges på samme nøgle. Hvordan præcist dette skal gøres afhænger af mode og algoritmekrav.

En sikker implementeringspraksis er derfor ikke bare “vælg AES”, men “vælg en passende mode og brug den som specificeret”.

Integritet: hvorfor ren kryptering ofte ikke er nok

Kryptering skjuler indholdet, men den garanterer ikke i sig selv, at ciphertext ikke er blevet ændret. I mange systemer ønsker man at opdage, hvis en angriber har manipuleret data.

Derfor bruges ofte en kombination af:

  • Kryptering (så indholdet er skjult)
  • Godkendelse/integritet (så ændringer kan opdages)

I praksis kan dette implementeres med AEAD-konstruktioner (Authenticated Encryption with Associated Data) eller ved at bruge en separat MAC (Message Authentication Code) i en sikker opsætning. Hvilken løsning der passer, afhænger af dine krav og hvordan systemet håndterer nøgler, ikke-standardiserede felter og fejlbeskeder.

Vigtig nuance: Integritet kan kun fungere, hvis den er korrekt knyttet til de relevante data (og typisk også inkluderer længde/metadata, hvor det er relevant). Ellers kan angriberen stadig udnytte designhuller.

Forskelle og grænser: hvad AES kan og ikke kan

AES er velegnet til selve krypteringsoperationen, men det betyder ikke, at et system automatisk bliver sikkert. Følgende grænser er værd at kende:

  • AES alene giver ikke automatisk beskyttelse mod manipulation. Du skal vælge en mode/konstruktion der også håndterer integritet.
  • Sikkerhed afhænger af hele opsætningen. Mode-valg, IV/nonce-adfærd, padding-strategi, fejlhåndtering og hvordan nøgler distribueres påvirker reelt sikkerhedsniveau.
  • Fejl i implementering kan blive den svage led. Typiske problemer er genbrug af nonce/IV, forkert key size, forkert håndtering af padding eller lækage via detaljerede fejlbeskeder.

En anden praktisk begrænsning er, at det at “implementere selv” kræver stor disciplin. I mange miljøer er det mere robust at bruge gennemprøvede kryptobiblioteker og deres anbefalede API-mønstre end at opbygge konstruktioner manuelt.

Praktisk kontrolliste til implementering

Her er kontrolpunkter, der hjælper dig med at vurdere, om en AES-implementering er fornuftig, uden at love noget udover det, algoritmen og den konkrete opsætning kan give:

  1. Bekræft nøgle og variant: Nøglestørrelse skal matche den valgte AES-variant, og nøglen skal holdes hemmelig.

  2. Vælg driftstilstand med omtanke: Til lange beskeder skal du bruge en mode, der håndterer længde korrekt og ikke skaber uønskede mønstre.

  3. Håndtér IV/nonce korrekt: Brug den forventede type værdi (IV eller nonce) og undgå genbrug på samme nøgle i de scenarier hvor det er relevant.

  4. Tilføj integritet: Overvej AEAD eller en tilsvarende godkendelsesmekanisme, så ændringer kan opdages.

  5. Tjek fejl- og sideeffektadfærd: Sørg for ensartet håndtering af ugyldige input og undgå at lække oplysninger via differentierede fejl.

Hvis du gennemgår en konkret implementering med punkterne ovenfor, kan du typisk identificere de største risici: forkert mode, forkert længde/padding, og dårlig nonce/IV eller integritetsbehandling.

Hvad kan ændre dit svar?

Din bedste “AES-forståelse” kan variere en smule afhængigt af, hvilken sammenhæng du spørger i (fx filkryptering, netværksprotokoller eller databaser). Det er især mode og integritetsstrategi, der kan flytte fokus fra “hvordan AES fungerer” til “hvordan hele beskeden pakkes, krypteres og verificeres”. Hvis du arbejder med et eksisterende system, kan dokumentationen for den konkrete krypteringsopsætning være afgørende—det er der, de praktiske valg typisk ligger.