Dagens tekst er hentet fra kapittel 14 i Cryptography and Network Security, og handler om hvordan man håndterer og distribuerer kryptonøkler. Dette er et område som er mer komplekst enn man skulle tro; det er utfordringer rundt kryptografien som skal brukes, protokoller, og administrasjon.

Symmetriske systemer krever at partene som er involvert deler en symmetrisk nøkkel, mens offentlig-nøkkel-varianter krever at partene er i stand til å få tak i gyldige offentlige nøkler. Ingen av delene er trivielt!

Nøkkeldistribusjonsteknikk

Med dette refererer vi til måten å levere en nøkkel til to parter som ønsker å utveksle data uten å la andre se nøkkelen. Dette er jo forutsetningen for at symmetrisk kryptering skal fungere. Hyppige nøkkelendringer er ønskelige for å begrense mengden av data som kompromitteres hvis en angriper skulle få tilgang til en enkelt nøkkel.

Symmetrisk nøkkeldistribusjon

Gitt partene Alice og Bob kan vi få til nøkkeldistribusjon på flere måter:

Alice kan velge en nøkkel og levere den fysisk til Bob
En tredjepart (Charlie) kan velge nøkkelen og levere den fysisk til Alice og Bob
Hvis Alice og Bob nylig har kommunisert med en nøkkel, kan en av dem velge en ny nøkkel og sende den til den andre kryptert med den gamle nøkkelen.
Hvis Alice og Bob har en kryptert forbindelse til Charlie, kan han velge en nøkkel og sende den kryptert til Alice og Bob

Nøkkelhierarki

Hvis alle skulle ha en delt nøkkel med alle tenkelige kommunikasjonspartnere, ville antallet nøkler øke eksponensielt. I de fleste tilfeller har vi et hierarki av nøkler, hvor vi nederst har en midlertidig sesjonsnøkkel som brukes for å kryptere data mellom brukere; denne brukes for en logisk sesjon, og forkastes når sesjonen er slutt. På neste nivå har man en masternøkkel som man kan bruke til å kryptere sesjonsnøkler med. Ofte vil denne nøkkelen være delt mellom brukeren og et nøkkeldistribusjonssenter, men også andre konfigurasjoner er mulige. Det er også mulig å ha flere nivåer i hierarkiet.

Hierarkisk nøkkelkontroll

For kommunikasjon mellom parter inne samme lokale domene, vil det lokale nøkkeldistribusjonssenteret (KDC) være ansvarlig for nøkkeldistribusjon. Hvis to parter i forskjellige domener trenger en delt nøkkel, så kan de respektive lokale KDCene kommunisere via en global KDC. Det hierarkiske konseptet kan utvides til tre eller flere nivåer.

Denne løsningen minimerer innsatsen som kreves for distribusjon av masternøkler, ettersom de fleste masternøkler er de som deles mellom en lokal KDC og dens lokale brukere/enheter. Dette begrenser også påvirkningen av en feilet eller kompromittert KDC til det lokale området.

Nøkkeldistribusjonsaspekter

Vi trenger hierarkier av KDCer for store nettverk, men de må stole på hverandre. Man bør begrense levetiden på sesjonsnøkler for bedre sikkerhet. Det er også praktisk med automatisk nøkkeldistribusjon på vegne av brukerne, men vi er da nødt til å stole på systemet. Et alternativ er å bruke desentralisert nøkkeldistribusjon. Det er også mulig å implementere mekanismer som begrenser hvordan nøkler kan brukes.

Levetid for sesjonsnøkler

Den som er ansvarlig for sikkerheten må veie for og imot: Jo oftere sesjonsnøkler byttes, jo sikrere er de; men distribusjon av sesjonsnøkler vil forsinke starten på enhver interaksjon, og vil være en belastning på nettverkskapasiteten. For forbindelsesorienterte protokoller vil et alternativ være å bruke samme sesjonsnøkkel så lenge forbindelsen er åpen, og utveksle en ny sesjonsnøkkel for hver nye sesjon. For en forbindelsesløs protokoll er det ingen eksplisitt opprettelse av forbindelse eller terminering, og det er følgelig ikke selvsagt hvor ofte man bør bytte sesjonsnøkkel.

Brukskontroll av nøkler

Konseptet med nøkkelhierarki og bruk av automatisert nøkkeldistribusjon reduserer dramatisk antallet nøkler som må håndteres og distribueres manuelt. Det kan være ønskelig å utøve kontroll over måten disse automatisk distribuerte nøklene brukes. For eksempel, i tillegg til å skille mellom sesjonsnøkler og masternøkler, kan vi ønske å definere forskjellige typer sesjonsnøkler basert på hva de skal brukes til.

Nøkkelkontroll

Hvis vi assosierer en merkelapp med hver nøkkel, kan vi styre forskjellig bruk. Et (litt foreldet) eksempel kan være å bruke de 8 ekstra bitene i en 64-bit nøkkelblokk (DES bruker som kjent kun 56 bit nøkkel). Disse blir ofte brukt for paritetssjekk av nøkkelen, men ingenting stopper oss fra å bruke dem til noe annet. Ettersom denne merkelappen er innebygd i nøkkelen så å si, blir den kryptert sammen med nøkkelen, og følgelig beskyttet. Ulemper med akkurat dette eksempelet omfatter at merkelappen er begrenset til 8 bit, noe som begrenser fleksibilitet og funksjonalitet; samt at ettersom merkelappen overføres kryptert, kan den bare brukes på det tidspunktet nøkkelen dekrypteres, noe som begrenser måtene bruken kan kontrolleres på.

En mer fleksibel måte er å bruke en nøkkelvektor som angir bruk etter nærmere regler. Denne XORer vi med en masternøkkel, og resultatet brukes til å kryptere sesjonsnøkkelen som skal oversendes. Nøkkelvektoren kan sendes ved siden av i klartekst; mottakeren må studere nøkkelvektoren (og presumtivt adlyde det den sier) og kombinere den med master før sesjonsnøkkel kan dekrypteres.

Symmetrisk distribusjon med offentlige nøkler

Som kjent er offentlig-nøkkel-kryptografi lite effektivt med hensyn på tid og ressurser, og de brukes derfor sjelden for direkte kryptering, men heller for å kryptere symmetriske nøkler for distribusjon.

Enkel hemmelig nøkkel distribusjon

Merkle foreslo denne enkle metoden:

A → B : PU_A || ID_A
B → A : E(PU_A , K_S)

Denne legger til rette for sikker kommunikasjon, og ingen symmetriske nøkler trenger å eksistere før eller etter sesjonen. Imidlertid er denne metoden sårbar for en aktiv angriper-i-midten.

Nøkkeldistribusjon med konfidensialitet og autentisering

Følgende metode foreslått av Needham beskytter mot både passive og aktive angrep.

A → B : E(PU_B ,[N₁|| ID_A])
B → A : E(PU_A , [N₁|| N₂])
A → B : E(PU_B ,N₂)
A → B : E(PU_B , E(PR_A ,K_S))

En hybrid løsning

En løsning brukt på IBM stormaskiner prøver å bruke det beste fra begge verdener. Her har man fortsatt en KDC som deler en hemmelig masternøkkel med hver bruker, og sesjonsnøkler distribueres kryptert med masternøkkelen. Masternøklene distribueres i forkant med et offentlig-nøkkel-system. Argumentene for denne løsningen omfatter ytelse og tilbakekompatibilitet.

Distribusjon av offentlige nøkler

Det har vært foreslått flere teknikker for distribusjon av offentlige nøkler; de fleste kan plasseres i en av de følgende fire kategoriene:

Offentlig annonsering: Brukere distribuerer offentlige nøkler til mottakere eller kringkaster til et fellesskap. Eksempler omfatter å hekte offentlige PGP-nøkler på slutten av alle epostmeldinger, eller sending til nyhetsgrupper eller epostlister. Den store svakheten er faren for forfalskninger; enhver kan lage en nøkkel og påstå at de er noen andre og kringkaste nøkkelen; til forfalskningen er oppdaget kan de gi seg ut for å være den andre
Offentlig tilgjengelig katalog: Kan oppnå bedre sikkerhet ved å registrere nøkler i en offentlig katalog, men denne må stoles på av alle. Katalogen må ha innslag med {navn,offentlig nøkkel}. Deltakerne må registrere seg hos katalogen på en sikker måte, men kan bytte ut sin nøkkel til enhver tid. Katalogen publiseres periodisk, og kan aksesseres elektronisk, men er fortsatt sårbar for forfalskning.
Offentlig-nøkkel-myndighet: Forbedrer sikkerheten ved å stramme inn kontrollen over distribusjon av nøkler fra katalogen. Forutsetter at brukerne kjenner den offentlige nøkkelen til katalogen, og så har interaksjon med katalogen for å få enhver ønsket offentlig nøkkel på en sikker måte. Forutsetter sanntidstilgang til katalogen når det er behov for nøkler, og kan fortsatt være utsatt for manipulering.
Offentlig-nøkkel-sertifikater: Tillater nøkkelutveksling uten sanntidstilgang til offentlig-nøkkel-myndigheten. Et sertifikat binder en identitet til en offentlig nøkkel, vanligvis i tillegg til en del annen informasjon som gyldighetsperiode, bruksrettigheter, etc., og alt innholdet er signert av en tiltrodd Offentlig-nøkkel-myndighet eller sertifikat-myndighet (CA). Sertifikatet kan verifiseres av enhver som har offentlig-nøkkel-myndighetens offentlige nøkkel.

X.509-sertifikater

X.509 er en av de få tingene som finnes igjen etter ISOs litt håpløse OSI-protokollstakk. X.509 er en del av ITUs X.500 serie som definerer en katalogtjeneste. Katalogen er i praksis en server eller distribuert samling servere som vedlikeholder en database med informasjon om brukere. X.509 definerer et rammeverk for å tilby autentiseringstjenester fra X.500-katalogen til sine brukere, og var første gang utgitt i 1988, med siste oppdatering i 2012.

X.509 er basert på bruk av offentlig-nøkkel-kryptografi og digitale signaturer, den dikterer ikke bruk av noen spesiell algoritme, men anbefaler RSA. Den angir heller ikke bruk av noen spesiell hash-algoritme.

Hvert sertifikat inneholder den offentlige nøkkelen til en bruker, og er signert med den private nøkkelen til en tiltrodd sertifiseringsmyndighet (CA). X.509 definerer alternative autentiseringsprotokoller basert på bruk av offentlig-nøkkel-sertifikater.

Et X.509-sertifikat har følgende elementer:

Versjon
Serienummer
Signaturalgoritme-identifikator
Utstedernavn
Gyldighetsperiode
Navn på eier (subject)
Eierens offentlig-nøkkel-informasjon
Utstederens unike identifikator
Subjektets unike identifikator
Utvidelser
Signatur

Hvordan man får seg et sertifikat

Brukersertifikater utstedt av en CA har følgende karakteristikker:

Enhver bruker med tilgang til den offentlige nøkkelen til CAen kan verifisere den offentlige nøkkelen som var sertifisert
Ingen part unntatt CAen kan modifisere sertifikatet uten at dette blir oppdaget
Ettersom sertifikater ikke kan forfalskes, kan de plasseres i en katalog uten at man trenger å gjøre noe spesielt for å beskytte dem.
Brukere kan dessuten sende sitt sertifikat direkte til andre brukere
Når B har As sertifikat i sin besittelse, har B tiltro til at meldinger han krypterer med As offentlige nøkkel vil være trygge mot avlytting, og at meldinger signert med As private nøkkel er sikre mot forfalskning

CA-hierarki

Hvis begge brukere deler samme CA kan vi anta at de kjenner dennes offentlige nøkkel, men ellers må CAer danne et hierarki. Vi kan da bruke sertifikater som kobler sammen medlemmer av hierarkiet for å validere andre CAer. Hver CA har sertifikater for klienter (forover) og “foreldre” (bakover). Hver klient stoler på sertifikater til deres “foreldre”; dette gjør det mulig å verifisere ethvert sertifikat fra en gitt CA av brukre fra alle andre CAer i hierarkiet.

Revokering av sertifikater

Hvert sertifikat har en gyldighetsperiode, og typisk vil det utstedes et nytt sertifikat rett før det gamle sertifikatet utløper. Enkelte ganger kan det være ønskelig å trekke tilbake et sertifikat før det utløper, enten fordi brukerens private nøkkel er antatt kompromittert, brukeren er ikke lenger sertifisert av denne CAen, eller fordi CAens private nøkkel er antatt kompromittert. Hver CA må vedlikeholde en liste over alle tilbakekalte (revokerte) sertifikater som ikke er utløpt, og disse listene må publiseres i katalogen.

X.509 versjon 3

X.509 har gått gjennom flere versjoner, og versjon 2 hadde ikke plass for all informasjonen som har vist seg nødvendig fra senere tids erfaring med design og implementering. I stedet for å stadig legge til nye felter i et rigid format, fant de som jobbet med standarden ut at en mer fleksibel tilnærming var nødvendig. Følgelig har versjon 3 et antall valgfrie utvidelser, som faller i en av tre hovedkategorier: Nøkkel- og policy-informasjon, attributter til subjekt og utsteder, begrensninger i sertifiserings-stien. Hver utvidelse består av en utvidelseidentifikator, en kritikalitetsindikator, og en utvidelsesverdi.

Nøkkel- og policy-informasjon

Disse utvidelsene gir ytterligere informasjon om nøklene til subjektet og utstederen, pluss indikatorer om sertifikatpolicy. Sistnevnte er et navngitt sett av regler som gir en indikasjon på anvendbarhet av et sertifikat for et gitt samfunn og/eller type applikasjon med felles sikkerhetkrav. Det omfatter myndighetsnøkkel identifikator, subjektnøkkel identifikator, nøkkelbruk, privat nøkkel bruksperiode, sertifikat policy, og policy-avbildininger.

Sertifikat subjekt- og utsteder-attributter

Disse utvidelsene støtter alternative navn, på alternative formater, for et sertifikat-subjekt eller sertifikat-utsteder. De kan gi ytterligere informasjon om sertifikat-subjektet for å øke sertifikatbrukerens tillit til at sertifikatsubjektet er en gitt person eller enhet. Utvidelsesfeltene omfatter subjekt alternativt navn, utsteder alternativt navn, og subjekt katalog-attributter.

Sertifiseringssti-begrensninger

Disse utvidelsene tillater spesifisering av begrensninger i sertifikater utstedt for CAer av andre CAer. Begrensningene kan avgrense type sertifikater som kan utstedes av subjekt-CAen, eller som kan opptre senere i sertifiseringskjeden. Utvidelsesfeltene på dette området omfatter grunnleggende begrensninger, navne-begrensninger, og policy-begrensninger.

PKIX styringsfunksjoner

PKIX identifiserer et antall styringsfunksjoner som potensielt må understøttes av styringsprotokoller: Registrering, initialisering, sertifisering, nøkkelpar-gjenvinning, nøkkelpar-oppdatering, revokeringsanmodning, og kryss-sertifisering.

Nøkkeldistribusjon og -håndtering