Autentiseringsløsninger i VPN og nøkkeldistribusjon

IMT4051 Cryptology Autumn Term 2004 MSc in Information Security Autentiseringsløsninger i VPN og nøkkeldistribusjon Håvard Hasli, haa_hasl@hig.no Mats Erik Smestad, mat_smes@hig.no Vidar Grønland, vid_groe@hig.no Norwegian Information Security Laboratory NISlab Department of Computer Science and Media Technology Gjøvik University College P.O. Box 191, 2802 Gjøvik, Norway

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 2 Sammendrag I dette prosjektet har vi tatt for oss måter VPN håndterer nøkkeldistribusjon og autentisering. Vi har spesielt tatt for oss sikkerhetsprotokollen IPSec, kryptoalgoritmen AES og generelt om nøkkeldistribuering. Abstract In this report we have looked at ways VPN takes care of keydistribution and authentication. We have focused on IPSec, AES and problems regarding keydistribution.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 3 Innholdsfortegnelse 1 Hva er VPN... 4 2 IPSec... 7 Autentisering... 8 Kryptering... 10 IPSec oppkobling... 11 SA... 11 IKE... 11 OAKLEY... 12 ISAKMP... 12 DOI... 12 3 Nøkkeldistribusjon... 17 Asymmetrisk kryptering... 17 Diffie-Hellmann (DH)... 17 RSA... 18 Symmetrisk kryptering... 18 AES... 18 Rijndael... 19 Hvordan fungerer Rijndael: (128bit blokklengde og nøkkellengde)... 20 Sikkerhet i Rijndael... 22 Hybride løsninger... 24 Nøkkeldistribusjon vha. kvantekryptografi (Quantum cryptography)... 25 Eksempel på kommersiell løsning... 27 Til ettertanke ved nøkkeldistribusjon... 28 4 Konklusjon... 29 5 Linker og referanser... 30

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 4 1 Hva er VPN VPN (Virtual Private Network), er et kryptosystem som gjør at man kan sikre data som går over et usikkert nettverk som f.eks. internett. Dette er ikke det samme som SSH, selv om det kanskje virker som det samme. SSH ble utviklet for at en bruker skulle kunne logge seg på en annen maskin og dermed kunne fjernadministrere maskinen. VPN er designet for at brukeren skal kunne aksessere alle ressurser tilgjengelig på et nettverk. Det vil da for brukeren virke som om han/henne sitter og jobber direkte på nettverket, selv om brukeren er koblet til utenfra. Det finnes tre typer VPN: Intranett VPN. For sammenkobling av nettverk innenfor bedriftens nett. F.eks. koble sammen nettverk i to byggninger eller distriktskontorer. Extranett VPN. Benytter internett til å distribuere konfidensiell informasjon til f.eks kunder, leverandører osv. Remote Access VPN. Benyttes av ansatte som bruker hjemmekontor eller er ute og reiser. VPN benytter seg av «tunneling», som er en punkt til punkt kobling. Denne tunnelen oppstår på det usikre nettverket (ofte internett). De to maskinene i hver ende av linken er selv ansvarlige for kryptering og dekryptering av dataene som går i tunnelen. VPN deles også opp i tre konfigurasjonskategorier: Host to host Host to gateway Gateway to gateway En VPN tunnel er alltid mellom to punkter, men det er fullt mulig å opprette koblinger til flere punkter samtidig. Hver tunnel er fortsatt separert fra de andre tunnelene. Det som ofte gjøres i store bedrifter er at de setter opp en VPN gateway som er koblet opp mot et krypteringsdomene. Da vil VPN gatewayen ta seg av all kryptering og dekryptering på vegne av nettverket.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 5 Host 1 Host 2 Host to host Krypterings Domene (nettverk) VPN Gateway Host 3 Host to gateway Klartekst Gateway to gateway Gateway2 Kryptert Tunnel Figur 1.1 Mulige oppkoblinger av VPN Det som i figur 1.1 er krypteringsdomene, er egentlig selve nettverket som aksesseres. Det foregår ingen kryptering her, siden dette er den delen som anses for å være sikkert. Dette fordi denne delen er under administratorens kontroll, noe internett ikke er. Poenget med å benytte seg av en VPN gateway er at man da får en sentral enhet å administrere mhp sikkerhetspolicy og kontroll av trafikk. Et annet poeng er at systemet ville blitt ubrukelig om en bruker skulle sette opp tunneler direkte til alle maskinene på nettverket han vil aksessere. VPN kan kobles opp på to forskjellige måter: Tunneling mode Transport mode «Tunneling mode» benyttes når man ønsker høy sikkerhet i overføringen. «Transport mode» benyttes når en bruker ønsker direkte kontakt med en annen maskin. Denne er noe raskere enn «tunneling mode», pga av at den ikke endrer IP pakka så mye. Felles for alle VPN systemer: Begge parter må autentisere seg for å kunne opprette en tunnel, dette for å sikre at de krypterte dataene kommer dit de skal. Begge parter må bli enige om hvilke protokoller som skal benyttes for kryptering og sikring av integritet. Når partene har blitt enige vil det genereres en nøkkel som vil bli brukt ved kryptering/dekryptering.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 6 Hvorfor VPN? Fordelene med å benytte VPN er at man da kan opprette en sikker forbindelse over et usikkert nettverk. Alternativene er å leie en fast linje mellom to punkter, eller å sende info ukryptert på internett. VPN er et kompromiss mellom de to ovennevnte, ved at info sendes kryptert over internett. Den største fordelen med VPN ligger i kostnaden. Det er dyrt å leie en fast linje i forhold til å benytte VPN. En annen fordel er at om den faste linjen brytes så har man ikke noe nett, men ved da å benytte internett, så finnes det som oftest en annen vei å gå. Ulempen er at man ikke har en garantert båndbredde tilgjengelig hele tiden. En annen fordel er at man kan koble seg opp mot bedriftens nettverk fra hvor som helst, bare man har tilgang til internett.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 7 2 IPSec Virtual Private Network(VPN) er en tjeneste som øker i popularitet. Spesielt større bedrifter har tatt i bruk denne tjenesten, som gir arbeidere muligheten til å jobbe fra et annet sted(for eksempel hjemme). Første steget var å sette alle pc ene til firmaet i et nettverk slik at man kunne dele data på en mye mer effektiv måte. Bedriften ble mer integrert. Når man satt ved pulten sin på jobben kunne man ha tilgang til det man måtte trenge i bedriftens database. Men de arbeiderne som befant seg fysisk utenfor bedriften, og som trengte disse dataene, måtte enten ta seg en tur på kontoret eller så måtte bedriften legge sin informasjon på en usikker tilkobling. Internett gir muligheten til å kunne kommunisere med mange maskiner over stort sett hele verden. Men Internett er også et sted som er utsatt for mye angrep og problemer, og for at en bedrift skal kunne gi sine medarbeidere tilgang til sensitiv data utenfor det lokale nettverket så må man være sikker på at man har en sikker tilkobling. Internett med tilhørende protokoller gir ikke denne sikkerheten. VPN gir muligheten til å koble sin PC, som befinner seg utenfor bedriften, slik at det virker som den tilhører det lokale nettverket. Men bedriften må da være sikker på at den som kobler seg til virkelig er en medarbeider og at kommunikasjonen ikke blir kompromitert. Det er her IPSec kommer inn i bildet. Internett LAN for en Bedrift Ansatt med hjemmepc Figur 2.1: Illusterer hvordan VPN oppkobling kan se ut. Konseptet er krafting forenklet, men man ser her at behovet for sikker kommunikasjon er åpenbar, da data trafikken skal passere igjennom Internett. Den ansatte blir her koblet til det lokale nettet i bedriften og danner et VPN.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 8 IPSec, eller Internet Protocol Security Protocol, er en protokoll som etablerer en sikker forbindelse mellom to eller flere parter. Den er utarbeidet av IETF (Internet Engineering Task Force) i 1995, men har siden da gjennomgått mange forandringer og tilpassninger. IPSec skal sørge for autentisering, kryptering og dekryptering og beskytte identitetene til deltakerene, og dette skal gjøres over usikre nett som for eksempel Internett. IPSec er en veldig fleksibel protokoll som gir mye spillerom, spesielt med tanke på typer algoritmer som kan benyttes. IPSec er åpen for de fleste; RSA, Diffie Hellman, AES, DES, trippel DES, Blowfish, RC4 med flere. Det å ha en fleksibel protokoll øker bruksområdene, men det fører også til at den blir svært komplisert. Og det er kjent at jo mer komplekst et system blir, jo mindre sikkert er det. IPSec lider også av en noe tåkete og uklar dokumentasjon, samtidig kan et spesifikt problem som IPSec skal løse ha svært mange løsninger, noe som kan føre til inkompabilitet eller uforusette sikkerhetshull. IPSec protokollen har måtte tåle mye kritikk og har generelt fått et rykte til å være en dårlig gjennomført protokoll med mye problemer. Men allikevel så leverer IPSec til nå den sikreste løsningen på kommunikasjon over usikre nett. Det finnes ingen gode alternativer eller løsninger som kan konkurrere med IPSec. Selve prinsippet til IPSec protokollen er enkel. En sender krever sikker oppkobling til en mottager, partene autentiseres og en sikker kanal opprettes. Når den sikre kanalen er opprettet så skal IPSec videre ta seg av integritetssjekk, kontrollere hvem som sender dataene(autentisering) og konfidensialitet både for data og trafikk analyse. IPSec kombinerer både assymetriske nøkler og symetriske nøkler. For selve autentiseringen og utveksling av «pre shared secret keys» data så benyttes asymmetriske nøkler. Men for selve data utvekslingen/kommunikasjonen så benyttes symmtriske nøkler, gjerne tripple DES eller AES siden de er sikrer og raskere enn asymmetriske nøkler. Autentisering Autentiseringen i IPSec foregår ved at den ene parten sender en «nonce». «Nonce» er en liten datamengde, som er pseudo random. En «nonce» forandrer seg over tid, og helst for hver gang den brukes. Jo mer random denne data mengden er, jo sikrere vil autentiseringssystemet være. For eksempel digesten generert av en hash på en tekst vil kunne gi en god «nonce» så lenge hashen kjøres på forskjellig tekst hver gang. Figur 2.1 viser hvordan to parter kan autentisere seg. Vi har Alice og Bob som forsøker å autentisere hverandre. Har skal vi se at Alice forsøker å autentisere Bob, og for å kunne gjøre dette trengs en Certificate Authority(CA). Dette er en kilde som holder på de offentlige nøkkel i et asymmetrisk nøkkelpar og kobler denne offentlige nøkkelen til en person. Denne CA en kan være en bank, egen forening, statlig eller holdt av firmaet selv. CA kan være global eller lokal. For VPN systemet så er det mest rimelig å anta at en CA er lokalt for bedriften og at den innheloder en offentlig

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 9 nøkkel til alle i bedriften og personlig data om de ansatte, og at de to enhetene er koblet sammen. Denne CA en må også beskyttes godt siden den er ryggraden i autentiseringen. Alice får vite at hun kommuniserer med Bob ved at han presenterer seg som Bob, men Alice vil være helt sikker på at det er Bob som hun kommuniserer med og ikke en som gir seg ut for å være Bob. Alice utforder Bob ved å sende en «nonce» til Bob. Alice har selv en kopi av denne «noncen», og det Bob skal gjøre når han mottar denne «noncen» er å signere den. Bob låser «noncen» med sin private nøkkel og sende den krypterte «noncen» tilbake til Alice. Alice tar så kontakt med CA og henter Bobs offentlige nøkkel og bruker denne nøkkelen til å løse opp den krypterte «noncen». Hvis den dekrypterte krypterte «noncen» stemmer med den orginale «noncen» så må Bob være den han gir seg ut for å være. Så sant ikke noe har blitt forandret på hos CA av en angriper. Bob kan gjøre det samme med Alice for å autentisere henne. I IPSec brukes stortsett RSA eller Diffie Hellman til denne asymmetriske krypteringen som gjøre at man kan autentisere hverandre. Disse algoritmene kan brukes til å sende konfidensiell data uten å opprette en sikker forbindelse, med autentisering først, noe som er svært viktig i IPSec. Alice Generer en nonce nonce Kryptert nonce Bob Krypter nonce med Bobs private nøkkel Hent bob s offentlige nøkkel CA Sammenlign dekryptert nonce og org. nonce Bobs offentlig nøkkel Figur 2.2: Autentisering ved hjelp av assymtrisk nøkkel og CA. Alice autentiserer Bob, Bob må autentisere Alice etterpå med samme prisipp.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 10 Kryptering Selve kryptering av datafragmentene i IPSec kan foregå på to måter, «tunneling mode» eller «transport mode». Det er ikke noe forskjell i algoritmene som brukes i krypteringen, men heller hva som krypteres. «Transport mode», som er lite brukt, krypterer kun payloaden og ikke headeren i datafragmenet. Det vil si at dataene for kommunikasjonen er beskyttet for innsyn, men det gjelder ikke for identiteten til avsender og mottaker. «Transport mode» er raskere, både med hensyn på kryptering og routing, men lar eventuelle angripere se hvem som sender data og hvor dataene ankommer. «Tunneling mode» er den metoden som mest beskyttet og det er den sikreste av de to. Her krypteres hele IP fragmentet, altså både payload og header. Gir også muligheten for å sjekke den totale integriteten på hele IP datagrammet. Et «man in the middle» angrep vil da ikke kunne finne ut hvilken maskin beskjeden egentlig kom fra, eller hvor den skal. Transport IPfragment: Original IP Header AH / ESP TCP DATA Tunnel IPfragment: New AH / ESP IP Header Original IP Header TCP DATA Authentication Header og Encapsulating Security Payload: To headere som er spesifisert av IPSec er Authentication Header(AH) og Encapsulating Security Payload(ESP) AH tar seg ikke av konfidensialitet i hele tatt. Den skal kun sørge for at mottakeren kan få verifisert hvor datafragmentene kommer ifra. Grunnen til at AH er separert ut fra ESP og ikke inneholder noe form for kryptering er for fleksibilitetens skyld. Det finnes steder der bruk av kryptering ikke er lov, men man må fortsatt forsikre seg om at pakkene kommer fra riktig sted. Separeringen har også sørget for denne standarden er veldig utbredt. AH tar seg samtidig av integritets sjekk av datafragmentet og her benyttes enten en Message Authentication Code(MAC), HMAC MD5 eller HMAC SHA 1, eller en digital signatur.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 11 ESP sørger for at data, eller payloaden, i IPfragmenet beskyttes mot innsyn. Payloaden kapsles inn og «paddes». Hvis «transport mode» skal benyttes så kapsles kun dataene inn, hvis «tunnel mode» skal benyttes så kapsles både IPheader og data. Den innkapslede payloaden krypteres med en symmetrisk nøkkel. Hvis AH skal brukes samtidig så legges denne på etter ESP. Dette gjør at mottakeren kan autentisere fragmenetet før selve dekrypteringen gjøres. Algoritmer som kan brukes av ESP er stort sett alle, men de mest vanlige er: Triple DES, AES, DES, CAST, IDEA, triple IDEA, Blowfish and NULL(hvis kryptering ikke ønskes). «Paddingen» gjør også at selve størrelsen på pakken er usynlig for en eventuell angriper. ESP kan også selv gjøre en dataautentisering, men kombineres allikevel ofte med AH for sikker autentisering. IPSec oppkobling Før vi tar en nærmere titt på hvordan IPSec setter opp en sikker linje for kommunikasjon skal vi se på noen sentrale begrep og gi en forklaring av de: SA Security Association er de settene med regler som to parter bestemmer seg for å kommunisere ved hjelp av. Hver kanal vil ha mange forskjellige SA er og hver enkelt av disse vil oppdateres kontinuerlig. SA vil typisk innholde hvilke algoritmer som skal benyttes, levetid på kanalen, destinasjons IP, sikkerhetsprotokoll(ah, ESP). SA styrer altså sikkerhetsreglene for hver part og utifra hva deltakerne i kanalen har tilgjengelige av protokoller, algoritmer og minstekrav til sikkerhet, så finner SA ut hvordan kommunikasjonen må foregå. En bedrift kan for eksempel kreve at alle som skal benytte seg av VPN/IPSec inn til det lokale nettverket skal bruke ESP og AH, AES til kryptering av data og Diffie Hellman eller RSA til autentisering. Da må SA ta hensyn til dette når en sikker kanal skal settes opp. IKE Internet Key Exchange det første leddet i en oppkobling for en sikker tjeneste. IKE er en veldig fleksibel protokoll og støtter flere autentiserings løsninger. IKE er en hybrid, eller en videretutvikling, av ISAKMP/Oakley protokollen. Den tar seg av opprettelse av den sikre forbindelsen ved å sørge at kun autoriserte deltagere mottar sesjonsnøkkelen som skal brukes til kommunikasjonen.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 12 OAKLEY Oakley er en videreutvikling av Diffie Hellman og er tilpasset til IPSec. Den tar seg av selve nøkkelutvekslingen i IPSec, og den kan enten distribuere krypterte nøkler, eller generere nye nøkler utifra gamle nøkler. Oakley benytter seg av «coockies» for å hindre enkle DoS(Denial of Service) angrep. Hovedprinsippet av Oakley er at to parter kan kommunisere konfidesielt, dele informasjon nøkkel, krypterings algoritmer og hashfunksjoner med mer, helt til partene er enig i hvordan kommunikasjonen skal foregå. ISAKMP Er rammeverket for autentisering og nøkkel behandling. Tar ikke for seg protokoll for nøkkel utveksling, det tar f.eks IKE seg av. ISKAMP er generisk og kombinert med Oakley og SKEME danner dette IKE protokollen. Fordelen med ISAKMP er at den er veldig fleksibel og lar partene kommunisere med hverandre til ønsket sikkerhetsregler er lagt frem. Deretter benyttes disse reglene til videre kommunikasjon og dataoverføring. DOI Domain of Interpretation. Denne protokollen setter et grensesnitt for de parameterne som sendes under forhandligen av kommunikasjonsreglene. DOI brukes for å tolke ISAKMP meldingene. Figur 2.3: Viser en layout av protokollene tilhørende i IPSec

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 13 Figur 2.4 Overordnet design av IPSec tunnel over VPN 1 Host A initierer oppkobling til Host B, og en IPSec tunnel kreves. Her settes opp et sett med regler, gjerne ved hjelp av permit og deny tabeller. Disse reglene bestemmer hvilken trafikk som skal krypteres(permit) og hva som ikke skal krypteres(deny) og disse tabellene kan integreres i router. Man kan også velge manuelt om datatrafikken skal sikres av IPSec. Dette vil, på lik linje med en access liste, føre til neste steg i prosessen. Autentisering av deltakerne. 2 Router A og B setter opp en IKE fase 1 sesjon(ike SA). Etter at man har gitt signal om at en sikker kanal må initieres, så skal deltakerne autentiseres og en sikker kanal for nøkkelutveksling settes opp. I denne fasen skal IPSec gjøre følgende ting: 1. IPSec skal autentisere deltakerne i den sikre kommunikasjonen og sørge for at identiteten er beskyttet for personer utenfor VPN. 2. IPSec skal sørge for at deltakerne bruker samme IKE SA policy for å beskytte nøkkel utvekslingen 3. I dette steget er det vanlig å utføre en nøkkelutveksling ved hjelp av Diffe Hellman eller RSA. Deltakerne, og kun de, skal nå ha en matchende delt nøkkel som er hemmelig 4. Til sist skal IPSec sette opp en sikker tunnel for IKE fase 2 IKE fase 1 kan foregå på to måter, main mode og aggressive mode:

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 14 Main mode Dette er en tre stegs løsning der begge parter må fullføre begge stegene. First exchange: Først settes opp en SA for IKE kommunikasjonen. De forskjellige algoritmer og hasher bestemmes mellom partene. Når de har blitt enige om hvilket «språk» som skal benyttes så skal partene autentiseres. Second exchange: RSA eller Diffie Hellman brukes for å sende data som genererer «shared secret» keys og for å sende «nonces». «Nonces» sendes til motparten som signerer denne. Dette gjøres for å bekrefte identiteten til den andre parten. Third exchange: Til slutt så verifiseres motpartens identitet. Her benytter IPSec seg av motpartens krypterte IP adresse. Begge partene skal fullføre disse tre stegene hver for seg og da skal de ha en matchende IKE SA som skal sørge for en sikker kanal med de samme kriteriene for ISAKMP. IKE SA spesifiserer hva slags autentiseringsmetode som skal benyttes(rsa eller Diffe Hellman), kryptering og hash algoritmer, eventuelt hvilken Diffie Hellman gruppe som skal benyttes, levetiden på den sikre kanalen(måles i enten sekunder eller kilobytes) og en shared key som kun er kjent for partene i den sikre kanalen. Aggresive mode Fortsatt så må begge partene sende data til hverandre for å åpne en sikker kanal, men nå har man ett trinn i stedet for tre. Dette gjør at færre pakker sendes og kommunikasjonen kan etableres raskere. Etter at det er klart at en IPSec kanal skal opprettes, så pakkes de nødvendige dataene(offentlige nøkkel, «nonce» som mottaker skal signere og en identitetspakke) i en blokk og sendes. Mottaker sender så tilbake den nødvendige informasjonen for å fullføre IKE SA reglene, og forhåpentligvis blir disse reglene godtatt. Partene autentiseres og en sikker kanal blir opprettet, men den blir opprettet etter at informasjonen er sendt. Ved å benytte seg av aggressive mode vil oppkoblingen gå raskere, men det er på bekostning av sikkerhet. I main mode så opprettes reglene, kanalen gjøres sikker og de nødvendige dataene for videre verifiserings sendes. I «aggressive mode» sendes alt samtidig før en sikker kanal for utvekslingen er satt opp. Det er lettere å tappe signalet og finne ut hvem som bestemte den nye SA.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 15 3 Router A og B setter opp en IKE fase 2 session(ipsec SA): I denne fasen skal partene sette opp en IPSec SA slik at en IPSec tunnel kan dannes. Hovedoppgavene i denne fasen er firdelt: 1. Partene skal forhandle frem IPSec SA parametere, og dette gjøres over den sikre kanalen som ble opprettet i IKE fase 2(IKE SA). 2. Ut i fra de forhandlede parameterne mellom partene skal det opprettes en IPSec SA. 3. For økt sikkerhet skal den sikre kanalen (IPSec SA) med jevne perioder reforhandles. 4. I tillegg kan det også med fordel utføres en ekstra autorisasjonssjekk med RSA eller Diffie Hellman. IKE fase 2 kalles «quick mode» og denne kommer rett etter at IKE har etablert en sikker tunnel i fase 1. I fase 1 så satte man opp en sikker kanal for å kunne dele nøkler for videre data overføring. I IKE fase 2 så har man lagt grunnlaget for en sikker kanal for data kommunikasjonen. Quick mode holder orden på regler for kommunikasjon over IPSec, og bruker nøkkelmaterialet som ble delt ut i IKE fase 1 for bruk i sikkerhets algoritmene i IPSec og for å beskytte seg mot «replay attacks» vil utveksling av nøkkel materiale skje ved jevne perioder. Dette gjøres ved å sende «nonces» som brukes i generering av nye symmetriske sessjons nøkler(pre shared secret keys). Reforhandliger av SA og distribusjon av symmetriske nøkler (preshared nøkkel materiale) skjer når IPSec SA har send en viss mengde data eller har vart over en gitt tid. «Perfect Forward Security(PFS)» øker ytterligere sikkerheten ved å sikre nøklene og senere bruk av disse. Hvis noen skulle klare å finne ut av en nøkkel, så sørger PFS at angriperen ikke tilgang på de andre nøklene. Ved å sjekke entropien å sørge for at den er så stor som mulig så gjør PFS det vanskeligere for angriperen å kompromitere hele systemet. Hvis for eksempel en angriper hadde fått tak i IKE SA nøkkelen, og sniffet all IPSec beskyttet data og brukt IKE SA nøkkelen til å knekke hele IPSec SA konfigurasjonen. Når PFS er i bruk så vil angriperen måtte knekke alle nøklene hver for seg. Men PFS er ganske CPU tung, spesielt med tanke på at dette er en kommunikasjonskanal som allerede legger beslag på regnekraft og bruker ønsker minst mulig forsinkelse i sin forbindelse.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 16 4 IPSec tunnel mellom Host A og B settes opp. Når IKE fase 2 er ferdig og quickmode har etablert en IPSec SA, så genereres en tunnel. Dette er da en sikker kanal mellom partene der hvor dataene krypteres og dekrypteres i henhold til det som er spesifisert i IPSec SA. Identiteten til partene kan også maskeres. Denne sikre tunnelen har en levetid som begrenser seg til en gitt tid eller til en viss datamengde, og når tunnelenes levetid er ute så må tunnelen reinitieres. Dette gjøres ved å gå igjennom quickmode på ny. 5 Oppkoblingen termineres Det er tre måter oppkoblingen kan termineres på. Hvis tunnelen har en forhåndsinnstillt levetid i antall sekunder så termineres kanalen når tiden er ute. Tunnelen kan også har en levetid på et antall bytes som sendes, og når en den fastsatte mengde data er sendt så vil tunnelen termineres. Tunnelen kan også termineres av brukeren manuelt. Når en tunnel er terminert, og videre oppkobling ønskes, må den settes opp igjen ved å gå tilbake til IKE fase 2, eller om nødvendig IKE fase 1. Alle sessjonsnøkler termineres med tunnelen og hvis reforhandligene om en ny tunnel blir godtatt av begge parter så vil nye nøkler genereres og en ny SA opprettes (Denne SA en kan inneholde de samme opplysningene og reglene, men det er fortsatt ikke den samme). Hvis IPSec policyen tillater det så kan en ny SA opprettes før en gammel SA dør ut, slik at kommuniksjonen ikke blir brutt.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 17 3 Nøkkeldistribusjon Et problem i de forskjellige kryptoscenarioene er distribusjon av nøkler. Dette kan gjøres på mange forskjellige måter. En av disse er å gå manuelt mellom de to partene som trenger nøkler, eller sende disse nøklene i posten. Dette kan bli litt tungvindt i lengden, derfor har man utviklet metoder for å gjøre dette vha. å sende nøklene over samme nettverk som dataene senere skal sendes på. De to hovedmåtene for kryptering er asymmetrisk og symmetrisk. I et asymmetrisk kryptosystem har hver part sin private nøkkel, og en offentlig nøkkel som er slik at den kan utveksles over et usikkert nettverk uten fare for at en angriper kan finne den tilhørende private nøkkelen eller klarteksten. I et symmetrisk kryptosystem må nøklene holdes hemmelige for andre enn de involverte partene og kan derfor ikke utveksles åpenlyst over en offentlig kanal. Symmetrisk kryptering er forresten ca 1000 ganger så rask som asymmetrisk i følge Cisco[1]. Asymmetrisk kryptering Asymmetrisk kryptering benytter seg av «smekkdør» funksjon, dvs. en funksjon som det er enkelt å kalkulere i den ene retningen men omtrent umulig å løse i den andre retningen. Forskjellen på «smekkdør» og «enveis» funksjon er at «smekkdør» funksjonen kan reverseres vha. en nøkkel. Poenget med den er sikker nøkkelutveksling over en usikker forbindelse mellom to parter uten at disse kjenner til noen hemmeligheter fra før. Måten dette gjøres på er at hver av partene som skal kommunisere (Alice og Bob) produserer sin egen private og offentlige nøkkel. Hvis Alice skal sende noe til Bob bruker hun den offentlige nøkkelen hans for å kryptere den hemmelige informasjonen. Den offentlige nøkkelen er laget slik at kun den private nøkkelen kan «låse opp» data kryptert med denne, og motsatt. Asymmetrisk kryptering løser problemet med overføring av hemmelige nøkler, men en må være oppmerksom på at den private nøkkelen trenger beskyttelse der den ligger lagret. Da asymmetriske kryptosystemer regnes for å være trege brukes de ofte i kombinasjon med symmetrisk kryptering. Eksempler på asymmetriske algoritmer er RSA, El Gamal, Diffie Hellman og Rabin. Diffie Hellmann (DH) Kjent som den første asymmetrisk algoritme for nøkkelutveksling, basert på diskrè logaritme problemet. Algoritmen ble «oppfunnet» i 1976 av Whitfield Diffie og Martin Hellman basert på konseptet med public key distribution system som Ralph Merkle hadde jobbet med. Egentlig hadde en forsker som het Malcolm Williamson ved Britisk

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 18 etterretningstjeneste funnet på algoritmen noen år tidligere, men siden dette var hemmelig så hadde det ingen innvirkning på forskningen til DH. (Om en skal gå helt i dybden var det John Gill som foreslo at bruk av diskré logaritmer kunne være en god ide.) DH er ikke konstruert for kryptering, kun nøkkelutveksling. RSA Litt mer avansert utgave enn DH, som i tillegg til nøkkelgenerering og distribusjon også tilbyr digital signering av dokumenter. Baserer seg på problemet med faktorisering av store primtall. Ble utviklet i 1977 av Rivest, Shamir og Adelman, men publisert først i 1978. RSA er en blokkchiffer algoritme og er den algoritmen som ansees for å være den beste asymmetriske algoritmen i dag. RSA kan benyttes til autentisering ved opprettelse av en tunnel ved at partene har en RSA nøkkel liggende beskytett på f.eks et smartkort. Symmetrisk kryptering Symmetriske kryptosystemer bruker den samme nøkkelen og algoritmen for kryptering og dekryptering, derfor er hemmelighold av nøkkelen svært viktig. Nøklene hentes på en tilfeldig måte fra et «sub sett» med alle mulige nøkler. Nå kan en påstå at en ikke får til tilfeldig utvelgelse på en deterministisk maskin, men på tross av dette finnes det i dag gode løsninger som sikrer en viss tilfeldighet allikevel. Fordelen med symmetrisk kryptering er hastigheten. Ulemper er nøkkelutveksling og hemmelighold av denne. Eksempler på symmetriske kryptoalgoritmer er DES, 3DES, AES, RC 4, RC 5 og IDEA. AES AES ble påbegynt i 1997, av NIST (National Institute of Standards and Technology). AES standarden ble utviklet av folk rundt om i hele verden. Det var en åpen prosess rundt det å finne ut hva som måtte/burde være med i standarden. Det de kom frem til var at AES burde ha blokklengde på minimum 128bits, og nøkkellengder på 128, 192 og 256 bits. Den skulle ikke benytte «Feistel struktur», alle bits i en runde skal krypteres i den runden. Bygger på abstrakt algebra og nummerteori (Galois kropper). Folk rundtom i verden satte seg da ned for å finne en algoritme som oppfylte disse kravene.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 19 I 1998 hadde NIST mottatt 15 kandidater som støttet standarden. (En av de fem beste algoritmene «Serpent», er utviklet av en dansk/norsk herre ved navn Knudsen m.fl. Denne ble ikke valgt fordi den var for treg og vanskelig å implementere. ) I oktober 2000 valgte NIST Rijndael som den beste kandidaten til AES. I oktober 2001 blir AES vedtatt som en standard av FIPS (Federal Information Processing Standard). Rijndael Rijndael ble utviklet av Daemen og Rijmen. Den kan benytte blokklengder på 128/192/256 bits og nøkkellengder på 128/192/256 bits. Det er valgfritt hvilken lengde som skal benyttes, noe som gjør det vanskelig for en inntrenger fordi han da må prøve alle mulige nøkler innenfor de tre lengdeintervallene. Antall runder som skal benyttes er 10/12/14 alt ettersom hvilken nøkkellengde som benyttes. Rijndael er et substitusjon permutasjon nettverk. Den bruker lite minne, er lett å implementere og er rask både i software og hardware. Strengt tatt er Rijndael en utvidet AES, siden AES har fast blokkstørrelse på 128bits, mens Rijndael kan spesifiseres med en hvilken som helst blokkstørrelse som er et multiplum av 32bits (min 128bits og maks 256bits). I praksis så benyttes AES og Rijndael om hverandre. Etter som AES er blitt en standard, er det meningen at den skal erstatte dagen DES standard. Det vil antagelig fortsatt benyttes en del 3DES, men DES er ikke å anbefale lenger da det ved bruk av en «DES Cracker» er rimelig raskt å finne nøkkelen. In the late 1990s, specialized «DES Cracker» machines were built that could recover a DES key after a few hours. In other words, by trying possible key values, the hardware could determine which key was used to encrypt a message.assuming that one could build a machine that could recover a DES key in a second (i.e., try 2 55 keys per second), then it would take that machine approximately 149 thousand billion (149 trillion) years to crack a 128 bit AES key. To put that into perspective, the universe is believed to be less than 20 billion years old. [2]

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 20 Hvordan fungerer Rijndael: (128bit blokklengde og nøkkellengde). Figur 4.1 Oversikt over gangen i Rijndael algoritmen AES benytter 4x4 matriser med bytes, kalt «states» (det finnes versjoner av Rijndael som har større blokkstørrelse og dermed større matrise). Ved kryptering, består hver runde av fire etapper (bortsett fra den siste, hvor MixColumns ikke er med): 1. SubBytes 2. ShiftRows 3. MixColumn 4. AddRoundKey

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 21 1. SubBytes en ulineær substitusjon hvor hver byte blir erstattet med en annen byte bestemt av en tabell (s box). Figur 4.2 SubByte operasjon. Operasjonen gjentas for hver byte i hele matrisen. 2. ShiftRows hver rad i matrisen blir forskjøvet syklisk et bestemt antall ganger. Figur 4.3. Rotasjon av kolonner. 3. MixColumns kombinerer de fire bytene i hver kolonne med en lineær transformasjon. Figur 4.4. Matrisemultiplikasjon på hver kolonne.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 22 4. AddRoundKey hver byte i klartekstkolonnen XOR es med hver byte i RoundKey kolonnen. Dette gjøres kolonne for kolonne. (Pk1 + RNk1, Pk2 + RNk2), hvor P er klartekstblokka og RN er rundenøkkelen. Rundenøkkelen endres hver runde av en «key scheduler». Figur 4.5 XORing av rundenøkkel med klartekstblokka. Alle tegninger i denne forklaringen er hentet fra [3]. For en fullstendig spesifikkasjon av AES se [4]. Sikkerhet i Rijndael Det er til nå ikke blitt registrert noe vellykket angrep på AES. NSA (The National Security Agency) som evaluerte de 5 beste algoritmene, påstod at samtlige var bra nok til sikring av uklassifisert data hos «US Government». AES blir nå antagelig brukt av «US Government» til å sikre «classified» informasjon: «The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths. The implementation of AES in products intended to protect national security systems and/or information must be reviewed and certified by NSA prior to their acquisition and use.»[5] Dette er faktisk første gang offentligheten har fått tilgang til en algoritme som NSA har godkjent for TOP SECRET nivå. Angrep mot blokkchiffer: Den vanligste måten å angripe et blokkchiffer på er ved å prøve forskjellige angrep på versjoner av chifferet med redusert antall runder. AES har 10 runder for 128bits nøkkel, 12 runder for 192bits nøkkel og 14 runder for 256bits nøkkel. Per 2004 er de mest kjente angrepene gjort på 7 runder(128bits nøkkel), 8 runder(192bits nøkkel) og 9 runder(256bits nøkkel). Det at noen har kommet så nærme å knekke algoritmen, bekymrer mange kryptologer. De mener at marginen mellom de beste angrepene og det antall runder algoritmen kjører er for liten. Hvis noen klarer å forbedre angrepene, så er det ikke så «mye» sikkerhet igjen. Et angrep sies å «knekke» et blokkchiffer hvis det er mer effektivt enn utfyllende nøkkelsøk, altså hvis angrepet er

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 23 mulig å utføre med færre operasjoner enn det som trengs for å lete igjennom alle mulige nøkler. En annen ting som er bekymringsverdig er den matematiske strukturen på AES. Til forskjell fra de fleste andre blokkchiffer har AES en ganske «snedig» matematisk beskrivelse. Spesifikasjonen til Rijndael er faktisk matematisk allerede i utgangspunktet. Dette har foreløpig ikke resultert i noen angrep, men enkelte forskere er engstelige for at fremtidige angrep kan finne en måte å utnytte denne strukturen på. Alle blokkchiffre kan uttrykkes ved hjelp av likningssystemer. Det som er poenget er hvor komplisert likningssystemet blir. I [6] kan man se at Rijndael kan beskrives av en eneste likning. Denne likningen har derimot over 20 50 ledd og er derfor i praksis umulig å løse. Det er også foreslått å studere Rijndael ved hjelp av likningssystem over GF(2) eller GF(28). I 2002 ble et teoretisk angrep kalt «XSL attack», offentliggjort av Nicolas Courtois og Josef Pieprzyk, teorien påviste en potensiell svakhet i AES. Angrepet i seg selv vil ikke praktisk la seg gjøre med dagens teknologi pga. av uoverkommelig høy «work factor». Det skal visstnok være gjort store forbedringer på dette feltet, så angrepet vil kanskje la seg gjennomføre en gang i fremtiden (hvis matematikken i angrepet stemmer). Men på det nåværende tidspunkt er dette angrepet bare i den spekulative fasen, da det er lite sannsynlig at noen er i stand til å utføre angrepet.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 24 Hybride løsninger Som en kan se har hver av de tradisjonelle løsningene sine styrker og svakheter når det kommer til nøkkeldistribusjon. I symmetrisk algoritmer er det problematisk å distribuere nøklene men de er raske til å kryptere data. Asymmetriske algoritmer løser distribusjonsproblemet, men er trege til å kryptere data. For asymmetrisk finnes løsninger for å omgå slike angrep, et eksempel er signering av nøkkel fra sender med hash eller PKI. Derfor kan en regne asymmetrisk for å være en noenlunde sikker måte å distribuere nøkler på, i alle fall bedre enn symmetrisk (hvor det kreves en sikker kanal for overføring av nøkkel). Som en «konsekvens» av dette kan en tenke seg en løsning hvor en kombinerer det beste fra disse to måtene. Benytter da asymmetriske algoritmer til å distribuere symmetriske nøkkler. Nøkkelutveksling med asymmetrisk løsning. Asymmetrisk har vist sin styrke ved at nøkler kan utveksles over en offentlig kanal. Fremover kommer også løsninger basert på kvantefysiske prinsipper som er lovende med tanke på avlytting og endring av overført melding. Kryptering med symmetrisk løsning som gir ønsket hastighet for applikasjoner som krever høy overføringshastighet.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 25 Nøkkeldistribusjon vha. kvantekryptografi (Quantum cryptography) Noe av det mer spennende som vil komme fremover er kvantekryptografi. Foreløpig kan dette kun brukes til å distribuere nøkler men det foregår også forskning på muligheten for å bruke dette fullt ut. Kvantekryptografi ble først foreslått på 1970 tallet av Stephen Wiesner, men ble ikke publisert før i 1983 av Sigact News. Da var Bennet og Brassard klare med sin egen protokoll kalt BB84 som er den første kvantenøkkelutvekslingsprotokollen som er laget. Denne ble lansert i 1984 og er basert på ideene til Wiesner. Nøkkeldistribusjon i kvantekryptografi bygger på to hovedprinsipper. Først selve hovedprinsippet i kvantemekanikk. Hvert forsøk på måling av en tilstand i et kvantesystem vil endre tilstanden til systemet dersom ikke systemet ikke er i en slik tilstand at det er kompatibelt med målingen.(noe som er meget usannsynlig.) Når Alice skal sende en melding til Bob stiller hun kvantesystemet i en tilstand som representerer meldingen som skal sendes. Det finnes flere måter å overføre dette systemet på, en måte bruker enkeltfotoner over en optisk kabel. Dette betyr at hvis Eve skal finne ut tilstanden i systemet så må hun utføre målinger, og disse målingene vil endre tilstanden til systemet. Målingene vil heller ikke kunne si noe om tilstanden til systemet Prinsipp: Ved bruk av enkeltfotoner over en fiberkabel vil enhver avlytting fra Eve forårsake en endring av overføringen. Å forklare et kvantesystem er ikke enkelt, men det dreier seg mye om tilstander (polarisasjon) på enkeltpartikler av lys, kalt fotoner. Et kvantesystem er enkelt forklart fire forskjellige tilstander; horisontal, vertikal, 45 grader og 135 grader (kan benevnes ved «/» og «\» ). Når Alice sender fotoner over til Bob vil han kunne måle den med et filter med to tilstander, + eller X. + vil kunne ta vertikal eller horisontal polarisasjon mens X tar / 45 eller \ 135 graders polarisasjon. Når Bob har målt disse polarisasjonene kan han sende hvilke innstilling filteret hadde ved måling til Alice og hun kan da si når han fikk et riktig treff. Dette kan gjøres på en tradisjonell kanal. På grunnlag av riktige treff blir nøkkelen bestemt hos Alice og Bob. En kan nevne at pga. diverse usikkerheter og matematiske formler vil ca. 50 % av fotonoverføringene bli målt feil slik at nøkkelen blir halvparten av overføringen.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 26 Nå har jo også kvantenøkkelutveksling også sine problemer, for eksempel så er den utsatt for «man in the middle» angrep. Bortsett fra at dette er usedvanlig vanskelig å gjennomføre vil dette «alltid» gjelde for et nøkkelutvekslingssystem. Det gjelder i hverdagen også, for hvordan kan du stole på at en du gir nøkkelen til hjemmet ditt er den du tror det er? Som regel kjenner du folk, men du har ikke annet bevis enn at de ser ut som den du kjenner. (Litt overdrevet og snevert, du burde kjenne mora di). Andre småproblemer er at: Det er foreløpig vanskelig å generere enkeltfotoner, problemet er da at om Alice kommer til å sende to like fotoner samtidig kan Eve bruke en splitter og lese det ene fotonet uten at dette oppdages. Du trenger en bra generator av tilfeldige tall for å velge hvilke polarisasjoner som skal brukes. Siden fotonene endres når de leses av så får en et problem med forsterkning av signalet. Overføring av hemmelige bit er litt treg (sett fra en praktisk anvendelse), en kan foreløpig ikke nå GHz hastigheter som ved annen kryptert overføring. Da må en over på hybrid kryptering, dvs. nøkkeldistribusjon med kvantemetoden og kryptering med for eksempel AES.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 27 Eksempel på kommersiell løsning QUANTUM KEY DISTRIBUTION (QKD) fra [7] Key distribution is a central problem in cryptography. Currently, public key cryptography is commonly used to solve it. However, these algorithms are vulnerable to increasing computer power. In addition, their security has never been formally proven. Quantum cryptography exploits a fundamental principle of quantum physics observation causes perturbation to distribute cryptographic keys with absolute security. id Quantique is introducing the first quantum key distribution system, which exchanges keys over standard optical fibers. Figur 1 Kvantenøkkeldistribusjon i praksis Main features Security guaranteed by quantum physics Encryption with AES or One Time Pad Transmission distance: up to 100 km Automated key management High transmission speed Figur 2 Innmat i boksene For forklaring, sjekk http://www.idquantique.com/files/njp-2002.pdf

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 28 Til ettertanke ved nøkkeldistribusjon Når en skal distribuere nøkler er det enkelte ting en bør huske på. Hvordan skal nøkler utveksles? Automatisk eller manuelt, epost eller telefon? Uansett bør det foreligge en policy som sier noe om dette. Hvor mange nøkler skal brukes, en per bruker, per gruppe? En per tilkobling eller ny for hver kommunikasjon? En bør alltid sørge for å ha tilgjengelig flere nøkler enn en har tenkt å benytte siden brukere kan flyttes rundt i en organisasjon med forskjellige rettigheter. Når skal nøkler endres, eventuellt hvor ofte? Hvis nøkler deles av flere brukere burde de gamle virke i en overgangsperiode ved utskifting? Hva om en person slutter i selskapet, skal nøklene fjernes fra hans datamaskin? Om flere brukere har samme nøkkel bør denne uansett skiftes ut. I tilfeller der ikke systemet tar seg av nøkkelutvekslingen, hvor bør disse lagres? I et smartkort? Som et passord en bruker må huske for å få tilgang til nøkkeldistribusjonsserveren?

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 29 4 Konklusjon Dette prosjektet har vært meget interessant fordi vi her har sett hvordan kryptografiske algoritmer kan kombineres og benyttes for å sikre data. Prosjektet har hjulpet en hel del på forståelsen av kryptografi i praksis. Det vi kan konkludere med er at dagens kryptoløsninger er basert på en matematisk tankegang som mener at enkelte problemer er vanskelige å løse. Vanskelig ja, men uløselig nei. Utviklingen mhp datakraft er i dag enorm og en eller annen gang kommer dagens algoritmer til å knekkes enten «brute force» eller vha snedige algoritmer. Det hele greia dreier seg om er å ligge i forkant av angriperne. Med tanke på de algoritmene som i dag benyttes mest i VPN (hovedsakelig DES og 3DES), vil vi anbefale VPN brukere å gå over til AES, fordi den så langt har vist seg å være sterkere enn de som benyttes nå. IPSec over VPN gir en tilstrekkelig sikkerhet, men er en protokoll som fortsatt bør gjennomgå en del forbedringer. Så lenge sikre algoritmer benyttes og de bakenforliggende systemer er sikre, så er IPSec også ganske sikker. Mye av problemet med IPSec er å konfiguerere systemet på en sikker måte, da IPSec er meget komplisert og tilbyr flere løsninger på samme problemstilling. Nøkkeldistribusjon kan gjøres enklere enn å benytte asymmetriske nøkler og CA, men sikkerheten blir lavere og autentiseringen blir svakere. Det er lett å føle seg litt paranoid når en tilegner seg kunnskap om informasjonssikkerhet, verden er ikke så trygg som en har oppfatning av. Men ved å lære kan en i alle fall begrense farene.

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 30 5 Linker og referanser Alle referanser og linker er funnet I tidsrommet Oktober November 2004 Elektronisk leksikon http://en.wikipedia.org/wiki/vpn VPN og IPSEC http://www.onlamp.com/lpt/a/3009 Questions and answers ipsec vpn http://searchsecurity.techtarget.com/qna/0,289202,sid14_gci812983,00.html Definisjoner + public vs secret key algoritmer http://www.cse.iitk.ac.in/users/braman/courses/cs625-fall2003/lec-notes/lec-notes25-2.html VPN Security Can It Be Trusted? http://www.rfgonline.com/subsforum/archive/daily/110899/111099nt.html Algorithm Alphabet Soup http://infosecuritymag.techtarget.com/2003/jan/algorithm.shtml Pensumside for 03hminf http://www.hig.no/imt/index.php?id=106 Definisjoner kort og godt http://searchsecurity.techtarget.com/sdefinition/0,,sid14_gci214037,00.html Hvordan fungerer AES, inkl eksempler http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf Norsk rapport om sikkerhet i AES www.telenor.no/fou/publisering/notater/n_31_2002.pdf Asymmetrisk kryptering i Perl http://www.perl.com/pub/a/2001/09/26/crypto1.html Planlegging av nøkkeldistribusjon http://www.clavister.com/manuals/ver8.4x/manual/vpn/planning_a_vpn.htm#key_distribution Prinsippet til IPSec og IKE http://www.ciscopress.com/articles/article.asp?p=25474&seqnum=7 IKE protokollen http://www.research.ibm.com/journal/sj/403/cheng.html Overblikk over IPSec http://www.eurescom.de/~public-web-deliverables/p1100-series/p1113/d1/41_ipsec_intro.html Sammenligning av IPSec og PPTP http://www.intranetjournal.com/foundation/tunneling.shtml IPSec FAQ http://www.zyxel.com/support/supportnote/zywall10/faq/vpn_faq.htm#6. What is IPSec? Introduksjon til IPSec http://www.cisco.com/warp/public/105/ipsecpart1.html

Autentiseringsløsninger i VPN og nøkkeldistribusjon Page 31 Teknisk forklaring av IPSec http://www.hsc.fr/ressources/articles/ipsec-tech/index.html.en Kvante kryptografi The Relevance of Quantum Cryptography in Modern Cryptographic Systems Christoph Guenther, GSEC Practical Requirements (v1.4b) Desember 2003, SANS institute Referanser [1] Safe VPN http://www.cisco.com/warp/public/cc/so/cuso/epso/sqfr/safev_wp.htm [2] SPM og svar AES http://csrc.nist.gov/cryptotoolkit/aes/aesfact.html [3] Animasjon av gangen i AES http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndael_anim_swf.zip [4] Spesifikasjon av AES http://csrc.nist.gov/cryptotoolkit/aes/rijndael/rijndael-ammended.pdf [5] Fakta om sikkerhet i AES http://www.nstissc.gov/assets/pdf/fact%20sheet.pdf [6] Matematisk formel for knekking av Rijndael http://www.macfergus.com/pub/rdalgeq.html [7] Skryte side for foton kvante ting http://www.idquantique.com/qrng.html