Protokoller og brannmurer

Sikker e-post

Tre mål: konfidensialitet, integritet og autentisering — og Alice bruker tre forskjellige nøkler for å oppnå dem alle.

E-post er det perfekte eksempelet for å sette sammen alle «puslespillbitene» vi har lært så langt. Tenk deg at Alice vil sende en e-post til Bob som er (1) konfidensiell — bare Bob kan lese den, (2) autentisert — Bob kan verifisere at det er Alice som har skrevet den, og (3) integritetssjekket — innholdet kan ikke endres underveis. La oss bygge opp løsningen trinn for trinn.

Steg 1: Bare konfidensialitet

Alice kunne kryptere hele meldingen med Bobs offentlige nøkkel, men det er altfor tregt for en lang e-post. I stedet gjør hun noe smart:

1. Generer en tilfeldig symmetrisk sesjonsnøkkel K_S
2. Krypter meldingen med K_S (raskt, med f.eks. AES)
3. Krypter K_S med Bobs offentlige nøkkel K_B⁺ (tregt, men K_S er kort)
4. Send både K_S(m) og K_B⁺(K_S) til Bob

Bob bruker sin private nøkkel til å dekryptere K_S, og bruker deretter K_S til å dekryptere selve meldingen. Dette er hybridkryptering — det beste fra begge verdener.

Steg 2: Bare integritet og autentisering

Noen ganger trenger ikke meldingen å være hemmelig, men mottakeren skal kunne verifisere hvem som sendte den. Alice beregner H(m), signerer hashen med sin egen private nøkkel K_A⁻, og sender både meldingen (i klartekst) og signaturen K_A⁻(H(m)). Bob verifiserer med Alices offentlige nøkkel.

Steg 3: Alt sammen

For full sikkerhet kombinerer Alice de to teknikkene. Hun bruker tre nøkler:

Bob gjør de komplementære operasjonene i omvendt rekkefølge: dekrypter K_S med sin private nøkkel, dekrypter meldingen med K_S, sjekk signaturen med Alices offentlige nøkkel.

TLS: sikring av TCP-forbindelser

Det mest utbredte sikkerhetslaget på Internett — det som gjør HTTPS mulig.

Transport Layer Security (TLS) er protokollen som legger et sikkerhetslag oppå TCP. Når du ser hengelåsen i nettleseren og «https» i URL-en, er det TLS som arbeider under panseret. TLS gir de tre klassiske egenskapene — konfidensialitet (via symmetrisk kryptering), integritet (via kryptografisk hashing) og autentisering (via offentlig nøkkelkryptografi og sertifikater) — med alle teknikkene vi allerede har lært.

Hvor bor TLS i protokollstabelen?

TLS er ikke et eget lag i tradisjonell forstand — det er et sublag som ligger mellom TCP og applikasjonslaget. Applikasjonen (f.eks. en nettleser) skriver data til en «TLS socket» i stedet for en vanlig TCP-socket. TLS krypterer dataene og sender dem ned til TCP som vanlige TCP-segmenter. For TCP og IP under ser alt normalt ut — de vet ikke at innholdet er kryptert.

Fire faser i en TLS-forbindelse

Vi kan forstå TLS ved å bygge en forenklet «toy-TLS» (t-tls) og se hva hver fase trenger:

Nøkkelutledning (key derivation)

Etter håndtrykket har Alice og Bob en felles «master secret». Men det anses som dårlig praksis å bruke én nøkkel til alt. Derfor utleder de fire separate nøkler fra master secret:

• E_A — krypteringsnøkkel for data fra Alice til Bob
• E_B — krypteringsnøkkel for data fra Bob til Alice
• M_A — MAC-nøkkel for data fra Alice til Bob
• M_B — MAC-nøkkel for data fra Bob til Alice

Record-basert kryptering

TCP gir en byte-strøm, men TLS kan ikke kryptere strømmen fortløpende — for da ville MAC-en først komme på slutten, og mottakeren ville ikke kunne sjekke integriteten før hele forbindelsen lukkes. Løsningen: TLS deler strømmen opp i records. Hver record inneholder data, en MAC for integritet, og en lengde. Hele recorden krypteres med sesjonsnøkkelen før den sendes til TCP.

Et viktig poeng: MAC-en beregnes ikke bare over selve dataene i recorden — den inkluderer også et sekvensnummer. Selv om sekvensnummeret ikke sendes eksplisitt i recorden, holder begge parter en intern teller. Uten sekvensnumre kunne Trudy fange opp en record og spille den av på nytt (replay-angrep), eller omorganisere rekkefølgen på records uten at mottakeren oppdager det. Med sekvensnummeret i MAC-beregningen vil enhver slik manipulasjon føre til at MAC-verifiseringen feiler.

TLS 1.3 og cipher suites

En «cipher suite» er et sett av algoritmer som brukes sammen: én for nøkkelutveksling, én for kryptering, én for MAC og én for digital signatur. TLS 1.3 (RFC 8446, 2018) er den nyeste versjonen og har strammet inn valgene kraftig.

IPsec og VPN

Sikkerhet på nettverkslaget — der hele IP-datagrammer krypteres og autentiseres.

TLS sikrer enkelttransportforbindelser (én TCP-forbindelse om gangen). Men hva om du vil sikre all trafikk mellom to nettverk — uansett applikasjon, uansett port? Da trenger du sikkerhet på nettverkslaget, og det er der IPsec kommer inn. IPsec gir kryptering, autentisering og integritetskontroll på datagram-nivå, for både brukerdata og kontrolltrafikk (BGP, DNS, osv.).

Security Association (SA)

Før IPsec kan sende et eneste kryptert datagram, må de to endepunktene opprette en Security Association (SA) — en enveis logisk forbindelse som definerer sikkerhetsparameterne for trafikken. Hver SA identifiseres av tre ting:

• SPI (Security Parameter Index): et 32-bits tall som inkluderes i hvert IPsec-datagram, slik at mottakeren vet hvilken SA (og dermed hvilke nøkler og algoritmer) pakken tilhører.
• Destinasjons-IP: adressen til den andre enden av SA-en.
• Protokollidentifikator: om SA-en bruker AH eller ESP.

Fordi en SA er enveis, trengs det to SA-er for toveis kommunikasjon — én i hver retning, hver med sin egen SPI og sine egne nøkler. Alle aktive SA-er lagres i en SAD (Security Association Database) på begge endepunkter. Når et IPsec-datagram ankommer, bruker mottakeren SPI-verdien i headeren til å slå opp riktig SA i SAD-en og dermed finne krypteringsnøkkelen og algoritmen som trengs for å dekryptere.

To moduser

Tunnel-modus er fundamentet for VPN (Virtual Private Network). Tenk på et selskap med kontorer i Oslo og Trondheim. Begge kontorene er koblet til Internett, og mellom gateway-ruterne på hvert kontor settes det opp en IPsec-tunnel. All trafikk mellom de to kontornettene pakkes inn i krypterte IP-datagrammer og tunneleres over det offentlige Internett. For brukerens PC ser det ut som om den er på samme lokalnett — men i virkeligheten er alt kryptert underveis.

To protokoller

ESP er klart den mest brukte av de to — den gir alle tre egenskapene. AH gir bare autentisering og integritet (men ingen kryptering), og er sjelden brukt alene i moderne nettverk.

Sikkerhet i trådløse nett

Hvordan WiFi (802.11) og mobilnett (4G/5G) autentiserer enheter og krypterer trafikk over lufta.

Alt vi har sett så langt — kryptering, signaturer, CA-er — er generelle mekanismer. Men trådløse nettverk har et spesielt behov: enheten som kobler seg til må autentisere seg før den får noen som helst tilgang til nettverket, og all trafikk over lufta må krypteres fordi radiobølger er trivielt enkle å avlytte. La oss se hvordan WiFi og 4G/5G løser dette.

802.11 WiFi: fire steg til sikker kommunikasjon

Når en mobilenhet kobler seg til et WiFi-nettverk med WPA3, gjennomgår den fire steg:

WPA3-håndtrykket i detalj

Steg 2 (gjensidig autentisering og nøkkelutledning) er det mest interessante. I WPA3 foregår det slik:

1. AS sender Nonce_AS — et tilfeldig engangsbrukstall — til mobilenheten.
2. Mobilenheten genererer Nonce_M, utleder en symmetrisk sesjonsnøkkel K_M-AP fra begge nonce-ene, det forhåndsdelte passordet og MAC-adressene, og sender Nonce_M pluss en HMAC-signert verdi tilbake.
3. AS utleder samme K_M-AP med samme ingredienser, verifiserer HMAC-en, og begge parter har nå en felles sesjonsnøkkel — uten at passordet noensinne ble sendt over lufta.

4G LTE: autentisering med SIM-kort

Mobilnett er fundamentalt annerledes enn WiFi fordi identiteten ligger i SIM-kortet, ikke i et passord. SIM-kortet inneholder en globalt unik identifikator (IMSI) og en forhåndsdelt hemmelig nøkkel K_HSS-M som bare SIM-kortet og hjemmenettverkets HSS (Home Subscriber Server) kjenner.

Autentiseringsflyten i 4G involverer flere aktører:

Autentiseringsflyt (forenklet)

1. a) Mobilen sender attach-melding med IMSI via basestasjon og MME til HSS i hjemmenettverket.
2. b) HSS bruker den forhåndsdelte nøkkelen K_HSS-M til å beregne et auth_token og en forventet respons xres_HSS. Auth_token inneholder kryptert informasjon som bare mobilenheten kan verifisere. HSS sender begge til MME.
3. c) MME sender auth_token videre til mobilen. Mobilen verifiserer auth_token med sin egen nøkkel — og vet dermed at nettverket er ekte. Mobilen beregner sin egen respons res_M og sender den tilbake.
4. d) MME sammenligner res_M med xres_HSS. Hvis de stemmer, er mobilen autentisert. MME informerer basestasjon og genererer sesjonsnøkler.
5. e) Mobilen og basestasjonen utleder krypteringsnøkler K_BS-M for å kryptere all videre kommunikasjon over 4G-linken (typisk med AES).

Fra 4G til 5G: viktige endringer

Den mest bemerkelsesverdige forbedringen i 5G er at IMSI nå krypteres — i 4G ble den sendt i klartekst, noe som muliggjorde IMSI-catchers (falske basestasjoner som fanger opp mobil-identiteter).

Brannmurer

Den første forsvarslinjen mellom det interne nettverket og det ville Internett.

Kryptografi beskytter innholdet i kommunikasjonen, men det er ikke alltid nok. En organisasjon trenger også å kontrollere hvilken trafikk som i det hele tatt slipper inn og ut av nettverket. Det er jobben til en brannmur (firewall): den sitter mellom organisasjonens interne nettverk og det offentlige Internett, og filtrerer pakker basert på et sett med regler.

Hvorfor brannmur?

• Forhindre DoS-angrep: f.eks. SYN-flooding der en angriper fyller opp serverens forbindelsesmessige ressurser med falske TCP-forespørsler.
• Forhindre uautorisert tilgang: blokkere tilgang til interne tjenester som ikke skal eksponeres for Internett.
• Tillate bare autorisert trafikk: begrense tilgangen til et sett av godkjente brukere, protokoller og porter.

Tre typer brannmurer

1. Tilstandsløs pakkefiltrering (stateless)

Den enkleste formen: brannmuren ser på hver pakke isolert og bestemmer om den skal slippes gjennom eller droppes, basert på informasjon i headeren:

• Kilde- og destinasjons-IP-adresse
• Kilde- og destinasjonsportnummer (TCP/UDP)
• ICMP-meldingstype
• TCP SYN- og ACK-flagg

Reglene uttrykkes i en Access Control List (ACL) — en tabell der reglene sjekkes fra topp til bunn, og første treff avgjør:

2. Tilstandsfull pakkefiltrering (stateful)

Problemet med tilstandsløs filtrering er at den er for grovkornet. Den slipper gjennom pakker som «ser riktige ut» men ikke tilhører noen reell forbindelse — f.eks. en pakke med ACK-flagg satt som ser ut som et svar, men ingen forespørsel ble noensinne sendt.

En tilstandsfull brannmur løser dette ved å holde styr på alle aktive TCP-forbindelser. Den sporer oppsett (SYN), nedrigging (FIN), og timeout for inaktive forbindelser. En innkommende pakke slippes bare gjennom hvis den tilhører en forbindelse som allerede er satt opp i forbindelsestabellen.

3. Applikasjonsgateway

En applikasjonsgateway filtrerer ikke bare på IP/TCP-headere, men inspiserer også applikasjonsdata. For eksempel: kun utvalgte interne brukere tillates å bruke Telnet. Alle Telnet-forbindelser må gå gjennom gatewayen, som verifiserer brukeridentiteten før den setter opp en viderekoblet forbindelse til det endelige målet.

Begrensninger

Brannmurer er ingen magisk løsning:

• IP-spoofing: ruteren kan ikke verifisere at kilde-IP er ekte.
• Skalerbarhet: hver applikasjon som trenger spesialbehandling krever sin egen gateway.
• Alt-eller-ingenting for UDP: vanskelig å skille «god» fra «dårlig» UDP-trafikk.
• Avveining: jo strengere filtrering, jo mer begrenses også legitim kommunikasjon.