NO316246B1 - Transaksjonsfremgangsmåte for et mobilapparat, samt identifiseringselementtil bruk for denne - Google Patents

Description

Foreliggende oppfinnelse angår en fremgangmåte og en anordning for formidling av oppgaver i et telekommunikasjonsnett Oppfinnelsen angår særlig en transaksjonsfremgangsmåte mellom en kunde og et fast apparat ved et transaksjonspunkt, som er forbundet med en server via et telekommunikasjonsnett, og også en transaksjonsinnretning egnet for denne transak-s jonsfremgangsmåte

Ifølge teknikkens stand blir transaksjoner mellom en kunde (eller klient, C) og en terminal, her kalt transaksjonspunkt (POT), som f eks kan være et salgssted (POS), ofte gjennomført ved hjelp av et elektronisk betalingskort F eks blir debet- og kreditkort benyttet i kasser i butik-ker, ved bensinstasjoner osv Kortene omfatter for det meste lagringsmidler, f eks en magnetstripe og/eller en brikke, og i disse er blant annet identifiseringen av kunden lagret For å gjennomføre en transaksjon med eieren eller den som betjen-er et POT, f eks når en gjenstand skal betales i en forretning, må kunden skyve kortet sitt inn i en dertil egnet kort-leser i POT-apparatet POT leser da identifiseringen til kunden fra kortet, formidler og viser beløpet som skal betales, undersøker f eks om kunden er betalingsdyktig og krever av kunden at han aksepterer transaksjonen ved betjening av en ordretast på POT-apparatet Når kunden er solvent og har gitt sin betalingsordre, blir kundens identifisering, beløpet som skal betales og eventuelt også en identifisering av POT videreformidlet til en finans-server forbundet med POT via et telekommunikasjonsnett Finans-serveren blir administrert av et finansinstitutt Deretter blir kundens konto i dette finansinstitutt belastet, straks eller senere

En ulempe med denne fremgangsmåte er at det er nødvendig at kunden må skyve sitt kort inn i et fremmed apparat Kunden har normalt ikke kortet sitt rett for hånden, og må f eks finne det i sin portemoné, og derfor blir en svært hurtig transaksjon heller ikke mulig Leilighetsvis er heller ikke åpningen som kortet skal innføres i, i leseapparatet ved POT, lett tilgjengelig, dette er særlig tilfelle når POT er en billettautomat for parkeringshus eller en betalingsautomat som kan betjenes fra kjøretøyet uten at bilisten stiger ut av dette Dessuten kan bedrageriske handlinger eller ikke-berik-tigede avlesninger av lagringsområdet til kortet, bli gjen-nomført i POT

Også i dag når noen brikkekort inneholder en mikropro-sessor, vil disse debet- og kreditkort stort sett være pas-sive elementer som lagrer data som hovedsakelig blir overført og benyttet av elektronikken i POT Kunden har derimot vanligvis ingen mulighet til å få direkte tilgang til disse data uten at han må begi seg til en skranke eller til en automat i det angjeldende finansinstitutt som utgir kortet For kunden er det også vanskelig å kontrollere transaksjonen som er gjennomført med kortet og føre regnskap over dette

Disse kort inneholder en kundeidentifikasjon som tillater at kunden bare blir identifisert overfor det finansinstitutt som har utgitt kortet Et kort kan altså vanligvis bare bli benyttet til en finansiell transaksjon dersom kunden og POT-betjeningen er tilknyttet samme finansinstitutt Derimot er bruken av kortet for andre typer transaksjoner, f eks for transaksjoner av ikke-finansiell art, men hvor en pålitelig identifikasjon av kunden/kortinnehaveren er nødvendig, ikke gjennomførbar For kunden er det også uunngåelig at han må ha et stort antall kort for enhver type av finansielle eller ikke finansielle transaksjoner, f eks flere debet- eller kreditkort som administreres av forskjellige finansinstitut-ter eller forretningskjeder, eller abonnementskort eller adgangskort for beskyttede soner Disse kortene er for det meste beskyttet av forskjellige PIN-koder som kunden med besvær må innskjerpe seg

Ved tyverier eller ved bedrageriske handlinger som foretas med kortet, må kortene sperres Slik sperring kan dog først skje når kortet blir innført i et tilsvarende apparat De vanlige kreditkortene kan dog i tillegg bli benyttet i manuelt betjente apparater, og en helt sikker sperring av kortet er derfor ikke mulig

I tillegg til debet- og kreditkort kjenner man de såkalte kontaktkort (e-cash-Karten) som gjør det mulig å lagre pengebeløp på elektronisk måte, hvoretter kortene aksepteres ved ulike POT-steder som betalingsmiddel For at disse kortene skal bli fornyet med nye pengebeløp, må kunden henvende seg ved skranken eller en automat til et finansinstitutt, noe som ikke alltid er mulig

I patentsøknad EP 708 547 A2 blir det beskrevet en fremgangsmåte og en anordning i henhold til hvilken kunden kan oppnå kredit ved hjelp av mobiltelefonen ved ervervelse av produkter og tjenester I tillegg til fremgangsmåten som er beskrevet i EP 708 547 A2 forlikes kunden og den aktuelle kjøper om et transaksjonspassord og dette kan kunden overføre til kjøperen ved hjelp av sm mobiltelefon sammen med et apparatnummer for mobiltelefonen og med et tilvist nummer for denne mobiltelefon til en mottagerenhet i en anordning hos selgeren I anordningen hos selgeren blir de data som mottas fra kunden tilføyet en kjøperidentifikasjon, samt et transaksjonsbeløp, og alle disse informasjoner formidles til et kreditsentrum hvor kreditverdigheten til den aktuelle kunde blir avklaret og det tilsvarende resultat overført til selgeren

I patentsøknad WO 94/11849 blir det beskrevet en fremgangsmåte i henhold til hvilken finanstransaksjoner kan bli gjennomført ved hjelp av SIM-kort (Subscriber Identity Mo-dule), som blir forbundet med mobiltelefonen Ved fremgangsmåten beskrevet i WO 94/11849 blir den aktuelle kunde auten-tisert ved tjenester i mobiltelefonnettet på grunn av sitt SIM-kort Etter at denne kunden har lastet inn en personlig kode for å bekrefte sin rett til å benytte dette SIM-kortet, og har meddelt dette over et dedisert kommunikasjonsnett til en forbindelse hos et finansinstitutt valgt av kunden, hvor ulike finanstransaksjoner kan bli gjennomført Kommunikasjonsterminalen hvori SIM-kortet innføres, er f eks instal-lert på et salgssted og kan benyttes av kunden for å angi et pengebeløp som blir etterspurt hos det valgte finansinstitutt og etter godkjenning belastet kunden, og dette blir deretter bekreftet via kommunikasjonsterminalen på kjøperstedet ved hjelp av et betalingsnummer for godskriving

Et formål med foreliggende oppfinnelse er å unngå de ovennevnte problemer med et system og en fremgangsmåte som angitt ovenfor

Et ytterligere formål med foreliggende oppfinnelse er å frembringe en transaksjonsfremgangsmåte som både er egnet for finansielle og ikke-fmansielle transaksjoner, som dessuten er enklere og mer pålitelige enn de i dag vanlige transak-sjonsfremgangsmåter

I henhold til foreliggende oppfinnelse blir dette særlig oppnådd ved angivelsene i de nedenfor fremsatte uavhengige krav Ytterligere fordelaktige utførelser fremgår dessuten av de avhengige krav og av beskrivelsen

De ønskede mål vil særlig bli nådd ved hjelp av en transaksjonsfremgangsmåte mellom en kunde og et POT-apparat (f eks et salgssted, POS) forbundet med telekommunikasjonsnett Dette telekommunikasjonsnett blir forbundet med en server slik at fremgangsmåten i POT-apparatet i det minste sammenholder en kundeidentifikasjon med en POT-apparatidentifikasjon som blir innlest i eller oppfattet av POT-apparatet, og med transaksjonsspesifikke data til et transaksjonsdokument, samt overføring av disse transaksjonsdokumenter via telekommunikasjonsnettet til serveren, hvorved kundeidentif1-seringen blir lagret i lageret til en bærbar identlflkasjons-lnnretning hos kunden, som minst omfatter en prosessor og er innrettet slik at den kan kommunisere over et kontaktløst grensesnitt med POT-apparatet, hvorved kundeidentifikasjonen kan innleses i identlfiseringselementet og overføres via det kontaktløse grensesnitt til POT-apparatet, hvoretter formid-lingen av transaksjonsdokumentet til serveren fra POT-apparatet omfatter en belastningsoppfordrmg som i det minste innbefatter de transaksjonsspesifikke data og kundeidentif1-kasjonen, blir overført direkte via det kontaktløse grensesnitt for overprøving av kundens identlfikasjonselement

Ved et utførelseseksempel kan serveren kommunisere med et annet luft-grensesnitt, f eks via et mobiltelefonnett, med et mobilsystem (f eks et mobilapparat med et ldentifi-seringskort) Når transaksjonen er en finansiell transaksjon, kan derved et pengebeløp som er lagret i mobilapparatet etterinnleses i serveren med elektroniske meldinger over luft-grensesnittet Pengebeløpet blir fortrinnsvis definert i en standard myntfot

Den kontaktløse overføring mellom mobilsystemet og POT-apparatet, kan f eks skje gjennom et elektromagnetisk grensesnitt i identifikasjonskortet eller i mobilapparatet

Dette grensesnitt kan f eks ha form av en induktiv spole eller en infrarød sender/mottager

Transaksjonsdokumentet blir fortrinnsvis kodet med en symmetrisk algoritme før det videreføres til serveren, og herunder må den symmetriske algoritme bli benyttet for sesongkoding Transaksjonsdokumentet blir fortrinnsvis dessuten sertifisert før det blir videreført til en fmans-server Fortrinnsvis blir det garantert en ende-til-ende-sikret overføringsstrekning mellom mobilsystemet og finans-serveren

Foreliggende oppfinnelse vil forstås bedre ved hjelp av eksemplene nedenfor og ved hjelp av de ledsagende figurer

Fig 1 viser et blokkskjema for informasjonsstrømmen ved en første utførelse av systemet i henhold til oppfinnelsen, og her er kunden forsynt med en mobiltelefon, fortrinnsvis et GSM-mobilapparat som kan motta og sende spesielle kort-meldinger Fig 2 viser et blokkskjema som angir informasjonsstrømmen ved en annen utførelse av systemet i henhold til oppfinnelsen, og her er kunden utstyrt med en mobiltelefon, fortrinnsvis et GSM-mobilapparat som kan motta og sende kort-meldinger, og hvor POT-apparatet er et apparat som er anvendbart via internett eller intranett Fig 3 viser et blokkskjema som angir informasjonsstrømmen ved en tredje utførelse av systemet i henhold til oppfinnelsen, hvor kunden er forsynt med en transponder som i det minste kan bearbeide visse kort-meldinger, og hvor POT-apparatet er i stand til å motta og/eller sende spesielle kort-meldinger,

f eks SMS- eller USSD-kort-meldinger

Fig 4 viser et blokkskjema som angir informasjonsstrømmen i en fjerde utførelsesform av systemet i henhold til oppfinnelsen Her er kunden utstyrt med en transponder som i det minste kan utføre endel av prosedyren i henhold til SICAP, og hvor POT-apparatet er et apparat som kan benyttes i forbindelse med internett eller intranett, og som f eks kan motta og/eller sende spesielle kort-meldinger slik som SMS- eller USSD-kort-meldinger Fig 5 viser et flytskjema for en fremgangsmåte for gjen-nomføring av betalingstransaksjoner i henhold til oppfinnelsen Fig 6 viser et flytskjema for en mulig etterladingstrans- aksjon ved hjelp av et SIM-kort Fig 7 viser et blokkskjema som angir informasjonsstrømmen i en ytterligere mulig utførelsesform av systemet Fig 8 viser et blokkskjema som angir informasjonsstrømmen i ytterligere en mulig utførelsesform av systemet Fig 9 viser et blokkskjema som angir informasjonsstrømmen ved en ytterligere mulig utførelsesform av systemet Fig 10 viser et blokkskjema som forklarer signeringen av

meldinger

Fig 11 viser et blokkskjema som forklarer overprøving av

signaturen

Fig 12 viser et blokkskjema som forklarer signeringen og

overprøvingen av signaturen

Fig 13 viser et blokkskjema som forklarer kodingen av meldingen

Fremgangsmåtene som er vist på fig 5 og 6 kan bli utført med et hvilket som helst vilkårlig system som er vist på fig 1-4 Den første og den andre variant krever begge et mobilapparat eller et SIM-kort med et ekstra infrarødt eller induktivt grensesnitt som vil bli beskrevet nærmere nedenfor Fig 1 viser informasjonsstrømmen i en første utførelse av oppfinnelsen Kunden er utstyrt med et mobilsystem, i dette tilfellet med et mobilapparat 1 i henhold til GSM-systemet Mobilapparatet 1 inneholder et identifikasjonskort 10, f eks et SIM-kort, og med dette blir kunden identifisert i nettet 6, som fortrinnsvis kan være et GSM-nett SIM-kortet oppviser en konvensjonell mikrokontroller 100 som inngår i kunststoffbæreren til kortet, og er kompetent til å gi kortet GSM-funksjonalitet, slik dette f eks er forklart i artikkel-en "SIM CARDS" av T Grigorova og I Leung, hvilken artikkel står i "Telecommunication Journal of Australia", vol 43, nr 2, 1993, på sidene 33-38 - og for nye funksjonaliteter som på et senere tidspunkt kan benyttes for SIM-kort Disse SIM-kort oppviser i tillegg ikke viste kontaktmidler som kortet kan kommunisere med mobilapparatet 1 over, og kortet blir innført i dette apparatet

SIM-kortet oppviser dessuten en annen prosessor 101 (CCI, Contactfree Chipcard Interface) som er kompetent til å gi den kontaktløse forbindelse med POT-apparatet 2 Den andre prosessor utfører blant annet den nedenfor beskrevne TTP (Thrusted Third Party)-funksjon, for mottagelse og sending av chiffrerte og signerte meldinger Et logisk grensesnitt 102 forbinder de to prosessorer 101 og 102

Det kontaktløse grensesnitt med POT-apparat 2 kan i det minste omfatte en spole integrert i SIM-kortet og knyttet til den andre prosessor 101 (ikke vist), slik at data kan over-føres induktivt i begge retninger over en radioforbmdelse En induktiv spole kan, ved en variant, også integreres i huset til mobilapparatet Ved en tredje variant omfatter det kontaktløse grensesnitt en infrarød sender/mottager i huset til mobilapparatet Den kontaktløse kommunikasjon mellom de to apparater blir fortrinnsvis kodet, f eks med en DEA-, DES-, TDES-, RSA- eller ECC-sikkerhetsalgoritme

Ved en induktiv signaloverføring fra POT til brikke-kortet blir det fortrinnsvis tatt i bruk en fasemodulasjons-fremgangsmåte, mens overføringen i motsatt retning fortrinnsvis benytter en modulering av amplituden til signalet

SIM-kortet inneholder fortrinnsvis et spesielt felt IDUI (International Debit User Identification), og med dette kan kunden identifiseres overfor POT-betjeningen og/eller et finansinstitutt Identifiseringen IDUI blir fortrinnsvis lagret i et sikret lagringsområde til en av de to prosessor-ene 101, 102 IDUI-koden inneholder i det minste en identifikasjon av nettadministratoren, et brukernummer som identifiserer brukeren for andre kunder hos den samme nettleverandør, en brukerklasseangivelse som definerer hvilke tjenester kunden kan benytte, og kan som en opsjon, ytterligere gi en landidentifikasjon Dessuten inneholder IDUI sikkerhetsdata, blant annet en transaksjonsteller Tz, et ladesignaltegn LTC og et felt for tidsperiodeutløp TO, som angir et valider-mgstidsrom Funksjonen for disse ulike data blir forklart nedenfor

Det symbolsk fremstilte POT-apparat 2 er likeledes forsynt med en kontaktløs sender/mottager 20, f eks med en induktiv spole eller med en infrarød sender /mottager Takket være disse grensesnitt kan mobilsystemet 1,10 kommunisere med apparatet 2 i begge retninger på kontaktfri måte

Terminalen eller POT-apparatet 2, kan f eks være et spesielt POS-apparat (Point of Sale) utstyrt med et trådløst grensesnitt 20 i en forretning POT-apparat 2 kan imidlertid også være tenkt benyttet for ikke-finansielle anvendelser,

f eks nøkkel for en adgangskontroll ("elektronisk portner'') som overvåker de som kommer og går innenfor et beskyttet område, f eks i et hotellværelse, i en bedrift, i

teater, på kino eller innenfor et park med attraksjoner POT-apparatet blir identifisert med et spesielt felt POSID (Pomt Of Sale Identification) POSID-koden avhenger av anvendelsen, dersom det er kassen i en forretning, inneholder den en

identifikasjon av nettoperatøren, en arealidentifisering (delområdet innenfor et land), et POS-nummer som identifiserer brukeren overfor andre POS med samme nettoperatør, en POS-klasseangivelse som definerer hvilke tjenester han benytter eller tilbyr, dato, tidspunktet, den benyttede valuta (SDR, euro eller dollar) og opsjonelt også en 1andidentifikasjon

POT-apparat 2 blir fortrinnsvis forsynt med et ikke-vist datainnlesningsmiddel, f eks med et tastatur, og med et ikke-vist datafremvisningsmiddel, f eks med en skjerm

IDUI-identlfikasjonen blir overført til POT over det kontaktløse grensesnitt 10/101, og i POT-apparatet blir det sammenlenket med POSID-koden og med ytterligere trans-aksjonsspesif ikke data, f eks med det oppnådde debiter-mgsbeløp A, slik at det oppstår et elektronisk transaksjonsdokument som kan kodes og signeres ved hjelp av en TTP (Thrusted Third Party)- eller PTP (Point-to-Point)-prosess Ytterligere forklaringer om TTP-fremgangsmåten vil nedenfor bli gitt i et vedlegg

Transaksjonsdokumentet blir deretter videreformidlet via et ikke-vist modem og sendt via kommunikasjonsnettet 5,

f eks gjennom et offentlig fastnett 5 eller gjennom et mobiltelefonnett som likeledes er forbundet med nettet via

klareringsenhet 3 Denne mottar det elektroniske dokument fra forskjellige POT-apparater 2, uavhengig av land eller handelsområde, og uavhengig av kundens land eller finansinstitutt I klareringsenheten 3 blir disse transaksjonsdokumenter ordnet etter finansinstitutt, eventuelt også etter operatør, og tilstilet det tilsvarende finansinstitutt Klareringsenheten er i seg selv tidligere kjent innenfor GSM-teknikken, og blir eventuelt benyttet f eks for innsamling og viderefordeling av oppkoblingskostnader Klareringsenheten kan f eks inneholde en databank som angir hvilke finans-mstitutt kunden som er identifisert av sm IDUI-kode, er tilknyttet

Det elektroniske transaksjonsdokument som er blitt behandlet i klareringsenhet 3 blir videreført til finans-serveren 4, 4' eller 4<11> i det tilsvarende finansinstitutt I finansserveren blir det mottatt transaksjonsdokument først kodet og lagret i et mellomlager 43 En avregnings-modul 42 godskriver deretter beløpet som er signert av kunden i den tilsvarende bankkonto 420,420' og/eller 420'1 for POT-leverandøren Disse konti kan være forvaltet gjennom det samme eller gjennom ulike finansinstitutt Avregningsmodulen fører dessuten et kontrollregnskap over kontoen til kunden På tilsvarende måte blir kundens konto 41 belastet finansinstituttet, eller transaksjonsdata blir lagret for senere kontroll Finansserveren inneholder dessuten en TTP-server 40 for å behandle dokumenter og meldinger med TTP (Thrusted Third Party) -algoritmen for siffrenng og signering

Dessuten blir hver finansserver 4 forbundet med en SIM-server 70, f eks via en SICAP-server Den aktuelle SICAP-fremgangsmåte er blant annet beskrevet i patent EP 689368 og tillater at data, programmer og også pengebeløp utveksles mellom SICAP-serveren 70 og SIM-kort 10 i mobilapparat 1 over det offentlige GSM-nett 6 (pilen 60) Andre overføringsproto-koller kan også bli benyttet for dataoverføringen mellom SIM-server og SIM-kort Derved kan f eks pengebeløp bli ettermnlastet i SIM-kort 10, som nærmere forklart nedenfor SIM-server 70 muliggjør dessuten styrt kommunikasjon mellom kunden og TTP-server 40 i fmansmstituttet

Fig 2 viser informasjonsstrømmen ved den annen ut-førelsesform av oppfinnelsen Kunden er likeledes i denne varianten utstyrt med et mobilsystem, f eks med en GSM-mobiltelefon 1 med et SIM-kort, fortrinnsvis med et SICAP-kompetent SIM-kort Likeledes inneholder mobilsystemet 1 et induktivt eller infrarødt grensesnitt og over dette kan en kontaktløs forbindelse opprettes med POT-apparat 2 Data og/eller programmer kan på denne måten utveksles i begge retninger mellom POT-apparat 2 og SIM-kort 10 i mobilsystemet

POT-apparat 2<1> er imidlertid i dette tilfellet en kalkulator som fortrinnsvis er forbundet med et nett, f eks tilknyttet internett eller et intranett Ulike informasjoner eller tilbud, f eks produkttilbud, kan f eks bli vist ved hjelp av en egnet meny på diplayet til kalkulatoren 2 Kunden kan styre denne kalkulator med sin mobiltelefon F eks kan han styre posisjonen til en markør i en meny for å kjøpe de tilbudte produkter eller velge informasjoner ved å betjene skyvetaster for markøren på tastaturet 11 Forskyvnings-mstruksjonene for markøren blir sendt ut over det kontakt-løse grensesnitt 101,20 til kalkulatoren 2' Brukeren betjen-er en betjeningstast, f eks tasten # på sitt tastatur, for å bekrefte den utvalgte menymarkering, f eks for å bestille et produkt

Kundeidentiflsenngen som er lagret i mobilsystemet 1,10 blir sammenlenket med POT-apparatidentifiseringen og med den utvalgte menyopsjon i henhold til transaksjonsspesifikke data i et elektronisk transaksjonsdokument, deretter blir dokumentet TTP- eller PTP-kodet og signert Transaksjonsdokumentet inneholder fortrinnsvis en kundeidentifisering IDUI som fåes fra SIM-kort 10, en leverandøridentifikasjon ifølge den valgte menyopsjon, samt en produktidentlfikasjon også ifølge den valgte menyopsjon, fortrinnsvis i Flexmart-format som foreslått i patentsøknad PCT/CH96/00464 Dette dokumentet blir formidlet via en Flexmart-modul 21 Flexmart-modulen er fortrinnsvis en programfunksjon operert fra kalkulatoren 2<1>

Analogt til i den første utførelsesform blir deretter det elektroniske transaksjonsdokument overført til den aktuelle finansserver 4,4' eller 4<11> gjennom klareringsenheten 3 hvor den blir bearbeidet

Fig 3 viser informasjonsstrømmen ved den tredje ut-førelsesform av forelilggende oppfinnelse Kunden er i denne varianten ikke utstyrt med et komplett mobilapparat, men bare med en transponder 10 * som f eks kan være integrert i et brikkekort eller i et hvilket som helst apparat som f eks en klokke, en nøkkelring eller en fingerring Transponderen kan også være integrert i en infrarød fjernstyringsenhet, og gjennom denne fjernstyring kan den kommunisere med POT-apparat 2 Transponderen 10' inneholder en første prosessor 100', og med denne kan spesielle kortmeldinger, f eks SMS- eller USSD-kortmeldinger, sendes, mottas og kodes Ved en fore-trukken variant omfatter den første prosessor 100<1> SICAP og/eller TTP-moduler hvorved data og programmer kan bli utvekslet med en server 10 ved hjelp av SMS- eller USSD-kortmeldinger Den første prosesor 100<1> inneholder imidlertid ingen mobilradiofunksjon og transponderen kan derfor ikke bli benyttet som SIM-kort i et mobilapparat

En annen brikke 101 (CCI, Contactfree Chipcard Interface) er forbundet med brikke 100' via et grensesnitt, og denne er kompetent til å gi den kontaktløse forbindelse med apparat 2 Det er naturligvis også mulig å benytte en eneste brikke, som oppfyller begge delfunksjoner Den kontaktløse forbindelse skjer i dette tilfellet fortrinnsvis ved hjelp av minst en induktiv spole i transponderen 10'

POT-apparatet 2<11> omfatter i dette tilfellet en sender/- mottager 20 som kan kommunisere på kontaktløs måte med transponderen 10', databearbeidningsmidler 23 med et tastatur 11, samt en mobiltelefon 24, fortrinnsvis et redusert GSM-apparat som bare kan motta og sende spesielle kortmeldinger som f eks SMS- eller USSD-kortmeldmger Tastaturet tjener som innlesningsmiddel for kunden

Det reduserte GSM-apparat 24 som er integrert i POT-apparatet og bare kan overføre kortmeldinger, muliggjør overføring av meldinger igjennom mobilradionett 6 mellom transponderen 10' og en første anvendelse i SIM-server 7, og derved oppnås den kodede etterladings-henholdsvis kontrollprosess (pilen 60) og dokumentoverføring (pilen 61) fra kunden til en SIM-server anvendelse 71 i SIM-server 7, f eks SICAP-server Ved en variant kan den kodede etterladnmgs-henholdsvis kontrollprosess og dokumentoverføring også skje over et modem eller en ISDN-tilknytning 22 og et fastnett 5

Meldingen og dokumentet blir deretter overført via det kontaktløse grensesnitt 101/20 og over mobilradiostreknmgen 60, 61 igjennom mobilnettet 6

Fig 4 viser informasjonsstrømmen ved en fjerde utfør-elsesf orm av oppfinnelsen Kunden blir, slik som i den tredje variant, ikke utstyrt med et komplett mobilapparat, bare med en transponder 10' POT-apparat 2'<11> er, på samme måte som i den andre utførelsesform, forbundet med dataprosesserings-midler 2' som rår over en Fleksmart-modul 21 Kunden kommuniserer med SIM-server 7 gjennom et noe begrenset mobilapparat 24, f eks et redusert GSM-apparat 24 som bare er egnet til overføring av spesielle SMS- eller USSD-kortmeldinger og befinner seg i 2''' De øvrige funksjoner er analoge med de i den tredje utførelsesform

Med Fleksmart-modul 21 kan oppdragsmeldinger bli forbe-redt i et standarisert format for en produkt- eller informasjons-leverandør, som beskrevet i patentsøknad PCT/CH96/00464

En betalingstransaksjonsfremgansmåte vil nå bli nærmere beskrevet under henvisning til fig 5 Denne fremgangsmåten kan anvendes i forbindele med vilkårlige utførelsesformer av oppfinnelsen i henhold til fig 1-4 Dette forløp er imidlertid almengyldig og ikke begrenset til GSM-prosessen

Den første kolonnen i fig 5 viser fremgangsmåtetrinnet som hovedsakelig involverer mobilsystemet 1 til kunden, den andre kolonnen beskriver fremgangsmåtetrinnene som utføres av POT-apparat 2, den tredje kolonnen angår driften av finans-server 4 mens den fjerde kolonnen angår virkningen på de forskjellige konti ved fmansmstituttet Det må imidlertid bemerkes at mange fremgangsmåtetrinn enten kan bli utført ved hjelp av mobilsystemet 1, f eks prosessen innenfor SIM-kort 10, eller i POT-apparat 2 F eks kan datainnføringen enten skje ved hjelp av POT eller ved hjelp av mobilsystem 1 når dette inneholder et tastatur, slik som f eks GSM-mobilapparat

Disse fremgangsmåter starter med trinnet 200, hvor identifikasjonskortet 10 til kunden, her et kontantkort, er lastet inn med et pengebeløp (e-cash) Kontantkort er i og for seg tidligere kjent, og vi vil senere i forbindelse med fig 6 forklare nærmere hvordan pengebeløp i ettertid kan innlastes Dessuten beskriver patentsøknad EP96810570 0 en fremgangsmåte for å etterinnlaste et pengebeløp i SIM-kort

Mobilsystem 1 henholdsvis 10 blir satt i funksjons-beredskap i trinn 201, f eks ved innkobling av mobilapparatet Likeså blir POT-apparat 2 aktivisert i trinnet 202 POT-apparat 2 anroper deretter i trinn 203, ved kring-kasting, de neste ubestemte kunder (kort-personsøking (kartenpagmg))

Når forbindelsen opprettes mellom POT-apparatet og mobilsystemet 1, 10 overlater mobilsystemet i trinn 204 sin identifikasjon IDUI (International Debit User Identification) og garantien om at vedkommende er solvent, til POT-apparatet Hvorvidt solvensgrensen er tilstrekkelig, kan i dette øyeblikk ennå ikke oppdages

POT-apparat 2 inneholder en svarteliste over sperrede kunder, og listen blir fortrinnsvis periodisk oppdatert fra fmansserver 4 IDUI-koden som overføres fra kunden blir sammenlignet med svartelisten (trinn 205) Når IDUI-koden som blir overgitt fra kunden gjenfinnes i svartelisten (trinn 206) settes et blokkeringsflagg i trinn 2 07 Dersom ingen overensstemmelse finnes, kan det innleses transaksjonsspesifikke data, f eks et debitbeløp A til betaling, på tastaturet 11 i POT-apparat 2 Med en variant kan beløpet A også leses inn på tastaturet til mobilapparatet 1 POT-apparatet 2, eller i en annen variant, SIM-kort 10, sammenlenker deretter disse transaksjonsspesifike data med identifikasjonen til POT-apparat 2 og IDUI-koden, og sender disse belastnings-oppfordringer til kunden Fortrinnsvis blir likeså ytterligere en referanse-valuta som f eks SDR, euro eller dollar angitt

Når kommunikasjonen blir signert, kan det i trinn 210 bli prøvet om belastningsoppfordrmgen samsvarer med IDUI Hvis ikke blir avslagsgrunnen vist på POT-apparat 2 (trinn 223) Ellers blir det satt opp et blokkeringsflagg i trinn 211 Blir dette satt opp, skjer en kontroll mot fmansserver 4 (trinn 248) Er flagget ikke satt opp følger en areal-kontroll (trinn 213) Herunder kan hvert SIM-kort bli sperret alt i avhengighet av anvendelsesområdet Dersom område-kontrollen er negativ, følger en kontroll mot fmansserver 4 (trinn 248), ellers blir det gjort en tidskontroll (215) Herunder blir det prøvet om validasermgstiden, hvorunder transaksjonen kan gjennomføres uten ytterligere kontroll, allerede er utløpt Dersom validisenngstiden er utløpt

(216) , følger en kontroll mot fmansserver (248) , ellers blir kunden i trinn 217 oppfordret til å lese inn sitt bruker-passord manuelt på mobilapparatet 1 Dersom det innleste passord er korrekt (218) blir beløpet A likeså omregnet til enhetsmyntfoten (f eks SDR) i trinn 219 Dermed blir en internasjonal gjennomføring av konseptet mulig Ellers blir i trinn 223, grunnen til at oppdraget ikke kan gjennomføres angitt ved POT-apparat 2

Mobilsystemet 1/10 beviser deretter i trinn 220 om det er dekning for beløpet A med det pengebeløp som er lastet mn på kortet (solvensprøvmg) Dersom dette ikke er tilfelle, blir dette angitt som tilbakevisningsgrunn på POT-apparatet

(trinn 223)

Når alle disse prøvinger er foretatt blir transaksjonen utført ved hjelp av en transaksjonsteller Tz som mkre-menteres Denne telleren uttrykker antall transaksjoner som er gjennomført med kortet 10 I trinn 224 blir deretter debet beløpet A, POT-apparatidentlfikasjon POSID og brukeridentifi-kasjonen IDUI sammenlenket i et transaksjonsdokument som endelig sertifiserer og oppsjonelt koder og eventuelt også komprimerer informasjon ECC-metoden (elliptic curve crypto-system) kan f eks bli benyttet for sertifiseringen En egnet sertifiserings- og kodemetode vil bedre bli forklart som et eksempel

Det belastede beløp A blir deretter, i trinn 225, avregnet på kortkontoen, og transaksjonsdokumentet blir lagt inn i en stabel på identlfikasjonselement 10 Denne stabel av kort fra kundene kan etter behov kalles opp for detaljert kontroll fra fmansserver Fortrinnsvis kan kunden selv også få se de transaksjonsdokumenter som er lagret i stabelen, på sitt mobilapparat

Etter trinn 224 blir transaksjonsdokumentet overlatt til POT-apparat 2 for avregning, og signaturen blir kontrollert av POT-apparatet (trinn 227) Oppsjonelt blir det trykt ut et papirdokument fra POT for kunden i trinn 228

I trinn 229 blir deretter belastningsdokumentet lenket med eventuelt tilføyde POS-data i POT-apparat 2, og transaksjonsdokumentet blir signert elektronisk av POT-apparatet og oppsjonelt komprimert og kodet Det på denne måte forbe-redte elektroniske transaksjonsdokument blir deretter lagt over i en stabel i POT-apparat 2 i en oppsjonell handling i trinn 230 Stabelen inneholder transaksjonsdokumenter fra forskjellige kunder Transaksjonsdokumentet blir deretter overført individuelt eller i grupper i trinn 231, til klareringsenhet 3 Overføringen kan enten skje straks etter at transaksjonen er foretatt, eller den kan bli utført periodisk ved tidsmellomrom (f eks hver time eller hver dag) idet flere transaksjonsdokumenter fra stabelen overføres samtidig En puljeprosess, for overføring av alle transaksjonsdokumenter f eks i løpet av natten, kan også benyttes

Klareringsenheten 3 mottar individuelle eller grupperte transaksjonsdokumenter fra flere POT-apparater 2 i den samme geografiske sone (trinn 234) Flere geografisk fordelte klarermgsenheter kan være tilrettelagt I trinn 235 tildeler klareringsenheten 3 de mottatte transaksjonsdokumenter fra de forskjellige POT-apparater til de tilsvarende finans-institutter eller tjenestetilbydere, og viderefører disse transaksjonsdokumenter i henhold til dette

Når transaksjonsdokumentene blir kodet, må de først dekodes av klareringsenheten for å bli tildelt en fmansserver 4,4', 4'', og deretter på ny chiffrert av klareringsenheten for å videresende dem Ved en foretrukket variant blir imidlertid dataelementene i feltene IDUI og eventuelt POSID i transaksjonsdokumentene, hvilke data er nødvendige for klareringen, ikke chiffrert i POT-apparat 2 Dermed kan en sikret ende-til-ende kodet overføring av transaksjonsdokumentet oppnås mellom POT-apparatene og finansserveren 4, 4 ' , 4 1 '

Den kompetente fmansserver mottar i trinn 236 transaksjonsdokumentene og om nødvendig dekomprimerer og koder TTP-server 40 disse og overprøver ektheten til signaturen fra POT-apparatet og fra kunden I trinn 237 blir det prøvet om POSID og/eller IDUI-kodene befinner seg i en gjenopprettingsliste Dersom testen er negativ (238) fordi hverken POT-apparatidentifikasjonen eller kundeidentifikasjonen IDUI befinner seg på gjenopprettingslisten, skjer i trinn 239 en test av ladetegnet LT Ladetegnet LT angir antall etterladmger på kortet 10 Dette ladetegnet blir oppdatert i fmansserver (LT„) og i kortet (LTC) etter hver etterladingsprosess, som beskrevet nedenfor En kopi av ladetegnene (LTC) blir overført i feltet IDUI i transaksjonsdokumentet Det ladetegn (LT0) som blir meddelt fra mobilsystemet 1,10, må være lik ladetegnet LTS lagret i fmansserver 4 Dersom etterladnmgsbeløpet ennå er på vei mellom fmansserver 4 og mobilsystemet 1,10, kan LTC temporært også være mindre enn LTS Finansserveren 4 undersøker også om LTC <

L<T>S

Blir denne betingelse ikke verifisert i trmn 240, blir sannsynlig en ikke-autorisert etterladningsprosess gjennom-ført og fremgangsmåten går over til trinn 241 Det blir her gjort forsøk på om mangelen skriver seg fra POT eller fra kunden Er det kunden som er ansvarlig, blir han i trmn 242 ført inn i en svarteliste Et kundeavsperringsdokument blir fortrinnsvis generert og sendt til kunden over mobilsystem 1,10 for å stille opp blokkeringsflagget og sperre av systemet såfremt denne kunden er blitt innført i svartelisten ved alle POT-apparater eller i det minste ved alle POT-apparater innen et forutbestemt geografisk område Blir derimot problemet forårsaket av POT-apparatet, vil dette trinnet 243 føre til en innføring av en POT-svarteliste

Blir ladetegnprøvmgen som skjer i trinn 240 bestått, kan beløpet A i trinn 244 bli belastet kundekonto 41 i finansinstituttet ved transaksjonsdokumentet Andre betal-ingsvarianter, f eks ved hjelp av et kredittkort eller ved fremsendelse av en regning, ligger selvsagt også innenfor rammen av oppfinnelsen Ved trmn 245 blir en konto 420, 420' eller 420'' i overensstemmelse med beløpet A, godskrevet POT-innehaveren via et finansinstitutt Bearbeidingsgebyr kan også bli belastet via et finansinstitutt og/eller fra POT-mnehaveren eller fra nettoperatøren via POT-konto 420 og/eller kundekonto 41

I trinn 246 fører fmansserver 4 denne transaksjonen mn i transaksjonstelleren En prosess følger deretter ved trinn 24 7 for å oppdatere verdien av ladetegn LT og fra transaksjonstelleren Tz i mobilsystemet

Vi kommer nå tilbake til prosessen i mobilsystem 1,10 Som allerede forklart fører dette systemet videre til trmn 248 når det faststelles et sikkerhetsproblem i trinn 212, 214 eller 216 I så fall følger en fullstendig kontroll med finansserveren, fortrinnsvis over mobilnettet 6 Kontrollen omfatter f eks en test og en fornyelse av autentiserings-sertifikatene såvel som en overprøving av alle utførte parametre, f eks ladetegn LT, transaksjonstelleren Tz, svartelisten osv Er resultatet av kontrollen negativ, blir blokkeringslaget satt opp slik at mobilsystem 1 eller i det minste den anggjeldende anvendelse i SIM-kort 10 blir sperret (trinn 253) Viser derimot denne kontrollen at det høyst sannsynlig ikke er blitt forsøkt å gjennomføre noen for-falskning, blir validiseringstiden innstilt på ny i trinn 250 Med validiseringstiden kan f eks mobilsystemet bli sperret når det ikke er blitt brukt innen en forutbestemt tid, f eks dersom det ikke er blitt benyttet i løpet av et år Denne angivelse må derfor bli innstilt på ny etter hver ny anvendelse Blokkeringsflagget blir deretter slukket i trmn 251, og et nytt område blir innsatt i trmn 252

Det er viktig å bemerke at belastnmgsprosessen kan skje med forskjellig myntfot, f eks på basis av de vanlige valutaer i telekommunikasjonsområdet SDR (spesialbelastnmgs-rett) eller med en annen referansevaluta (f eks euro eller dollar) Det maksimale beløp på kortet er definert etter hver kundeklasse Den minste verdien er en utgangsverdi (default) i SDR Hvert apparat 2 lagrer den verdi som er relevant for dette apparat SDR-verdi (valutaspesifikk), som meddeles vedkommende fra serveren i en opprettmgsprosess Ved enhver kurssvingning blir POT-apparatet automatisk forsynt med de aktuelle kurser fra finansserveren

En fremgangsmåte for ettennnlasting av et pengebeløp i mobilsystemene 1,10 blir nedenfor beskrevet nærmere i forbindelse med fig 6 Denne fremgangsmåte kan likeledes utføres med vilkårlige utføringsformer av oppfinnelsen i henhold til fig 1-4

En etterinnlastmgsprosess følger kunden og POT-apparatet 2 sammen ved hjelp av mobilsystemet 1,10 En direkte etterladningsprosess fra fmansserver 4 kan også gjennomføres Alt etter kundeklassifisering eller også etter behov, kan fmansserver anrope dokumentstabelen hos kunden, ved hjelp av detaljert kontroll Etter at etterladmngs-prosessen har funnet sted kan stabelen fjernes fra finans-serveren

Den første kolonnen i fig 6 viser fremgangsmåtetrinn som hovedsakelig mnvolverer mobilsystemet 1,10, den andre kolonnen beskriver fremgangsmåtetrinn som blir utført av POT-apparat 2, den tredje kolonnen angår driften av fmansserver 4, og den fjerde kolonnen angir effekten på de forskjellige konti i finansinstituttet Det må imidlertid bemerkes at flere fremgangsmåtetrinn kan bli utført enten ved mobilsystem 1,10, f eks innenfor SIM-kort 10, eller med POT-apparat 2

F eks kan fremgangsmåtetrmnet som angår data-innlesning enten foretas fra POT-apparatet eller fra mobilapparat 1, så sant mobilapparatet inneholder et tastatur, slik som f eks et GSM-mobilapparat Når mobilapparatet 1 og POT-apparat 2 ikke er forbundet med hverandre via trådforbmdelse, blir kommunikasjon mellom de to komponenter fortrinnsvis kodet,

f eks ved hjelp av en DEA-, DES-, TDES-, RSA- eller ECC-sikkerhetsalgoritme

I trmn 300 blir først mobilsystemet 1,10, f eks identifikasjonskort 10, frikoblet for betjening av etter-ladinsprosess, POT-apparat 2 blir på sin side aktivisert også i trinn 301 POT-apparat 2 går deretter, i trinn 3 02, inn i en kringkastmgsmodus for anrop av det neste, ubestemte mobilsystem 1,10 {Kort paging)

Når forbindelsen mellom POT-apparat 2 og mobilsystem 1,10 er blitt etablert, oversender kunden i trmn 303 sm identifikasjonskode IDUI {International debet user identifi-catiori) til POT, og også typen av prosessen som skal starte, her en etterlading

POT-apparat 2 inneholder en periodisk oppdatert svarteliste som fortrinnsvis oppdateres fra fmansserver 4 over det sperrende mobilsystemet (gjenopprettingsliste) IDUI-koden som oversendes fra kunden, blir sammenlignet med svartelisten i trmn 3 04 Når IDUI-koden som mottas fra kunden gjenfinnes i svartelisten (trinn 305), blir et blokkeringsflagg satt ut i trinn 306 Deretter, eller når ingen overensstemmelse er funnet, blir det i trinn 307 testet om oppføringen samsvarer med IDUI Dersom dette ikke er tilfelle blir nektelsesgrunnen vist på POT-apparat 2 i trinn 315 Ellers blir blokkeringsflagget testet i trinn 308 Dersom det er satt opp, blir mobilsystemet 1 eller minst den aktuelle anvendelse i identifikasjonskort 10, sperret (trmn 331) Flagget blir ikke satt opp dersom kunden i trinn 310 oppfordres til å lese inn sitt

brukerpassor på manuell måte i mobilapparat 1 Dersom det innleste passord ikke er korrekt (311) blir likeså blokker-mgsflagget satt opp og tilbakevisningsgrunnen blir fremvist på POT-apparat 2 i trinn 315, forøvrig blir prosessen stilt åpen for etterlading og kunden blir i trinn 312 oppfordret til å lese mn transaksjonsspesifike data, her et etter-lnnladningsbeløp A Ved den foreliggende variant kan etter-ladnmgsbeløpet leses mn ved POT-apparatet, dette beløpet blir i trinn 313 lenket videre til POSID og til IDUI, deretter signert og overført til kort 10 Beløpet A kan imidlertid også angis ved mobilapparatet 1, i dette tilfellet blir ingen POT-krets innvolvert og POSID-koden vil da heller ikke være nødvendig

Ved trmn 314 blir det f ør søkt om IDUI-data som er mottatt i POT-apparat 2 overensstemmer med verdien på IDUI i egen enhet Dersom dette ikke er tilfelle blir tilbakevisningsgrunnen anvist på POT-apparat 2 i trmn 315, ellers blir det ønskede og ved POT-apparatet innleste etterladningsbeløp vist frem på billedskjermen til mobilapparatet Ved trinn 316 blir deretter POSID, IDUI, det allerede omtalte antall betalingstransaksjoner Tz, antall utførte etterladningsprosesser lagret på kortet (LTc, ladetegnkunder) og restbeløp på kortet DRA (Debit Rest Amount) sammenlenket, signert, kodet og deretter komprimert Det dannes derved et etterladnmgsbeløp Oppsjonelt kan også dokumentstabelen overføres til kortet,

f eks avhengig av kundeklassifisering, ved kortutgivelsen eller etter behov under anvendelse ved solvensproblemer POSID-nummeret blir da bare integrert i etterladningsbeløpet dersom kunden disponerer et mobilapparat uten POT-innles-nmgsdel, og i dette tilfellet kan han også bli nådd fra fmansserver Etterladningsbeløpet blir deretter overført til finansserveren 4, 4', henholdsvis 4'<1>, idet TTP-serveren 40 mottar dette dokument i trinn 317, dersom dette er aktuelt i kodet og dekomprimert form, og signaturen fra kunden som likeledes blir overprøvet av POT

I trmn 319 blir ved hjelp av tabell 318 som lagrer antall og tegn i henhold til prosessene som foregår mellom kunden og finansserveren, følgende prøving gjennomført

Beløpsprøvnmg Summen SA for alle beløp som er lastet inn, inklusive startsummen må være lik eller mindre enn summene av kontroll belastningen EKB og restbeløpene DRA på kortet Summen kan være mindre fordi beløp som ennå befinner seg mellom mobilsystemet 1,10 klarerinsenheten 3 og finans-serveren 4, 4', 4'1 ennå ikke er angitt i dette øyeblikk

Ladetegntesting Antall innlastinger- henholdsvis etterinniastningstransaksjoner blir telt opp i mobilsystemet, f eks i SIM-kortet ved hjelp av et tegn LTc og i finans-serveren med annet tegn LTs Disse to tegn må være like

Transaksjonstellerprøving For hver tellertransaksjon blir transaksjonstelleren Tz i mobilsystemet 1,10 mkre-mentert, ved hvert etterlaingdokument blir også Tz overført Transaksjonstelleren Tzs, som blir inkrementert for hvert dokument som overføres fra kundene og som er legret i finansserveren, må være lik eller eventuelt mindre enn transaksjonstallene Tz i mobilsystemet 1, 10

Når en av disse tre betingelser ikke er oppfylt (trmn 320), blir blokkeringsflagget satt i trinn 321 og etter-ladningsprosessen i trmn 325 blir tilbakevist Ellers blir i trmn 322 kontostanden 41 til kunden overprøvet Strekker kontoen ikke til for etterladnmgen, blir likeledes tilbake-visningen forberedet

Når kontoen (eller kontogrensen) til kunden i finansinstituttet er tilstrekkelig for etterladning av beløpet (trinn 322, 323), blir dette beløpet trukket fra kundekonto 41 (trinn 324), inklusive gjeldende kommisjoner Et etter-ladningsdokument blir da utarbeidet i trinn 326 fra POSID, IDUI, beløpet A, det nye lade-tegnet LTn, og et på forhånd definert Tid-ut T01 inkrement Dette etterladnmgsbeløp blir signert i trmn 327, og eventuelt kodet og komprimert, og overført til kundens mobilsystem 1, 10 Dette konstaterer under trmn 328 om signaturen i beløpet stammer fra finans-serveren, og verifiserer under trinn 330, om blokkeringsflagget er satt opp Dersom det er satt opp (trinn 330), blir mobilsystemet eller i det minste den aktuelle anvendelse, sperret i trinn 331 Hvis ikke blir det også testet hvorvidt finansserveren har oppfordret til en tilbakevisning (trinn 332) som fører til avbrytelse av prosessen med anvisning av tilbakevisnmgsgrunnen (trmn 334)

Når alle tester er bestått med hell, blir kortkontoen i trinn 335 bokført med det nødvendige etterladnmgsbeløp Det gamle ladetegn LTc blir deretter erstattet av det nye ladetegn LTn som overføres fra finans-serveren (trmn 33 6) Transaksjonstelleren Tz på kortet blir nullstilt i neste trinn 337, og tid-ut TOi, blir tilbakestilt i trmn 338 Når det i trinn 339 blir fastslått at POSID inneholdes i etter-ladningsdokumentet, blir dessuten et nytt areal innstilt i trinn 340

Etterladningsbeløpet blir da angitt som bekreftet, enten ved mobilapparatets skjerm eller ved POT-apparatet (trmn 341) Endelig blir også den totale kontosaldo på kortet vist

(trmn 342)

Sikringen av dataoverføringen ved kryptering blir foretatt i to forskjellige segmenter Mellom kunden og POT blir kommunikasjonen sikret via luft-grensesnittet f eks ved hjelp av en algoritme som DES, TDES, RSA eller ECC Mellom kunden og finans-serveren kommer derimot TTP (Thrusted Third Party)- metoden eller eventuelt en PTP (Point-to-Point)-fremgangsmåte til anvendelse De nødvendige elementer er integrert på identlflsenngselementet 10 og i TTP-serveren 4 0 En beskrivelse av TTP-konseptet er beskrevet i vedlegget

I det følgende blir informaskjons-strømmen ved en videre, mulig utførelsesform av transaksjonsfremgangsmåten forklart Kunden er utstyrt med et mobilapparat 1 som likeledes inneholder et SIM-kort 10, som identifiserer ham for GSM-nettet 5 Selgeren trenger et POT-apparat 2 med en modem tilkobling 22 til et telekommunikasjonsnett 6, f eks et fastnett Begge har en overenskomst med innehaveren av fmans-serveren 4 1 , f eks et finansinstitutt

Por at transaksjonen mellom kunden og selgeren skal finne sted, må selgeren først taste inn beløpet A som skal betales, i POT 2 POT-apparatet lenker dette beløp A sammen med et POSID som er lagret i POT, slik at filialen og kassen i denne filialen blir identifisert Disse sammenlenkede data blir formidlet over det fortrinnsvis sikrede datanett 6 til finans-serveren

Kunden forbereder en spesiell kortmelding ved sitt apparat 1, fortrinnsvis en SMS-kortmeldmg eller eventuelt USSD-data som inneholder beløpet A som skal betales og POSID som er muntlig meddelt fra selgeren, og sender denne kortmelding over GSM-nettet 5 og den ikke viste kortmeldings-driftssentral (SMSC) til fmansserver 4' Denne kortmelding inneholder automatisk kundeidentifikasjonen som er lagret i SIM-kortet Fortrinnsvis inneholder den dessuten en påkrevet sikkerhets PIN-kode Kortmeldingen kan bli kodet før den overføres

For å sikre privatsfæren til kjøperen blir fortrinnsvis ingen angivelse om den kjøpte tjeneste, produktet eller informasjonen overført

Finansserveren 4<1> får data fra POT-apparatet 2 og fra mobilsystemet 1 til kunden, og bekrefter dem om nødvendig Den kjenner, fra POT, identiteten POSID og beløpet A Derav kan den bestemme hvilken POT-konto 420, 420', 420'' som skal godskrives Fra kunden kjenner den identiteten gjennom kundeidentifisering, og evt PIN og beløpet Derav kan den bestemme hvilken kundekonto 41 som skal belastes Finans-serveren 4<1> sammenligner deretter POSID som er formidlet fra POT-apparatet 2 og fra mobilsystemet, og også beløpet Ved overensstemmelse skjer transaksjonen mellom POT-kontoen og kundekontoen Finansserveren 4<1> sender deretter en melding til POT-apparatet 2 og/eller til mobilapparatet 1 om at transaksjonen er foretatt, og denne melding blir fremvist Dersom det ikke er overensstemmelse blir forløpet avbrutt

Nedenfor blir ved hjelp av fig 8 informasjonsstrømmen ved en ytterligere mulig utførelsesform av transaksjonsmåten forklart Kunden er utstyrt med et mobilapparat som likeledes inneholder et SIM-kort, og dette identifiserer ham overfor mobilnettet 5 Selgeren trenger et POT-apparat 2 med en modemtilknytnmg 22 til et telekommunikasjonsnett 6, f eks et fastnett Begge har en kontrakt med administrasjonen for finans-server 4', f eks et finansinstitutt

For at transaksjonen mellom kunden og selgeren skal gjennomføres, må operatøren for POT-apparatet, f eks en selger, registrere beløpet A og mobilanropsnummeret til kunden på POT-apparatet 2 POT-apparatet sammenlenker disse angivelser med et POSID lagret i POT, og dette POSID identifiserer filialen og kassen i denne filialen Disse sammenlenkede data blir formidlet gjennom det fortrinnsvis sikrede datanett 6 til fmans-serveren 4' Fortrinnsvis blir det ikke overført noen angivelse om det kjøpte produkt for å garantere kjøperens anonymitet

Finansserveren 4' mottar data fra POT og supplerer dem om nødvendig Den kjenner identiteten POSID til POT og beløpet A Deretter kan den fastslå den POT-konto 420, 420', 420'<1> som skal godskrives Likeså kan den identifisere kunden gjennom det overførte mobilnummer og kjenner derigjennom kundekontoen 41 som skal belastes

Fmansserver 4 ' sender deretter kunden en spesiell kortmelding, f eks en SMS- eller USSD-kortmeldmg som inneholder beløpet A Kunden må deretter bekrefte transaksjonen med en bekreftende kortmelding som inneholder en identifisering av kunden i GSM-nettet Dersom det ikke kommer noen bekreftelse fra kunden eller dersom den overførte identifikasjon ikke stemmer overens med kundens mobilnummer, blir forløpet avbrutt Ellers skjer transaksjonen

Nedenfor vil informasjonsstrømmen i en ytterligere mulig utførelsesform av transaksjonsfremgangsmåten forklares ved hjelp av fig 9 Kunden er utstyrt med et mobilapparat 1 som likeledes inneholder et SIM-kort som identifiserer vedkommende i GSM-nettet Selgeren trenger et vanlig POT-apparat 2 som ikke trenger noen telekommumkasjonstilknytning Begge har en overenskomst med en f mans-serveroperatør, f eks et finansinstitutt

For at transaksjonen mellom kunden og selgeren skal finne sted må kunden forberede en spesiell kortmelding,

f eks en SMS- eller USSD-kortmelding som inneholder beløpet A som skal betales og POSID-koden som kommuniseres fra selgeren, og sende denne kortmelding over GSM-nettet 5 og SIM-sentralen til finansserveren 4' Denne kortmelding inneholder automatisk kundeidentifikasjonen som er lagret i SIM-kortet Fortrinnsvis inneholder den dessuten en påkrevet sikkerhetskode, PIN Ingen opplysninger om det kjøpte produkt blir fortrinnsvis sendt ut for derved å beskytte kjøperens privatliv

Finansserveren 4<1> mottar data fra kunden og kompletterer dem om nødvendig Den kjenner identiteten POSID til POS-apparatet og beløpet A Dermed kan den bestemme den POT-konto som skal godskrives Likeledes kan den identifisere kunden gjennom kundeidentifiseringen i kortmeldingen, og kjenner dermed kundekontoen som skal belastes

Finansserveren 4' utfører dermed transaksjonen og sender POT-innehaveren en bekreftelsesmeddelelse i form av en kortmelding, en e-post eller et vanlig brev Denne melding inneholder minst identifiseringen av POT, datoen, klokke-slettet, beløpet og evt kundekontoen

Alle bilag blir fortrinnsvis overført mellom mobilapparat, POT-apparat og fmansserver som SMS- eller USSD-meldmger Dersom SMS-kortmeldinger blir benyttet, blir de fortrinnsvis forsynt med en spesiell "header" i data-telegrammet for å skille denne meldingen fra vanlige meldinger Fortrinnsvis blir dessuten innholdet i disse meldinger kodet med TTP-fremgangsmåten som er beskrevet i appendikset og anskueliggjort i figurene 10 - 13

Fagmannen vil forstå at oppfinnelsen også er egnet for ikke-finansielle transaksjoner mellom et mobilsystem og et POT-apparat som er forbundet gjennom et telekommunikasjons-system 5 POT-apparatet kan f eks også utgjøres av en låse-mnretning, og for denne anvendelse blir mobilsystemet f eks i form av et brikkekort, forsynt med en elektronisk nøkkel, nøkkelen blir lastet inn i serveren 4 på ettertid og lagret på kortet 10 For å åpne låseinnretningen blir det bygget opp en kontakt-løs kommunikasjon, f eks gjennom et induktivt eller eventuelt infrarødt grensesnitt mellom mobilsystemet 10 og POT-apparatet 2 Låseinnretningen blir bare åpnet når det etter denne kommunikasjon påvises at nøkkelen som er lagret i mobilsystemet 10 er korrekt og gir innehaveren adgangsrett til den beskyttede sone Serveren 4 som låseinnretningen er forbundet med via nettet 5, forvalter og registrerer adkomst-autorisasjon og belaster samtidig kundens konto 41 med et beløp i henhold til den aktuelle adgang

VEDLEGG - GRUNNLAG FOR KRYPTOGRAFI OG TTP

Sikkerhetskrav:

Ved utveksling av data mellom mobilsystemet 1, 10 og finans-serveren 4 skjelner man mellom følgende krav til sikkerheten <*> Fortrolighet Sikring av at en informasjon ikke gjøres tilgjengelig eller leselig for uvedkommende <*> Autentifikasjon Prosess ved hvilken ektheten blir overprøvet <*> Autentisitet Bevis for en identitet Den fører til visshet om at kunden, POT-apparatet 2 eller serveren 4 først og fremst er den den utgir seg for å være <*> Autentisitet av en informasjon Sikkerhet om at avsender/frembringer av en informasjon(mobilsystem 1, 10, POT-apparat eller fmansserver) er ekte <*> Ikke-sporbarhet av opprinneIse/herkomstbevis Avsenderen av en informasjon kan ikke bestride at informasjonen stammer fra ham <*> Integritet Sikring av konsistensen til en informasjon, dvs beskyttelse mot forandring, tilføyelse eller sletting av informasjon

Heretter blir termen "melding" brukt i steden for termen "informasjon" En melding er en informasjon (her en bitrekke-følge), som blir overført fra en sender til en mottager For denne applikasjon kan en melding f eks være et betalings-bilag eller et etterinnlastingsdokument Begrepet "avsender" og "mottager" betyr, alt etter meldingens retning, enten mobilsystemet 1, 10, POT-apparatet 2 eller finansserveren 4

Autentisiteten til senderen, Integriteten til informasjonen og ikke-bestridbarheten til opprinnelsen av informasjonen oppnås ved anvendelse av en såkalt digital signatur En digital signatur er en kryptografisk kode (dvs en bitsekvens) som er unik for en bestemt informasjon og når denne informasjon skal frembringes benyttes denne nøkkelen som bare forfatteren besitter Den digitale signatur kan derfor bare fremstilles av den som besitter den private nøkkel Vanligvis blir de tilføyet den originale melding

Fortroligheten til informasjonsoverføringen oppnås ved koding Den består i at meldingen ved hjelp av en kode-algoritme og en kryptografisk nøkkel (bitsekvens) blir forvandlet til en ikke-leselig tilstand Fra den melding som er forvandlet på denne måte, kan ikke den opprinnelige informasjon vinnes tilbake, man må i såfall kjenne den nøkkel som er nødvendig for dekoding

Hvordan dette virker i detalj er vist i det følgende

Symmetrisk og asymmetrisk koding

Man skjelner mellom to typer av kode-nøkler

<*> Symmetrisk For å chifrere og dechifrere (chifrere = kode) en informasjon blir densamme kryptografiske nøkkel benyttet Følgelig må sender og mottager begge være i besittelse av den samme nøkkel Uten denne nøkkel er det umulig å komme tilbake til den opprinnelige informasjon Dagens vanligste symmetriske algoritme er DES(Digital Encryptic Standard) Andre algoritmer er f eks IDEA, RC2, og RC4 Symmetriske algoritmer blir fortrinnsvis benyttet for å sikre dataoverføring mellom et mobilsystem og POT-apparater Nøkkelen blir da lagret i POT-apparatet 2 og mobilsystemet 10 <*> Asymmetrisk For chifrering og dechifrering blir to ulike, komplementære nøkler benyttet (nøkkelpar), dvs at meldinger blir chifrert med en første nøkkel og dechifrert med en annen nøkkel Denne prosedyren er reversibel, dvs man kan også benytte den andre nøkkel for chifrering og den første nøkkel for dechifrering Det er umulig å rekonstruere den andre nøkkel fra den første (eller omvendt) Likeså er det umulig, pga den chifrerte informasjonen, å utlede nøkkelen (dette gjelder til og med når origmalinformasjonen er kjent) Den klart hyppigste brukte asymmetriske algoritme er RSA (oppkalt etter oppfmnerene Rivest, Shamir og Adleman) En variant av denne er DSS (Digital Signature Standard)

Ved hjelp av asymmetrisk chifrering kan en såkalt digital signatur fremstilles Hvordan dette skjer er i detalj forklart i det følgende

Private og offentlige nøkler

Ved hjelp av den asymmetriske kode-teknikk kan et såkalt system av offentlige og private nøkler realiseres Derved blir en nøkkel til de komplementære nøkkelpar betegnet som private Den er i avsenderens besittelse, f eks kunden, og er bare kjent av ham Den blir også kalt hemmelig nøkkel

(dette begrepet vanligvis blir brukt om symmetriske nøkler)

Den andre nøkkelen er den offentlige nøkkel Den er ålment tilgjengelig Som nevnt ovenfor er det ikke mulig, på grunn av den offentlige nøkkel, å beregne den private Hvert mobilsystem, POT-apparat og hver fmansserver tildeles et nøkkelpar omfattende en privat og en offentlig nøkkel fra en pålitelig instans

Det er av største viktighet at den private nøkkel også virkelig forblir hemmelig, dvs at ingen annen person kjenner den, fordi sikkerheten til den digitale signatur bygger på dette Derfor blir den private nøkkel bare lagret i kodet form på identifikasjonskortet 10, hvor dessuten chifferalgo-ritmen er direkte implementert På denne måte forblir den private nøkkel alltid på brikken, og forlater ikke denne i noe øyeblikk Data som skal kodes blir overført til brikken, der blir de kodet og deretter atter sendt tilbake Arkitek-turen til brikken er definert slik at den private nøkkel kan leses enten med elektroniske, med optiske, mekaniske, kjem-iske eller elektromagnetiske hjelpemidler

I motsetning til private nøkler er de offentlige nøkler kjente, og blir fordelt til alle brukere For enkelhets skyld blir den offentlige nøkkel som regel sendt med sammen med hver melding Som vi vil se nærmere nedenfor, trenges det derfor en pålitelig instans (sertifiseringsinstans), som innestår for ektheten av den offentlige nøkkel, da en kriminell kan fremstille sitt eget nøkkelpar og utgi disse som enhver annen Ekthetsgarantien foretas i form av et såkalt sertifikat, som vil bli beskrevet i det følgende Hash-funksjonen

Hash-funksjonen er en ikke-resiprok algoritme som frem-bringer, på grunn av at en bestemt informasjon har vilkårlig lengde en Hash-verdi (kortform/komprimert-form), av fast lengde Den kan sammenlignes med tverrsummen av et helt tall Dermed blir lengden av meldingen typisk noe større enn den derav beregnede Hash-verdi Slik kan meldingen f eks omfatte flere Megabyte mens Hashverdien bare er 128 bit lang Det skal bemerkes at fordi Hash-verdien ikke kan tilbakeformes til origmalmformasjonen (ikke-resiprositet) , og fordi det er svært vanskelig å modifisere informasjonen slik at den gir den samme Hash-verdi Hensikten med en slik funksjon er frem-stillingen av en kort, for hvert dokument unik kode Denne blir benyttet for fremstilling av den digitale signatur Eksempler på Hash-algoritmer er MD4 (Message Dienst 4), MD5, RIPE-MD og SHA (Secure Hash Algoritme)

DEN DIGITALE(ELEKTRONISKE) SIGNATUR

Denne fremgangsmåte blir beskrevet med hjelp av figur 10 Hver bruker får en privat og en offentlig nøkkel For å signere en melding 90, på digital måte, blir den chifrert med avsenderens privat nøkkel (blokk 94) Resultatet er den digitale signatur 92 Da imidlertid signaturen som er opp-stått på denne måte blir like stor som originalmeldingen, blir først Hash-verdien 93 beregnet for meldingen 90 Som nevnt ovenfor har Hash-verdien en fast lengde og er unik for en bestemt melding For dannelse av den digitale signatur blir nå Hash-verdien 93 chifrert i steden for originalmeldingen Den således oppnådde digitale signatur 92, blir tilføyet originaldokumentet 90 Det hele blir deretter sendt over til mottageren (fig 10)

Da bare avsenderen av dokumentet er i besittelse av sin private nøkkel 91, kan bare han fremstille den digitale signatur Heri ligger da også analogien med en håndskrevet signatur Den digitale signatur besitter imidlertid visse egenskaper, som ikke foreligger ved en håndskrevet underskrift Således kan det f eks ved en kontrakt som er signert for hånd, ikke utelukkes at noen informasjoner ubermerket er blitt tilføyet eller slettet, og dette er ikke mulig med en digital signatur Den digitale signatur oppviser derfor en enda større sikkerhet enn den tradisjonelle underskrift for hånd

Overprøving av den digitale signatur

Da den offentlige nøkkel 97 blir fordelt til alle brukere og dermed er ålment kjent, kan enhver mottager av den digitale signatur 92 overprøve denne I denne hensikt dechifrerer han den digitale signatur 92 med avsenderens offentlige nøkkel (blokk 96 på fig 11) Resultatet er Hash-verdien til origmalmeldingen 90 Parallelt med dette be-regner mottageren Hash-verdien 95 til originaldokumentet 90, som likeledes er blitt overført til ham (sammen med signaturen 92) Denne resulterende andre Hash-verdi 95 sammenligner mottageren nå med Hash-verdien 96 som er dechifrert fra signaturen Stemmer disse to Hash-verdier overens, så er den digitale signatur autentisk

Om nå origmalmeldingen 90 under overføringen er blitt forandret (en bit er nok), så vil også dens Hash-verdi endres Dermed vil mottageren fastslå at Hash-verdien 95, som han har utledet fra den opprinnelige melding, ikke overensstemmer med Hash-verdien som er dannet av signaturen, og dette betyr at signaturen ikke er korrekt Følgelig garanterer mottageren ved en vellykket overprøving av den digitale signatur, at meldingen 90 ikke er blitt endret

(integritet)

Da bare den som fremstiller en signatur er i besittelse av sin private nøkkel 91, kan bare han fremstille den digitale signatur 92 Dette betyr at mottageren, som har den digitale signatur, kan bevise at bare avsenderen kunne fremstille signaturen (ikke-bestridbarhet av informasjonens opprinnelse)

Sertifisering av offentlige nøkler

Den Digitale signatur muliggjør også en lkke-bestridbarhet av opprinnelsen og en mtegritetsgaranti for en melding 90 Nå gjenstår imidlertid ennå ett sikkerhetsproblem, nemlig ekthetsgarantien for den offentlige nøkkel 97 til avsenderen Hittil har nemlig mottageren ingen garanti for at den offentlige nøkkel 97 nettopp er den som stammer fra senderen Signaturen kan riktignok være gyldig, da den dermed tilhør-ende offentlige nøkkel 97 rent teoretisk kan stamme fra en bedrager

Mottageren av en melding 90 trenger også sikkerhet for at den offentlige nøkkel 97 til avsenderen, som han er i besittelse av, faktisk tilhører den riktige avsender Denne garanti kan han få på forskjellige måter En mulighet er at avsenderen overleverer ham den offentlige nøkkel på et eller annet tidspunkt Eller mottageren kan anrope avsenderen og sammenligne de 10 første posisjoner på de offentlige nøkler Denne metoden er dog omstendelig og betinger at han enten allerede kjenner brukeren eller at de har truffet hverandre tidligere

Det ville være bedre om det fantes en instans som garanterer at en offentlig nøkkel tilhører en viss person Denne instans blir kalt en sertifiseringsinstans (Certifi-cation Authority/CA) og borger for at en bestemt offentlig nøkkel 97 tilhører en bestemt person Den gjør dette ved at den fremstiller et såkalt sertifikat 98 (fig 12) Det består hovedsakelig av den offentlige nøkkel og av navnet på innehaveren Det hele blir deretter signert av sertif lsenngs-lnstansen (signatur 98) Gjennom denne sertifiseringen binder CA også en offentlig nøkkel 97 til en bestemt avsender (kunde, POT eller server) For alle brukere blir det således fremstilt et sertifikat av CA for de offentlige nøkler Disse sertifikater er tilgjengelige for alle brukere

Ved overprøvingen av den digitale signatur 99 for avsenderens sertifikat såvel som signaturen 92 i selve meldingen, har mottageren et bevis for at meldingen 90 er underskrevet av en som er den han utgir seg for (autentifi-sermg)

Det må bemerkes at nøkkelsertifikatene 98 ikke må beskyttes spesielt, da de ikke kan forfalskes Om nemlig sertifikatet innhold blir endret vil mottageren merke at signaturen 99 ikke lenger er korrekt Og da ingen uten CA har den private nøkkel, er det ikke mulig for noen å forfalske signaturen til CA

Det finnes forskjellige muligheter for utbredelse av nøkkelsertifikater 98 En mulighet er at sertifikatene 98, 99 sendes sammen med hver melding

Ved hjelp av den ovenfor beskrevne teknikk kan også to kunder som ikke kjenner til hverandre, POT og server, utveksle informasjon innbyrdes, og dette på en sikker måte

Fordeling av offentlige nøkler fra sertifiserings-xnstans.

Nå gjenstår et siste problem Som beskrevet i forrige kapitel overprøver mottageren av en melding sertifikatet til avsenderen Til dette formål trenger han den offentlige nøkkel fra sertifiseringsinstansen CA kan nå riktignok sertifisere sin egen nøkkel, dette synes dog lite formåls-tjenlig, da det for enhver er mulig å selv generere et nøkkelpar og selv fremstille et CA-sertifikat (med tilsvarende navn for CA) For den offentlige nøkkel fra CA finnes det altså intet egentlig sertifikat Disse forhold tillater i teorien at en kriminell utgir seg som sertifi-sermgsinstans og deretter fremstiller og fordeler falske nøkkelpar og sertifikater Derfor må den offentlige nøkkel nå frem til brukeren på en sikker måte fra sertifiseringsinstansen Brukeren må være overbevist om at han besitter den riktige nøkkel fra CA

En løsning som straks byr seg, er at den offentlige nøkkel fra sertifiseringsinstansen lagres i brukerens SIM-kort Enhver kan riktignok (i motsetning til brukernes private nøkkel) lese nøkkelen, men kan ikke overskrive den eller slette den Dette oppnås ved hjelp av den spesielle arkitektur til brikken 101

Formidling av en digital signert melding uten

chiffrering:

Sammenfatning

<*> Senderen underskriver meldingen 90 med sin private, på kortet 10, lagrede nøkkel 91, for å bekrefte dennes opprinnelse <*> Origmalmeldingen 90 blir sammen med signaturen 92 og det signerte sertifikat 98,99 sendt fra avsenderen til

mottageren (pil 80)

<*> Mottageren overprøver den digitale signatur 92 for dokumentet 90 ved hjelp av den offentlige nøkkel 97 som

oversendes fra avsenderen i sertifikatet 98

<*> Dessuten forsikrer han seg om ektheten av den offentlige nøkkel 97 fra avsenderen, ved at han overprøver den digitale signatur 99 i sertifikatet 98 For dette formål benytter han den offentlige nøkkel 81 fra sertifiser-lngsinstansen

Chif£rering av meldingen

For å garantere fortroligheten i en overføring, det vil si beskyttelse mot innsikt fra uvedkommende, må meldingen kodes (chiffreres) For dette formål foreligger to muligheter Man kan kode meldingen med den offentlige nøkkel fra mottageren Da bare mottageren er i besittelse av den dertil hørende private nøkkel, kan følgelig bare han dekode meldingen Nå er det imidlertid slik at den asymmetriske chiffreringsalgoritme er svært langsom sammenlignet med den symmetriske

Derfor blir fortrinnsvis en symmetrisk algoritme benyttet for chiffrering av meldingen (fig 13) Avsenderen av en melding 90 genererer en symmetrisk nøkkel 83, og ved hjelp av denne koder han meldingen 90 Denne symmetriske koding tar bare en brøkdel av tiden som ville vært nødvendig om en asymmetrisk algoritme skulle benyttes Mottageren må kjenne den samme symmetriske nøkkel Den må også bli over-sendt til ham, og riktignok kodet, da en bedrager ellers ville kunne lese nøkkelen 83 under overføringen og detkode den mottatte melding 86 Derfor blir den symmetriske nøkkel 83, den såkalte "sesongnøkkel" kodet med den offentlige nøkkel 84 Den dermed oppståtte, kodede "sesongnøkkel1 ■ blir også kalt tegn 85 Tegnet 85 inneholder også den symmetriske nøkkel 83 som benyttes for chiffrering av meldingen 90, og kodes med den offentlige (asymmetriske) nøkkel 84 i mottageren Tegnet 85 blir overført sammen med den kodede melding 86, signaturen 92 og sertifikatet 98,99

Mottageren dekoder tegnet 85 med sm private nøkkel Dermed oppnår han den nødvendige symmetriske nøkkel 83 for dekoding av meldingen Da bare han har den private nøkkel, kan bare han dechiffrere meldingen

Oversendelse av en digital signert melding med

chiffrering:

Sammenfatning

Avsender

<*> Avsenderen underskriver meldingen 90 med sm private nøkkel 91 <*> Deretter koder han meldingen 90 med en symmetrisk nøkkel

83 generert av ham

<*> Denne symmetriske nøkkel koder han deretter med den offentlige nøkkel 84 på mottageren Herav oppstår tegnet

85

<*> Origmalmeldingen 90 blir deretter sendt til mottageren sammen med signaturen 92, tegnet 85 og de signerte sertifikat 98,99

Mottager

<*> Mottageren dekoder først tegnet 85 med sin private nøkkel <*> Med den derav oppnådde symmetriske nøkkel 83 dekoder han meldingen 90 <*> Nå overprøver han den digitale signatur 92 i meldingen 90 ved hjelp av den offentlige nøkkel 97 som forefinnes

i sertifikatet 98 til avsenderen

<*> Dessuten forsikrer han seg om ektheten til den offentlige nøkkel 97 fra avsenderen, idet han overprøver den digitale signatur 99 til sertifikatet 98 gjennom sertifiseringsinstansen Dertil benytter han den offentlige nøkkel 81 fra sertifiseringsinstansen Tilbakekallingsliste/ugyldighetserklæring av sertifikater.

Anta at kunden blir frastjålet sitt SIM-kort som inneholder vedkommendes private nøkkel 91 Tyven kan da sette inn denne private nøkkel og utgi seg for å være den bestjålne, uten at mottageren merker dette Derfor trenges en mekanisme for å meddele alle brukere at den stjålne, private nøkkel 91 og sertifikatet som hører til dette, ikke lenger er gyldig Dette skjer ved en såkalt liste over ugyldige sertifikater, den ovennevnte Certificate Revocation List (CRL) Denne blir signert digitalt av CA og offentliggjort, det vil si at listen blir tilgjengelig for alle POT-apparater og servere Enhver mottager av en melding fra en kunde må nå også, i tillegg til overprøvingen av signaturen og sertifikatet til avsenderen, kontrollere at den sistnevnte ikke befinner seg i tilbakekallelseslisten, det vil si at han ikke er blitt gjort ugyldig

For at ikke tilbakekallelseslisten (Revokation List) skal bli for stor, blir bare serienummeret samt datoen for sertifikatet som blir erklært for ugyldig tilføyet i steden for hele sertifikatet Listen består altså av serienummer og dato for ugyldighetserklæring, og denne blir nederst signert på digital måte av CA Offentliggjønngsdato for listen og navnet på CA er likeledes tilgjengelig

Trust center og trusted-third-party-tjenesten.

Som vi ovenfor har sett trenges det i et åpent og fordelt system som brukes av flere brukere, og hvor to brukere som ikke råder over noe felles fortrolighetsforhold, for at disse skal kunne kommunisere med hverandre på sikker måte også et tredje sted, hvor disse brukere kan få en sikker-hetstjeneste til rådighet, da nemlig det ellers vil bli en for stor oppgave for brukeren om han selv skulle utveksle og forvalte de nødvendige nøkler Dette tredje sted blir kalt trust-senter eller trusted-third-party (TTP) og tjenesten som her tilbys blir betegnet som TTP-tjeneste CA er f eks en slik tjeneste TTP overtar nøkkelforvaltningsoppgavene for brukeren og nyter derfor deres tillit TTP-tjenesten sørger også for sikring av diverse applikasjoner og protokoller

Bestanddelene til et trusten-third-party er

<*> Registreringsinstans (RA) Den identifiserer brukeren, tar imot brukerens data og fører vedkommende videre til sertifiseringsinstansen Identifikasjon av brukeren er nødvendig, da CA garanterer for at en bestemt offentlig nøkkel tilhører en bestemt person Derfor må disse

personer først identifisere seg

<*> Sertifiseringsinstans (CA) Den fremstiller nøkkel-sertifikat og tilbakekallelseslister Disse blir der-

etter lagt ut i en fortegnelse for offentliggjørelse

eller sendt direkte til brukeren

<*> Nøkkelgenerermg Den genererer nøkkelen for brukeren Den private nøkkel blir overlatt, via en sikker kanal, til brukeren, den offentlige nøkkel blir sendt til CA

med henblikk på sertifisering

<*> Nøkkelpersonaliseringstjeneste Den fremlegger de private nøkler i en modul (f eks et brikkekort), for å

beskytte det mot bruk fra uvedkommende

<*> Nøkkeldeponenngstj eneste (key escrow) Den lagrer en kopi av den benyttede nøkkel (som sikkerhet ved nøkkeltap eller av hensyn til avhør hos politiet for beskyttelse av statssikkerhet eller bekjempelse av

forbrytere)

<*> Arkiveringstjeneste Den arkiverer nøkkelsertifikatet (for å sikre langtidsmulighet for overprøving av digitale signaturer) <*> Fortegnelsestjeneste Den stiller nøkkelsertifikat og tilbakestillingslister til rådighet for brukerne

<*> Notarialtjeneste for

1 Sender og mottagerbevis

2 Tidsstempling

3 Verifisering av innholdets korrekthet (analog til

bestående notarialtjeneste)

I den ovenfor gitte beskrivelse står det hyppig angitt ""mottageren overprøver signaturen" eller ""avsenderen koder meldingen" Naturligvis må brukeren i de vanlige tilfeller ikke selv eksplisitt utføre disse operasjoner, men mobilsystemet 1,10, henholdsvis finans-serveren 4, utføre dette automatisk for ham

Claims (38)

1 Transaksjonsfremgangsmåte mellom en kunde og et fast Punkt-for-transaksjons-(POT)apparat (2,2',2''), som er forbundet med en server (4) gjennom et telekommunikasjonsnett (5, 6), hvilken fremgangsmåte omfatter en sammenlenking av kundedata og POT-apparatidentifisering (POSID) som blir lest eller registrert i POT-apparatet { 2, 2,, 2, t) og sammen med transaksjonsspesifikke data utgjør et transaksjonsdokument, idet kundedata i det minste omfatter en kundeidentifisering (IDUI) som blir lest inn i et bærbart identlfiseringselement hos kunden, hvilket identlfiseringselement (10, 10') idet minste omfatter en prosessor (100, 100', 100<11>) og er slik innrettet at data overføres direkte over et kontaktløst grensesnitt (101-20) til POT-apparatet (2,2',2'') og hvor fremgangsmåten omfatter formidling av transaksjonsdokumentet via telekommunikasjonsnettet (5,6) til serveren (4), karakterisert ved at det før overføringen av transaksjonsdokumentet til serveren fra POT-apparatet (2,2',2'') blir overført en belastningsoppfordring til kundens identlfikasjonselement (10,10'), hvilken oppfordring 1 det minste omfatter transaksjonsspesifikke data (A) for POT-apparatidentifisering samt kundeidentifisering (IDUI), idet overføringen skjer direkte gjennom det kontaktløse grensesnitt (101,20) for overprøving av om belastnings-oppf ordringen er korrelert med kundeidentifiseringen (IDUI)

2 Transaksjonsfremgangsmåte ifølge krav 1, karakterisert ved at de transaksjonsspesifikke data i det minste omfatter et pengebeløp (A) som skal betales, hvilket pengebeløp (A) blir sammenlignet med et lagret pengebeløp i et bærbart ldentifi-seringselement

3 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at identlfiseringselementet (10) er et SIM-kort

4 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at identlfiseringselementet er en transponder (10')

5 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at transponderen (10') kommuniserer over et infrarødt grensesnitt med POT-apparatet (2,2,,2'<1>)

6 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at identlfiseringselementet (10,10') kommuniserer via en spole som er integrert i POT-apparatet (2,2',2'')

7 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at identlfiseringselementet (10,10<*>) er slik innrettet at det kan samarbeide funksjonelt med et mobilapparat (1,24) for å sende og/eller motta kortmeldinger ved hjelp av mobilapparatet gjennom et mobiltelefon-nett (6)

8 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at mobilapparatet (24) inneholdes i POT-apparatet (2")

9 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at transaksjonsdokumentet blir overført til serveren (4) gjennom mobiltelefonnettet (6)

10 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at minst noen av de data som blir overført mellom POT-apparatet (2,2',2") og identlfiseringselementet (10,10') over det kontaktløse grensesnittet, blir kodet

11 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at transaksjonsdokumentene som blir overført gjennom telekommunikasjonsnettet (5,6), blir kodet

12 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at transaksjonsdokumentene som blir overført gjennom telekommunikasjonsnettet (5,6), ikke blir kodet under over-føringen

13 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at transaksjonsdokumentet blir kodet med en symmetrisk algoritme, idet den symmetriske algoritme blir benyttet sammen med en sesong-tast (83) som benytter en asymmetrisk algoritme

14 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at transaksjonsdokumentet som blir overført gjennom telekommunikasjonsnettet (5,6), blir sertifisert

15 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at transaksjonsdokumentet som overføres gjennom telekommunikasjonsnettet (5,6) inneholder en elektronisk signatur for identlfiseringselementene (10,10') i POT-apparatet og kan etterprøves av serveren

16 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at transaksjonsdokumentet som overføres gjennom telekommunikasjonsnettet (5,6), inneholder en elektronisk signatur for POT-apparatet og at denne kan etterprøves av serveren

17 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved følgende trinn fremstilling av "hash-verdier" (93) fra transaksjonsdokumentet (90) , chifrering av disse "hash-verdier" med en privat nøkkel (91) lagret på et identlfiseringselement (10,10'), signering av transaksjonsdokumentet (90) med den chifrerte hash-verdi

18 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at transaksjonsdokumentet blir formidlet over en klareringsenhet (3) i serveren (4)

19 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at de dataelementer (IDUI) som er nødvendige for klarering i klareringsenheten (3) ikke blir kodet, slik at klareringsenheten ikke må dekode transaksjonsdokumentet

20 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at de transaksjonsspesifikke data (A) blir innlest i eller registrert i POT-apparatet (2,2',2")

21 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at de transaksjonsspesifikke data (A) blir innlest i eller registrert i mobilapparatet (1)

22 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at serveren (4) lagrer en kundesvarteliste og at fremgangsmåten blir avbrudt når den mottatte kundeidentifikasjon (IDUI) foreligger i svartelisten

23 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at serveren (4) lagrer en POT-svarteliste og at fremgangsmåten avbrytes dersom den mottatte POT-apparatidentifikasjon (POSID) foreligger i POT-svartelisten

24 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at POT-apparatet (2,2',2") lagrer en kundesvarteliste som er oppdatert av serveren (4), og at fremgangsmåten blir avbrudt dersom kundeidentifikasjonen (IDUI) foreligger i kundesvarte-listen

25 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at identlfikasjonselementet blir i det minste delvis sperret dersom kundeidentifikasjonen foreligger i en kundesvarteliste 1 POT-apparatet og/eller i serveren (4)

2 6 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at identlfikasjonselementet (10,10') inneholder et lager med data over allerede gjennomførte transaksjoner, og at disse data kan hentes fra serveren

27 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at de transaksjonsspesifikke data omfatter et pengebeløp (A), at serveren (4) blir forvaltet av et finansinstitutt, og at et pengebeløp som er lagret på identlfikasjonselementet (10,10') mens transaksjonen blir bokført

28 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at pengebeløpet (A) som er lagret på identlfiseringselementet (10, 10') kan bli ettermnlastet med et innlastingsdokument fra serveren (4)

2 9 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at pengebeløpet (A) angis i en standard myntfot

3 0 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at de transaksjonsspesifikke data blir overført fra POT-apparatet (2,2',2") til serveren (4) over et annet kontakt-løst grensesnitt som transmisjonsspesifikke data fra identlfikasjonselementet (10, 10')

31 Transaksjonsfremgangsmåte ifølge et av de foregående krav, karakterisert ved at i det minste noen data blir overført fra serveren (4) gjennom et mobiltelefonnett (6) til mobilapparatdelen (24) til POT-apparatet (2"), og fra denne videreføres til transponderen (10')

32 Identlfiseringselement (10,10') som kan benyttes ved en transaksjonsfremgangsmåte ifølge et av de ovenstående krav, karakterisert ved at identlfikasjonselementet (10,10') omfatter minst en prosessor (100,100<1>,101) som inneholder et lagringselement hvori en kundeidentifikasjon (IDUI) er lagret, hvilket ldentifika-sjonselement (10,10') inneholder elektroniske signerings-midler innrettet til å forsyne transaksjonsdokumentet, som minst inneholder kundeidentifikasjonen (IDUI), med en elektronisk signatur, og hvilket identlfikasjonselement (10,10') omfatter et kontaktløst grensesnitt (101,-20) for å videreføre det signerte transaksjonsdokument direkte til et POT-apparat (2,2',2") og hvor identlfikasjonselementet (10,10') dessuten inneholder en anordning for å motta en belastningsoppfordrmg, som i det minste omfatter kundeidentifikasjonen (IDUI), en POT-apparat identifikasjon (POSID) samt transaksjons-speisfikke data (A), direkte gjennom det kontaktløse grensesnitt (101-20) for å overprøve om belastningsoppfordringen korrelerer med kundeidentifikasjonen (IDUI)

33 Identlfiseringselement (10,10') ifølge krav 32, karakterisert ved at det dessuten inneholder en sammenligningsanordning for å sammenligne pengebeløpet (A) som ifølge de transaksjonsspesifikke data (A) skal betales med et pengebeløp som er lagret i identlfikasjonselementet (10,10') for derved å kontrollere om kunden er solvent

34 Identlfiseringselement (10,10') ifølge et av kravene 32 - 33, karakterisert ved at signaturmidlene omfatter følgende elementer - en privat nøkkel (91) lagret i lageret, - en innretning for fremstilling av en "hash-verdi" (93) fra et ikke-kodet transaksjonsdokument (90), - en innretning for å kode "hash-verdien" med en privat kode (91) og for å signere transaksjonsdokumentet med den chifrerte "hash-verdi"(92)

35 Identlfiseringselement {10,10') ifølge et av kravene 32 - 34, karakterisert ved at det omfatter en deri integrert spole for kommunikasjon over det kontaktløse grensesnitt(101 -20)

36 Identlfiseringselement (10,10') ifølge et av kravene 32 - 34, karakterisert ved at det er en transponder (10') som omfatter et kontaktløst grensesnitt (101 - 20) for kommunikasjon med en infrarød sender/mottager

37 Identlfiseringselement (10,10') ifølge et av kravene 32 - 35, karakterisert ved at det er et SIM-kort

38 Identlfiseringselement (10,10') ifølge krav 37, karakterisert ved at SIM-kortet er et verdikort (debetkort eller kontantkort)