Kryptografi og integritet
De fire sikkerhetsegenskapene, symmetrisk og offentlig nøkkelkryptografi, meldingsintegritet, digitale signaturer og sertifiseringsinstanser.
Hva er nettverkssikkerhet?
Fire egenskaper som et sikkert kommunikasjonssystem må oppfylle — og hva som skjer når det ikke gjør det.
Når Alice sender en melding til Bob over Internett, passerer den gjennom titalls rutere, svitsjer og linker som ingen av dem kontrollerer. Hvem som helst langs veien — en nysgjerrig nettadministrator, en hacker på et åpent WiFi, en statlig etterretningstjeneste — kan i prinsippet lytte, endre eller blokkere meldingen. Nettverkssikkerhet handler om å gjøre det umulig, eller i det minste ugjennomførbart, for en tredjeperson å misbruke kommunikasjonen.
Et sikkert kommunikasjonssystem må oppfylle fire grunnleggende egenskaper:
Bare avsender og tiltenkt mottaker skal kunne forstå innholdet i meldingen. Senderen krypterer, mottakeren dekrypterer. Alle andre ser bare uforståelig støy.
Sender og mottaker skal kunne bekrefte hverandres identitet. Når du logger inn på nettbanken din, vil banken vite at det virkelig er deg — og du vil vite at du virkelig snakker med banken, ikke en falsk kopi.
Innholdet i meldingen skal ikke kunne endres underveis — verken av en angriper eller ved tilfeldige feil — uten at mottakeren oppdager det.
Tjenestene må faktisk være tilgjengelige for legitime brukere. Et Denial-of-Service-angrep (DoS) prøver nettopp å bryte denne egenskapen ved å oversvømme en server med så mye trafikk at den ikke klarer å betjene ekte forespørsler.
Alice, Bob og Trudy
I sikkerhetsverdenen bruker vi tre faste karakterer: Alice og Bob vil kommunisere sikkert med hverandre. Trudy (fra «intruder») er angriperen som sitter mellom dem og prøver å sabotere. Trudy kan gjøre overraskende mye:
Hvem er Alice og Bob i praksis? Det kan være en nettleser og en nettbank, to DNS-servere som utveksler oppslag, to BGP-rutere som deler rutingtabeller, eller rett og slett to mennesker som sender e-post. Trudy kan være hvem som helst med tilgang til nettverket mellom dem.
Hva kan en angriper gjøre?
- Avlytte (eavesdrop): passivt fange opp meldinger uten at noen merker det.
- Sette inn meldinger: aktivt injisere falske pakker i en pågående forbindelse.
- Utgi seg for andre (spoofing): forfalske kildeadressen i en pakke slik at den ser ut som den kommer fra noen andre.
- Kapre en forbindelse (hijacking): ta over en pågående TCP-forbindelse ved å fjerne den ene parten og tre inn i deres sted.
- Tjenestenekt (DoS): oversvømme en server med forespørsler slik at den ikke kan betjene ekte brukere.
Symmetrisk nøkkelkryptografi
Når sender og mottaker deler én og samme hemmelige nøkkel.
Kryptografi er verktøykassen som gjør de fire sikkerhetsegenskapene mulige. Det grunnleggende oppsettet er alltid det samme: en klartekst (plaintext) m sendes gjennom en krypteringsalgoritme sammen med en nøkkel KA, og resultatet er en chiffertekst (ciphertext) som er uleselig for alle som ikke har den riktige dekrypteringsnøkkelen KB. Mottakeren bruker KB til å gjenskape klarteksten: m = KB(KA(m)).
I symmetrisk nøkkelkryptografi er krypterings- og dekrypteringsnøkkelen den samme: KA = KB = KS. Begge parter må altså kjenne den samme hemmeligheten. Det reiser et umiddelbart spørsmål: hvordan blir de enige om nøkkelen i utgangspunktet? Men la oss først se på selve mekanismene.
Klassiske chiffer — byggesteinene i historien
Før vi går til DES og AES er det lærerikt å se på hvordan klassiske chiffer fungerte. De er alle pensum (kap. 8.2.1), og de illustrerer prinsippene som moderne algoritmer bygger på — og hvorfor moderne algoritmer trenger å være så mye mer kompliserte.
Caesar-chiffer
Det enkleste substitusjonschifferet, oppkalt etter Julius Caesar som angivelig brukte det i militære meldinger. Hver bokstav skiftes k posisjoner i alfabetet. Med skift k = 3:
Monoalfabetisk substitusjonschiffer
Generaliseringen av Caesar: i stedet for et fast skift bruker man en vilkårlig permutasjon av alfabetet som nøkkel. Hver bokstav får sin egen, konsekvente erstatning gjennom hele meldingen.
Antall mulige nøkler er nå 26! ≈ 4 × 10²⁶ — alt for stort for brute force selv med moderne datamaskiner. Likevel er det trivielt å knekke ved frekvensanalyse: i engelsk tekst utgjør bokstaven «e» ca. 12,7 % av alle tegn, «t» ca. 9 %, «a» ca. 8 %. Tell hvilken bokstav som er hyppigst i chifferteksten — det er sannsynligvis «e». Gjenta med nest hyppigste, sjekk vanlige bigrammer som «th», «he», «in», og du har hele substitusjonstabellen på 100–200 tegn chiffertekst. Stort nøkkelrom hjelper ikke når strukturen i klarteksten lekker rett gjennom.
Polyalfabetisk chiffer (Vigenère)
For å beskytte mot frekvensanalyse roterer man mellom flere substitusjoner. Vigenère-chifferet bruker et nøkkelord, der hver bokstav i nøkkelordet velger ett av 26 mulige Caesar-skift. Slik krypteres samme klartekstbokstav ulikt avhengig av sin posisjon.
Polyalfabetisk kryptering var i bruk fra 1500-tallet helt frem til andre verdenskrig (tyske Enigma var en mekanisk variant). Det er fortsatt sårbart hvis nøkkelordet er kort: når du først har gjettet nøkkellengden, kan du gjøre frekvensanalyse på hver «posisjon mod nøkkellengde» separat — og hvert delproblem er bare et Caesar-chiffer.
Hvorfor klassiske chiffer ikke holder i moderne nett
Felles for alle klassiske chiffer er at de behandler én bokstav om gangen og lar statistisk struktur lekke gjennom. Moderne blokkchiffer som DES og AES opererer i stedet på blokker av bits (64 eller 128) og bruker mange runder med substitusjon, permutasjon og XOR med rundenøkler. Resultatet er at hver enkelt bit av chifferteksten avhenger av hver bit i klarteksten og nøkkelen — to egenskaper Claude Shannon kalte confusion (skjul nøkkelen) og diffusion (spred klarteksten utover hele blokken). Frekvensanalyse fungerer ikke lenger.
Å bryte kryptering
En angriper kan prøve å knekke en kryptering på tre måter:
| Angrepstype | Hva Trudy har | Strategi |
|---|---|---|
| Ciphertext-only | Bare chifferteksten | Brute force (prøv alle nøkler) eller statistisk analyse |
| Known-plaintext | Noen klartekst-chiffertekst-par | Bruk parene til å utlede nøkkelen |
| Chosen-plaintext | Kan velge klartekst og se resulterende chiffertekst | Velg strategisk klartekst for å avdekke nøkkelstrukturen |
Blokkchiffer og strømchiffer
Symmetriske algoritmer kommer i to hovedformer. Et strømchiffer krypterer én bit eller ett byte om gangen ved å XOR-e klarteksten med en pseudo-tilfeldig nøkkelstrøm. Et blokkchiffer deler i stedet meldingen i blokker av fast størrelse (typisk 64 eller 128 bit) og krypterer hver blokk for seg. DES og AES er begge blokkchiffer, og dominerer i moderne nettverksprotokoller (TLS, IPsec, WPA2/WPA3).
DES — Data Encryption Standard
DES var den amerikanske standarden for symmetrisk kryptering fra 1977 (FIPS PUB 46). Den bruker en 56-bits nøkkel og opererer på 64-bits blokker av klartekst. Hvor sikkert er DES? Ikke sikkert nok. I DES Challenge ble en 56-bits nøkkel knekt med brute force på under ett døgn. Løsningen var 3DES: krypter tre ganger med tre forskjellige nøkler, som effektivt gir en 168-bits nøkkelstyrke.
AES — Advanced Encryption Standard
AES erstattet DES i 2001 som NIST-standard. Den opererer på 128-bits blokker og støtter nøkkellengder på 128, 192 eller 256 bit. For å sette det i perspektiv: hvis brute force på DES tar ett sekund, ville brute force på AES med 128-bits nøkkel ta omtrent 149 billioner år. AES er i dag den dominerende symmetriske algoritmen — den brukes i TLS, WiFi (WPA2/WPA3), IPsec og mye annet.
Cipher Block Chaining (CBC) og IV
Et blokkchiffer alene har et subtilt, men alvorlig problem: hvis Alice krypterer hver blokk uavhengig med samme nøkkel, vil to like klartekstblokker gi to like chiffertekstblokker. En angriper som ser «AB12 ... AB12» i chifferteksten vet umiddelbart at de to klartekstblokkene er like — selv uten å kjenne innholdet. For strukturerte data (e-post-headere, faste passordfelt, bilder med ensfargede områder) lekker dette mye informasjon. Det er også et problem at samme melding kryptert to ganger blir helt identisk på linja, slik at Trudy kan kjenne igjen «meldingen jeg så i går».
Løsningen er Cipher Block Chaining (CBC): før hver klartekstblokk krypteres, XOR-er man den med forrige chiffertekstblokk. Slik blir hver blokk avhengig av alle de foregående. Den aller første blokken har ingen «forrige» — derfor genererer Alice en tilfeldig Initialization Vector (IV) som hun XOR-er med blokk 1. IV-en sendes med meldingen i klartekst (den trenger ikke være hemmelig, bare uforutsigbar og ny for hver melding). Resultatet: samme melding kryptert to ganger med samme nøkkel produserer helt forskjellige chiffertekster, fordi IV-en er forskjellig.
Offentlig nøkkelkryptografi
En radikal idé: publiser den ene nøkkelen for hele verden — og hold den andre strengt privat.
Symmetrisk kryptografi har et grunnleggende problem: Alice og Bob må på forhånd bli enige om en felles hemmelig nøkkel. Hvis de aldri har møttes fysisk, hvordan gjør de det uten at Trudy fanger opp nøkkelen? Offentlig nøkkelkryptografi — foreslått uavhengig av Diffie og Hellman (1976) og av RSA-gruppen (Rivest, Shamir, Adleman, 1978) — løser dette på en elegant måte.
Idéen er enkel men revolusjonerende: Bob har to nøkler. Den ene — den offentlige nøkkelen KB+ — publiserer han for hele verden. Den andre — den private nøkkelen KB- — holder han strengt for seg selv. Systemet har to avgjørende egenskaper:
- Krypterer du med den offentlige nøkkelen, kan bare den private dekryptere: KB-(KB+(m)) = m
- Gitt den offentlige nøkkelen er det beregningsmessig umulig å finne den private.
I praksis kombineres de to: offentlig nøkkelkryptografi brukes til å utveksle en felles symmetrisk sesjonsnøkkel, og deretter brukes den raske symmetriske algoritmen (f.eks. AES) til å kryptere selve datastrømmen. Det er dette mønsteret vi kommer til å se igjen og igjen — i sikker e-post, i TLS, og i IPsec.
Alice vil sende en kryptert melding til Bob. Hun har aldri møtt Bob, men kjenner hans offentlige nøkkel. Hvilken nøkkel bruker hun til å kryptere meldingen?
Meldingsintegritet og digitale signaturer
Hvordan bevise at en melding ikke er endret underveis — og at det virkelig var Bob som sendte den.
Kryptering gir oss konfidensialitet, men det er ikke nok. Selv om Trudy ikke kan lese meldingen, kan hun kanskje endre noen bits i chifferteksten uten å vite hva hun endrer. Eller hun kan sende en helt ny melding og late som den kommer fra Bob. Vi trenger to ting til: meldingsintegritet (innholdet er uendret) og autentisering (avsenderen er den de utgir seg for å være).
MAC — symmetrisk integritet og avsenderautentisering
Når Alice og Bob allerede deler en hemmelig nøkkel KS, kan de feste en Message Authentication Code (MAC) til meldingen: en kort verdi som bare noen som kjenner KS kan ha beregnet riktig. Mottakeren beregner samme MAC fra meldingen og nøkkelen; stemmer den ikke, er meldingen endret eller forfalsket.
HMAC (Hash-based Message Authentication Code) er den vanlige konstruksjonen i praksis: man kombinerer en kryptografisk hash (f.eks. SHA-256) med den hemmelige nøkkelen på en standardisert måte (RFC 2104). Det er ikke trygt å «bare» hashe nøkkel og melding sammen med enkle mønstre (f.eks. H(KS || m)) — lengdeutvidelsesangrep og andre sårbarheter gjorde at HMAC fikk en presis definisjon.
MAC: krever delt hemmelig nøkkel; gir integritet og at meldingen må komme fra noen som kjenner nøkkelen (ofte to kjente parter, f.eks. i TLS eller WiFi).
Digital signatur: bruker privat/offentlig nøkkelpar; mottakeren trenger ikke delt hemmelighet med avsender, og man kan få ikke-benekting overfor tredjepart.
Digitale signaturer
En digital signatur er den kryptografiske versjonen av en håndskrevet signatur, men mye sterkere. Bob signerer en melding m ved å kryptere den (eller en hash av den) med sin private nøkkel KB-. Resultatet er signaturen KB-(m).
Når Alice mottar meldingen og signaturen, anvender hun Bobs offentlige nøkkel KB+ på signaturen. Hvis KB+(KB-(m)) = m, vet hun to ting:
- Bob signerte meldingen — fordi bare Bob har den private nøkkelen som kunne lage den signaturen.
- Meldingen er uendret — fordi enhver endring i m ville gjort at verifiseringen feiler.
I tillegg får vi ikke-benekting (non-repudiation): Alice kan vise meldingen og signaturen til en tredjepart (f.eks. en domstol), og bevise at Bob må ha signert, fordi bare Bobs private nøkkel kunne produsert den signaturen.
Message digest og hashfunksjoner
Å public-key-kryptere en hel lang melding er beregningsmessig dyrt. Løsningen er å bruke en hashfunksjon H som lager et kort «fingeravtrykk» av meldingen — en message digest H(m) av fast lengde. I stedet for å signere hele m, signerer Bob bare H(m). Alice verifiserer ved å: (1) beregne H(m) selv fra den mottatte meldingen, (2) dekryptere signaturen med Bobs offentlige nøkkel, og (3) sjekke at de to hashene er like.
En kryptografisk hashfunksjon har tre viktige egenskaper:
- Mange-til-en: forskjellige meldinger kan i prinsippet gi samme hash (men det skal være ekstremt usannsynlig).
- Fast lengde: uansett hvor lang meldingen er, gir hashen en output av fast størrelse.
- Enveisfunksjon: gitt en hashverdi x er det beregningsmessig umulig å finne en melding m slik at H(m) = x.
TCP bruker allerede en checksum for feildeteksjon — hvorfor kan vi ikke bruke den? Fordi Internett-checksummen er for enkel. Det er lett å finne to forskjellige meldinger som gir nøyaktig samme checksum. For eksempel gir «IOU 100.99 BOB» og «IOU 900.19 BOB» identisk 16-bits checksum. En kryptografisk hashfunksjon (som SHA-256) gjør dette praktisk talt umulig.
Hashalgoritmer
| Algoritme | Digest-lengde | Status |
|---|---|---|
| MD5 | 128 bit | Foreldet — kollisjoner funnet |
| SHA-1 | 160 bit | Foreldet — kollisjoner demonstrert i 2017 |
| SHA-256 | 256 bit | Anbefalt standard i dag |
Sertifiseringsinstanser (CA)
Hele systemet hviler på at Alice har Bobs ekte offentlige nøkkel. Men hva om Trudy later som hun er Bob og publiserer sin egen offentlige nøkkel med Bobs navn? Da kan Trudy signere meldinger som ser ut som de kommer fra Bob.
Løsningen er en Certification Authority (CA) — en pålitelig tredjepart som binder en offentlig nøkkel til en identitet. Bob gir nøkkelen sin til en CA, beviser hvem han er, og CA-en lager et sertifikat: et dokument som inneholder Bobs identitet og offentlige nøkkel, digitalt signert av CA-en med CA-ens private nøkkel.
Når Alice trenger Bobs offentlige nøkkel, henter hun sertifikatet og verifiserer CA-ens signatur med CA-ens offentlige nøkkel. Men vent — hvor kommer CA-ens offentlige nøkkel fra? Den kommer typisk forhåndsinstallert i nettleseren eller operativsystemet ditt. Det er derfor nettleseren kan verifisere at et SSL-sertifikat fra et nettsted er ekte — den har CA-ens rot-nøkkel innebygd fra fabrikken.
Hvorfor signerer Bob en hash av meldingen sin (H(m)) i stedet for hele meldingen?