Sikkerhet i datanettverk

Svar: (1) Konfidensialitet — kun avsender og mottaker forstår innholdet. (2) Autentisering — partene kan bekrefte hverandres identitet. (3) Meldingsintegritet — innholdet er uendret underveis. (4) Tilgjengelighet — legitime brukere kommer fram.

Hvorfor: CIA-triaden i informasjonssikkerhet (Confidentiality, Integrity, Availability) er det samme rammeverket. Autentisering støtter særlig integritetsdelen — du må vite hvem som skrev meldingen for å vurdere om den er autentisk. Tjenestenektangrep (DoS) er det klassiske angrepet på A-delen: flommen av falsk trafikk hindrer ekte brukere uten å bryte konfidensialitet eller integritet. Hver av de fire egenskapene løses med ulike kryptografiske/operasjonelle verktøy — kryptering for C, MAC/signaturer for I, sertifikater for autentisering, brannmurer/oppstrømsfiltrering for A.

Svar: (1) Avlytting (eavesdrop) — passivt fange opp meldinger. (2) Injeksjon — aktivt sette inn falske pakker i en pågående forbindelse. (3) Spoofing — forfalske kildeadressen i en pakke. (4) Hijacking — overta en pågående TCP-forbindelse ved å fjerne den ene parten. (5) Tjenestenekt (DoS/DDoS) — oversvømme en server med forespørsler slik at den ikke kan betjene ekte brukere.

Hvorfor: Hvert angrep utnytter en bestemt mangel — avlytting fordi nettet ikke krypterer av seg selv, spoofing fordi IP-laget ikke autentiserer avsender, hijacking fordi TCP er tilstandsfull og dermed kan kapres. Forsvarene speiler dette: kryptering mot avlytting, MAC/digital signatur mot injeksjon, sertifikater mot spoofing av identitet, sekvensnummer mot replay/hijacking, og brannmurer/SYN-cookies mot DoS.

Svar: Klartekst m krypteres med nøkkel K_A til chiffertekst K_A(m), og dekrypteres med K_B tilbake til m. I symmetrisk kryptografi er K_A = K_B = K_S — én delt hemmelig nøkkel. I offentlig nøkkelkryptografi er K_A og K_B ulike: én er offentlig (publisert fritt), den andre er privat.

Hvorfor begge eksisterer: Symmetrisk er raskt (AES, ofte ~1000× raskere enn RSA) og brukes til å kryptere selve dataene i TLS, IPsec og WiFi. Offentlig nøkkel er tregt, men løser to problemer symmetrisk ikke kan: (a) nøkkelutveksling uten forhåndsdelt hemmelighet, og (b) digitale signaturer. I praksis kombineres de i hybridoppsett — public-key brukes én gang for å utveksle en symmetrisk K_S, deretter krypterer K_S selve dataene.

Svar: Caesar har bare 25 mulige nøkler — trivielt brute force. Monoalfabetisk har 26! ≈ 4·10²⁶ nøkler, men knekkes av frekvensanalyse: «e» er hyppigst i engelsk (~12,7 %), «t» nest hyppigst (~9 %), og bigrammer som «th», «he», «in» avslører resten på 100–200 tegn chiffertekst. Vigenère er polyalfabetisk, men knekkes ved å først gjette nøkkellengden, deretter gjøre frekvensanalyse på hver «posisjon mod nøkkellengde» som et eget Caesar-chiffer.

Hvorfor: Felles svakhet er at de behandler én bokstav om gangen og lar statistisk struktur i klarteksten lekke gjennom. Moderne blokkchiffer (DES, AES) opererer på bit-blokker med mange runder substitusjon, permutasjon og XOR — Shannons confusion (skjul nøkkelen) og diffusion (spred klarteksten) gjør at hver bit av chifferteksten avhenger av hver bit i klarteksten og nøkkelen. Stort nøkkelrom alene er ikke nok.

Svar: Et strømchiffer krypterer én bit/byte om gangen ved å XOR-e klarteksten med en pseudo-tilfeldig nøkkelstrøm. Et blokkchiffer krypterer faste blokker — DES bruker 64-bits blokker og en 56-bits nøkkel, AES bruker 128-bits blokker og 128/192/256-bits nøkkel.

Hvorfor AES vant: DES' 56-bits nøkkel ble knekt med brute force på under ett døgn i DES Challenge. 3DES (kryptering med tre forskjellige nøkler etter hverandre) ga ~168-bits nøkkelstyrke som mellomløsning, men ble for tregt. AES-128 vil ta ca. 149 billioner år å brute force selv om DES tok 1 sekund. AES er i dag dominerende i TLS, WPA2/WPA3, IPsec og 4G/5G.

Svar: Uten CBC ville to like klartekstblokker gitt to like chiffertekstblokker — en angriper som ser «AB12 ... AB12» vet at de er like uten å kjenne innholdet. CBC løser dette ved å XOR-e hver klartekstblokk med forrige chiffertekstblokk før kryptering. Den første blokken har ingen «forrige» — derfor genererer avsenderen en tilfeldig IV som XOR-es med blokk 1.

Hvorfor IV-en sendes i klartekst: IV må være ny (uforutsigbar) for hver melding, men trenger ikke være hemmelig. Når IV varierer, gir samme melding kryptert to ganger helt forskjellig chiffertekst — Trudy kan ikke kjenne igjen «meldingen jeg så i går». Dette beskytter strukturerte data (faste headere, passordfelt, repeterte mønstre) der likhet ellers ville lekket informasjon.

Svar:

Ciphertext-only: Trudy har bare chifferteksten — må bruke brute force eller statistisk analyse.
Known-plaintext: Hun har noen klartekst-chiffertekst-par (f.eks. fordi meldingen begynner med «Dear Bob,»). Parene brukes til å utlede nøkkelen.
Chosen-plaintext: Hun kan velge hvilken klartekst som krypteres og se chifferteksten — det sterkeste tilfellet.

Hvorfor det betyr noe: En algoritme må holde også mot det sterkeste angrepet (chosen-plaintext) for å regnes som trygg i moderne kryptografi. AES er designet med dette for øye. Klassiske chiffer faller raskt i alle tre kategoriene; selv WEP-protokollen ble brutt fordi den var sårbar mot known-plaintext-angrep med gjenbrukte IV-er.

Svar: Bob har et nøkkelpar: offentlig K_B⁺ (publisert fritt) og privat K_B^- (holdt hemmelig). To egenskaper:

(1) K_B^-(K_B⁺(m)) = m — det den offentlige krypterer, kan bare den private dekryptere (og omvendt for signaturer).
(2) Gitt K_B⁺ er det beregningsmessig umulig å finne K_B^-.

Hvorfor det er revolusjonerende: Diffie-Hellman (1976) og RSA (1978) løste 2000 års kryptografihistories største problem: nøkkelutveksling uten forhåndsmøte. Alice kan kryptere til Bob selv om de aldri har snakket sammen. Samme matematikk muliggjør digitale signaturer (signer med privat, verifiser med offentlig). I dag er dette grunnsteinen i TLS, sikker e-post og hele PKI.

Svar: Hybridkryptering kombinerer offentlig-nøkkel og symmetrisk: (1) Alice genererer en tilfeldig symmetrisk sesjonsnøkkel K_S, (2) krypterer meldingen raskt med K_S (AES), (3) krypterer den korte K_S med Bobs offentlige nøkkel K_B⁺, og sender begge. Bob dekrypterer K_S med K_B^- og bruker den til å dekryptere meldingen.

Hvorfor: Offentlig-nøkkel-kryptering er ~1000× tregere enn AES — å kryptere en hel e-post med RSA ville vært upraktisk. Hybridkryptering bruker den dyre operasjonen én gang på en kort nøkkel, og den raske én på dataene. Mønsteret går igjen overalt: sikker e-post, TLS, IPsec og WPA3. Som bonus får hver økt sin egen K_S, så en kompromittert sesjonsnøkkel avslører bare den ene øktens data.

Svar: En hashfunksjon H tar input av vilkårlig lengde og produserer et kort «fingeravtrykk» H(m) av fast lengde. Den må være (1) enveis — gitt H(m) er det praktisk umulig å finne m, (2) kollisjonsresistent — praktisk umulig å finne to ulike meldinger m₁, m₂ med H(m₁) = H(m₂), og (3) små endringer i input gir helt forskjellig output.

Hvorfor ikke checksum: TCP-checksum er designet for å oppdage tilfeldige bitfeil, ikke ondsinnet manipulasjon. Det er trivielt å konstruere to forskjellige meldinger med samme 16-bits checksum — f.eks. har «IOU 100.99 BOB» og «IOU 900.19 BOB» identisk checksum. SHA-256 er dagens anbefaling; MD5 og SHA-1 er foreldet etter at kollisjoner er funnet/demonstrert (SHA-1 i 2017).

Svar:

MAC (HMAC): Krever en delt hemmelig nøkkel K_S. Senderen beregner MAC = H(melding + K_S); mottakeren gjør det samme og sammenligner. Avvik avslører manipulasjon eller feil avsender.
Digital signatur: Senderen krypterer hashen H(m) med privat nøkkel K_A^-; hvem som helst kan verifisere med offentlig K_A⁺.

Hvorfor begge eksisterer: MAC er raskt og krever ingen PKI — perfekt for protokoller der partene allerede deler en nøkkel (TLS-record, WiFi-trafikk). Men det gir ikke ikke-benektbarhet, fordi begge parter kjenner K_S. Digital signatur gir non-repudiation: bare Bob har K_A^-, så Alice kan vise meldingen og signaturen til en domstol som bevis. Trade-off: signatur er tregere og krever sertifikat-infrastruktur (CA).

Svar: En Certification Authority (CA) er en pålitelig tredjepart som binder en identitet (f.eks. domenenavn) til en offentlig nøkkel. Sertifikatet (X.509) inneholder eierens identitet, eierens offentlige nøkkel, utstedende CA og utløpsdato — alt signert av CA-en med dens private nøkkel. CA-ens egen rotnøkkel kommer forhåndsinstallert i nettleseren/operativsystemet.

Hvorfor det stopper MITM: Uten sertifikater kunne Trudy plassere seg mellom Alice og Bob, sende sin egen offentlige nøkkel til Alice (og utgi seg for Bob) og lese alt. Sertifikatet løser dette: Alice verifiserer CA-signaturen med CA-ens forhåndsinstallerte offentlige nøkkel, og vet dermed at den offentlige nøkkelen virkelig tilhører Bob — Trudy kan ikke forfalske sertifikatet uten CA-ens private nøkkel. Dette er fundamentet i TLS/HTTPS.

Svar:

1. K_A^- (Alices private nøkkel) — signerer hashen H(m) for integritet og avsenderautentisering.
2. K_S (tilfeldig symmetrisk sesjonsnøkkel) — krypterer hele {melding + signatur} raskt med AES for konfidensialitet.
3. K_B⁺ (Bobs offentlige nøkkel) — krypterer den korte K_S slik at bare Bob kan utvinne den med K_B^-.

Hvorfor akkurat denne kombinasjonen: Hver nøkkel gjør én ting de andre ikke kan. Signering må gjøres med Alices private nøkkel (bare hun har den), så Bob kan verifisere med hennes offentlige nøkkel og vite at det er Alice. Selve dataene må krypteres symmetrisk fordi public-key er for tregt for lange meldinger. K_S selv kan ikke sendes i klartekst — derfor pakkes den inn i Bobs offentlige nøkkel. Bob gjør de tre operasjonene i omvendt rekkefølge ved mottak.

Svar:

1. Håndtrykk: Sertifikatutveksling og autentisering. Partene avtaler en felles hemmelighet (master secret) — i TLS 1.3 typisk via ephemeral Diffie-Hellman.
2. Nøkkelutledning: Fra master secret utledes fire separate nøkler (én krypterings- og én MAC-nøkkel per retning).
3. Dataoverføring: Data sendes som krypterte records, hver med MAC for integritet og lengde. TLS 1.3 bruker AEAD (kryptering + integritet i én operasjon).
4. Nedkobling: Spesielle close-meldinger sendes før TCP FIN, slik at en angriper ikke kan gjennomføre truncation attack ved å sende en falsk FIN.

Hvorfor lagdelingen virker: TLS er ikke et eget OSI-lag, men et sublag mellom TCP og applikasjonen. Applikasjonen skriver til en TLS-socket; TLS krypterer og leverer til TCP som vanlige segmenter. TCP/IP under vet ingenting om kryptering — derfor kan TLS sikre HTTPS, IMAP, SMTP osv. uten å endre transportlaget.

Svar: TLS utleder:

E_A — kryptering Alice→Bob
E_B — kryptering Bob→Alice
M_A — MAC Alice→Bob
M_B — MAC Bob→Alice

Hvorfor: God kryptografisk praksis er å aldri bruke samme nøkkel til to ulike formål eller retninger. Forskjellige nøkler per retning gjør det vanskeligere for en angriper å «reflektere» en kryptert melding tilbake til avsender og få den akseptert. Forskjellige nøkler per formål (kryptering vs MAC) isolerer skadeomfanget hvis én algoritme skulle vise seg svekket — kompromittering av MAC-konstruksjonen lekker ikke krypteringsnøkkelen, og omvendt.

Svar: TCP gir en byte-strøm, men TLS deler den opp i records: hver record inneholder data, en MAC og en lengde, og krypteres som en helhet før den leveres til TCP. Sekvensnummeret er en intern teller hos hver part — det sendes ikke eksplisitt i recorden, men inkluderes i MAC-beregningen.

Hvorfor: Uten sekvensnummer kunne Trudy fange opp en gyldig record og spille den av igjen senere (replay-angrep), eller bytte rekkefølge på records uten at mottakeren oppdaget det — meldingen ville fortsatt vært gyldig kryptert og MAC-en ville stemt. Med sekvensnummer i MAC-beregningen vil enhver replay/omrokering få MAC-verifiseringen til å feile, fordi forventet sekvensnummer hos mottakeren ikke matcher det som ble brukt da MAC-en ble laget. Samme prinsipp brukes også på record-nivå i AEAD-modus i TLS 1.3.

Svar:

Transport-modus: Krypterer bare payloaden i IP-datagrammet — den opprinnelige IP-headeren er fortsatt synlig. Brukes mellom to endepunkter (host-to-host).
Tunnel-modus: Krypterer hele det opprinnelige datagrammet (inkludert headeren) og pakker det inn i et nytt IP-datagram med ny ytre header. Brukes mellom gateways.

Hvorfor tunnel-modus dominerer i praksis: En VPN (Virtual Private Network) bygges på tunnel-modus. Tenk på et selskap med kontorer i Oslo og Trondheim: gateway-ruterne på hvert kontor setter opp en IPsec-tunnel, og all trafikk mellom kontorene pakkes inn i krypterte IP-datagrammer som tunneleres over offentlig Internett. På linja er både innholdet og de opprinnelige IP-adressene skjult. IPsec sikrer alt på nettverkslaget — uavhengig av applikasjon eller port — i motsetning til TLS som bare sikrer én TCP-forbindelse om gangen.

Svar: I WPA3-håndtrykket utveksler mobilenheten og Authentication Server bare nonce-verdier (engangsbrukstall) og en HMAC-verifiseringsverdi. Begge parter utleder lokalt samme symmetriske sesjonsnøkkel K_M-AP fra: passordet, begge nonce-ene og MAC-adressene. Hver part beregner og verifiserer en HMAC over disse ingrediensene. Hvis HMAC-en stemmer på begge sider, vet de at den andre kjenner passordet.

Hvorfor det er trygt: Passordet selv blir aldri overført. Trudy som lytter på lufta ser bare nonce-er og en HMAC — hun kan ikke regne baklengs til passordet (HMAC er enveis), og hun kan heller ikke gjenta gamle handshakes fordi nonce-ene er nye hver gang. WEP og WPA2-PSK var sårbare for ordbokangrep mot fanget håndtrykk-trafikk; WPA3 SAE er designet for å motstå dette ved at hver gjettings-runde krever en ny aktiv handshake.

Svar: I 4G LTE sendes IMSI (mobilenhetens unike identifikator på SIM-kortet) i klartekst ved nettverkstilkobling. I 5G krypteres IMSI med public-key-kryptografi før den sendes, slik at bare hjemmenettverkets HSS kan dekryptere den. I tillegg flyttes selve autentiseringsbeslutningen fra MME i besøkt nett (4G) til hjemmenettverket (5G).

Hvorfor det betyr noe: I 4G muliggjorde klartekst-IMSI såkalte IMSI-catchers — falske basestasjoner («Stingrays») som lurer mobiler til å koble seg til, fanger opp identiteten og sporer bevegelser. 5G-krypteringen gjør dette sporet umulig fordi bare hjemmenettverket har den private nøkkelen. Flyttingen av autentiseringsbeslutningen reduserer også tilliten et besøkt operatørnett trenger — selv en kompromittert besøkt operatør kan ikke utstede falske autentiseringsvedtak. Begge endringene styrker både konfidensialitet og autentisering.

Svar:

Tilstandsløs (stateless) brannmur: Ser på hver pakke isolert. Beslutter ut fra header-felt (kilde-/dest-IP, port, protokoll, TCP-flagg) og en ACL-tabell som sjekkes ovenfra og ned.
Tilstandsfull (stateful) brannmur: Holder en forbindelsestabell over alle aktive TCP-forbindelser (sporer SYN, FIN, timeouts). Innkommende pakker slippes bare hvis de hører til en kjent forbindelse.
Applikasjonsgateway: Inspiserer applikasjonsdata (lag 7), ikke bare pakkehodet. F.eks. krever den brukerautentisering før den setter opp en viderekoblet Telnet-forbindelse.

Hvorfor stateful løser et reelt problem: En tilstandsløs brannmur slipper igjennom en TCP-pakke med ACK-flagg satt fordi den «ser ut som» et svar — selv om Trudy fabrikkerte pakken og ingen forbindelse finnes. En tilstandsfull brannmur sjekker forbindelsestabellen og avviser den. Applikasjonsgateways går enda lengre, men har høyere overhead og krever én gateway per applikasjonsprotokoll. Felles begrensninger: brannmurer er fortsatt sårbare for IP-spoofing, og kryptert trafikk (TLS) skjuler innholdet for inspeksjon.

Svar: Tre mønstre:

1. Sårbarhetsutnyttelse: spesialformede meldinger som krasjer eller henger tjenesten (utnytter en bug i selve programvaren).
2. Båndbreddeflom: oversvømmer mål-linken med så mye trafikk at legitim trafikk ikke kommer fram. Krever ofte et botnett (DDoS) for å produsere nok volum.
3. Tilkoblingsflom: åpner enormt mange halvferdige TCP-forbindelser (SYN flooding) til serverens forbindelsestabell er full og ingen nye tilkoblinger kan opprettes.

Hvorfor: Alle tre angriper tilgjengeligheten (A-delen i CIA-triaden) — ikke konfidensialitet eller integritet. Hver utnytter en ulik begrensning (programvarens robusthet, linkens kapasitet, serverens tilstandsbuffer) og krever ulike forsvar: patching, oppstrøms-filtrering, og SYN cookies/connection rate-limits. DDoS er særlig vanskelig å filtrere fordi trafikken kommer fra mange ekte IP-adresser samtidig.

Svar: I et replay-angrep fanger Trudy opp en gyldig melding (f.eks. en autentisert «overfør 1000 kr»-kommando) og spiller den av på nytt senere — meldingen er ekte og verifiseres som autentisk, men handlingen utføres flere ganger. Tre standardforsvar:

• Nonces (engangsbrukstall) — mottakeren krever at hver melding inneholder et nytt, ikke gjenbrukt tall.
• Tidsstempler — meldinger med stempel utenfor et lite vindu avvises.
• Sekvensnummer i MAC-beregningen — brukes f.eks. i TLS-records.

Hvorfor: Felles for alle: hver melding gjøres «fersk» slik at en gammel kopi avvises. Replay-angrep er spesielt farlig der autentisering bare bekrefter at meldingen kom fra rett avsender — den sier ingenting om når. WPA3-håndtrykket beskytter med nonces, TLS-records med sekvensnummer, Kerberos med tidsstempler.

Svar: Fire aktører:

• UE (User Equipment): mobilenheten med SIM-kort som inneholder IMSI og forhåndsdelt nøkkel K_HSS-M.
• eNode-B: basestasjonen — videreformidler autentiseringsmeldinger.
• MME: tar autentiseringsbeslutningen i besøkt nett.
• HSS: endelig autoritet i hjemmenettverket — kjenner alle abonnenter og deres nøkler.

Hvorfor det er gjensidig: HSS bruker K_HSS-M til å beregne et auth_token og forventet respons xres, og sender begge til MME. MME videresender auth_token til mobilen, som verifiserer det med sin egen nøkkel — og vet dermed at nettverket er ekte (motvirker falske basestasjoner). Mobilen beregner sin egen respons res og sender til MME. MME sammenligner res med xres — stemmer de, er mobilen autentisert. Til slutt utleder UE og basestasjonen krypteringsnøkkel K_BS-M som krypterer all videre 4G-trafikk (typisk AES).

Svar:

• WEP: Tidlig 802.11-kryptering med svake nøkler (40/104 bit) og dårlig IV-bruk — knekkes på minutter. Regnes som brutt.
• WPA2 (802.11i): CCMP basert på AES, lenge industristandard. Sårbarhet: hvis du fanger 4-veis-håndtrykket, kan du gjøre offline ordbokangrep mot et svakt PSK-passord uten at AP-et merker det.
• WPA3: Bytter ut PSK-håndtrykket med SAE. Passordet kan ikke gjettes offline lenger; hver gjettings-runde krever en ny aktiv handshake mot AP-et.

Hvorfor: Hver generasjon retter en konkret feil. WEP feilet på selve kryptografien (svake nøkler, IV-gjenbruk). WPA2 fikset krypteringen (AES) men beholdt et håndtrykk som lekket nok til offline-angrep. WPA3 fikset håndtrykket. Lærdom: en kjede er ikke sterkere enn det svakeste leddet — sterk kryptering hjelper lite hvis nøkkelutvekslingen lekker.

Svar: En cipher suite er et sett av algoritmer som brukes sammen i én TLS-forbindelse: én for nøkkelutveksling, én for symmetrisk kryptering, én for MAC, og én for digital signatur. I TLS 1.2 valgte partene en cipher suite under håndtrykket. I TLS 1.3 (RFC 8446, 2018) er listen drastisk strammet inn — bare moderne, trygge kombinasjoner gjenstår.

Hvorfor AEAD: TLS 1.3 bruker AEAD (Authenticated Encryption with Associated Data) — kryptering og integritet i én operasjon, ikke separat MAC over payload som tidligere. Eksempler: AES-GCM, ChaCha20-Poly1305. Fordelene er færre angrepsflater (eldre TLS hadde sårbarheter som POODLE og BEAST på grunn av rekkefølgen MAC-then-encrypt eller encrypt-then-MAC), bedre ytelse, og enklere å implementere riktig. Record-strukturen og behovet for sekvensnummer mot replay består.

Svar: IP-spoofing er å sende pakker med en forfalsket avsender-IP-adresse, slik at mottakeren tror pakken kommer fra noen andre. IP-laget verifiserer ikke avsenderen — protokollen ble designet for et tillitsfullt nett.

Hvorfor refleksjonsangrep er farlig: Trudy sender en kort forespørsel til en tjener (f.eks. en åpen DNS-resolver) med offerets IP som «avsender». Tjeneren sender et stort svar tilbake til offeret, som verken sendte forespørselen eller har bedt om svaret. IP-spoofing er fundamentet for slike angrep, og er en del av den generelle trussel-taksonomien i 8.1.

Svar:

• Confusion (skjul nøkkelen): Forholdet mellom nøkkel og chiffertekst skal være så komplisert at en angriper ikke kan utlede nøkkelen ved statistisk analyse av chifferteksten.
• Diffusion (spred klarteksten): Hver bit av klarteksten skal påvirke mange bits av chifferteksten — endring av én klartekst-bit endrer i snitt halvparten av chiffertekst-bitene.

Hvorfor det er viktigere enn nøkkelrom: Monoalfabetisk substitusjon har 26! ≈ 4·10²⁶ mulige nøkler — for stort for brute force — men knekkes likevel trivielt av frekvensanalyse, fordi statistisk struktur i klarteksten lekker rett gjennom. Stort nøkkelrom hjelper ikke når strukturen er bevart. Moderne blokkchiffer (DES, AES) bruker mange runder med substitusjon, permutasjon og XOR med rundenøkler nettopp for å oppnå begge egenskapene. Resultat: hver bit av chifferteksten avhenger av hver bit i klarteksten og nøkkelen — frekvensanalyse fungerer ikke.

Svar: En Access Control List er en tabell av regler brannmuren konsulterer for hver pakke. Hver regel består av en handling (allow/deny) og et sett av match-kriterier: kilde- og destinasjons-IP, kilde- og dest-port, protokoll (TCP/UDP/ICMP), og evt. TCP-flagg (SYN, ACK).

Hvorfor «første treff vinner»: Reglene sjekkes ovenfra og ned, og første regel som matcher avgjør — alle senere regler ignoreres for den pakken. Derfor må mer spesifikke regler ligge øverst, og en fallback-regel deny all nederst slik at alt som ikke eksplisitt er tillatt blokkeres. Et typisk eksempel: tillat utgående HTTP fra interne klienter til eksterne port 80, og tillat returtrafikk med ACK-flagg satt — alt annet droppes. Begrensningen er at en tilstandsløs ACL ikke vet om en innkommende ACK-pakke faktisk hører til en aktiv forbindelse, og kan slippe inn fabrikkerte pakker (derav behovet for stateful filtrering).

Svar: Bob beregner H(m) (f.eks. SHA-256 → 256 bit), krypterer hashen med sin private nøkkel K_B^- og sender meldingen + signaturen til Alice. Alice (1) beregner H(m) selv fra mottatt melding, (2) dekrypterer signaturen med K_B⁺, (3) sammenligner.

Hvorfor signere bare hashen: Public-key-operasjoner er ~1000× tregere enn symmetrisk kryptering — å signere en hel lang melding ville vært upraktisk. Hashen er kort og av fast lengde uavhengig av meldingen.

Hva signaturen verifiserer i én operasjon: (a) Bob signerte — bare Bob har K_B^- som kunne lage en signatur som dekrypteres til riktig hash. (b) Meldingen er uendret — enhver bit-endring i m gir helt annen H(m), så sammenligningen feiler. I tillegg: non-repudiation — Alice kan vise meldingen og signaturen til en domstol som bevis på at Bob faktisk signerte.

Svar: En sesjonsnøkkel er en kortvarig symmetrisk nøkkel som genereres for én enkelt forbindelse (f.eks. én TLS-økt, én e-post). Den brukes til å kryptere selve dataene raskt med AES, mens den dyre offentlig-nøkkel-operasjonen bare brukes én gang for å utveksle den trygt.

Hvorfor: Tre fordeler.

(1) Ytelse — symmetrisk er ~1000× raskere enn public-key, så public-key brukes så lite som mulig.
(2) Skadebegrensning — hvis én sesjonsnøkkel kompromitteres, lekker bare den ene øktens data; ikke historikk eller framtid.
(3) Forward secrecy — i moderne TLS 1.3 utveksles sesjonsnøkkelen med ephemeral Diffie-Hellman, slik at selv om serverens private langtidsnøkkel kompromitteres senere, kan ikke gamle økter dekrypteres.

Mønsteret går igjen i sikker e-post, TLS, IPsec og WPA3.

Svar: Den naive konstruksjonen H(KS || m) har subtile sårbarheter knyttet til hvordan hashfunksjoner internt prosesserer data blokk-for-blokk — i visse tilfeller kan en angriper utnytte hashens interne tilstand uten å kjenne K_S. Derfor trengs en standardisert, presis MAC-konstruksjon.

Hvorfor HMAC løser det: HMAC (RFC 2104) bruker den hemmelige nøkkelen kombinert med to konstanter (ipad og opad) i to runder hashing: HMAC(K, m) = H(K ⊕ opad || H(K ⊕ ipad || m)). Den ytre hashen beskytter mot angrep mot den indre tilstanden. HMAC er standard MAC-konstruksjon i TLS, IPsec og WPA3.

Svar:

1. Oppdagelse av sikkerhetskapabiliteter: AP-et annonserer sin tilstedeværelse og hvilke autentiserings-/krypteringsformer det støtter; mobilen velger ønsket form.
2. Gjensidig autentisering og nøkkelutledning: Authentication Server og mobil bruker passordet, nonces og hashing til å autentisere hverandre — uten å sende passordet — og utleder en felles symmetrisk sesjonsnøkkel K_M-AP.
3. Distribusjon av sesjonsnøkkel: AS informerer AP-et om K_M-AP så AP kan kryptere trafikk til/fra mobilen.
4. Kryptert kommunikasjon: Mobil og AP bruker K_M-AP (typisk AES) til all videre trafikk over linken.

Hvorfor strukturen er slik: Steg 1 trengs fordi mobilen ikke vet på forhånd hvilken sikkerhetsstandard nettverket bruker. Steg 2 er det interessante — det er der WEP, WPA2-PSK og WPA3-SAE skiller seg fra hverandre (kvaliteten på håndtrykket avgjør om passordet kan gjettes offline). Steg 3 og 4 er like uansett protokoll: når du har en sesjonsnøkkel, krypterer du symmetrisk.

Svar: TLS er ikke et eget OSI-lag, men et sublag mellom TCP og applikasjonen. Applikasjonen (f.eks. nettleseren) skriver klartekst til en TLS-socket; TLS krypterer og leverer dataene ned til TCP som vanlige TCP-segmenter. For TCP og IP under ser alt normalt ut — de vet ikke at innholdet er kryptert.

Hvorfor det er praktisk: Modellen lar TLS sikre enhver TCP-applikasjon uten å endre transportlaget. HTTPS er bare HTTP over TLS over TCP (port 443). Tilsvarende finnes IMAPS, SMTPS, FTPS — samme TLS-sublag, ulike applikasjoner over. Applikasjonsutvikleren trenger nesten ingen kryptografisk kunnskap; biblioteket håndterer alt fra håndtrykk til record-kryptering. Eneste applikasjonsspesifikke valg er typisk å verifisere at sertifikatets domenenavn matcher serveren man trodde man koblet til.

Svar: Et truncation attack er når Trudy injiserer en falsk TCP FIN (eller RST) som tvinger forbindelsen lukket før dataene egentlig er ferdig sendt. Mottakerens applikasjon ser en «ren» avslutning og tror den har fått hele meldingen — men kanskje viktige data ble kuttet av (f.eks. en autorisasjonsstreng på slutten).

Hvorfor TLS-nedkobling motvirker det: TLS' fjerde fase sender eksplisitte close_notify-meldinger over den krypterte forbindelsen før TCP FIN. Disse meldingene er en del av TLS-recordstrømmen og dermed beskyttet av MAC. Mottakeren skiller mellom «fikk close_notify → ekte avslutning» og «fikk bare TCP FIN → kanskje truncation». Uten dette steget kunne enhver angriper med tilgang til TCP-forbindelsen falske en avslutning. Senere TLS-versjoner har strammet dette enda mer.

Svar: En applikasjonsgateway er en brannmur som inspiserer applikasjonsdata (lag 7), ikke bare pakkehoder. Eksempel: en Telnet-gateway tvinger alle Telnet-forbindelser til først å gå til gatewayen. Brukeren autentiserer seg mot gatewayen (f.eks. med engangskode); gatewayen verifiserer brukeren og setter opp en viderekoblet Telnet-forbindelse til det endelige målet på vegne av brukeren.

Hvorfor og hvilken kostnad: Pakkefiltrering kan bare se «port 23 til server X» — den vet ikke hvem som koblet til. En applikasjonsgateway gir finkornet tilgangskontroll (per bruker, per kommando). Kostnadene: (a) én gateway per applikasjonsprotokoll — separate gateways for HTTP, FTP, SSH osv., (b) høyere overhead fordi gatewayen termineter forbindelsen, (c) gatewayen blir et single point of failure og en attraktiv målskive selv. Brukes typisk for spesielt sensitive interne tjenester.

Svar:

1. IP-spoofing: Brannmuren kan ikke verifisere at kilde-IP er ekte — en angriper med spoofet IP kan utgi seg for en intern bruker.
2. Skalerbarhet: Hver applikasjon som trenger spesialbehandling krever sin egen gateway; det vokser fort.
3. Alt-eller-ingenting for UDP: UDP er forbindelsesløs — vanskelig å skille «god» fra «dårlig» trafikk uten dyptgående protokollinspeksjon.
4. Avveining konfigurasjon vs brukbarhet: Strenge regler stopper også legitime brukere; løsere regler gir flere angrepsflater.

Hvorfor det er viktig: Brannmurer er ett forsvarslag, ikke en magisk løsning — derfor bygges nettverkssikkerhet i lag (defense in depth): brannmur + IDS + endepunktsbeskyttelse + kryptering (TLS/IPsec) + tilgangskontroll på applikasjonsnivå. Kryptert trafikk (TLS) er en blindsone: brannmuren ser at det er port 443, men ikke hva som faktisk sendes.

Svar: I symmetrisk kryptografi må Alice og Bob på forhånd være enige om den samme hemmelige nøkkelen K_S. Hvis de aldri har møttes, må de på en eller annen måte utveksle K_S over en upålitelig kanal uten at Trudy fanger den opp. Dette var det store uløste problemet i kryptografi i over 2000 år.

Hvorfor public-key løste det: Diffie og Hellman (1976) og RSA-gruppen (1978) viste at man kan lage et nøkkelpar der den ene nøkkelen kan publiseres åpent uten å kompromittere den andre. Alice trenger ikke utveksle hemmeligheter med Bob — hun bare henter Bobs offentlige nøkkel og krypterer med den. Bare Bob (med den private nøkkelen) kan dekryptere. Dette er fundamentet for at to parter som aldri har møttes kan kommunisere sikkert. I praksis brukes public-key til å utveksle en symmetrisk sesjonsnøkkel (hybridoppsett), siden public-key er for tregt til selve dataene.

Svar: Når en TCP-forbindelse opprettes, mottar serveren en SYN, allokerer ressurser i en halvåpen forbindelsestabell og sender SYN-ACK. I et SYN flood sender Trudy enorme mengder SYN-er (gjerne med spoofet kilde-IP) men aldri den avsluttende ACK. Tabellen fylles opp, og legitime klienter kan ikke opprette nye forbindelser.

Hvilken sikkerhetsegenskap: SYN flooding angriper tilgjengelighet — den fjerde av de fire grunnleggende sikkerhetsegenskapene. Konkrete mottiltak hører hjemme i transportlaget (kap. 3) og er ikke detalj-pensum i kap. 8.

Svar: Et sertifikat trenger ikke være signert av en rot-CA direkte — det kan være signert av en mellomliggende CA som igjen er signert av rot-CA-en. En sertifikatkjede er hele rekken: server → mellom-CA → mellom-CA → rot-CA. Nettleseren validerer hele kjeden ved å verifisere hver signatur opp til en rot.

Hvorfor bare forhåndsinstallerte rot-CA-er: Hele tilliten må starte et sted — man kan ikke verifisere en rot-CA med en annen CA, fordi det blir uendelig regress. Derfor leveres operativsystemet/nettleseren med en liste over et hundretalls forhåndsbetrodde rot-CA-er fra fabrikken (DigiCert, Let's Encrypt osv.). Når et nettsted legger fram en sertifikatkjede, sjekker nettleseren om roten er i listen. Mellom-CA-er finnes for å begrense skadeomfanget hvis én blir kompromittert: bare sertifikater under den ene mellom-CA-en blir mistenkelige, ikke hele rot-CA-ens kjede.

Svar:

• DES (1977): 56-bits nøkkel — ~7,2·10¹⁶ mulige nøkler.
• 3DES: 56·3 = 168 bit nominelt (i praksis ~112 bit pga. meet-in-the-middle).
• AES (2001): 128, 192 eller 256 bit. AES-128 har 3,4·10³⁸ mulige nøkler.

Hvorfor 56 bit faller: Nøkkelrommets størrelse vokser eksponentielt med bit-lengden. DES Challenge knekte en 56-bits nøkkel på under ett døgn med dedikert hardware. Hvert ekstra bit dobler tiden — å gå fra 56 til 128 bit gjør brute force ~2⁷² ≈ 4,7·10²¹ ganger tregere. Hvis DES tar 1 sekund, tar AES-128 ~149 billioner år. Sikkerhetsmarginen er ikke bare «litt sterkere»; den er enorm. AES-128 antas trygg langt forbi nåværende dataverktøys levetid; 3DES er foreldet og fases ut i alle moderne protokoller.

Svar: I et bedriftsoppsett (f.eks. eduroam) er AS en separat server (typisk en RADIUS-server) som kjenner alle brukernes legitimasjoner og gjør selve autentiseringsbeslutningen. AP-et håndterer bare radiotrafikken og videresender autentiseringsmeldinger mellom mobil og AS. Når AS godkjenner brukeren, sender den den utledete sesjonsnøkkelen K_M-AP til AP-et som deretter krypterer trafikken.

Hvorfor separasjonen: (a) Sentralisert brukerdatabase — én AS kan tjene mange AP-er på campus, så studenters legitimasjon ligger ett sted. (b) AP-er er enkle — de trenger ikke holde kryptografisk hemmelig brukermateriale, og kan settes opp/byttes ut uten databasevedlikehold. (c) Sikkerhetsskille — selv om en AP fysisk kompromitteres (gjest-stasjon), kan ikke angriperen lese hele brukerregisteret. I hjemme-WiFi spiller ruteren ofte begge roller, men den logiske modellen er den samme.

Svar: HSS bruker den forhåndsdelte nøkkelen K_HSS-M (kjent bare av SIM-kortet og HSS) til å lage to verdier:

• auth_token sendes via MME til mobilen. Mobilen bruker sin egen K_HSS-M til å verifisere at auth_token er gyldig — og vet dermed at nettverket er ekte (motvirker falske basestasjoner). Mobilen ekstraherer også fra auth_token den utfordringen den må svare på.
• xres (expected response) sendes til MME, ikke til mobilen. Mobilen beregner sin egen respons res ut fra utfordringen og sender til MME. MME sammenligner res med xres — stemmer de, er mobilen autentisert.

Hvorfor delt slik: Splittelsen gir gjensidig autentisering uten at MME (i besøkt nett) trenger den hemmelige nøkkelen — den får bare den ferdig beregnede xres-en. Slik kan MME avgjøre lokalt om mobilen er ekte, mens HSS forblir den eneste som kjenner K_HSS-M. I 5G flyttes selve sammenligningen tilbake til hjemmenettverket, slik at heller ikke et kompromittert besøkt nett kan utstede falske godkjenninger.

Svar: Kobling verktøy → egenskap:

• Konfidensialitet → symmetrisk kryptering (rask, brukes på selve dataene), evt. innpakket av public-key for nøkkelutveksling.
• Autentisering → public-key + sertifikater (CA bekrefter identitet), eller delt hemmelighet via MAC.
• Meldingsintegritet → kryptografisk hashfunksjon kombinert med MAC (delt nøkkel) eller digital signatur (privat nøkkel).
• Tilgjengelighet → er ikke et kryptografisk problem; løses med brannmurer, oppstrøms-filtrering, lastfordeling, SYN cookies.

Hvorfor synet er nyttig: Hver protokoll i pensum (sikker e-post, TLS, IPsec, WPA3) er en bestemt sammensetning av disse fire verktøyene. Når du analyserer en ny sikkerhetsprotokoll, spør: hvilken egenskap skal dekkes, og hvilket verktøy brukes? Kryptografi løser tre av fire egenskaper; tilgjengelighet er på en annen akse og krever andre tiltak.

Svar:

• K_S(m): Symmetrisk kryptering av meldingen m med delt hemmelig nøkkel K_S. Brukes til konfidensialitet på selve dataene (rask, AES).
• K_B⁺(m): Kryptering med Bobs offentlige nøkkel. Bare K_B^- kan dekryptere. Brukes til å sende noe til Bob (f.eks. en sesjonsnøkkel) uten felles forhåndsdelt hemmelighet.
• K_B^-(H(m)): «Kryptering» med Bobs private nøkkel. Hvem som helst kan «dekryptere» med K_B⁺ — det vil si verifisere. Dette er en digital signatur over hashen H(m).

Hvorfor notasjonen virker: RSA har den fine egenskapen at K_B^-(K_B⁺(m)) = m og K_B⁺(K_B^-(m)) = m. Dvs. enten nøkkel kan «kryptere»; den andre nøkkelen reverserer. Når den private krypterer, kan alle verifisere — derav signaturer. Tommelfingerregel: til Bob bruker offentlig (alle kan); fra Bob bruker privat (bare Bob har).

Svar:

• DES — Data Encryption Standard (1977, 56-bits blokkchiffer, foreldet)
• AES — Advanced Encryption Standard (2001, 128-bits blokker, 128/192/256-bits nøkkel)
• MAC — Message Authentication Code (kort verdi som beviser integritet + avsender)
• HMAC — Hash-based MAC (RFC 2104; standard MAC-konstruksjon)
• AEAD — Authenticated Encryption with Associated Data (kryptering + integritet i én operasjon)
• CA — Certification Authority (binder identitet til offentlig nøkkel)
• PKI — Public Key Infrastructure (hele systemet av CA-er, sertifikater og verifikasjon)
• IV — Initialization Vector (tilfeldig startverdi i CBC-modus)
• SAE — Simultaneous Authentication of Equals (WPA3-håndtrykket)

Hvorfor det er nyttig å huske: Pensumtekstene veksler mye mellom akronym og fullt navn. Eksamensoppgaver bruker ofte forkortelsen alene — særlig i flervalg eller kortsvar. Når du ser «AEAD» i en oppgave, skal du klare å si at det er kryptering og integritet kombinert, og at TLS 1.3 brukte det som standard.

Svar:

Nonce (number used once): et engangsbrukstall som brukes for å garantere ferskhet — typisk i et håndtrykk. Mottakeren krever at hver melding inneholder en ny nonce; gamle meldinger kan ikke spilles av (replay). Trenger ikke være hemmelig.

IV (Initialization Vector): startverdien til en blokkchiffermodus som CBC. Sendes i klartekst, må være uforutsigbar og ny for hver melding slik at samme klartekst krypteres ulikt hver gang. Trenger ikke være hemmelig.

Sesjonsnøkkel: kortvarig symmetrisk nøkkel som brukes til å kryptere selve dataene i én økt. Utveksles via public-key (eller utledes via Diffie-Hellman) og MÅ være hemmelig. Forskjellig for hver økt.

Hvorfor: De løser hver sitt problem. Nonce sikrer mot replay; IV sikrer mot mønstergjenkjenning innen én melding/økt; sesjonsnøkkel skadebegrenser kompromittering til én økt og gir forward secrecy i moderne protokoller. Eksamenstips: nonce ↔ ferskhet, IV ↔ randomisering, sesjonsnøkkel ↔ konfidensialitet.

Svar: ClientHello (med liste over støttede cipher suites), ServerHello, sertifikat og PMS sendes alle før kryptering er etablert. På slutten sender klienten en HMAC over alle håndtrykksmeldinger den har sett, og serveren tilsvarende. Begge regner ut forventet HMAC og avbryter hvis det ikke stemmer.

Hvorfor: Uten dette kunne Trudy som woman-in-the-middle fjerne sterke algoritmer fra ClientHello og tvinge fram en svak cipher suite (downgrade attack). Siden HMAC bruker M-nøkkel som bare partene kjenner, oppdager begge enhver tukling med håndtrykket.

Svar:

Segment replay (record-nivå): Trudy fanger en gyldig record og spiller den av senere i samme økt. Stoppes av sekvensnummer i HMAC-beregningen.

Connection replay (hel økt): Trudy fanger hele TLS-økten og spiller den av neste dag som om hun var Bob. Stoppes av nonces i ClientHello/ServerHello — siden Alice sender ny nonce hver økt blir Master Secret forskjellig, og gamle records vil feile MAC-sjekk.

Hvorfor begge trengs: Sekvensnummer alene holder ikke for hele økter (de teller fra 0 hver gang). Nonces alene holder ikke innen en økt. Til sammen dekker de begge angrep.

Svar: Klienten genererer en tilfeldig PMS, krypterer den med serverens offentlige nøkkel og sender EMS = K_A⁺(PMS). Begge parter kombinerer PMS med klient-nonce og server-nonce gjennom en standardisert key derivation function (KDF) for å få Master Secret. MS deles så opp i fire nøkler: E_A, E_B, M_A, M_B.

Hvorfor PMS i mellom: Public-key-kryptering brukes bare på den korte PMS-en (rask). Selve MS regnes lokalt — den krysser aldri linjen. Nonces sikrer at MS er forskjellig hver økt, selv om PMS skulle gjenbrukes.

Svar: Det første TCP-segmentet i en forbindelse har ACK = 0 (bare SYN). Alle senere segmenter, inkludert SYN-ACK fra serveren, har ACK = 1. Brannmuren konfigureres til å droppe alle innkommende TCP-segmenter med ACK=0.

Resultat: Eksterne kan aldri åpne TCP-forbindelser inn (de starter med ACK=0). Svar på forbindelser åpnet innefra slipper gjennom (ACK=1).

Begrensning: En angriper som fabrikkerer en pakke med ACK=1 (uten ekte forbindelse) slipper gjennom. Det er nettopp dette som motiverer stateful filtre.

Svar: Et smurf-angrep er et refleksjons-DoS-angrep. Angriperen sender en ICMP echo request (ping) til en broadcast-adresse (f.eks. 130.207.255.255) med offerets IP forfalsket som kilde. Alle verter på subnettet svarer offeret samtidig — én pakke kan generere hundrevis av svar mot offeret.

Brannmur-regel: Drop alle ICMP-pakker med broadcast-destinasjon. Standard ACL-regel.

Hvorfor det rammer tilgjengeligheten: Offeret oversvømmes med ICMP-svar det aldri ba om. Båndbreddeflom forsterket av reflektorer — ingen kryptografi involvert.

Svar:

1. Færre cipher suites: 5 valg mot 37 i 1.2 — bare moderne, sikre kombinasjoner.
2. Krever Diffie-Hellman for nøkkelutveksling — RSA-nøkkelutveksling er fjernet.
3. AEAD-modus: kryptering og integritet i én operasjon (f.eks. AES-GCM, ChaCha20-Poly1305).
4. HMAC bruker SHA-256 eller SHA-384.

Hvorfor: TLS 1.2 hadde for mange svake legacy-valg. Krymping av cipher-suite-listen og krav om AEAD eliminerer hele klasser av angrep ved konstruksjon.

Svar: K_HSS-M er den forhåndsdelte hemmelige nøkkelen mellom én bestemt mobil og dens hjemmenett. Den finnes på nøyaktig to steder:

• På SIM-kortet (lagret av operatøren ved utstedelse).
• I HSS (Home Subscriber Server) i hjemmenettet, sammen med kundens IMSI.

Verken basestasjonen, MME i besøkt nett eller noen annen part kjenner K_HSS-M.

Hvorfor: Ved å holde nøkkelen ute av besøkt operatør kan ikke en kompromittert utenlandsk operatør utstede falske godkjenninger eller dekryptere brukerdata.

Svar: Et SIM-kort inneholder:

• IMSI — globalt unik abonnent-identifikator.
• K_HSS-M — forhåndsdelt hemmelig nøkkel mot hjemmenettets HSS.
• Liten prosessor som kan gjøre kryptografiske beregninger uten å eksponere K_HSS-M.

Hvorfor SIM-kort: Identiteten er fysisk knyttet til chipen — bytter du telefon, flytter du SIM-kortet. K_HSS-M forlater aldri SIM-kortet, så selv malware på mobilen kan ikke lekke nøkkelen.

Svar:

• AS (Authentication Server, WiFi): Sentral autentiserings-server (typisk RADIUS).
• AP (Access Point, WiFi): Radioenhet; videresender autentiseringstrafikk.
• eNode-B (4G): Basestasjon; videresender autentiseringstrafikk.
• MME (4G besøkt nett): Tar autentiseringsbeslutningen ut fra HSS-data.
• HSS (4G hjemmenett): Endelig autoritet; kjenner alle K_HSS-M.

Mapping: AS i WiFi spiller samme logiske rolle som MME+HSS gjør sammen i 4G. AP og eNode-B har samme rolle (radio + relay).

Svar:

• K_M-AP (WiFi): Symmetrisk sesjonsnøkkel mellom mobil og access point. Brukes til AES-kryptering av frames over 802.11-linken. Utledes lokalt av begge fra passord, nonces og MAC-adresser.
• K_BS-M (4G): Symmetrisk sesjonsnøkkel mellom mobil og base station. Brukes til AES-kryptering av frames over 4G-linken. Utledes fra K_HSS-M og verdier i autentiseringen.

Felles prinsipp: Det forhåndsdelte hemmelige (passord/K_HSS-M) brukes aldri direkte til kryptering — det utledes en kortvarig, økt-spesifikk nøkkel. Lekker økt-nøkkelen, lekker bare én økts trafikk.

Svar: TLS er ikke et eget OSI-lag, men et sublag mellom TCP og applikasjonen. Applikasjonen skriver til en TLS-socket; TLS krypterer og leverer dataene til TCP som vanlige TCP-segmenter. HTTPS bruker TCP-port 443 (mot 80 for HTTP).

Hvorfor det er praktisk: Plasseringen er protokoll-agnostisk — HTTPS, IMAPS, SMTPS, FTPS bruker alle samme TLS-sublag. TCP og IP under bryr seg ikke om innholdet er kryptert.

Svar: Vanligvis tenker vi på autentisering som «nettverket sjekker at brukeren er ekte». Men i trådløse nett må også mobilen sjekke at nettverket er ekte. Hvis ikke kan en angriper sette opp en falsk basestasjon (en rogue base station) som lurer mobilen til å koble seg til, fanger opp identitet og sporer bevegelser.

Hvordan oppnås det: I 4G verifiserer mobilen auth_token (fra HSS, signert med K_HSS-M). I WPA3 verifiserer mobilen HMAC fra AS (basert på passordet). Bare ekte nettverk har den hemmelige nøkkelen som trengs — falsk basestasjon kan ikke fabrikkere disse.

Svar: En IMSI-catcher er en falsk basestasjon som utgir seg for å være et legitimt mobilnett. Mobiler i nærheten kobler seg til (de velger sterkeste signal) og gir fra seg sin IMSI. I 4G LTE sendes IMSI i klartekst ved første tilkobling — IMSI-catcheren kan dermed logge identiteter og spore bevegelser.

Hvorfor 5G fikser det: I 5G krypteres IMSI med public-key-kryptografi før den sendes — bare hjemmenettets HSS har den private nøkkelen som kan dekryptere. Falske basestasjoner ser bare en kryptert verdi.

Svar: Eksempelet (fra boken) viser at TCP-checksum er ubrukelig som integritetsbeskyttelse. En angriper kan trivielt endre beløpet uten å endre checksum.

Hvorfor: TCP-checksum er en enkel sum av byte-grupper, designet for tilfeldige bitfeil i overføring. Den oppdager ikke ondsinnet manipulasjon. En kryptografisk hashfunksjon (SHA-256) er kollisjonsresistent — det er praktisk umulig å konstruere to meldinger med samme hash. Derfor må MAC og digitale signaturer bruke kryptografisk hash, ikke checksum.

Svar:

• Blokkstørrelse: Alltid 128 bit, uansett nøkkellengde.
• Nøkkellengder: 128, 192 eller 256 bit.

Eksamenstips: Det er nøkkellengden som varierer, ikke blokkstørrelsen. AES krypterer alltid 128-bits blokker; nøkkelen avgjør hvor mange runder substitusjon/permutasjon som gjøres internt. Brute force på AES-128 tar ~149 billioner år hvis DES-56 tar 1 sekund.

Svar:

• Type-felt (klartekst): handshake, applikasjonsdata eller close_notify.
• Versjon-felt (klartekst): TLS-versjon.
• Lengde-felt (klartekst): bytes i data + MAC.
• Data-felt (kryptert med E_A eller E_B).
• HMAC-felt (kryptert sammen med data, beregnet over data + sekvensnummer + faste felt med M_A/M_B).

Hvorfor lengden er i klartekst: TCP gir en byte-strøm uten meldingsgrenser. TLS bruker lengden til å plukke ut én record om gangen før den dekrypteres.

Svar: WPA2 bruker CCMP (Counter Mode CBC-MAC Protocol) basert på AES. CCMP gir både konfidensialitet og integritet i samme operasjon.

Hvorfor det erstattet WEP: WEP brukte RC4 med dårlig IV-håndtering — knekkes på minutter. AES-CCMP regnes kryptografisk solid den dag i dag. Svakheten ved WPA2 er 4-veis-håndtrykket, som tillater offline ordbokangrep mot fanget trafikk hvis passordet er svakt — det WPA3 SAE løser.

Svar:

MAC i kap. 8: Message Authentication Code — kort kryptografisk verdi som beviser meldingsintegritet og avsenderautentisering (delt nøkkel).

MAC i kap. 6: Medium Access Control — protokollen og adressen som styrer hvem som sender på et delt medium (f.eks. 802.11 MAC-adresser).

Eksamenstips: Les konteksten — snakker vi om kryptografi/integritet (kap. 8) eller delt medium/adressering (kap. 6)?

Svar:

• Hjemmenett: Operatøren du har abonnement hos. Inneholder HSS med din K_HSS-M. Forblir siste autoritet selv når du roamer.
• Besøkt nett: Operatørnettet du faktisk er koblet til akkurat nå (f.eks. en utenlandsk operatør). Inneholder MME og basestasjoner. Får aldri direkte tilgang til K_HSS-M.

5G-endring: Selve autentiseringsbeslutningen flyttes tilbake til hjemmenettet — enda mindre tillit til besøkt operatør.

Svar: AES (Advanced Encryption Standard) er den dominerende symmetriske krypteringsalgoritmen i:

• TLS (HTTPS) — AES-GCM, AES-CBC.
• WPA2/WPA3 (WiFi) — AES-CCMP.
• IPsec (VPN).
• 4G/5G — AES for trafikkryptering.

Hvorfor: Rask (AES-NI-instruksjoner i moderne CPU-er), godt analysert, NIST-standardisert siden 2001. AES brukes til selve dataene; public-key (RSA, DH) bare til å utveksle AES-nøkkelen.

Svar:

• Eierens identitet (Common Name, ofte domenenavn).
• Eierens offentlige nøkkel og hvilken algoritme den er for.
• Utstedende CA og dens identitet.
• Gyldighetsperiode (utstedelsesdato + utløpsdato).
• Serienummer (unikt hos CA).
• CA-ens digitale signatur over alt over.

Hvorfor signaturen er det avgjørende: Hvem som helst kan lage et dokument som påstår «ntnu.no har offentlig nøkkel X». CA-ens signatur (gjort med CA-ens private nøkkel) er det som binder identitet til nøkkel og kan ikke forfalskes.

Svar: Non-repudiation betyr at avsenderen ikke i ettertid kan benekte å ha sendt en melding. Hvis Bob signerer med K_B^-, kan Alice bevise i en domstol at Bob må ha signert — bare Bob har den private nøkkelen som kunne lage signaturen.

Hvorfor MAC ikke gir det: En MAC krever at begge parter kjenner K_S. Hvis Bob hevder «det var Alice som lagde MAC-en», kan domstolen ikke avgjøre — begge kunne ha lagd den. Bare digital signatur (privat-/offentlig-nøkkelpar) gir non-repudiation.

Svar: Public-key (RSA) er ~1000× tregere enn AES per byte. Lange meldinger må også deles opp i RSA-blokker (typisk 2048 bit), noe som blir upraktisk.

Hybridkryptering løser det:

1. Generer tilfeldig sesjonsnøkkel K_S.
2. Krypter selve meldingen med K_S (rask AES).
3. Krypter bare K_S med Bobs offentlige nøkkel.

Mønsteret går igjen i TLS, IPsec, sikker e-post og WPA3.

Svar: Når Alice verifiserer K_B⁺(K_B^-(H(m))) = H(m), vet hun:

1. Bob signerte: Bare K_B^- kunne lage signaturen, og bare Bob har den.
2. Bob signerte akkurat m: Hvis m endres, blir H(m) annerledes, og verifikasjonen feiler.
3. Non-repudiation: Alice kan vise m og signaturen til en domstol som bevis.

Hvorfor det er kompakt: Én operasjon (verifikasjon med offentlig nøkkel) gir tre ulike sikkerhetsegenskaper — autentisering av avsender, integritet av melding, og uforfalskbarhet.

Svar: Hver TLS-record har en HMAC beregnet over (data + sekvensnummer) med M_A eller M_B. Mottakeren:

1. Dekrypterer recorden med E_A/E_B.
2. Beregner forventet HMAC selv (har samme M-nøkkel og kjenner sekvensnummeret).
3. Sammenligner med HMAC-en i recorden.

Avvik → recorden er manipulert eller en bit er korrupt → forbindelsen lukkes.

Hvorfor det virker: Trudy uten M-nøkkelen kan ikke fabrikkere en gyldig HMAC. Sekvensnummer hindrer henne i å spille av en eldre gyldig record.

Svar: I et VPN mellom firmakontorer ønsker man å skjule både innholdet og strukturen i den interne trafikken — også de interne IP-adressene. Tunnel-modus pakker hele det opprinnelige IP-datagrammet (inkludert intern header) inn i en kryptert payload, og setter på en ny ytre header med gateway-rutere som adresser.

Transport-modus krypterer bare payloaden — den opprinnelige IP-headeren er fortsatt synlig. Egnet for host-to-host, men avslører nettverksstruktur.

Praksis: Nesten all VPN-bruk er tunnel-modus mellom gateway-rutere.

Svar: Tabellen har én linje per aktiv TCP-forbindelse: kilde-IP, dest-IP, kilde-port, dest-port. Oppdateres ved:

• SYN observert → ny linje legges til.
• FIN observert → linjen markeres for sletting.
• Inaktivitet > timeout (typisk 60 s) → linjen slettes.

Hvorfor: For hver innkommende pakke sjekker brannmuren om den hører til en kjent forbindelse. En pakke med ACK=1 fra en server slipper bare gjennom hvis tabellen viser at intern klient nylig åpnet en forbindelse mot den serveren — fabrikkerte ACK-pakker fanges opp.

Svar:

• SHA-1: 160-bits hash. Foreldet — kollisjoner ble demonstrert i 2017.
• SHA-256: 256-bits hash. Del av SHA-2-familien. Anbefalt standard i dag.
• MD5: 128-bits hash. Foreldet — kollisjoner kjent på 2000-tallet.

Hvorfor lengden betyr noe: Lengre hash gir større nøkkelrom, men også viktigere er at konstruksjonen ikke er knekt — selv 256 bit hjelper lite hvis algoritmen har strukturelle svakheter.

Svar: Public-key brukes ikke til selve dataene, men til to ting:

1. Autentisering via sertifikatverifisering — du verifiserer CA-signaturen på serverens sertifikat med CA-ens forhåndsinstallerte offentlige nøkkel og vet at den offentlige nøkkelen tilhører serveren.
2. Nøkkelutveksling — krypter en symmetrisk sesjonsnøkkel med serverens offentlige nøkkel, eller utled en felles nøkkel via DH.

Etter dette: bare AES brukes til selve dataene. Mønsteret går igjen i TLS, IPsec, sikker e-post og WPA3.

Svar: MME er bare en middleman. HSS bruker K_HSS-M til å forhåndsberegne to verdier:

• auth_token (sendes til mobilen via MME) — mobilen verifiserer det med sin egen K_HSS-M.
• xres_HSS (sendes til MME) — MME holder dette og venter på mobilens svar res_M. MME sammenligner res_M med xres_HSS uten å trenge K_HSS-M.

Hvorfor: Selv om en besøkt operatør blir kompromittert, kan ikke angriperen utstede falske godkjenninger — de mangler K_HSS-M. Minimal tillit til besøkt operatør.

Svar: HSS bruker K_HSS-M til å lage auth_token (f.eks. ved å kryptere mobilens IMSI eller en utfordring med K_HSS-M). Når mobilen mottar auth_token, verifiserer den med sin egen K_HSS-M. Stemmer resultatet, vet mobilen at avsenderen kjenner K_HSS-M — og siden bare HSS har den, må forespørselen ha gått gjennom det ekte hjemmenettet.

Hvorfor det stopper falske basestasjoner: En IMSI-catcher uten K_HSS-M kan ikke generere et gyldig auth_token. Mobilen vil ikke akseptere meldingen, og kobler seg ikke videre.

Svar:

Sikker e-post: Beskytter selve meldingsinnholdet end-to-end mellom Alice og Bob. Meldingen kan lagres på e-postserveren i kryptert form.

TLS: Beskytter trafikken under transport mellom klient og server. Når meldingen ligger hos serveren, er den dekryptert.

Hvorfor begge eksisterer: TLS sikrer at «ingen mellom klient og server» kan lese — men serveren selv kan. End-to-end-kryptering sikrer at heller ikke serveren kan lese, til en kostnad av mer komplisert nøkkelhåndtering.

Svar: En brannmur som ser TLS-trafikk på port 443 ser bare at det er TLS — ikke hva som faktisk sendes. Den kan ikke:

• Inspisere innhold for malware.
• Skille en legitim webside fra command-and-control-tilbakemelding fra et infisert system.
• Filtrere på applikasjonsdata (f.eks. URL-er innen HTTPS).

Hvorfor: Personvern-egenskapen ved kryptering blir en blindsone for brannmuren. Bedrifter løser det med TLS-inspeksjon (egne CA-sertifikater installert i klientene), men det bryter end-to-end-prinsippet.

Svar: I WPA3-håndtrykket sendes K_M-AP aldri over lufta. I stedet:

1. AS sender Nonce_AS i klartekst.
2. Mobilen genererer Nonce_M og beregner K_M-AP = KDF(passord, Nonce_AS, Nonce_M, MAC-adresser) lokalt.
3. AS gjør samme beregning lokalt.

Begge ender opp med samme nøkkel uten at den krysset luften.

Hvorfor: Hvis K_M-AP ble sendt, måtte den vært kryptert med en allerede etablert nøkkel — som vi ikke har. Lokal utledning unngår problemet.

Svar: Public-key-operasjoner er ~1000× tregere enn symmetrisk per byte. Å signere lange meldinger direkte ville:

• Tatt lang tid.
• Krevd at meldingen deles opp i RSA-blokker (typisk 2048 bit).
• Gjort verifisering tilsvarende treg.

Løsning: H(m) er kort (256 bit for SHA-256), uavhengig av meldingens lengde. Bob signerer bare H(m) → én rask RSA-operasjon. Kollisjonsresistensen i hashfunksjonen sikrer at signaturen er bundet til akkurat denne meldingen.

Svar:

(a) Krypterer m med K_B⁺ (eller K_S): Konfidensialitet — bare Bob kan lese. Ikke hvem avsenderen er.

(b) Signerer H(m) med K_A^-: Integritet + at Alice signerte. Ikke konfidensialitet — meldingen sendes i klartekst.

(c) Gjør begge (hybrid + signatur): Konfidensialitet + integritet + autentisering — alle tre.

Hvorfor: Boken bygger sikkerhet trinnvis — start med ett mål, vis svakheten, legg til neste mekanisme. Gir en mal for å analysere enhver protokoll: hvilken egenskap dekker hver byggekloss?

Svar: Master Secret (MS) er den felles hemmeligheten Alice og Bob har etter TLS-håndtrykket. Fra MS utledes fire nøkler:

• E_A — kryptering A→B
• E_B — kryptering B→A
• M_A — MAC A→B
• M_B — MAC B→A

Hvorfor fire: Aldri bruk samme nøkkel til to ulike formål eller retninger. Forskjellig per retning hindrer reflection attacks; forskjellig kryptering vs MAC isolerer skadeomfang hvis én algoritme blir svekket.

Svar:

• WPA1 (TKIP): Mellomløsning som la til meldingsintegritet på toppen av WEPs RC4. Fortsatt svakt; brukes ikke i dag.
• WPA2 (802.11i, CCMP/AES): Sterk kryptering. Industristandard i mer enn et tiår. Svakhet: 4-veis-håndtrykket tillater offline ordbokangrep mot svake passord.
• WPA3 (SAE): Erstatter håndtrykket — passordet kan ikke gjettes offline. Hver gjettings-runde krever ny aktiv handshake mot AP-et.

Lærdom: Sterk kryptering hjelper lite hvis nøkkelutvekslingen lekker.

Svar: DoS-angrep angriper tilgjengelighet (A i CIA-triaden). Det rammer ikke konfidensialitet, integritet eller autentisering — datene som passerer er fremdeles uforandret og uleste.

Hvorfor: Kryptografi løser ikke tilgjengelighet. Forsvar er driftsmessige: brannmurer, oppstrøms-filtrering, lastfordeling, SYN cookies. DDoS er særlig vanskelig fordi trafikken kommer fra mange ekte IP-adresser samtidig.

Svar: RSA og DH bygger på modulær eksponentiering med veldig store tall (2048–4096 bits). Hver kryptering/signatur involverer mange multiplikasjoner og modulo-operasjoner på heltall som ikke får plass i én CPU-register. Til sammenligning kjører AES på 128-bits blokker som passer rett inn i moderne CPU-registre. Resultat: AES er typisk ~1000× raskere enn RSA per byte.

Når man betaler kostnaden: Public-key brukes én gang per økt til (1) autentisering via sertifikatverifisering og (2) nøkkelutveksling. Etter at en symmetrisk sesjonsnøkkel er etablert, brukes bare AES til selve dataene. Mønsteret går igjen i TLS, IPsec, sikker e-post og WPA3.