NO341998B1 - System, fremgangsmåte og anordning for muliggjøring av vekselvirkning med dynamisk sikkerhet - Google Patents

Abstract

Kodegenereringsenhet (6a-c) for aktivering av interaksjon med dynamisk sikkerhet mellom en bruker (2a-c) og en leverandør av transaksjonstjenester (3), nevnte kodegenereringsenhet (6a-c) har: informasjon innhentningsmidler (51, 52), og prosesseringskretser (60) konfigurert til: å motta, via informasjonsinnhentningsmodulene (51, 52), en transaksjonsspesifikk kode som genereres av at leverandøren av transaksjonstjenester (3); evaluere nevnte transaksjonsspesifikke kode, utføre, basert på nevnte evaluering av transaksjonsspesifikke kode, en transaksjonsspesifikk sekvens av forutbestemte funksjoner, hver som involverer å spørre nevnte bruker (2a-c) å indikere en respektiv funksjonsrelatert verdi, noe som resulterer i en sekvens av funksjonsrelatert verdier angitt med brukeren, og avgjøre en transaksjonsspesifikk responskode basert på nevnte sekvens av funksjonsrelaterte verdier, og dermed muliggjøre sikker autentisering av nevnte transaksjon.

Description

Teknisk felt

Den foreliggende oppfinnelsen omhandler en kodegenereringsenhet for å muliggjøre samhandling med dynamisk sikkerhet mellom en bruker og en leverandør av transaksjonstjenester. Oppfinnelsen vedrører også et transaksjonsserversystem og en sikker transaksjon som omfatter en slik kodegenereringsenhet og et slikt transaksjonsserversystem.

Oppfinnelsen vedrører videre en metode for samhandling med dynamisk sikkerhet mellom en leverandør av transaksjonstjenester og en bruker som har en kodegenereringsenhet.

Teknisk bakgrunn

De nyeste iverksatte systemene for sikre online-transaksjoner, for eksempel online-banktjenester, behandler alle transaksjoner på samme måte, uavhengig av risikoen knyttet til transaksjonen. Når denne tradisjonelle tilnærmingen er brukt, må en leverandør av transaksjonstjenester foreta en avveining mellom enkel bruk og risiko. Gjennom en slik avveining, risikerer leverandøren av transaksjonstjenester å miste kunder hvis for strenge sikkerhetstiltak er gjennomført, eller tape betydelige pengebeløp og kundetillit hvis sikkerheten er for ettergivende.

US 2005/0097320 beskriver en dynamisk transaksjonsmetode og et system som benytter risiko-autentisering som et alternativ til de tradisjonelle, statiske transaksjonssystemene.

I henhold til fremgangsmåten vist i US 2005/0097320, er nivået på godkjenning for en bestemt transaksjon satt avhengig av en risikovurdering av transaksjonen og/eller en av partene i transaksjonen. Ifølge US 2005/0097320, kan nivået på autentiseringen heves ved å kreve at en bruker legger inn personlige detaljer og kontodetaljer etc. og/eller ved å sende en engangskode til brukeren via en alternativ kommunikasjonskanal, for eksempel på SMS.

Men siden den dynamiske sikkerheten i dette systemet er basert på et sett med data som tidligere er hentet inn fra brukeren, er fleksibilitet i systemet begrenset av mengden av tidligere innsamlet data. Videre må tidligere innsamlet data samles i et virkelig sikkert miljø, noe som vanligvis innebærer kostbar og intrikat administrasjon.

Videre blir den dynamiske sikkerheten i henhold til US 2005/0097320 gjennomført ved å sende autentiseringsinformasjon av spørsmål-og-svar-typen over internett, der det alltid er en risiko for at svindlere avskjærer kommunikasjonen eller innhenter godkjenningsinformasjon ved å utgi seg for å være leverandøren av transaksjonstjenester (såkalte "pharming").

WO 02/082387 beskriver et system og en fremgangsmåte for å utføre elektroniske transaksjoner. Systemet omfatter en server for å generere en oppfordring basert på en transaksjonsforespørsel. Oppfordringen, liksom annen informasjon vedrørende transaksjonen, sendes til en personlig mobil enhet som omfatter en sikker maskinvaremodul. Den sikre maskinvaremodulen mottar informasjon vedrørende transaksjonen, ber brukeren å godta transaksjonen og oppgi en PIN, og beregner et svar som sendes tilbake til serveren. Serveren verifiserer svaret og godtar eller avslår transaksjonen basert på svaret.

Sammenfatning av oppfinnelsen

I lys av ovennevnte og andre ulemper ved den tidligere kjente teknikken, er det et generelt formål med denne oppfinnelsen å skaffe til veie et forbedret transaksjonssystem med dynamisk sikkerhet.

I henhold til et første aspekt av denne oppfinnelsen, oppnås disse og andre formål med en kodegenererende anordning ifølge krav 1.

Med "leverandør av transaksjonstjenester" menes i forbindelse med den foreliggende søknaden enhver enhet som gjør at en registrert bruker kan utføre en hvilken som helst form for transaksjon. Eksempler på leverandører av transaksjonstjenester er for eksempel banker, myndigheter, aksjemeglere etc. Leverandører av transaksjonstjenester er vanligvis virkeliggjort ved et transaksjonsserversystem som er konfigurert til å samhandle med sine brukere over et nettverk.

Typiske transaksjoner omfatter for eksempel innlogging, overføring av midler, betaling, etc.

Følgelig skal en transaksjonsspesifikk kode forstås som en kode som er utarbeidet av leverandøren av transaksjonstjenester i forbindelse med en forespørsel om en bestemt transaksjon. "Midler for å hente inn informasjon" er midler for å hente opplysninger inn i kodegenereringsenheten, og kan omfatte en eller flere av for eksempel et tastatur, et kamera, en strekkodeskanner, et grensesnitt for kablet eller trådløs kommunikasjon etc. Den foreliggende oppfinnelsen er basert på erkjennelsen av at et høyt overordnet nivå av sikkerhet i kombinasjon med enkel bruk i et online transaksjonssystem kan oppnås ved å dynamisk kontrollere sikkerhetsnivået basert på den estimerte risikoen for transaksjonen. Oppfinneren har dessuten innsett at en slik dynamisk kontroll av sikkerhetsnivået med fordel kan oppnås ved å bestemme, hos leverandøren av transaksjonstjenesten, en transaksjonsspesifikk grad av interaksjon mellom en bruker og hans personlige kodegenereringsenhet. Denne "fjernkontrollen" av samspillet mellom brukeren og hans kodegenereringsenhet oppnås i henhold til den foreliggende oppfinnelsen ved koding, i den transaksjonsspesifikke koden som tilbys av leverandøren av transaksjonstjenesten, av en sekvens av forhåndsbestemte funksjoner som skal utføres av kodegenereringsenheten.

Hver av disse forhåndsbestemte funksjonene innebærer å be brukeren å angi en funksjonsrelatert verdi. Et eksempel på en slik forhåndsdefinert funksjon kan være å be brukeren om å angi en verdi, som for eksempel kan være knyttet til transaksjonen, eller være relatert til identiteten til brukeren, ved å gi verdien via midlene for å hente inn informasjon. Et annet eksempel på en forhåndsdefinert funksjon kan være å be brukeren om å godta en melding som vises til brukeren, der en verdi som representerer denne meldingen er angitt av brukeren.

Funksjonsrelaterte verdier kan dermed for eksempel inkludere verdier som er indikative for transaksjonsspesifikke detaljer, slik som beløp, destinasjonskontonummer osv., verdier som er indikative for brukerspesifikke detaljer, slik som brukerens personnummer, telefonnummer osv, og brukerens PINkode; verdier som er indikative for meldinger som vises til brukeren, som kan forholde seg til den type valgte transaksjon, som internasjonale overføringer, endring av personlig informasjon osv.

Etter angivelsen av den siste funksjonsrelaterte verdien, fastsettes responskoden basert på rekkefølgen av funksjonsrelaterte verdier angitt av brukeren. Herved kan svarkoden, avhengig av sikkerhetsnivået som kreves av leverandøren av transaksjonstjenesten, indikere brukernærvær, brukerbevissthet om detaljene i transaksjonen, tidspunkt for transaksjonen, brukeridentitet osv.

Dersom risikoen for transaksjonen antas å være lav, kan brukeren bli bedt om å bare legge inn den handelsspesifikke koden og sin PIN inn i kodegenereringsenheten, hvoretter kodegenereringsenheten genererer en svarkode for signering av transaksjonen. I dette tilfellet dannes den transaksjonsspesifikke sekvensen av at den enkle forhåndsbestemte funksjonen ber om oppføring av brukerens PIN-kode, og den transaksjonsspesifikke responskoden fastsettes basert på den transaksjonsspesifikke koden og PIN angitt av brukeren.

Ved et middels risikonivå kan en forhåndsbestemt melding vises til brukeren, og brukeren kan bli bedt om å bekrefte innholdet i meldingen, som kan innebære hans hensikt å utføre for eksempel en internasjonal overføring av midler, ved å trykke "OK" på tastaturet på kodegenereringsenheten og deretter taste inn sin PIN i kodegenereringsenheten, hvoretter kodegenereringsenheten genererer en svarkode basert på en verdi som indikerer den forhåndsbestemte meldingen og brukerens PIN-kode.

Til slutt, i tilfelle en høyrisikotransaksjon, kan brukeren bli bedt om å aktivt legge inn, i kodegenereringsenheten, informasjon som destinasjonskonto, valuta, beløp, og til slutt sin PIN, før kodegenereringsenheten beregner en svarkode som indikerer sekvensen av funksjonsrelaterte verdier angitt av brukeren.

Hvilken sekvens av funksjoner som bør utføres av kodegenereringsenheten bestemmes i henhold til den foreliggende oppfinnelsen av den transaksjonsspesifikke koden presentert av leverandøren av transaksjonstjenesten. Det bør her bemerkes at brukeren ikke trenger å ha noen kunnskap om - og er faktisk typisk uvitende om - hvilken rekkefølge av forutbestemte funksjoner som den transaksjonsspesifikke koden representerer.

Brukeren kan dermed utføre signeringstrinnene "off-line" i trygge omgivelser med sin egen kodegenereringsenhet. Dette reduserer risikoen for at brukeren ved en feil utfører en transaksjon at han ikke har til hensikt å utføre. Videre er praktisk talt alle typer av såkalte man-in-the-middle angrep forhindret.

Videre er verdier som indikerer disse signeringstrinnene inkludert i den resulterende svarkoden, hvor en meget sterk og sikret Act-of-will på vegne av brukeren kan formidles til leverandøren av transaksjonstjenester. Dette gir leverandøren av transaksjonstjenester en styrket ikke-avvisning av transaksjonen.

Oppsummert gjør evnen kodegenereringsenheten har for å gjenkjenne og reagere på en "sikkerhetsnivåkode" som inngår i den transaksjonsspesifikke koden, det mulig for leverandøren av transaksjonstjenester, for eksempel en bank, å iverksette de strengeste sikkerhetstiltakene der disse er nødvendige, og prioriterer brukerbekvemmelighet for transaksjoner som anses å innebære en lavere risiko.

Den transaksjonsspesifikke koden kan med fordel omfatte en første underkode som er beskrivende for den transaksjonsspesifikke sekvensen av forhåndsdefinerte funksjoner, og en andre underkode som kan være en funksjon av den første underkoden, og prosesseringskretsene kan videre være konfigurert til å vurdere den andre underkoden for å verifisere riktigheten av den første underkode.

Herved kan kodegenereringsenheten være forhindret fra å svare på en feilaktig oppføring av den transaksjonsspesifikke koden ved å starte en sekvens av forutbestemte funksjoner, noe som ikke samsvarer med den forespurte transaksjonen. Dette øker brukerens tillit til kodegenereringsenheten.

Videre kan den transaksjonsspesifikke koden inneholde en oppfordringsverdi som er beskrivende for tidspunktet for transaksjonen. For eksempel kan oppfordringsverdien angi økten som inneholder transaksjonen.

Kodegenereringsenheten i henhold til den foreliggende oppfinnelse kan dessuten med fordel konfigureres til å samhandle med en kryptografisk modul, og å utnytte denne kryptografiske modulen for å bestemme den ovennevnte transaksjonsspesifikke responskoden.

Den "kryptografiske modulen" er en programvare- eller hardwaremodul som er tilpasset enten å kryptere, dekryptere eller bestemme en meldingsgodkjenningskode via data. Den kryptografiske modulen kan implementere hvilke som helst kryptografiske algoritmer, symmetriske, asymmetriske eller kryptografiske hash-funksjoner. Eksempler på en symmetrisk kryptografisk algoritme kan for eksempel inkludere en trippel-DES MAC, og eksempler på en asymmetrisk kryptografisk algoritme kan for eksempel inkludere en hemmelig / offentlig nøkkelpartilnærming ofte referert til som "public key infrastructure". Et eksempel på en kryptografisk hash-funksjon er SHA-1.

Kodegenereringsenheten kan videre omfatte en kobling for å tilkoble prosesseringskretsen til en fjernbar elektronisk krets som inneholder den kryptografiske modulen.

I denne utførelsesformen kan den kryptografiske modulen knyttet til brukeren fortrinnsvis være i form av en flyttbar elektronisk krets, som den sikre kretsen på et såkalt smart-kort, hvor kodegenereringsenheten har en kobling konfigurert til å aktivere kommunikasjonen mellom prosesseringskretsen som befinner seg i kodegenereringsenheten og den flyttbare elektroniske kretsen.

Alternativt kan kodegenereringsenheten omfatte et trådløst grensesnitt for å muliggjøre trådløs kommunikasjon med en ekstern kryptografisk modul. Ifølge et ytterligere alternativ, kan den kryptografiske modulen befinne seg i prosesseringskretsene.

I alle fall inneholder den kryptografiske modulen en representasjon av en bruker-spesifikk hemmelig kryptografisk nøkkel som kan benyttes til å dekryptere krypterte meldinger fra leverandøren av transaksjonstjenestene. For å muliggjøre en slik overføring av kryptert informasjon, bør brukeren og leverandøren av transaksjonstjenesten, på tidspunktet for transaksjonen, ha et etablert forhold. Spesielt bør begge parter helst ha tilgang til en kryptografisk nøkkel knyttet til den andre, for eksempel en felles hemmelig nøkkel i et symmetrisk kryptografisk system, eller den offentlige nøkkelen til den andre parten i situasjonen med asymmetrisk offentlig nøkkelinfrastruktur.

Kodegenereringsenheten kan dessuten konfigureres til å dekryptere kryptert transaksjonsinformasjon omfattet i den transaksjonsspesifikke koden, og vise dekryptert transaksjonsinformasjon til brukeren ved hjelp av en skjermenhet som befinner seg i kodegenereringsenheten. Herved kan den bekreftes av brukeren, i det sikre og pålitelige miljøet til sin egen kodegenereringsenhet i samspill med sine personlige kryptografiske moduler, at leverandøren av transaksjonstjenester er ekte og/eller at transaksjonen som skal utføres, faktisk er den som ble forespurt.

Ifølge en utførelsesform kan midlene for å innsamle informasjon som befinner seg i kodegenereringsenheten, inneholde en bildeervervingsenhet, og prosesseringskretsen som befinner seg i kodegenereringsenheten, kan videre konfigureres til å hente, gjennom bildeervervingsenheten, et bilde gitt av leverandøren av transaksjonstjenestene. Dette bildet kan videre kode den ovenfor nevnte transaksjonsspesifikke koden. "Bildeervervingsenheten" kan være en enhet i stand til å tilegne seg bildeinformasjon, slik som for eksempel en kameramodul (inkludert en bildebrikke og muligens et optisk element, slik som et objektiv), eller en enkel skanner, for eksempel en strekkodeleser.

Bildet som koder den transaksjonsspesifikke koden, kan vises på en displayenhet eller skrives ut på et transaksjonsdokument, for eksempel en pengeoverføringsbestilling.

Ved bruk av kodegenereringsenheten i henhold til denne utførelsen kan brukeren enkelt og uten problemer overføre informasjon, som kan være kryptert eller ikke, fra leverandøren av transaksjonstjenester til kodegenereringsenheten. Dette gjør det mulig å kontrollere og vurdere informasjon i det sikre miljøet til sin egen kodegenereringsenhet.

Ved å erverve en transaksjonsspesifikk kode, for eksempel en oppfordringskode i forbindelse med en transaksjon, som et bilde, vil det ikke bli oppfattet som anstrengende eller kjedelig for en bruker å signere transaksjonen.

Videre blir risikoen for feil input praktisk talt fjernet. Følgelig kan den foreliggende oppfinnelsen gjøre det mulig for leverandøren av transaksjonstjenester å opprettholde et høyt sikkerhetsnivå (for eksempel gjennom en utvidet lengde på den transaksjonsspesifikke koden) på en brukervennlig måte.

I tillegg er risikoen for såkalte skuldersurfing (en annen person enn brukeren får tilgang til transaksjonsinformasjonen ved å "se over skulderen" til brukeren) praktisk talt eliminert, siden bare brukeren vanligvis er i stand til å få bildet dekodet og, avhengig av applikasjon, dekryptert.

Ifølge et andre aspekt ved denne oppfinnelsen, oppnås det ovenfor nevnte og andre formål med et transaksjonsserversystem ifølge krav 13.

Effekter og trekk av dette andre aspektet ved denne oppfinnelsen er stort sett analoge med de som er beskrevet ovenfor i forbindelse med den første utførelsesformen.

Kodegenereringsenheten og transaksjonsserversystemet i henhold til den foreliggende oppfinnelsen kan dessuten inngå i en sikker systemtransaksjon, videre omfattende et brukerkommunikasjonsverktøy som er i forbindelse med transaksjonsserversystemet.

Kommunikasjonsenheten til brukeren kan konfigureres til å vise et bilde til brukeren, og å motta transaksjoner relatert til input fra brukeren.

Ifølge en utførelsesform, kan kommunikasjonsenheten til brukeren være en personlig datamaskin. Dette er typisk tilfellet for elektroniske banksystemer, der brukeren håndterer sine kontoer og utfører transaksjoner, for eksempel betaling av regninger, over internett.

Ifølge en annen utførelsesform kan kommunikasjonsenheten til brukeren være en mobiltelefon eller en personlig digital assistent. Ifølge enda en utførelsesform kan kommunikasjonsenheten til brukeren være en minibank (ATM).

Ifølge et tredje aspekt av denne oppfinnelsen oppnås den ovenfor nevnte og andre formål med en metode ifølge krav 20.

I tillegg oppnås de ovennevnte og andre formål med en dataprogrammodul konfigurert til å utføre trinnene til fremgangsmåten i henhold til den foreliggende oppfinnelsen når det kjøres på prosesseringskretser som befinner seg i en kodegenereringsenhet i henhold til oppfinnelsen.

Kort beskrivelse av figurene

Disse og andre sider ved den foreliggende oppfinnelsen vil nå bli beskrevet mer i detalj, med henvisning til de vedlagte figurene som viser en foreløpig foretrukket utførelsesform av oppfinnelsen, hvor:

Figur 1 viser skjematisk en sikker systemtransaksjon i henhold til den foreliggende oppfinnelsen.

Figur 2 er en skjematisk illustrasjon av utvekslingen av informasjon mellom en bruker og en leverandør av transaksjonstjenester og mellom brukeren og en kodegenereringsenhet i henhold til den foreliggende oppfinnelsen når man utfører en transaksjon;

Figur. 3 er et flytdiagram som skjematisk illustrerer en transaksjonsautorisasjonsmetode utført av transaksjonsserversystemet i figur 1.

Figur 4 er et flytdiagram som skjematisk illustrerer en utfrelsesform av metoden i henhold til den foreliggende oppfinnelsen og dens forhold til transaksjonsautorisasjonsmetoden i figur 3.

Figur 5 er en skjematisk planvisning av en kodegenereringsenhet i henhold til en utførelsesform av den foreliggende oppfinnelsen sett forfra og fra siden.

Figur 6 er et skjematisk blokkdiagram av kodegenereringsenheten i figur 5; Figur 7 er en skjematisk illustrasjon av et eksempel på et visningsbilde for å vise til en bruker med en kodegenereringsenhet med en bildeinnhentningsenhet;

Figur 8 er et flytdiagram som skjematisk illustrerer en utførelsesform av metoden utført som svar på displaybildet i figur 7, og

Figur 9 er et flytdiagram som skjematisk illustrerer en utførelsesform av metoden i henhold til den foreliggende oppfinnelsen utført som svar på displaybildet i figur 7.

Detaljert beskrivelse av en foretrukket utførelsesform av oppfinnelsen I den følgende beskrivelse er den foreliggende oppfinnelsen beskrevet under henvisning til et sikkert transaksjonssystem der hver bruker er i sikker forbindelse med et transaksjonsserversystem gjennom en Internett-tilkoblet PC. Videre er kodegenereringsenheten utstyrt med en skjerm og et tastatur.

Det bør bemerkes at dette på ingen måte begrenser omfanget av denne oppfinnelsen, som er like aktuell for å sikre transaksjonssystemer der brukerne er tilkoblet leverandøren av transaksjonstjenestene gjennom andre typer av brukerkommunikasjonsenheter, for eksempel mobiltelefoner eller minibanker (ATM), eller der ulike brukere benytter ulike typer av brukerkommunikasjonsenheter.

I tillegg kan kodegenereringsenheten ha hvilken som helst annen form for brukerinput på andre måter enn et tastatur, for eksempel en touch-skjerm, et såkalt klikkehjul etc.

Figur 1 viser skjematisk et sikkert transaksjonssystem 1, hvor hver av et mangfold av brukere 2a-c kommuniserer med en leverandør av transaksjonstjenester, her vist som et transaksjonsserversystem 3, gjennom sine respektive personlige datamaskiner 4a-c som er tilknyttet transaksjonsserversystemet 3 over et nettverk 5, som for eksempel internett. Hver bruker 2a-c har sin personlige kodegenereringsenhet 6a-c.

Transaksjonsserversystemet 3 inneholder en database 7 for lagring av brukerdata, slik som, for hver bruker, en bruker-ID, et seed for etablering av en brukerspesifikk kryptografisk nøkkel og kontodetaljer. Databasen 7, som her er illustrert som et datamaskinminne i en transaksjonsserver, kan befinne seg internt i transaksjonsserveren eller kan ligge i en (muligens fjernt beliggende) separat enhet som kan konfigureres til å kommunisere data som er lagret i databasen med en eller flere transaksjonsservere. Transaksjonsserversystemet 3 inkluderer i tillegg prosesseringskrets 8, som er konfigurert til å kommunisere med databasen 7, og et nettverksgrensesnitt 9, hvor transaksjonsserversystem 3 kommuniserer med brukerkommunikasjonsenhetene 4a-c over nettverket 5. Prosesseringskretsene 8 består videre av en kryptografisk modul, som i denne sammenheng ofte benevnes en Host Security Module (HSM).

Den informasjonsutveksling som forekommer under en transaksjon, mellom en bruker, som for eksempel bruker 2b i figur 1, og leverandøren av transaksjonstjenester 3, og mellom brukeren 2b og hans kodegenereringsenhet 6b vil nå blir beskrevet under henvisning til figur 2.

I figur 2 illustreres hendelser som involverer flyt av informasjon mellom partene 2b, 3, 6b av piler, der det oppstår hendelser sekvensielt fra topp til bunn i figur 2.

Den første hendelsen i dette eksemplet på en transaksjon er en transaksjonsforespørsel sendt fra brukeren 2b (via sin bruker-kommunikasjon enhet 4b) til leverandøren av transaksjonstjenestene 3. Denne hendelsen er representert ved at den øverste pilen 20 strekker seg fra venstre til høyre i figur 2. Som svar på transaksjonsforespørsel 20, overfører leverandøren av transaksjonstjenester, som indikert av at pilen 21 strekker seg fra høyre til venstre, en transaksjonsspesifikk kode til brukeren 2b. Denne transaksjonsspesifikke koden gis til kodegenereringsenheten 6b assosiert med brukeren 2b, som indikert av pilen 22. Kodegenereringsenheten utfører deretter en sekvens av de forhåndsdefinerte funksjonene som bestemmes av den transaksjonsspesifikke koden. Hver funksjon innebærer å be brukeren 2b å indikere en funksjonsrelatert verdi i kodegenereringsenheten 6b. Denne to-veis utveksling mellom brukeren 2b og hans kodegenereringsenhet 6b er representert ved pilen 23 i figur 2. Etter siste input i sekvensen av funksjonsrelaterte verdier, gir kodegenereringsenheten 6b en svarkode for brukeren 2b. Dette vises med neste pil 24 i figur 2.

Denne svarkoden overføres deretter av brukeren 2b, via sin brukerkommunikasjonsenhet 4b, til leverandøren av transaksjonstjenester 3, som indikert av siste pil 25 i figur 2.

Som illustrert i figur 2, utføres en "ikke-tilkoblet", eller "off-line", signeringsprosedyre, hvor brukeren 2b samhandler med sin kodegenereringsenhet 6b. Denne ikke-koblede signeringsprosedyren bestemmes av leverandøren av transaksjonstjenestene 3 gjennom den transaksjonsspesifikke koden overført fra leverandøren av transaksjonstjenester 3 til brukeren 2b (pil 21).

Transaksjonsprosedyren, og særlig den ikke-koblede signeringsprosedyren, skjematisk illustrert i figur 2, vil nå bli utredet videre under henvisning til flytdiagrammer i figurene 3 og 4.

Flytdiagrammet i figur 3 illustrerer skjematisk prosedyren utført av transaksjonsserversystemet i henhold til en utførelsesform av den nåværende oppfinnelsen, mens flytdiagrammet i figur 4 skjematisk illustrerer prosedyren utført av kodegenereringsenhet i henhold til en utførelse av foreliggende oppfinnelse, i tilfelle en transaksjon med "høy risiko".

Ved å henvise i første omgang til figur 3, mottas transaksjonsforespørselen fra brukerkommunikasjonsenheten (for eksempel 4b i figur 1) i et første trinn 301. I det etterfølgende trinnet 302, utfører transaksjonsserversystemet en risikovurdering basert på transaksjonsforespørselen. Risikovurderingen kan basere seg på faktorer som for eksempel type transaksjon som forespørres, status for brukeren som ber om transaksjonen, opprinnelsen til transaksjonen (for eksempel IP-nummer), målet for transaksjonen (dersom transaksjonen innebærer overføring av midler), historien om lignende transaksjoner, etc, eller en kombinasjon av slike faktorer.

Basert på resultatet av risikovurderingen utført i trinn 302, genererer transaksjonsserversystemet 3 en transaksjonsspesifikk kode og sender denne transaksjonsspesifikke koden til brukerkommunikasjonsenheten 4b i følgende trinn 303. Den transaksjonsspesifikke koden inneholder en kodeindikasjon på en sekvens av forhåndsbestemte funksjoner som skal utføres av kodegenereringsenheten 6b assosiert med brukeren 2b som transaksjonsforespørselen gikk ut fra.

Eksempler på slike koder og tilhørende forhåndsbestemte funksjoner finnes nedenfor i tabell 1. Det bør bemerkes at disse kodene og funksjonene kun er gitt for å eksemplifisere, og de bør på ingen måte tolkes som å begrense omfanget av denne oppfinnelsen.

Tabell 1:

Anta nå at risikovurderingen utført i trinn 302 indikerte at den valgte transaksjonen er en høyrisiko transaksjon av en slik art at leverandøren av transaksjonstjenester 3 ville kreve at brukeren aktivt bekrefter destinasjonskontoen, og valutaen og beløpet som skal overføres til denne kontoen.

Med henvisning til eksemplene på funksjoner og tilhørende koder gitt i tabell 1, vil brukeren 2b da bli instruert av leverandøren av transaksjonstjenester 3, til å legge inn den handelsspesifikke koden '043' i sin kodegenereringsenhet 6b. Det første sifferet i koden, '0', viser her at den dynamiske sikkerhetsfunksjonaliteten til kodegenereringsenheten 6b bør gjøres gjeldende. Det andre og tredje sifferet '43' angir at den forhåndsbestemte funksjonen, '4' (Destinasjonskonto) og '3'(valuta og beløp) bør utføres i sekvens av kodegenereringsenhet 6b.

Ved midlertidig å forlate figur 3 på dette stadiet, vil nå prosedyren gjennomført av kodegenereringsenheten 6b som svar på oppføring av den transaksjonsspesifikke koden '043' bli beskrevet i detalj med henvisning til figur 4.

Som vist i figur 4, mottar kodegenereringsenheten 6b den transaksjonsspesifikke koden '043' i det første trinn 401. Kodegenereringsenheten 6b vurderer deretter koden sekvensielt, siffer for siffer, og kommer først inn i "dynamisk" modus som kodet av det første sifferet '0'. Kodegenereringsenheten 6b går deretter videre til dekoding av resten av den transaksjonsspesifikke koden, og utfører i trinn 402 den første funksjonen ('4'), nemlig å be brukeren oppgi destinasjonskontonummeret. Etter innspill fra brukeren 2b om destinasjonskontonummeret, blir denne verdien lagret på et forhåndsbestemt sted i en signeringsbuffer 49. Senere, i trinn 403, utføres den andre funksjonen ('3'), nemlig å be brukeren 2b å legge inn valuta og beløpet som skal overføres. Verdiene som angir valuta og beløp, legges inn i kodegenereringsenheten 6b av brukeren 2b og lagres i tilsvarende forutbestemte steder i signeringsbufferen 49.

I neste trinn 404, ber kodegenereringsenheten 6b brukeren om å angi sin PIN for å demonstrere brukerens tilstedeværelse, og bekrefter PIN-koden.

Når hele rekken av funksjoner forespurt av leverandøren av transaksjonstjenester 3 er blitt utført, og den tilsvarende sekvensen av bruker-inn verdier har blitt lagret i signeringsbufferen 49, er innholdet av signeringsbufferen 49 signert av kodegenereringsenheten 6b i følgende trinn 405. Denne signering finner vanligvis sted ved å utnytte en kryptografisk modul, som kan for eksempel bli gitt i kode-genererings-enheten 6b selv eller på et smartkort som kodegenereringsenheten 6b er konfigurert til å samhandle med.

Til slutt, i trinn 406, vises responskoden til brukeren 2b, som så kan sende svarkoden til transaksjonsserversystemet via sin brukerkommunikasjonsenhet 4b.

Nå som prosedyren utført i kodegenereringsenheten er blitt ferdigbehandlet, tilsvarende pil 22, 23 og 24 i figur 2, skal de neste trinnene som utføres av transaksjonsserversystemet 3 beskrives under fortsatt henvisning til figur 3.

Som vist i figur 3, mottar transaksjonsserversystemet 3 responskoden, generert av kodegenereringsenheten 6b, i trinn 304.

I det etterfølgende trinnet 305, vurderes responskoden. Hvis evalueringen utført i trinn 305 indikerer at responskoden er et gyldig svar på den transaksjonsspesifikke koden, utføres transaksjonen i trinn 306, og hvis svarkoden er ugyldig, blir transaksjonen avvist i trinn 307.

En utførelsesform av kodegenereringsenheten 6a-c, som omfatter en bildeinnhentningsenhet, vil nå bli nærmere beskrevet med henvisning til figurene 5 og 6.

Figur 5 viser en planvisning av en utførelsesform av kodegenereringsenheten i henhold til den foreliggende oppfinnelsen forfra og fra siden, hvor kodegenereringsenhet 6a-c er utstyrt med et display 50, et tastatur 51, et kamera 52 og en slot 53 for å motta en flyttbar kryptografisk modul i form av et smartkort 54.

Fig. 6 er et blokkdiagram som skjematisk illustrerer den funksjonelle konfigurasjonen av kodegenereringsenhet 6a-c i fig 5, der en mikroprosessor 60 er koblet til tastaturet 51, displayet 50, og en kameramodul 52 som består av en linse 61 og en solid state bildesensor 62, for eksempel en CMOS-sensor eller en CCD sensor. Både kameramodulen 52 og mikroprosessoren 60 er koblet til en 2D strekkode dekoder 63 for å muliggjøre rask dekoding av data kodet i 2D strekkode 64 ervervet gjennom kameramodul 52.

Når smartkortet 54 settes inn i sporet 53 (se fig 5), er mikroprosessoren også koblet til den kryptografiske modulen 65 omfattet i den sikre kretsen på smartkortet 54.

I det følgende vil ulike utførelsesformer av metoden i henhold til oppfinnelsen bli beskrevet med henvisning til figurene 7-9.

Fig. 7 illustrerer skjematisk et eksempel på et skjermbilde 70 presentert for brukeren 2b som en følge av en brukerforespørsel om en pengeoverføring mellom kontoer i det sikre transaksjonssystemet 1 i fig 1.

Som vist i figur 7, har brukeren 2b oppgitt et kildekontonummer 8143697206, et destinasjonskontonummer 5264992738, og et beløp som skal overføres, 10 000 EUR, i de aktuelle boksene 71 -73. Skjermbildet 70 inneholder også en 2D strekkode 74 generert av transaksjonsserversystemet 3 basert på transaksjonsdetaljene inn i inputboksene 71 -73, og en tekstboks 75 for oppføring av en svarkode, der brukeren 2b signerer for den forespurte overføring av midler.

En konkretisering av metoden, utført som svar på skjermbildet i fig 7, skal nå beskrives under henvisning til fig 8.

Som illustrert i figur 8, er et bilde ervervet og dekodet i et første skritt 801. Bildet er i dette tilfellet en 2D strekkode 74 anskaffet ved hjelp av kameramodul 52 på kodegenereringsenheten 6b. Bildeinnhentningen styres av mikrokontrolleren 60 og initieres vanligvis av en handling fra brukeren 2b, for eksempel en aktivering av en av tastene på tastaturet 51, eller ved hjelp av en brukerinputenhet (vises ikke) som er dedikert til drift av kameramodul 52.

Dekodingen av 2D-strekkoden 74 kan utføres av mikroprosessoren 60, av kameramodul 52, eller ved en dedikert dekoder 63.

2D strekkoden 73 koder for en transaksjonsspesifikk kode, som i det foreliggende eksempelet inneholder kryptert transaksjonsinformasjon. Etter innhentning og dekoding (trinn 801) av bildet, dekrypteres kryptert transaksjonsspesifikk kode ved hjelp av brukeren 2b sin kryptografiske modul 65, og den dekrypterte transaksjonsinformasjonen vises til brukeren 2b ved hjelp av displayet 50 av kodegenereringsenhet 6b, i trinn 802. Herved kan brukeren 2b, i et sikkert miljø, med sin kodegenereringsenhet 6b i samarbeid med hans personlige kryptografiske modul båret av smartkortet 54, kontrollere at transaksjonsdetaljer (kildekontoen, målkontoen og beløpet som skal overføres) er korrekt. Når transaksjonsinformasjonen vises, ber også kodegenererenheten 6b brukeren 2b å legge inn en PIN-kode for å anerkjenne hans aksept av den viste informasjon. Etter å ha mottatt og verifisert PIN gitt av brukeren 2b, genereres en svarkode i trinn 803.

Responskoden inneholder gjerne informasjon som angir transaksjonsdetaljene, bruker-ID, og at brukeren 2b har gjennomgått og anerkjent transaksjonsdetaljene i kodegenereringsenheten 6b. Den genererte responskoden vise i trinn 804 til brukeren 2b gjennom displayet 50, der brukeren 2b aktiveres til å skrive inn svarkoden i den aktuelle tekstboksen 75.

En utførelsesform av metoden i henhold til oppfinnelsen som utføres som svar på skjermbildet i fig 7, vil nå bli beskrevet med henvisning til fig 9.

Metoden som beskrives med henvisning til fig 9 er forskjellig fra det i henhold til fig 8 i at den transaksjonsspesifikke koden kodet av den viste 2D strekkoden 74 inneholder en kodeindikasjon på en sekvens av funksjoner som skal utføres av kodegenereringsenhet 6b før en responskode kan genereres.

Etter innhenting og dekoding (trinn 801) av bildet som tidligere beskrevet, blir koden kodet av 2D strekkode 74 bedømt av kodegenereringsenheten 6b å finne ut hvilken sekvens av funksjoner som er nødvendig for leverandøren av transaksjonstjenester for denne transaksjonen.

Flytdiagrammet i figur 9 viser et tilfelle da risikoen for at transaksjonen anses som høy, og leverandøren av transaksjonstjenestene dermed overfører et bilde 74 til brukerkommunikasjonsverktøyet 4b til koding av en transaksjonsspesifikk kode inkludert en kode indikativ på en sekvens av forhåndsbestemte funksjoner som tilbyr et høyt nivå av sikkerhet og ikkebenektelse for transaksjonen.

I det aktuelle eksemplet blir brukeren 2b, i trinn 901, bedt om å angi målkontoen for pengeoverføringen. Deretter, i trinn 902, blir brukeren 2b bedt om å oppgi beløpet som skal overføres, og i trinn 903, blir han bedt om å velge en av en liste over valutaer, for eksempel ved å skrive inn et tall som angir en i en liste av viste valutaer.

Ved å skrive inn destinasjonskontoen, beløpet og valutaen for den valgte overføring, har brukeren 2b aktivt uttrykt en handling av vilje til å utføre overføringen. For å sikre at riktig bruker 2b er i besittelse av kodegenereringsenheten 6b og svarer på spørsmålene som stilles, blir mer personlig informasjon, for eksempel brukerens telefonnummer, fødselsdato, personnummer osv. forespurt i trinn 904. Etter oppføringene i trinn 901-904 av transaksjonsspesifikk og brukerspesifikk informasjon, blir brukeren, i trinn 905, bedt å endelig godkjenne de opplysninger som tidligere er skrevet inn i kodegenereringsenheten 6b, ved å angi sin PIN.

Deretter genereres responskoden som beskrevet ovenfor i forbindelse med figurene 8, basert på sekvensen av brukerinputverdier lagt inn av brukeren 2b i den ovenfor beskrevne godkjenningssekvensen.

Endelig vises svarkoden til brukeren i trinn 804, slik at brukeren 2b kan skrive inn svarkoden i den aktuelle tekstboksen 75 og dermed godkjenne transaksjonen.

Inkludert i responskoden, vil leverandøren av transaksjonstjenesten, på et høyt nivå av sikkerhet, være i stand til å verifisere hva som har blitt signert, av hvem det er signert, og en meget sterk indikasjon på en viljestyrt handling på vegne av brukeren 2b.

Personer med kjennskap til teknikken innser at foreliggende oppfinnelse som defineres i kravene, på ingen måte er begrenset til de foretrukne utførelsesformene beskrevet ovenfor. For eksempel trenger svarkoden generert i kodegenereringsenheten ikke vises til brukeren, men kan leveres direkte fra kodegenereringsenheten til brukerkommunikasjonsenheten eller transaksjonsserversystemet. Videre koding av hver funksjon, og angivelse av en funksjonsrelatert verdi forespurt av brukeren, vil være avhengig av en bestemt gjennomføring og hvem som skal bruke denne teknologien: banker, børsmeglere, osv. Videre bør det forstås at enten en brukerangitt verdi, for eksempel en PIN-kode, eller en representasjon eller indikasjon av den kan brukes til bestemmelse av den transaksjonsspesifikke responskoden.