Obligatorisk oppgave 2 INF-2310 < Sikkerhet i distribuerte systemer > 15. oktober 2003 Obs! Denne rapporten forutsetter kjennskap til medlagte JavaDoc informasjon. Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no
Problemstilling: Implementere en nettverksprotokoll som gjør både hemmelighold og etterlater seg bevis i form av signaturer. Dette innebærer bruk av JCE til kryptografisk hash, signering og kryptering med RSAnøkler. Angrepsvinkel: Ved starten av oppgaven har man to distinkte verktøy til rådighet - filen ProtocolBase.java og testprogrammet simplemsg.java som benytter seg av denne. Det vil si at vi har en fungerende protokoll og et testprogram som benytter seg av denne protokollen. I vår objektorienterte verden har det, forutsatt en rimelig kvalitetsstandard selvsagt, ingen formål å ikke benytte seg av ferdigutviklede elementer. Løsningsmetode: For å benytte seg av funksjonalitet som allerede er implementert i ProtocolBase, arves det fra denne klasse. Funksjoner som er relevant for oss er sendmessage( ) og revievemessage( ), og disse overstyres for å passe oppgaven. Målet er altså at ett program som allerede benytter seg av den allerede eksisterende protokollen skal kunne bruke vår nye sikre protokoll med mindre eller ingen modifikasjoner. Forutsetter at utveksling av offentlige nøkler foregår separat fra vår protokoll, og ved bruk forutsettes det at nøkler allerede er distribuert. Likevel manglende nøkler burde detekteres og resultere i en Exception. Implementasjon: Oppretter en ny klasse kalt SecureProtocol som arver i fra klassen ProtocolBase. I denne nye klassen overstyrer vi funksjonene sendmessage( ) og revievemessage( ), og i starten lar dem gjøre lite annet enn å kalle opp de tilsvarende funksjonene i superklassen. Resultatet er at vi nå har en fungerende nettverksprotokoll, om enn bare ett skall uten den funksjonaliteten vi var ute, men det kommer etter hvert. Testprogrammet simplemsg endres til å arve ifra den nye sikre protokollen og en testkjøring bekrefter at alt fungerer slik det skal gjøre. Ett rask overblikk på oppgaven viser en datastruktur bestående av en indre og en ytre beskjed. Den ytre beskjeden er brukt under overføring, mens den indre inneholder data relatert og inkludert det som overføres. Figur: M Y = A, B, {K I }K B, IV, {M I }K I MI (beskjed) = A, B, I, TA, XA, σka-1 MI (kvittering)= A, B, K, TA, H(XA), σka-1 Hvor: M Y A B K I {}K B IV M I {}K I I T A X A σk -1 A = Ytre beskjed, brukt under overføring = Senders identifikator = Mottakers identifikator = Tilfeldig generert IDEA nøkkel = Kryptert med mottakers offentlig nøkkel ved bruk av RSA = Tilfeldig generert initialiseringsvektor, for bruk med IDEA = Indre beskjed, brukt til å holde data = Kryptert med generert IDEA nøkkel = Innleveringsidentifikator = Tidsstempel = Data som skal overføres = RSA signatur generert på basis av overført data
H( ) = Kryptografisk hash Generelt sett en simpel sak, men vi har tre manglende elementer for å kunne fullføre oppgaven, nemlig funksjonalitet for kryptering og signering ved bruk av RSA algoritmen samt kryptografisk hash. RSA: RSA er en kryptografisk algoritme for bruk i relasjon til offentlig-nøkkel kryptering. Den er i stand til å både kryptere og dekryptere data, men er generelt sett lite brukt ettersom lengden av dataen som skal krypteres må være mindre enn nøkkelstørrelse. Nøkkellengden kan varieres, men på grunn av ueffektivitet brukes denne algoritmen svært sjelden sett bort fra ett distinkt område: overføring av krypteringsnøkler. Grunnen til at vi kan bruke RSA til overføring av nøkler er ikke bare på grunn av at til dags dato foreligger det ingen metoder for å knekke nøklene, men at ved bruk av offentlige og private nøkler er det mulig å kontrollere hvem som skal kunne dekryptere dataen. Dette vil i så fall si at Kari kan hente ned Olas offentlige nøkkel fra for eksempel Olas hjemmeside og bruke denne til å kryptere en hemmelig sesjonsnøkkel. En del av offentlig nøkkel kryptografi tilsier at data dermed krypteres med en offentlig nøkkel alle har tilgang på, men en hemmeligholdt privat nøkkel kun kan dekryptere nevnte data. Dette vil si at Kari, selv om hun krypterte dataen ikke kan dekryptere den dette er noe kun Ola kan gjøre. I implementasjonen brukes RSA algoritmen i EBC modus med PKCS#1 padding. Electronic Code Book (EBC): EBC modus er en av de enkleste cipher-modusene, og samtidig en veldig usikker modus dersom brukt kun i seg selv. Modusen tar 64-bit blokker som inndata, padder ut den siste til en full blokk. Hver blokk blir kryptert med en hemmelig nøkkel. Ettersom modusen opererer kun på blokker av data vil samme data gi samme resultat, og dermed vil to påfølgende identiske blokker gi den samme ciphertekst. Dette vil si at en kan tilegne seg informasjon ved å se på repeterende blokker ciphertekst, samt at ettersom blokkene er uavhengige kan de dermed stokkes om. Public-Key Cryptography Standard (PKCS): Et sett av standarder, PKCS#1-15, laget for å definere standarder for hvordan en beskjed skal formateres før kryptering med f.eks. RSA. PKCS#n standardene er konstruert med hensyn på å stoppe flere sikkerhetstrusler mot RSA, og dermed forhindre brukerfeil som lett kunne uheldige kombinasjoner som kan gjøre krypteringen mindre sikrere. PKCS#1, som brukes her definerer følgende anbefalte standard for formatering: minst 8 tilfeldig genererte Data 0 2 0 oktetter ikke lik null (lengde < nøkkelstørrelse) Kryptering med RSA: For å kryptere med RSA har jeg laget en slags wrapperklasse for å rydde opp i det obskure utseendet til JCE og lette lesning og forståelse av protokoll-implementasjonen. Denne klassen har jeg kalt RSA_Crypto og fungerer de funksjoner en kan forvente. Ettersom denne klassen wrapper rundt JCE burde ikke unntakshåndtering være ett problem og er mer eller mindre neglisjert ettersom det er forventet at sikkerhetsprotokollen ikke leverer fra seg misformet eller ukorrekt data. En del feil vil oppstå dersom Cryptix ikke er installert, eller ikke satt opp rett. Det endelige UML diagrammet for klassen er vist til høyre. Funksjonaliteten er som antydet veldig begrenset og nærmest basisk. Funksjonen encrypt( )
operer med og krever den offentlige delen av ett nøkkelpar, mens decrypt( ) trenger den private delen av nevnte nøkkelpar. Begge funksjonene returnerer null dersom en feil oppsto i funksjonskallet, i tillegg til at stack-trace skrives til skjermen. Klassen kan eksekveres for å teste dens funksjonalitet, og samtidig bekrefte at Cryptix fungerer. Ved bruk av JCE refereres beskrevne funksjon under algoritmenavnet RSA/ECB/PKCS#1. Signering med RSA: I likhet med kryptering er det opprettet en wrapperklasse, med navn RSA_Signature, for signering og verifisering av Signatur ved bruk av JCE. Denne signerer ved bruk av RSA, eller det vil si mer nøyaktig en signatur i form av en MD5 hash med RSA kryptering. I forhold til JCE spesifikt gir dette algoritmenavnet MD5withRSA. PKCS#1, som brukes her definerer følgende anbefalte standard for formatering: minst 8 oktetter ASN.1 formatert hashtype 0 1 0 med verdi ff 16 identifikator og selve hashen. Hvor av ASN.1 står for Abstract Syntax Notation 1, og er ett system for å beskrive data i dette tilfelle beskrive hvilken type hashfunksjon som genererte den medfølgende hashen. MD5: RSA_Signature klassen støtter kun de to funksjonene lag signatur og verifiser signatur. Ettersom mengden av data som oftest er for stor til å effektivt å kunne benytte seg av RSA direkte lages signaturen isteden med basis i en MD5 hash av denne dataen. Dette gir ett marginalt tap i sikkerhet, men enormt mye i form av potensiell økt effektivitet jevnt over (Mer om MD5 i neste punkt). UML diagrammet til høyre oppsummerer klassens funksjonalitet. I likhet med RSA_ Crypto blir lite unntakshåndtering gjennomført, men så lenge Cryptix er installert og fungerer så burde det ikke oppstå noen uventede bieffekter. I tilfelle feil returnerer verify alltid verdien false, og sign returnerer null. Oppgaven krever en eller annen form for kryptografisk hash, og den mest brukte for tiden er uten tvil og MD4 og MD5. Valget falt på den nyere MD5 hashing funksjonen ettersom den er mindre fokusert på hastighet, men heller sikkerhet i forhold til MD4. Kryptografisk hash er definert som en enveis funksjon, ettersom det skal være vanskelig eller upraktisk å beregne hvilken inndata produserte forskjellige datahasher. For at denne skal være kryptografisk sikker, kreves det at det er i all praktisk sans umulig å finne to forskjellige inndata som produserer samme hash til tross for at det kanskje er en teoretisk mulighet for dette. Med dette i tankene kan vi benytte oss av denne egenskapen til å oppdage dersom data er forandret, på basis av en kryptografisk hash av gammel og ny data, og det er her vårt behov kommer inn: En kryptografisk hash av sendt data signeres og kan verifiseres. Med fornevnte egenskap kan vi oppdage dersom den mottatte data er endret ifra den som ble sendt, ettersom det ikke bare er praktisk vanskelig å endre data på en måte at den gir samme
kryptografisk hashverdi, men bortimot teoretisk umulig å samtidig kunne gjøre dette på en måte som gir noen spesiell mening eller format hos mottaker. MD5 fungerer svært likt MD4. Den produserte hashverdien er en 128 bit sekvens produsert på bakgrunn av gitt data, i blokker á 512 bit. For hvert steg i prosesseringen tas verdien av hashen og modifiseres ved bruk av neste datablokk. Hvert steg foretas fire ganger for hver 128bit del av datablokken som prosesseres. MD5 til forskjell fra MD4 bruker en varierende konstant for hver av de fire gjennomgangene i hver av de fire stegene. Implementasjon av hash funksjonen er gjort i all enkelhet, og som UML diagrammet (diagram nedenfor) støtter lite eller ingenting utover JCE funksjonalitet, men tjener mer som en lettforståelig sak på ett generelt nivå. MD5 brukes implisitt ved signering og kryptering, men mer direkte ved generering av ett fingeravtrykk for overført data til bruk i kvitteringer returnert til avsender som bekreftelse. Denne implementasjon er ment å være generell for de hash funksjonene som er støttet originalt og gjennom Cryptix. Ved bruk av argumentløs konstruktør benyttes MD5 som standard. Dersom hash funksjonene feiler returneres verdien null, men burde ikke forekomme ettersom feil burde vært fanget opp eller resultert i en Exception ved initiering av en instans av denne klassen. Sikker nettverksprotokoll: Implementasjonen, se filen SecureProtocol.java, legger til sikker overføring på allerede eksisterende funksjonalitet i klassen ProtocolBase. For å unngå å reimplementere ting arves det fra denne klassen, og som under punktet løsningsmetode arves det fra ProtocolBase og de mest sentrale funksjonene recievemessage( ) og sendmessage( ) overstyres for å gi plass til ønsket funksjonalitet (Endelig resultat ser ikke slik ut, men kommer til det etter hvert). Sende data: Starter med funksjonen sendmessage( ), og har nå ett definert behov for å legge på bygge opp indre (inneholder dataen som skal sendes) og ytre beskjed i henhold til definert sikkerhetsprotokoll (se oppstilling i begynnelsen av punktet implementasjon). For å kunne gjøre dette atskilt fra sendmessage( ) funksjonen etter opprettelsen av en gyldig melding naturlig nok er behøvd i flere sammenhenger defineres en ny funksjon encodemessage( ). Sette sammen gyldig beskjed (encodemessage( )): Starter med forhåndsarbeidet med å sette opp og generere de datastrukturerer som behøves videre i funksjonen. Det vil si: Generer tilfeldig IDEA nøkkel og initialiseringsvektor. Hent offentlig nøkkel til mottaker fra det offentlig-nøkkel biblioteket vi har til rådighet.
På grunn av en intern avhengighet mellom indre og ytre beskjed må den indre beskjeden, som etter hvert vil utgjøre ett enkelt datum i den ytre beskjeden, være ferdig sammensatt. Sammensetting av den indre beskjeden gjøres helt enkelt ved å følge oppstillingen av protokollstrukturen sekvensielt og legge dem til en etter en. Legger først til vår egen identifikator fulgt av mottakers identifikator. Neste datum som legges til er den såkalte innleveringsiden tifikator fulgt av et tidsstemple formatert ved bruk av SimpleDateFormat tilbydd av pakken java.text. Neste datum varierer på bakgrunn av innleveringsidentifikator: I (ny beskjed) = X A K (kvittering) = H(X A ) Siste element av den indre beskjeden som skal legges til består av en signatur laget på basis av nåværende indre beskjed, dvs. før signaturen legges til. Sammensetning av den ytre beskjeden, kan nå gjøres da ett av dens elementer ikke lenger avhenger av data som ikke er ferdig sammensatt ennå. Starter med å først legge til vår egen identifikator fulgt av mottakers identifikator. Som neste datum legges til den tilfeldig genererte IDEA nøkkelen, kryptert ved hjelp av RSA og fulgt som neste datum den medfølgende genererte initialiseringsvektoren. Som siste datum i den ytre beskjeden legges til den indre beskjeden kryptert med nevnte IDEA nøkkel og initialiseringsvektor. Etter at funksjonen vår har satt sammen dataen i henhold til spesifikasjon er meldingen klar til å transporteres, noe som utføres med ett enkelt kall til tilsvarende funksjon i superklassen. Ettersom vi nå har funksjonalitet for å sende data sikkert over ett usikkert medium, men som en følge av dette tillegget som potensielt kan kaste ett NoSuchPublicKeyException stemmer ikke definisjonen av denne funksjonen direkte overens med funksjonen den overstyrer. For å løse dette endres funksjonens navn til s_sendmessage. Dette stemmer ikke helt overens med målet om minimale endringer i eksisterende i eksisterende programmer som allerede benytter seg av ProtocolBase. Løsningen er like enkel som den er kortfattet, men vi kommer tilbake til dette punktet på ett senere tidspunkt. Mottak av data: Grunnlaget for denne funksjonen ligger i den allerede implementerte funksjonen tilbydd av superklassen, nemlig recievemessage( ) og første steg er at vi benytter oss av denne funksjonen og får ut den informasjonen som ble sendt (dvs. den ferdig krypterte meldingen). Å baklengs gjenta hvert steg i denne teksten er overdokumentering og drøfter fremover kun de mer interessante delene av den. Dekryptere overført data (decodemessage( )): Helt i starten sjekkes det opp mot forventet antall elementer for å sjekke at meldingen
ikke er korrupt eller misformet på noen måte. Kaster en CorruptedMessageException dersom den finner noe galt på dette tidspunkt. Den ytre delen av beskjeden inneholder den informasjon vi trenger til å dekryptere den indre beskjeden. IDEA nøkkelen er kryptert ved hjelp av RSA, og vi benytter oss av en instans av klasse RSA_Crypto til å dekryptere denne. Hvis dekrypteringen feiler kastes en CorruptedMessageException med beskjed om dette. Nå er vi klar til å dekryptere den indre beskjeden og CryptoEngine implementert i forrige obligatoriske oppgave tar seg av denne biten uten problemer. På dette tidspunktet har vi den data vi er ute etter, men uten å verifisere den mottatte dataen mot den medfølgende signaturen kan vi ikke verifisere at den er autentisk. Dersom noen har prøvd å endre på data, senders identifikator, eller signaturen vil denne sjekken oppdage dette og en SignatureException kastes med beskjed om mulig forfalskning. Som nevnt krever dette også senders identifikator og i likhet med encodemessage( ) kastes en NoSuchPublicKeyException dersom vi ikke har tilgang på den tilsvarende offentlige nøkkelen. Hvis mottatt data overlever alle disse sjekkpunktene og ingen Exception kastes vet vi at den mottatte dataen er autentisk og vi har autentisert at den som sendte dataen også er den person /datamaskin som sitter med den private delen av nøkkelen. Ettersom recievemessage( ) trenger mer informasjon enn bare den overførte dataen, men også innleveringsidentifikator osv. returneres denne. Likevel vet vi at dataen autentisk og vi kan med sikkerhet gjøre dette. Med basis av at det er kun en type innleveringsidentifikator som er interessant for programmer som bruker protokollen, nemlig beskjedene med identifikatoren I. Dersom vi finner identifikatoren K, har vi mottatt en kvittering som det foretas noen få prosesseringer på. For å filtrere disse to typene identifikatorerer leses beskjedene inn i en løkke frem til vi har funnet en melding som er passende for å returneres. Hvis vi mottar en melding med identifikatoren I sendes en kvittering tilbake til avsenderen for å bekrefte mottaket, noe som funksjonene s_ sendreciept( ) tar seg av. I likhet med det vi gjorde med vår implementerte sendmessage( ) endrer vi navnet på denne funksjonen fra recievemessage( ) til s_recievemessage( ). Håndtering av kvitteringer: Så langt har den implementerte protokollen ikke foretatt noen håndtering av kvitteringer på sendt data annen enn å dumpe en beskrivelse til debug. Minimum for en oppgave av denne typen er å bekrefte at kvitteringer stemmer overens med sendt data. Ettersom protokollen skal antas å kunne kommunisere med andre implementasjoner basert på samme definisjon kan en ikke forvente at til ethvert tidspunkt er neste mottatte melding en kvittering på forrige utsendte melding. Grunnen til dette kan være at en for eksempel hardt belastet mottaker heller velger å utsette utsending av kvitteringer til etter at belastningen har avtatt, noe som kan være gjort ettersom Internett-trafikk i praksis er belastningsmessig kraftig varierende bursty. Tatt dette i betraktning falt valget på å implementere en helt elementær beskjedloggingsfunksjon. Denne funksjonen skal ha to elementære funksjoner: Oppbevare data i påvente bekreftelse på at den er bekreftet mottatt av mottaker. Ta imot kvitteringer og verifisere mot allerede sendt data.
Loggen fungerer på en slik måte at hvert loggelement som blir lagt til inneholder all informasjon som skal til for å reprodusere beskjeden som ble sendt samt en kryptografisk hash som brukes til å identifisere dette eksakte loggelementet. Mottatte kvitteringer inneholder en kryptografisk hash som skal stemme overens med ett av loggelementene. Hva som skjer med det aktuelle elementet som korresponderer til oppgitte hash avhenger av verdien til delete_policy internt i MessageLog objektet, men nærmere forklaring av det punktet overlates til medhørende JavaDoc. Dersom mottatt kvittering ikke stemmer overens med sendt data kastes en MessageLogException med en mer beskrivende beskjed. Avhengende av delete_policy kan det forekomme at en mottar kvittering for data som allerede er kvittert for, og i så fall resulterer dette i en kastet MessageConfirme dexception. Bakoverkompatibilitet: Som tidligere nevnt var det ikke mulig å overstyre funksjonene fra ProtocolBase direkte ettersom våre funksjoner kan kaste flere unntak ( Exception ), og dermed stemmer definisjonene ikke lenger overens. Løsningen er å opprette en ny klasse kalt SimpleSecureProtocol som arver fra SecureProtocol, men overstyrer nevnte funksjoner og tar imot eventuelle unntak. En effekt av dette er at programmer som originalt benytter seg av ProtocolBase ikke trenger å endres mer enn innlesning av nøkkelbiblioteker og å settes til å bruke/ arve fra SimpleSecureProtocol. Nye programmer som skal benytte seg av protokollen kan dermed som effekt av dette foreta unntakshåndtering på en mer profesjonell måte eller bare satse på at ingenting uforutsett skjer. Ett eksempel på program som benytter seg av SimpleSecureProtocol, og dermed også tester ut all implementert funksjon SecureProtocol er å finne i det vedlagte eksempelprogrammet simplemsg. Evaluering: Vedlagte program, ProtocolTest, tester implementasjonen mot test data for å sjekke at beskjeder dekodes korrekt, samt at feil oppdages. For å teste at implementert funksjonalitet fungerer slik den skal kan programmet simplemsg kjøres. Med lette modifikasjoner fungerer sikkerhetsdelen av protokollen sømløst uten at programmereren eller brukeren trenger å vite noe om det, bare høste fordelene av sikker overføring. Alt i alt burde dette regnes som en suksessfull implementasjon.
Filoversikt: Her følger en oversikt over medfølgende filer med forklaring i henhold til oppgave relasjon dersom dette er nødvendig. Egenproduksjon, og eller modifiserte versjoner av filer gitt sammen med oppgaven: CryptoEngine.java Min egen IDEA/CBC/PKCS#5 implementasjon fra obligatorisk oppgave 1 med mindre modifikasjoner for å legge til bruk av SecureRandom. Hash.java MakeKeys.java MessageLog.java MessageLogTest.java ProtocolTest.java RSA_Crypto.java RSA_Signature.java SecureProtocol.java Wrapper klasse som letter bruk av kryptografisk hash ved bruk av JCE. Applikasjon brukt til å legge til nye offentlige/private nøkkelpar i nøkkelbibliotekene i vedlagte testdata filer. Enkel implementasjon av en beskjedlogg for oppbevaring av informasjon sendt og synking mot mottatte kvitteringer. Tester funksjonalitet gitt av MessageLog.java. Tester SecureProtocol implementasjon mot testdata. Wrapper klasse som letter kryptering og dekryptering av data med RSA algoritmen og JCE. Wrapper klasse som letter signering og verifisering av data med RSA algoritmen. Bruker JCE til generell funksjonalitet. Hovedimplementasjonen av oppgaven. simplemsg.java Testprogram omtalt i rapporten for uttesting av protokollimplementasjon. Viser bruk av SimpleSecureProtocol, og dermed også superklassen SecureProtocol. SimpleSecureProtocol.java Enklere implementasjon som overstyrer funksjon i ProtocolBase og erstatter dem med funksjonalitet funnet i SecureProtocol. Filer gitt av oppgaven: Message.java ProtocolBase.java Testdata: public-keys.store private_keys/ Klasse brukt til å sette sammen meldinger/beskjeder. Implementasjon av generell nettverksprotokoll. Bibliotek for oppbevaring av offentlige nøkkel. Katalog som inneholder brukte offentlig/private nøkkelpar.