Introduksjon I tillegg til autentisering, bør/skal også ein sikker kanal tilby garanti for meldings- integritet og konfidensialitet

Integritet Meldingar skal vera beskytta mot modifisering

Konfidensialitet Meldingar skal ikkje kunna bli fanga opp og lese av inntrengarar Kan lett etablerast ved å kryptera ei melding før ho blir sendt Integritet er meir komplisert

Digitale signaturar 1 Eksempel: Alice og Bob utfører ein handel ved bruk av mail

Digitale signaturar 2 Kva med integritet i dette tilfellet? Alice må vera sikker på at Bob ikkje endrar prisen på 500 kroner, nevnt i meldinga, til noko større, for så at han seinare påstår at ho tilbaud han meir pengar Bob må vera sikker på at Alice ikkje kan nekta på at ho har sendt meldinga

Digitale signaturar 3 Dei to punkta kan handterast dersom Alice digitalt signerar meldinga, slik at signaturen hennar er unikt knytta til innhaldet Ein populær måte å gjera dette på er å bruka eit ”public key” krypteringssystem som til dømes RSA Då kan ikkje Alice seinare nekta på at ho lovde Bob 500 kroner for...

RSA Alice krypterar meldinga med sin private nøkkel Ka- (sikrar integritet) Om Alice også vil halda innhaldet hemmelig nyttar ho Bob sin offentlege nøkkel Kb+ (sikrar konfidensialitet) Bob dekrypterar først med sin private nøkkel Kb- og så Alice sin offentlege nøkkel Ka+ Samanliknar signert versjon av m med m Bevist at meldinga berre kan vera frå Alice Vidare er Alice sikra mot at Bob modifiserar prisen gitt i m, for ei modifisert melding vil ikkje vera signert av Alice

Problem Alice sin signatur vil berre vera gyldig så lenge den private nøkkelen hennar er hemmeleg Alice endrar nøkkelen sin Alice krypterar heile meldinga med sin private nøkkel, dette er prosesseringsmessig veldig dyrt, og fullstendig unødvendig. Om det einaste ein vil er å knytta ein signatur til meldinga, vil bruk av ei meldingsforkorting (message digest) vera eit betre alternativ Om Alice vil ut av handelen kan ho jo påstå at nøkkelen hennar har blitt stjålet Er lurt å endra nøkkelen,men då blir jo meldinga sendt over til Bob for ingen nytte Må innføra ein sentral autoritet som held styr på ting

Message Digest Dette er ein bit-streng h med fast lengde, som har blitt berekna frå ei melding m med vilkårleg lengde, ut frå ein kryptografisk hashfunksjon H h = H(m) Dersom m er blitt endra til m` vil H(m`) vera ulik H(m)

Digital signering med ”Message Digest” Alice sender kryptert ”message digest” og meldinga m i klartekst til Bob Om konfidensialitet blir krevd må Alice i tillegg kryptera m med Bob sin Kb+ Dersom dei to H(m)’ane er like; Bob veit at m kjem frå Alice Har ikkje tatt så nøye forklaring her, sjå forrige figur Over til nytt tema

Sesjonsnøklar Etter at autentiseringsfasen er ferdig, vil dei to kommuniserande partane vanlegvis bruka ein unik delt sesjonsnøkkel for konfidensialitet Eit alternativ er å bruka dei same nøklane som blei brukt for å setta opp den sikre kanalen Mange fordeler ved å bruka alternative sesjonsnøklar Vanskelegare å avsløra nøklar som blir brukt lite Ved å etablera ulike nøklar for kvar sikker kanal får ein betre besyttelse mot såkalla ”replay attacks” (Kan også bruka sesjonsnøkkelpar) Dette er ikkje lurt (pkt 2) Sikrare å bruka autentiseringsnøkkelen så lite som mulig Kommuniserande partar er iallfall beskytta mot ra ein heil sesjon , for å verna mot ra mht meldingar frå tidligare sesjonar må ein i tillegg ha tidsstempel eller sekvensnr Hopp til nytt tema

Sikker gruppekommunikasjon 1 Går no frå to til N kommuniserande partar Korleis sikra konfidensialitet i dette tilfellet? Alt. 1: La alle partane dela ein felles hemmeleg nøkkel, men kan ein stola på alle partane ? Alt. 2: Bruk nøklar mellom par av deltakarar Problemet her blir nøkkeloverhead’en: N(N-1)/2 nøklar Alt. 3: ”Public Key” krypteringssystem der kvar deltakar har sitt eige nøkkelpar (offentleg nøkkel, privat nøkkel) Her blir antalet nøkkelpar N Pkt 3: Brukt til både kryptering og dekryptering Pkt 4: Så fort ein ser at ein part lekk info kan ein berre slutta å senda til denne parten og halda fram med å bruka nøklane sine som før

Sikker gruppekommunikasjon 2 Korleis handtera dette mht replikerte serverar? Ein brukar ventar seg eit resultat han kan stola på Alt. 1: Samla responsen gitt frå alle serverane og samanlikna Dette øydelegg mht replikasjonstransparens Alt. 2: ”Hemmeleg deling”, Reiter(1994) Går ut frå at fleire brukarar/prosessar deler ein hemmelighet, ingen veit heile hemmeligheten; dei må gå saman for å få svaret Kvar server signerar responsen sin med ei ”message digest” Ser på eit eksempel Pkt 1: pga feiltolerans og ytelse Pkt 3: om det finst eit fleirtal blant svara kan klienten stola på at dette er rett Pkt 5: tek vare på replikasjonstransparens Pkt 6: alle sender inn sitt svar

Sikker gruppekommunikasjon 3 Skal kunne tolerera 2 øydelagde/utro serverar og framleis gi rett svar ri er respons for server si Har fem serverar Sig (Si,ri) = Ki-(md(ri)) der md(ri) er server Si si ”message digest” Denne er litt komplisert