SIE 50AB Non - repudiation

Introduksjon Non – repudiation referer til bruken av digitale signaturer for å løse uoverensstemmelser. ISO/IEC definerer 4 tjenester: –Non-repudiation of origin (NRO) –Non-repudiation of delivery (NRD) –Non-repudiation of submission (NRS) –Non-repudiation of transport (NRT)

Non-repudiation services Non-repudiation of origin (NRO) –Er ment å forhindre at opphavsmannen til meldingen kan nekte for å ha laget og sendt meldingen. Non-repudiation of delivery (NRD) –Er ment å forhindre at mottaker av meldingen kan nekte for å ha mottatt meldingen. (Erstattes av NRR – non rep. of recipient) Non-repudiation of submission (NRS) –Er ment for å skaffe bevis for at en nettoperatør har akseptert meldingen for oversendelse. Non-repudiation of transport (NRT) –Er ment for å skaffe bevis for at nettoperatøren har levert meldingen til påtenkt mottaker. (Erstattes av NRR)

Non-repudiation parameters Alle non-repudiation tjenestene inneholder stort sett de samme parametrene (token). Her er oversikten av hvilke parametre som bør være med: –En beskrivelse av hva parametrene skal bevise. –Identifikasjon av sender. –Identifikasjon av påtenkt(e) mottaker(e). –Identifikasjon av den som har generert parametrene (vanligvis sender). –Dato og tid for når parametrene ble generert. –Dato og tid for når meldingen ble sendt. –Beskrivelse av signaturmekanismen inkludert hash-funksjon. –Hash verdien av meldingen.

Non-repudiation parameters Vi trenger et sikkert tidsstempel. Dette betinger at vi må ha en 3.part. Tidsstempel parametre: –Hva slags non-repudiation policy benyttes. –Dato og tid for når tidsstempelet ble generert. –Beskrivelse av signaturmekanismen. –Hash verdi av meldingen som skal tidsstemples.

Symmetriske mekanismer ISO/IEC part 2 inneholder 3 mekanismer som tilbyr NRO og NRR. M1: –Tilbyr NRO (Non-repudiation of Origin) og NRR (Non- repudiation of Recipient). –Online TTP genererer og verifiserer bevis på forespørsel av enten sender eller mottaker. –Melding og bevis blir utvekslet direkte mellom sender og mottaker.

Teknikk M1, M2, M3 A: sender av melding B: mottaker TTP: tiltrodd 3. Part a: hemmelig nøkkel kjent av A og TTP. b: hemmelig nøkkel kjent av B og TTP. x: hemmelig nøkkel kjent kun av TTP. M: Melding som blir sendt fra A til B. f EOO og f EOR flagg som indikerer type bevis generert av TTP. EOO: Evidence of Origin. EOO=SENVx(z), hvor z=f EOO,A,B, H(M). EOR: Evidence of receipt. EOR=SENVx(z), hvor z=f EOO,A,B, H(M). PON: TTP’s verifisering av EOO og EOR (positive or negative).

A B TTP 1. SENVa(z) 2. SENVa(EOO) 3. M, EOO 4. SENVb (EOO) 5. SENVb(PON, EOO, EOR) 6. EOR 7. SENVa (EOR) M1: Mandatory NRO, optional NRR 8. SENVa (PON, EOR)

Symmetriske mekanismer M2: –Tilbyr NRO (Non-repudiation of Origin), men her er NRR (Non- repudiation of Recipient) også obligatorisk. –Online TTP genererer og verifiserer bevis på forespørsel fra enten sender eller mottaker. –Melding blir utvekslet direkte mellom sender og mottaker. –Beviset blir sendt direkte fra TTP til A istedenfor å gå via B.

M2: Mandatory NRO and NRR A B TTP 1. SENVa(z) 2. SENVa(EOO) 3. M, EOO 4. SENVb (EOO) 5. SENVb(PON, EOO, EOR) 6. SENVa (EOR)

Symmetriske mekanismer M3: –Tilbyr NRO (Non-repudiation of Origin), men her er NRR (Non- repudiation of Recipient) også obligatorisk. –Inline TTP genererer og verifiserer bevis på forespørsel fra enten sender eller mottaker. –Melding blir ikke utvekslet direkte mellom sender og mottaker, men sendes via TTP. –Beviset blir sendt direkte fra TTP til A etter å ha mottatt EOO fra B.

M3: Mandatory NRO and NRR with intermediary TTP A B TTP 1. M, SENVa(z) 2. SENVa(EOO) 6. SENVa (EOR) 5. SENVb(PON, EOO, EOR) 3. M, EOO 4. SENVb (EOO)

Sammenligning M1, M2 og M3 M1: –Egner seg for situasjoner der sender (originator) ikke forventer eller ønsker bekreftelse på at meldingen er mottatt (kutter ut pkt 6,7 og 8). M2: –Her er NRR obligatorisk og egner seg dermed til situasjoner der sender ønsker bekreftelse (selv om det kan unngås ifra mottakers side). M3 : –Samme som M2. Eneste forskjellen er at TTP blir et mellomledd for all kommunikasjon (uten at dette gir noen umiddelbare fordeler).

Asymmetriske mekanismer ISO standarden definerer også 2 ulike mekanismer for non- repudiation uten bruk av TTP. –M-h: Mandatory NRO and NRR using hash function. –M-e: Mandatory NRO and NRR using encryption. Parametre som brukes: –A: sender av melding –B: mottaker av melding –M: melding –POE – Promise Of Exchange = S A (f POE, B, H(M) –ACP – Acknowledgment = S A (f ACP, B, H(M) –F X : Flagg

A B M-h: Mandatory NRO and NRR using hash function 1. f POE, B, H(M), POE 2. f ACP, A, ACP 3. f EOO, B,M, EOO 4. f EOR, A, EOR

M-e: Mandatory NRO and NRR using encryption A B 1. f POE, B, eK(M), POE 2. f ACP, A, ACP 3. f EOO, B, K, EOO 4. f EOR, A, EOR

Time-Stamping Evidence - Vise når bevisene er laget og sendt, brukes i bevisførsel. - Problematisk når ’stempelet’ blir påført av avsender/ mottaker og ikke en autoritet. (ubrukelig) EOO = A,B,T g,T 1,M, s S A (A,B, T g,T 1,M) -Påført av autoritet: 1. A => TSA: EOO 2. TSA => A: T 1, s S TSA (EOO, T 1 ) Beviser kun at meldingen er sendt ETTER T 1. MEN: Dersom B godtar T 1, kan ikke A fornekte at M er sendt på T 1.

-Dersom signaturen til A blir avslørt etter T g, er det ikke noe problem for en tredjepart å etterligne EOO ved å legge til et gyldig/passende stempel. Derfor bør T g genereres av en autoritet. EOO = A,B,M, s S A (A,B,M) EOO 1 = EOO, T g, s S TSA (EOO, T g ) -Etter min mening en dårlig løsning, forskyver kun problemet.