A randomized protocol for signing contracts (extended abstract)

1. A randomized protocol for signing contracts (extended abstract) S.Even, O. Goldreich, A.Lempel

2. Kontraktsignering • Hva bør eksistere? • Gyldighet – i slutten av en tilstrekkelig utførelse av protokollen skal hver part ha motpartens signatur på kontrakten • Samtidighet – Hvis Alice utfører protokollen tilstrekkelig, kan ikke Bob få Alice signatur på kontrakten uten å feste sin egen signatur til kontrakten

3. Kontraktsignering • Hva oppnås med denne protokollen • Gyldighet – ved slutten av en tilstrekkelig utførelse av protokollen kan hver part verifisere motpartens signatur på kontrakten • Tilnærmet samtidighet – Hvis Alice utfører protokollen på en riktig måte, kan hun med høy sannsynlighet i hvert steg av protokoll utførelsen beregne Bobs signatur på kontrakten med tilnærmet samme beregningsarbeid som Bob bruker på å beregne Alice signatur på kontrakten • Hva betyr dette i praksis: • Hvis Alice utfører protokollen kan ikke BOB få Alices signatur uten å gi fra seg sin egen signatur!

4. Bakgrunn • Er tidligere vist til at ingen slik protokoll eksisterer uten deltakelse fra en tredjepart (TTP) • Likevel ønskelig å ha en protokoll for å signere kontrakter uten tredjepart involvert. • Dette kan realiseres med konseptet Oblivious Transfer (OT) • OT Tidligere løst via problemet med å faktorisere store primtall • Artikkelen foreslår løsning basert på ethvert PKCS (Public Key Crypto System – her RSA)

5. Oblivious Transfer • Original definisjon av OTOT protokollen er en to-veis protokoll der Alice overfører bit b til Bob. Bob mottar bit b med sannsynlighet ½ , og Alice vet ikke hvorvidt Bob har mottatt bit b. For Alice er sannsynligheten ½ for at BOB faktisk har lest bit b. • Definisjon av OT (1-out-of-2 OT)Alice overfører to bits (b0, b1) til Bob. Bob velger hvilken bit be han ønsker å motta. Alice lærer ikke e, og bob vet ikke b1-e

6. Et eksempel.. • Alice genererer 2 public/private nøkkelpar. Hun sender de to public-nøklene til Bob. • Bob generer en symmetrisk nøkkel (f.eks DES) og krypterer denne med en av de to public-nøklene han fikk av Alice. Han sender denne krypterte nøkkelen til Alice. • Alice vet ikke hvilken av nøklene Bob brukte, så hun dekrypterer meldingen med begge sine private-nøkler. Hun sitter nå med to mulige dekrypteringer av meldingen fra Bob. Den ene vi være en kopi av Bob’s DES nøkkel, den andre bare tilfeldige bits. • Alice krypterer så melding 1 med den ene mulige dekrypteringen som DES-nøkkel, og melding 2 med en andre. Disse sender hun til Bob. • Bob prøver å dekryptere begge meldingene fra Alice. Den ene blir bare tull, som han kan kaste, den andre blir noe fornuftig (forhåpentligvis..) – som da er en av meldingene fra Alice.

7. Svakhet • Dermed har Bob en av to meldinger fra Alice, og Alice vet ikke hvilken del. Protokollen har en svakhet vet at Alice kan jukse – dersom hun krypterer den samme meldingen med de to mulige nøklene i trinn 4, så vet hun hvilken melding bob får, uten at Bob er klar over dette. • Dette kan løses ved at Alice etterpå gir fra seg sine private-nøkler til Bob, som kan verifisere at hun faktisk krypterte to forskjellige meldinger, men da kan Bob lett finne også den andre meldingen.

8. Kontraktsignering - antagelser • Antar eksistens av sikker PKCS • Antar eksistens av sikkert konvensjonelt krypteringssystem (bruker her DES) • Algoritme skal være sikker • Dvs. ikke noe raskere måte å finne nøkkel enn brute force • Hver deltaker A velger et ord Xa, og generer fra dette et krypteringspar (Public Key par) (EA, DA) • Deretter offentliggjør de to partene sine offentlige nøkler. • En part kan da signere en melding M med sin private nøkkel • Beregningstid er tilnærmet lik for begge sider

9. Kontraktsignering - Aksiomer • Bob kan gjenkjenne M. (M er f.eks en signatur på en kjent melding M’. i.e. M = DS(M’) • Hvis Alice er ærlig mottar Bob M med sannsynlighet ½. For Alice er sannsynligheten for at BOB har lest meldingen etter sending ½. • Hvis Alice prøve å jukse, kan BOB detektere det med sannsynlighet minst ½.

10. Alice generer tilfeldig et ordnet set (Xi) ni=1 av nøkler for kryptosystem F. Hun deklarerer at hvis Bob kan presentere (n-m) signerte medlemmer av settet (mi)ni=1’, er Bob forpliktet til kontrakten C. Bob handler samtidig og generer nøklene (Yi) ni=1 Alice sender settet (FXi(DA(Mi))ni=1 til Bob Bob sender settet FYi(DB(Mi)ni=1 til Alice. For j=1 til n gjør følgende Alice sender Xi til Bob via OT Bob sender Yi til Alice via OT For j = 1 til (lengden av nøklene for F) Alice sender j-te bit for hver Xi til Bob Bob sender j-te bit for hver Yi til Alice Under steg 3 bør både Alice og Bob benytte seg av juksdeteksjon mekanismen i OT. Under steg 4 kan hver side sjekke om bits som avsløres under alternerende steg matcher nøkkelen som ble avslørt under steg 3. (Etter steg 3 vil hver side gjennomsnittlig vite halvparten av den andres hemmelighet. Alice eller Bob vil avbryte protokoll umiddelbart ved detektering av forsøk på juks. Kontraktsignering (4 steg)

11. Analyse av protokollen Hvis begge parter følger protokollen på ærlig vis vil begge ha en signatur på kontrakten av motparten. Hver side vil faktisk ha alle n- signerte Mi er. P(n,m) er sannsynligheten for at X får minst (n-m) nøkler under utførelse av steg (3) av protokollen. Teorem: Sannsynlighet for at X har motpartens signatur på kontrakten før steg (4) i protokollen er mindre enn (1/2)m+1. Hvis Alice vil jukse, må hun sørge for at Bob får mindre enn (n-m) signerte Mi. Alice må da plukke m+1 Mi som Bob ikke har signaturen på. Analyse

12. Juks • Hvis Alice vil jukse, må hun sørge for at Bob får mindre enn (n-m) signerte Mi. Alice må da plukke m+1 Mi som Bob ikke har signaturen på. • Måter å gjøre dette på: • Sende ”falsk”(FXi(DA(Mi))ni=1 • Jukse i OT overføring (3) • Jukse i avsløringen av bits Xi (4). • Ikke hensiktsmessig å jukse i mer enn 1 av disse, fordi en av de to første er nok til at mottaker ikke får FXi(DA(Mi))ni=1 • Flere forsøk på juks øker sannsynlighet for å bli oppdaget

13. Risiko i protokoll • Ifølge aksiom (I) og (III) for OT, vil (1) og (2) bli detektert med sannsynlighet ½. • Ifølge aksiom (II) vil sannsynlighet for å bli tatt i steg (3) ½. • Sannsynligheten for at en av partene jukser blir da maks. (1/2)m+1 • Den samlede risiko i protokollen for partene blir da 2(1/2) m+1 = 1/2 m

14. Merknader • Viktig egenskap i protokoll: Mulighet til å beregne en signatur er omtrent den samme for begge parter. • Dette først mulig i steg (4). • * Hvis X stopper korrespondanse i steg 4, vil fordelen overfor Y være maks 1 bit pr. nøkkel. • Hvis dette vurderes som et problem kan protokollen forandres slik at kun 1 bit sendes av gangen i stedet for n-bits.

15. Eksempel • Signatur på kontrakt C fra både Alice og Bob ved hjelp av kontrakt-signerings-protokollen.

16. Kontrakt C Alice Bob • FXi(DA(Mi))ni=1 • FYi(DB(Mi))ni=1 • Lager et sett nøkler for FAlice • Lager et sett nøkler for FBob • i n steg: Xi via OT Yi via OT • Sender j-te bit for hver Xi til Bob i j steg: • Sender j-te bit for hver Yi til Alice

17. Protokoll brukes til • Kontraktsignering • 1 av 2 (mynt / kron) • E-post • Online gambling