NL9301348A

NL9301348A - Elektronisch betalingssysteem.

Info

Publication number: NL9301348A
Application number: NL9301348A
Authority: NL
Original assignee: Stefanus Alfonsus Brands
Priority date: 1993-08-02
Filing date: 1993-08-02
Publication date: 1995-03-01
Also published as: JPH09500977A; US5521980A; AU698271B2; SG49828A1; AU7709394A; CA2168658A1; EP0740872A1; NL9302103A; WO1995004417A1

Description

Elektronisch betalingssysteem

De uitvinding heeft betrekking op een elektronisch betalingssysteem, waarbij geld gerepresenteerd wordt door tupels (aantallen) getallen.

Men gaat hierbij uit van drie betrokkenen, namelijk een bank, een gebruiker en een winkel, die beiden een rekening bij de bank hebben en die elk de beschikking hebben over een elektronisch rekentuig en een geheugen in de vorm van bijvoorbeeld een computer, een personal computer of een palmtopcomputer, een smart card of, binnen een e-mail-omge-ving, een werkstation. Het zal duidelijk zijn dat het aantal gebruikers en winkels en wellicht ook het aantal banken in de praktijk groter zal zijn dan één.

In een dergelijk stelsel is het bekend, gebruik te maken van zogenaamde digitale handtekeningen. Hiertoe genereert de bank twee algoritmen of sleutels, waarvan er een openbaar gemaakt wordt. Met het andere algoritme wekt de bank een tupel (aantal) getallen op en verstrekt dit tupel aan een gebruiker ter representatie van een bedrag, waarbij - uiteraard - de bankrekening van de gebruiker voor een overeenkomstig bedrag gedebiteerd wordt.

Met het andere, openbare, algoritme kan de winkel nagaan of het tupel getallen juist is en dus of het door de bank is opgewekt. In dat geval representeert het tupel -volgens de regels van het stelsel - een bedrag, en zal de winkel het ter betaling van diensten of goederen accepteren.

Na verloop van tijd, bijvoorbeeld aan het einde van een dag, zendt de winkel het tupel getallen naar de bank, waarna de bank opnieuw het tupel controleert en bij het voldoen aan het algoritme de bankrekening van de winkel crediteert.

Een dergelijk stelsel is in dit gebied van de cryptografie algemeen bekend.

Een eerste nadeel van dit bekende stelsel is het probleem dat de vertrouwelijkheid of privacy van de transacties niet meer gewaarborgd is, omdat de bank gemakkelijk kan nagaan waar zijn rekeninghouders hun geld spenderen; de bank weet immers welke tupels aan welke gebruiker verstrekt zijn.

Een tweede probleem is, dat een gebruiker een tupel getallen meer dan één maal kan uitgeven, hetgeen door de bank, na het meer dan één maal ontvangen van hetzelfde tupel getallen, wordt bemerkt. De bank kan dan alsnog de rekening van de gebruiker debiteren en/of andere maatregelen nemen, omdat de identiteit van de misbruikmakende gebruiker bekend is; de bank weet immers aan wie het betreffende tupel is verstrekt.

Het eerste probleem kan worden opgelost door het toepassen van zogenaamde blinde digitale handtekeningen. Hierbij geeft de bank aan een gebruiker die geld wil opnemen een tupel uit de verzameling geldige tupels, waarbij de bank geen informatie heeft over welk tupel aan welke gebruiker wordt verstrekt.

Een dergelijk, met blinde digitale handtekeningen werkend stelsel is bekend uit EP-A-0 218 305 en uit EP-A-0139 313.

Deze oplossing verzwaart echter wel het tweede probleem; bij het twee maal uitgeven van eenzelfde tupel kan de bank nu niet meer nagaan aan wie zij dit tupel heeft verstrekt. Dit probleem is in principe wel oplosbaar door het verschaffen van een "on-line" verbinding tussen de winkel en de bank, doch een dergelijke verbinding is minder aantrekkelijk in verband met traagheid, kosten en dergelijke.

Het is trouwens ook mogelijk de toegang tot het rekentuig van de gebruiker zodanig te blokkeren, dat de gebruiker geen toegang meer heeft tot zijn rekentuig. Dit afgesloten regentuig zal, om het dubbele uitgeven tegen te gaan, slechts één maal eenzelfde tupel getallen naar de winkel doorlaten. Wanneer de gebruiker ditzelfde tupel voor een tweede maal wil uitgeven, wordt dit geblokkeerd. Bij een dergelijk afgeschermd rekentuig is het voor de gebruiker niet na te gaan of de informatie, waar de gebruiker zijn geld uitgeeft, wel vertrouwelijk is; het is immers denkbaar dat het rekentuig deze informatie gecodeerd doorgeeft.

Er zijn echter stelsels denkbaar, die bij het meer dan eenmaal uitgeven van eenzelfde tupel aan de bank de identiteit van de gebruiker openbaren. Hiertoe is echter interactie tussen de winkel en de gebruiker vereist.

Bij een transactie zal de gebruiker in respons op een vraag van de winkel (een getal of tupel) een antwoord in vorm van extra informatie afgeven die een deel van de identiteit van de gebruiker representeert. De winkel kan de echtheid van dit antwoord controleren. Welke vraag de winkel zal stellen valt voor de gebruiker niet te voorspellen.

De bank, die deze informatie van de winkel krijgt alvorens tot creditering van de bankrekening van de winkel over te gaan, kan hieruit nog geen enkele informatie afleiden die de privacy van de gebruiker in gevaar brengt.

Bij een volgende - illegale - transactie zal de gebruiker met overgrote waarschijnlijkheid een andere vraag krijgen, en dus een ander antwoord moeten afgeven,dat dus een ander deel van de identiteit van de gebruiker openbaart. Ook dit deel is niet voldoende om de identiteit van de gebruiker te bepalen. De bank kan echter wel - achteraf -uit twee verzamelingen van zulke vragen en antwoorden tezamen de identiteit van de gebruiker bepalen. De bank kan met beide stukken informatie de volledige identiteit van de mis-/gebruiker bepalen, en dus achteraf maatregelen nemen.

Een dergelijk stelsel is bekend uit EP-A-0 407 465.

Dit bekende stelsel is conceptueel van aard. Tot nu toe bekende implementaties ervan vergen in principe veel rekenkracht, geheugencapaciteit en zij veroorzaken veel informatieverkeer. Bovendien zijn zij inflexibel en laten zij slecht, gewenste uitbreidingen toe.

Het doel van de uitvinding is het verschaffen van een werkwijze en een stelsel dat bovengenoemde nadelen vermijdt en dat ook voor algemeen informatieverkeer geschikt is.

Dit doel wordt bereikt, doordat een stelsel voor het uitvoeren van vertrouwelijk elektronisch informatieverkeer tussen tenminste één partij van de eerste soort, tenminste één partij van de tweede soort en tenminste één partij van de derde soort, - waarbij een gebruiker van de eerste soort de informatie-eenheid van een gebruiker van de tweede soort ontvangt volgens een eerste protocol, de informatie-eenheid bij een partij van de derde soort aflevert volgens een tweede protocol en de gebruiker van de tweede soort de informatie-eenheid onderzoekt volgens een derde protocol, - waarbij het eerste protocol tenminste de volgende stappen omvat: * het verstrekken van een eerste tupel getallen door de gebruiker van de eerste soort aan de gebruiker van de tweede soort, waarbij het eerste tupel informatie omvat; * het door de gebruiker van de tweede soort versleutelen van het eerste tupel getallen; * het retourneren van het aldus verkregen tweede tupel getallen door de gebruiker van de tweede soort aan de gebruiker van de eerste soort; en * het transformeren van het tweede tupel door de gebruiker van de eerste soort tot een een handtekening van de gebruiker van de tweede soort belichamend derde tupel getallen.

Vervolgens zal de uitvinding worden toegelicht aan de hand van de volgende tekeningen, waarin voorstellen: fig. 1: Een restrectief protocol voor blinde handtekeningen; fig. 2: Een protocol voor het opnemen van een munt bij B; fig. 3: Het betalen met een munt door U bij S; fig. 4: Het opsturen van een betalingstranscript door S naar B; fig. 5: Een protocol voor het opnemen van een munt bij B met bescherming tegen framing; fig. 6: Het betalen met een munt door U bij S met bescherming tegen framing; fig. 7: Het opsturen van een betalingstranscript door S naar B met bescherming tegen framing; fig. 8: Een protocol voor het opnemen van een cheques bij B; fig. 9: Het betaling met een cheque door U bij S? fig.10: Het opsturen van een betalingstranscript door S naar B in de uitbreiding met cheques? fig.11: Het vergoed krijgen van een niet gespendeerd deel van een cheques; fig.12: Een protocol voor het openen van een rekening bij B in de vierde uitbreiding; fig.13: Een protocol voor het opnemen van een munt bij B in de vierde uitbreiding? fig.14: Het betalen met een munt door U (en 0), bij S bij de vierde uitbreiding? fig.15: Het verkrijgen van een pseudoniem bij de vijfde uitbreiding; fig.16: Een restrectief protocol voor blinde handtekeningen; fig.17: Een ander mogelijk restrectief protocol voor blinde handtekeningen?1 fig.18: Een protocol voor het opnemen van een munt bij B.

fig.19: Het betalen met een munt door U bij S? fig.20: Het opsturen van een betalingstranscript door S naar B? fig.21: Een protocol voor het opnemen van een cheques bij B; fig.22: Het betalen met een cheque door U bij S? fig.23: Het opsturen van een betalingstranscript door S naar B? fig.24: Het vergoed krijgen van het niet gespendeerde deel van een cheque; fig.25: Een protocol voor het opnemen van een munt bij B volgens een vierde uitbreiding? en fig.26: Het betalen met een munt door U (en O) bij S volgens de vierde uitbreiding.

Gedetailleerde beschrijving van twee voorkeursuitvoeringen

Alhoewel de notatie die in de figuren gebruikt is duidelijk zou moeten zijn, wordt voor de volledigheid eerst enige toelichting gegeven. De protocollen dienen van boven naar beneden gelezen te worden, en zodra er een pijl op een regel staat dient men het lezen aan de kant van de bladzijde waar de pijlpunt naar wijst, te vervolgen. De informatie boven de pijlen wordt van de ene deelnemer naar de andere gestuurd in de richting aangegeven door de pijlpunt. Indien een verificatie niet klopt, dan wordt het protocol afgebroken. Met het symbool r wordt een toekenning bedoelt, en met het symbool 6^ wordt bedoelt dat het element of de elementen aan de linkerkant van dit symbool volgens uniforme kansverdeling uit de verzameling aan de rechterkant van het symbool gekozen worden.

In de begeleidende tekst wordt met 'een toevalsgetal genereren uit een verzameling' eveneens geïmpliceerd dat dit volgens uniforme kansverdeling geschiedt. Hiervoor bestaan bekende technieken.

De diverse typen deelnemers in de protocollen worden met de volgende calligrafische letters aangeduid: V = deelnemer die de handtekening zet TZ = deelnemer die de handtekening ontvangt B - de bank in een betaalsysteem U — een rekeninghouder in een betaalsysteem S * een winkel in een betaalsysteem O = een bank-module in een betaalsysteem

In de eerste voorkeursuitvoering wordt gewerkt in een multiplicatieve groep Gq met orde q, waarbij q een priemgetal is. Hiervoor komen velerlei groepen in aanmerking. Voor de duidelijkheid is gekozen voor de ondergroep van orde q van Z*, waarbij p een priemgetal is waarvoor q een deler van p — 1 is. Desalniettemin komen bijvoorbeeld ook elliptische krommen in aanmerking. Voor de veiligheid van het systeem is noodzakelijk dat, gegegeven een aantal elementen («7i, · · · i9k)r allen ongelijk aan 1, in de groep, en een willekeurig getal A in deze groep, het ondoenlijk moet zijn om elementen (al7...,ak) te vinden zodanig dat

(Het zogenaamde Discrete Logarithme probleem doet zich in zo'n groep voor.) Zoals gezegd is hier expliciet voor een ondergroep van Z* gekozen. Alle vermenigvuldigingen en delingen betreffende elementen uit deze groep zijn derhalve modulo p. Om deze reden is gekozen om de aanduiding modp in dergelijke uitdrukkingen achterwege te laten (zo betekent g*1 dus g^modp) . Wel wordt aangegeven als er modulo q wordt gerekend (zoals bijvoorbeeld 7*1 = x\ + x2cmocL q) · Indien elementen gekozen worden uit een groep, wordt steeds het kleinste positieve element bedoeld. Zo betekent atftZq dat a op willekeurige wijze uit de verzameling {0,...,g--l} wordt gekozen, en o Z* dat a op willekeurige wijze uit de verzameling {l,...,g — 1} gekozen wordt.

Er zijn enkele voor de hand liggende modificaties in de protocollen aan te brengen. Zo wordt verondersteld dat q bekend is aan de rekeninghouders, en derhalve kunnen zij berekeningen modulo q uitvoeren. Een mogelijke variant is om te zorgen dat de groepsorde q onbekend blijft (zie: E. Brickell en K. McCurley, 'An interactive Identification scheme based on discrete logarithms and factoring', Journal of Cryptology, Vol. 5, no. 1 (1992), pages 29-39). Alle berekeningen modulo q dienen dan vervangen te worden door berekeningen modulo p— 1. Belangrijke voordelen biedt dit echter niet. Bijvoorbeeld, alhoewel bepaalde aanvallen op het systeem moeilijker worden (factorizatie gaat mee spelen), gaat de effientie omlaag. Voorts kan men de elementen #,· niet van orde q maar van orde p- 1 kiezen, aangezien Z* φ(ρ - 1) generatoren heeft. In dat geval wordt er dus in zijn geheel in Z* gewerkt. Dit heeft echter geen voordelen maar wel nadelen. Soortgelijke modificaties zijn genoegzaam bekend in de literatuur.

In de tweede voorkeursuitvoering wordt gewerkt in Z*, de multiplicatieve groep modulo n, waarbij n het produkt van twee grote, ongelijke, priemgetallen is. Het zogenaamde RSA probleem doet zich in zo'n groep voor. In tegenstelling tot de eerste voorkeursuitvoering is de groepsorde in de toepassing niet bekend aan hen die de factorizatie van n niet weten, en wordt er dus niet in de exponenten modulo de groepsorde gewerkt, maar modulo een zekere υ.

Derhalve krijgt men te maken met uitdrukkingen divv, te danken aan het feit dat voor a € Z geldt dat a — a mod v + v (a div u). Aangezien vermenigvuldigingen en delingen in Z* vanzelfsprekend modulo n zijn, wordt de aanduiding modn achterwege gelaten. Zo betekent YU1 dus y^modn. Voor andere modulo operaties wordt dit wel expliciet aangeduid (zoals bijvoorbeeld ri = xi + X2C mod v). Indien elementen gekozen worden uit een groep, wordt steeds de kleinste positieve rest bedoeld. Zo betekent a Z* dat a op willekeurige wijze uit de deelverzameling van {l,—1} bestaande uit de getallen onderling ondeelbaar met n wordt gekozen. Voor de veiligheid van het systeem wordt gebruik gemaakt van het feit dat, gegegeven een aantal elementen allen ongelijk aan 1, in de groep, en een willekeurig getal A in deze groep, het ondoenlijk is om elementen (a*,... ,α*.; α*.+1) te vinden zodanig dat

Opgemerkt zij dat de gebruikt wordt om aan te geven dat het element erachter uit Z* komt, niet uit Z„ zoals de elementen ervoor.

Er zijn enkele voor de hand liggende modificaties in de protocollen aan te brengen. Zo wordt verondersteld dat v een priemgetal is dat onderling ondeelbaar is met de orde van Z*. Men kan bepaalde aanvallen op het systeem moeilijker maken (verschuiving van RSA naar factorizatie) door v = 2v', met v' een priemgetal, te kiezen. Dit heeft daarentegen weer als nadeel dat men meer werk moet doen om te zorgen dat de bank de identiteit van een fraudeur kan bepalen. Ook kan men andere keuzes van v bedenken, bijvoorbeeld v=p'q', voor priemgetallen p',q' zodanig dat een van beide de groepsorde deelt. Dit soort modificaties zijn genoegzaam bekend in de literatuur.

Algemene omschrijving van een restrictief blinde handtekeningen protocol Het doel van een blinde handtekening is dat V getal(len) en handtekening die 72. aan het einde van het protocol kan bepalen, met geen mogelijkheid kan voorzien. Preciezer gezegd, gegeven de verzameling van alle mogelijke getallen met bijbehorende handtekening, is de kans dat ΊΖ een bepaald getal met handtekening aan het protocol heeft overgehouden uniform verdeeld over de verzameling.

Deze eis is vanzelfsprekend te verslappen door bijvoorbeeld genoegen te nemen met een iets andere kansverdeling, of slechts te eisen dat de taak om te bepalen welk getal met handtekening uit welke specifieke uitvoering van het blinde handtekeningen protocol komt, te veel rekenkracht vergt.

Voor een restrictief blinde handtekening komt daar, zoals hiervoor aangegeven, nog bij dat een bepaald wiskundige verband in de representatie die 7Z van het ongeblindeerde getal weet, behouden blijft in de representatie die 72. na afloop van het protocol van de geblindeerde informatie weet, onafhankelijk van de geheime sleutel die 72. voor het blinderen gebruikt heeft.

Een restrictief blinde handtekening protocol werkt als volgt. Aan het begin van het protocol weet U een fc-tupel (als...,ajb) (genaamd een representatie) zodat m = /ι(αι, · ·,ajfc) voor een zekere functie /i(-). Na afloop van het restrictief blinde signature protocol weet U een getal ml met een bijbehorende handtekening van B, en U kent een ί-tupel (1,...,63) (een representatie) zo dat ml = /2(61,...,61) voor een zekere functie /2(-)· Zij ^ de verzameling van alle transformaties £(771,7-1,...,7-,) (waarbij de 7-,'s willekeurige keuzen zijn) zodanig dat U na afloop van het protocol een £(771,7-1,...,7-,) met een bijbehorende handtekening weet, en een representatie van dit getal. In de restrictief blinde handtekening geldt dan dat er een functie /(·) is zodanig dat /(6 1,..., &*) = (ai,..., a*) onafhankelijk van de 7·;' s (en welke £(·) is toegepast) .

De functies /i(·) en /2(-) zullen one-way functies moeten zijn, bij voorkeur 'collision-free' .

In de eerste voorkeursuitvoering weet U bijvoorbeeld α.ι,α.2, en is m — g^jg^d. Derhalve, met /1(21,^2,23) = 9?sTd**, weet U de representatie (α!,α2,ΐ) van 771. Na transformatie weet de user (61,62,63), zo dat /2(61,62,63) = 77iJ. Een 'invariant' /(·) is

want dit levert altijd (αι,α2) op, onafhankelijk van de keuze van s.

In de tweede voorkeursuitvoering weet U ax < v, en is m = Yai. Derhalve, met fx(xi,x2) = YxlX2mo&n' weet U de representatie (di,l) van 771. Na transformatie weet de user (63.,62) zo dat /2(61,62) = 7717. Een invariant is

want dit levert altijd ax op.

1 Eerste voorkeursuitvoering 1.1 Een restrictief blinde handtekening geschikt voor de eerste voorkeursuitvoering

Allereerst wordt een restrictief blinde handtekening protocol beschreven.

Verondersteld wordt dat V een getal g £ Gq en een getal x G Zq heeft gekozen, en g en h = g* publiekelijk bekend gemaakt heeft. Het getal x is de geheime sleutel van V. De functie Ti is een 'one-way' hashfunctie, zoals bekend in het vakgebied, met als argumenten vier getallen uit Z* die op een getal in Z* worden afgebeeld.

De beschrijving van een mogelijk protocol is als volgt (zie Figuur 1):

Stap 1 7Z deelt aan V een getal m mede dat TZ

gedurende de volgende drie stappen gaat blinderen teneinde een blinde handtekening te verkrijgen.

In de voorkeursuitvoering van het betaalsysteem zelve blijft deze stap achterwege, omdat m eenmalig wordt bepaald door een van beide partijen (of in samenwerking), en vervolgens steeds opnieuw gebruikt wordt indien dezelfde TZ in het protocol betrokken is.

Stap 2 V genereert een toevalsgetal w Zgf en berekent z = mx, a = gw en b = mw. Vervolgens stuurt V de getallen z,a,b naar TZ.

Stap 3 TZ genereert vier toevalsgetallen s,t en u, v, allen element van Zq. Gebruik makend van s en t, berekent TZ de geblindeerde vorm m! van m als m' = msgt. Gebruik makend van u en vr blindeert TZ de overige getallen a, b en z als volgt (waarbij w' = uw + v mod q) : a' = augv (dit is dus gelijk aan gw')f b' = auibus{m')v (hetgeen gelijk is aan , en z' = z3hl (is gelijk aan (m/)x) . Vervolgens berekent 7Z c' = H(m', z',a', b')r en stuurt c — c'/umodq naar V.

Stap 4 V berekent r = w + cx mod q, en stuurt r naar Tl.

Tl accepteert dan en slechts dan als de gelijkheden hca = gT en zcb = mr gelden. Indien Tl accepteert, berekent hij r' = ur + v mod q. In dat geval weet Tl nu dus m', en (z1, a', b\ r'). Het viertal getallen is een digitale handtekening op m' (dus per definitie door eenieder te verifiëren). In het vervolg zal voor de duidelijkheid sign(m1) geschreven worden i.p.v. het viertal (z\ a', b', r1). Het paar m' met handtekening voldoet aan de voorwaarde van een blinde handtekening.

Indien verondersteld wordt dat Tl voordat het protocol begint, een fc-tupel (αι,van m kent, zodanig dat Π?=ι9? = en na afloop een fc-tupel .. ,6fc) van m' zodat nf=i = m'r dan zal voor elk paar bir bj gelden dat bi/bj = a{/aj mod q, op voorwaarde dat s φ 0, dat alle gS s verschillen van g, en dat Tl geen fc-tupel (ci,...,cjfe+i) (niet allen 0) kent zodat (Π{=ιffi’)PCfc+1 = 1 · Deze relatie, geïnduceerd door quotiënten te nemen (vanzelfsprekend geldt hetzelfde dan ook voor bijv. sommen van quotiënten) blijft steeds behouden, onafhankelijk van de keuze van s en t door Tl.

Opgemerkt kan worden dat Tl t— 0 zal moeten kiezen. Vanzelfsprekend geldt een soortgelijk iets indien een van de gS s gelijk is aan g (in dat geval kan dan wel tφ 0 gekozen worden).

Overigens kan Tl een blinde handtekening verkrijgen op elk getal m' dat hij wenst, door in stap in m = {m!)xl*g~it* op te sturen naar V. In het geval steeds dezelfde m gebruikt wordt, zoals aangegeven, kan dit niet zonder meer zonder onevenredig veel rekenkracht te gebruiken.

Het zij opgemerkt dat dit slechts een mogelijke uitvoering is. Bijvoorbeeld kan men zonder veel moeite een variant hiervan bedenken waarbij de verificatie relaties hac = gr en zbc = mT moeten gelden (al worden de blinderingen van a, b, en z dan iets ingewikkelder). Andere mogelijke uitvoeringen zijn denkbaar, zonder af te wijken van het hoofdidee dat een bepaald wiskundig verband tussen de representatie \ (ai,...,afc) van m behouden blijft in de representatie (&!,..., 6fc) van de geblindeerde informatie.

Nu volgt een gedetailleerde omschrijving van de protocollen van onze eerste voorkeuruitvoering van een privacybeschermend betaalsysteem. In deze gedetailleerde omschrijving wordt expliciet het zojuist beschreven restrictief blinde handtekeningen schema gebruikt. Het moge duidelijk zijn dat, indien een ander schema hiervoor in de plaats gebruikt wordt, alle protocollen eenvoudig kunnen worden aangepast afhankelijk van het specifieke verband dat tussen de representaties behouden blijft.

1.2 Basisuitvoering

Allereerst worden de protollen voor (1) het opnemen van informatie door een klant bij B, (2) het betalen van informatie door de klant aan een winkel, en (3) de crediterings fase (i.e. S krijgt van B geld overgestort) beschreven, allen voor één vaste geldwaarde van de informatie. D.w.z. in de nu volgende beschrijving wordt vooralsnog verondersteld dat het systeem met slechts een enkel type munt werkt. Dit is de basisuitvoering van het systeem. Uitbreidingen naar het gebruik van meerdere typen munten (net als in het huidige geldsysteem stuivers, kwartjes, guldens etc. gebruikt worden) worden daarna besproken, alsmede alle overige uitbreidingen (op volgorde: bescherming tegen 'framen', checks, een extra bank-module, anonieme rekeningen).

Initialisatie van het systeem Alvorens het systeem in gebruik kan worden genomen, genereert B de volgende getallen: 1. Een getal x G en een getal g £ Gq. B berekent h = gx en maakt (g,h) publiekelijk bekend. Het getal x is de geheime sleutel van B.

2. Een getal gi€Gq. Ook dit maakt B publiekelijk bekend.

3. Een getal deGq. Dit getal, dat ook publiekelijk bekend gemaakt wordt, zorgt ervoor dat een U die meerdere malen met hetzelfde geld betaald, achteraf door B geïdentificeerd kan worden.

Opgemerkt zij dat de keuzen van B voor g,h,g1,d uit veiligheidsoverwegingen zo dienen te worden gemaakt dat het voor anderen dan B ondoenlijk is om een tupel getallen (01,...,04) te bepalen, niet allen 0, zodanig dat gaihaigl3da* = 1.

Voorts maakt B een geschikte hash-functie H publiekelijk bekend. Deze functie heeft als argument vijf getallen uit Gq, en beeldt deze af op 7Lq. Voorts dient H aan bepaalde welbekende cryptografieche voorwaarden voor hash-fun'cties te voldoen. In het bijzonder dient H een 'one-way' functie te zijn.

De publiekelijk bekende informatie zal vanzelfsprekend in de software van het rekentuig van de gebruiker ingepast worden (of de hardware, bijv. in het ROM).

Openen van een rekening door U bij B Indien U een rekening wenst te openen bij B, dient hij zich te legitimeren (bijvoorbeeld met een paspoort). B registreert deze informatie tesamen met een getal Ui 6 2’. Dit getal kiest B verschillend voor iedere rekeninghouder. Indien U fraudeert, door dezelfde munt meerdere malen te spenderen, zal B het getal u-i kunnen berekenen. Omdat het in deze fase geregistreerd is, weet B dan dat U deze fraude gepleegt heeft, en kan dus maatregelen nemen.

Protocol om een munt op te nemen bij B Wanneer U een munt wil opnemen van zijn rekening, voert hij het volgende protocol uit met B (zie Figuur 2) :

Stap 1 B debiteert de rekening van U met de waarde van het muntstuk. Voorts berekent B m = g*ld. Hierbij dient te worden opgemerkt dat dit getal slechts eenmaal berekent hoeft te worden, en daarom zou het net zo goed opgeslagen kunnen worden in de vorige fase. Het getal m hoeft niet overgestuurd te worden, aangezien U het zelf ook kan berekenen (evt. eenmalig, waarna het opgeslagen wordt in het geheugen van het rekentuig van U) . Vervolgens genereert B een willekeurig getal w £ Zqr en berekent z = mx, a = gw en b = mw. Vervolgens stuurt B de getallen z, a, b naar U.

Stap 2 U genereert drie toevalsgetallen s en u,v, allen element van Zq maar s ongelijk 0. Gebruik makend van s, berekent U de geblindeerde vorm m' van m als ml — ms. Gebruik makend van u en v, blindeert U de overige getallen a, b en z als volgt (waarbij w' = uw + v mod q) : a' = augv (dit is dus gelijk aan gw'), b' — bua(m')v (hetgeen gelijk is aan (77^)^), en z' = zs (is gelijk aan (m')s) . Tot zover is dit als in de beschrijving van het restrictief blinde handtekeningen protocol, met i= 0. Nu echter 'splitst' U eerst m' (= m5 = glisd3) op willekeurige wijze in twee delen A en B.

Hiertoe kiest U toevalsgetallen Xi en yif beiden uit Zq/ en berekent (waarbij X2 = u1s-x1 mod g en yz = s — Ui mod q) vervolgens A — gl^d1^ en B = m'/A.

Merk op dat dus B = gl2dy*f en AB = m'. Daarna berekent U c' = 'H(A,B,z',al,b')f en stuurt c = c'/umodq naar B.

Stap 3 B berekent r = w + cx mod qr en stuurt r naar U.

U accepteert dan en slechts dan als de gelijkheden hca = gr en zcb = mT gelden. Indien U accepteert, berekent hij r' = ur + v mod q. U heeft nu getallen A,B met een bijbehorende handtekening sign(.A,l?) = (ζ',α', b',r').

In Stap 2 hoeft B de gebruiker niet mx te sturen, indien B in de initializatie fase ook nog gl en d* publiekelijk bekend maakt. Dan kan U z zelf berekenen. Merk op dat in ieder geval B het getal z hooguit eenmalig naar U hoeft te sturen, omdat het nooit verandert: U kan het op slaan zodra het getal eenmaal aan hem bekend is. In de figuren wordt het berekenen van m, z, en de transmissie van z voor de duidelijkheid wel steeds vermeld, maar zijn er om deze redenen blokhaken omheen gezet (' [ ]'). Deze conventie wordt in deze aanvrage aangehouden.

Opgemerkt zij voorts dat U veel informatie al van te voren kan berekenen, alleen de berekeningen die afhangen van a en b moeten (deels) in 'real-time' gedaan worden.

Het betalen met een munt door U bij S Teneinde met de opgenomen informatie (munt) te betalen bij een winkel Sr dient het volgende protocol uitgevoerd te worden (zie Figuur 3):

Stap 1 U stuurt het triple A = gl1dyi, B — gl2dyz, sign(i4, B) — (z',a',b',r') naar S.

Stap 2 S verifieert eerst dat AB φ 1. Als dit klopt, dan verifieert S de handtekening op A,B. Hiertoe berekent S eerst d = H{A,B\z',a',V)r en met deze c' controleert S dat de equivalenties gr' = he'a' en (AB)r' = (zy'b1 gelden. Indien alle verificaties kloppen, stuurt S een 'vraag' c £ \ {1} naar U.

De condities voor de vraag c worden hieronder besproken.

Stap 3 U verifieert dat οφ 1, en indien dit klopt, berekent U de 'antwoorden' = χχ + cx2 mod q en r2 = Vi + cy2 rood q. U stuurt τχ,τζ naar S.

S accepteert dan en slechts dan als g[1(T2 = ABe. De •p verificatie AB ψ 1 in Stap 2 kan worden verklaard uit het feit dat een keuze s = 0 in het opname protocol bij B, het U mogelijk maakt om deze informatie meerdere malen te spenderen zonder dat B later ui kan bepalen.

Het crediteren van de rekening van S door B Op vaste tijdstippen, bijvoorbeeld aan het eind van de werkdag, stuurt S alle informatie die hij heeft waargenomen tijdens de betaling (voor elke betaling), naar B (zie Figuur 4). Dit worden de betaling 'transcripten' genoemd. B verifieert de geldigheid van het transcript door dezelfde verificaties te doen als S (i.e. AB ψ 1, controleren van de handtekening, en van de antwoorden τχ,τ2) . Tevens doorzoekt B zijn 'database' van gespendeerde informatie (ofwel, van binnengekomen en door B reeds geaccepteerde betaling transcripten) teneinde vast te stellen of er gefraudeerd is. In dat geval zijn A,B met handtekening reeds eerder door een winkel naar B opgestuurd, en heeft een gebruiker dus meer dan een maal hetzelfde geld uitgegeven.

Voor de volledigheid zij opgemerkt dat B in dat geval twee verschillende transcripten met dezelfde A, B heeft, maar verschillende vragen c en c', en corresponderende antwoorden ri,r2 en r'^r^. Daarmee kan B Ui als volgt berekenen: ui = (ri(c' - 1) - r[(c - l)))/(r2(c' - l) - r'(c - 1)) mod q.

Derhalve kan B de identiteit van de fraudeur vaststellen.

Er zijn meerdere methoden bekend in de cryptografie om te voorkomen dat dezelfde vraag c meermaals gebruikt wordt. Hiertoe kan B een deel van c voorschrijven, dat per winkel verschilt. Voorts kan voorgeschreven worden dat c een 'one-way' hashwaarde is van de getallen uit de eerste transmissie (van U naar S) en bijzonderheden zoals tijdstip van transactie.

Opgemerkt zij dat dit betekent dat in principe U c zelf kan berekenen, en het betalingsprotocol dus geen interactie behoeft.

In de gedetailleerde beschrijving van het betaalsysteem tot nu toe werd gemakshalve aangenomen dat er slechts munten van een vaste waarde zijn, bijvoorbeeld van een gulden. Het is bekend in de literatuur dat men, teneinde in het systeem verschillende muntwaarden te hebben (stuivers, kwartjes, guldens, etc.), B voor iedere bepaalde muntwaarde een ander type handtekening kan laten gebruiken. Indien er bijvoorbeeld k verschillende muntwaarden zijn, laat men B k verschillende publieke sleutels (g,hi) gebruiken (en de k waarden Xi, met gSi = h, houdt B geheim) .

Een andere mogelijkheid wordt hier voor het eerst beschreven. Deze houdt in dat d de waarde van het geld representeert. Indien B, in plaats van slechts een element, k elementen 6 G, publiekelijk

bekend maakt, met de afspraak dat di 21-1 dubbeltjes waard is (bij wijze van voorbeeld), dan gebruikt B in het geldopname protocol m = gi1d{ in Stap 1, indien U 2i_1 dubbeltjes op wil nemen. Dit maakt het mogelijk om elk bedrag kleiner dan 2k dubbeltjes als munt op te nemen. Indien U bijvoorbeeld een munt van 21 dubbeltjes wil opnemen, dan berekent B m in het protocol voor het opnemen van een munt ra als als m = gi1d1d3d5, en is did3d5 ook het getal dat S in Stap 3 bij de betaling in plaats van d gebruikt om de antwoorden van U te controleren. Vanzelfsprekend zijn er meerdere kleine variaties op dit idee te bedenken, die echter niet van het idee afwijken dat B

m berekent door g*1 te vermenigvuldigen met een variabel deel dat een bepaald bedrag representeert.

1.3 Eerste uitbreiding: bescherming tegen

'framen' van U door B

In de basisuitvoering zoals hiervoor beschreven kan U zijn onschuld niet aantonen indien B hem ten onrechte ervan beschuldigt meerdere malen dezelfde informatie (munt) uitgegeven te hebben, omdat B ux van U reeds kende.

Een extra voordeel van het idee van de restrictief blinde handtekening is dat er slechts een kleine ingreep nodig is om het mogelijk te maken dat gebruikers hun onschuld kunnen bewijzen. Hiertoe genereert in de fase waarin U zijn rekening opent niet B, maar U het getal ux. Daarna maakt U I — gïl aan B bekend, maar niet ux zelf. Voor de rest zijn geen wijzigingen nodig in het systeem, want B heeft hier voldoende aan om m (= ld) te berekenen. Het zij opgemerkt dat uit veiligheidsoverwegingen U (eenmalig) aan B moet bewijzen dat hij een getal ui € Zq kent zodanig dat I — g*1 (zonder daarmee B enige extra informatie omtrent ux te geven). Hiervoor zijn eenvoudige protocollen bekend in de cryptografie. Voorts kan I ook in samenwerking met B worden, zonder dat B ux te weten komt. Dit kan het voordeel hebben dat Ui nu een getal is dat 'wederzijds toevallig' (engels: mutually random) bepaald is. Ook hiervoor is een simpel protocol bekend.

Indien U fraudeert door meerdere malen dezelfde informatie uit te geven, kan B uXr en dus I en daarmee zijn identiteit achterhalen. Echter, teneinde U ten onrechte van fraude te beschuldigen, zal B met ux op de proppen moeten komen (dit zal een 'rechter' eisen). Daartoe dient B log51 mod q te berekenen, hetgeen verondersteld wordt onevenredig veel computerkracht te vergen (dit is het zgn. Discrete Logarithme probleem). Merk op dat het dus niet onmogelijk is voor B om U te framen, het kost alleen zeer veel rekenkracht.

In de literatuur zijn andere methoden bekend om 'framen' te bewijzen. Deze zijn echter niet zo efficiënt en elegant als bovenstaande methode, omdat zij vereisen dat li zelf handtekeningen op een aanvraag ter opname van een munt, en alle informatie gebruikt ter blindering bewaard. De hier beschreven nieuwe methode heeft echter nog een voordeel, dat tot nu toe in geen enkel ander voorgesteld systeem verwezenlijkt is: men kan voorkomen dat B met succes een gebruiker kan framen, onafhankelijk van rekenkracht. Hiertoe genereert U (mogelijk weer in samenwerking met B) tijdens het openen van zijn rekening twee getallen Ui,u2£Zqr en maakt I = g'jjgl2 aan B bekend. Hierbij is g2 £ Gq een getal dat B ook van te voren bekend heeft gemaakt. Indien U fraudeert zal B zijn kunnen berekenen, daarmee I, en dus zijn identiteit. Echter, indien B U wil framen, moet B (op eis van de 'rechter') het paar u2 dat U weet als representatie van I, achterhalen. De kans dat B dat kan is verwaarloosbaar klein, onafhankelijk van rekenkracht, omdat er zeer veel in aanmerking komende paren zijn, maar U weet er met uniforme kans slechts een (wegens het Discrete Logarithme probleem) .

Voor de volledigheid wordt nu het systeem beschreven met de bescherming tegen framen onafhankelijk van rekenkracht van B.

Initialisatie van het systeem Dit is als voorheen, met de uitbreiding dat B ook een getal g2 £ Gq publiekelijk bekend maakt, verschillend van d, g, h en 9i·

Openen van een rekening door U bij B Indien U een rekenincr wensu te openen bij B, dient hij zich te legitimeren (d.m.v. bijv. een paspoort). U genereert twee toevalsgetallen i£i,u2eZg (eventueel in samenwerking met B, zoals hiervoor aangegeven), berekent I — g^g^2 r en stuurt I op naar B. Indien U fraudeert, door dezelfde munt meerdere malen te spenderen, zal B de getallen ui,u2 kunnen berekenen. Omdat I = g?gf in deze fase geregistreerd is, weet B dan dat U deze fraude gepleegt heeft, en kan dus maatregelen nemen. U kan zich dan, als boven beschreven, niet op 'framen' van B beroepen bij een 'rechter', omdat B precies zijn getallen u^u2 kent.

Protocol om een munt op te nemen bij B Allereerst zij opgemerkt dat een mogelijke manier voor U om aan B te bewijzen dat hij inderdaad van zijn eigen rekening gebruik maakt, is dat U bewijst een paar (ui,u2) te kennen waarvoor g^g'z = I (dit zal toch op zijn minst eenmalig moeten gebeuren, bij voorkeur overigens al tijdens het openen van de rekening). Het aangepaste protocol voor het opnemen van een munt, afgebeeld in Figuur 5, is als volgt:

Stap 1 B debiteert de rekening van U met de waarde van het muntstuk. Voorts berekent m = Id (dezelfde opmerkingen als voorheen gelden, en voor het gemak is weer verondersteld dat er maar een muntwaarde is). Vervolgens genereert B een willekeurig getal w G Zg, en berekent z = m*, a = gw en b = mw. Dan stuurt B de getallen z,a, b naar U.

Stap 2 U genereert drie toevalsgetallen s € Z* en η,νζΈg. Gebruik makend van s, berekent U de geblindeerde vorm m' van m als m' = m’. Gebruik makend van u en v, blindeert U de overige getallen a, b en z als volgt (waarbij w' = uw + v mod q) : a' = augv (dit is dus gelijk aan gw'), b'= bus(m')v (hetgeen gelijk is aan (m')w'), en z' = z3 (is gelijk aan (m!)x) . Dan splitst U m! (= ms = g1isg2lSds) op willekeurige wijze in twee delen A en B. Hiertoe kiest U toevalsgetallen xlr yx en zlr allen £ Z?, en berekent (waarbij x2 = uxs - xx mod qr y2 = u2s — yx mod q en z2 = s — zx mod q) vervolgens A = gV'gfd*1 en B = m'/A. Daarna berekent U c' = H(A,B,z',cl',V), en stuurt c — djumodq naar B.

Stap 3 B berekent r = w + cx mod q, en stuurt r naar U.

U accepteert, als voorheen, dan en slechts dan als de gelijkheden hca = gr en zcb = mr gelden. Indien U accepteert, berekent hij r' = ur + v mod q. U heeft nu getallen A,B met een bijbehorende handtekening sign(A, B) = (z',a',b',r').

Het betalen met een munt door U bij S Teneinde met de opgenomen informatie (munt) te betalen bij S, dient het volgende protocol uitgevoerd te worden (zie Figuur 6):

Stap 1 U stuurt het triple A = gl1 gf dzi, B = gx2g^dZz, sign(i4,5) = (z',a',b',r') naar S.

Stap 2 S verifieert eerst dat AB^l. Als dit klopt, dan verifieert S de handtekening op A,B als voorheen. Indien alle verificaties kloppen, stuurt S een vraag c e \ {1} naar U. De condities voor de vraag c zijn zoals reeds besproken.

Stap 3 U verifieert dat οφί, en indien dit klopt, berekent U de antwoorden rx = xx + c®2 mod q, r2 = Vx + cy2 mod q, en r3 = zx + cz2 mod q. U stuurt rijr2i^3 naar 5.

S accepteert dan en slechts dan als gx1g22dr3 = ABC.

Het crediteren van de rekening van S door B Op vaste tijdstippen, bijvoorbeeld aan het eind van de werkdag, stuurt S het betaling transcript naar B (zie Figuur 7) . B verifieert de geldigheid van het transcript door dezelfde verificaties te doen als S (i.e. AB ψ 1, controleren van de handtekening, is c wel correct bepaald door S, en zijn de antwoorden rx,r2 juist). Tevens doorzoekt B zijn database van gespendeerde informatie (ofwel, van binnengekomen en door B reeds geaccepteerde betaling transcripten) teneinde vast te stellen of er gefraudeerd is. In dat geval zijn A,B met handtekening reeds eerder door een winkel naar B opgestuurd, en heeft een gebruiker dus meer dan een maal hetzelfde geld uitgegeven.

In dat geval heeft B (minstens) twee verschillende transcripten met dezelfde A, B, maar verschillende vragen c en c', en corresponderende antwoorden r1,rz en r*i,7*2· Daarmee kan B u-ι als volgt berekenen: ui = (7i(c' - 1) - 7*ί(c - 1)))/(r3(c' - 1) - r'3(c - l)) mod q, u2 = (r2{c' - 1 )-r'2{c- l)))/(r3(c' - l) - r'3(c - l)) mod q.

Derhalve kan B als voorheen, door I te berekenen, de identiteit van de fraudeur vaststellen.

1.4 Tweede uitbreiding: Munten die meerdere malen mogen worden uitgegeven

In het beschreven voorkeurssysteem zijn in het betalings protocol de antwoorden van U punten op een lijn. Aangezien twee verschillende punten in het platte vlak op unieke wijze een lijn bepalen, kan B aan de hand van twee betaling transcripten die dezelfde munt betreffen, de identiteit van de fraudeur bepalen.

Omwille van de efficiëntie kan men de protocollen zo wijzigen, dat men eenzelfde munt meerdere malen, zeg k keer, mag uitgeven. Hiertoe laat men U in het betalingsprotocol bij S de antwoorden vormen als punten op een polynoom van de graad k. Dit idee is nog niet eerder in electronische betaalsystemen toegepast, alhoewel vanzelfsprekend wel bekend is dat k+1 verschillende punten in het platte vlak op unieke wijze één polynoom van de graad k definiëren.

Het protocol voor het opnemen van een munt die k maal mag worden uitgegeven wordt hiertoe enigszins gemodificeerd. Ten eerste trekt B in Stap 1 k maal de muntwaarde af van de rekening van U. De hashfunctie H die B in de initializatie fase publiceert heeft k + 4 argumenten uit Gq. Voorts splitst U m' in het munt-opname protocol niet in twee, maar in k+1 delen Ao,..· ,Ak, door k willekeurige keuzes x% £ alsmede k willekeurige keuzes yx (voor 0<z<fc-l)in Stap 2 te maken, en (met xk = «is - Et=i ximod· ? en Vk = s - yi mod q) A{ als A{ = g^dyi te berekenen.

Tevens wordt c' berekend als d = H(A0t... ,Ak,z',a'xb').

In het betalingsprotocol dient U in Stap 3 de twee antwoorden te berekenen als x,-cfc mod q en Γ2 = Σ*=ο yic1 mod g. Opgemerkt kan worden dat deze antwoorden met 'Horner's rule' snel berekend kunnen worden. De verificatie door S luidt dan: s;‘!7?=nio4?‘·

Indien B voor de k + 1-de maal een betaling transcript binnenkrijgt betreffende dezelfde munt, kan uit de k+1 verschillende verzamelingen antwoorden met bijbehorende vragen, % van de fraudeur weer bepaalt worden. Immers, alle z/ s en yxr s kunnen dan berekend worden, en daarmee ui.

Bijna identieke modificaties zijn natuurlijk in alle uitbreidingen (reeds beschreven, en nog te beschrijven) te realizeren.

1.5 Derde uitbreiding: electronische cheques

Opgemerkt zij dat deze uitbreiding hier beschreven wordt met ingebouwde bescherming tegen framen (onafhankelijk van rekenkracht). Hiervoor is gekozen om te illustreren dat alle uitbreidingen tegelijkertijd verwezenlijkt kunnen worden. Men zou kunnen zeggen dat ze 'orthogonaal' zijn. Voor eenzelfde opzet is gekozen in de uitbreiding tot extra bank-modules in de eerste voorkeursuitvoering. In de tweede voorkeursuitvoering van een electronisch betaalsysteem gebaseerd op de geclaimde technieken is ervoor gekozen om dit niet te doen, aangezien twee voorbeelden duidelijk genoeg moeten zijn voor iemand met kennis van het vakgebied om deze orthogonaliteit te illustreren.

Een cheque is, als voorheen, een of meer getallen met een bijbehorende handtekening van B. Het verschil met een munt is dat men de cheque voor em elk bedrag tot een bepaalde limiet kan besteden. Voor het niet gespendeerde deel kan men zijn geld teruggestort krijgen door B. Hiervoor is een extra, vierde, protocol nodig.

Initializatie van het systeem Dit is als voorheen beschreven, met de uitbreiding dat B ook 2k getallen Si,fi,...,ek,fk uit Z* en twee getallen dud2€Gq publiekelijk bekend maakt, allen onderling verschillend, alsmede verschillend van g, h, gx en g2. Hierbij neemt d-ι de rol van d over. Preciezer gezegd moeten al deze getallen dusdanig zijn dat het moeilijk is voor anderen dan B om 2k + 6 getallen b{ £ (niet allen 0) te vinden zodanig dat

(Aan deze eis is eenvoudig te voldoen.)

Cheques in het systeem kunnen dan voor 2k verschillende bedragen worden uitgegeven, zonder dat U van te voren hoeft te weten voor welk bedrag hij de cheque zal besteden. Men kan hiertoe het paar (e,·,ƒ,·) bijv. 21-1 dubbeltjes laten representeren, zoals reeds beschreven in de context van munten.

Voorts dient B uit veiligheidsoverwegingen een andere x te gebruiken dan die waarmee B munten certificeert.

Openen van een rekening door U bij B Dit is precies als voorheen beschreven in de eerste uitbreiding.

Protocol om een cheque op te nemen bij B Nadat U, als voorheen, toegang tot zijn rekening heeft gekregen (i.e. U heeft B overtuigd dat het geld van zijn eigen rekening wordt gehaald), kan U met het volgende protocol (zie Figuur 8) een cheque opnemen:

Stap 1 U genereert 2k+1 verschillende toevalsgetallen ai, bi (voor l<i<fc) en ak+1, allen uit ZJ. Dan berekent U mx = (Π,ί=ι en stuurt mx naar B.

Stap 2 B debiteert de rekening van U voor het maximale bedrag waarvoor de cheque kan worden betaald, en registreert τηχ bij U's gegevens (rekening). Met m2 = Idlr berekent B m als m = mim2. Daarna, als voorheen, stuurt B z = mx, a — gw b = mw (voor een toevalsgetal w € Zq) naar U.

Stap 3 U genereert toevalsgetallen s EKZJ, u,üGk2?, en transformeert m naar vn! = m3. Merk op dat

Vervolgens splits U elke van de 2k + 4 exponenten in twee delen, als voorheen, op de volgende manier:

De getallen aan de rechterkant van deze gelijkheden worden door U op willekeurige wijze gegenereert uit Zqf op zodanige wijze dat de gelijkheden gelden. Dan berekent U

en B = m'jA, alsmede de overige termen (gebruik makend van u,v als voorheen) die als argumenten voor de hashfunctie H dienen (te weten ζ',α',δ'). Tenslotte stuurt U

naar B.

Stap 4 B stuurt r = w + cx mod q naar U.

U accepteert dan en slechts dan als beschreven in de eerste uitbreiding.

Het betalen met een cheque door U bij 5 Teneinde met de opgenomen informatie (cheque) te betalen bij S, dient het volgende protocol uitgevoerd te worden (zie Figuur 9):

Stap 1 U stuurt A, B, sign (A,B) naar S, en informeert S over het bedrag (onder het limiet bedrag vanzelfsprekend) dat hij wil besteden. Zonder verlies van algemeenheid wordt veronderstelt dat U een bedrag wil uitgeven corresponderend met (βι,/ι)>··-,(ey,/j) (i.e. $2J - 1 dubbeltjes in het gegegeven voorbeeld), waarbij 1 <j < k.

Stap 2 S controleert eerst dat AB φ 1, alsmede de geldigheid van de handtekening. Als dit in orde is, stuurt hij een vraag céZ5\ {l} naar U, bepaald zoals voorheen uitgelegd.

Stap 3 U controleert dat οφ 1. Als dit klopt, dan berekent U de volgende antwoorden:

Voor i= 1 tot en met j: ri = (rt'i, Ti2, , T~i4) < (öj'A) βίΑι βΐΐ})

Voor i = j + 1 tot en met k:

Ti = (ra, ra)«- (α^ι + caiB mod g, βίΑ + αβίΒ mod g) rfc+i = (r(fc+x)i,r(fc+i)2,r(jt+1)3) *— (χχ + CX2 mod g, y2 + cy2 mod g, Ζχ + cz2 mod g) τιt+2 «- a.A + caB mod g.

Vervolgens stuurt W al deze antwoorden naar S. D.w.z., voor elke 'term' (e^,/,·) die in het te spenderen bedrag voorkomt, stuurt U de bijbehorende exponenten op, en voor het 'identiteitsgedeelte' punten op een lijn. De andere 'punten op lijnen' dienen in feite alleen om het S mogelijk te maken de correctheid van de antwoorden te controleren.

Opgemerkt dient te worden dat de exponenten in Stap 3 reeds in Stap 1 gestuurd kunnen worden. S verifieert of:

en accepteert dan en slechts dan als al deze verificaties kloppen.

Het crediteren van de rekening van 5 door B Als voorheen stuurt S het betaling transcript naar B, en B verifieert de correctheid (i.e. dezelfde relaties als 5 controleert tijdens de betaling, de correctheid van c, etc.). Zie Figuur 10 . Indien dit in orde is, en de cheque is nog niet eerder uitgegeven (een transcript met dezelfde A, B is nog niet binnen gekomen bij B), dan bewaart B, voor i — 1 tot en met j, de termen

m een aparte database (i.e. dit is een andere 'gesorteerde lijst' dan voor het identiteitsgedeelte van de cheque, corresponderend met (gi,9z,d)) .

Indien een cheque reeds eerder gespendeerd is, ontdekt B dat als voorheen.

Het vergoed krijgen van het ongespendeerde deel van de cheque Indien U voor het deel van de cheque dat niet besteed is zijn geld terug wil krijgen, brengt hij eerst B op de hoogte van de desbetreffende cheque (mi) . B controleert of ττίχ inderdaad is geregistreerd bij de rekening-informatie van U. Als dat zo is, dan wordt het volgende protocol uitgevoerd (zie Figuur 11):

Stap 1 U stuurt aj,&t·, voor j<i<k, naar B. (I.e. de exponenten corresponderende tot de termen (et·,/;) van de cheque die niet gespendeerd zijn. Er wordt overigens hier weer, zonder verlies van algemeenheid, aangenomen dat dit de laatste k — j termen zijn.)

Stap 2 B controleert dat, voor alle j <i<k, bi φ 0.

Als dit klopt, dan controleert B dat de quotiënten at/6t· mod q van de getallen die U in de vorige Stap toestuurde, nog niet in de aparte database geregistreerd zijn. Als ook dit in orde is, dan bewijst U aan B kennis van een representatie van i.eeen tupel zodanig dat elf ft β?-1 ή2’d%1+l aan dit getal gelijk is. Uit privacy-overwegingen gebeurd dit vanzelfsprekend zonder prijs te geven welk tupel dat dan wel is. In Figuur 11 is hiervoor expliciet een eenvoudige generalizatie van een bekend protocol uit de cryptografische literatuur gebruikt.

Stap 3 Indien B accepteert, stort B het bedrag dat U terug wilde hebben op diens rekening. Vervolgens slaat B ai/bi mod q, voor j < i <kr op in de aparte database, en wist B het geregistreerde getal πΐχ.

Er zij opgemerkt dat indien er gebruik gemaakt zou worden van een iets ander restrictief blinde handtekening protocol in het protocol voor opnemen van de cheque, waarvoor m alleen naar m! = mgt geblindeerd kan worden (niet naar m' = msgt voor willekeurige s zoals het geval is in het concrete handtekeningen protocol dat hier steeds gebruikt wordt), dan kan het check systeem toe met twee keer zo weinig termen (i.e. alleen e* i.p.v. (e^, ƒ,·)) . Aangezien deze vereenvoudiging mogelijk is in de tweede voorkeursuitvoering, terwijl niet van het feitelijke idee afgeweken wordt, wordt het niet nodig geacht dit hier te beschrijven.

1.6 Vierde uitbreiding: extra bank-module die in het rekentuig van de gebruiker ingebed wordt

Deze uitbreiding wordt, zoals de derde uitbreiding, beschreven op dusdanige wijze dat framen onafhankelijk van de rekenkracht van B voorkomen wordt.

Een mogelijk nadeel van het systeem tot nu toe is dat B pas naderhand ontdekt dat dezelfde informatie meerdere malen is uitgegeven. Zoals in de . cryptografische literatuur is ppgemerkt, kan B dit a priori al ondoenlijk maken. Hiertoe krijgt elke rekeninghouder bij B een zogenaamde bank-module, die fraude-bestendig is {engels: tamperresistant). De bank-module heeft eigen geheugen en rekenkracht, net als het rekentuig van de rekeninghouders. Wegens de fraude-bestendigheid van de bank-module kan, in tegenstelling tot het eigen rekentuig, de inhoud van de bank-module niet bestudeerd en/of gekopieerd worden. Er wordt nu voor gezorgd dat het rekentuig van de gebruiker alleen in samenwerking met de bank-module transacties kan doen. Het meerdere malen uitgeven van dezelfde informatie zal dan a priori niet lukken, omdat de bank-module daar niet aan mee werkt.

Uit de literatuur is bekend dat de bank-module 'ingebed'' dient te worden in de module (rekentuig) van de rekeninghouder teneinde diens privacy te waarborgen. Er zijn diverse criteria bekend waaraan de protocollen dienen te voldoen teneinde diverse gradaties van privacy te waarborgen. Deze uitbreiding wordt hier beschreven onder de meest stringente condities voor privacy (genaamd 'no shared Information' in het vakgebied), en zodanig dat indien de bank-module 'gekraakt' wordt (zelfs voor initializatie van het systeem!) B nog steeds achteraf de identiteit van de fraudeur kan bepalen (als voorheen).

De bank-module wordt in de beschrijvingen steeds met ö aangeduid. Elke O is uitgerust met een publieke/geheime sleutel waarmee O handtekeningen kan berekenen, teneinde B te laten weten of O bij bepaalde berekeningen betrokken was (dit gebeurt alleen in de fase van het openen van een rekening).

Initializatie van het systeem Dit is als voorheen beschreven in de eerste uitbreiding.

Openen van een rekening door U bij B Hiertoe dient het volgende protocol uitgevoerd te worden (zie

Figuur 12):

Stap 1 U genereert drie toevalsgetallen U berekent vervolgens Au — g'ygT, en stuurt T' = Aug1 naar O.

Stap 2 O genereert twee toevalsgetallen ols o2 Gft Zg en berekent Ao — g^g^. Vervolgens berekent O zijn digitale handtekening op T = T'Ao, en stuurt Aq en de handtekening naar U.

Stap 3 U verifieert dat de handtekening juist is. Indien dit het geval is, stuurt UT — T'Aq, de handtekening van O, en t naar B.

Stap 4 B verifieert de handtekening. Als dit klopt, berekent B T/g*.

Stap 5 O en U bewijzen samen dat ze samen een paar (αι>α2) kennen zodanig dat T/gt = gl1g%2, zonder informatie over het paar zelf prijs te geven, en zodanig dat O niets over het paar (£>i,o2) aan U prijsgeeft. Hiervoor kan een eenvoudig protocol bekend uit de literatuur gebruikt worden.

Indien B het bewijs van O en U accepteert, registreert B I = T/g1 tesamen met de identiteit van U (die zich weer met bijv. een paspoort dient te identificeren) als rekeninginformatie behorende bij U.

Men kan aantonen dat indien B accepteert, en dus de rekening opent, dat dan O Ao=gx'g^ kent alsmede (o1,o2) (O's geheime sleutel), en U kent Au — g^\gU2 en (ui,u2) (U's geheime sleutel). Voorts heeft O geen informatie omtrent Au, terwijl U wel Aa kent maar niet 0χ,ο2. Tenslotte geldt I-AoAu.

Indien U tegen verwachting in toch de inhoud van de bank-module weet te achterhalen (door de 'tamperresistance'’ te kraken) en als voorheen hetzelfde geld vaker uitgeeft dan toegestaan, dan zal B als voorheen (oj. + Wi,o2 + u2) kunnen berekenen. Door dan I = g^+ui g2i+U2 te berekenen kan B de identiteit van de fraudeur achterhalen.

Opgemerkt zij dat indien de bescherming tegen framen niet ingebouwd wordt, men eenvoudig B een paar (o1;o2) kan laten genereren (zie tweede voorkeursuitvoering). Deze worden dan bijv. in het ROM van O ingebakken alvorens O aan U te overhandigen.

Protocol om een munt op te nemen bij B Teneinde een munt van zijn rekening op te nemen, bewijst U eerst dat de betreffende rekening op zijn naam staat.

Hiertoe kan bijvoorbeeld een eenvoudig protocol, bekend uit de literatuur, gebruikt worden waarmee O en U samen bewijzen dat ze samen een paar (¾,a2) kennen zodanig dat I = g^g^, zonder informatie over dit paar zelf prijs te geven. Vervolgens wordt het volgende protocol uitgevoerd (zie Figuur 13):

Stap 1 O genereert twee toevalsgetallen o3,o4GZgf en berekent = ¢^024 · Daarna stuurt ö Bq naar U. Opgemerkt zij dat Ό dit in feite op elk willekeurig tijdstip voor Stap 2 kan doen.

Stap 2 U en B voeren het protocol voor opnemen van een munt zoals beschreven in de eerste uitbreiding uit, met een klein verschil in de manier waarop U m'= ma splitst in A, B. Namelijk, U berekent A = (AoAuYBqBu(Fr B = Bq3Bylda"*, voor toevalsgetallen α,β, j E Z* en Bu=g\3g2A voor toevalsgetallen u3,u4eZg. Opgemerkt zij dat Bu niet expliciet berekend dient te worden, en dat a,/3,7,u3,u4 door U bewaart moeten worden teneinde later de munt te kunnen uitegeven.

Het betalen met een munt door U (en O) bij S Na afloop van het vorige protocol om een munt op te nemen, weet U A, B, sign (A,B) en toevalsgetallen ct,/?,7€Z* en u3,u4éZ,, zodanig dat A = (AoAu)a BqBu<F , Β = BöPBüld*-\

Teneinde met deze munt te betalen, dient het volgende protocol te worden uitgevoerd (zie Figure 14):

Stap 1 U stuurt A, B, sign (A,B) naar S.

Stap 2 S verifieert de handtekening als voorheen. Als dit klopt, dan stuurt S een vraag c ê Z, \ {l} (bepaald als voorheen beschreven) naar U.

Stap 3 U verifieert dat ο,φ 1. Als dit het geval is, dan berekent U c' = β[ΐ — c)/a mod q, en stuurt c' naar O.

Stap 4 Allereerst controleert O of de munt niet al eerder is uitgegeven. In dat geval helpt ö niet mee. Als daarentegen dit een legale transactie is, en c' φ 0, dan berekent O de antwoorden r'x = οχ + doi mod q en r'2 — o2 + c'o4 mod q. Tenslotte stuurt ö r1}r2 naar U.

Stap 5 U verifieert of g2g2 = AqBq. Als dit het geval is, dan berekent U de drie antwoorden = a(r^ + ηχ) + (l — c)u$ mod q, r2 = a(r'2 + u2) + (l — c)u4 mod q, en r3 = η + c(a — j) mod q. Daaarna stuurt U r-i,r2,T2 naar S.

S accepteert dan en slechts dan als gr^gr2dr3—ABc.

Het crediteren van de rekening van S door B Hiervoor wordt naar de beschrijving in de eerste uitbreiding verwezen. Indien B ontdekt dat meerdere malen heltzelfde geld is gespendeerd (en 'dus' dat de fraudeur zijn bank-module heeft weten te 'kraken'), dan kan B als voorheen (ux + ox,u2 + o2), en daarmee I en de identiteit van de fraudeur bepalen.

Framen heeft een verwaarloosbare kans op succes, zelfs als de bank-module van de rekeninghouder die B wil framen mee werkt. Namelijk, het bepalen van ui,u2 heeft verwaarloosbare kans op succes zelfs als O een andere o1} o2 voorgeeft te hebben gebruikt.

Met een weinig moeite kan men bijvoorbeeld de uitbreiding tot cheques inbouwen in deze vierde uitbreiding. Hiertoe kan men verkiezen om te zorgen dat alle exponenten alleen door O en U samen gekend worden, of slechts de exponenenten op gx,g2,d1 (de exponenten op (dz,e1} fa,... ,ek, fk) zijn dan geheel aan U bekend).

1.7 Vijfde uitbreiding: anonieme rekeningen

Tot nu betreft de privacy van de rekeninghouders alleen hun bestedingspatroon (transacties zijn anoniem). B kan wel precies zien wat er met de rekeningen van haar klanten gebeurd (hoeveel er opgenomen en gestort wordt, e.d.). Ook dit kan voorkomen worden; gebruikers kunnen een rekening op fictieve naam openen (een pseudonym). Deze uitbreiding is nog niet eerder verwezenlijkt.

In de eerste uitbreiding is bij de rekening van U een getal I = gx2gz2 geregistreerd, tesamen met de identiteit van U. Teneinde de rekening anoniem te openen, neemt U het getal in een voorafgaand protocol met B op in een restrictief blinde handtekeningen schema. In feite is dit bijna identiek aan het protocol beschreven in de eerste uitvoering. Het enige verschil is dat U nu niet een munt, maar een pseudoniem I opneemt bij B. Een mogelijke uitvoering van dit protocol is de volgende (zie Figuur 15) ;

Stap 1 B genereert een uniek toevalsgetal ux e Z? voor U, en stuurt dit naar U. U identificeert zichzelf als voorheen. B bewaart al deze informatie in een database. Men kan tegen framen beschermen door in plaats hiervan U het getal ux te laten kiezen, en U alleen gJ11 aan B bekend te laten maken.

Stap 2 Met een kleine variatie op het protocol om geld op te nemen als voorheen (B berekent m als m = gl1g2), verkrijgt U een restrictief blinde handtekening op I = (gl1 g2)r, voor een door hem gekozen toevalsgetal

De rest van het systeem is zoals beschreven in de eerste uitbreiding. I is het gecertifeerde (het gaat vergezeld van een handtekening van B) pseudonym van U. In de fase waarin U nu zijn rekening opent, identificeert U zich niet meer. B controleert alleen dat I gecertificeerd is, en U moet bewijzen (als voorheen) dat hij een paar ax,az kent zodanig dat I = gfg? (op deze manier kan U ook bewijzen dat de rekening van hem is, wanneer later geld opgenomen moet worden).

Aangezien I = gx1Tg2r en het protocol om een munt op te nemen, m = Id tot m' = m3 voor een toevalsgetal s £ Zg geblindeerd wordt, geldt dat

Bij het meerdere malen uitgeven kan B derhalve ux berekenen, en de identiteit van de fraudeur vaststellen (merk op: niet door de database met rekeningen-informatie te doorzoeken, maar de database met informatie over uitgifte van pseudonymen) .

In dit specifieke voorbeeld kan B bij fraude ook r en daarmee I berekenen, en weet B dus tevens meteen welke rekening van de fraudeur is. Vanzelfsprekend zijn meerdere voor de hand liggende variaties op dit idee denkbaar. Zo kan men ervoor zorgen dat alleen de rekening, of alleen de identiteit maar niet de rekening bekend worden (los van de vraag wat voor voordeel dit zou bieden).

Voorts kan men met een eenvoudige modificatie ervoor zorgen dat framen van B niet zal slagen, onafhankelijk van diens rekenkracht (in het bovenstaande geval kan B nog Ui bepalen met zeer veel rekenkracht). Hiertoe laat men in Stap 1 U twee getallen ui,u2 kiezen, en alleen g^g^2 aan B bekend maken. Alle protocollen moeten dan enigszins gewijzigd worden, afhankelijk van of 9i,92,dr of bijvoorbeeld gx,g2,93,d gebruikt worden.

1 kan meerdere malen restrictief geblindeerd worden; zo kan men een 'keten' van pseudonymen krijgen.

2 Tweede voorkeursuitvoering 2.1 Een restrictief blinde handtekening geschikt voor de tweede voorkeursuitvoering

Verondersteld wordt dat V publiekelijk eendrietal (η,ν,Χ Εΐζ) bekend heeft gemaakt. Hierbij is n het produkt van twee grote priemgetallen, v een priemgetal onderling ondeelbaar met de orde van Z* (maar, zoals voorheen toegelicht, kan men ook andere keuzes voor v maken, en zelfs v een macht van twee nemen), en X een element van grote orde uit Z*. V bewaart u-1 mod \(n) (hierna aangegeven in de exponent met l/v) als geheime sleutel. H is een publiekelijk bekende one-way hashfunctie die twee argumenten uit Z* afbeeldt op een element uit Z*.

Een mogelijke uitvoering van het restrictief blinde handtekeningen protocol geschikt voor de tweede voorkeursuitvoering is als volgt (zie Figuur 16): :ap 1 Tl deelt aan V een getal m mede dat Tl gedurende de volgende drie stappen gaat blinderen teneinde een blinde handtekening te verkrijgen. In de voorkeursuitvoering van het betaalsysteem zelve blijft deze stap achterwege, omdat m eenmalig wordt bepaald door een van beide partijen (of in samenwerking), en vervolgens steeds opnieuw gebruikt wordt indien dezelfde TZ in het protocol betrokken is.

Stap 2 V genereert een toevalsgetal a£Z* en stuurt het naar TZ.

Stap 3 TZ genereert drie toevalsgetallen x €τι Z*.

Vervolgens berekent TZ m! = msv en a! = aHv. Hiermee berekent hij d = H(m\a!) en de geblindeerde vraag c=c'rmodu. Tenslotte stuurt TZ c naar V.

1. V berekent bx = {Xac)l!v en b2 = , en stuurt 6χ, &2 naar TZ.

TZ accepteert dan en slechts dan als b\ = Xac en bl = mac. Als dit het geval is, dan berekent TZ

Indien vèrondersteld wordt dat TZ voordat het protocol begint een k + 1-tupel (αχ G Z„,..., ak G ak+x G Z*) kent, zodanig dat (IliLi ^i0i)afc+i = mr en na afloop een k + 1-tupel (61,...,64/64+1) zodanig dat (^=1^)64+1 = ^, dan zal steeds gelden dat a* = bi voor 1 < i < k, op voorwaarde dat alle Yi' s verschillen van elkaar en van X, en dat TZ geen k + 1-tupel (cx,... ,cjfc+1) kent (niet allen 0) zodat (Πί=ι i^Ci)^Ci+1 = !· Deze relatie, en hetzelfde geldt vanzelfsprekend ook voor bijv. sommen van de a;' s, blijft dus steeds behouden, onafhankelijk van de keuze van s door TZ.

Overigens kan TZ een blinde handtekening verkrijgen op elk getal m! dat hij wenst, door in Stap 1 m = m's~v op te sturen naar V. In het geval steeds dezelfde m gebruikt wordt, zoals aangegeven, kan dit echter niet zonder meer 2onder onevenredig veel rekenkracht te gebruiken. Het ligt wor de hand dat dit toegepast kan worden in het deelgebied der cryptografie dat zich met 'credential' mechanismen bezighoudt.

Als voorheen moge het duidelijk zijn dat dit slechts een mogelijke uitvoering is. Als illustratie hiervan wordt nu een andere mogelijke uitvoering beschreven.

2.2 Een tweede uitvoering van een restrictief blinde handtekeningen protocol (Zie Figuur j^·)

Stap 1 Tl deelt aan V een getal m mede dat Tl gedurende de volgende drie stappen gaat blinderen teneinde een blinde handtekening te verkrijgen.

Stap 2 V genereert een toevalsgetal a6 Z* en stuurt het naar Tl.

Stap 3 Tl genereert drie toevalsgetallen s,t €κΖ*η,

Vervolgens berekent Tl m' = msv en a' = axtv. Hiermee berekent hij d — en de geblindeerde vraag c = d/x modu. Hier wordt met djx bedoelt c^x"1 mod u). Tenslotte stuurt Tl c naar V.

1. V berekent bx = {Xca)1!'3 en b2 = (mca)1^vr en stuurt bx,b2 naar Tl.

Tl accepteert dan en slechts dan als b\ = Xca en bl = mca. Als dit het geval is, dan berekent Tl

waarbij e berekend'wordt (met de zgn. uitgebreide Euclidische algorithme) uit (x-1 mod υ)χ = 1 + ev.

2.3 Basisuitvoering

De basisuitvoering en alle uitbreidingen van de tweede voorkeursuitvoering worden in termen van het eerste restrictief blinde handtekeningen schema beschreven. Vanzelfsprekend had ook voor het tweede schema gekozen kunnen worden, of een andere, zonder daarmee wezenlijk af te wijken.

Als in de beschrijving van de basisuitvoering van de eerste voorkeursuitvoering worden de protocollen allereerst beschreven voor één muntwaarde.

Initializatie van het systeem Voordat het systeem in gebruik kan worden genomen genereert B de volgende getallen: 1. Twee priemgetallen p,q. Het produkt n van p en q maakt B publiekelijk bekend. Geschikte keuzes voor p,q zijn uit de literatuur bekend (in verband met het RSA systeem) .

2. Een redelijk groot priemgetal v (als υ te klein is dan kan iedereen digitale handtekeningen vervalsen), onderling ondeelbaar met φ{η). B berekent u-1 mod \[n). Dit getal zal in het vervolg met l/v aangeduid worden. Het zij opgemerkt dat ψ de Euler phi-functie is, λ de Carmichael functie.

3. Twee verschillende getallen Χ,Υ £ Z*, bij voorkeur met orde λ(η). Zoals bekend is, is het zeer eenvoudig om toevalsgetallen met orde λ(π) uit Z* te genereren, indien zowel p — 1 als q — 1 minstens een grote priemfactor hebben (engels: 'hard primes').

In de praktijk wordt vaak een n van 512 bits gekozen, en is v 64 of ook wel 128 bits.

B publiceert ook een hashfunctie

waarvoor soortgelijke eisen als beschreven in de eerste voorkeursuitvoering gelden. In het bijzonder dient H een 'one-way' functie te zijn.

De eis dat v een priemgetal is is niet noodzakelijk, maar lijkt wel te prefereren (men worde verwezen naar een eerdere bespreking hiervan).

Openen van een rekening door U bij B Indien U een rekening wenst te openen bij B, dient hij zich te legitimeren (d.m.v. bijv. een paspoort). B registreert deze informatie tesamen met een getal Si E Dit getal kiest B verschillend voor iedere rekeninghouder. Indien U fraudeert, door dezelfde munt meerdere malen te spenderen, zal B het getal ux kunnen berekenen aan de hand van de betaling transcripten. Omdat het in deze fase geregistreerd is, weet B dan dat U deze fraude gepleegt heeft, en kan dus maatregelen nemen.

Protocol om een munt op te nemen bij B Wanneer U een munt wil opnemen van zijn rekening, dient hij eerst aan te tónen eigenaar van zijn rekening te zijn.

Daarna voert U het volgende protocol uit met B (zie Figuur 18):

Stap 1 B debiteert de rekening van U met de waarde van het muntstuk. Vervolgens genereert B een toevalsgetal en stuurt het naar U.

Stap 2 U genereert een toevalsgetal S2 Gtï Z* en blindeert hiermee m = KS1 naar m' = ms\ . Daarna genereert U toevalsgetallen x £ηι Z* en t £n Z*, and berekent a' = axtv. Vervolgens splitst U m' in twee delen A,B zodanig dat m! = AB. Preciezer gezegd, U berekent A = Y011^ voor toevalsgetallen αχ Stj Zai, «2 Z*, en B = m'[A {-Υ^βΙ) voor βχ = sx - ax, βζ = · Hiermee berekent U c' = H(A,B,a') en de geblindeerde vraag cr^imodt;. Tenslotte stuurt U c naar B.

Stap 3 B berekent m = (eenmalig is voldoende, zie opmerking in de eerste voorkeursuitvoering) .

Vervolgens berekent B de antwoorden 6χ = (Ja')1/” en 62 = (ma')1/”, waarbij m = YSl, en stuurt deze naar U.

U accepteert dan en slechts dan als 6^ = Xac en b2 = mac. Als dit het geval is, dan berekent U

Het drietal (a', wordt voor de duidelijkheid met sign(A,B) aangeduid.

Het betalen met een munt door tl by S Teneinde met de opgenomen informatie (munt) te betalen bij een winkel S, dient het volgende protocol uitgevoerd te worden (zie Figuur i<j ) :

Stap 1 U stuurt Α = Υαια%, B = ΥβιβΙ, sign(A, B) - {a!,VX,V2) naar S.

Stap 2 S verifieert de handtekening. Hiertoe berekent S eerst c' = H(A,B,a')r en verifieert dan of (6'1)v = X(a')c' en (b'2)v = AB(a')c'. Als de verificatie in orde is, stuurt c een vraag c £ Z* \ {1} naar U. Voor de vraag gelden dezelfde opmerkingen als in de eerste voorkeursuitvoering.

Stap 3 Indien c^l, dan berekent U de antwoorden ri = Oh + Φι mod v, r2 =Yai+c^ldivva2/¾, en stuurt ze naar S.

S accepteert dan en slechts dan als YTir% = ABe.

Evenals in de eerste voorkeursuitvoering mag c niet 1 zijn, omdat dan meteen uit de antwoorden βχ = αι+βι berekent kan worden.

Het crediteren van de rekening van S door B Op een bepaald tijdstip, bijvoorbeeld aan het eind van de werkdag, stuurt S het betaling transcript (en dat voor elke betaling), naar B (zie Figuur 20 ). B verifieert de geldigheid van het transcript door dezelfde verificaties te doen als S (i.e. controleren van de handtekening, en van de antwoorden ri,r2), en te controleren dat c op de 'voorgeschreven' manier bepaald is. Tevens doorzoekt B zijn database van reeds binnengekomen betaling transcripten teneinde vast te stellen of er gefraudeerd is. In dat geval zijn A,B met handtekening reeds eerder door een winkel naar B opgestuurd, en heeft een gebruiker dus meer dan een maal hetzelfde geld uitgegeven.

Voor de volledigheid zij opgemerkt dat B in dat geval twee verschillende transcripten met dezelfde A, B heeft, maar verschillende vragen c en c', en corresponderende antwoorden rx,r2 en γ^,γ^. Daarmee kan B ux berekenen, en dus de identiteit van de fraudeur.

In de gedetailleerde beschrijving van het betaalsysteem tot nu toe werd, als in de eerste voorkeursuitvoering, gemakshalve aangenomen dat er slechts munten van een vaste waarde zijn, bijvoorbeeld van een gulden. Indien er bijvoorbeeld k verschillende muntwaarden dienen te zijn, kan men (zoals welbekend in de literatuur) B k verschillende Vi' s gebruiken (paarsgewijs onderling ondeelbaar) in plaats van één v. Eventueel kan n per munttype verschillen.

2.4 Eerste uitbreiding: bescherming tegen

framen van U door B

In de basisuitvoering kan U zijn onschuld niet aantonen indien B hem ten onrechte ervan beschuldigt meerdere malen dezelfde informatie (munt) uitgegeven te hebben, omdat B ux van U reeds kende.

Het idee van de restrictief blinde handtekening maakt het mogelijk dit probleem elegant op te lossen, op analoge wijze aan hoe dit in de eerste voorkeursuitvoering gebeurde. Hiertoe genereert in de fase waarin U zijn rekening opent niet B, maar U het getal sχ. Daarna maakt U I = F*1 aan B bekend, maar niet Si zelf. Voor de rest zijn geen wijzigingen nodig in het systeem, want dit is precies het getal m. Het zij opgemerkt dat uit veiligheidsoverwegingen U (eenmalig) aan B moet bewijzen dat hij een getal ai 6¾ kent zodanig dat I— Yai (zonder daarmee B enige extra informatie omtrent αχ te geven), en dat αχ < υ (of evt. een ietsjes ruimere bovengrens dan v) .

Indien U fraudeert door meerdere malen dezelfde informatie uit te geven, kan B Siinodu berekenen uit de betaling transcripten. Aangezien iedere rekeninghouder heeft bewezen dat de exponent sχ op hun I kleiner dan ti is, levert dit de I van de fraudeur op. Echter, teneinde U ten onrechte van fraude te beschuldigen, zal B met ν,χ op de proppen moeten komen (dit zal een 'rechter' eisen). Daartoe dient B Si te berekenen, hetgeen verondersteld wordt onevenredig veel computerkracht te vergen (dit is het zgn. RSA probleem). Merk op dat het dus niet onmogelijk is voor B om U te framen, het kost alleen zeer veel rekenkracht (al zij opgemerkt dat B de berekeningen in Gq en Z* kan doen en het uiteindelijke resultaat dan met de zgn. Chinese rest stelling kan berekenen).

In de literatuur zijn andere methoden bekend om framen te bewijzen. Als voorheen, in de eerste voorkeursuitvoering, opgemerkt, zijn deze echter niet zo efficiënt en elegant als bovenstaande methode, omdat zij vereisen dat U zelf handtekeningen op een aanvraag ter opname van een munt, en alle informatie die ter blindering gebruikt werd, bewaard.

Als voorheen kan men de hier beschreven methode eenvoudig modificeren, teneinde te voorkomen dat B met succes een gebruiker kan framen, onafhankelijk van B' s rekenkracht. Analoog aan het idee hiertoe in de eerste voorkeursuitvoering wordt in de protocollen dan gewerkt met -'ƒ = m = Y^Y^2, waarbij sl5 S2 € Ζυ door U zelf bepaald zijn, en B alleen m weet.

Aangezien de nodige modificaties voor de hand liggend zijn, en voor de eerste voorkeursuitvoering wel beschreven zijn in detail, wordt hier de gedetailleerde beschrijving van bescherming tegen framen achterwege gelaten, en wordt zij ook niet ingepast in de uitbreidingen.

2.5 Tweede uitbreiding: Munten die meerdere malen mogen worden uitgegeven

Het moge duidelijk zijn dat, net als in de eerste voorkeursuitvoering, de protocollen zo gewijzigd kunnen worden dat men eenzelfde munt meerdere malen, zeg k keer, mag uitgeven. Hiertoe laat als voorheen beschreven U in het betalingsprotocol bij S de antwoorden vormen als punten op een polynoom van de graad k.

Het protocol voor het opnemen van een munt die k maal mag worden uitgegeven wordt hiertoe op soortelijke wijze gemodificeerd. Ten eerste trekt B in Stap 1 k maal de muntwaarde af van de rekening van U. De hashfunctie H die B in de initializatie fase publiceert heeft k + 2 argumenten uit Z*. Voorts splitst U m! in het munt-opname protocol niet in twee, maar in Hl delen Ao,...,Ak, door k willekeurige keuzes X{ 6 Z„ alsmede k willekeurige keuzes t/i 6 Z* (voor 0 < i < k — 1) in Stap 2 te maken, en (met

Zfc = *1 - Eti xi m°d v en yk = s2/Ui=i Vi) A‘ als A{ = YXiy\ te berekenen. Tevens wordt d berekend als c' — "kt{Ao,..., Ak, a').

In het betalingsprotocol dient U in Stap 3 dan de twee antwoorden te berekenen als ri = XiCk mod v en r2 = F£<=o*<cfcdivorii=D0f * De verificatie door S luidt dan: ΥΤίτν2 = Π?=0 Af.

Indien B voor de k + 1-de maal een betaling transcript binnenkrijgt betreffende dezelfde munt, kan uit de k+1 verschillende verzamelingen antwoorden met bijbehorende vragen, sx van de fraudeur weer bepaalt worden. Immers, alle x.'s kunnen dan berekend worden, en daarmee sx.

Als voorheen zijn bijna identieke modificaties in alle uitbreidingen (reeds beschreven, en nog te beschrijven) te realizeren.

2.6 Derde uitbreiding: electronische cheques

Initialisatie van het systeem Dit is als beschreven in de basisuitvoering van de tweede voorkeursuitvoering, met de uitbreiding dat B k toevalsgetallen Z\,..., Zk € Z* met grote orde (liefst λ(η)) publiceert. Op deze manier kan een cheque, als voorheen, voor 2k verschillende bedragen gespendeerd worden.

Analoog aan de eerste voorkeursuitvoering dient v onderling ondeelbaar te zijn met het getal v dat B in de basisuitvoering gebruikt.

Openen van een rekening door U bij B Dit is precies als beschreven in de basisuitvoering.

Protocol om een cheque op te nemen bij B Nadat U, als voorheen, toegang tot zijn rekening heeft gekregen (i.e. U heeft B overtuigd dat het geld van zijn eigen rekening wordt gehaald), kan U met het volgende protocol (zie Figuur Zί) een cheque opnemen:

Stap 1 U genereert k toevalsgetallen olr.. ,ak £% TLvt en een toevalsgetal ak+1 Z*. Vervolgens berekent U mx = (nf=i Z?)at+i en stuurt dit getal naar B.

Stap 2 B vermindert de rekening van U met het

maximumbedrag waarvoor de cheque besteed kan worden, en registreert mx op rekening van U. B

genereert daarna een toevalsgetal a 67^ en stuurt het naar U.

Stap 3 U genereert een toevalsgetal s2 Gtï, Έ*η en blindeert hiermee m = m\Yn tot m' = ms2. Voorts kiest U toevalsgetallen x en t ^en berekent a' = axtv. Daarna splitst U m! in twee termen A en B, zodanig dat m' = AB. Hiertoe berekent U A = Z?1 · · * Ζ£*Υα*+1αΖ+2 voor toevalsgetallen ai G71 Zai,..., «fc €71 %at,afc+i en afc+2 Gtj. K' en B = Zf · · ΖξΎβί+1βΙ+ζ · Voor de getallen /¾ geldt

Hiermee berekent U d = H(A,B,a'), en c = c'xmodx;. Tenslotte stuurt U c naar B.

Stap 4 B berekent = {Xac)1!v en b2 = (ma')1^, waarbij B m berekent als m = τη^Υ*1. Vervolgens stuurt B de antwoorden b1,b2 naar U.

U accepteert dan en slechts dan als bl=Xac en b2 = mac. Als dit in orde is, berekent U als voorheen b[ = WXC'X en b'2 = b2mc'x d±vvs2tc'.

Het betalen met een cheque door U bij 5 Teneinde met de opgenomen cheque te betalen bij S, dient het volgende protocol uitgevoerd te worden (zie Figuur 21):

Stap 1 U stuurt A,B, sign(A, B) naar S, en informeert S over het bedrag (onder het limiet bedrag vanzelfsprekend) dat hij wil besteden. Zonder verlies van algemeenheid wordt veronderstelt dat U een bedrag wil uitgeven corresponderend met Zx,...,Zj, waarbij l<j<k. (In het algemeen dus ; € S C {1,... ,k}.)

Stap 2 S verifieert dat de handtekening klopt. In dat geval stuurt S een vraag c 6 \ {1} naar U.

Stap 3 U verifieert dat 1. Als dit klopt dat berekent U de volgende antwoorden:

Vervolgens stuurt U deze antwoorden naar S. Wat hier gebeurt is dat U voor iedere denominatie (overeenkomend met een getal Zx) die hij wenst te spenderen, de corresponderende twee exponenten (een in A en de ander in B) bekend maakt, en voor het identiteitsgedeelte (corresponderend tot Y) als voorheen een punt op een lijn.

S accepteert dan en slechts dan als

en 0 < Γ{χ,Γ{2 < v voor 1 <i<j (deze laatste conditie kan afgezwakt worden voor wat betreft de bovengrens v). Zoals het geval met al dit soort uitdrukkingen, kunnen zij met behulp van bekende technieken ('vector addition chains', 'simultaneous repeated squaring') snel geevalueerd worden.

Als in de eerste voorkeursuitvoering kunnen de 'exponenten' ook al in Stap 1 gestuurd worden.

Het crediteren van de rekening van S door B Als voorheen stuurt S het betaling transcript naar B, en B verifieert de correctheid als voorheen (zie Figuur 23). Indien dit in orde is, en een transcript met dezelfde A,B is nog niet eerder binnen gekomen bij B, dan bewaart B, voor i = 1 tot en met j, het transcript in een aparte database. Voorts betaalt B aan S het gedeelte van de cheque dat is gespendeerd.

Indien een cheque reeds eerder gespendeerd is, berekent B de identiteit van de fraudeur als voorheen.

Het vergoed krijgen van het ongespendeerde deel van de cheque Indien U voor het deel van de cheque dat niet besteed is zijn geld terug wil krijgen, brengt hij eerst B op de hoogte van de desbetreffende cheque (mi) . B controleert of πΐχ inderdaad is geregistreerd bij de rekening-informatie van U. Als dat zo is, dan wordt het volgende protocol uitgevoerd (zie Figuur 2<i) :

Stap 1 U stuurt aj, voor j <i<k, naar B. (I.e. de exponenten corresponderende tot de termen Zi van de cheque die niet gespendeerd zijn. Er wordt overigens hier weer, zonder verlies van algemeenheid, aangenomen dat dit de laatste k — j termen zijn.)

Stap 2 B verifieert dat a» < v voor alle j + 1 < i < k, en dat geen van deze getallen al in zijn 'aparte' database voorkomt. Als dit in orde is, dan moet U een 'proof of knowledge' van een tupel (oi,..., a.j; üj+i) zodanig dat

uitvoeren met B. In de figuur is daarvoor een mogelijke uitvoering gebruikt voor concreetheid.

Stap 3 Als B het bewijs accepteert, dan geeft B het bedrag dat U wenste terug te ontvangen aan U. Daarna wist B het getal mi.

2.7 Vierde uitbreiding: extra bank-module die in het rekentuig van de gebruiker ingebed wordt

De bank-module wordt in de beschrijvingen steeds met O aangeduid. Elke O is uitgerust met een publieke/geheime sleutel waarmee O handtekeningen kan berekenen, teneinde B te laten weten of Ό betrokken was bij bepaalde berekeningen (dit gebeurt alleen in de fase van het openen van een rekening).

Initialisatie van het systeem Dit is als beschreven in de basisuitvoering.

Openen van een rekening door U bij B Aangezien de bescherming tegen framen niet ingebouwd wordt hier, in tegenstelling tot hoe deze uitbreiding in de eerste voorkeursuitvoering is beschreven, is er niet een dergelijk protocol nodig hier. (Als de bescherming tegen framen wel ingebouwd wordt dan is dit vanzelfsprekend wel nodig).

In plaats daarvan kan met het volgende volstaan worden: U identificeert zich, en B kiest een uniek getal sa £ Z, voor U (zoals in de basisuitvoering) . Vervolgens geeft B aan U een bank-module O, met daarin 'ingebakken', oj. € Zv en o2 £ Z*. Deze getallen zijn niet aan U bekend. Het getal wordt met Aq aangeduid, en is wel aan U bekend.

Daarna genereert U (en/of B) als voorheen een toevalsgetal u^Z,,. Het getal F"1 of ux zelf is ook B bekend, maar niet aan O. Het getal Yvi wordt met Au aangeduid.

Hiertoe kan bijvoorbeeld een eenvoudig protocol, bekend uit de literatuur, gebruikt worden waarmee O en U samen bewijzen dat ze samen een paar (αχ; a2) kennen zodanig dat ΑκΑο=Υαια2, zonder informatie over dit paar zelf prijs te geven. Vervolgens wordt het volgende protocol uitgevoerd (zie Figuur 25):

Stap 1 O genereert twee toevalsgetallen o3 en o4 6 Z*, en berekent Bo = Y°*o\. Vervolgens stuurt O Bp naar U. Dezelfde opmerking als in de vierde uitbreiding van de eerste voorkeursuitvoering is hier van toepassing.

Stap 2 U en B voeren het protocol om een munt op te nemen uit, zoals beschreven in de basisuitvoering, met een modificatie in de wijze waarop U m' splitst. Aangezien B m berekent als m = Y0l+Ulo2r geldt dat ml — Y°1+Ul(o2u2)v. Voor eenvoud wordt Yuiu2 nu met Au aangeduid (het zij opgemerkt dat de blindering u2r in het basisprotocol sx genaamd, hierin verwerkt zit), en dus m'= AUA0. U berekent A = AoAuB^By1 en B = BqBu, voor een toevalsgetal d Z*.

Als voorheen berekent U vervolgens c' = H(A,B,a') en c=dx modü, en stuurt c naar B.

Stap 3 B berekent 61 = (Xa0)1^ en b2 = (ma0)1/'0, waarbij m = Y°1+Ulol.

U accepteert dan en slechts dan als de equivalenties zoals in de basisuitvoering beschreven staan gelden, en als dit in orde is berekent U b[,b'2 als voorheen.

Het betalen met een munt door U (en ö) bij. S Na afloop van het vorige protocol om een munt op te nemen, weet U A, B, sign (A, B) zodanig dat

Ao = B0 = y-oj,

Au = YUiul,

Bu = YU3u\.

Het zij opgemerkt dat O o4 = 1 kan nemen.

Teneinde met deze munt te betalen, dient het volgende protocol te worden uitgevoerd (zie Figure 2é):

Stap 1 U stuurt A, B, sign (A,B) naar S.

Stap 2 S verifieert de handtekening als voorheen. Als dit klopt, dan stuurt S een vraag cGZ„ \ {1} (als voorheen beschreven) naar U.

Stap 3 U verifieert dat c^l. Als dit het geval is, dan berekent U d — {c—l)dmodv, en stuurt d naar O.

Stap 4 ö verifieert dat dit een legale transactie is. In dat geval, en als d φ 0, berekent ö de antwoorden r[ = Oi + c'03 mod v en r'2 = y(Ol+c,°3)divt,0204 en stuurt ze naar U.

Stap 5 U verifieert of Υ^(τ'2)υ = AqBq . Als dit het geval is, dan berekent U

ri = r[ + ti! + (c - l)u3 mod v en r2 = r^r(ri+t£1+(c~1)u3)div,'u2ur1^c"1)‘idivt’. Vervolgens stuurt U deze antwoorden naar S.

S accepteert dan en slechts dan als Ynr%=:ABe.

Het crediteren van de rekening van S door B Hiervoor wordt naar de beschrijving in de basisuitvoering verwezen. Indien B ontdekt dat meerdere malen hetzelfde geld is gespendeerd (en dus dat de fraudeur zijn bank-module heeft weten te 'kraken'), dan kan B als voorheen iti + Οχ mod v bepalen, en daarmee de identiteit van de fraudeur.

Als in de eerste voorkeursuitvoering beschreven, kan men met een weinig moeite bijvoorbeeld de uitbreiding tot cheques inbouwen in deze vierde uitbreiding.

2.8 Vijfde uitbreiding: anonieme rekeningen

Hiervoor wordt naar deze uitbreiding in de eerste voorkeursuitvoering verwezen.

Claims

1. Werkwijze voor het uitvoeren van vertrouwelijk elektronisch informatieverkeer tussen tenminste één partij van de eerste soort, tenminste één partij van de tweede soort en tenminste één partij van de derde soort, - waarbij een eerste informatie-eenheid door een tupel getallen wordt gerepresenteerd, - waarbij een gebruiker van de eerste soort de informatie-eenheid van een gebruiker van de tweede soort ontvangt volgens een eerste protocol, de informatie-eenheid bij een partij van de derde soort aflevert volgens een tweede protocol en de gebruiker van de tweede soort de informatie-eenheid onderzoekt volgens een derde protocol, - waarbij het eerste protocol tenminste de volgende stappen omvat: * het verstrekken van een eerste tupel getallen door de gebruiker van de eerste soort aan de gebruiker van de tweede soort, waarbij het eerste tupel informatie omvat ,· * het door de gebruiker van de tweede soort versleutelen van het eerste tupel getallen; * het retourneren van het aldus verkregen tweede tupel getallen door de gebruiker van de tweede soort aan de gebruiker van de eerste soort; en * het transformeren van het tweede tupel door de gebruiker van de eerste soort tot een een handtekening van de gebruiker van de tweede soort belichamend derde tupel getallen, met het kenmerk, dat het derde tupel getallen de in het eerste tupel getallen omvatte informatie omvat.

2. Werkwijze volgens conclusie 1, met het kenmerk, dat het versleutelen van het eerste tupel door de gebruiker van de tweede soort interactieve handelingen tussen de gebruiker van de eerste soort en de gebruiker van de tweede soort behoeft.

3. Werkwijze volgens conclusie 1 of 2, met het kenmerk, dat bij meer dan een vooraf bepaald aantal malen toetsen van de elektronische handtekening de in het derde tupel omvatte informatie beschikbaar komt.

4. Werkwijze volgens conclusie 1, 2 of 3, met het kenmerk, dat de in het eerste tupel omvatte informatie betrekking heeft op de identiteit van de gebruiker van de eerste soort.

5. Werkwijze volgens conclusie 1-4, met het kenmerk, dat de werkwijze betrekking heeft op elektronisch betalingsverkeer, dat de gebruikers van de eerste soort betalende partijen zijn, dat de gebruikers van de tweede soort door financiële instellingen, zoals banken of krediet-kaartmaatschappijen gevormd worden en dat de gebruikers van de derde soort ontvangende partijen zijn. vorm heeft:

6. Werkwijze volgens een van de conclusies 1-5, met het kenmerk, dat het eerste tupel getallen de volgende

7. Werkwijze volgens conclusie 6, met het kenmerk, dat elementen vormen van een wiskundige groep waarbij het aantal elementen van de groep een priemgetal is.

8. Werkwijze volgens een van de conclusies 1-5, met het kenmerk, dat het eerste tupel de volgende vorm heeft:

waarbij n het produkt van twee verschillende priemgetallen is.

9. Werkwijze volgens een van de voorafgaande conclusies, met het kenmerk, dat de werkwijze tenminste twee maal wordt uitgevoerd, waarbij het bij de eerste maal uitvoeren van de werkwijze verkregen derde tupel het nieuwe eerste tupel vormt bij een volgende uitvoering van de werkwijze.

10. Werkwijze volgens een van de voorafgaande conclusies, met het kenmerk, dat de werkwijze gebruikt wordt voor het verkrijgen van een door het derde tupel gerepresenteerd pseudoniem.

11. Werkwijze volgens een van de voorafgaande conclusies, met het kenmerk, dat de omvatte informatie van het eerste tupel getallen per gebruiker tenminste één vast element omvat.

12. Werkwijze volgens een van de voorafgaande conclusies, met het kenmerk, dat het derde tupel tenminste één deel van de omvatte informatie omvat dat bij een eerste toetsing prijsgegeven wordt, terwijl het complementaire deel niet wordt prijsgegeven.

13. Werkwijze volgens conclusie 12, met het kenmerk, dat deze werkwijze toegepast wordt bij van cheques gebruik makend betalingsverkeer.

14. Werkwijze volgens een van de voorafgaande conclusies, met het kenmerk, dat de omvatte informatie van het derde tupel verdeeld wordt over tenminste twee entiteiten die voor een geslaagde toetsing door de gebruiker van het derde type, noodzakelijkerwijs samenwerken.

15. Werkwijze volgens conclusie 14, met het kenmerk, dat de werkwijze betrekking heeft op betalingsverkeer, en dat tenminste één van de entiteiten door de bank wordt beheerd, en dat het deel van de omvatte informatie aanwezig in de door de bank beheerde entiteit onafhankelijk is van door en aan de gebruiker van de derde soort toegevoerde informatie.

16. Stelsel, ingericht voor het uitvoeren van een werkwijze volgens één van de voorafgaande conclusies.

17. Elementen van een stelsel volgens conclusie 16.