BE1017304A6 - Authenticatie op afstand en digitale handtekeningen voor transacties. - Google Patents

Abstract

De uitvinding betreft een methode, toestel, computer leesbaar medium en signaal voor het authentificeren van gebruikers en tekenen van transacties met toestellen die PKI private sleutels bevatten. De authenticiteit van de gebruiker / boodschap wordt geverifieerd terwijl voor de bewerking geen applicatie nodig is om een directe of indirecte digitale verbinding te hebben met het PKI-toestel, noch een digitale verbinding waardoor men gegevens naar het PKI-toestel kan sturen / een handtekening kan opvragen, noch dat het PKI-toestel symmetrische cryptografische bewerkingen kan ondersteunen of gepersonaliseerd kan worden met een gegevenselement dat door een lezer gelezen kan worden.

Description

Authenticatie op afstand en digitale handtekeningen voor transacties

Achtergrond [001] Naargelang de toegang vanop afstand tot computersystemen en -toepassingen almaar populairder wordt, nemen ook het aantal en de soorten transacties sterk toe die vanop afstand via openbare netwerken zoals het internet uitgevoerd kunnen worden. Deze populariteit benadrukt de nood aan beveiliging, meer bepaald: a. Hoe verzekeren dat mensen die zich vanop afstand toegang verschaffen tot een toepassing zijn wie ze beweren te zijn en hoe verzekeren dat de transacties vanop afstand door rechtsgeldige personen worden uitgevoerd. Hiervoor gebruikt men de term authenticatie.

b. Hoe verzekeren dat transactiegegevens niet gewijzigd zijn voor ze op een applicatieserver aankomen. Hiervoor gebruikt men de term gegevensintegriteit.

c. Hoe garanderen dat een individu na het aangaan van een transactie die transactie niet kan ontkennen. Hiervoor gebruikt men de term onloochenbaarheid.

[002] In het verleden maakten leveranciers van toepassingen gebruik van statische paswoorden om in de veiligheid van toepassingen vanop afstand te voorzien. De laatste jaren is duidelijk gebleken dat statische paswoorden niet voldoen en dat meer geavanceerde beveiligingstechnologie nodig is.

PKI SMART CARDS

[003] Een manier om de veiligheidsproblemen aan te pakken die gepaard gaan met de toegang vanop afstand tot computersystemen en -toepassingen via openbare netwerken is het gebruik van een Public Key Infrastructure (PKI) (publieke sleutelinfrastructuur). In een Public Key Infrastructure wordt aan elke gebruiker een publiek-privaat sleutelpaar toegekend. Het sleutelpaar wordt verbonden met een certificaat (uitgegeven door een Certificaat Autoriteit) dat het publiek-privaat sleutelpaar met een welbepaalde gebruiker verbindt. Met behulp van asymmetrische cryptografie kan dit publiek-privaat sleutelpaar gebruikt worden: a. om de gebruiker te authenticeren, b. om transacties, documenten en e-mails te tekenen (om ontkenning tegen te gaan), en c. om geëncrypteerde communicatiekanalen op te zetten.

[004] Om een voldoende hoog veiligheidsniveau te waarborgen, moet de private sleutel van elke gebruiker geheim blijven en mag die enkel toegankelijk zijn (bv. om een handtekening te maken) voor de rechtmatige gebruiker die verbonden is aan de sleutel. Gewoonlijk wordt een smartcard gebruikt om het publiek-privaat sleutelpaar en het certificaat te bewaren en om de cryptografische berekeningen met betrekking tot de private sleutel uit te voeren. Het gebruik van de private sleutel door de smartcard wordt dan vaak beveiligd door een pincode.

[005] PKI-smartcards worden en werden uitgegeven door: a. Bedrijven aan hun werknemers of klanten om het inloggen op hun computernetwerken of de toegang vanop afstand tot hun toepassingen te beveiligen, b. Banken aan hun klanten om bv. internetbanktoepassingen te beveiligen en c. Overheden aan hun burgers als elektronische identiteitskaarten om wettelijk bindende digitale handtekeningen te maken.

[006] Naast voordelen zijn er aan PKI en aan de smartcards met PKI-sleutels en -certificaten ook enkele nadelen verbonden: a. Het opzetten van een Public Key Infrastructure is over het algemeen vrij ingewikkeld en bijgevolg duur in vergelijking met concurrerende beveiligingstechnologieën.

b. PKI is inherent beperkt tot omgevingen en toepassingen met een digitale verbinding tussen clients en servers. Het is met andere woorden niet geschikt voor telefoonbankieren of andere verdeelkanalen waar de mogelijkheid ontbreekt om een digitale verbinding te maken tussen de drager van het PKI-certificaat en de private sleutel enerzijds en een applicatieserver anderzijds, c. PKI-smartcards beschikken niet over een stroomvoorziening of een gebruikersinterface. PKI-smartcards hebben daarom een verbindingstoestel nodig dat de kaart van elektriciteit voorziet, dat in staat is om digitaal gegevens uit te wisselen met de kaart en dat verbinding kan maken met de gebruiker (bv. om de pincode van de kaart op te halen en de gegevens door te geven die getekend moeten worden). Meestal wordt een pc met een geconnecteerde transparante smartcardlezer gebruikt. Dit beperkt de mobiliteit van de gebruiker (veel computers zijn niet uitgerust met smartcardlezers). Bovendien brengt dit ook een veiligheidsprobleem met zich mee: alle gebruikersinteractie (zoals een handtekening goedkeuren of de pincode van de kaart ophalen) gebeurt op de inherent onveilige pc.

Tokens voor sterke authenticatie [007] Een alternatieve technologie voor authenticatie en digitale handtekeningen voor transacties is het gebruik van zogenaamde ‘tokens voor sterke authenticatie’. Een typisch voorbeeld van een token voor sterke authenticatie is eender welke Digipass-token die door Vasco Data Security Inc. aangeboden wordt, zie website Vasco.com.

[008] Een token voor sterke authenticatie is een klein autonoom toestel met batterijvoeding en een eigen display en toetsenbord. In sommige gevallen is het toetsenbord gereduceerd tot een enkele knop of zelfs helemaal weggelaten. De bedoeling van een token voor sterke authenticatie is voornamelijk zogenaamde ‘eenmalige paswoorden’ of ‘one-time passwords’ (OTP’s) genereren. Soms kunnen tokens voor sterke authenticatie ook electronische handtekeningen of Message Authentication Codes (MAC’s) genereren op gegevens die via het toetsenbord van het token ingevoerd zijn. Als het token een toetsenbord heeft, is het gebruik ervan vaak beveiligd met een pincode.

Om OTP’s of MAC’s te genereren, kunnen tokens voor sterke authenticatie cryptografische berekeningen maken gebaseerd op symmetrische cryptografische algoritmes, geparametriseerd met een geheime waarde of sleutel. Typische voorbeelden van zulke symmetrische cryptografische algoritmes, geparametriseerd met een geheime waarde of sleutel, zijn symmetrische encryptie/decryptiealgoritmes (zoals 3DES of AES) en/of versleutelde éénrichtingshashfuncties (zoals MD5 of SHA-1 in OATH-tokens). In de tekst zal er verder soms naar de output van zulke algoritmes verwezen worden met de term ‘symmetrisch cryptogram’. Onder de term ‘symmetrisch cryptogram’ zal dus niet alleen de output van symmetrische encryptiealgoritmes maar ook van symmetrische decryptiealgoritmes of versleutelde hashfuncties verstaan worden. Tokens voor sterke authenticatie worden gepersonaliseerd met een of meerdere geheime sleutels die voor elk individueel token geacht worden verschillend te zijn. Om een eenmalig paswoord of een handtekening te genereren, doorloopt een token typisch volgende stappen (zie fig.1): a. Stap 10: Het token neemt een invoerwaarde (dit kan een challenge zijn gegenereerd door een server en ingevoerd op het toetsenbord van de gebruiker en/of de waarde van de interne real-time klok van het token en/of de waarde van een interne teller beheerd door het token en/of transactiegegevens ingevoerd op het toetsenbord door de gebruiker).

b. Stap 11: Het token zet de invoerwaarde in een gespecificeerd formaat.

c. Stap 12: Het token stuurt die geformatteerde invoer dan naar een symmetrisch encryptie/decryptiealgoritme en/of een one-way hashfunctie geparametriseerd met een gepersonaliseerde geheime sleutel 15 veilig opgeslagen in het token. Het resultaat is een cryptogram of een hashwaarde.

d. Stap 13: Het token verandert het cryptogram of de hashwaarde die voortkomt uit deze encryptie/decryptie of one-way hash in het eigenlijke OTP of MAC. Dat wil zeggen dat het cryptogram of de hash typisch afgekapt wordt, omgezet wordt naar een door de mens leesbaar formaat (bv. door decimalisatie) en getoond wordt op het display. De gebruiker kan deze waarde naar de applicatieserver sturen.

[009] Meestal is een token voor sterke authenticatie een fysisch toestel, maar soms wordt de functionaliteit van deze tokens voor sterke authenticatie om OTP’s of MAC handtekeningen te genereren, geëmuleerd door software op een computer, een werkstation, een gsm, een elektronische agenda, een PDA enz. Dan worden ze ‘soft tokens’ genoemd.

[0010] Nadat het OTP of de MAC berekend is, wordt het naar een entiteit gebracht waar de waarde geverifieerd kan worden ter authenticatie van de gebruiker of het bericht, zie fig. 2. . Die entiteit is gewoonlijk een applicatieserver. De applicatieserver slaat gegevens op voor elk token waaronder de geheime sleutel(s) waarmee het token gepersonaliseerd werd en de identiteit van de gebruiker die met het token verbonden is. Om een eenmalig paswoord of een handtekening te valideren, roept de server de geheime sleutel (115) op, die een kopie is van de sleutel waarmee het token gepersonaliseerd is. De server neemt dezelfde invoer die door het token gebruikt werd en voert in essentie hetzelfde algoritme 112 uit als het token. Daarna vergelijkt de server 120 het verkregen resultaat met de ontvangen waarde. (In de praktijk is de validatie van een OTP of MAC vaak wat ingewikkelder als het algoritme voor sterke authenticatie gebaseerd is op tijd of een teller ten gevolge van synchronisatieproblemen.) Aangezien een eenmalig paswoord of een handtekening gegenereerd door een token voor sterke authenticatie een functie is van de individuele geheime sleutel van het token en de steeds andere waarden van de invoer in het algoritme van het token, geeft de validatie van de juistheid van het eenmalig paswoord of de handtekening de applicatieserver een zeer hoge graad van zekerheid dat de persoon die het eenmalig paswoord of de handtekening invoert over het juiste token beschikt en de pincode ervan kent (als het token beveiligd is met een pincode). Dat geeft dan weer een zeer hoge graad van zekerheid dat die persoon daadwerkelijk de rechtmatige gebruiker is die verbonden is met dat token.

[0011] Aangezien de server die het OTP verifieert en het OTP token in essentie hetzelfde algoritme gebruiken met dezelfde sleutel, kan het algoritme dat het OTP genereert een éénrichtings- of niet-omkeerbare functie zijn. Dit houdt in dat het eigenlijke OTP korter kan zijn dan het cryptogram of de hashwaarde waarvan het is afgeleid. Hierdoor kan het OTP of de MAC voldoende kort zijn zodat het niet te storend is voor gebruikers om de OTP- of MAC-waarden manueel te kopiëren van het display van het token naar de pc. Tokens voor sterke authenticatie vereisen bijgevolg geen digitale verbinding tussen het token en de verificatieserver.

[0012] De belangrijkste voordelen van tokens voor sterke authenticatie in vergelijking met PKI-kaarten zijn: a. Ze zijn volledig autonoom (tokens hebben een eigen elektrische voeding en gebruikersinterface); b. Ze staan los van het verdeelkanaal of het communicatiemedium (tokens vereisen geen enkele digitale of elektronische verbinding met een ander toestel; alle invoer en uitvoer van gegevens gebeurt door de gebruiker via het display en toetsenbord van het token) en c. Ze bieden een zeer hoge graad van veiligheid (alle interactie met de gebruiker zoals het ophalen van de pincode of het doorgeven van transactiegegevens die getekend moeten worden, gebeurt via de eigen veilige gebruikersinterface van het token.).

[0013] In sommige gevallen waar smartcards werden uitgegeven, wil men de nadelen en beperkingen die gepaard gaan met smartcards omzeilen en dezelfde voordelen verkrijgen als bij tokens voor sterke authenticatie, namelijk volledige autonomie, onafhankelijkheid van het verdeelkanaal en een veilige gebruikersinterface.

[0014] Eén mogelijkheid is de smartcard combineren met een niet-geconnecteerde smartcardlezer die op batterijen werkt en over een eigen display en toetsenbord beschikt. Het idee is dat de combinatie van een smartcard en een niet-geconnecteerde smartcardlezer een token voor sterke authenticatie emuleert. De functionaliteit die gewoonlijk geleverd wordt door een token voor sterke authenticatie, wordt dan verdeeld over de smartcard en de niet-geconnecteerde lezer. De niet-geconnecteerde lezer zorgt voor de hele gebruikersinterface, en alle of een deel van de overige functionaliteit van het token wordt de kaart toebedeeld.

[0015] Alle gepersonaliseerde geheimen en veiligheidsgevoelige gegevens worden typisch opgeslagen en beheerd door de kaart (bv. de pincode wordt opgeslagen en gecontroleerd door de kaart, de geheime sleutels worden opgeslagen op de kaart en alle cryptografische bewerkingen met die sleutels worden door de kaart uitgevoerd, de tellers gebruikt als invoer voor het algoritme van het token worden opgeslagen en beheerd door de kaart). Een deel van de functionaliteit van het token dat minder gevoelig is (bv. het afkappen en omzetten van de gegenereerde hashes of cryptogrammen) gebeurt vaak in de lezer. Een voorbeeld van deze combinatie wordt hieronder besproken.

[0016] Dit principe wordt vaak gebruikt door banken die de bankkaarten die ze uitgeven (voor gebruik aan geldautomaten of betaalterminals) combineren met niet-geconnecteerde lezers om hun banktoepassingen vanop afstand (zoals intemetbankieren of telefoonbankieren) te beveiligen. Een mooi voorbeeld hiervan is het

MasterCard Chip Authentication Programme (CAP), dat aantoont hoe EMV-smartcards gebruikt kunnen worden in combinatie met niet-geconnecteerde smartcardlezers om eenmalige paswoorden en digitale handtekeningen over transactiegegevens te genereren.

[0017] Deze technologie steunt op de smartcards die in staat zijn om symmetrische cryptografische bewerkingen uit te voeren en gepersonaliseerd zijn met een geheime sleutel om te gebruiken voor symmetrische cryptografische bewerkingen. PKI-smartcards zijn echter ontworpen om asymmetrische sleutels op te slaan en asymmetrische cryptografische bewerkingen uit te voeren. Veel PKI-smartcards ondersteunen geen symmetrische cryptografische bewerkingen, of (als ze dat toch doen) zijn nooit gepersonaliseerd met een individuele symmetrische geheime sleutel.

Traditionele PKI-handtekeningen

[0018] Doorgaans wordt een digitale handtekening met een PKI-smartcard gemaakt door de invoergegevens (gewoonlijk bestaan de invoergegevens uit een hash van de eigenlijke transactiegegevens die men wil tekenen) te encrypteren met de private sleutel van de kaart.

[0019] Doorgaans wordt een dergelijke handtekening gevalideerd doordat de entiteit die valideert de ontvangen handtekening met de publieke sleutel decrypteert. Als de decryptie van de handtekening dezelfde waarde oplevert als de invoergegevens die geacht worden te zijn geëncrypteerd met de private sleutel, dan wordt de handtekening met succes gevalideerd. Merk op dat dankzij dit asymmetrische kenmerk de entiteit die valideert nooit toegang nodig heeft tot de private sleutel van de kaart. Zo kan de private sleutel geheim gehouden worden voor alle andere partijen dan de ondertekenaar, zelfs voor elke controlerende partij, en dus voor echte onloochenbaarheid zorgen.

[0020] Dit kan slechts werken als de handtekening zelf volledig beschikbaar is voor de entiteit die valideert. De decryptie van een onvolledige handtekening zou enkel tot zinloze gegevens leiden die niet vergeleken kunnen worden met de invoergegevens die geacht worden getekend te zijn.

[0021] In de praktijk kan niet aan deze voorwaarde voldaan worden als kleine, draagbare en niet-geconnecteerde smartcardlezers gebruikt worden: aangezien de typische grootte van een PKI-handtekening ongeveer 100 bytes bedraagt, is het display van deze lezers veel te klein om een volledige handtekening te tonen. Bovendien is het in elk geval volledig onrealistisch om van de gebruiker te verwachten dat hij/zij een waarde van 100 bytes manueel van het display van de lezer naar een pc kan kopiëren zonder ook maar een fout te maken. De typische 100 bytes van een PKI-handtekening zou vergeleken moeten worden met de 6 tot 8 cijfers of 3 tot 4 bytes van een typische OTP of MAC gegenereerd door een traditioneel token voor sterke authenticatie. Dit is zeker een reden waarom asymmetrische cryptografie en private sleutels niet gebruikt worden om OTP’s en MAC’s te genereren met bv. tokens voor sterke authenticatie.

[0022] Een methode en toestel zijn gewenst die: a) het gebruik mogelijk maken van een toestel waarop private sleutels voor PKI (zoals PKI-smartcards of USB-sticks) opgeslagen worden om gebruikers te authenticeren en transacties te ondertekenen, b) zonder de behoefte aan een gebruikerstoepassing om een of andere directe of indirecte digitale verbinding te hebben met het toestel waarop de private sleutel opgeslagen is, meer bepaald een digitale verbinding waardoor de gebruikerstoepassing gegevens naar de kaart zou kunnen sturen om te tekenen met de private sleutel van de kaart en die het mogelijk zou maken de volledige verkregen handtekening van de kaart op te vragen, zou niet nodig mogen zijn, c) zonder dat het PKI toestel waarop de private sleutel opgeslagen is (bv. een PKI-smartcard of USB-stick): 1) ofwel symmetrische cryptografische bewerkingen moet ondersteunen, 2) of gepersonaliseerd moet zijn met geheime of vertrouwelijke gegevens die door een geschikte lezer gelezen kunnen worden.

Samenvatting van de uitvinding

[0023] Deze aanvraag geeft een beschrijving van een methode en toestel die aan de voorafgaande eisen voldoen. Deze aanvraag beschrijft meer bepaald een aantal uitvoeringsvormen die de private sleutel van een publiek-privaat sleutelpaar (een sleutel die bedoeld is om te gebruiken voor asymmetrische cryptografie zoals het RSA- algoritme) gebruiken om een gebruiker te authenticeren (door een OTP te genereren) of om gegevens te ondertekenen (door een MAC te genereren).

[0024] De hier beschreven uitvoeringsvormen verschillen van het traditionele gebruik van private sleutels om gebruikers te authenticeren en gegevens te ondertekenen (zoals hierboven beschreven) omdat: a) dezelfde cryptografische sleutel gebruikt wordt om de OTP’s en MAC’s te genereren en te controleren; en b) de lengte in bits van de OTP- en MAC-waarden gerust aanzienlijk korter kan zijn dan de lengte in bits van de cryptogrammen die door de private sleutels gegenereerd worden.

[0025] Alle uitvoeringsvormen hebben gemeen dat: a) Ze allemaal een dynamische waarde berekenen aan de hand van een of meerdere variabele invoergegevens met behulp van een cryptografisch algoritme dat een geheim gebruikt dat ook gekend of toegankelijk is voor een controlerende server.

b) De variabele invoergegevens kunnen zijn: 1) Tijdswaarde, of 2) Tellerwaarde, of 3) Challengewaarde, of 4) Transactiegegevens, of 5) Een combinatie van bovenstaande.

c) De dynamische waarde dan wordt omgezet in een OTP of MAC.

d) Op een bepaald punt tijdens het genereren van het OTP of MAC een asymmetrische cryptografische bewerking met een private sleutel (i.e. een encryptie/decryptie of een handtekening) wordt uitgevoerd.

e) de dynamische waarde zo in een OTP of MAC wordt omgezet dat de lengte of grootte van het OTP of MAC kleiner is dan de grootte van het cryptogram dat gegenereerd werd door de asymmetrische cryptografische bewerking met de private sleutel.

[0026] De precieze rol van de asymmetrische cryptografische bewerking met de private sleutel in het hele proces om het OTP of MAC te genereren, kan verschillen naargelang de uitvoeringsvorm.

[0027] In sommige uitvoeringsvormen wordt de asymmetrische cryptografische bewerking met de private sleutel uitgevoerd telkens als er een OTP of MAC gegenereerd moet worden. In andere uitvoeringsvormen kunnen meerdere OTP’s of MAC’s gegenereerd worden bij een enkele asymmetrische cryptografische bewerking met de private sleutel. In het laatstgenoemde geval kunnen de criteria die bepalen of een nieuwe asymmetrische cryptografische bewerking met de private sleutel al dan niet vereist is wanneer een nieuw OTP of MAC moet gegenereerd worden de volgende zijn: a) De tijd die verstreken is sinds de laatste asymmetrische cryptografische bewerking.

b) Het aantal OTP’s en/of MAC’s die al gegenereerd zijn.

c) Of een communicatiesessie tussen een toestel dat de private sleutel bevat en een toestel dat de invoergegevens ophaalt en dat de OTP’s levert al dan niet ononderbroken is verlopen (bv. of een PKI-smartcard al dan niet werd verwijderd uit een smartcardlezer).

d) Het type OTP of MAC. Zo kan het genereren van een MAC altijd een nieuwe asymmetrische cryptografische bewerking vereisen, maar het genereren van een OTP niet.

[0028] In een typische uitvoeringsvorm wordt slechts één private sleutel gebruikt en wordt slechts één asymmetrische cryptografische bewerking uitgevoerd met die private sleutel. Sommige uitvoeringsvormen kunnen echter een aantal cryptografische bewerkingen uitvoeren met ofwel een enkele private sleutel of met meerdere private sleutels. Voorbeelden: a) Indien het OTP een functie is van het encryptieresultaat van de variabele invoergegevens door een private sleutel, dan zou een variant kunnen zijn dat het OTP een functie is van meer dan één cryptogram, of dat de variabele invoergegevens geëncrypteerd zijn door meer dan één private sleutel om het OTP te genereren.

b) Indien het genereren van een OTP slechts plaatsheeft nadat de aanwezigheid van een welbepaalde smartcard geverifieerd is door het resultaat te controleren van een encryptie van een challenge met de private sleutel van de kaart, dan zou een variant kunnen zijn dat meer dan één challenge naar de kaart gestuurd is om te encrypteren met de private sleutel van de kaart.

c) In veel gevallen bevat een PKI-kaart een zogenaamde private identificatiesleutel en een private handtekeningsleutel. in dat geval kan de identificatiesleutel gebruikt worden indien een OTP gegenereerd wordt en de handtekeningsleutel indien een MAC gegenereerd wordt.

[0029] In een te verkiezen uitvoeringsvorm kunnen zowel OTP’s om een gebruiker te authenticeren als MAC’s om gegevens te ondertekenen gegenereerd worden. Andere uitvoeringsvormen daarentegen kunnen enkel in staat zijn om OTP’s te genereren of enkel in staat zijn om MAC-handtekeningen te genereren.

[0030] In een typische uitvoeringsvorm zal het asymmetrische cryptografische algoritme dat met de private sleutel gebruikt wordt het RSA-algoritme zijn. Andere uitvoeringsvormen kunnen echter gebruik maken van andere asymmetrische algoritmes op voorwaarde dat ze in staat zijn tot encrypteren of decrypteren of tot het genereren van handtekeningen met behulp van de private sleutel. Enkele voorbeelden van zulke algoritmes zijn: RSA, knapsack-algoritmes zoals Merkle-Hellman of Chor-Rivest, Pohlig-Hellman, Diffie-Hellman, EIGamal, Schnorr, Rabin, Elliptic Curve cryptosystems, Finite Automaten public key cryptosytems, het Digital Signature Algorithm (DSA, DSS).

[0031] In een typische uitvoeringsvorm zijn de component die de private sleutel bevat en de component die de OTP- en MAC-waarden genereert twee verschillende componenten, die allebei deel uitmaken van twee verschillende toestellen. Er kunnen echter makkelijk uitvoeringsvormen ontworpen worden waarbij deze twee componenten deel uitmaken van hetzelfde toestel of waarbij de twee componenten dezelfde component zijn.

[0032] In een typische uitvoeringsvorm wordt de private sleutel op een smartcard opgeslagen. In een te verkiezen uitvoeringsvorm worden de cryptografische berekeningen met de private sleutel uitgevoerd door die smartcard. In een typische uitvoeringsvorm worden de OTP- en/of MAC-waarden gegenereerd door een toestel dat uitgerust is met of verbonden is met een component of een toestel dat kan communiceren met de smartcard die de private sleutel bevat.

[0033] In een te verkiezen uitvoeringsvorm is de kaartlezer een niet-geconnecteerde smartcardlezer met eigen elektrische voeding, die de geschikte software gebruikt om te communiceren met een PKI-smartcard die ingevoerd wordt in de smartcardlezer teneinde OTP’s of MAC’s te genereren.

[0034] In een andere uitvoeringsvorm is de kaartlezer de combinatie van een toestel zoals een pc, pda, gsm, enz. dat uitgerust is met een smartcardlezer en dat de geschikte software gebruikt om OTP’s of MAC’s te genereren.

[0035] In een typische uitvoeringsvorm zijn de fysische, elektrische en protocollaire aspecten van de communicatie tussen de smartcard en de smartcardlezer identiek aan of vergelijkbaar met diegene die beschreven zijn in de ISO 7816-norm. Andere uitvoeringsvormen kunnen gebruik maken van andere communicatiemiddelen zoals niet-geconnecteerde smartcards zoals beschreven in ISO 14443.

[0036] Er bestaan alternatieve uitvoeringsvormen voor het toestel dat de private sleutel bevat, alsook voor het toestel dat OTP’s of MAC’s genereert. Er bestaan ook alternatieve middelen voor de communicatie tussen de component of het toestel dat de private sleutel bevat enerzijds en de component of het toestel dat OTP’s en MAC’s genereert anderzijds. Deze alternatieven vallen binnen het toepassingsgebied van de uitvinding zoals die hier wordt beschreven.

[0037] In een bepaalde uitvoeringsvorm worden de OTP- of MAC-waarden weergegeven op de display van de kaartlezer. Een OTP kan bv. bestaan uit een reeks symbolen. In een typische uitvoeringsvorm zijn deze symbolen decimale getallen. In andere uitvoeringsvormen kunnen deze symbolen bijvoorbeeld zijn: a) hexadécimale getallen, of b) base64-tekens, of c) tekens uit een schriftsysteem zoals een alfabet, of d) pictogrammen.

[0038] In een bepaalde uitvoeringsvorm worden de gegenereerde OTP’s of MAC’s naar de gebruiker gecommuniceerd door middel van geluidssignalen. Het OTP kan bijvoorbeeld een string van getallen of tekens of woorden zijn die elk beschikken over een kenmerkende toon of die worden voorgelezen door een text-to-speech Converter.

[0039] In een bepaalde uitvoeringsvorm worden de gegenereerde OTP’s of MAC’s rechtstreeks gecommuniceerd naar een toepassing door een al dan niet draadloos communicatiemechanisme. Dit mechanisme kan voorzien zijn van een USB-verbinding of een infraroodverbinding of een Near Field Communication-verbinding of een RF-verbinding of een Bluetooth-verbinding.

[0040] Er kan worden voorzien in andere uitvoermechanismen voor de OTP’s of MAC’s. In sommige uitvoeringsvormen wordt de functie die op de private sleutel gebaseerd is beveiligd door middel van een pincode.

[0041] Hieronder volgt een meer gedetailleerde beschrijving van de basisuitvoeringsvormen. In sommige uitvoeringsvormen wordt de functie van de kaart die op de private sleutel gebaseerd is rechtstreeks of onrechtstreeks gebruikt voor het genereren van de OTP’s of MAC’s. Ofwel a. is een asymmetrische cryptografische bewerking met de private sleutel van de kaart een integrale fase of een deel van de transformatie van de variabele invoergegevens naar een OTP of MAC (waarbij het asymmetrisch algoritme op een symmetrische manier gebruikt wordt), ofwel b. wordt de functie van de kaart die op de private sleutel gebaseerd is op een meer onrechtstreekse manier gebruikt om een seed-waarde te creëren, die gebruikt wordt om een geheime symmetrische sleutel af te leiden die op zijn beurt gebruikt wordt door het algoritme dat de OTP’s en MAC’s genereert. (Een asymmetrisch cryptogram gebruiken als een seed om een geheime sleutel af te leiden).

[0042] In sommige uitvoeringsvormen is de waarde van de OTP’s en/of MAC’s een functie van de eigenlijke waarde van de private sleutel van de kaart. In nog andere uitvoeringsvormen wordt de functie van de kaart die op de private sleutel gebaseerd is gebruikt om het algoritme dat de OTP's of MAC’s genereert vrij te maken in de lezer: a. Ofwel wordt de kaart verbonden met een reeds gepersonaliseerde lezer en herkend op basis van het (de) opgeslagen challenge-response paar(paren), ofwel b. Wordt de kaart geauthenticeerd door de lezer door middel van de gebruikelijke verificatie op basis van PKI-certificaten.

[0043] In de uitvoeringsvormen die beschreven worden in de voorgaande paragraaf is de waarde van de gegenereerde OTP’s en/of MAC’s geen functie van de eigenlijke waarde van de private sleutel van de kaart.

[0044] Bijgevolg voorziet de uitvinding in een aspect in een methode om een beveiligingswaarde te genereren die een One-Time Password (OTP) of een Message Authentication Code (MAC)-handtekening omvat, hetgeen inhoudt: een dynamische tussenwaarde verkrijgen die gecreëerd werd door gebruik van een of meer variabele invoergegevens en een cryptografisch algoritme waarbij minstens één geheim gebruikt wordt; de genoemde dynamische waarde omzetten in de genoemde beveiligingswaarde, waarbij een asymmetrische cryptografische bewerking met een private sleutel wordt uitgevoerd en een cryptogram gecreëerd wordt om de genoemde dynamische waarde te transformeren, en waarbij de genoemde transformatie het produceren omvat van de genoemde beveiligingswaarde met een grootte die kleiner is dan de grootte van een cryptogram dat gegenereerd werd door de genoemde asymmetrische cryptografische bewerking.

[0045] In een ander aspect voorziet de uitvinding in een toestel om een beveiligingswaarde te genereren die een One-Time Password (OTP) of een Message Authentication Code (MAC)-handtekening omvat, waarbij de hierboven beschreven methode gebruikt wordt.

[0046] In een ander aspect voorziet de uitvinding in een methode om een beveiligingswaarde die ingegeven werd door een gebruiker te valideren om zo de gebruiker of gebruikersspecifieke gegevens te authenticeren, waarbij de genoemde beveiligingswaarde een One-Time Password of een Message Authentication Code handtekening is; de genoemde methode omvat hierbij: een referentiecryptogram creëren met een referentie cryptografisch algoritme dat wordt toegepast op één of meer referentie invoergegevens aan de hand van een serversleutel die verbonden is aan een PKI private sleutel van een authentieke gebruiker, waarbij het referentie cryptografisch algoritme en de enkele of meerdere referentie invoergegevens geselecteerd worden als identiek aan overeenkomstige elementen die gebruikt worden bij het creëren van de beveiligingswaarde door de authentieke gebruiker; en vervolgens ofwel enkel het genoemde referentiecryptogram verwerken door het genoemde referentiecryptogram om te zetten naar een referentie beveiligingswaarde met een grootte die kleiner is dan de grootte van het referentiecryptogram en een vergelijking tot stand brengen tussen de genoemde referentie beveiligingswaarde en de genoemde beveiligingswaarde, ofwel zowel het genoemde referentiecryptogram als de genoemde beveiligingswaarde verwerken om tot een gewijzigd referentiecryptogram en een gewijzigde beveiligingswaarde te komen, waarbij de genoemde bewerking met het genoemde referentiecryptogram deels identiek is aan een bewerking die uitgevoerd wordt om de genoemde beveiligingswaarde te creëren, en een vergelijking tot stand brengen tussen het genoemde gewijzigde referentiecryptogram en de genoemde gewijzigde beveiligingswaarde, en de geldigheid van de genoemde beveiligingswaarde bepalen aan de hand van de resultaten van de genoemde vergelijking.

[0047] In nog een ander aspect omvat de uitvinding een door een computer leesbaar medium dat een reeks instructies ondersteunt die bij uitvoering een methode toepassen om een beveiligingswaarde te genereren die een One-Time Password (OTP) of een Message Authentication Code (MAC)-handtekening omvat, waarbij de genoemde methode het volgende omvat: een dynamische tussenwaarde verkrijgen die gecreëerd werd door gebruik van een of meer variabele invoergegevens en een cryptografisch algoritme waarbij minstens één geheim gebruikt wordt; de genoemde dynamische waarde omzetten naar de genoemde beveiligingswaarde, waarbij een asymmetrische cryptografische bewerking met een private sleutel wordt uitgevoerd en een cryptogram gecreëerd wordt om de genoemde dynamische waarde te transformeren, en de genoemde transformatie het produceren omvat van de genoemde beveiligingswaarde met een grootte die kleiner is dan de grootte van een cryptogram dat gegenereerd werd door de genoemde asymmetrische cryptografische bewerking.

[0048] Ten slotte in nog een ander aspect omvat de uitvinding een informatiedragend signaal dat uit een reeks instructies bestaat die bij uitvoering in een processor een methode toepassen om een beveiligingswaarde te genereren die bestaat uit een One-Time Password (OTP) of een Message Authentication Code (MAC) handtekening, waarbij de genoemde methode het volgende omvat: een dynamische tussenwaarde verkrijgen die gecreëerd werd door gebruik van een of meer variabele invoergegevens en een cryptografisch algoritme waarbij minstens één geheim gebruikt wordt; de genoemde dynamische waarde omzetten naar de genoemde beveiligingswaarde, waarbij een asymmetrische cryptografische bewerking met een private sleutel wordt uitgevoerd en een cryptogram gecreëerd wordt om de genoemde dynamische waarde te transformeren, en waarbij de genoemde transformatie het produceren omvat van de genoemde beveiligingswaarde met een grootte die kleiner is dan de grootte van een cryptogram dat gegenereerd werd door de genoemde asymmetrische cryptografische bewerking.

Beknopte omschrijving van de figuren

[0049] Verscheidene uitvoeringsvormen van de uitvinding worden nu verder besproken in de volgende paragrafen van de specificatie en zijn overeenkomstig met de bijgevoegde figuren waarbij:

[0050] Fig. 1 een flowchart is van de bewerking van een token voor sterke authenticatie volgens de stand van de techniek bij het genereren van een OTP of MAC;

[0051] Fig. 2 een flowchart is van de bewerking van een server volgens de stand van de techniek bij het authenticeren van een OTP of een MAC die gegenereerd werd door een token voor sterke authenticatie en de verhouding ervan tot het genereren van de OTP of MAC;

[0052] Fig. 3 een flowchart is van een uitvoeringsvorm van de uitvinding die steunt op een asymmetrische cryptografische bewerking met een PKI private sleutel om een cryptogram te creëren waaruit een OTP of een MAC wordt gegenereerd;

[0053] Fig. 4 een flowchart is van een uitvoeringsvorm van de uitvinding die het genereren toont van het OTP/MAC bij de cliënt (zoals in fig. 3, bijvoorbeeld) en de gerelateerde authenticatie op een server;

[0054] Fig. 5 een flowchart is van een andere uitvoeringsvorm van de uitvinding die een asymmetrisch cryptogram gebruikt als een seed om er een sleutel van af te leiden die gebruikt wordt bij het creëren van een cryptogram dat staat voor een OTP of een MAC;

[0055] Fig. 6 en 7 flowcharts zijn van nog een andere uitvoeringsvorm van de uitvinding waarbij de smartcard gebruikt wordt om de gebruiker te authenticeren bij de lezer, die op zijn beurt een cryptogram creëert waarvan een OTP of MAC wordt afgeleid; in deze uitvoeringsvorm wordt de smartcard van de gebruiker verbonden met de lezer in een initiële bewerking (fig. 6) en de aansluitende bewerking wordt weergegeven in fig. 7;

[0056] Fig. 8 en 9 flowcharts zijn van weer een andere uitvoeringsvorm van de uitvinding waarbij de smartcard, inclusief PKI-certificaat, gebruikt wordt om de gebruiker te authenticeren bij de lezer, die op zijn beurt een cryptogram creëert waarvan een OTP of MAC wordt afgeleid; in deze uitvoeringsvorm kan een willekeurige gebruiker geauthenticeerd worden;

[0057] Fig. 10 en 11 handelingen illustreren die ondernomen worden in een initiële sessie om de informatie op te halen die de bewerking met verscheidene uitvoeringsvormen van de uitvinding toelaat;

[0058] Fig. 12 de context illustreert waarin uitvoeringsvormen van de uitvinding bewerkingen uitvoeren;

[0059] Fig. 13 een illustratie is van een eerste validatieprocedure, en

[0060] Fig. 14 een illustratie is van een andere validatieprocedure. Gedetailleerde Beschrijving

[0061] Belangrijke componenten van uitvoeringsvormen van de uitvinding worden geïllustreerd in Fig. 12 zoals inclusief een smartcardlezer 20 (of simpelweg lezer) en een authenticatieserver 30 (of simpelweg server).

[0062] Minimaal is de lezer 20 uitgerust met een interface 28 om een smartcard te ontvangen en met een elektrische voeding 27. Sommige lezers zijn ook uitgerust met één of meerdere knoppen of toetsen die door de gebruiker kunnen gebruikt worden; dit wordt weergegeven in fig. 12 door het toetsenbord 25. In dit geval schuift een gebruiker een smartcard in de smartcardinterface 28. Ten gevolge van één of andere bewerking die uitgevoerd wordt door de reader 20, wordt informatie gegenereerd door de lezer. Die informatie kan een One-Time Password (OTP) zijn. Als de invoer van de lezer transactiegegevens zijn, kan de informatie die gegenereerd wordt een handtekening bevatten zoals een MAC. De outputinformatie kan worden weergegeven op een display, zoals display 26. De lezer kan ook digitaal verbonden zijn met een netwerk. In dat geval kan de informatie weergegeven worden door een andere entiteit die ook met het netwerk verbonden is en kan display 26 overbodig zijn. Gewoonlijk wordt de informatie die gegenereerd wordt door de lezer 20 gebruikt om een persoon of een boodschap te authenticeren. Een persoon kan geauthenticeerd worden aan de hand van een smartcard (bewijzen dat hij/zij de eigenaar van de kaart is) en andere informatie (zoals een pincode of andere gebruikersgegevens). De lezer aanvaardt de smartcard en andere informatie en creëert een OTP. Het OTP wordt gecommuniceerd naar server 30. In andere gevallen wordt de boodschap getekend door de lezer 20, waardoor een MAC gecreëerd wordt en de MAC gecommuniceerd wordt naar server 30.

[0063] Server 30 wordt doorgaans gebruikt als een computer met verwerkingscapaciteit en een database 35. De informatie die gegenereerd wordt door de lezer wordt gecommuniceerd naar de server 30 via het datapad 40. Datapad 40 kan verschillende vormen aannemen. Doorgaans verzendt de gebruiker handmatig informatie van het display 26 naar een cliënt die verbonden is met de server 30. In een ander geval kan datapad 40 een digitaal pad omvatten om informatie te communiceren van lezer 20 naar lezer 30. In nog een ander geval kan het datapad geluidsinformatie overdragen, zoals een telefooncircuit dat de stem van een gebruiker overbrengt die de informatie uitspreekt die aan de gebruiker getoond wordt op display 26; hierbij kan de informatie een OTP of MAC zijn. Datapad 40 kan optische signalen overdragen die de informatie weergeven die gegenereerd wordt bij lezer 20. Over het algemeen is datapad 40 om het even welk pad dat kan gebruikt worden om informatie te communiceren van de lezer 20 naar de server 30. De server 30 aanvaardt het OTP of MAC en beslist met behulp van gegevens in de database 35 om de informatie te aanvaarden of te weigeren als validatie van de identiteit van de gebruiker (OTP) of de authenticiteit van de boodschap (MAC). De specifieke procedures en gegevens die worden gebruikt door de server 30 worden hieronder meer in detail beschreven. Eén output van de server 30 kiest ervoor status 36 te aanvaarden of te weigeren, wat neerkomt ofwel op de aanvaarding van het OTP als validatie van de authenticiteit van de identiteitsclaim van de gebruiker ofwel op de validatie van de MAC als authenticatie van de bijhorende boodschap.

Het asymmetrisch algoritme op een symmetrische manier gebruiken

[0064] In deze uitvoeringsvorm (zie fig. 3) werkt een smartcard 100 samen met een smartcardlezer 105. Smartcard 100 bewaart een PKI private sleutel 301 die gebruikt wordt in een asymmetrische cryptografische bewerking. De functie van de kaart die op de private sleutel gebaseerd is (i.e. een asymmetrische cryptografische bewerking met de private sleutel van de kaart zoals tekenen of decrypteren) is een integrale fase of deel van het proces dat het OTP of MAC voortbrengt.

[0065] Het genereren van de OTP’s en/of MAC’s gebeurt op de volgende manier:

Stap 99: Invoerwaarden die zullen gebruikt worden in latere stappen worden opgehaald.

Stap 101: de invoerwaarde(n) voor het algoritme dat het OTP of MAC genereert, wordt(en) getransformeerd of geformatteerd in een initiële waarde.

Stap 102: De initiële waarde wordt getekend of geëncrypteerd/ gedecrypteerd door de private sleutel 301 van de kaart.

Stap 103 : het verkregen cryptogram wordt getransformeerd in een OTP of MAC.

[0066] In het voorbeeld in Figuur 3 is het OTP of MAC enkel een functie van het resultaat van de asymmetrische cryptografische bewerking. In andere uitvoeringsvormen kan het OTP of MAC echter ook een functie zijn van andere gegevenselementen inclusief waarden die functies zijn van de variabele invoergegevens maar die geen functies zijn van de private sleutel 301.

[0067] In een typische uitvoeringsvorm zijn de invoergegevens naar het algoritme dat het OTP of MAC genereert dezelfde of gelijkend op de invoergegevens voor het(de) algoritme(n) voor sterke authenticatie die gebruikt worden in traditionele tokens voor sterke authenticatie. Deze invoergegevens kunnen met andere woorden geselecteerd worden als een: tijdswaarde, of challenge (meestal aangereikt door een server), of tellerwaarde, of transactiegegevens, of elke combinatie van de bovenstaande.

[0068] In sommige uitvoeringsvormen kunnen bijkomende invoergegeven(s) of parameter(s) bij het algoritme dat het OTP/MAC genereert de volgende zijn : gegevens die een toestel identificeren (bv. serienummer van een lezer), of geheimen opgeslagen in het toestel, of gebruikersidentificatiegegevens, of geheime codes of geheime waarden geleverd door de gebruiker.

[0069] Deze invoergegeven(s) formatteren naar de initiële waarde, stap 101 kan bewerkingen inhouden zoals :

Aaneenschakeling, of Hashing, of encryptie/ decryptie met een symmetrisch cryptografisch algoritme (bv. Met gebruikmaking van een geheime sleutel die in het toestel opgeslagen is of die geleverd wordt door de gebruiker).

[0070] Het verkregen cryptogram omzetten in het uiteindelijke OTP of MAC-waarde, stap 103 kan de volgende bewerkingen inhouden : hashing (mogelijk een versleutelde hashing met een geheime sleutel die bewaard wordt in de lezer 105 of geleverd wordt door de gebruiker), of encryptie/decryptie met een symmetrisch cryptografisch algoritme (bv. met een geheime sleutel die in de lezer 105 opgeslagen is of die geleverd wordt door de gebruiker), of afkapping, of een selectie van bepaalde bits, nibbles of bytes, of decimalisatie. Dit laatste kan bereikt worden door : de bitstring die moet worden gedecimaliseerd te interpreteren als een grote binaire weergave van een getal, of de bitstring die moet worden gedecimaliseerd op te delen in groepen van bits en iedere groep bits om te zetten in een decimaal getal. Een typisch voorbeeld is de bitstring opdelen in nibbles en iedere nibble omzetten naar een decimaal getal conform de volgende regel. Als de hexadécimale waarde van de nibble 0x0 tot 0x9 is, neem dan het decimaal getal met dezelfde waarde; als de hexadécimale waarde van de nibble OxA tot OxF is, trek een constante af ( tussen 0x6 en OxA ) en neem dan het decimaal getal met dezelfde waarde als het resultaat van de aftrekking, of vele andere decimalisatiealgoritmen die gekend zijn bij vakkundigen.

[0071J Hieronder wordt de validatiefase beschreven. In deze uitvoeringsvorm heeft de server die valideert een kopie van de private sleutel 301 die gebruikt werd om de OTP- of MAC-waarde te genereren en gebruikt die om in essentie hetzelfde algoritme toe te passen als het algoritme dat de OTP of MAC-waarde heeft gegenereerd. De server die valideert: (zie Fig. 4) verkrijgt of reconstrueert of raadt op een of andere manier de waarde(n) van de gegevenselementen die gebruikt werden als invoer voor het algoritme dat het OTP of MAC genereert toen het OTP of MAC werd gegenereerd: in geval van een tijdswaarde, kan de server die valideert zijn eigen klok hebben die gesynchroniseerd is met de klok die gebruikt wordt om het OTP of MAC te genereren, in geval van een challenge, kan de challenge gegenereerd zijn door de server zelf die valideert of kan doorgegeven zijn door de toepassing aan de server die valideert samen met het ontvangen OTP of MAC, in geval van een teller, kan de server die valideert zijn eigen tellerwaarde hebben die gesynchroniseerd is met de tellerwaarde die gebruikt wordt voor het genereren van het OTP of MAC, in geval van transactiegegevens, kunnen deze gegevens naar de server die valideert overgedragen zijn door de toepassing samen met het ontvangen OTP of MAC; de invoer voor het algoritme dat het OTP of MAC genereert, wordt getransformeerd in een initiële waarde.

[0072] De initiële waarde wordt daarna getekend of geëncrypteerd/gedecrypteerd ( 402) met behulp van de kopie van de private sleutel 301 bewaard door de validatieserver. De server die valideert, vergelijkt (403) dan het verkregen referentiecryptogram met de ontvangen OTP- of MAC-waarde. Indien het verkregen referentiecryptogram overeenkomt met de ontvangen OTP- of MAC-waarde, dan wordt de handtekening met succes gevalideerd. Deze vergelijking kan uitgevoerd worden op verschillende manieren:

De validatieserver kan in sommige uitvoeringsvormen het referentiecryptogram omzetten in een referentie OTP- of MAC-waarde en de referentie OTP- of MAC-waarde vergelijken met de ontvangen OTP- of MAC-waarde (bv. door na te gaan of ze identiek zijn), of de validatieserver kan van de ontvangen OTP- of MAC-waarde een deel van het originele cryptogram, gegenereerd door de private sleutel, reconstrueren en dit gedeeltelijke cryptogram vergelijken met het (de) overeenkomstige deel (delen) van het referentiecryptogram, of de validatieserver kan het referentiecryptogram transformeren in een eerste validatietussenwaarde, en het ontvangen OTP of MAC transformeren in een tweede validatietussenwaarde, en dan de eerste en tweede validatietussenwaarde vergelijken.

[0073] Dit kan geïllustreerd worden met het volgende voorbeeld (zie Fig. 14). In dit voorbeeld wordt het OTP of MAC gegenereerd op basis van een cryptogram dat het resultaat is van een asymmetrische encryptie met behulp van een private sleutel 1308. De server produceert een referentiecryptogram dat ook het resultaat is van een asymmetrische encryptie met behulp van een sleutel 1324 die een kopie is van de private sleutel 1308. Zoals voorgesteld in fig.14 - de lezer 1350 berekent het OTP of MAC van het genoemde originele cryptogram door: o elke eerste bit van elke byte van het genoemde verkregen cryptogram (1355) te selecteren, en o de genoemde geselecteerde bits aaneen te schakelen in een bitstring (1356), en o de genoemde bitstring te interpreteren als de binaire interpretatie van een getal en het OTP of MAC te verkrijgen door de decimale weergave van het genoemde getal (1357) te nemen - de validatieserver valideert dit OTP of MAC als volgt: o de server wijzigt het referentiecryptogram door alle bits behalve elke eerste bit van elke byte op 1 te zetten (1364), en o de server interpreteert het ontvangen OTP of MAC als de decimale weergave van een getal en verkrijgt een bitstring door de binaire weergave van dat getal te nemen (1359), en o de server breidt de genoemde bitstring uit door elke bit van de genoemde bitstring te vervangen door een byte die bestaat uit de uitgebreide bit met toevoeging van zeven 1-bits (1360), en, o de server vergelijkt de genoemde uitgebreide bitstring met het genoemde gewijzigde referentiecryptogram (1365).

[0074] De parameters van deze procedure (het kiezen van één bit van elke byte) zijn illustratief. Vakkundigen zullen in staat zijn om de juiste parameter te kiezen die het best bij hun noden en de context past. Meer bepaald, een typische RSA-cryptogram bestaat uit ongeveer 100 bytes. Eén bit van elke byte selecteren zal 100 bits geven. Aan ongeveer 3 bits per decimaal getal zal dit voor het OTP of MAC ongeveer 30 decimale getallen opleveren, wat praktischer is dan 300 decimale getallen, maar wat nog altijd als onhandig kan worden beschouwd. In dat geval kunnen we één bit van elke 40 bits kiezen voor een totaal van 20 bits of ongeveer 6 decimale getallen. Dezelfde procedure voor het genereren van het OTP of MAC van een cryptogram (transformatie door sommige maar niet alle bits van het cryptogram te selecteren) kan ook gebruikt worden wanneer een symmetrische sleutel gebruikt wordt in plaats van de asymmetrische sleutel. Een typisch symmetrisch cryptogram bestaat uit ongeveer 100 bits. Als we in dit geval één bit kiezen van elke acht bits, dan geeft ons dat ongeveer 12 bits of 4 decimale getallen. Dit kan beschouwd worden als een te klein aantal om voldoende beveiliging te bieden tegen aanvallen. Om dit probleem te vermijden, gebruiken we enkel één van elke 4 bits (in plaats van 1 van elke 8) wat ons ongeveer 25 bits of ongeveer 8 decimale getallen oplevert.

[0075] Een andere validatieprocedure wordt geïllustreerd in fig. 13. De procedures in fig. 13 zijn dezelfde procedures als die in fig. 14 voor het produceren van het cryptogram op de cliënt (bewerking 1305) en het referentiecryptogram op de server (bewerking 1323). Zoals weergegeven in fig. 13: het cryptogram wordt omgezet in het OTP of MAC door een opeenvolging van twee transformaties, eerst een transformatie A (1306) en dan een transformatie B (1307).

de validatieserver onderwerpt het referentiecryptogram aan een bewerking 1325 om een gewijzigd referentiecryptogram te produceren, bewerking 1325 is identiek aan de bewerking van transformatie A, de validatieserver onderwerpt ook het OTP of MAC aan een bewerking (1327), die het tegenovergestelde is van transformatie B om een gewijzigd OTP of MAC te creëren, validatie hangt af van een vergelijking (1328) van het gewijzigd OTP of MAC met het gewijzigd referentiecryptogram.

[0076] Wat ook het geval was voor de validatieprocedure in fig. 14, de techniek in fig. 13 kan gebruikt worden ongeacht of het cryptogram gecreëerd is met een symmetrische of asymmetrisch sleutel.

[0077] In tegenstelling tot de traditionele PKI handtekeningverificatie, vraagt de methode in fig. 3 niet dat de volledige handtekening beschikbaar is voor de server (zoals getoond werd in verband met ofwel fig. 13 of 14). De oplossing kan een erg hoge graad van beveiliging leveren, zelfs als er geen bijkomende geheime codes of sleutels (geleverd door de gebruiker of opgeslagen in het toestel) gebruikt worden behalve de private sleutel.

[0078] De techniek in fig. 3 kan echter alleen gebruikt worden als de server die valideert een kopie heeft van de private sleutel van de kaart wanneer het een OTP of MAC moet valideren. De essentie van PKI is nu net dat, om echte onloochenbaarheid te garanderen, de private sleutel nooit toegankelijk is voor een andere persoon dan de gebruiker die verbonden is met die sleutel. In vele gevallen wordt dit gegarandeerd doordat de kaart het private en publieke sleutelpaar genereert op de kaart zonder dat er een mogelijkheid is om de private sleutel van de kaart te halen. In andere gevallen wordt het sleutelpaar extern gegenereerd en daarna op de kaart gezet, maar dan zijn er procedures die normaal gezien verzekeren dat de private sleutel na overzetting naar de kaart in het personaliseringssysteem van de kaart onmiddellijk vernietigd wordt en dat er geen kopie van de private sleutel kan bestaan dan die op de kaart. Deze methode zal met andere woorden in vele gevallen niet een geschikte oplossing zijn.

Een asymmetrisch cryptogram gebruiken als een seed om een geheime sleutel af te leiden (Fia. 51

[0079] In de volgende uitvoeringsvorm, is de voorwaarde dat de validatieserver toegang heeft tot een kopie van de private sleutel op het moment van de validatie verdwenen. In deze uitvoeringsvorm wordt een OTP/MAC op dezelfde manier gegenereerd als in een traditioneel token voor sterke authenticatie. Alle stappen van dit algoritme (de invoergegevens ophalen, de inputgegevens formatteren, de geformatteerde invoergegevens encrypteren of hashen, het verkregen cryptogram of hash transformeren in een OTP/MAC) worden uitgevoerd door de lezer 505. In deze uitvoeringsvorm verschilt de uitvinding van de conventionele praktijk in de manier waarop de lezer 505 de symmetrische geheime sleutel voor sterke authenticatie verkrijgt. Om deze geheime symmetrische sleutel voor authenticatie te verkrijgen, maakt de lezer 505 gebruik van een bewerking van de kaart 500 met de private sleutel van de kaart 510.

De belangrijkste stappen van een basisuitvoeringsvorm van deze methode zijn de volgende : 1. Indien nodig (i.e. de kaart beschermt het gebruik van de private sleutel met een pincode) vraagt de lezer aan de gebruiker om de pincode in te geven en stuurt de lezer die pincode naar de kaart.

2. Als de kaart 500 de pincode aanvaardt, dan stuurt de niet-geconnecteerde kaartlezer een vaste waarde naar de kaart die getekend moet worden door de private sleutel. Aan deze vaste waarde wordt verder gerefereerd als de 'lezer-naar-kaart challenge'.

3. De kaart tekent de gegeven challenge met zijn private sleutel en geeft het verkregen cryptogram terug aan de lezer. Aan dit verkregen cryptogram wordt verder gerefereerd als de 'kaart-naar-lezer handtekeningresponse'.

4. De lezer gebruikt het verkregen cryptogram als een seed om een symmetrische geheime sleutel af te leiden. Aan deze sleutel wordt verder gerefereerd als de ‘afgeleide geheime sleutel voor sterke authenticatie’.

[0080] De lezer personaliseert op een dynamische manier het algoritme voor sterke authenticatie (dat volledig wordt uitgevoerd door de lezer) met die afgeleide geheime sleutel voor sterke authenticatie. Met andere woorden, de lezer voert het algoritme voor sterke authenticatie van het token uit met behulp van de afgeleide geheime sleutel voor sterke authenticatie.

[0081] Fig. 5 illustreert een gepaste uitvoeringsvorm die de interactie van lezer 505 en kaart 500 toont. Tijdens het proces kan de gebruiker gevraagd worden om een pincode 510 in te geven om de kaart 500 te deblokkeren. Deze stap is optioneel maar als hij wordt uitgevoerd, dan wordt de pincode die door de gebruiker bij 501 werd ingegeven, gecommuniceerd 511 naar de kaart 500 om getest te worden. De kaart aanvaardt of weigert de pincode. De response van de kaart 500 wordt getest, 512 en enkel bij aanvaarding wordt het proces voortgezet. Daarna haalt functie 513 alle of enkele invoerwaarden van de lezer op, de gebruiker en de kaart. Functie 514 kan enkele of alle invoerwaarden formatteren. Enkele van of al deze waarden, of andere, kunnen een lezer-tot-kaart challenge 515a vormen die verzonden wordt (functie 515) naar de kaart 500. De kaart 500 gebruikt de challenge 515a door een cryptografische bewerking uit te voeren met de private sleutel van de kaart 510. Het verkregen cryptogram, de kaart-tot-lezer handtekeningresponse 516a, wordt terug gecommuniceerd naar de lezer, functie 516. De response 516a wordt dan gebruikt als een seed om een geheime waarde of sleutel 517a te creëren via functie 517. Sleutel 517a wordt een afgeleide geheime sleutel voor sterke authenticatie genoemd. De sleutel 517a wordt dan gebruikt in een cryptografische bewerking bij functie 518 samen met de geformatteerde waarde die geleverd wordt door functie 514. Uiteindelijk wordt het verkregen cryptogram getransformeerd bij functie 519 om het OTP of MAC te creëren.

[0082] De ‘lezer-tot-kaart challenge’ 515a zou een van de volgende kunnen zijn: 1. Een vaste waarde die dezelfde is voor alle lezers van een bepaalde batch.

2. Een vaste waarde die vast is voor een gegeven lezer maar die een verschillende waarde heeft voor elke lezer.

3. Een vaste waarde die constant is voor een gegeven gebruiker maar die verschillend kan zijn voor verschillende gebruikers en die minstens één keer in de lezer wordt ingevoerd door de gebruiker. In de praktijk is het erg waarschijnlijk dat deze waarde zal ingevoerd worden olwel telkens als de kaart wordt gebruikt, ofwel enkel de eerste keer dat een gegeven kaart met een bepaalde lezer wordt gebruikt en dan zal worden onthouden door de lezer.

4. Statische gegevens opgeslagen op de kaart die kunnen worden gelezen door de lezer (bv. de publieke sleutel en certificaat of het serienummer van een kaart).

5. Een combinatie van de hierboven beschreven mogelijkheden.

6. Een waarde afgeleid van een van de hierboven beschreven mogelijkheden.

De afleiding kan optioneel het gebruik van een of ander geheim van de lezer bevatten.

[0083] Het algoritme om de geheime sleutel voor sterke authenticatie af te leiden van de ‘kaart-tot-lezer handtekeningresponse’ kan (onder andere) gebruik maken van de volgende technieken: 1. Bits uit sommige gegevenselementen extraheren 2. Sommige delen van sommige gegevenselementen aaneenschakelen 3. Symmetrische encryptie/decryptiealgoritmen (bv. DES, AES) 4. Hashing-algoritmen (bv. SHA-1)

[0084] Het algoritme om de geheime sleutel voor sterke authenticatie 517a van de ‘kaart-tot-lezer handtekeningresponse’ 516a af te leiden, kan gebruik maken van de volgende extra gegevenselementen naast de ‘kaart-tot-lezer handtekeningresponse’516a: 1. Een vaste waarde die dezelfde is voor alle lezers van een bepaalde batch.

2. Een vaste waarde die vast is voor een gegeven lezer maar die een verschillende waarde heeft voor elke lezer.

3. Een vaste waarde die constant is voor een gegeven gebruiker maar die verschillend kan zijn voor verschillende gebruikers en die minstens één keer door de gebruiker ingevoerd wordt in de lezer.

4. Statische gegevens opgeslagen op de kaart die kunnen worden gelezen door de lezer (bv. gegevens verbonden met de private sleutel zoals de publieke sleutel en certificaat, of het serienummer van een kaart).

5. Een combinatie van de hierboven beschreven mogelijkheden.

[0085] Deze beschrijving vermeldt enkel het gebruik van een enkele private sleutel van een smartcard en een enkele bewerking met die sleutel; als de kaart meer dan een private sleutel bevat, kan de lezer de ’lezer-tot-kaart challenge' 515a naar elk van die private sleutels op de kaart sturen en de verkregen 'kaart-tot-lezer handtekeningresponses' 516a combineren in de afleiding van de ‘afgeleide geheime sleutel voor sterke authenticatie' 517a.

[0086] Op dezelfde manier kan de lezer ook verschillende ‘lezer-tot-kaart challenge’ waarden 515a naar de kaart sturen en de verkregen 'kaart-tot-lezer handtekeningresponses' 516a combineren in de afleiding van de ‘afgeleide geheime sleutel voor sterke authenticatie’ 517a.

[0087] In nog een andere uitvoeringsvorm doet de lezer geen beroep op een enkele 'lezer-tot-kaart challenge’ 515a en overeenkomstige ‘kaart-tot-lezer handtekeningresponse’ 516a en ‘afgeleide geheime sleutel voor sterke authenticatie' 517a, maar gebruikt in plaats daarvan een reeks ‘lezer-tot-kaart challenges’ 515a en overeenkomstige 'kaart-tot-lezer handtekeningresponses’ 516a en ‘afgeleide geheime sleutels voor sterke authenticatie’ 517a. Om een ‘afgeleide geheime sleutel voor sterke authenticatie’ 577a te verkrijgen, selecteert de lezer een van deze ‘lezer-tot-kaart 515a challenges’ en stuurt die naar de kaart. Welke ‘lezer-tot-kaart challenge’ 515a geselecteerd wordt, bepaalt de overeenkomstige ‘kaart-tot-lezer handtekeningresponse’ 516a en ‘afgeleide geheime sleutel voor sterke authenticatie’ 517a. Daarom moet de selectie gemaakt worden op een manier die door de validatieserver te voorspellen is. De lezer kan bv. de reeks ‘lezer-tot-kaart challenges’ 515a in een vastgelegde volgorde doorlopen of een ‘lezer-tot-kaart challenge’ 515a selecteren afhankelijk van de waarde van de invoer in het algoritme van het token voor sterke authenticatie. Een eenvoudig voorbeeld van de laatstgenoemde methode is dat het algoritme van het token voor sterke authenticatie in challenge-response modus werkt en dat een welbepaald cijfer (bv. het laatste cijfer) van de challenge de index aangeeft van de ‘lezer-tot-kaart challenge’ die gebruikt dient te worden.

[0088] Omdat de private sleutel verschillend is voor elke kaart, zal de afgeleide geheime sleutel voor een gegeven challenge specifiek zijn voor een gegeven kaart. De geheime sleutel die gebruikt wordt in het algoritme voor sterke authenticatie in de lezer is m.a.w. een functie van de kaart (of preciezer nog: van de private sleutel 510 op die kaart). Dit betekent dat men in principe toegang moet hebben tot de juiste kaart om een correct OTP te genereren.

[0089] In de meeste gevallen wordt de private sleutel met een pincode beveiligd, zodat men naast de juiste kaart ook de pincode van de kaart moet hebben om een correct OTP te genereren.

[0090] Als de vaste waarde die de lezer naar de kaart stuurt om door de private sleutel getekend te worden, kan verschillen van lezer tot lezer, dan heeft men naast de andere elementen (bv. de juiste kaart en de pincode van de kaart) ook de juiste lezer nodig. Let wel: een dergelijk gebruik van een waarde die verschillend is voor elke lezer, betekent dat in praktijk de lezer ‘gebonden’ is aan de kaart.

[0091] Om de OTP’s en/of MAC’s voor sterke authenticatie die op die manier gegenereerd zijn te valideren, moet de validatieserver de waarde kennen van de afgeleide geheime sleutel voor sterke authenticatie 517a. Daarvoor moet de server de handtekeningresponse 516a van de kaart kennen. De handtekeningresponse voor een gegeven kaartchallenge wordt bepaald door de private sleutel 510 van de kaart en kan niet berekend worden zonder toegang tot de private sleutel 510. Een gevolg is dat de server minstens één keer toegang moet hebben tot de private sleutel 510 van de kaart (direct of indirect).

[0092] Als het sleutelpaar intern op de kaart gegenereerd wordt, moet de server minstens één keer toegang hebben tot de kaart, zodat de server naar de kaart de kaartchallenge(s) kan sturen die voor deze gebruiker zullen gelden en de kaartresponse(s) op die challenge(s) kan bewaren (indirecte toegang tot de private sleutel). Als het sleutelpaar extern gegenereerd wordt en dan op de kaart gezet wordt, kan de server de private sleutel rechtstreeks gebruiken om de challenge(s) te encrypteren vooraleer de private sleutel buiten de kaart vernietigd wordt.

[0093] Enkel dan kan de server de overeenkomstige afgeleide sleutel voor sterke authenticatie berekenen uit de geëncrypteerde kaartchallenge. Het nadeel hiervan is dat, in de praktijk, ofwel de gebruiker de server toegang moet verlenen tot zijn/haar kaart tijdens een soort registratiefase, ofwel (in geval dat de sleutel extern gegenereerd wordt) de server de challenge moet kunnen encrypteren met de waarde van de private sleutel, vooraleer de waarde van de private sleutel vernietigd wordt.

[0094] Een ander gevolg is dat in de praktijk voor een bepaalde gebruiker de afgeleide geheime sleutel voor sterke authenticatie ongewijzigd moet blijven. Aangezien de afgeleide geheime sleutel voor sterke authenticatie afgeleid wordt van de handtekeningresponse van de kaart op een bepaalde kaartchallenge, moeten die kaartchallenge en de overeenkomstige ‘kaart-tot-lezer handtekeningresponse’ ongewijzigd blijven voor een gegeven gebruiker. Het nadeel hiervan is dat, als een aanvaller de waarde van de ‘kaart-tot-lezer handtekeningresponse’ van een bepaalde gebruiker kent, hij valse kaarten zou kunnen maken die altijd die vastgelegde waarde van de ‘kaart-tot-lezer handtekeningresponse’ geven als de kaart in een lezer wordt ingevoerd.

[0095] Het betrekken van gegevenselementen eigen aan de lezer of de gebruiker bij het genereren van de ‘lezer-tot-kaart challenge’ en/of het afleiden van de ‘afgeleide geheime sleutel voor sterke authenticatie’ uit de ‘kaart-tot-lezer handtekeningresponse’ kan het voor een aanvaller moeilijker maken om de waarde van de correcte ‘kaart-tot-lezer handtekeningresponse’ te verkrijgen of om die waarde samen met een lezer te misbruiken en op een frauduleuze manier correcte OTP’s of MAC’s te genereren.

[0096] Een andere manier om het voor een aanvaller moeilijker te maken om de correcte ‘kaart-tot-lezer handtekeningresponse’ te bekomen is niet een enkele ‘lezer-tot-kaart challenge’ en overeenkomstige ‘kaart-tot-lezer handtekeningresponse’ en ‘afgeleide geheime sleutel voor sterke authenticatie’ gebruiken maar wel een reeks ‘lezer-tot-kaart challenges’ en overeenkomstige ‘kaart-tot-lezer handtekeningresponses’ en ‘afgeleide geheime sleutels voor sterke authenticatie’ zoals hierboven uitgelegd.

[0097] In de volgende uitvoeringsvorm, is het helemaal niet meer nodig dat de server minstens één keer toegang heeft tot de kaart om een bewerking uit te voeren met de private sleutel.

[0098] In deze uitvoeringsvorm hangt de waarde van de symmetrische geheime authenticatiesleutel niet (direct of indirect) af van de waarde van de private sleutel van de kaart. De symmetrische geheime authenticatiesleutel wordt niet afgeleid van een seed dat gegenereerd wordt door de kaart via een asymmetrische cryptografische bewerking met de private sleutel van de kaart. In plaats daarvan wordt de lezer gepersonaliseerd met de symmetrische geheime authenticatiesleutel of met geheime gegevens waaruit de lezer de symmetrische geheime authenticatiesleutel op een dynamische manier kan afleiden. Met deze symmetrische geheime authenticatiesleutel kan de lezer OTP’s of MAC’s genereren net als een traditioneel token voor sterke authenticatie. Het gebruik van de lezer wordt beveiligd en gereserveerd voor de rechtmatige gebruiker door de kaart van de gebruiker op een logische manier met de lezer te verbinden. Eens de kaart van de gebruiker met de lezer verbonden is, zal de lezer enkel een OTP of MAC genereren als de gebruiker de kaart invoert die met de lezer verbonden is. Zo werkt de kaart als een toegangssleutel om de gepersonaliseerde lezer te deblokkeren.

[0099] Bij het eerste gebruik, zal de lezer vragen om de gebruikerskaart in te voeren. Na invoering van de kaart, verbindt de lezer zich op een logische manier als volgt met de ingevoerde kaart. De lezer bepaalt en onthoudt enkele specifieke individuele kenmerken van die kaart. Die kenmerken kunnen zijn: o het serienummer van de kaart o de publieke sleutel en/of het certificaat van de kaart o de response van de kaart op een gegeven challenge (waarbij de response gedefinieerd wordt als de encryptie van de challenge door de private sleutel van de kaart. Let wel: hiervoor moet de gebruiker doorgaans de pincode invoeren om de private sleutel te deblokkeren). Deze challenge en de overeenkomstige response van de kaart moeten onthouden worden door de lezer. De challenge kan zijn: een vaste algemene challenge (dezelfde voor alle kaarten en alle lezers) een vaste challenge per lezer een vaste challenge per kaart (bv. willekeurig door de lezer gegenereerd als de kaart voor het eerst ingevoerd wordt en daarna door de lezer onthouden) een challenge geleverd door de gebruiker een combinatie van de bovenstaande mogelijkheden

[0100] Een voorbeeld van deze bewerking wordt geïllustreerd in fig.6. De lezer 600 wacht op de ontvangst van de gegevens van de kaart (functie 616). De kaart levert enkele gegevens van de kaart 611 aan de lezer (functie 610). Als de lezer de gegevens van de kaart 611 ontvangt, worden die gegevens bewaard (functie 617).

[0101] Als de gebruiker een dynamisch paswoord of handtekening wil genereren (zie fig. 7), vraagt de lezer naar de kaart die met de lezer verbonden werd. De lezer controleert of de ingevoerde kaart ook de verwachte kaart is. De lezer vraagt m.a.w. de kenmerken op van de ingevoerde kaart (functie 710) en vergelijkt ze met de bewaarde kenmerken van de kaart die met de lezer verbonden werd (functie 711). Deze stap kan als volgt verlopen: het serienummer van de kaart lezen de publieke sleutel en/of het certificaat van de kaart lezen een (opgeslagen) challenge naar de kaart sturen om te encrypteren met de private sleutel van de kaart (hierbij kan de gebruiker gevraagd worden zijn pincode in te voeren om de private sleutel te deblokkeren) en de response van de kaart ontvangen.

[0102] Na een succesvolle validatie van de ingevoerde kaart, voert de lezer het algoritme voor sterke authenticatie uit als een gewoon token voor sterke authenticatie.

[0103] Om de beveiliging te verhogen, zijn vele variaties mogelijk. De lezer kan de symmetrische geheime authenticatiesleutel afleiden uit: o een gegevenselement dat vooraf in de lezer werd gepersonaliseerd, o en/of een gegevenselement dat door de gebruiker aan de lezer werd geleverd, o en/of een gegevenselement dat de lezer van de kaart afleest.

[0104] Deze gegevenselementen zijn bij voorkeur geheim. In plaats van steeds dezelfde challenge en overeenkomstige kaartresponse te gebruiken die gebruikt en verkregen werd toen de kaart aan de lezer verbonden werd, kan de lezer meerdere challenge - response paren gebruiken. Variaties op dit principe zijn: o Als de kaart met de lezer verbonden wordt, genereert en stuurt de lezer meer dan één challenge naar de kaart en onthoudt hij de overeenkomstige responses. Als de lezer dan later de kaart moet valideren, kan hij een of andere subset van deze challenges naar de kaart sturen en controleren of de responses van de kaart overeenstemmen met de bewaarde responses.

o Als de lezer de ingevoerde kaart met succes gevalideerd heeft, kan hij een nieuwe challenge genereren en een overeenkomstige response van de kaart verkrijgen. Dit nieuwe challenge-response paar kan dan door de lezer onthouden worden als een alternatief of een bijkomend paar bij de(het) al eerder gekende challenge-response paren(paar).

o Deze beide variaties kunnen worden gecombineerd.

[0105] Het principe van nog een andere uitvoeringsvorm (Fig. 8 en 9) is als volgt. Namens de server authenticeert de lezer de gebruiker lokaal door middel van een traditionele op het certificaat gebaseerde authenticatie van de PKI-kaart van de gebruiker.

[0106] Als de gebruiker met succes geauthenticeerd werd door de lezer, genereert de lezer een OTP of MAC (met behulp van een traditioneel algoritme van een token voor sterke authenticatie) dat door de validatieserver kan gevalideerd worden. De gebruiker kan dan dit OTP of MAC naar de server sturen als bewijs dat hij met succes door de lezer geauthenticeerd werd.

[0107] De lezer authenticeert de gebruiker lokaal met behulp van de door de gebruiker ingevoerde PKI-kaart en traditionele PKI-technologie. In een typische uitvoeringsvorm kan dit als volgt gedaan worden (zie Fig.8): 1. De lezer 800 valideert het certificaat 806 van de kaart (of de keten van certificaten) a. Let wel: hierbij wordt verondersteld dat de lezer toegang heeft tot de betrouwbare publieke sleutel van de (root) Certificaat Autoriteit (CA). Dit kan bereikt worden door de betrouwbare publieke sleutel van de (root) Certificaat Autoriteit in de lezer op te slaan.

b. Let wel: de lezer 800 hoeft niet het hele certificaat (keten) van bij de publieke sleutel van de (root) CA expliciet te controleren telkens als de kaart in de lezer ingevoerd wordt. In plaats daarvan kan de lezer 800 de volledige controle uitvoeren wanneer een kaart 805 voor het eerst in de lezer wordt ingevoerd. De lezer kan vervolgens het geverifieerde certificaat of de publieke sleutel van het certificaat of een referentiewaarde afgeleid van het geverifieerde certificaat of publieke sleutel (bv. een hash van het certificaat of de publieke sleutel) bewaren. Als de kaart 805 later opnieuw ingevoerd wordt, moet de lezer niet meer alle berekeningen met betrekking tot de certificaatvalidatie uitvoeren maar kan hij gewoon het certificaat op de kaart vergelijken met het certificaat of de referentiewaarde die werden opgeslagen in de lezer.

2. De lezer 800 voert een challenge-response authenticatie uit van de private sleutel van de kaart: a. De lezer (810) genereert een challenge 811, bv. typisch een willekeurig nummer of een andere onvoorspelbare waarde die bv. uit een tijdswaarde of tellerwaarde afgeleid wordt met een cryptografisch algoritme met behulp van een geheim dat in de lezer is opgeslagen.

b. De gebruiker geeft de pincode in die de private sleutel van de kaart beveiligt.

c. De lezer 800 stuurt de pincode naar de kaart.

d. De lezer 800 stuurt een willekeurige challenge 811 naar de kaart om door de private sleutel van de kaart geëncrypteerd te worden.

e. De kaart tekent (815) de challenge van de lezer met zijn private sleutel en stuurt de response (= de geëncrypteerde challenge 816) terug.

f. De lezer 800 decrypteert de response van de kaart met de publieke sleutel van de kaart (van het certificaat).

g. De lezer vergelijkt 820 de gedecrypteerde response van de kaart met de initieel gegenereerde challenge. Als de gedecrypteerde response van de kaart dezelfde is als de initieel gegenereerde challenge, dan wordt de private sleutel van de kaart geauthenticeerd en dus ook de gebruiker.

[0108] In essentie genereert de lezer (825) een OTP/MAC op dezelfde manier als een traditioneel algoritme voor sterke authenticatie. Al de stappen van dit algoritme (ophalen van de invoer, formatteren van de invoer, encrypteren of hashen van de geformatteerde invoer, transformeren van het verkregen hashcryptogram in een OTP/MAC) worden door de lezer 800 eigenlijk op dezelfde manier uitgevoerd als door een traditioneel token voor sterke authenticatie. In één uitvoeringsvorm wordt de lezer gepersonaliseerd met een symmetrisch geheime sleutel voor sterke authenticatie. In dat geval is de lezer 800 ook typisch geconfigureerd om een welbepaalde kaart te verwachten. De lezer herkent deze kaart aan de hand van een kenmerkende waarde van een gegevenselement van de kaart. Doorgaans wordt het certificaat van de kaart gebruikt als een dergelijk gegevenselement. In andere uitvoeringsvormen (zie Fig.9), om de lezers niet te moeten personaliseren en configureren, leidt de lezer 800 (835) een kaartspecifieke waarde voor de symmetrische geheime sleutel voor sterke authenticatie af uit de volgende gegevenselementen: o publieke gegevens van de kaart, bij voorkeur gegevens verbonden aan het certificaat of de publieke sleutel van de kaart (bv. het serienummer van de kaart, het serienummer van het certificaat, publieke sleutel, enz.).

o een mastersleutel 846 die in de lezer bewaard wordt en gekend is door de server. Deze mastersleutel kan zijn: een identieke waarde voor alle lezers een specifieke/unieke waarde voor elke individuele lezer. Hierbij moet de lezer op een of andere manier aan de gebruiker toegewezen worden en moet deze toewijzing op de server geregistreerd worden.

o een (optioneel) extra afgeleid gegevenselement kan een (geheim) gegevenselement zijn, dat door de gebruiker aan de lezer wordt geleverd. De gebruiker moet dit gegevenselement expliciet leveren: ofwel telkens als de lezer en de kaart op deze manier gebruikt worden, ofwel enkel wanneer deze kaart de eerste keer gebruikt wordt met deze lezer (daarna onthoudt de lezer de geleverde waarde van het gegevenselement voor deze kaart)

[0109] De lezer 800 gebruikt de afgeleide kaartspecifieke symmetrische authenticatiesleutel 836 in een symmetrisch algoritme voor sterke authenticatie (zoals het Digipass-algoritme of OATH) om een dynamisch paswoord (challenge-response en/of op tijd en/of event gebaseerd) te genereren (845) of om een digitale handtekening van het MAC-type op enkele transactiegegevens (optioneel inclusief tijd en/of event tellerinformatie) te genereren (845).

[0110] Een server valideert het gegenereerde dynamische paswoord of handtekening als volgt: • De server leidt dezelfde kaartspecifieke symmetrische sleutel voor sterke authenticatie af als de lezer. Dit veronderstelt dat de server over een database beschikt (of een alternatieve manier om de vereiste informatie op te halen) die de gebruiker verbindt aan: o de publieke gegevens van de kaart o het gegevenselement geleverd door de gebruiker (indien van toepassing) o en de mastersleutel van de lezer

Let wel: in plaats van deze afleiding telkens uit te voeren bij elke validatie, kan ze ook één keer uitgevoerd worden en kan de verkregen afgeleide sleutel opgeslagen worden in een database voor toekomstig gebruik.

• De server valideert het dynamisch paswoord of handtekening op dezelfde manier als in het geval van een traditioneel token voor sterke authenticatie.

[0111] Een typische uitvoeringsvorm functioneert als volgt (Fig. 10-11):

In een inschrijvingsfase, gaat een bankklant 1001 naar een bankfiliaal 1003. Met behulp van zijn/haar nationale elektronische identiteitskaart (e-ID-kaart 1002) en een BBT (Bank Branch Terminal of bankterminal van het bankfiliaal) ondertekent de klant digitaal een e-bankingovereenkomst 1004.

[0112] Terwijl de e-ID-kaart van de klant in de BBT (1010) ingevoerd wordt, wordt door de BBT: o het certificaat van de klant (1011) opgehaald, o een willekeurige seed challenge (1012) gegenereerd, o de willekeurige seed challenge naar de e-ID-kaart (1002) gestuurd om door de private sleutel van de kaart (1013) gecodeerd te worden, o het cryptogram van de kaart op die challenge (1014) ophalen.

[0113] Ten slotte stuurt de BBT het certificaat van de klant, de gegenereerde seed challenge en het cryptogram van de kaart op de seed challenge naar een server (1015). De server bewaart deze gegevens in een database die aan de klant verbonden is. De bank levert dan een niet-geconnecteerde smartcardlezer aan de klant. Deze lezer bevat een geheime mastersleutel. De bank stuurt de klant ook een PIN mailer (vertrouwelijke envelop met pincode) met de waarde van de seed challenge die gegenereerd en gebruikt werd door de BBT. Op de authenticatieserver wordt de waarde van de geheime mastersleutel eveneens opgeslagen.

[0114] Als de klant de lezer voor het eerst gebruikt: o De lezer vraagt de klant zijn/haar e-l D-kaart in te voeren.

o De lezer vraagt ook de seed challenge uit de PIN mailer en slaat het in zijn geheugen op.

o De lezer leest het certificaat van de kaart en slaat het ook in zijn geheugen op.

o De lezer genereert een willekeurige challenge en stuurt die naar de kaart om geëncrypteerd te worden met de private sleutel van de kaart. De lezer bewaart zowel de challenge van de lezer als het overeenkomstige cryptogram dat gegenereerd werd door de kaart.

[0115] Als de klant een OTP (of MAC of response of ...) wil genereren, dan volgt de lezer de volgende stappen: o De lezer vraagt de klant om zijn/haar e-ID-kaart in te voeren, o De lezer valideert de kaart:

De lezer leest het certificaat van de kaart en vergelijkt het met het opgeslagen certificaat.

Als het resultaat OK is, stuurt de lezer de opgeslagen challenge van de lezer naar de kaart voor een handtekening en vergelijkt het cryptogram van de kaart met het opgeslagen cryptogram.

o Als de lezer de kaart met succes gevalideerd heeft, genereert de lezer de geheime authenticatiesleutel:

De lezer stuurt de opgeslagen seed challenge uit de PIN mailer naar de kaart om door de kaart geëncrypteerd te worden.

De lezer leidt nu een geheime authenticatiesleutel af uit: • de geheime mastersleutel in de lezer, • de seed challenge uit de PIN mailer, • het cryptogram van de kaart op die seed challenge uit de PIN mailer, • het certificaat van de kaart.

o De lezer gebruikt nu de gegenereerde geheime authenticatiesleutel in een algoritme voor sterke authenticatie (bv. om een OTP of MAC te genereren).

[0116] De authenticatieserver kan het verkregen OTP (of MAC) controleren aangezien hij toegang had tot alle gegevens die nodig waren om de geheime authenticatiesleutel te genereren: o de geheime mastersleutel in de lezer, o het certificaat van de kaart, o de challenge uit de PIN mailer, o het cryptogram van de kaart op de challenge uit de PIN mailer.

[0117] Met behulp van de gegenereerde geheime authenticatiesleutel kan de authenticatieserver de OTP’s of MAC’s op dezelfde manier valideren als de OTP’s of MAC’s die gegenereerd werden door traditionele tokens voor sterke authenticatie.

[0118] Anderzijds kan de authenticatieserver een van de procedures volgen zoals getoond in figuren 13 of 14 voor een validatiebewerking.

[0119] Met betrekking tot de procedure van fig. 13, gaan we ervan uit dat het cryptogram dat gegenereerd werd door de lezer getransformeerd wordt in een opeenvolging van transformatie A (1306) en transformatie B (1307). Om te valideren, onderwerpt de server het OTP of MAC aan de omgekeerde transformatie B (1327) om een gewijzigd OTP of MAC te produceren en onderwerpt dan het referentiecryptogram aan transformatie A (1325) om het gewijzigde referentiecryptogram te produceren. Ten slotte maakt de server een vergelijking tussen het gewijzigde referentiecryptogram en het gewijzigde OTP of MAC.

[0120] Met betrekking tot de procedure van fig. 14, gaan we ervan uit dat het cryptogram dat gegenereerd werd door de lezer getransformeerd wordt in een opeenvolging van de bitselectie (1355), aaneenschakeling (1356) en bitstringtransformatie (1357) zoals getoond in fig. 14 om het OTP of MAC te produceren. Om te valideren, onderwerpt de server het OTP of MAC aan de bitstream en expansieprocessen 1359 en 1360 van fig. 14 om een gewijzigd OTP of MAC te produceren. De server onderwerpt het referentiecryptogram aan bewerking 1364 om het gewijzigde referentiecryptogram te produceren. Ten slotte maakt de server om te valideren een vergelijking (1365) tussen het gewijzigde referentiecryptogram en het gewijzigde OTP of MAC.

[0121] In het voorgaande werden verschillende aspecten of uitvoeringsvormen beschreven die methodes of toestellen omvatten. In een ander aspect omvat de uitvinding een reeks instructies opgeslagen op een medium dat leesbaar is door een computer en dat bij uitvoering door een processor de reeds beschreven methodes toepast. Software kan ook geleverd worden via digitale netwerken zoals het internet. Bijgevolg bestaat de uitvinding in nog een ander aspect uit een informatiedragend signaal dat een reeks instructies omvat die bij uitvoering door een processor de reeds beschreven methodes toepassen.

[0122] Hoewel verschillende uitvoeringsvormen van de uitvinding in detail beschreven werden, moet deze beschrijving als voorbeeld en niet exhaustief beschouwd worden; de reikwijdte van de uitvinding moet bepaald worden door de hieraan toegevoegde claims.

Claims (54)

1. Methode om een beveiligingswaarde te genereren die bestaat uit een eenmalig paswoord (One Time Password of OTP) of een digitale handtekening (Message Authentication Code of MAC), omvattende: een dynamische tussenwaarde verkrijgen die gecreëerd wordt met behulp van een of meer variabele invoergegevens en een cryptografisch algoritme dat minstens een geheim gebruikt; de genoemde dynamische waarde transformeren in de genoemde beveiligingswaarde, waarbij een asymmetrische cryptografische bewerking met een private sleutel uitgevoerd wordt en een cryptogram geproduceerd wordt om de genoemde dynamische waarde te transformeren, en de genoemde transformatie de productie van de genoemde beveiligingswaarde omvat met een grootte die kleiner is dan de grootte van een cryptogram dat gegenereerd werd door de genoemde asymmetrische cryptografische bewerking.

2. Methode volgens conclusie met een of meer variabele invoergegevens die een of meer van de volgende zijn: een tijdswaarde; een tellerwaarde; een challengewaarde; transactiegegevens; of een combinatie van de bovenstaande mogelijkheden.

3. Methode volgens conclusie 2 waarbij de genoemde dynamische tussenwaarde gecreëerd wordt met behulp van een of meer van het volgende: gegevens die een toestel identificeren dat de genoemde beveiligingswaarde genereert; of een geheim of geheimen opgeslagen in het toestel dat de genoemde beveiligingswaarde genereert; of gegevens die een gebruiker identificeren van het toestel dat de genoemde beveiligingswaarde genereert; of gegevens verbonden aan de genoemde private sleutel; of een geheim geleverd door de gebruiker van het toestel dat de genoemde beveiligingswaarde genereert.

4. Methode volgens conclusie 2 waarbij: de genoemde transformatie van de genoemde dynamische waarde in de genoemde beveiligingswaarde een of meer van het volgende omvat: hashing; encryptie of decryptie met een symmetrisch cryptografisch algoritme; afkapping; selectie van bepaalde bits, nibbles of bytes; of decimalisatie.

5. Methode volgens conclusie 2 die verder het volgende omvat: een eerste toestel gebruiken om waarden van de genoemde enige of meerdere variabele invoergegevens op te halen en om de genoemde beveiligingswaarde te tonen, een tweede toestel gebruiken om de genoemde private sleutel te bewaren en de genoemde asymmetrische cryptografische bewerking uit te voeren, waarbij het genoemde tweede toestel informatie ontvangt van het eerste toestel en informatie stuurt naar het genoemde eerste toestel, en het genoemde eerste toestel informatie stuurt naar het tweede toestel en informatie ontvangt van het tweede toestel.

6. Methode volgens conclusie 3 die verder het volgende omvat: een eerste toestel gebruiken om waarden van de genoemde enige of meerdere variabele invoergegevens op te halen en om de genoemde beveiligingswaarde te tonen, een tweede toestel gebruiken om de genoemde private sleutel te bewaren en de genoemde asymmetrische cryptografische bewerking uit te voeren, waarbij het genoemde tweede toestel informatie ontvangt van het eerste toestel en informatie stuurt naar het genoemde eerste toestel, en het genoemde eerste toestel informatie stuurt naar het tweede toestel en informatie ontvangt van het tweede toestel.

7. Methode volgens conclusie 5 waarbij: het genoemde eerste toestel een smartcardlezer is met batterijvoeding, een toetsenbord en een display.

8. Methode volgens conclusie 6 waarbij: het genoemde eerste toestel een smartcardlezer is met batterijvoeding, een toetsenbord en een display.

9. Methode volgens conclusie 5 waarbij: het genoemde tweede toestel een smartcard is.

10. Methode volgens conclusie 5 waarbij: het genoemde tweede toestel een USB-stick is.

11. Methode volgens conclusie 5 waarbij: het genoemde eerste toestel een pc of een pda of een gsm is.

12. Methode volgens conclusie 2 waarbij: de genoemde beveiligingswaarde afhankelijk is van de waarde van de genoemde private sleutel.

13. Methode volgens conclusie 12 waarbij: de genoemde beveiligingswaarde een functie is van de waarde van het genoemde cryptogram gegenereerd door de genoemde asymmetrische cryptografische bewerking met de genoemde private sleutel.

14. Methode volgens conclusie 13 waarbij een waarde berekend op basis van minstens één van de genoemde enige of meerdere variabele invoergegevens gebruikt wordt als invoer voor de genoemde asymmetrische cryptografische bewerking, en de genoemde dynamische tussenwaarde een functie is van het verkregen cryptogram geproduceerd door de genoemde asymmetrische cryptografische bewerking.

15. Methode volgens conclusie 13 waarbij voor het berekenen van de genoemde beveiligingswaarde een symmetrisch cryptografisch algoritme gebruikt wordt, waarbij een sleutel gebruikt in het genoemde symmetrisch cryptografisch algoritme afgeleid wordt van het genoemde cryptogram gegenereerd door de genoemde asymmetrische cryptografische bewerking met de genoemde private sleutel.

16. Methode volgens conclusie 5 waarbij: het genoemde eerste toestel een challenge van het eerste toestel naar het genoemde tweede toestel stuurt; het genoemde tweede toestel een asymmetrische cryptografische bewerking uitvoert op de genoemde challenge van het eerste toestel met de genoemde private sleutel en een verkregen cryptogram terugstuurt naar het genoemde eerste toestel; het genoemde eerste toestel het genoemde verkregen cryptogram verifieert; en het genoemde eerste toestel de genoemde beveiligingswaarde genereert op voorwaarde dat de genoemde verificatie van het genoemde verkregen cryptogram succesvol is.

17. Methode volgens conclusie 16 waarbij: de genoemde dynamische tussenwaarde verkregen wordt in een bewerking met behulp van de genoemde enige of meerdere variabele invoergegevens en een symmetrische cryptografische bewerking.

18. Methode volgens conclusie 17 waarbij: de gegevens voor de genoemde symmetrische cryptografische bewerking afgeleid worden van de genoemde enige of meerdere variabele invoergegevens; en de genoemde dynamische tussenwaarde afgeleid wordt van de output van de genoemde symmetrische cryptografische bewerking.

19. Methode volgens conclusie 17 waarbij: de genoemde symmetrische cryptografische bewerking een symmetrisch geheim gebruikt dat afgeleid is van een of meer van het volgende: gegevens die het genoemde eerste toestel identificeren; een geheim of geheimen opgeslagen in het genoemde eerste toestel; gegevens verbonden aan de genoemde private sleutel; gegevens opgeslagen op het genoemde tweede toestel; gegevens die een gebruiker van het genoemde eerste toestel identificeren; of een geheim geleverd door de gebruiker van het genoemde eerste toestel.

20. Methode volgens conclusie 16 waarbij een challenge van het eerste toestel minstens tweemaal aan het genoemde tweede toestel overhandigd wordt en een initieel cryptogram geproduceerd wordt op de genoemde initiële overhandigde challenge en een later cryptogram op een tweede overhandigde challenge: en de genoemde methode verder het volgende omvat: een referentiewaarde afleiden van het genoemde initiële cryptogram; de genoemde referentiewaarde opslaan in het genoemde eerste toestel; en het genoemde latere cryptogram verifiëren door het genoemde latere cryptogram te vergelijken met de genoemde opgeslagen referentiewaarde.

21. Methode volgens conclusie 16 die verder het volgende omvat: in het genoemde eerste toestel minstens één challenge van het eerste toestel bewaren samen met minstens één overeenkomstige verificatiewaarde; en waarbij de genoemde verificatie van het genoemde verkregen cryptogram het vergelijken omvat van het genoemde verkregen cryptogram met de genoemde overeenkomstige verificatiewaarde.

22. Methode volgens conclusie 16 die verder het volgende omvat: tijdens een initieel gebruik van het genoemde eerste toestel met het genoemde tweede toestel een reeks uitvoeren als volgt: minstens één genoemde challenge genereren; de minimaal één genoemde challenge naar het genoemde tweede toestel sturen voor een asymmetrische cryptografische bewerking door het genoemde tweede toestel met behulp van de genoemde private sleutel; van het genoemde tweede toestel minstens één verkregen cryptogram ontvangen; van het genoemde minimaal één verkregen cryptogram een verificatiewaarde afleiden; en de minimaal één genoemde challenge bewaren samen met de genoemde minimaal één verificatiewaarde.

23. Methode volgens conclusie 22 waarbij het genoemde eerste toestel nu en dan een reeks uitvoert als volgt: een nieuwe toestel challenge genereren; de genoemde nieuwe toestel challenge naar het genoemde tweede toestel sturen voor een asymmetrische cryptografische bewerking door het genoemde tweede toestel met behulp van de private sleutel; van het genoemde tweede toestel een overeenkomstig nieuw cryptogram ontvangen; van het genoemde overeenkomstige nieuwe cryptogram een nieuwe verificatiewaarde afleiden; en de genoemde nieuwe challenge van het toestel in het geheugen opslaan samen met de genoemde nieuwe verificatiewaarde.

24. Methode volgens conclusie 23 waarbij: de genoemde nieuwe challenge van het toestel en de genoemde nieuwe verificatiewaarde een vroegere challenge van het toestel en verificatiewaarde vervangen.

25. Methode volgens conclusie 24 waarbij de genoemde reeks uitgevoerd wordt telkens als de genoemde verificatie succesvol is.

26. Methode volgens conclusie 17 waarbij: de genoemde verificatie door het genoemde eerste toestel van het genoemde verkregen cryptogram het gebruik vereist van een publieke sleutel die overeenstemt met de genoemde private sleutel van het genoemde tweede toestel.

27. Methode volgens conclusie 26 waarbij; het genoemde eerste toestel een certificaat of keten van certificaten verifieert dat overeenstemt met de genoemde publieke sleutel.

28. Methode volgens conclusie 27 waarbij: het genoemde eerste toestel een publieke sleutel van een Certificaat Autoriteit in het geheugen opslaat; de genoemde verificatie door het genoemde eerste toestel van het genoemde certificaat of keten van certificaten het gebruik vereist van de genoemde publieke sleutel van de genoemde Certificaat Autoriteit.

29. Toestel dat een beveiligingswaarde genereert die bestaat uit een eenmalig paswoord of One-Time Password (OTP) of een digitale handtekening of Message Authentication Code (MAC) aan de hand van een methode volgens conclusie 2.

30. Toestel volgens conclusie 29 dat een lezer bevat voor. het genereren van een invoergegeven voor de genoemde asymmetrische cryptografische bewerking op basis van de genoemde enige of meerdere variabele invoergegevens, het overbrengen van het genoemde invoergegeven naar de genoemde asymmetrische cryptografische bewerking, en het ontvangen van het verkregen asymmetrisch cryptogram van de genoemde asymmetrische cryptografische bewerking, en het afleiden van de genoemde dynamische tussenwaarde van het genoemde verkregen cryptogram.

31. Toestel volgens conclusie 29 dat een lezer bevat voor: het overbrengen van een invoergegeven naar de genoemde asymmetrische cryptografische bewerking, en het ontvangen van het verkregen asymmetrisch cryptogram van de genoemde asymmetrische cryptografische bewerking, en het afleiden van een symmetrische sleutel van het genoemde verkregen asymmetrisch cryptogram, en het berekenen van de genoemde beveiligingswaarde met behulp van de genoemde symmetrische sleutel met een symmetrisch cryptografisch algoritme.

32. Toestel volgens conclusie 29 dat bevat: een lezer voor: het overbrengen van een challenge van de lezer naar de genoemde asymmetrische cryptografische bewerking, en het ontvangen van het verkregen asymmetrisch cryptogram van de genoemde asymmetrische cryptografische bewerking: en dat ook het volgende ömvat een geheugen voor het bewaren van een referentiewaarde; en dat ook het volgende omvat een processor voor: het verifiëren van het genoemde verkregen asymmetrische cryptogram door het genoemde verkregen asymmetrische cryptogram te vergelijken met de genoemde opgeslagen referentiewaarde, en het genereren van de genoemde beveiligingswaarde op voorwaarde dat de genoemde verificatie van het genoemde verkregen asymmetrische cryptogram succesvol is.

33. Toestel volgens conclusie 29 dat bevat: een lezer voor: het overbrengen van een challenge van de lezer naar de genoemde asymmetrische cryptografische bewerking, en het ontvangen van het verkregen asymmetrische cryptogram van de genoemde asymmetrische cryptografische bewerking; en dat ook het volgende bevat een processor voor: het verifiëren van het genoemde verkregen asymmetrische cryptogram door een publieke sleutel te gebruiken die overeenstemt met de genoemde private sleutel en door een certificaat of keten van certificaten te verifiëren dat overeenkomt met de genoemde publieke sleutel, het genereren van de genoemde beveiligingswaarde op voorwaarde dat de genoemde verificatie van het genoemde verkregen asymmetrische cryptogram succesvol is.

34. Toestel volgens conclusie 33 dat ook een geheugen bevat voor: het opslaan van een publieke sleutel van een Certificaat Autoriteit die gebruikt wordt om het genoemde certificaat of keten van certificaten te verifiëren dat overeenkomt met de genoemde publieke sleutel.

35. Toestel van een van de claims 29, 31 en 32 dat verder een batterijvoeding, een toetsenbord en een display bevat.

36. Toestel volgens conclusie 35 dat verder een smartcard bevat die de genoemde asymmetrische cryptografische bewerking uitvoert.

37. Methode om een beveiligingswaarde te valideren die geleverd wordt door een gebruiker om de gebruiker of gegevens verbonden aan de gebruiker te authenticeren, waarbij de genoemde beveiligingswaarde een One Time Password of een handtekening die bestaat uit een Message Authentication Code omvat; waarbij de genoemde methode het volgende omvat: een referentiecryptogram creëren met behulp van een referentie cryptografisch algoritme toegepast op een of meerdere referentie invoergegevens aan de hand van een serversleutel die een functie is van de waarde van een PKI private sleutel van een authentieke gebruiker, het referentie cryptografisch algoritme en de enige of meerdere referentie invoergegevens geselecteerd als identiek aan de overeenkomstige elementen gebruikt voor het creëren van de beveiligingswaarde door de authentieke gebruiker; vervolgens ofwel enkel het genoemde referentiecryptogram bewerken door het genoemde referentiecryptogram te transformeren in een referentiebeveiligingswaarde waaronder het produceren van de genoemde referentiebeveiligingswaarde met een grootte die kleiner is dan de grootte van het referentiecryptogram en het maken van een vergelijking tussen de genoemde referentiebeveiligingswaarde en de genoemde beveiligingswaarde, ofwel zowel het genoemde referentiecryptogram als de genoemde beveiligingswaarde bewerken om een gewijzigd referentiecryptogram en een gewijzigde beveiligingswaarde te produceren en een vergelijking te maken tussen het genoemde gewijzigde referentiecryptogram en de genoemde gewijzigde beveiligingswaarde, en de geldigheid bepalen van de genoemde beveiligingswaarde op basis van de resultaten van de genoemde vergelijking.

38. Methode volgens conclusie 37 waarbij: de genoemde bewerking op het genoemde referentiecryptogram om het genoemde gewijzigde referentiecryptogram te produceren gedeeltelijk identiek is aan een bewerking die uitgevoerd wordt om de genoemde beveiligingswaarde te creëren.

39. Methode volgens conclusie 37 waarbij het genoemde referentie cryptografisch algoritme een asymmetrisch algoritme is en de genoemde serversleutel dezelfde waarde heeft als de PKI private sleutel van de authentieke gebruiker.

40. Methode volgens conclusie 37 waarbij het genoemde referentie cryptografisch algoritme een symmetrisch algoritme is en de genoemde serversleutel afgeleid is van een cryptogram dat gegenereerd werd met een PKI private sleutel van de authentieke gebruiker.

41. Methode om een beveiligingswaarde te valideren die geleverd wordt door een gebruiker om de gebruiker of gegevens verbonden aan de gebruiker te authenticeren, waarbij de genoemde beveiligingswaarde een One Time Password of een handtekening die bestaat uit een Message Authentication Code omvat en gegenereerd werd volgens de methode van claim 1 ; waarbij de genoemde methode het volgende omvat: een referentiecryptogram creëren met behulp van een referentie cryptografisch algoritme toegepast op een of meerdere referentie invoergegevens aan de hand van een serversleutel, de serversleutel en het referentie cryptografisch algoritme en de enige of meerdere referentie invoergegevens geselecteerd als identiek aan de overeenkomstige elementen gebruikt voor het creëren van de beveiligingswaarde door de authentieke gebruiker, en het genoemde referentiecryptogram bewerken door het genoemde referentiecryptogram te transformeren in een referentiebeveiligingswaarde waaronder het produceren van de genoemde referentiebeveiligingswaarde met een grootte die kleiner is dan de grootte van het genoemde cryptogram dat gegenereerd werd door de genoemde asymmetrische cryptografische bewerking, en de genoemde beveiligingswaarde bewerken om een gewijzigde beveiligingswaarde te produceren, en een vergelijking maken tussen de genoemde referentiebeveiligingswaarde en de gewijzigde beveiligingswaarde, en de geldigheid bepalen van de genoemde beveiligingswaarde op basis van de resultaten van de genoemde vergelijking.

42. Methode volgens conclusie 41 waarbij: de genoemde bewerking op het genoemde referentiecryptogram gedeeltelijk identiek is aan een bewerking die uitgevoerd is om de genoemde beveiligingswaarde te creëren.

43. Door een computer leesbaar medium dat een reeks instructies bevat die bij uitvoering een methode toepassen om een beveiligingswaarde te genereren die bestaat uit een One-Time Password (OTP) of een Message Authentication Code handtekening (MAC), waarbij de genoemde methode het volgende omvat: een dynamische tussenwaarde verkrijgen die gecreëerd wordt met behulp van een of meerdere variabele invoergegevens en een cryptografisch algoritme dat minstens één geheim gebruikt; de genoemde dynamische waarde transformeren in de genoemde beveiligingswaarde, waarbij een asymmetrische cryptografische bewerking met een private sleutel uitgevoerd wordt en een cryptogram geproduceerd wordt om de genoemde dynamische waarde te transformeren, en de genoemde transformatie het produceren omvat van de genoemde beveiligingswaarde met een grootte die kleiner is dan de grootte van een cryptogram dat gegenereerd werd door de genoemde asymmetrische cryptografische bewerking.

44. Door een computer leesbaar medium volgens conclusie 43 waarbij de genoemde een of meer variabele invoergegevens een of meer van de volgende zijn: een tijdswaarde; een tellerwaarde; een challengewaarde; transactiegegevens; of om het even welke combinatie van de voorgaande mogelijkheden.

45. Door een computer leesbaar medium volgens conclusie 44 waarbij het creëren van de genoemde dynamische tussenwaarde het gebruik van een of meer van het volgende omvat: gegevens die een toestel dat de genoemde beveiligingswaarde genereert, identificeert; of een geheim of geheimen opgeslagen in het toestel dat de genoemde beveiligingswaarde genereert; of gegevens die een gebruiker van het toestel dat de genoemde beveiligingswaarde genereert, identificeert; of gegevens verbonden aan de genoemde private sleutel; of een geheim geleverd door de gebruiker van het toestel dat de genoemde beveiligingswaarde genereert.

46. Door een computer leesbaar medium volgens conclusie 44 waarbij: de genoemde transformatie van de genoemde dynamische waarde in de genoemde beveiligingswaarde een of meer van het volgende omvat: hashing; encryptie of decryptie met een symmetrisch cryptografisch algoritme; afkapping; selectie van bepaalde bits, nibbles of bytes; of decimalisatie.

47. Informatiedragend signaal dat uit een reeks instructies bestaat die bij uitvoering in een processor een methode toepassen om een beveiligingswaarde te genereren die bestaat uit een One-Time Password (OTP) of een Message Authentication Code (MAC) handtekening, waarbij de genoemde methode het volgende omvat: een dynamische tussenwaarde verkrijgen die gecreëerd wordt met behulp van een of meerdere variabele invoergegevens en een cryptografisch algoritme dat minstens één geheim gebruikt; de genoemde dynamische waarde transformeren in de genoemde beveiligingswaarde, waarbij een asymmetrische cryptografische bewerking met een private sleutel uitgevoerd wordt en een cryptogram geproduceerd wordt om de genoemde dynamische waarde te transformeren, en de genoemde transformatie het produceren omvat van de genoemde beveiligingswaarde met een grootte die kleiner is dan de grootte van een cryptogram dat gegenereerd werd door de genoemde asymmetrische cryptografische bewerking.

48. Informatiedragend signaal volgens conclusie 47 waarbij de genoemde een of meer variabele invoergegevens een of meer van de volgende zijn: een tijdswaarde; een tellerwaarde; een challengewaarde; transactiegegevens; of om het even welke combinatie van de voorgaande mogelijkheden.

49. Informatiedragend signaal volgens conclusie 48 waarbij het creëren van de genoemde dynamische tussenwaarde het gebruik van een of meer van het volgende omvat: gegevens die een toestel dat de genoemde beveiligingswaarde genereert, identificeert; of een geheim of geheimen opgeslagen in het toestel dat de genoemde beveiligingswaarde genereert; of gegevens die een gebruiker van het toestel dat de genoemde beveiligingswaarde genereert, identificeert; of gegevens verbonden aan de genoemde private sleutel; of een geheim geleverd door de gebruiker van het toestel dat de genoemde beveiligingswaarde genereert.

50. Informatiedragend signaal volgens conclusie 48 waarbij: de genoemde transformatie van de genoemde dynamische waarde in de genoemde beveiligingswaarde een of meer van het volgende omvat: hashing; encryptie of decryptie met een symmetrisch cryptografisch algoritme; afkapping; selectie van bepaalde bits, nibbles of bytes; of decimalisatie.

51. Methode om meerdere gebruikers te authenticeren waarbij elke gebruiker minstens één met zichzelf verbonden smartcard heeft; waarbij de genoemde smartcards minstens één PKI private sleutel bevatten en asymmetrische cryptografische bewerkingen met de genoemde PKI private sleutel kunnen uitvoeren ; waarbij de genoemde methode bestaat uit de volgende stappen: een serversleutel genereren voor elke smartcard verbonden met een gebruiker, en van de genoemde gebruikers beveiligingswaarden ontvangen die OTP’s of MAC’s bevatten, en de genoemde gebruikers authenticeren door de genoemde ontvangen beveiligingswaarden te valideren volgens de methode van claim 41 met behulp van de genoemde serversleutel.

52. Methode volgens conclusie 51, die de volgende stappen omvat: voor elke gebruiker een challenge sturen naar de genoemde smartcard die verbonden is met de genoemde gebruiker voor een asymmetrische cryptografische bewerking met de genoemde private sleutel op de genoemde smartcard, en van de genoemde smartcard het verkregen cryptogram op de genoemde smartcard ontvangen, en het genoemde verkregen cryptogram verkregen met de genoemde private sleutel op de genoemde smartcard gebruiken voor het genoemde genereren van de genoemde serversleutel.

53. Methode volgens conclusie 51 die de volgende stappen omvat: een of meer seeds genereren om een geheime sleutel af te leiden, en minstens één van de genoemde seeds om een geheime sleutel af te leiden, gebruiken voor het genoemde genereren van de genoemde serversleutel, en aan de genoemde gebruikers de genoemde minimaal een van de genoemde seeds om een geheime sleutel af te leiden communiceren die gebruikt werden voor het genoemde genereren van de genoemde serversleutels voor de genoemde smartcards verbonden met deze gebruikers.

54. Methode volgens conclusie 51 die de volgende stappen omvat: gegevens verkrijgen van een certificaat opgeslagen op de genoemde smartcard verbonden met elk van de genoemde gebruikers, en de genoemde gegevens van het genoemde certificaat gebruiken voor het genoemde genereren van de genoemde serversleutel.