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:

Læreboken (kap. 8.6) presenterer TLS i to nivåer. Først en forenklet «almost-TLS» (8.6.1) som viser de tre fasene handshake → key derivation → data transfer; deretter et mer fullstendig bilde (8.6.2) der nonces, algoritmeforhandling og handshake-beskyttelse er med. Pensum-modellen er den klassiske: klienten genererer en Pre-Master Secret og sender den kryptert med serverens offentlige RSA-nøkkel fra sertifikatet. (TLS 1.3 i den virkelige verden bruker som regel ephemeral Diffie–Hellman og AEAD i stedet — det er nevnt nederst som tilleggsinfo, men er ikke det 8.6 beskriver.)

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

Beskyttelse av selve håndtrykket

Et siste, kritisk steg i håndtrykket: etter at MS er utledet sender begge parter en HMAC over alle håndtrykksmeldingene de har sendt og mottatt — beregnet med de nye HMAC-nøklene. Hvorfor? Den aller første meldingen (ClientHello) inneholder en liste over chiffer klienten støtter, og denne listen sendes i klartekst (ingen nøkler er avtalt enda). Trudy som mann-i-midten kunne strippe vekk de sterke algoritmene fra listen og tvinge partene til å velge en svak chiffer — et såkalt nedgraderingsangrep. Men når både klient og server etterpå sender en HMAC over hele håndtrykket, vil enhver slik manipulasjon gi forskjellige HMAC-er hos de to, og forbindelsen avbrytes.

Hvorfor nonces? Connection replay attack

Sekvensnumrene beskytter mot at enkeltpakker spilles av på nytt midt i en aktiv økt — men ikke mot at en hel økt spilles av på nytt en annen dag. Forestill deg at Trudy avlytter alle TLS-meldingene mellom Alice og Bob i dag. I morgen kobler hun seg mot Alice og spiller av nøyaktig den samme sekvensen av meldinger som Bob sendte. Uten nonces ville Alice utlede de samme sesjonsnøklene som i går, integritetssjekkene ville passere, og Alice (om hun er en e-handelsserver) ville registrert det samme kjøpet på nytt. Nonces løser dette: fordi klient og server velger nye, ferske nonces hver økt, blir master secret — og dermed alle sesjonsnøklene — forskjellige hver gang. De gamle records vil da feile integritetssjekken, og «connection replay»-angrepet stoppes.

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 består av et type-felt (handshake-melding, applikasjonsdata, eller signal om at forbindelsen lukkes), et versjon-felt, et lengde-felt, selve dataene og en HMAC. Type, versjon og lengde sendes i klartekst — mottakeren trenger lengden for å plukke recordene ut av TCP-strømmen — mens data og HMAC krypteres med sesjonsnøkkelen før det hele gis 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.

I TLS 1.3 brukes ofte AEAD (Authenticated Encryption with Associated Data): kryptering og integritet i én operasjon, i stedet for eldre oppsett med separat MAC over payload. Record-struktur og behovet for integritet og beskyttelse mot replay er likevel de samme prinsippene som i «toy-TLS»-forklaringen over.

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.).

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.

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.

Fra WEP til WPA3

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. Målet er en felles sesjonsnøkkel K_M-AP uten at det forhåndsdelte passordet forlater enhetene i klartekst. Passordet inngår bare i lokale beregninger; over lufta sendes verdier som er avledet av passordet, men som ikke avslører passordet direkte — en angriper må fortsatt gjette eller teste passordet (derfor teller sterke passord).

I denne forenklede beskrivelsen (som samsvarer med fire-stegs-oversikten over) skjer utvekslingen slik:

1. AS sender Nonce_AS — et tilfeldig engangsnummer — til mobilenheten. Verdien er offentlig i den forstand at den avlyttes i klartekst, men den binder denne økten til et bestemt tidspunkt og hindrer enkelt gjenbruk av gamle meldinger (replay).
2. Mobilenheten trekker sitt eget tilfeldige Nonce_M og kjører en avtalt nøkkelutledning (KDF) lokalt: den blander passordet (som bare finnes på enheten), Nonce_AS, Nonce_M og typisk MAC-adressene til stasjon og tilgangspunkt. Resultatet er K_M-AP og kryptografisk materiale til å lage en bekreftelse. Enheten sender Nonce_M og en HMAC tilbake. HMAC-en er en kort autentiseringskode basert på hash og delt hemmelighet — ikke en asymmetrisk signatur med privat nøkkel fra PKI — men den viser likevel at avsenderen kan ha brukt samme hemmelige grunnlag som mottakeren forventer etter å ha blandet inn riktig passord og riktige nonce-verdier.
3. AS gjør samme KDF med samme ingredienser, beregner forventet HMAC og sammenligner med det som ble mottatt. Stemmer de, er partene gjensidig overbevist om at den andre kjenner passordet, og de deler nå K_M-AP — 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.