NO332725B1 - A method and device for strong multi-factor authentication - Google Patents

Abstract

A method and device for strong multi-factor authentication, based on tying keys for use in authenticating users to secure cryptographic elements. The invention uses a Key Guard (6), installed on a first Data Device (1), to encrypt and decrypt the authentication key, provided by a Supplicant (5) and previously exchanged with an Authenticator (16), along with an encryption key provided by Secure element (10), optionally based on user input. Secure element (10) may be, for example, a GSM SIM card, a UMTS USIM card, a Smart Card, or a software component installed on a second data device

Description

A METHOD AND DEVICE FOR STRONG MULTI-FACTOR AUTHENTICATION

Field of the invention

This invention concerns multi-factor authentication of users, i.e. using something the user knows in combination with physical devices (with or without keys) that the user possesses. More specifically, the invention enables strong authentication of users by using mobile devices (e.g. mobile phone) and USB devices, possibly together with user-defined passwords/passphrases.

Technical background

Strong and secure authentication of users is one of the most fundamental requirements in most services traded today, whether they are services used for physical access or virtual/logical services on the Internet.

Currently, strong authentication is also one of the weakest functions on the Internet (especially on the World-Wide-Web (WWW)). Most services rely on username/password authentication. One of the reasons for this is the cost of adopting safer and more advanced technology. Another reason is that introducing more secure solutions often results in lower usability. Service providers therefore have to accept a compromise between security and user-friendliness, while also taking account of costs.

As the number of annual phishing attacks, fraud and identity theft remain high [1], more and more service providers are being forced to adopt better solutions for end-user authentication. One solution is to use two-factor authentication solutions. These solutions typically require the user to be in possession of specific knowledge (a password/passphrase) in addition to a physical device (e.g. a Smart Card, one-time password calculator, mobile device, etc.).

This invention proposes a solution for strong multi-factor authentication of end users against services, using mobile devices and optionally USB devices, together with the user's knowledge, to ensure that strong authentication can take place.

Known solutions

A summary of existing, general solutions to the problem area is given first.

Username password

The most common authentication method used for services on the WWW today is based on username/password. There are many drawbacks to the username/password authentication method and they are vulnerable to many attacks.

Security depends on the user choosing long enough passwords with high enough entropy (randomness). That is, the password must look random, thus making it difficult for attackers to "guess" it, as well as impossible to find using dictionary attacks.

Incidentally, this is usually not the case, and users typically reuse the same password for many services and choose passwords that are easy to remember based on common words from the language, making them easy targets for dictionary attacks.

For a password to be secure enough today, it should be at least 8-9 characters long, chosen from as many character classes as possible (upper/lower case letters, numbers, special characters). Assuming the use of only 6 characters from upper and lower case, then the number of possibilities is 52^6. Assume further that it is possible to check 2.5 million permutations every second, a moderate number, then in the worst case it will only take 2 hours to find the password (assuming that all permutations must be checked).

In reality, the password will be found much faster. This of course depends on the type of service, whether it is network-based or not, etc.

In addition to searching for the password, it may in some cases be possible to obtain it by listening to network traffic, unless this is encrypted.

Smart Card with PKI

There are many Smart Card-based

authentication solutions. These are secure, but the security comes with an increased cost (Smart Card reader, Smart Card and infrastructure), in addition to reduced user-friendliness (e.g. the need to always carry a card and a card reader when you are out and about travel).

One-Time-Password (OTP) with SMS

Some service providers (e.g. in banking and public services) have adopted Short Messaging Service (SMS) as a platform for OTP. When the user must log in, the authentication server generates a password that is only valid for one authentication transaction. This password is sent to the user's pre-registered mobile phone number as an SMS, and the user must enter it as a password when logging in. Sometimes static passwords are used in combination with SMS OTP.

As the OTP is tied to the mobile subscription of the user, the solution is quite secure - a lot of resources are required to gain unauthorized access to SMS messages. As it is only possible to use an OTP once, "replay" attacks are difficult.

One of the disadvantages of the OTP SMS solution is the additional cost of sending an SMS for each authentication (it is common with a cost of at least NOK 0.30 for each transaction), so for many service providers this will be too expensive. It is also not very user-friendly for users to have to read the password from SMS and then enter it in the browser. In particular, it can be difficult for older people or people with disabilities such as e.g. poor vision. Another disadvantage is that the authentication requires that the SMS service is available (this is not necessarily the case in all countries), and that the response time of the mobile network is sufficiently low (so that the OTP does not arrive too late, e.g. after 1 hour).

OTP with mobile applications

Another OTP solution is to install applications on a user's mobile phone, and let it generate/offer the OTP. On the server side, there will be a corresponding application that can generate the same OTP. OTP can be exchanged between OTP server and mobile applications, or it can be generated separately based on time synchronization etc. Usually such solutions implement the HOTP protocol [2].

Verification with telephone connection setup

Another solution for using mobile phones for user authentication is to base it on the setup of the phone connection. With PhoneFactor [3], the user is called on a pre-registered phone number when she tries to log on to a service. The user must then answer the call and optionally enter a PIN code to continue logging in. The solution can also be used together with a static password. One of the limitations of this solution is that connection to and coverage of the mobile network is required to log on to a service. Another disadvantage is the complex infrastructure required, as well as the cost of establishing the authentication calls.

Some patents relevant to the problem area are now described.

Norwegian patent no. 326555 [4] provides a solution for strong authentication of users of Web-based services by using the user's mobile phone together with U/SIM to carry out the authentication. This is done by utilizing standard GSM/UMTS authentication mechanisms against a mobile operator, after which the operator confirms the successful authentication against an identity provider, which finally confirms the same to a tj sole provider.

The main limitation of the patent referred to above is that it is mainly based on cooperation with a mobile operator to carry out the authentication process.

Norwegian patent no. 326557 [5] provides a similar solution to the solution referred to above, except that the service access goes through the mobile device instead of a personal computer. This solution nevertheless has the same limitation as the solution above as it is based on a collaboration with mobile operators to carry out the authentication process.

United States Patent no. 7590847 [6] proposes a solution for mobile authentication of a user against a network using temporary and/or one-time passwords (OTP). Many authentication solutions based on OTP exist today, many of which use SMS for distribution of OTP. The main limitation of these based on SMS is the cost of using SMS in each authentication transaction.

Norwegian Patent no. 324315 [7] proposes another solution based on mobile applications for establishing OTP. The main limitations of such solutions are the requirement for a specialized application on the mobile devices to be able to establish the OTP, in addition to the usual requirement for manual transmission of the OTP from the mobile device to the computer device used to complete the authentication against the requested service.

The invention in this description offers a solution that does not have any of the above-mentioned limitations.

The invention does not require any collaboration with mobile operators to implement strong authentication, although it reuses the strong security features included in standard mobile technology today (mobile phone and U/SIM).

The invention does not use SMS to carry out authentication, and there is thus no additional cost for the user. In fact, the solution does not depend on a connection to the mobile network at all to carry out the authentication procedure.

The invention does not require the installation of an application on the user's mobile phone, although it offers an alternative solution that uses this in addition.

Summary of the invention

The main objective of the invention is to allow the use of mobile technology, available and used by everyone, for authentication of the user against arbitrary Internet services, without the requirement of cooperation with mobile operators. This can be done by linking/tying a second secret key to a secure element, where the secure element can be the U/SIM in a mobile phone or a USB dongle, or it can be a Smart Card or a mobile application installed on the mobile the device (mobile phone).

The challenge is thus to securely link an authentication to the U/SIM (or another secure element). The following example is based on a situation where U/SIM is used to authenticate the user.

In existing U/SIM-based authentication solutions (i.e. in mobile GSM and UMTS networks), the authentication is based on a secret key Kirsom only exists in two places, specifically on the user's U/SIM and in the mobile network operator's Authentication Center (AuC) . The authentication is normally based on establishing trust that the user is in possession of K± which belongs to the specified user identity. A user is identified by an International Mobile Subscriber Identity (IMSI) in mobile networks.

In this invention, the possibility of verifying the existence of a correct K± by connecting to the AuC is not present because there is no cooperation with a mobile network operator, thus access to the K± on the network side is not possible.

Instead, the invention is based on transitive trust in secret keys. A new, shared key Ka is established between the authentication server (Authenticator) and the client side (Supplicant) using e.g. Diffie-Hellman [8].

The establishment of these secret keys must be satisfactorily secure, and OTP SMS can e.g. be used in the initial phase of this establishment (as SMS is also tied to a mobile subscription).

The exact procedure for establishing Ka is not within the scope of this invention, and the invention is not limited by the exact process for establishing this key; the establishment can even be the physical exchange of a device (eg a USB Flash drive) containing the key, or a manual exchange (although this is inconvenient) by voice over a secure telephone line. Assuming that the shared key Ka has been established between Authenticator and Supplicant, the next step is to link/bind this key to the user's U/SIM, so that the key cannot be used unless the user is in possession of the specific U/SIM. If the key cannot be used, authentication of the user against her/his account cannot be carried out.

Ka can be tied to U/SIM in the following way:

On U/SIM:

On the user's computer:

By (optionally) using user defined input I (eg a passphrase) the U/SIM can generate a key Kcog a signed response SRES using the standardized A38 (or the equivalent UMTS functions with conversion functions) algorithm. H can be a hash function such as SHA-1 [16] or another hash function, which can be used to generate a fixed-length input to A38 based on an input I of arbitrary length.

The algorithm (eg A38) also takes the secret key K± as input, and thus the result from A38 is strongly linked to this secret key even though the secret key itself is not exposed.

A combination of Kcog SRES, Kc., is used to protect (encrypt) the user's Ka to EKc. (Ka) . Thus, access to Ka is only possible if access to the user's U/SIM is granted, as the same key is required for decryption as was used for encryption.

EXC'(Ka) can be stored on the user's mobile phone, on a USB memory device, on the user's computer (e.g. in the Windows registry or on a hard drive), etc.

It is possible to add a third factor to the authentication by requiring the presence of an additional physical device. An example of such a device would be a USB Bluetooth dongle, which has a globally unique network address. This can be used together with the user's input and given as input I to A38 (this input is usually referred to as RAND in GSM and UMTS terminology), to further strengthen Kc. which is used to protect Ka.

It is thus possible to offer a strong three-factor authentication solution consisting of a user's mobile phone with U/SIM, a USB Bluetooth dongle (or other physical device with e.g. a USB interface) and a user-defined password/passphrase.

The scope of the invention appears from the attached patent claims.

Brief description of the drawings

The invention will now be described in detail with reference to the attached drawings, where: Figure 1 shows a general architecture of the invention. Figure 2 shows a more specific architecture of the invention where the authentication key Ka is tied to the user's U/SIM which is located in a mobile phone. Figure 3 shows another specific architecture of the invention where the authentication key Ka is tied to the user's Smart Phone using a mobile application. Figure 4 shows another specific architecture of the invention where the authentication key Ka is tied to an application on a Smart Card which is inserted into a Smart Card reader. Figure 5 shows a UML message diagram that illustrates the process of establishing a key bound to a user's U/SIM located in a mobile phone. Figure 6 shows a UML message diagram illustrating the process of authenticating a user using a key that is bound to a user's U/SIM located in a mobile phone.

Detailed description

The invention consists of the following main parts:

• The method of binding an authentication key to a user's secure element for use in strong authentication. • The method of authenticating a use with an authentication key bound to a user's secure element. • The device that enables the binding of an authentication key to a user's secure element for use in strong authentication.

The functionality of the components

Computing device # 1 ( 1)

This component represents a personal computer (PC), laptop, Personal Digital Assistant (PDA) or similar computing device.

Computing device # 2 ( 2)

This component represents either a mobile device (e.g. a mobile phone or a Smart Phone) that may contain a U/SIM card or an application, or another Card Access Device (CAD), e.g. a Smart Card reader, which can contain a Smart Card (this can also be

Without/SIM).

Identity provider ( 3)

This component represents a network entity responsible for managing user identities for a service provider. It may or may not be co-located with the service provider, and it must have the ability to verify a user's claimed identity against a tj sole provider.

Service provider ( 4)

This component represents a service provider.

Applicant ( 5)

This component represents a software component that implements functionality to carry out authentication of a user against an Authenticator (16).

Supplicant (5) exposes the interface Ie.

Interface Ie

Service Client (8) uses this interface to initiate authentication, and Supplicant (5) provides Service Client (8) with the result of an authentication over this interface (ie authentication token or error message).

Key cases ( 6)

This component represents a software component that implements functionality to keep an authentication key secret (e.g., using encryption), but can temporarily expose such an authentication key through an API given that the necessary resources are available (e.g., passphrase from user, PIN code for U/SIM access, access to the U/SIM A38 algorithm, access to the hardware address of another device, etc.).

Key protector (6) exposes the interface Ia.

Interface I«

Supplicant (5) uses this interface to access the authentication key, in addition to handing over the authentication key after the initial key establishment phase. The interface supports at least the following methods: byte[] getAuthenticationKey( PIN, PASSPHRASE) - Using this method, the Supplicant (5) can retrieve the authentication key of the user and proceed with authentication against the Authenticator (16).

boolean setAuthenticationKey( PIN, PASSPHRASE) - Using this method, Supplicant (5) can set

the authentication key for the user after the initial key establishment phase, so that service access at a later time can be correctly authenticated.

Persistent storage ( 7)

This component represents any type of non-volatile storage (ie hard drive, Flash based memory etc) and can expose its storage space through standard file system (ie NTFS, FAT32, Ext2/3 etc).

Service Client ( 8)

This component represents the client side of a service offered by a service provider; it can e.g. be a Web browser that displays a website on the Web.

Secure Item ( 10)

This component can represent both a physical entity and a logical part (software component/application) of a Secure Element. In Figure 2, this is a U/SIM inserted into a mobile phone, while in Figure 3 this is a mobile application running on a mobile device. In Figure 4, it is realized by functionality on a Smart Card.

Secure element (10) exposes interface Ic, optionally and as required in combination with Ic., depending on the type of architecture and type of Secure element.

Interface Ic& Ic.

These interfaces may, but are not limited to, support methods and functionality according to [9] [10] [11]

[12] [13] [14] .

Service Server ( 15)

This component represents server-side components of a service offered by a service provider, which require authentication of users. It could, for example, be a Web server that "hosts" a Web application.

Service server (15) exposes interface If.

Interface If

This interface exposes methods according to the application at Service Server (15) and the platform on which it runs. It can e.g. be based on HTTP with specific methods above the HTTP layer, or it can be based on XML Web Services, REST etc.

Authenticator ( 16)

This component represents functionality required to authenticate a user. It can often be co-located with Identity Provider (3). It often also has a connection to other components (e.g. user databases) necessary to authenticate the users, depending on which authentication mechanism is used.

Authenticator (16) exposes the interface Id to Supplicant (5).

Interface Id

This interface supports at least the following methods: AuthResponse authRequest( CREDENTIALS) - Using this method, Supplicant (5) can issue an arbitrary number of authentication requests against Authenticator (16) , thus supporting different authentication methods. An AuthResponse is returned for each request, either containing the final result of the authentication, or specifying further steps to continue with the authentication. This method can be used any number of times in sequence, according to the actual authentication method used. For example, with username/password authentication, an AuthRequest may be enough, while with challenge/response-based methods, it will be necessary to call the method many times.

Persistent storage ( 17)

This component represents any non-volatile storage (eg hard disk, Flash-based memory etc.) and can expose its storage space through standard file system (eg NTFS, FAT32, EXT2/EXT3 etc). The storage space can also be exposed through a database management system (DBMS), an LDAP server, etc. Persistent storage (17) is i.a. used for storing all users' Ka.

Figure 2 shows a more specific architecture. The following changes have been made: • Computer #2 (2) has been replaced with a Mobile Phone (2)

• Mobile equipment/ME (9) has been added.

• Secure element (10) has been replaced by U/SIM (10) .

• USB device (11) has been added.

• Persistent storage device (12) has been added.

The new components introduced in Figure 2 are now described.

Without SIM (10)

This represents a standard GSM/UMTS U/SIM with functionality and interface according to ETSI/3GPP specifications referred to earlier.

USB device ( 11)

This component represents a USB device that can be connected to a computer device using e.g. a USB connection. This can e.g. be a USB Bluetooth adapter, USB WiFi adapter, USB Flash storage device etc. The importance of USB device (11) is that it contains some form of identifier/data that can be incorporated into the authentication process (e.g. by combining those with the user-specified passphrase). USB devices other than those listed here may, but must not, contain such an identifier.

Persistent Storage Device( 12)

This component represents any type of non-volatile storage, implemented on a device that can be connected to a computing device using e.g. a USB connection. This can e.g. be a USB Flash storage device, and it can e.g. be used to store EKC' (Ka) .

Mobile phone( 2)

This represents a typical mobile phone, e.g. a GSM or UMTS mobile phone, which uses U/SIM for security functions related to mobile networks.

Mobile Equipment ( ME) ( 9)

This component represents most of the functionality in a mobile phone, apart from U/SIM-specific functionality. The term Mobile Equipment/ME is in common use in the standardization process for mobile technology (by ETSI and 3GPP). ME (9) can support dynamic applications developed in programming languages such as JavaME, C++, Objective C etc.

ME (9) exposes the interface Ic.

Interface Ic

Key protector (6) uses this interface to communicate with ME (9), e.g. with an application running in ME (9). Key protector (6) can also use the interface to communicate with U/SIM through ME (9)

(using Bluetooth SAP [15]). The interface may also support other application-specific methods.

Figure 3 shows another specific architecture. The following changes have been made:

• Computer device #2 (2) has been replaced by a SmartPhone (2) . • Secure element (10) has been replaced by an Application (10).

The new components introduced in Figure 3 are now described.

Smartphones ( 2)

This is a modern mobile phone that can run dynamic applications developed in e.g. Java, C++, Objective C etc.

Application ( 10)

This represents a dynamic application, which is at least capable of performing mathematical operations based on the requirements of a key generation algorithm.

Figure 4 shows another specific architecture. The following changes have been made: • Computer device #2 (2) has been replaced with a Smart Card reader (2). • Secure element (10) has been replaced with a Smart Card (10).

The new components introduced in Figure 4 are now described.

Smart Card reader ( 2)

This component represents a standard Smart Card reader; it can have either the original Smart Card form factor, the U/SIM form factor or any other specialized form factor (eg micro-SIM).

The Smart Card reader exposes the interface Icsom e.g. can support functionality according to the PC/SC standard.

Smart Card ( 10)

This card conforms to Smart Card standards and is capable of running dynamic key generation applications.

Message sequence diagram ammer

Figure 5 shows a UML message sequence diagram illustrating the process of initializing an authentication key bound to a user's U/SIM.

The messages in Figure 5 are as follows:

1: initialiseKey( IMSI, MSISDN) - This method is used to start an initialization procedure for key exchange between Supplicant (5) and Authenticator (16). In order for the key exchange to be secure (i.e. that it is beyond any doubt that the user is who they claim to be), it is critical that the initialization procedure is also secure. The procedure in Figure 5 uses One-Time-Password (OTP) over SMS to start the initialization process. A password is sent via SMS to the MSISDN registered to the relevant user. The rest of the invention does not depend on this specific procedure - any initialization of sufficient strength can be used. Another example is to perform the initialization procedure and key development in the initial user account registration. 1. 1: sendSMS( RAND) - This method is used against an SMS gateway, to send an SMS to the user's mobile phone. 1. 1. 1: SMS( RAND) - SMS has been sent to the user's mobile phone. 2: transfer (RAND) - OTP that is included in the SMS is transferred to the Applicant (5) either manually or automatically through e.g. a Bluetooth connection (this requires an application installed on the user's mobile phone). 2. 1: initialiseKey ( RAND) - This method initializes the key exchange procedure against Authenticator (16). It should be an asymmetric key exchange, ie a shared key is established without compromising information that can be used by unauthorized persons to establish a copy of the secret key. An example of such a protocol is the Diffie-Hellman Key Exchange [8]. 3: setAuthenticationKey( Ka) - After the key exchange is completed between the Supplicant (5) and the Authenticator (16), the Supplicant (5) transfers the key to the Key Protector (6) for safe storage. 3. 1: runCHV( PIN) - Key protector (6) unlocks the user's U/SIM using the PIN code. 3. 1. 1: runCHVResponse() - U/SIM returns success if the PIN code was correct, and access to other functionality in U/SIM is enabled. 4: runA38( PASSPHRASE) - Key Protector (6) runs the A38 algorithm on U/SIM with user defined passphrase as input. 4. 1: runA38Response ( SRES, Kc) - U/SIM returns the result of the A38 algorithm, i.e. Signed Response (SRES) and encryption key Kc. 4. 1. 1: encryptKey ( Ka, SRES, Kc) - Key protector (6) encrypts the authentication key Ka using a combination of SRES and Kc. 4. 1. 2: storeKey ( E ( Ka)) - Key Protector (6) stores the encrypted authentication key in Persistent Storage (7).

Figure 6 shows a UML message sequence diagram that illustrates the process of authenticating a user with a key tied to that person's U/SIM card.

The messages in Figure 6 are as follows:

1: requestService() - A Service Client (8) requests a service from a Service Server (15) at a

Service provider (4).

1. 1: authenticate () - Service server (15) asks Service client (8) to authenticate itself before access to the service can be granted. 2: authenticate () - Service client (8) requests authentication from Supplicant (5). 2. 1: runCHV( PIN) - Applicant (5) unlocks U/SIM using of the user's PIN code. 2. 1. 1: runCHVResponse() - U/SIM is unlocked and access to necessary functionality is granted if the PIN code is correct. 2. 1. 1. 1: getlMSIf) - Supplicant (5) requests the mobile identity (IMSI) of the user from U/SIM (10). 2. 1. 1. 1. 1: getlMSIResponse () - Supplicant (5) receives the user's IMSI from the U/SIM (10). 3: authRequest( IMSI) - Supplicant (5) sends an authentication request against Authenticator (16) by indicating the user's identity (IMSI). 3. 1: authResponse( CHALLENGE) - Authenticator (16) issues a challenge to Supplicant (5). 4: getAuthenticationKey( PASSPHRASE) - Supplicant (5) requests authentication key from Key Protector (6) and provides the user's passphrase as input. This can be specified through a user interface (Ul). 4. 1: runA38( PASSPHRASE) - Key Protector (6) runs the A38 algorithm on U/SIM (10) with the user-defined passphrase as input. 4. 1. 1: runA38Response ( SRES, Kc) - Supplicant (6) receives SRES and Kc from U/SIM (10) . 4. 1. 1. 1: decryptKey ( E ( Ka) , SRES, Kc) - Key protector (6) decrypts the authentication key Ka using a combination of SRES and Kc. 4. 1. 1. 2: getAuthenticationKeyResponse ( Ka) - Key Protector (6) returns the authentication key Ka to Supplicant (5) .

5: generateResponse( Ka, CHALLENGE) - Supplicant (5) generates an authentication response based on the challenge (challenge) received from Authenticator (16) and the authentication key Ka.

6: authRequest( RESPONSE) - Supplicant (5) issues a new authentication request against Authenticator (16) and includes the authentication response.

6. 1: verifyResponsef) - Authenticator (16) verifies that the authentication response corresponds to the expected value (calculated internally with the same

the authentication key and the challenge).

6. 2: authResponse( TOKEN) - Authenticator (16) successfully responds to Supplicant (5) and includes an authentication token in the response. 6. 2. 1: authenticateResponse. see ( TOKEN) - Supplicant (5) successfully responds to Service Client (8) and includes the authentication token in the response. 6. 2. 1. 1: requestService( TOKEN) - Service client (8) issues a new request for the service and includes the authentication token in the request. 6. 2. 1. 1. 1: verifyToken( TOKEN) - Service server (15) verifies the received authentication token. The verification of the authentication token can be done in several ways, depending on the relevant platform on which the service runs. If Authenticator (16) and Service Server (15) are co-located, then the authentication token can be verified locally;

the authentication token can also be verified externally against a DBMS/LDAP server; the authentication token can be of such a nature that it is verifiable in itself (e.g. a SAML 2.0 token with a digital signature can be verified with the issuer's, i.e. Authenticator (16) or

Identity Provider (3) public key).

Information sources with references

[1] Anti Phishing Working Group, "Phishing Activity Trends Report - lst Quarter 2010",

http://www.antiphishing.org/reports/apwg_report_Ql_2010.pdf

[2] IETF, "RFC4226: HOTP: An HMAC-Based One-Time Password Algorithm", 12/2005,

http://datatracker.ietf.org/doc/rfc422 6/

[3] PhoneFactor, http://www.phonefactor.com

[4] Ubisafe AS, "Procedure and system for joint strong authentication of web services", Norwegian patent no. 326555,

https://dbsearch2.patentsyret.no/Patent/DetailNewWindow.as px?idappl=20061637&culture=en-GB

[5] Ubisafe AS, "Procedure and system for joint strong authentication of web services", Norwegian patent no. 326557,

https://dbsearch2.patentsyret.no/Patent/DetailNewWindow.as px?idappl=20061885&culture=en-GB

[6] Alcatel, "Mobile authentication for network access", United States Patent no. 7590847,

http://www.freepatentsonline.com/7590847.html

[7] enCap, "Method and system for secure user authentication at a personal computer terminal", Norwegian Patent no. 324315, https://dbsearch2.patentsyret.no/Patent/DetailNewWindow.as px?idappl=2005454 9&culture=en-GB

[8] IETF, "RFC2631: Diffie-Hellman Key Agreement Method", http://datatracker.ietf.org/doc/rfc2 631/

[9] ETSI/3GPP TS 100.922 V8.0.0, "Digital cellular telecommunications system (Phase 2+) (GSM); Subscriber

Identity Modules (SIMs); Functional characteristics (GSM 02.17 version 8.0.0 Release 1999)"

[10] ETSI/3GPP TS 131.102 V8.7.0, "Universal Mobile Telecommunications System (UMTS); LTE; Characteristics of the Universal Subscriber Identity Module (USIM) application (3GPP TS 31.102 version 8.7.0 Release 8)"

[11] ETSI/3GPP TS 100.929, "Digital cellular telecommunications system (Phase 2+); Security-related network functions (3GPP TS 03.20 version 8.6.0 Release 1999)"

[12] ETSI/3GPP TS 131.900, "Universal Mobile Telecommunications System (UMTS); LTE; SIM/USIM internal and external interworking aspects (3GPP TR 31.900 version 8.0.0 Release 8)"

[13] ETSI/3GPP TS 133.102, "Universal Mobile Telecommunications System (UMTS); LTE; 3G security; Security architecture (3GPP TS 33.102 version 8.4.0 Release 8) "

[14] ETSI/3PP, TS 11.11, "Digital cellular

telecommunications system (Phase 2) (GSM); Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface (GSM 11.11 version 4.21.1)"

[15] PaloWireless, "SIM Access Profile",

http://www.palowireless.com/infotooth/tutorial/nl2_sap.asp

[16] IETF, “RFC3174: US Secure Hash Algorithm 1 (SHA1), http://datatracker.ietf.org/doc/rfc317 4/

Claims (20)

1. A method for binding a key Katil a Secure element (10) for use in strong authentication between a software component Supplicant (5) installed on a first Computer Device (1) and an Authenticator (16) located in a network, characterized in that said binding includes the following steps: Said Supplicant (5) and said Authenticator (16) exchange shared key Ka in a secure manner; Said Applicant (5) transfers said key Ka to a software component Key Protector (6); Said Key Protector (6) requests data to construct a key from a Secure Element (10); Said Secure element (10) generates data K using an algorithm A and optional input data I; Said Secure Element (10) returns said generated data K to said Key Protector (6); Said Key Protector (6) uses said data K to construct a key Kc.; Said Key Protector (6) encrypts said key Ka by using said key Kc. and encryption algorithm E to<E>kc (<K>a) ; Said Key Protector (6) stores said encrypted key EKC'(Ka) on Persistent storage (7). 2. A method as in claim 1, characterized in that said Secure element (10) is a GSM SIM card and that said algorithm A is the GSM A38 algorithm, said generated data K consists of SRES and Kc. 3. A method as in claim 1, characterized in that said Secure element (10) is a UMTS USIM card and that said algorithm A is UMTS f2K, f3K and f 4K with conversion functions c2 and c3, said generated data K consists of SRES and Kc . 4. A method as in claim 1, characterized in that said Secure element (10) is a Smart Card and that said algorithm A is a key generation algorithm implemented on said Smart Card. 5. A method as in claim 1, characterized in that said Secure Element (10) is a software component installed on a second Data Device (2) and that said algorithm A is a key generation algorithm implemented by said software component. 6. A method as in claims 1 to 5, characterized in that said input data I is partially or fully located on an external device that communicates with a first Data Device (1) or a second Data Device (2). 7. A method as in claims 1 to 5, characterized in that said input data I is specified through a user interface. 8. A method for a Supplicant (5) to establish a key for authentication against an Authenticator (16), characterized in that said establishment includes the following steps: Said Supplicant (5) requests a key Ka from a software component Key Protector (6); Said Key Protector (6) requests data to construct a key from a Secure Element (10); Said Secure element (10) generates data K using algorithm A and optional input data I; Said Secure Element (10) returns said generated data K to Key Protector (6); Said Key Protector (6) uses said data K and algorithm B to construct a key Kc.; Said Key Protector (6) decrypts the encrypted key EKC'(Ka) using said key Kcog decryption algorithm D until Ka = DKc. (EKc. (Ka) ) ; Said Key Protector (6) returns said key Ka to said Applicant (5); Said Applicant (5) performs authentication against said Authenticator (16) based on said key Ka. 9. A method as in claim 8, characterized in that said Secure element (10) is a GSM SIM card and that said algorithm A is the GSM A38 algorithm, said generated data K consists of SRES and Kc. 10. A method as in claim 8, characterized in that said Secure element (10) is a UMTS USIM card and that said algorithm A is UMTS f2K, f3K and f4K with conversion functions c2 and c3, said generated data K consists of SRES and Kc. 11. A method as in claim 8, characterized in that said Secure element (10) is a Smart Card and that said algorithm A is a key generation algorithm implemented on said Smart Card. 12. A method as in claim 8, characterized in that said Secure Element (10) is a software component installed on a second Data Device (2) and that said algorithm A is a key generation algorithm implemented with said software component. 13. A method as in claims 8 to 12, characterized in that said input data I is partially or fully located on an external device that communicates with a first Data Device (1) or a second Data Device (2). 14. A method as in claims 8 to 12, characterized in that said input data I is specified by the user through a user interface. 15. A device which enables the binding of key Ka to a Secure element (10) for use in strong authentication, characterized in that said device contains: A Secure element (10) which is equipped with an algorithm A to generate data K; Said algorithm A is adapted to optionally use input data I in generating said data K; Said Safe element (10) is equipped with an interface ic; A software component Key Protector (6) located on a Data Device (1), said Key Protector (6) is adapted to communicate with a Secure Element (10) over said interface Ic; Said Key Protector (6) is equipped with an interface ia; A software component (5) is adapted to supply and request a key Ka over said interface Ia; Said Key Protector (6) is equipped with an algorithm B to generate a key Kc. based on said data K for use in encryption and decryption of said key Ka; Said Key Protector (6) is equipped with an algorithm E to encrypt said key Ka using said key Kc. to encrypted key EKC' (Ka) ; Said Key Protector (6) is equipped with an algorithm D to decrypt said encrypted key EKc. (Ka) using said key Kc. to Ka = DKC' (EKC' (Ka) ) ; Said Key Protector (6) is adapted to enable the storage of said encrypted key EKc. (Ka) on Persistent storage (7). 16. A device as in claim 15, characterized in that said Secure element (10) is a GSM SIM card and that said algorithm A is the GSM A38 algorithm, said generated data K consists of SRES and Kc. 17. A device which in claim 15, characterized in that said Secure element (10) is a UMTS USIM card and that said algorithm A is UMTS f2K, f3K and f4K with the conversion functions c2 and c3, said generated data K consists of SRES and Kc. 18. A device as in claim 15, characterized in that said Secure Element (10) is a Smart Card and that said algorithm A is a key generation algorithm implemented on said Smart Card. 19. A device as in claim 15, characterized in that said Secure Element (10) is a software component installed on a second Data Device (2) and that said algorithm A is a key generation algorithm implemented by said software component. 20. A device as in claims 15 to 19, characterized in that an external unit is equipped to communicate with said first Data Device (1) or said second Data Device (2); Said external device is adapted to deliver said input data I.