NO326556B1

NO326556B1 - Method and system for strong authentication using pregenerated GSM authentication data

Info

Publication number: NO326556B1
Application number: NO20062751A
Authority: NO
Inventors: Thuan Van Do
Original assignee: Ubisafe As
Priority date: 2006-06-13
Filing date: 2006-06-13
Publication date: 2009-01-12
Also published as: NO20062751L

Abstract

En metode og ett system for sterk autentisering til tjenester og applikasjoner lokalisert i personlig datamaskin eller Personal Digital Assistant som er basert på forhåndsgenerert GSM autentiseringsdata.Systemet muliggjør generasjon og administrasjon av GSM SIM autentiseringsdata som er generert av SIM kort. Autentiserinsdata vil bli brukt ved autentisering av bruker. Systemet vil også detektere og initiere generering av autentiseringsdata når en terskel er nådd.A method and one system for strong authentication to services and applications located in personal computer or Personal Digital Assistant which is based on pre-generated GSM authentication data. The system enables generation and management of GSM SIM authentication data generated by SIM cards. Authentication data will be used when authenticating the user. The system will also detect and initiate the generation of authentication data when a threshold is reached.

Description

ET ARRANGEMENT OG METODE FOR ADMINISTRASJON AV FORHÅNDSGENERERTE STERKE SIM-AUTENTISERINGSDATA AN ARRANGEMENT AND METHOD FOR ADMINISTRATION OF PRE-GENERATED STRONG SIM AUTHENTICATION DATA

Oppfinnelsens område Field of the invention

Denne oppfinnelsen gjelder en autentiseringsmetode som bruker et sett av GSM autentiseringsdata for å autentisere en bruker som forsøker å benytte seg av en applikasjon eller tjeneste på Internett. This invention relates to an authentication method that uses a set of GSM authentication data to authenticate a user who attempts to use an application or service on the Internet.

Teknisk bakgrunn Technical background

En rekke tjenester i Internet-domenet, som i telekom-domenet, krever en form for autentisering a brukeren, dvs. å verifisere at brukeren er den han eller hun utgir seg for å være. Dette er særdeles viktig for tjenester som inkluderer kjøp hvor den autentiserte brukeren automatisk kan bli økonomisk belastet basert på de presenterte fullmaktene (credentials). Eksempler på tjenester som krever autentisering er mobil taletelefoni (f.eks. GSM), banktjenester på Internett, butikker på World-Wide-Web med brukerkontoer, Voice-over-IP tjenester (f.eks. Skype), pratetjenester (f.eks. MSN Messenger), etc. For hver slik tjeneste må brukeren besitte informasjon som kan benyttes for å verifisere han eller hennes identitet. Den mest brukte type slik informasjon er par med brukernavn og passord (referert til som passordbasert autentisering). A number of services in the Internet domain, as in the telecom domain, require a form of user authentication, i.e. verifying that the user is who he or she claims to be. This is particularly important for services that include purchases where the authenticated user can automatically be financially charged based on the credentials presented. Examples of services that require authentication are mobile voice telephony (e.g. GSM), banking services on the Internet, shops on the World-Wide-Web with user accounts, Voice-over-IP services (e.g. Skype), chat services (e.g. . MSN Messenger), etc. For each such service, the user must possess information that can be used to verify his or her identity. The most commonly used type of such information is username and password pairs (referred to as password-based authentication).

For mange typer tjenester er passordbasert autentisering en tilstrekkelig løsning og tilbyr god nok sikkerhet, men for noen tjenester er passordbasert autentisering en for svak autentiseringsmekanisme. F.eks. krever vanligvis banktjenester på Internett engangspassordkalkulatorer (OTP) og digitale sertifikater. For many types of services, password-based authentication is a sufficient solution and offers good enough security, but for some services, password-based authentication is too weak an authentication mechanism. E.g. Internet banking usually requires one-time password (OTP) calculators and digital certificates.

En annen svakhet med passordbasert autentisering er brukerens håndtering/administrasjon av denne informasjonen. Sikkerheten er avhengig av at brukerne velger passord som er vanskelige å gjette, og at de bruker forskjellige passord for de ulike tjenestene, og dette blir en uhåndterlig oppgave for brukeren med tanke på det økende antall tjenester som krever autentisering. Resultatet er at de fleste brukerne velger enkle passord som er lette å huske, og at de ofte bruker de samme brukernavn/passord-parene for flere tjenester. Another weakness of password-based authentication is the user's handling/administration of this information. Security depends on users choosing passwords that are difficult to guess, and that they use different passwords for the various services, and this becomes an unmanageable task for the user in view of the increasing number of services that require authentication. The result is that most users choose simple passwords that are easy to remember, and that they often use the same username/password pairs for several services.

Kjente løsninger Known solutions

Det eksisterer i dag ingen liknende løsninger til den foreslåtte arkitekturen. There are currently no similar solutions to the proposed architecture.

Oppsummering av oppfinnelsen Summary of the invention

Denne oppfinnelsen foreslår en autentiseringsmetode som bruker forhåndsgenererte GSM autentiseringsdata og tilbyr en løsning for å lage og administrere forhåndsgenererte GSM autentiseringsdata, som senere kan bli brukt for å autentisere brukerne ved å bruke deres SIM-kort. Løsningen kan brukes til å autentisere brukerne mot en hvilken som helst tjeneste eller applikasjon som er tilbudt av en hvilken som helst tjenesteleverandør som er koblet opp mot den spesifiserte infrastrukturen ved å benytte de beskrevne mekanismene. This invention proposes an authentication method using pre-generated GSM authentication data and offers a solution for creating and managing pre-generated GSM authentication data, which can later be used to authenticate users using their SIM cards. The solution can be used to authenticate users against any service or application offered by any service provider connected to the specified infrastructure by using the described mechanisms.

Kort beskrivelse av tegningene Brief description of the drawings

Oppfinnelsen vil nå bli beskrevet i detalj med referanse til de vedlagte tegningene, hvor: Figur 1 viser en overordnet arkitektur med alle de viktigste komponentene og grensesnittene mellom dem. Figur 2 viser et sekvensdiagram som illusterer prosessen med å samle autentiseringsdata for brukeren fra SIM-kortet og overfører disse til Authentication Data Storage. Figur 3 viser et sekvensdiagram som illusterer prosessen med å autentisere en bruker. The invention will now be described in detail with reference to the attached drawings, where: Figure 1 shows an overall architecture with all the most important components and the interfaces between them. Figure 2 shows a sequence diagram illustrating the process of collecting authentication data for the user from the SIM card and transferring this to the Authentication Data Storage. Figure 3 shows a sequence diagram illustrating the process of authenticating a user.

Detaljert beskrivelse Detailed description

Denne oppfinnelsen tilbyr en metode for å benytte GSM SIM-autentisering uten kravet om en oppkobling til et reelt GSM-nettverk. Autentiseringen er basert på forhåndsgenererte GSM autentiseringsdata som er etablert ved å kommunisere med brukerens SIM-kort. Disse er deretter overført til en server/tjener for administrasjon og påfølgende autentisering av brukeren når vedkommende prøver å benytte seg av en tjeneste med beskyttede ressurser. This invention offers a method of using GSM SIM authentication without the requirement of a connection to a real GSM network. The authentication is based on pre-generated GSM authentication data which is established by communicating with the user's SIM card. These are then transferred to a server for administration and subsequent authentication of the user when he tries to use a service with protected resources.

Oppfinnelsen består av to hoveddeler: The invention consists of two main parts:

• Metoden å benytte ett forhåndsgenerert sett av GSM autentiseringsdata for å autentisere brukeren som er definert i det vedføyde selvstendige krav 1. • Systemet som muliggjør generering og administrasjon av SIM autentiseringsdata samlet inn på en distribuert måte og lagret i en sentralisert autentiseringstjener som er definert i det vedføyde selvstendige krav 9. • The method of using a pre-generated set of GSM authentication data to authenticate the user defined in the attached independent claim 1. • The system enabling the generation and management of SIM authentication data collected in a distributed manner and stored in a centralized authentication server defined in the attached independent claim 9.

Figur 1 viser hovedkomponentene som er relatert til oppfinnelsen. Figure 1 shows the main components related to the invention.

Oppfinnelsen muliggjør generering av autentiseringsdata både hos tjenesteleverandørens (Service Provider) kontor under veiledning av autorisert personell eller på brukerens private datamaskin. The invention enables the generation of authentication data both at the service provider's (Service Provider) office under the guidance of authorized personnel or on the user's private computer.

Det er to komponenter både på klientterminalen (sluttbrukerens datamaskin) og tjenesteleverandørens terminal (tjenesteleverandørens datamaskin): There are two components on both the client terminal (the end user's computer) and the service provider's terminal (the service provider's computer):

• Authentication Data Management Client • Authentication Data Management Client

• Supplicant • Supplicant

Disse samarbeider med These cooperate with

• Authentication Data Management Server for generering av autentiseringsdata • Authentication Data Management Server for generating authentication data

• Authenticator for autentisering av brukeren • Authenticator for authenticating the user

For å autentisere brukeren er det installert en supplikant på sluttbrukerens datamaskin. Denne kommuniserer med SIM-kortet for å få tak i SRES som er sendt til Authenticator som befinner seg hos tjenesteleverandørens tjener, og som blir benyttet for autentiseringen. Authenticator sammenligner SRES med den mottatt fra Authentication Data Storage. Hvis disse er like betyr dette at brukeren er autentisert. To authenticate the user, a supplicant is installed on the end user's computer. This communicates with the SIM card to obtain the SRES that is sent to the Authenticator located at the service provider's server, and which is used for the authentication. Authenticator compares the SRES with the one received from the Authentication Data Storage. If these are the same, this means that the user is authenticated.

Komponentenes funksjonalitet The functionality of the components

Authentication Data Management Client Authentication Data Management Client

Authentication Data Management Client er ansvarlig for å kommunisere med brukerens SIM-kort for å generere autentiseringsdata, og for å overføre disse autentiseringsdata til Authentication Data Management Server på en sikker måte. The Authentication Data Management Client is responsible for communicating with the user's SIM card to generate authentication data, and for transmitting this authentication data to the Authentication Data Management Server in a secure manner.

Authentication Data Management Client kan være installert på en datamaskin som tilhører tjenesteleverandøren som benytter autentiseringsmetoden basert på forhåndsgenererte sett av GSM/UMTS autentiseringsdata, f.eks. banker, bedrifter, offentlige tjenester, etc. Den kan også være installert på en datamaskin som tilhører sluttbrukeren. For å tilby en høy grad av sikkerhet kan Authentication Data Management Client kreve at supplikanten, som også er installert på samme datamaskin, foretar en autentisering av brukeren før generering av autentiseringsdata starter. Dette kan f.eks. være personell som er autorisert til å generere autentiseringsdata hos tjenesteleverandøren eller hos sluttbrukeren. The Authentication Data Management Client may be installed on a computer belonging to the service provider that uses the authentication method based on pre-generated sets of GSM/UMTS authentication data, e.g. banks, companies, public services, etc. It can also be installed on a computer belonging to the end user. In order to offer a high level of security, the Authentication Data Management Client may require the supplicant, which is also installed on the same computer, to authenticate the user before the generation of authentication data starts. This can e.g. be personnel authorized to generate authentication data at the service provider or at the end user.

Authentication Data Management Client må være utstyrt med en metode som kan varsle brukeren om at antallet tilgjengelige autentiseringsdata er lavere enn et forhåndsdefinert antall, og deretter kan initiere generering av data som følger: NotifyAuthenticationData( IMSI) - Denne methoden varsler brukeren om at det er nødvendig å generere nye autentiseringsdata ((RAND, SRES, Kc) x N) for brukeren identifisert med IMSI. The Authentication Data Management Client must be provided with a method that can notify the user that the number of available authentication data is lower than a predefined number, and then can initiate the generation of data as follows: NotifyAuthenticationData( IMSI) - This method notifies the user that it is necessary to generate new authentication data ((RAND, SRES, Kc) x N) for the user identified by IMSI.

Generering av Kc, som er krypteringsnøkkelen, er valgfritt og bare påkrevet når det er nødvendig med kryptering av kommunikasjonskanalen. Generation of Kc, which is the encryption key, is optional and only required when encryption of the communication channel is required.

Metoden er veldig viktig fordi den tillater Authentication Data Management Server å starte genereringen av nye autentiseringsdata når antall ubrukte The method is very important because it allows the Authentication Data Management Server to start the generation of new authentication data when the number of unused

autentiseringstriplets går under en bestemt grense. authentication triplets go below a certain limit.

De genererte autentiseringsdataene består av brukerens International Mobile Subscriber Identity (IMSI) og et antall (n) triplets: The generated authentication data consists of the user's International Mobile Subscriber Identity (IMSI) and a number (n) of triplets:

( RANDi, SRES! = A3 ( RAND2) , Kc2 = A8 ( RAND2 )) ( RANDi, SRES! = A3 ( RAND2) , Kc2 = A8 ( RAND2 ))

( RANDn, SRESn= A3 ( RANDn) , Kcn= A8 ( RAND2) ( RANDn, SRESn= A3 ( RANDn) , Kcn= A8 ( RAND2)

RANDi..n - Dette er tilfeldige (random) byte arrays av med lengde 16. RANDi..n - These are random byte arrays of length 16.

SRESi..n = A3(RAND!..n) - Disse tallene er de signerte responsene som er resultatet av å kjøre A3-algoritmen på SIM-kortet med RANDi..n og den 128-bit Individual Subscriber Authentication Key (Ki) som parametre. SRESi..n = A3(RAND!..n) - These numbers are the signed responses resulting from running the A3 algorithm on the SIM card with RANDi..n and the 128-bit Individual Subscriber Authentication Key (Ki) as parameters.

Kci..n = A8(RAND!..n) - Disse tallene er de signerte responsene som er resultatet av å kjøre A8-algoritmen på SIM-kortet med RANDi..n og den 128-bit Individual Subscriber Authentication Key (Ki) som parametre. Kci..n = A8(RAND!..n) - These numbers are the signed responses resulting from running the A8 algorithm on the SIM card with RANDi..n and the 128-bit Individual Subscriber Authentication Key (Ki) as parameters.

n må være valgt på basis av hvor mange autentiserte brukersesjoner som skal være støttet før nye autentiseringsdata må genereres (som krever fysisk tilgang til SIM-kortet). n must be chosen on the basis of how many authenticated user sessions must be supported before new authentication data must be generated (which requires physical access to the SIM card).

Authentication Data Management Client må også tilby brukeren muligheten for å starte generering av autentiseringsdata. The Authentication Data Management Client must also offer the user the option to initiate the generation of authentication data.

SIM- kort SIM card

SIM-kortet er et GSM SIM-kort. Det er benyttet over Ia grensesnittet (av Authentication Data Management Client) og Ie grensesnittet (av Supplicant). I praksis er disse grensesnittene helt like, dvs. At meldingene som går over disse grensesnittene er de samme, men meldingssekvensen over grensesnittene er forskjellige (dette kan sees i Figur 2 og Figur 3). The SIM card is a GSM SIM card. It is used over the Ia interface (by the Authentication Data Management Client) and the Ie interface (by the Supplicant). In practice, these interfaces are exactly the same, i.e. that the messages that go over these interfaces are the same, but the message sequence over the interfaces is different (this can be seen in Figure 2 and Figure 3).

Den fysiske tilgangen under grensesnitt Ie kan være hvilken som helst av følgende (avhengig av den reelle støtten på enheten det dreier seg om): The physical access under interface Ie can be any of the following (depending on the actual support on the device in question):

- Bluetooth mot en mobiltelefon - Bluetooth to a mobile phone

- Seriell forbindelse mot en serieport på mobiltelefonen - Serial connection to a serial port on the mobile phone

- Seriell forbindelse mot en Smart Kort/SIM-kort leser - Serial connection to a Smart Card/SIM card reader

- USB forbindelse mot en mobiltelefon - USB connection to a mobile phone

- USB forbindelse mot en Smart Kort/SIM-kort leser - USB connection to a Smart Card/SIM card reader

- USB forbindelse mot en SIM-dongle - USB connection to a SIM dongle

- IrDA mot en mobiltelefon - IrDA against a mobile phone

Authentication Data Management Server Authentication Data Management Server

Autentiserings Data Management Server er ansvarlig for å mottat autentiseringsdata fra Authentication Data Management Client og videresende denne til riktig largingskomponent. Denne komponenten er benyttet over Ib grensesnittet (av the Authentication Data Management Client). All informasjonen som går over Ib grensesnittet er sikret med kryptering, f.eks. ved å benytte Transaction Layer Security (TLS), for å hindre at andre skal få innsyn i sensitive autentiseringsdata. Ib grensesnittet vil I tillegg være styrt av Service Level Agreements mellom tjenesteleverandør og enheten ansvarlig for Authentication Data Management Server, med mindre disse er de samme enhetene. Ib grensesnitte må minst støtte følgende metoder: updateAuthenticationData( IMSI, ( RAND, SRES, Kc) xN) - Denne metoden oppdaterer autentiseringsdata ((RAND, SRES, Kc) x N) for brukeren identifisert med IMSI. The Authentication Data Management Server is responsible for receiving authentication data from the Authentication Data Management Client and forwarding this to the correct sending component. This component is used over the Ib interface (by the Authentication Data Management Client). All the information that goes over the Ib interface is secured with encryption, e.g. by using Transaction Layer Security (TLS), to prevent others from gaining access to sensitive authentication data. The Ib interface will also be governed by Service Level Agreements between the service provider and the entity responsible for the Authentication Data Management Server, unless these are the same entities. Ib interface must at least support the following methods: updateAuthenticationData( IMSI, ( RAND, SRES, Kc) xN) - This method updates authentication data ((RAND, SRES, Kc) x N) for the user identified by IMSI.

I tillegg til Ic grensesnittet må det eksistere en metode som tillater Authentication Data Storage å varlse at antall autentiseringsdata er under en forhåndsdefinert terskelverdi og at generering av nye data er nødvendig: NotifyAuthenticationData( IMSI) - Denne metoden varsler at generering av nye autentiseringsdata, for brukeren identifisert med IMSI, er nødvendig. In addition to the Ic interface, there must be a method that allows Authentication Data Storage to notify that the number of authentication data is below a predefined threshold value and that the generation of new data is necessary: NotifyAuthenticationData( IMSI) - This method notifies the user that the generation of new authentication data identified by IMSI, is required.

Ved kall på denne metoden vil Authentication Data Management Server kalle den korresponderende metoden NotifyAuthenticationData( IMSI) i Authentication Data Management Client. When calling this method, the Authentication Data Management Server will call the corresponding method NotifyAuthenticationData (IMSI) in the Authentication Data Management Client.

Authentication Data Storage Authentication Data Storage

Denne komponenten står for den faktiske lagringen av autentiseringsdata, og tilbyr er sikker, konsistent lagring av autentiseringsdata. Denne komponenten er samlokert med Authentication Data Management Server og i noen tilfeller også med Authenticator, for å tilby maksimum sikkerhet og hindre potensielle "eavesdroppers" å få tilgang til sensitive autentiseringsdata som er overført mellom komponentene. Denne komponenten er benyttet over Ic grensesnittet(av Authentication Data Management Server) og Id grensenittet (av Authenticator). Ic grensesnittet må minst støtte følgende metode: storeAuthentlcatlonData( IMSI, ( RAND, SRES, Kc) xN) - Denne metoden sørger for persistent larging av autentiseringsdata ((RAND, SRES)xN) for brukeren identifisert med IMSI. This component is responsible for the actual storage of authentication data and offers secure, consistent storage of authentication data. This component is co-located with the Authentication Data Management Server and in some cases also with the Authenticator, to offer maximum security and prevent potential "eavesdroppers" from accessing sensitive authentication data transferred between the components. This component is used over the Ic interface (by Authentication Data Management Server) and the Id interface (by Authenticator). The Ic interface must at least support the following method: storeAuthentlcatlonData( IMSI, ( RAND, SRES, Kc) xN) - This method ensures persistent larging of authentication data ((RAND, SRES)xN) for the user identified by IMSI.

Authentication Data Storage må være utstyrt med en overvåkningsmekanisme som monitorerer antall ubrukte autentiseringsdata. Når denne er under en forhåndsdefinert grense så vil Authentication Data Storage forespørre Authentcation Data Management Server om å initiere generering av nye sett med autentiseringsdata. Authentication Data Storage must be equipped with a monitoring mechanism that monitors the number of unused authentication data. When this is below a predefined limit, the Authentication Data Storage will request the Authentication Data Management Server to initiate the generation of new sets of authentication data.

Authentication Data Storage kommuniserer med Authenticator over Id grensesnittet som støtter minst følgende metode: getAuthData( IMSI, RAND, XRES, Kc) - Denne metoden tillater en Authenticator å forespørre autentiseringsdata for brukeren spesifisert med IMSI fra Authentication Data Storage. Authentication Data Storage returnerer et par med autentiseringsdata (RAND, XRES) til Authenticator. Authentication Data Storage communicates with the Authenticator over the Id interface which supports at least the following method: getAuthData( IMSI, RAND, XRES, Kc) - This method allows an Authenticator to request authentication data for the user specified by IMSI from the Authentication Data Storage. Authentication Data Storage returns a pair of authentication data (RAND, XRES) to the Authenticator.

Service Client Service Client

Service Client representerer en generisk klientapplikasjon som kjører på en datamaskin, og som krever autentisering for å få tilgang til en annen komponent av tjenesten som befinner seg på en annen lokasjon (representert med Services boksen i Figur 1). Klienten kan for eksempel være en Web-browser eller en Voice-over-IP klient. Denne klientapplikasjonen kan spørre Supplicant for en autentiseringstoken som representerer en autentisert sesjon for denne brukeren. Hvis Supplicant ikke kan levere en slik token så kan den etter forespørsel fra klientapplikasjonen initiere en autentiseringsprosess ved å sende en autentiseringsforespørsel til Authenticator. Service Client represents a generic client application that runs on a computer, and which requires authentication to access another component of the service located in another location (represented by the Services box in Figure 1). The client can, for example, be a Web browser or a Voice-over-IP client. This client application can query the Supplicant for an authentication token that represents an authenticated session for this user. If the Supplicant cannot provide such a token then it can, upon request from the client application, initiate an authentication process by sending an authentication request to the Authenticator.

Supplicant Supplicant

Supplicant er en programvaremodul som befinner seg på klientdatamaskinen, og som autentiserer brukeren gjennom Authenticator (beskrevet ovenfor). Supplicant eksponerer et standardisert grensesnitt som autentiseringstoken kan bli utvekslet over. Supplicant is a software module located on the client computer that authenticates the user through the Authenticator (described above). Supplicant exposes a standardized interface over which authentication tokens can be exchanged.

Supplicant er benyttet over If grensesnittet av Service Clients og av Authentication Data Management Client. Grensesnittet består av følgende metode: Supplicant is used over the If interface by Service Clients and by the Authentication Data Management Client. The interface consists of the following method:

auth& nticat& Us& r( AuthTok& n) auth& nticat& Us& r( AuthTok& n)

Denne metoden tillater Service Clients og Authentication Data Management Client å forespørre en autentisering av brukeren. This method allows Service Clients and the Authentication Data Management Client to request an authentication of the user.

Før det er tillatt å generere autentiseringsdata kan det også være nødvendig å autentisere brukeren, som kan være autorisert personell hos tjenesteleverandøren eller sluttbrukeren. Before it is allowed to generate authentication data, it may also be necessary to authenticate the user, who may be authorized personnel of the service provider or the end user.

Supplicant må ha et brukergrensesnitt som tillater brukeren å velge mellom tre alternativer: The supplicant must have a user interface that allows the user to choose between three options:

• Førstegangsinnlogging • First time login

• Sluttbrukerinnlogging • End user login

• Innlogging av autorisert personell • Login by authorized personnel

Førstegangsinnlogging: Sluttbrukeren har nettopp abonnert på autentisering basert på forhåndsgenererte GSM autentiseringsdata. Han/hun mottok et brukernavn og et etgangspassord fra tjenesteleverandøren, levert på en sikker måte som f.eks. rekommendert post eller sikker kryptert e-post. Ved å velge førstegangsinnlogging vil brukeren bli spurt om å skrive brukernavnet og engangspassordet. First login: The end user has just subscribed to authentication based on pre-generated GSM authentication data. He/she received a username and a one-time password from the service provider, delivered in a secure way such as e.g. registered mail or secure encrypted email. By selecting first-time login, the user will be asked to enter the username and one-time password.

Sluttbrukerinnlogging: Sluttbrukeren vil bli spurt om å forberede autentiseringen med mobiltelefonen med Bluetooth, SIM-dongle, kortleser eller PCMCIA med SIM installert. For å oppnå en sterkere autentisering, dvs. to-faktor autentisering basert på noe man besitter og noe man vet, vil brukeren bli spurt om å taste inn en PIN-kode. End user login: The end user will be asked to prepare the authentication with the mobile phone with Bluetooth, SIM dongle, card reader or PCMCIA with SIM installed. In order to achieve stronger authentication, i.e. two-factor authentication based on something you possess and something you know, the user will be asked to enter a PIN code.

Innlogging av autorisert personell: Den ansatte hos tjenesteleverandørens kontor kan bli autentisert ved å bruke passord eller en mobiltelefon med Bluetooth, SIM-dongle, kortleser eller PCMCIA med SIM-kort installert. Login by authorized personnel: The employee at the service provider's office can be authenticated using a password or a mobile phone with Bluetooth, SIM dongle, card reader or PCMCIA with SIM card installed.

Authenticator Authenticator

Authenticator har muligheten til å verifisere om den autentiseringsinformasjonen som blir presentert av brukeren er gyldig eller ikke. Dette betyr ikke nødvendigvis at verifiseringen er utført lokalt av Authenticator, men Authenticator vil i de fleste tilfellene kontakte andre enheter for den faktiske verifiseringsprosessen (f.eks. en RADIUS-tjener). Authenticator er benyttet over Ih grensesnittet (av Supplicant). Authenticator has the ability to verify whether the authentication information presented by the user is valid or not. This does not necessarily mean that the verification is performed locally by the Authenticator, but the Authenticator will in most cases contact other devices for the actual verification process (eg a RADIUS server). Authenticator is used over the Ih interface (by Supplicant).

Metodene som er kalt over dette grensesnittet er avhengig av den spesifikke autentiseringsfunksjonen, men grensesnittet må minst støtte de følgende metodene: AuthResponse authRequest( AuthRequest reqaest) - Denne metoden initierer en autentiseringsprosedyre mot Authenticator. Kravene til autentiseringen, dvs. autentiseringsnivå, så vel som brukerens autentiseringsinformasjon er sendt i AuthRequest parameteret. AuthResponse inneholder resultatet av metodekallet. The methods called over this interface depend on the specific authentication function, but the interface must at least support the following methods: AuthResponse authRequest( AuthRequest reqaest) - This method initiates an authentication procedure against the Authenticator. The requirements for the authentication, i.e. authentication level, as well as the user's authentication information are sent in the AuthRequest parameter. AuthResponse contains the result of the method call.

Det vil i mange tilfeller være nødvendig å sende flere autentiseringsforespørsler for å gjennomføre en komplett autentiseringsprosedyre. For eksempel, med GSM SIM-autentisering så vil den første forespørselen inneholde abonnentens identitet (IMSI) som gjør det mulig for Authenticator å hente ut en utfordring fra Authentication Data Storage. Denne utfordringen (RAND) vil bli returnert I den første AuthResponse til Supplicant og muliggjør at SIM-kortet kan kalkulere en GSM-triplet ved å benytte A3-algoritmen [4]. Resultatet av A3-algoritmen (SRES) vil bli sendt tilbake til Authenticator i en ny AuthRequest gjennom den samme metoden. Hvis svaret fra Supplicant er korrekt vil autentiseringsprosessen avsluttet ved at Authenticator sender en endelig AuthResponse tilbake til Supplicant. Denne endelig AuthResponse vil inneholde en autentiseringstoken som kan bli brukt av Service Client i påfølgende bruk av den aktuelle tjenesten. In many cases, it will be necessary to send several authentication requests to carry out a complete authentication procedure. For example, with GSM SIM authentication, the first request will contain the subscriber's identity (IMSI) which enables the Authenticator to retrieve a challenge from the Authentication Data Storage. This challenge (RAND) will be returned in the first AuthResponse to the Supplicant and enables the SIM card to calculate a GSM triplet by using the A3 algorithm [4]. The result of the A3 algorithm (SRES) will be sent back to the Authenticator in a new AuthRequest through the same method. If the response from the Supplicant is correct, the authentication process will end with the Authenticator sending a final AuthResponse back to the Supplicant. This final AuthResponse will contain an authentication token that can be used by the Service Client in subsequent use of the service in question.

Meldingssekvensdiagrammer Message Sequence Diagrams

Oppdatering av brukerens autentiseringsdata Updating the user's authentication data

Figur 2 viser et meldingssekvensdiagram som illusterer hvordan SIM-autentiseringsdata kan bli oppdatert for en bruker. Figure 2 shows a message sequence diagram illustrating how SIM authentication data can be updated for a user.

Meldingene i Figur 2 er som følger: The messages in Figure 2 are as follows:

1: runA3( RAND) - Authentication Data Management Client kjører A3 på brukerens SIM-kort, og bruker et tilfeldig generert byte array som parameter (RAND). 1: runA3( RAND) - Authentication Data Management Client runs A3 on the user's SIM card, using a randomly generated byte array as parameter (RAND).

2: runA3Response ( SRES) - SIM-kortet returnerer en signert respons (SRES) som er generert av A3-algoritmen basert på 2: runA3Response (SRES) - the SIM card returns a signed response (SRES) generated by the A3 algorithm based on

RAND. RAND.

3: runA3( RAND) - Samme som 1) 3: runA3( RAND) - Same as 1)

4: runA3Response ( SRES) - Samme som 2) 4: runA3Response ( SRES) - Same as 2)

5: updateAuthenticationData ( IMSI, ( RAND, SRES) x N) Authentication Data Management Client sender N par med autentiseringsdata (RAND, SRES) for brukeren identifisert med IMSI, til Authentication Data Management Server. 5: updateAuthenticationData ( IMSI, ( RAND, SRES) x N) The Authentication Data Management Client sends N pairs of authentication data (RAND, SRES) for the user identified by the IMSI, to the Authentication Data Management Server.

6: storeAuthenticationData ( IMSI, ( RAND, XRES) xN) - De motatte autentiseringsdata blir lagret i en database for senere bruk. 6: storeAuthenticationData ( IMSI, ( RAND, XRES) xN) - The received authentication data is stored in a database for later use.

Melding 1 og 2 (tilsvarer 3 og 4) må kjøre mange ganger for å generere et så stort sett som nødvendig med utfordringer (RAND) og responser (SRES). For å oppnå maksimum sikkerhet i senere autentiseringsprosesser bør ikke utfordringer/responser gjenbrukes. Dette betyr at hvert genererte par i de fleste tilfeller vil representere en brukersesjon, slik at antall par gjenspeiler totalt antall ganger en bruker kan bli autentisert før han må ha et nytt sett med autentiseringsdata generert. Messages 1 and 2 (equivalent to 3 and 4) must run many times to generate as large a set of challenges (RAND) and responses (SRES) as necessary. To achieve maximum security in subsequent authentication processes, challenges/responses should not be reused. This means that each generated pair will in most cases represent a user session, so that the number of pairs reflects the total number of times a user can be authenticated before he must have a new set of authentication data generated.

Det er verdt å nevne at i tilfeller hvor kryptering er nødvendig så kan en krypteringsnøkkel bli generert med A8-algoritmen ved å benytte RAND. It is worth mentioning that in cases where encryption is necessary, an encryption key can be generated with the A8 algorithm by using RAND.

Autentisering av brukeren Authentication of the user

Figur 3 illusterer prosessen for autentisering av en bruker. I forkant av de viste meldingene har brukeren prøvd å få tilgang til en beskytte ressurs gjennom en tjenesteklient (f.eks. gjennom en Web-browser eller annen klientapplikasjon). Figure 3 illustrates the process for authenticating a user. Prior to the displayed messages, the user has tried to access a protected resource through a service client (e.g. through a Web browser or other client application).

Meldingene i Figur 3 er som følger: The messages in Figure 3 are as follows:

1: authRequest() -Service Client forespør en autentisering fra Supplicant. 1: authRequest() - Service Client requests an authentication from Supplicant.

2: getlMSI() - Supplicant forespør IMSI fra brukerens SIM-kort . 2: getlMSI() - Supplicant request IMSI from the user's SIM card.

3: getlMSIResponse( IMSI)- SIM-kortet returnerer IMSI til Supplicant. 3: getlMSIResponse( IMSI)- The SIM card returns the IMSI to the Supplicant.

4: authRequest( IMSI) -Supplicant forespør autentisering fra Authenticator. 4: authRequest( IMSI) -Supplicant requests authentication from Authenticator.

5: getAuthData( IMSI) -Authenticator forespør autentiseringsdata for brukeren, spesifisert med IMSI, fra Authentication Data Storage. 5: getAuthData( IMSI) -Authenticator requests authentication data for the user, specified by IMSI, from Authentication Data Storage.

6: getAuthDataResponse( RAND, XRES) -Authentication Data Storage returnerer et par med autentiseringsdata (RAND, XRES) til Authenticator. 6: getAuthDataResponse( RAND, XRES) -Authentication Data Storage returns a pair of authentication data (RAND, XRES) to Authenticator.

7; authResponse ( RAND) -Authenticator returnerer en utfordring (RAND) til Supplicant. 7; authResponse ( RAND) -Authenticator returns a challenge (RAND) to Supplicant.

8: runA3( RAND) - Supplicant kjører A3-algoritmen på SIM-kortet med utfordringen som parameter (RAND). 8: runA3( RAND) - Supplicant runs the A3 algorithm on the SIM with the challenge as parameter (RAND).

9: runA3Response ( SRES) - SIM-kortet returnerer en signert respons generert av A3-algoritmen og basert på utfordringen som ble gitt i forrige metodekall. 9: runA3Response ( SRES) - The SIM card returns a signed response generated by the A3 algorithm and based on the challenge given in the previous method call.

10: authRequest ( SRES) -Supplicant sender en ny autentiseringsforespørsel til Authenticator med den signerte responsen som parameter (SRES). 10: authRequest ( SRES) - Supplicant sends a new authentication request to Authenticator with the signed response as parameter (SRES).

11: authResponse( SUCCESS)- Authenticator sammenligner den mottatte signerte responsen (SRES) med den forventede responsen mottatt 6), og hvis de er like returneres en suksessmelding som inkluderer en autentiseringstoken til Supplicant. Ved mislykket autentisering (SRES og XRES er ulike) blir det sendt en feilmelding istedet. 11: authResponse( SUCCESS)- Authenticator compares the signed response received (SRES) with the expected response received 6), and if they are equal a success message is returned which includes an authentication token to the Supplicant. If authentication fails (SRES and XRES are different), an error message is sent instead.

12: authResponse( SUCCESS) - Supplicant indikerer at autentiseringsprosessen var vellykket til Service Client og utleverer en autentiseringstoken som er brukt i påfølgende forsøk på å få tilgang til den beskyttede ressursen som i utgangspunktet krevde autentisering. 12: authResponse( SUCCESS) - Supplicant indicates that the authentication process was successful to the Service Client and issues an authentication token that is used in subsequent attempts to access the protected resource that initially required authentication.

Informasjonskilder med referanser Information sources with references

[1] Liberty Alliance, specifications available online: https://www.projectliberty.org/resources/specifications.php [1] Liberty Alliance, specifications available online: https://www.projectliberty.org/resources/specifications.php

[2] Kristol, D. & Montulli, L. (1997). "HTTP State Management Mechanism", IETF, February 1997, available online: http://www.ietf.org/rfc/rfc2109.txt?number=2109 [2] Kristol, D. & Montulli, L. (1997). "HTTP State Management Mechanism", IETF, February 1997, available online: http://www.ietf.org/rfc/rfc2109.txt?number=2109

[3] Fielding, R. et. al. (1997). "Hypertext Transfer Protocol - HTTP/1.1", IETF, January 1997, available online: http://www.ietf.org/rfc/rfc2068.txt?number=2068 [3] Fielding, R. et al. eel. (1997). "Hypertext Transfer Protocol - HTTP/1.1", IETF, January 1997, available online: http://www.ietf.org/rfc/rfc2068.txt?number=2068

[4] ETSI, Digital cellular telecommunications system (Phase 2+); Specification of the GSM-MILENAGE algorithms: An example algorithm set for the GSM Authentication and Key Generation Functions A3 and A8 (3GPP TS 55.205 version 6.1.0 Release 6), 2004 [4] ETSI, Digital cellular telecommunications system (Phase 2+); Specification of the GSM-MILENAGE algorithms: An example algorithm set for the GSM Authentication and Key Generation Functions A3 and A8 (3GPP TS 55.205 version 6.1.0 Release 6), 2004

Claims

1. A method of strong authentication for services and applications that the user uses through a personal computer, personal digital assistant or mobile phone, which uses a set of pre-generated GSM authentication data consisting of RAND and SRES; said method characterized by the following steps: generating a set of GSM authentication data (RAND, SRES) by means of a SIM card and storing said set of GSM authentication data in a network server; using said set of n pre-generated RAND and RES in n authentications of the user and then initiating the generation of a new set of RAND and RES for further authentication.

2. The method as in claim 1 characterized in that said generation and storage of said set of GSM authentication data pairs (RAND, SRES) consists of the following steps: request from the Authentication Data Management Client that the user's SIM card should run the A3 algorithm with a pre-generated RAND; returning response SRES to said Authentication Data Management Client from the SIM card, generated by the A3 algorithm using the received RAND; storing the received SRES together with the RAND by said Authentication Data Management Client; repeating the following steps N times by said Authentication Data Management Client to generate N pairs of authentication data (RAND, SRES); sending N pairs of authentication data (RAND, SRES) for the user identified by the IMSI to the Authentication Data Management Server by the Authentication Data Management Client; storage of N pairs of authentication data (RAND, SRES) in the Authentication Data Storage of the Authentication Data Management Server for later authentication of the user.

3. The method as in claim 1 characterized in that said authentication data is extended to also contain parameter Kc established by the A8 algorithm using RAND.

4. The method in claim 1 characterized in that said authentication of the user consists of the following steps: request from the Service Client to the Supplicant to carry out an authentication of the user; request from the said Supplicant to obtain the IMSI from the user's SIM card disclosure of the user's IMSI to the said Supplicant and request for authentication from the said Supplicant to the Authenticator; request authentication data (RAND, SRES) from said Authenticator to Authentication Data Storage for said IMSI; sending challenge RAND to said Supplicant by said Authenticator; sending of challenge RAND from said Supplicant and request for SRES from SIM by said Supplicant, return of SRES to said Authenticator by said Supplicant, comparison of received SRES from said Supplicant and that from said Authentication Data Storage; return of success message including an authentication token to said Supplicant by said Authenticator; delivery of said authentication token to the Service Client by said Supplicant.

5. Method as in claim 4 characterized in that said Authentication Data Storage reduces by one the number of available authentication data when delivering authentication data (RAND, SRES) to said Authenticator.

6. Method as in claim 5 characterized in that said Authentication Data Storage notifies that new generation of authentication data (RAND, SRES) is necessary when the number of available authentication data is lower than a predefined number.

7. Method as in claim 6 characterized in that said notification of generation of authentication data (RAND, SRES) consists of the following steps: notification to the Authentication Data Management Server about new generation of authentication data for the user with the IMSI of the Authentication Data Storage; notification to the Authentication Data Management Client about the new generation of authentication data for the user with the IMSI of said Authentication Data Management Server; notifying the user that a new generation of authentication data by the Authentication Data Management Client is required.

8. Method as in claim 1 characterized by the fact that before the generation and storage of authentication data is permitted, the user must be authenticated using one of the following alternative authentication methods: authentication based on username and one-time password for first-time end users; authentication based on pre-generated GSM authentication data for non-first time end users; authentication based on username and password, or based on pre-generated GSM authentication data for authorized personnel.

9. A system for generating, storing and using a set of GSM authentication data, namely RAND and SRES, in the authentication of the user for other services and applications, characterized in that the generation of GSM authentication data is carried out by the user's SIM card and that said system includes: an Authentication Data Management Client which is installed on the computer of the end user or a computer belonging to a service provider and is responsible for initiating the generation of sets of GSM authentication data consisting of RAND and RES; an Authentication Data Management Server located on a computer belonging to a service provider and responsible for collecting generated sets of RAND and RES; an Authentication Data Storage which is located on a computer belonging to the service provider and responsible for storing the generated set of RAND and RES; a Supplicant installed on the computer of the end user or a computer belonging to the service provider and responsible for communication with the SIM card; an Authenticator located on a computer belonging to a service provider and responsible for authenticating the user using pre-generated RAND and RES;

10. A system as claim 9 characterized in that said Authentication Data Management Client is equipped to perform the functions: send random number RAND and request SRES from the SIM card; collecting the set of n authentication data (RAND, SRES) for an IMSI; send said authentication data to said Authentication Data Management Server for storage and use it in the authentication; notify the user that new generation of authentication data is required; require authentication of the User from the Supplicant when the User requests the generation of authentication data;

11. System as in claim 9 characterized in that said Authentication Data Management Server is equipped to perform the functions: collect and store the set of n authentication data of a user with IMSI I Authentication Data Storage; establishing a secure channel with said Authentication Data Management Client; notify said Authentication Data Management Client that generation of new authentication data is required;

12. System as in claim 8 characterized in that said Authentication Data Storage is equipped to perform the functions: storage of the set of n authentication data for the users; retrieval and delivery of authentication data (RAND, SRES) for a user with IMSI to an Authenticator for user authentication; monitor and notify the Authentication Data Management Server when the number of available authentication data is lower than a predefined number;

13. System as in claim 9 characterized in that said Supplicant is equipped to perform the functions: send RAND and request SRES from the SIM card; send SRES to Authenticator for authentication; ask the user to enter a PIN code; return the authentication token received from the Authenticator to the Service Client after successful authentication.

14. System as in claim 8 characterized in that said Authenticator is equipped to perform the functions: retrieve authentication data (RAND, SRES) for an IMSI from said Authentication Data Storage; compare the SRES received from the Supplicant and that from the Authentication Data Storage; send an authentication token to the Supplicant if the two SRES are the same.