SIE 50AB

1. SIE 50AB Non - repudiation

2. 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)

3. 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)

4. 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.

5. 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.

6. Symmetriske mekanismer • ISO/IEC 13888 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.

7. 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. • fEOO og fEOR flagg som indikerer type bevis generert av TTP. • EOO: Evidence of Origin. EOO=SENVx(z), hvor z=fEOO,A,B, H(M). • EOR: Evidence of receipt. EOR=SENVx(z), hvor z=fEOO,A,B, H(M). • PON: TTP’s verifisering av EOO og EOR (positive or negative).

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

9. 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.

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

11. 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.

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

13. 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).

14. 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 = SA(fPOE, B, H(M) • ACP – Acknowledgment = SA(fACP, B, H(M) • FX: Flagg

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

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

17. 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,Tg,T1,M, sSA(A,B, Tg,T1,M) • Påført av autoritet: • 1. A => TSA: EOO • 2. TSA => A: T1, sSTSA(EOO, T1) • Beviser kun at meldingen er sendt ETTER T1. • MEN: Dersom B godtar T1, kan ikke A fornekte at M er sendt på T1.

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