Offentlig nøkkel kryptografi og RSA

Transkript

1 Offentlig nøkkel kryptografi og RSA Jens Otto Hatlevold Jan Magne Tjensvold Oktober 2006

2 Sammendrag Utgangspunktet for prosjektet er offentlig nøkkel kryptografi og hvordan denne teknikken benyttes i praksis. Denne rapporten tar for seg kryptering med offentlige nøkler og implementering av RSA som er en asymmetrisk krypteringsalgoritme. Flere løsninger på praktiske problemer rundt implementeringen av RSA blir diskutert. Blant annet gjelder dette viktige tema som Optimal Asymmetric Encryption Padding (OAEP), Probabilistic Signature Scheme (PSS) og andre sentrale sikkerhetsaspekter. Det blir også gjort en vurdering av hvordan asymmetriske krypteringsalgoritmer kan brukes til å utveksle hemmelige nøkler mellom to parter på en sikker og hensiktsmessig måte. 1

3 Innhold Sammendrag 1 1 Introduksjon Bakgrunn Litteratur søk Oppgaven Offentlig nøkkel kryptografi Bakgrunn Digital signatur Nøkkel utveksling RSA Bakgrunn Nøkkel generering Valg av primtall Kryptering Dekryptering Signering og verifisering Sikkerhet Padding i kryptering og signering Padding i PKCS #1 versjon Signatur i PKCS #1 versjon Optimal Asymmetric Encryption Padding Probabilistic Signature Scheme Konklusjon Erfaringer Forslag til videreutvikling Bibliografi 25 2

4 Kapittel 1 Introduksjon 1.1 Bakgrunn Vi ønsket å implementere RSA algoritmen fordi offentlig nøkkel kryptografi virket som et interessant tema. Det å implementere RSA kunne derfor hjelpe oss å forstå mer av de praktiske vurderingene som måtte gjøres. Det gir også et godt innblikk i hvordan man på best mulig måte kan beskytte sensitiv data fra ondsinnet tredjeparter. Offentlig nøkkel kryptografi er også et viktig tema ettersom trenden med å overføre mer sensitive personopplysninger over Internett ser ut til å fortsette. 1.2 Litteratur søk Mye av informasjonen har blitt hentet fra William Stallings bok Cryptography and Network Security [1] fra kapittel 9 og 10. Request for Comments (RFC) [2] inneholder RSA standarden og andre spesifikasjoner for systemer som benytter seg av offentlig nøkkel kryptografi. Google [3] og Wikipedia [4] er stort sett benyttet for å finne frem til ting som er utelatt i læreboka og RFC-ene. 1.3 Oppgaven Oppgaven går ut på å implementere RSA algoritmen på en måte som gjør at det er lett å se hvordan den fungerer på et overordnet plan. Algoritmen skal implementeres i Microsoft sitt.net rammeverk ved hjelp av C#. Sluttresultatet vil være et bibliotek (DLL fil) og et program som demonstrerer mesteparten av funksjonaliteten i biblioteket. Vi benytter oss av den ferdige klassen BigInteger [5] som utfører grunnleggende matematiske operasjoner på store tall, som ofte oppstår innenfor kryptografi. Klassen tilbyr også en pseudo tilfeldig nummer generator, og flere algoritmer for å teste om et tall er et primtall. 3

5 Kapittel 2 Offentlig nøkkel kryptografi 2.1 Bakgrunn Vanlig symmetrisk kryptering benytter seg bare av én nøkkel. Denne nøkkelen må holdes hemmelig slik at det bare er de to partene som skal kommunisere som har kjennskap til den. I kryptografi kaller man ofte partene som kommuniserer med hverandre for Alice og Bob. For at Alice og Bob skal kunne utveksle krypterte meldinger må de på forhånd bli enige om en felles hemmelig nøkkel. Dette kan ofte være vanskelig å utføre i praksis. Tenk deg at Alice ønsker å bestille en vare fra Bob sin nettbutikk i utlandet. Alice må oppgi navn, adresse, kredittkort nummer, og ofte annen informasjon som hun ikke ønsker at skal komme på avveie. Meldinger som sendes over Internett kan leses av andre. Derfor ønsker Alice å kryptere disse viktige opplysningene. Problemet oppstår når hun ønsker å benytte symmetrisk kryptografi. Den sikreste måten å utveksle den hemmelige nøkkelen er ved personlig oppmøte, men det er ikke særlig praktisk når nettbutikken befinner seg langt borte. Figur 2.1 på neste side viser prinsippet for hvordan symmetrisk kryptering fungerer. Det er mulig å få hjelp av en tredjepart, men det fører til større risiko for at nøkkelen faller i feil hender. Et innbrudd eller en stevning kan føre til at tredjeparten må oppgi nøkkelen. Dermed kan Alice sine personopplysninger leses av andre som ikke var tiltenkt denne informasjonen. Hele systemet baserer seg på tillit og det er selvfølgelig en fordel hvis hun bare trenger å ha tillit til en person istedet for flere. Dette gjelder spesielt når man må ha tillit til en instans som ikke har noe med den informasjonen som kommuniseres. Slik unødvendig risiko er det offentlig nøkkel kryptografi prøver å kvitte seg med. Offentlig nøkkel (asymmetrisk) kryptografi baserer seg på et nøkkel par som består av en hemmelig/privat nøkkel og en offentlig nøkkel. Den private nøkkelen er det bare Bob som kjenner til, og den offentlig nøkkelen kan hvem som helst få tak i. Bob lager derfor et nøkkel par og sender den offentlige 4

6 Figur 2.1: Symmetrisk kryptografi nøkkelen til Alice, uten å kryptere den. Alice benytter så denne nøkkelen til å kryptere sine sensitive opplysninger, og deretter sendes meldingen tilbake til Bob. Han benytter så sin private nøkkel til å dekryptere meldingen. Dermed kan han sende varen til Alice, etter at han har fått betalt. Figur 2.2 illustrerer hvordan offentlig nøkkel kryptografi fungerer. Figur 2.2: Offentlig nøkkel (asymmetrisk) kryptografi Offentlig nøkkel kryptografi kan sammenliknes med hvordan en fysisk hengelås fungerer. Hvis Bob har en hengelås kan han sende den til Alice i åpen tilstand. Han beholder selv den eneste nøkkelen som kan åpne hengelåsen. Alice kan dermed benytte hengelåsen til å låse inn en hemmelighet i f.eks. en solid boks. Denne boksen sendes så til Bob, som 5

7 er den eneste som kan låse den opp. Offentlig nøkkel kryptografi baserer seg på såkalte enveis funksjoner og fallemmer. En enveis funksjon er en matematisk funksjon som er lett å utføre en vei, og vanskelig å utføre den andre veien. I RSA er den lette operasjonen når man multipliserer to store primtall for å komme frem til verdien n. For å gå andre veien må man faktorisere n, noe som krever betydelig lengre tid. 2.2 Digital signatur Et problem med offentlige nøkler er at det i utgangspunktet ikke er mulig å bestemme hvem eieren er. Dette kan delvis løses med digital signatur. En måte å se dette problemet på er å bruke hengelås eksempelet (se Kapittel 2.1 på forrige side) igjen. Bob sender sin hengelås til Alice, men før den kommer frem bytter Carol den ut med sin egen hengelås. Alice har ingen mulighet til å fastslå at hengelåsen faktisk kommer fra Bob. Det kan gjerne hende at Bob har avtalte å sende den på forhånd, derfor antar hun naturligvis at den er hans. Etter at Alice har låst inn sin hemmelighet er det bare Carol som kan åpne den. Når den så sendes tilbake til Bob så kan Carol plukke den opp på veien, og deretter åpne den. Et enkelt systemet for digital signatur er hvis Alice først bruker sin private nøkkel til å signere meldingen. Deretter bruker hun Bob sin offentlige nøkkel til å kryptere meldingen, for så å sende den til Bob. Han dekrypterer så meldingen med sin private nøkkel. Etterpå kan han verifisere at meldingen faktisk kommer fra Alice ved å benytte Alice sin offentlige nøkkel. Problemet med hvordan de skal klare å utveksle de offentlige nøklene på en sikker måte gjenstår fortsatt. Og selv om man løser det problemet så er det fortsatt ikke sikkert at Bob faktisk er den personen hun tror det er. For å bestemme den faktiske identiteten til den som eier en offentlige nøkkelen må man gå et skritt lengre enn digital signatur. Det kreves det et system som sørger for å sjekke identiteten til utsteder av de offentlige nøklene. Dette kan oppnås på forskjellige måter, men den mest kjente er kanskje offentlig nøkkel infrastruktur, eller Public Key Infrastructure (PKI) på engelsk. PKI er et veldig formelt system hvor en Certificate Authority (CA) sørger for å utstede sertifikater som beviser den faktisk identiteten til en person. Det er også mulig å basere seg på et mer uformelt system slik som Pretty Good Privacy (PGP) gjør. Der bygger man seg et såkalt web of trust hvor man selv bestemmer hvilke offentlige nøkler man ønsker å stole på, og i hvilken grad man stoler på dem. 2.3 Nøkkel utveksling Det finnes flere nyttige protokoller som sørger for digital signatur og integriteten til meldingen som sendes. For å ivareta både konfidensialitet, integritet 6

8 og sørge for autentisering så må alle de tidligere teknikkene benyttes. Asymmetrisk kryptografi er kun praktisk hvis mengden informasjon som skal utveksles er relativt liten. Det finnes heldigvis flere måter å effektivt kombinere symmetrisk kryptografi med asymmetrisk kryptografi. Da benytter man offentlig nøkkel kryptografi til å utveksle hemmelige nøkler for symmetrisk kryptografi. Diffie-Hellman er en slik kjent teknikk for nøkkel utveksling. RSA kan også brukes til nøkkel utveksling i applikasjoner som f.eks. Secure Shell (SSH) [6]. Selv om RSA ikke er så vanlig i SSH i dag forventes det mer utstrakt bruk ettersom det rapporteres å være en del raskere enn Diffie-Hellman til dette formålet. Dette vil være spesielt nyttig for mobile enheter ettersom de ikke har like bra ytelse som vanlige PC-er. Diffie-Hellman er derimot hyppig brukt til nøkkel utveksling i mange forskjellige applikasjoner. Blant annet brukes det som standard i SSH [7]. 7

9 Kapittel 3 RSA 3.1 Bakgrunn RSA er en offentlig nøkkel baserte krypteringsalgoritme. Algoritmen ble utviklet av Ron Rivest, Adi Shamir og Len Adleman (derav RSA) i 1977 og utgitt i 1978 [8]. Det er en av de første offentlig nøkkel kryptografi løsningene og er uten tvil den som er mest kjent og benyttet i dag. Selve algoritmen beskrives i sin helhet i Public Key Cryptography Standard (PKCS) #1 [9] En vanlig symmetrisk kryptering benytter seg bare av en enkel nøkkel, mens asymmetrisk (offentlig nøkkel basert) kryptering har to nøkler. Den ene nøkkelen må holdes hemmelig (privat nøkkel) mens den andre kan distribueres til andre kommunikasjonspartnere (offentlig nøkkel). RSA består i hovedsak av tre deler: Generering av privat og offentlig nøkkel par (se Kapittel 3.2 på neste side). Kryptering (se Kapittel 3.3 på side 12). Dekryptering (se Kapittel 3.4 på side 14). RSA er et blokk chiffer hvor klartekst og kryptert tekst er et heltall mellom 0 og n 1. En typisk verdi for n (nøkkel lengde) er bit, eller som består av 309 desimale siffer. For en klartekst i ASCII (8 bit/tegn) og n = bit vil RSA generere en blokk for hver 127. tegn. I test programmet som er utviklet benyttes det UTF-8 [10] som gir 8 bit ut for vanlig ASCII tekst (de 128 første tegnene). Alle andre tegn (f.eks. æ, ø og å) vil føre til 16 bit eller mer og det kan derfor være mindre enn 127 tegn i en blokk ved en nøkkel lengde på bit. Ved bruk av forskjellige padding teknikker (som OAEP i Kapittel på side 18) så vil det bli plass til enda færre tegn i en blokk. RSA kan blant annet benyttes til å sikre konfidensialitet og benyttes til digital signatur og nøkkel utveksling. Innenfor offentlig nøkkel kryptografi 8

10 er det også flere algoritmer å velge mellom. Tabell 3.1 viser en oversikt over bruksområdene til de ulike algoritmene for offentlig nøkkel kryptografi. Algoritme Konfidensialitet Digital Signatur Nøkkel utveksling RSA Ja Ja Ja Elliptisk kurve Ja Ja Ja Diffie-Hellman Nei Nei Ja DSS Nei Ja Nei Tabell 3.1: Algoritmer for offentlig nøkkel kryptografi Elliptisk kurve kryptografi (først beskrevet i 1985), eller Elliptic Curve Cryptography (ECC) på engelsk, er en nyere algoritme enn RSA, og den støtter også de samme anvendelsene som RSA. Siden ECC er såpass ny og har levd litt i skyggen av RSA så det ikke blitt forsket så mye på den enda. Dette gjør at man ikke kan stole helt og fullt på sikkerheten som algoritmen tilbyr. Bare mange års forskning og kritisk vurdering av algoritmen vil vise om den virkelig er sikker. Diffie-Hellman er en godt kjent og mye brukt algoritme for nøkkel utveksling og Digital Signature Standard (DSS) er en algoritme for digital signatur. Mer om digital signatur og nøkkel utveksling finnes i hhv. Kapittel 2.2 på side 6 og Kapittel 2.3 på side Nøkkel generering Et RSA nøkkel par består av en privat og en offentlig nøkkel. Nøkkel paret genereres slik: p, q = tilfeldig valgte primtall; p q n = p q λ(n) = lcm(p 1, q 1) gcd(λ(n), e) = 1; 2 < e < n d e 1 (mod λ(n)) Offentlig nøkkel, P U = {e, n} Privat nøkkel, P R = {d, n} Nøkkel genereringen i RSA algoritmen baserer seg på å velge to store tilfeldige primtall. Mye av sikkerheten i RSA ligger i at det skal være veldig vanskelig å faktorisere n og dermed finne p og q. Vi kommer mer tilbake til valg av primtall i Kapittel på neste side. n, også kalt RSA modulus, blir kalkulert ved å multiplisere p og q. Videre regnes λ(n) ut ved å benytte funksjonen LCM (Least Common Multiple eller minste felles multiplum) på 9

11 tallene q 1 og p 1. Her er det en endring fra PKCS #1 versjon 1.5 til versjon 2.0 som bruker λ(n) i stedet for φ(n) (hvor φ(n) = (p 1)(q 1)). Samtidig ble det også gjort en endring slik at versjon 2.0 og senere kan generere flere enn to primtall faktorer av n, samt at det er støtte for bruk av Chinese Remainder Theorem (CRT) ved dekryptering. GCD (Greatest Common Divisor eller største felles nevner) benyttes for å sørge for at e og λ(n) ikke har noen felles faktorer. Sammenhengen gcd(a, b) lcm(a, b) = a b benyttes slik at GCD funksjonen i BigInteger klassen kan brukes uten å måtte implementere en egen algoritme for LCM i tillegg. Krypterings eksponenten e velges i de fleste implementasjonene til et fast lavt oddetall. Dette gir flere positive egenskaper. For det første blir det mye raskere å kryptere ved bruk av et såkalt Fermat primtall. Dette er tall som kun har den mest signifikante bit og den minst signifikante bit satt til 1. De eneste Fermat primtallene som er kjent er F 0,, F 4, hvor F n er et Fermat tall på formen 2 2n, hvor n er et ikke-negativt heltall. Dette gjelder for eksempel tallet 3 ( = F 0 ) og tallet ( = F 4 ). Det er ikke anbefalt å bruke tallet 3 som offentlig eksponent da dette er for lite til å gi tilstrekkelig sikkerhet i krypteringen. Tallet har vist seg å ha gode egenskaper som offentlig eksponent og vi har derfor, i likhet med andre implementeringer, valgt å bruke dette tallet. Til sammenligning bruker RSA implementeringen i.net (RSACryptoServiceProvider) en offentlig eksponent lik En annen fordel ved å velge et fast lavt tall for e er at dekrypterings eksponenten d alltid vil bli veldig stor slik at man unngår noen angrep på RSA som er omtalt i Kapittel 3.6 på side 15. Når e er valgt kan d enkelt beregnes. Den offentlige nøkkelen består da av e og n, mens den private nøkkelen består av d og n. Det er essensielt for sikkerheten at d, p og q holdes hemmelig Valg av primtall Et primtall er et positivt heltall større enn 1 som bare kan deles på seg selv og 1 uten at divisjonen medfører en rest. Tallene p og q skal være tilfeldig valgte primtall som er tilstrekkelig store. Det finnes ingen enkel teknikk for å plukke ut primtall av en vilkårlig størrelse. Det som ofte gjøres er å finne frem til et tilfeldig oddetall i den rette størrelsen. Deretter testes dette tallet med en rekke tester for å bestemme om det sannsynligvis er et primtall. Det finnes i dag ingen tester som kan avgjøre om et tall er et primtall med 100% sikkerhet. Til tross for denne usikkerheten så er det mulig å kjøre testene slik at sannsynligheten kommer så nær 100% som ønsket. Dette går selvfølgelig på bekostning av tiden det tar å generere nøkkel paret. Flere slike tester eksisterer, og noen av dem er tilgjengelige i BigInteger klassen som vi benytter i implementering. I BigInteger finner vi disse testene: Fermat primality test, Miller-Rabin primality test, Solovay-Strassen 10

12 primality test og Strong Lucas pseudo prime. Vår implementering benytter seg av Miller-Rabin testen i tillegg til en enkel divisjons test som sjekker om tallet kan deles på noen av primtallene som er lavere enn Primtallene som genereres må også ha den egenskapen slik at n = p q gir en n med antall bits som er lik ønsket nøkkel lengde. Det er nemlig antall bit i n som avgjør nøkkel lengden. Det er flere metoder for å oppnå dette. Noen av disse er nevnt nedenfor: Generer p og q innenfor et gitt intervall. Generer først p og generer deretter q inntil n = p q gir ønsket antall bit i n. Generer p og q og sett de to mest signifikante bitene til 1. Vi benytter oss av den siste metoden. Metodene nevnt over har sine svakheter. Det vil ikke være mulig for en annen part å verifisere at nøklene virkelig er generert fra tilfeldige primtall p og q. Det har vist seg at det er mulig å generere faktorer p og q slik at man kan sende skjulte meldinger i n [11]. Dette kalles en underbevisst kanal, eller subliminal channel. På denne måten er det mulig å sende informasjon som hvem som helst kan få tak i så lenge man vet hvor man skal se. For eksempel kan dette være informasjon som gjør det mulig å gjenskape p og q slik at krypterte meldinger kan dekrypteres. Slik informasjon sendes uten at brukeren(e) av nøklene er klar over det. Problemet med en underbevisst kanal refereres i faglitteraturen som fange problemet. I fange problemet er to fanger gitt tillatelse til å kommunisere mellom hverandre, men har ikke lov å sende krypterte meldinger. De får bare lov til å utveksle offentlige nøkler og signere meldingene digitalt. Problemet er da hvordan de skal få kommunisert med hverandre uten at fangevokteren verken kan oppdage eller tyde meldingene. En slik kommunikasjonskanal kalles en underbevisst kanal (subliminal channel). Underbevisste kanaler faller også inn under begrepet kleptografi, som betyr å stjele informasjon sikkert, uten at det er mulig å oppdage det. Å stjele informasjonen sikkert betyr at informasjonen ikke skal være tilgjengelig for andre enn de som stjeler informasjonen. Dette kan gjøres ved at informasjonen som sendes i den underbevisste kanalen er kryptert slik at man må ha tilgang til en dekrypteringsnøkkel for å tyde informasjonen. I [11] nevnes det to metoder for å minimere og eliminere denne kanalen når nøklene blir generert. Protokollen som brukes for å eliminere den underbevisste kanalen kalles for KEy Generation with VErifiable Randomness (KEGVER). I korte trekk benytter KEGVER seg av en betrodd tredje part som deltar i nøkkelgenereringsprosessen. Vi kommer ikke til å gå nærmere inn på dette temaet. 11

13 Et annet problem ved generering av nøkler er at det ved en standard implementering av RSA ikke er mulig for andre å verifisere at faktorene av n (p og q) virkelig er tilfeldige. Problemet er at man ikke kan kontrollere at nøklene som mottas av andre ikke inneholder underbevisste kanaler, eller at faktorene p og q ikke er generert på en slik måte at det blir enkelt å faktorisere n og dermed kalkulere den private nøkkel komponenten e. Dette problemet løser KEGVER. Ved bruk av denne protokollen vil det i etterkant være mulig å verifisere at nøkkelen oppfyller kravene om tilfeldighet også av andre enn den som genererte nøklene. [11] skisserer også en metode som minimerer den underbevisste kanalen. Fordelen med denne metoden er at den ikke krever en tredje part for å generere nøkkelen. Også her vil det være mulig for andre å verifisere at nøkkelen er generert med helt tilfeldige primtall. Svakheten er at den underbevisste kanalen ikke blir lukket helt, men det er en vesentlig forbedring fra nøkkelgenereringsmetoder som ikke tar hensyn til dette. Til sammenlikning vil en nøkkelgenereringsmetode som ikke tar hensyn til dette kunne lekke data tilsvarende inntil halvparten av nøkkel-lengden, mens metoden nevnt her bare vil lekke omkring 8 bit. KEGVER er helt fri for underbevisste kanaler. 3.3 Kryptering RSA er i sin enkleste form bygget opp av noen matematiske operasjoner som utfører kryptering, dekryptering, signering og verifisering. Disse forskjellige operasjonene er i RSA kalt for henholdsvis: RSAEP (RSA Encryption Primitive) bruker offentlig nøkkel til mottaker for å kryptere en melding RSADP (RSA Decryption Primitive) bruker egen privat nøkkel for å dekryptere en melding RSASP (RSA Signing Primitive) bruker egen privat nøkkel for å signere en melding RSAVP (RSA Verification Primitive) bruker offentlig nøkkel til avsender for å verifisere en melding Vi skal i de påfølgende kapitlene gjennomgå disse, samt beskrive metoder for å gjøre krypteringen og signeringen mer sikker. Kryptering (RSAEP) foregår på følgende måte (M = klartekst, C = kryptert tekst): 12

14 M < n C = M e mod n Klarteksten M blir representert av en eller flere blokker med heltall som er mindre enn modulus verdien n. Hver av disse blokkene blir så kryptert hver for seg, og resultatet blir like mange blokker med kryptert tekst. Parametrene e og n er komponentene i den offentlige nøkkelen. Det er kun den tilhørende private nøkkelen som kan dekryptere meldingen som krypteres med den offentlige nøkkelen. Grunnen til at meldingen M må være mindre enn n er at resultatet fra krypteringsalgoritmen blir redundant hvis dette ikke er oppfylt. Hvis så skjer vil det ikke lenger være entydig mulig å kryptere meldingen. Man ender opp med at klar tekster kan bli kryptert til en og samme kryptert tekst. Derfor vil det heller ikke lenger være mulig å dekryptere teksten. Dette kan enkelt vises med et eksempel (se Tabell 3.2). I denne tabellen brukes de følgende verdiene: n = 15, e = 9, d = 7 og dekryptering gjøres med M = C d mod n. M 1 = mod 15 = 0 = C mod 15 = 0 = M 1 M 2 = mod 15 = 0 = C mod 15 = 0 = M 2 M 3 = mod 15 = 1 = C mod 15 = 1 = M 3 M 4 = mod 15 = 1 = C mod 15 = 1 = M 4 Tabell 3.2: Eksempel på kryptering med RSA hvor M n Eksempelet viser tydelig at når klarteksten er lik eller større n så blir resultatet fra krypteringsalgoritmen redundant. M 1 og M 2 er to ulike klartekster, men resultatet av krypteringen blir lik siden M 1 ikke oppfyller kravet M < n. Videre viser eksempelet også en annen viktig svakhet ved krypteringen. Krypteres klarteksten 0 eller 1 så blir den krypterte meldingen lik klarteksten. Dette er vist matematisk i Tabell 3.3. } 0 x = 0 0 mod y = 0 1 x = 1 1 mod y = 1 0 x mod y = 0 } 1 x mod y = 1 Tabell 3.3: Kryptering av 1 og 0 x 0 y 0 Det er svært viktig å være klar over denne svakheten. Ved å legge til en tilfeldig padding sammen med klarteksten vil man ikke lenger være utsatt for dette problemet. I tillegg vil man da kunne få flere ulike krypterte meldinger som tilhører samme klartekst. Vi vil komme tilbake til dette senere. 13

15 3.4 Dekryptering Dekryptering (RSADP) foregår slik (M = klartekst, C = kryptert tekst): M = C d mod n Dekryptering skjer på samme måte som for kryptering bortsett fra at den private nøkkelen blir brukt. Hver blokk med kryptert tekst blir dekryptert hver for seg og satt sammen til den opprinnelige klarteksten. Her må selvfølgelig den krypterte teksten C være mindre enn n, tilsvarende slik som for kryptering. Dette vil ikke være noe problem hvis det er den tilhørende private nøkkelen som blir brukt for å kryptere meldingen. Dekrypteringen skjer med den private nøkkelen som er veldig stor ofte like stor som nøkkel lengden. På grunn av dette tar det my lengre tid å dekryptere en melding fremfor å kryptere den (siden da den mye kortere offentlige nøkkelen brukes). En metode som gjør dekrypteringen mye raskere er å bruke Chinese Remainder Theorem. Vi har ikke tenkt å gå spesielt i dybden på denne metoden annet enn å nevne at det vil gå om lag fire ganger så fort å dekryptere meldingen ved bruk av CRT fremfor standard metode. CRT krever også at det regnes ut noen flere eksponenter og koeffisienter under nøkkelgenereringsprosessen. 3.5 Signering og verifisering En en av de store fordelene med asymmetrisk kryptering fremfor symmetrisk kryptering er at det er mulig å autentisere seg. Dette er mulig fordi hver enkelt har sin egen private nøkkel med en tilhørende offentlig nøkkel. Med symmetrisk kryptering kan hvem som helst som har tilgang på den hemmelige nøkkelen kryptere en melding og sende den videre til den andre parten, eller påstå at en annen har sendt den. Det er derfor ikke mulig å kunne avgjøre hvem som egentlig var avsender. Dette problemet løses ved at hver enkelt har et eget nøkkel par en offentlig og en privat. Krypteres meldingen med den private nøkkelen er det bare den offentlige nøkkelen som kan brukes for å dekryptere meldingen. Dette gir mottakeren muligheten til å verifisere at meldingen virkelig stammer fra den påståtte avsenderen. Siden den offentlige nøkkelen brukes til å kryptere meldingen kan hvem som helst som har tilgang til den offentlige nøkkelen dekryptere meldingen. Siden nøkkelen er offentlig, må man anta at alle har eller kan få tilgang til nøkkelen og dermed også meldingen. På bakgrunn av dette er det ikke hensiktsmessig å kryptere meldingen med den private nøkkelen for å oppnå signering. Spesielt gjelder dette når meldingen er såpass lang at den må deles i flere blokker som krypteres hver for seg. En enkel metode som brukes er å benytte en hashfunksjon som lager en tilstrekkelig lang hashkode av 14

16 meldingen. Denne hashkoden blir så kryptert med den private nøkkelen, og lagt til klarteksten. Den krypterte hashkoden blir kalt en signatur, og fastslår at den tilhørende klarteksten virkelig kommer fra avsenderen. For å verifisere at meldingen virkelig kommer fra den påståtte avsenderen, trenger mottakeren den offentlige nøkkelen til avsenderen. Når mottakeren har funnet den, kan hashkoden dekrypteres og sammenlignes med en hashkode som mottakeren selv har generert fra meldingen. Er disse to like er meldingen autentisk og stammer fra den påståtte avsenderen. Det er mulig for mottakeren å lagre meldingen og den tilhørende krypterte hashkoden (signaturen) for å avgjøre eventuelle tvister som måtte oppstå i etterkant. Det er da tilstrekkelig å gi fra seg meldingen med tilhørende signatur til en tredje part som henter inn avsenderens offentlige nøkkel. Slik kan meldingen verifiseres fra en tredje part uten at private nøkler blir kompromittert. Primitivene for signering (RSASP) og verifisering (RSAVP) er matematisk identiske med primitivene for henholdsvis dekryptering (RSADP) og kryptering (RSAEP), men er separert for å vise at de brukes til å utfører ulike operasjoner. 3.6 Sikkerhet RSA har, som alle andre krypteringsalgoritmer, enkelte svakheter. Det er i hovedsak fire forskjellige måter å angripe RSA algoritmen på: Brute force angrep: Prøv alle mulige private nøkler. Matematisk angrep: Faktorisering av produktet til to primtall. Timing angrep: Avhenger av kjøretiden til dekrypteringsalgoritmen. Valgt kryptert tekst angrep: Utnytter egenskaper til RSA. Alle kryptosystemer er kan angripes med såkalt brute force, som vil si at man prøver alle mulige hemmelige nøkler. RSA beskytter seg mot dette ved å ha en så stor nøkkel lengde at dette angrepet blir praktisk umulig å gjennomføre. Ulempen er at ved å bruke en større nøkkel så vil alle operasjonene med algoritmen ta lengre tid. I 1990 rapporterte Michael J. Wiener [12] om en svakhet i RSA når eksponenten d i den private nøkkelen er liten. Det ble vist at d enkelt kan bestemmes hvis e < n (som er vanlig), d < n 1/4 og q < p < 2q. Vår implementering tar høyde for denne svakheten ved å forkaste nøkler som tilfredstiller disse ulikhetene. RSA baserer seg på vanskeligheten av å kunne faktorisere verdien n. Ved hjelp av mer sofistikerte algoritmer og mer prosesseringskraft har det etterhvert blitt lettere og lettere å utføre slik faktorisering. For å gjøre 15

17 verdien n vanskeligere å faktorisere har utviklerene av RSA derfor foreslått at følgende retningslinjer bør følges: Forskjellen i antall desimale siffer mellom p og q bør ikke være mer enn noen få. Både p 1 og q 1 bør inneholde en stor primtallsfaktor. gcd(p 1, q 1) bør være liten. Valgt kryptert tekst angrep beskrives blant annet i Kapittel Padding i kryptering og signering Padding i PKCS #1 versjon 1.5 RSA algoritmen er i utgangspunktet sårbar mot et valgt kryptert tekst angrep (Choosen Ciphertext Attack). For å unngå denne svakheten legges det til en tilfeldig generert tekst i tillegg til klarteksten. Dette gjør et valgt kryptert tekst angrep mye vanskeligere siden en bestemt klartekst kan generere mange ulike krypterte tekster. I Tabell 3.4 er en oversikt over denne paddingen. BT D EB k ED PS X Y X block type data encryption block length of modulus in octets encrypted data padding string concatenation of X, Y length in octets of X EB = 0x00 BT PS 0x00 D EB = k BT = 0x00 - privat nøkkel operasjon - PS = 0x00 (ikke anbefalt) 0x01 - privat nøkkel operasjon - PS = 0xFF 0x02 - offentlig nøkkel operasjon - PS = tilfeldige tall ulik 0 PS = k - D - 3 Tabell 3.4: Oversikt over paddingen til RSA som beskrevet i PKCS #1 versjon 1.5 Den første byten sørger for at EB er mindre enn modulus-komponenten i nøkkelen. BT angir hvilken nøkkel som skal brukes i krypteringen. Hvis det er en kryptering av en melding så er det den offentlige nøkkelen som brukes slik at bare mottakeren med den tilhørende private nøkkelen kan dekryptere 16

18 meldingen. Det man oppnår er at PS blir fylt med tilfeldige tall slik at den krypterte teksten blir forskjellig selv om den samme klarteksten krypteres flere ganger. Dette er brukes for å kunne unngå valgt klar tekst angrep. Når RSA skal brukes til å autentisere/signere meldinger er dette ikke ønskelig siden da flere ulike signaturer kan brukes til å autentisere samme melding. For å unngå dette velges PS til en fast verdi ved å sette BT til 0x00 eller 0x01. Hvis BT settes til 0x00 må meldingslengden være kjent for den som skal dekryptere, ellers må klarteksten begynne med en byte ulik 0x00. Det anbefales derfor ikke å bruke verdien 0x00 for BT. PS er selve paddingen som brukes til å fylle opp krypteringsblokken (EB) til lik lengde som nøkkel lengden. PS må være lik eller større enn 8, noe som betyr at klarteksten får maks lengde: k 8 3 = k 11 Dette betyr igjen at nøkkel lengden i RSA algoritmen minimum må være: = 12 bytes = 12 8 = 96 bits Alle elementene settes sammen til en krypteringsblokk som får like mange bytes som nøkkelen. Denne krypteringsblokken blir så kryptert. RSA algoritmen har ingen eksplisitt innebygd integritet sjekk for å fange opp feilaktige data ved for eksempel en dataoverføring. Men, strukturen til krypteringsblokken garanterer at sannsyligheten for at feilaktige data ikke blir oppdaget er mindre enn 2 16, som er største sannsynlighet for at en tilfeldig krypteringsblokk ser ut som en blokk type (BT) 0x02. Ved dekryptering dekrypteres den krypterte teksten til en krypteringsblokk. Krypteringsblokken deles så videre opp i BT, PS og D. Enhver feil eller uoverenstemmelse med verdiene i blokkene sees på som en feil, og dekrypteringen avbrytes. Går alt bra er innholdet i D den dekrypterte meldingen. Paddingen som er definert i versjon 1.5 av RSA er ikke lenger sett på som noen god metode for å unngå klar tekst angrep. Det finnes flere avanserte og sofistikerte metoder for å angripe kryptert tekst kodet med denne paddingen. For å unngå dette problemet er RSA utvidet med en ny form for padding kalt Optimal Asymmetric Encryption Padding (OAEP). Denne paddingen er temaet i Kapittel på neste side Signatur i PKCS #1 versjon 1.5 Signeringen i PKCS #1 versjon 1.5 baserer seg på samme oppsett som ved paddingen forklart i Kapittel på forrige side. Sikkerheten i signaturen baserer seg på at det er veldig vanskelig å matematisk beregne den private nøkkelkomponenten e, samt at hash funksjonen har gode egenskaper slik at det er vanskelig å finne kolliderende tekster. To ulike tekster som kolliderende genererer den samme hash verdien, og med en god hash funksjon er det vanskelig å finne en slik tekst. Signeringsalgoritmen i PKCS #1 versjon 1.5 er deterministisk. Dette betyr at den alltid gir den samme signaturen med den samme teksten. Det er 17

19 lagt opp en del padding og faste verdier for å fylle ut den kodetet meldingen slik at den blir like lang som nøkkelen. Disse faste verdiene kan igjen brukes for å kontrollere at det er signaturen er i et gyldig format. Formatet til den kodete meldingen er vist nedenfor. EM = 0x00 BT PS 0x00 T Denne har den samme strukturen som for padding i kryptering og dekryptering i PKCS #1 versjon 1.5. Forskjellen er at BT (Block Type) settes til 0x01 og PS (Padding String) blir fylt med 0xFF. T inneholder hash koden til meldingen samt en ASN.1 (se Kapittel 3.7.3) identifikator for hash funksjonen som er brukt. T-blokken var opprinnelig kodet med BER (Basic Encoding Rules) men ble i PKCS #1 versjon 2.0 byttet ut med DER (Distinguished Encoding Rules). Vi har ikke satt oss inn i DER eller BER, men benyttet oss av de forhåndsdefinerte verdien for bruk av SHA-1 som er listet opp i [9]. EM blir tilslutt kryptert med signerings primitivet RSASP. For å verifisere signaturen beregnes signaturen på nytt og sammenliknes med meldings-signaturen. Dette kan gjøres fordi signeringskodingen er deterministisk og vil derfor alltid gi samme resultat. Er begge like er signaturen verifisert Optimal Asymmetric Encryption Padding Optimal Asymmetric Encryption Padding (OAEP) ble oppfunnet av Mihir Bellare og Phillip Rogaway i 1994 [13], og ble forbedret av Don B. Johnson og Stephen M. Matyas i 1996 [14]. Fordelen med OAEP fremfor paddingen definert i versjon 1.5 av PKCS #1 er at OAEP er motstandsdyktig mot tilpasset kryptert tekst angrep (adaptive chosen ciphertext attacks - CCA2). Problemet med versjon 1.5 er at det er mulig å generere gyldige krypterte tekster uten å vite hva klarteksten er. Fra versjon 2.0 av PKCS #1 ble OAEP innført i RSA. OAEP og RSAEP (RSA Encryption Primitive) har i seg selv svakheter som gjør det mulig for en angriper å hente ut hele eller deler av den kodete informasjonen. Allikevel så viste Fujisaki, Okamoto, Pointcheval, and Stern [15] at kombinasjonen RSAES-OAEP er motstandsdyktig mot CCA2. Ved bruk av OAEP er det ikke lenger mulig å generere gyldige krypterte tekster uten å vite klarteksten. Dette betyr at RSAES-OAEP er klartekst-bevisst (plaintext-aware). En slik egenskap er tett forbundet med motstandsdyktighet mot valgt klartekst angrep. OAEP tar en melding M (Message) og koder den til en kodet melding EM (Encoded Message) ved hjelp av noen parametre, en hash funksjon og en maske genererende funksjon (MGF - Mask Generating Function). For å få meldingen M tilbake fra den kodete meldingen EM kjøres en invers OAEP funksjon. En del begreper må forklares før en gjennomgang av selve OAEP gjøres. OAEP benytter seg av en MGF (Mask Generating Function). En MGF 18

20 genererer en gitt lengde med tilfeldige bit som er avhengige av en verdi også kalt seed. Det som er spesielt med MGF er at den alltid vil gi ut samme bit streng når samme seed brukes. Bit strengen som genereres av MGF vil også være totalt tilfeldig slik at det ikke er mulig å gjette en del av bit strengen gitt at man vet en annen del av strengen. Lengden av bit strengen kan være så lang som ønskelig. OAEP benytter seg også av en hash funksjon. Den mest vanlige å bruke er SHA-1. I vår implementering benytter vi oss av SHA1CryptoServiceProvider i.net som er en SHA-1 implementering beregnet på kryptografiske operasjoner. Hash funksjonen genererer en helt tilfeldig bit streng med fast lengde. For SHA-1 er denne lengden 20 byte. Figur 3.1 viser skjematisk oppbygning av OAEP. Figur 3.1: Optimal Asymmetric Encryption Padding lhash er hashverdien av en tekst (enkelsk: label) som kan legges ved meldingen som skal kodes. Standard verdi for denne teksten er en tom streng. Vi kommer ikke til å gå inn på bruksområder for denne teksten. M er meldingen som skal kodes. Tomrommet i DB (Data Block) fylles med PS (Padding String). PS er en streng der alle bytene har verdien 0x00. Mellom PS og M settes byten 0x01 for å kunne identifisere starten 19

21 på meldingen. seed er en 20 byte lang tilfeldig streng som brukes av MGF. Strengen som genereres av MGF er like lang som DB og kombineres med DB ved hjelp av en XOR operasjon. Likeledes genereres det en maske for å maskere den tilfeldige verdien seed. Disse strengene settes til slutt sammen i EM (Encoded Message) med den første byten satt til 0x00. Lengden av EM er lik nøkkel lengden. Av dette kan man fort regne ut maks lengde av klarteksten som kan kodes ved bruk av en bits nøkkel. 16 bit går til 0x00 og 0x01 i henholdsvis EM og DB seed er 160 bit lhash er 160 bit (lengden av hashverdien) PS fyller tomrommet i DB avhengig hvor stor meldingen M er. PS kan være 0 byte. Med litt regning blir den maksimale lengden av meldingen ved bruk av bits nøkkel og SHA-1 hash algoritme være 688 bit - eller 68 byte. Dataene i EM blir til slutt kryptert med krypteringsprimitiven RSAEP som gir den krypterte teksten. For å hente tilbake meldingen M gjøres operasjonene beskrevet ovenfor i revers. maskeddb blir argument til MGF som igjen sammen med maskedseed gjenskaper seed som blir brukt i MGF for å sammen med maskeddb gir DB. Nå er det bare å sjekke at verdiene lhash, PS og byten 0x01 er slik som de skal og til slutt hente ut meldingen M Probabilistic Signature Scheme Probabilistic Signature Scheme (PSS) ble oppfunnet av Mihir Bellare and Phillip Rogaway [16] i PSS brukes som navnet tilsier til å signere meldinger. Fordelen med PSS fremfor den tidligere signeringsmetoden beskrevet i PKCS #1 versjon 1.5 er at den er probabilistisk og ikke deterministisk slik som versjon 1.5 er. PSS introduserer en tilfeldig verdi kalt salt som gjør at signaturen blir ulik hver gang den signeres. Salt-verdien gir forbedret sikkerheten i forhold til deterministiske signeringsmetoder. Allikevel er ikke tilfeldigheten i salt-verdien kritisk for sikkerheten, og sikkerheten kan da sammenliknes med deterministiske signeringsmetoder [17]. Introduksjonen av en tilfeldig verdi gjør også at kravene til hash funksjonen ikke er like strenge. Dette fordi en angriper ikke kan vite hvilket tall som blir valgt, og dermed er det ikke nok for en angriper å finne en kolliderende tekst for å forfalske en signatur. Det er derfor ikke så viktig at hash funksjonen er motstandsdyktig mot kollisjoner som ved deterministiske signeringsrutiner. 20

22 I PKCS #1 versjon 1.5 kodes det inn en identifikator for hash funksjonen. Dette gjøres ikke i PSS. Det er da i teorien mulig for en angriper å bytte ut hash funksjonen for meldingen med en svakere hash funksjon. Men siden det er vanlig å bruke samme hashfunksjon også i MGF (Mask Generating Function) så vil hele EM (Encodet Message) være avhengig av hashfunksjonen og ikke bare en del av den slik som i PKCS #1 versjon 1.5. En eksisterende signatur vil derfor ikke la seg verifisere ved bruk av en annen hash funksjon. I tillegg består signaturen av en stor mengde verifiserbar struktur som gjør det veldig vanskelig å lage falske signaturer. Det er ikke lenger anbefalt å benytte signering basert på metoden beskrevet i PKCS #1 versjon 1.5. Med tanke på fremtidige krav er det PSS som anbefales. Kjernen i denne verifiserbare strukturen er MGF som genererer en tilfeldig verdi som må stemme overens med en stor del ev EM for å få en gyldig signatur. Figur 3.2: PSS Fremgangsmåten for PSS har likhetstrekk til OAEP som beskrevet i Kapittel på side 18, og er vist skjematisk i Figur 3.2. En hash-verdi av meldingen blir som for signeringen i PKCS #1 versjon 1.5 generert. I vår implementasjon benytter vi oss av SHA-1 i alle hash-funksjonene. I strengen 21

23 M blir den tilfeldige verdien salt lagt til. Lengden av salt-verdien kan være variabel, men er som oftest 0 eller lengden av hash funksjonen. padding 1 er en streng av 8 bytes med verdien 0x00. M blir så hashet til strengen H, samtidig som den er argument til MGF som igjen genererer en maske lik lengden til DB (Data Block). DB består av saltverdien samt en padding padding 2 som fyller tomrommet i DB. DB og resultatet fra MGF blir gjennom en XOR operasjon til strengen maskeddb. maskeddb, H og en byte lik 0xBC blir satt sammen i EM (Encoded Message), som er resultatet av PSS kodingen. EM blir så kryptert med signerings primitiven RSASP. Grunnen til at den siste byten 0xBC er med er for kompabilitet med andre signatur primitiver [9]. Dekoding/verifisering av en signatur skjer i motsatt rekkefølge av kodingen. Alle faste strenger blir sjekket for at de er korrekte i både størrelse og verdi. Hash verdien av meldingen blir tilslutt sjekket om den stemmer overens med mhash. Stemmer alle disse kriteriene blir signaturen godkjent. 22

24 Kapittel 4 Konklusjon Vi har implementert et bibliotek i C# med et stort antall funksjoner slik at det kan fungere sammen med andre liknende løsninger. Dette inkluderer blant annet: Grunnleggende nøkkel generering (se Kapittel 3.2 på side 9) Kryptering (se Kapittel 3.3 på side 12) Dekryptering (se Kapittel 3.4 på side 14) Optimal Asymmetric Encryption Padding (OAEP) (se Kapittel på side 18) Probabilistic Signature Scheme (PSS) (se Kapittel på side 20) 4.1 Erfaringer Det har vist seg at det ikke var selve RSA algoritmen som var vanskelig å implementere. Det som krevde mest tid var ting som i hovedsak hadde noe med formatet til den endelige meldingen å gjøre. Slik som blant annet Optimal Asymmetric Encryption Padding (OAEP) (se Kapittel på side 18) og Abstract Syntax Notation One (ASN.1) (se Kapittel på side 16) slik at implementeringen i større grad følger standardene beskrevet i Public Key Cryptography Standards (PKCS) serien. 4.2 Forslag til videreutvikling Her diskuteres noen mulige måter vår implementering av RSA kan forbedres. 23

25 Forbedret ytelse Arbeidet som er gjort med implementeringen har i hovedsak vært fokusert på funksjonalitet og at det er i overensstemmelse med de gjeldende standarder. Det er derfor mulig å få til en signifikant ytelses forbedring ved å gjøre nærmere analyser av koden. Chinese Remainder Theorem (CRT) (se Kapittel 3.4 på side 14 og Kapittel 3.2 på side 9) kan benyttes for å raskere utføre dekryptering og signering. Ved å ta vare på svarene til enkelte mellomregninger i nøkkel genereringen er det mulig å bruke noen snarveier slik at beregningene blir raskere. I tillegg til å implementere CRT så er det mulig å få ytterligere forbedringer i ytelsen ved å analysere koden nærmere med et kode profiler program. Det er også mulig å optimalisere deler av de grunnleggende tall operasjonene i BigInteger klassen. Dette gjelder spesielt de operasjonene som brukes mest av vår RSA implementering. Nøkkel utveksling Slik som implementeringen av RSA er nå så mangler vi en mekanisme for å utveksle nøkler på en sikker måte. Det hadde derfor vært en fordel å få implementert en slik mekanisme slik at implementeringen kan tas i bruk i flere praktiske situasjoner. 24

26 Bibliografi [1] W. Stallings. Cryptography and Network Security. Pearson Education, 4. utgave, ISBN [2] RFC-Editor. [3] Google. [4] Wikipedia, the free encyclopedia. [5] C. K. Tan. C# BigInteger Class. csharp/biginteger.asp. [6] B. Harris. RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol. RFC 4432 (Standards Track), Mars URL [7] T. Ylonen og C. Lonvick. The Secure Shell (SSH) Transport Layer Protocol. RFC 4253 (Standards Track), Januar URL http: // [8] R. Rivest, A. Shamir og L. Adleman. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM, 21(2): , Februar [9] J. Jonsson og B. Kaliski. Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1. RFC 3447 (Informational), Februar URL rfc3447.txt. [10] F. Yergeau. UTF-8, a transformation format of ISO RFC 3629 (Standards Track), November URL rfc3629.txt. [11] A. Young. Mitigating Insider Threats to RSA Key Generation. RSA Laboratories Cryptobytes, 7(1):1 15, URL Cryptobytes.pdf. 25

27 [12] M. J. Wiener. Cryptanalysis of short RSA secret exponents. IEEE Transactions on Information Theory, 36(3): , URL MichaelPapers/ShortSecretExponents.pdf. [13] M. Bellare og P. Rogaway. Optimal asymmetric encryption. Advances in Cryptology - Eurocrypt 94, 950(1):92 111, [14] D. Johnson og S. Matyas. Asymmetric encryption: Evolution and enhancements. RSA Laboratories Cryptobytes, 2(1), URL ftp: //ftp.rsasecurity.com/pub/cryptobytes/crypto2n1.pdf. [15] E. Fujisaki, T. Okamoto, D. Pointcheval og J. Stern. RSA-OAEP Is Still Alive!, November URL [16] M. Bellare og P. Rogaway. PSS: Provably Secure Encoding Method for Digital Signatures, August URL groups/1363/p1363a/contributions/pss-submission.pdf. [17] J. Coron. Security of PSS for Short Random Size, Juli