Abstract:
The present invention provides a secure, efficient, simple and operator-independent method for generating an electronic signature, for execution by a processing unit in a mobile terminal. The method comprises the steps of receiving an electronic message, fetching a basic key from a memory area, inputting a credential from a user, generating a dynamic key based on the basic key and the credential, and generating an electronic signature for the message using the dynamic key. The invention further comprises a corresponding method for verifying the electronic signature, for execution by a verification server.

Description:
TECHNICAL FIELD 
       [0001]    The present invention relates in general to data security and mobile data communication. 
         [0002]    More specifically, the invention relates to a method, a computer program and a mobile terminal for providing an electronic signature, for execution by a processing unit in a mobile terminal. The invention further comprises a method, a computer program and a verification server for verifying the electronic signature. 
       BACKGROUND OF THE INVENTION 
       [0003]    A result of the general advances in digital communications technology is that more and more types of communication and transactions are taking place digitally. The spread of mobile communication, in particular, has resulted in mobile terminals or handsets such as mobile telephones or PDAs being used for various forms of electronic commerce and mobile payment services. 
         [0004]    When implementing such services, security is an essential factor. It is particularly important to provide secure, efficient and simple authentication of the identity of a mobile terminal user. 
         [0005]    The simplest authentication solutions, based on user name and password, have a number of drawbacks. These include a conflict between the need for a lengthy and distinctive password for the sake of security, and the desire for a short and easily memorised password for the sake of user friendliness. Passwords sent over open networks will also be a cause of reduced security. 
         [0006]    Today, mobile operators have a great degree of control over the infrastructure of the mobile channel, and thus also the services that are offered via the mobile channel. Accordingly, authentication solutions based on the SIM (Subscriber Identity Module) in the mobile terminal have previously been described. 
         [0007]    A generally recognised, prior art technique is known as strong authentication. This is based on the electronic identity being linked to an encryption key that is stored so as to be secure and inaccessible to unauthorised persons, specifically in a smartcard. All operations that employ the key can be executed internally in a processor on the smartcard. 
         [0008]    There are previously known such solutions for strong authentication in which the SIM card in the mobile terminal is also a smartcard containing an encryption key. However, this means that the mobile operator, who is the actual owner of the card, has full control over the key and the authentication operations in which the key is used, since the key storage device in the SIM card is not accessible to an independent service provider. A solution of this kind is therefore not operator-independent. 
         [0009]    The ordinary memory in the mobile terminal is accessible to an independent service provider, and therefore in principle permits an operator-independent authentication solution. However, this memory is not suitable for storing keys because the contents of the memory are readily accessible also to unauthorised persons. 
         [0010]    U.S. Pat. No. 6,529,886 teaches an operator-independent authentication process where importance is given to maintaining anonymity towards a third party. 
         [0011]    The document refers to (1) the use of a counter on the client side, (2) the derivation of client-specific keys from a master key, and (3) a single-directional authentication protocol from client to server. 
         [0012]    The present invention differs from this document, inter alia, by the generation of dynamic keys using a master key, a counter and a user credential such as a password or a pin code, thereby eliminating the need to store the dynamic key in the memory of the mobile telephone. 
         [0013]    US 2002/0099940 teaches an authentication solution where a user establishes, via the web, a connection with an authentication server that collects authentication information in the form of a password. A platform-independent code in the form of a Java applet is then downloaded to a mobile client. This code identifies itself to the server, and a secure connection is established. 
         [0014]    The document deals primarily with the establishment of a secure connection, and it cannot be seen to relate to the signing of messages. The document cannot be seen to describe key generation like that used in the present invention. 
       SUMMARY OF THE INVENTION 
       [0015]    The present invention provides a method for generating an electronic signature, for execution by a processing unit in a mobile terminal. The invention further comprises a method for verifying the electronic signature. 
         [0016]    A particular object of the invention is to provide a method which specifically involves operator independence. 
         [0017]    A further object of the invention is to provide methods of the aforementioned type, which involve a sufficient degree of security against malicious attack or attempted fraud. 
         [0018]    In accordance with the present invention, there is provided a method for providing an electronic signature as disclosed in claim  1  below, a corresponding computer program as disclosed in claim  10  below, and a corresponding mobile terminal as disclosed in claim  14  below. 
         [0019]    Further in accordance with the present invention, there is provided a method for verifying a signature as disclosed in claim  11  below, a corresponding computer program as disclosed in claim  13  below, and a corresponding verification server as disclosed in claim  15  below. 
         [0020]    Advantageous embodiments are set forth in the dependent claims. 
         [0021]    According to the invention, it is assured that the dynamic key is only used transiently for signature purposes. The dynamic key is therefore not stored. Furthermore, it is assured that the user&#39;s credential, for example, a password, is not stored in the mobile terminal or transmitted over the line. These features of the invention contribute to increased security. 
         [0022]    A relevant utilisation of the invention is to use the terminal application as software-based user identification or authentication, for example, in services such as mobile ordering and/or payment. This results in authentication that does not require access to keys or other data stored in the SIM card, or to other functionality provided by the SIM card. These features of the invention result in operator independence. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0023]    The appended drawings illustrate an advantageous embodiment of the invention. Together with the description, the drawings serve to explain the principles of the invention. 
           [0024]      FIG. 1  is a schematic block diagram illustrating a system in which a mobile terminal and a verification server are adapted to operate in accordance with methods according to the invention. 
           [0025]      FIG. 2  is a general, schematic flow chart illustrating a sequence of steps from the ordering/registration of a terminal application to the use of the terminal application. 
           [0026]      FIG. 3  is a schematic block diagram illustrating a mobile terminal adapted to operate in accordance with the invention. 
           [0027]      FIG. 4  is a schematic flow chart illustrating a method for execution in a mobile terminal according to the invention; and 
           [0028]      FIG. 5  is a schematic process diagram illustrating the generation and use of a terminal application; and 
           [0029]      FIG. 6  is a schematic process diagram illustrating a verification process. 
           [0030]      FIG. 7  is a schematic block diagram for a further aspect of the invention. 
       
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
       [0031]    In what follows the invention will be described in more detail by way of example with reference to the drawings. Where possible, the same reference numerals are used for identical elements in the different drawings. 
         [0032]      FIG. 1  is a schematic block diagram illustrating a system where a mobile terminal operates in accordance with the method according to the invention. 
         [0033]    The system in  FIG. 1  comprises a mobile network  110 , such as a GSM network, with a plurality of base stations, of which one is illustrated at  111 . The base station  111  communicates with a user&#39;s mobile terminal  300 , such as a mobile telephone. The system further comprises a client computer  122  provided with a web client. The client computer  122  and a web server  124  are both operatively connected to a computer network  120 , preferably the Internet. 
         [0034]    A gateway  116  is provided for operatively interconnecting the mobile network  110  and the computer network  120 . 
         [0035]    A server  112  at the service provider is operatively connected to the mobile network  110 . The server  112  at the service provider is also operatively connected to the verification server  130 , preferably via a closed communications link, for example by means of a virtual private network  114 . As those skilled in the art will appreciate, a virtual private network  114  of this kind can advantageously be implemented as a subset of the Internet, and thus a part of the computer network  120 . For the sake of simplicity, the virtual private network in  FIG. 1  is illustrated as a separate connection. 
         [0036]    The verification server  130  is operatively connected to the web server  124 . The verification server  130  and the web server  124  may be located in the same geographic area, and in that case the connection  132  between them can be accomplished using a local network (LAN). Alternatively, the connection  132  can be accomplished using a virtual private network. As those skilled in the art will appreciate, a virtual private network  132  of this kind can advantageously be implemented as a subset of the Internet, and thus a part of the computer network  120 . For the sake of simplicity, the connection  132  in  FIG. 1  is illustrated as a separate connection. 
         [0037]    The client computer  122  is provided with a web browser. Thus, a user can by means of the client  122  exchange information with other computers linked to the network  120 , such as the web server  124 . 
         [0038]    By using the web browser in the client computer  122 , the user can carry out an ordering and registration process that is executed by the web server  124 . This process permits the user to register himself and order a downloadable, specially adapted terminal application for mobile signing/authentication. 
         [0039]    The communication between the client computer  122  and the web server  124  may advantageously take place in an encrypted manner, for example, by using the security protocol SSL (Secure Sockets Layer). 
         [0040]    The web server  124  is therefore adapted to generate a specially adapted terminal application, comprising an executable program code which can be executed by the mobile terminal  300 . A J2ME application (midlet suite) containing the necessary code and other data is especially preferred. This ensures portability. 
         [0041]    By means of the mobile network  110  and the service provider  112 , it is possible to establish a communication channel between the mobile terminal  300  and the verification server  130 . To hinder unauthorised viewing of protocols and unauthorised access to messages and/or signatures, unauthorised persons should be prevented from gaining access to this channel. This can be handled by the built-in security/encryption functions in the mobile network  110  and in the preferred VPN connection  114 . 
         [0042]      FIG. 2  is a general flow chart illustrating the sequence of steps from the ordering/registration of a terminal application to implemented use of the terminal application. 
         [0043]    The sequence starts at the start step  200 . 
         [0044]    First, the ordering and registration process  202  is executed. During this process, a user orders a specially adapted terminal application for a specified use. The ordering is typically carried out by means of interaction between the client computer  122  and the web server  124  over the network  120 , typically the Internet. 
         [0045]    During the ordering and registration process  202 , the user identifies and registers himself and orders a downloadable terminal application. By exchanging information with the web server  124 , the user can, via the client computer  122 , select a desired application type. During the ordering and registration process  202 , the desired application type is linked together with a mobile subscriber identification, preferably a mobile telephone number, which is presented by the user. The mobile subscriber identification is used by the web server  124  as an address for a message regarding downloading, which will be sent to the mobile terminal  300  in connection with the downloading process  206 . 
         [0046]    During the ordering and registration process  202 , the user also presents the relevant credential, in particular a password or a PIN code, which will also be associated with the specific terminal application. 
         [0047]    Next, the production or adaptation process  204  is executed. The web server  124  is during the adaptation process  204  arranged to specially adapt a pre-generated terminal application, comprising an executable program code which can be executed by the mobile terminal  300 . Most preferably, the terminal application is a J2ME application (midlet suite), containing the necessary code and other data. The adaptation process  204  starts from an already generated program code for a terminal application, of the type that is selected by the user during the ordering process  202 . 
         [0048]    The adaptation process  204  involves the terminal application being assigned an identifier that is unique to the terminal application concerned. 
         [0049]    The credential that was input from the user during the ordering step  202  is stored in a database in the web server  124 , associated with the assigned unique identifier for the terminal application. The credential is preferably stored in an encrypted manner. 
         [0050]    The adaptation process  204  further involves the terminal application being assigned a basic key which is also unique to the terminal application in question. The basic key is generated during the adaptation process, said basic key being derived from a centrally stored master key and from the unique identifier for the terminal application. 
         [0051]    The adaptation process  204  further involves the program code being marked with the unique identifier and the basic key. Preferably, the data representing the identifier is inserted in the adapted terminal application code in a direct and open manner, whilst the data representing the basic key is inserted in the terminal application code in an obfuscated manner. Obfuscated should in this connection be understood to mean that the basic key is hidden in the code in such manner that it cannot openly be read or derived from the code, for example, by decompilation. 
         [0052]    Additional details of the adaptation process  204  will be further described with reference to  FIG. 5  below. 
         [0053]    The resultant, adapted terminal application is stored on the web server  124 , preferably as a so-called midlet suite. 
         [0054]    In the downloading step  206  in  FIG. 2 , a service message is generated, typically in the form of an SMS message, which is sent to the mobile terminal  300 . The mobile terminal  300  is addressed by means of the aforementioned mobile subscriber identification. The message contains a link to the terminal application which is stored on the web server  124 . When the user of the terminal activates this link, this initiates a downloading of the terminal application from the web server  124  via the network  120 , the gateway  116  and the mobile network  110  to the mobile terminal  300 . 
         [0055]    After the terminal application has been transferred to the mobile terminal, and the mobile terminal has thus been rendered capable of executing the terminal application, a composite application process  210  is carried out. This comprises two subprocesses: a signing process  212  for execution in the mobile terminal, and a verification process  214  for execution in the verification server. 
         [0056]    The signing process  212  involves a user executing the specially adapted, downloaded terminal application on his mobile terminal. The verification process is executed in the verification server in order to verify the signature after the signing process has been executed. This can in turn be used as verification of the user&#39;s identity. 
         [0057]      FIG. 3  is a schematic block diagram illustrating the structural architecture of a mobile communication terminal that is adapted to operate in accordance with the invention. 
         [0058]    The mobile terminal  300  is constructed having a standard bus structure, wherein a bus  302  is operatively connected to a processor  320 , a memory  330 , a subscriber identification module (SIM)  310  in the form of a smartcard, an audio unit  316 , a display adapter  312 , a radio communications module or transceiver  350  and an input adapter  304 . 
         [0059]    The display adapter  312  is further connected to a display  314 . 
         [0060]    The transceiver  350  is further connected to an antenna  352 . 
         [0061]    The input adapter  304  is adapted to receive manual input from an input unit such as a keypad  306 . 
         [0062]    The memory  330  is adapted in order, during the operative functional state of the terminal, to contain, inter alia, specially adapted terminal applications (midlet suite)  340 . A terminal application comprises an executable program code which, inter alia, contains data representing a basic key associated with the terminal application. 
         [0063]      FIG. 4  is a schematic flow chart illustrating a method for execution by a mobile terminal, according to the invention. 
         [0064]    The illustrated method is intended to be executed by a processing unit  320  in a mobile terminal  300 , and its purpose is to provide an electronic signature to a received message. The signed message can then be transferred to a verification server  130 . 
         [0065]    The method is initiated at the start step  400 . 
         [0066]    In the receiving step  402 , a message is received, preferably from the service provider&#39;s component in the terminal. In principle, the message can be a random message or challenge, the content of which has no meaning, such as a random byte sequence. In practice, and especially if the method is to be used in connection with mobile ordering or payment solutions, the message may contain commerce data, especially data representing a contract between the service provider  112  and the user of the mobile terminal  300 . 
         [0067]    In the step  404 , a basic key is fetched from a memory area in the terminal. Specifically, the basic key is fetched from a memory area containing a code portion of a terminal application, that is to say, an application program that has been downloaded in the terminal. Preferably, the code portion, including algorithms and the data representing the basic key, is obfuscated. 
         [0068]    Then, the step  406  is executed, in which a counter value is fetched from a counter in the mobile terminal, preferably from a persistent memory. The counter value is incremented after being fetched, or at another time, so that it has a new value for each new, executed signature generation step  412  (see below). 
         [0069]    Next, the step  408  of inputting a credential from a user of the mobile terminal is executed. Preferably, a password is entered from the user by means of the terminal keypad or other user-operated manual input unit. The password may advantageously be numerical, in the form of, for example, a four-digit PIN code. 
         [0070]    The further processing presupposes the use of an underlying encryption function, which is employed for generation of both key and signature. Particularly advantageously, the encryption function can be based on symmetric cryptography, such as 3DES. 
         [0071]    Now the step  410  is executed, in which a dynamic key is generated based on the basic key, the counter value and the credential. 
         [0072]    The key generation process  410  includes the use of the predetermined encryption function to generate the dynamic key. The basic key, the counter value and the credential are preferably all used as input to this encryption function. Most preferably, the dynamic key is generated according to the following scheme: 
         [0000]    K I   c =f(BK(i), c, PW), wherein
 
f(BK, c, P) is a function for generating a unique encryption key,
 
BK(i) is the basic key; and
 
PW is the input credential.
 
         [0073]    The signature generation step  412  is then executed, during which a signature for the message is generated using the dynamic key. This signature generation step  412  comprises the use of a predetermined signing function on the message received in the receiving step  402 . 
         [0074]    The signing function is based on an underlying encryption function as stated above. Examples of suitable signing functions are known to those skilled in the art as CBC-MAC and OMAC. 
         [0075]    Preferably, the step  414  is then executed, in which the unsigned message, and in which the resulting signature are sent to the verification server  130 . The counter value and the unique identifier for the terminal application are sent in addition. 
         [0076]    With the method described above, it is assured that a dynamic key is only used transiently or temporarily, and solely for signing purposes. The dynamic key is therefore not stored at any time or in any place. Furthermore, it is assured that the credential, such as the PIN code, is not kept stored in the mobile terminal. These features of the invention contribute to increased security. 
         [0077]      FIG. 5  is a process diagram illustrating special adaptation and use of a terminal application. 
         [0078]    The top part of  FIG. 5 , indicated by  504 , illustrates an adaptation process that is executed for production of a specially adapted terminal application. This process  504  has previously been referred to using the reference numeral  204  in  FIG. 2 . The production process  204  is typically executed in the web server  124 , in response to a completed ordering process  202 . 
         [0079]    The bottom part of  FIG. 5 , indicated by  500 , illustrates a signing process for execution by the terminal application. This signing process  500  is executed in the mobile terminal  300  and has previously been referred to using the reference numeral  212  in  FIG. 2 . 
         [0080]    In the following the adaptation process  504  is first described: 
         [0081]    A basic key  532  is derived based on a unique identifier  510  and a master key  518 . The basic key  532  is used as input to the signing process  500 . 
         [0082]    In the following the signing process  500  is described: 
         [0083]    A dynamic key  534  is derived from the credential  520 , the counter value  524  and the basic key  532 . The dynamic key  534  is used as input to the signature generation subprocess  536 . 
         [0084]    During the signature generation subprocess  536 , the message  538  is signed using the dynamic key  534 , which results in a signature  540 . 
         [0085]      FIG. 6  is a schematic process diagram illustrating a verification process  600 . 
         [0086]    The verification process  600  corresponds essentially to the same subprocesses/steps as the adaptation process  204  and the signing process  212 . Where the subprocesses/steps correspond to each other, the same reference numerals are used in  FIGS. 5 and 6 . 
         [0087]    The verification process  600  is executed in the verification server  130 . 
         [0088]    Input data to the verification process consists of the unique identifier  510 , the counter value  524 , the unsigned message  538  and the signature  540  that is to be verified. 
         [0089]    The purpose of the verification process  600  is to give a verification signal  604  (with the value true or false), which indicates whether the submitted signature  540  is the correct signature for the message  538 , given the unique identifier  510  for the terminal application, and the counter value  524 . 
         [0090]    The unique identifier  10 , the counter value  524 , the unsigned message  538  and the signature  540  are received from the mobile terminal after the mobile terminal has completed the signing process. Preferably, this data is received via the server  112  at the service provider. 
         [0091]    In addition, the master key  518  is available for the verification process  600 , as it is stored in the verification server  130 . 
         [0092]    Furthermore, the verification process  600  has access to the database  606  in the verification server  130 . The database  606  comprises stored credentials (in particular passwords or PIN codes) in an encrypted form. A decryption process  608  is provided in order to decrypt stored, encrypted credentials, and in order thereby to provide an unencrypted credential  520  associated with a relevant unique identifier  510 . 
         [0093]    A basic key  525  is derived in module  512  based on a unique identifier  510  and a master key  518 . 
         [0094]    In the module  522  a dynamic key is derived based on the credential  520 , the counter value  524  and the basic key  525 . 
         [0095]    The credential  520  is generated by the decryption function  608  as mentioned above. 
         [0096]    The dynamic key  534  is used as input to the signature generation subprocess  536 . 
         [0097]    In the signature generation subprocess  536 , the input message  538  is signed using the dynamic key  534 , which results in a generated signature  612 . 
         [0098]    In the comparison subprocess  602 , the generated signature  612  is compared with the input signature  540  that is to be verified. If the signatures are identical, the verification signal  604  is established as true. If they are not identical, the verification signal  604  is established as false. 
         [0099]      FIG. 7  is a schematic block diagram illustrating a further aspect of the present invention. This figure shows that the mobile terminal  300  may also contain an additional component  342 , adapted to the services offered by the service provider  112 , such as mobile ordering or payment services. 
         [0100]    The terminal application may consist of several components, but will typically consist of two components. These are a component from the provider and a component in accordance with the present invention, which together constitute a single terminal application as is shown schematically by module  345  in  FIG. 7 . 
         [0101]    Thus, the mobile terminal  300  is in  FIG. 7  shown to comprise an application which may contain two components that can include a downloaded signing component  340  which operatively cooperates and communicates with the provider component  342 . Both components  340 ,  342  are executable program modules which (with reference back to  FIG. 3 ) are included in the memory  330  in the mobile terminal  300 . As indicated in  FIG. 7 , the unsigned message M is transferred from the provider component  342  to the signing component  340 , whilst the signature S, the unique identifier uid, and the counter value cnt are returned to the provider component  342 . Signature S, unique identifier uid, counter value cnt and commerce data, i.e., data associated with the services offered, and especially data associated with a contract between the user and the service provider, are transferred over the mobile communications network to the server  112  at the service provider. The service provider server then communicates message M, signature S, unique identifier uid and counter value cnt to the verification server, via the communications channel (for example, VPN)  114 . In the verification server there is provided a verification signal  604  that is returned to the service provider server  112 , and which indicates verification or refusal of the generated signature. This may be used in the service provider server  112  as verification or authentication of the user&#39;s identification. 
         [0102]    Many modifications and adaptations of the present invention will of course be obvious to those skilled in the art, either on interpreting the above detailed description of the invention or on putting the invention into practice. 
         [0103]    The above detailed description is presented in particular with a view to illustrating and describing advantageous embodiments of the invention. However, the description does not in any way limit the invention to the specific embodiments that are described in detail. 
         [0104]    The mobile network  110  is by way of example disclosed as being a GSM network. However, it should be understood that other mobile communication networks are equally as useful for the invention, e.g., a 3G or UMTS network. 
         [0105]    The mobile terminal  300  is by way of example disclosed as being a mobile telephone. It should be understood that other types of mobile terminals, adapted for communication with the mobile network  110 , are just as useful for the invention, for instance, PDAs or portable PCs. 
         [0106]    Where it has been stated that the mobile terminal application advantageously is a J2ME application (midlet suite), it should be understood that such an embodiment is particularly expedient for reasons of portability, i.e., the possibility of being able to run the application on different hardware platforms without further modification. Other possible implementations are however feasible within the scope of the invention. In particular, the terminal application may be coded at a lower level (object code), or in other high-level languages. 
         [0107]    Further modifications and variations will be obvious to the skilled person in the light of the above description. The scope of the invention is apparent from the patent claims below and their equivalents.