[0049] FIG. 1 shows a schematic view of a client communications terminal and a server communications terminal according to an embodiment of the invention. The client communications terminal 106 includes an aerial 113 for communicating via a mobile communications network 114, e.g. a GSM network. The client communications terminal further comprises circuitry 107 for controlling the communications terminal, a storage medium 108, a display 111 and a keypad 112, or other user input/output means. For example, the client communications device may be a mobile telephone or another personal communications device, such as a communicator, a PDA, a pager, a car phone, or the like. Further examples of a client communications device include a modem, a telefax or other telecommunications equipment. The storage medium 108 may be a memory section of a SIM card comprising EPROM, ROM and/or RAM sections. Alternatively, the storage medium may be a another built-in or insertable memory, such as EEPROM, flash memory, ROM, RAM, etc.

[0050] The client communications terminal further comprises a Bluetooth transceiver 110. Via the Bluetooth transceiver, a local radio link 115 for data transmission can be established between the client communications terminal and a Bluetooth transceiver 104 of a server communications terminal 101 when the server communications device is brought into the connection range of the wireless local communication of the client communications device, or vice versa. The server communications terminal 101 comprises a processing unit 105 and a subscription module 102. In one embodiment, the subscription module is a SIM card comprising a processing unit, a memory including an EPROM section, a ROM section and a RAM section and an input/output port. Hence, the server communications device has direct access to a subscription module and is physically connection to it. The server communications device may grant the client communications terminal access to the services and files of the subscription module 102. For example, the server communications terminal may be a mobile telephone or other personal communications equipment. Alternatively, the server communications device may be a special remote access device which only serves as an access server for different client terminals. For example, the server communications terminal may be implemented as a contactless smart card, e.g. a smart card with an integrated wireless communications interface such as a short-range radio interface.

[0051] Hence, the client communications terminal 106 may access the services and files of the subscription module 102 of the server communications terminal 101, via the radio link 115, and use the accessed for the connection to the cellular network 114. In the above, two general roles have been described: A Remote Authentication Access Server (RAA Server) having direct access to the subscription module, and a Remote Authentication Access Client (RAA Client) obtaining remote access to the subscription module, thereby obtaining access to a number of possible services. Hence, in the following, the client communications terminal will also be referred to as the RAA Client and the server communications terminal will be referred to as the RAA Server. Examples of the functionality, services and data which may be accessed by the RAA Client include:

[0052] Register the RAA Client 106 in a cellular network 114 using the subscription module 102 in the RAA Server 101.

[0053] The RAA client 106 can access data and services available in the subscription module 102.

[0054] The RAA Server 101 may exercise access control on what services and data can be accessed by a RAA Client 106;

[0055] Establish a connection (i.e. a voice, fax, or data call), hereafter referred to as a “call”, from the RAA Client 106 using the subscription module 102 in the RAA server 101;

[0056] Receiving a call from the network 114 at the RAA Client 106.

[0057] According to the invention, the subscription module 102 comprises a remote access authorisation functionality 103 for the protection of the subscription module against unauthorised access to the sensitive subscription information and services on the module. The remote access authorisation functionality 103 provides functionality for the authentication of different RAA Clients, such that only an authorised RAA client is allowed to get access to the subscription module 102. The authentication procedure may be based on a symmetric key mechanism, a public key mechanism, or the like. Two embodiments of such mechanisms will be described in greater detail in connection with FIGS. 5-6. Preferably, the RAA Client 106 comprises a corresponding remote server authorisation functionality 109 allowing the RAA Client 106 to authenticate different subscription modules. Only an authorised module is trusted by the RAA Client. According to the invention, the remote access authorisation functionality 103 and the remote server authorisation functionality 109 have a shared secret, or the possibility of exchanging a shared secret key, used to authenticate and/or protect the connection between the RAA Client 106 and the subscription module 102. The connection between the RAA client 106 and the subscription module 102 is encrypted end-to-end. The key used for the encryption is either fixed or, preferably, derived from the shared secret at each connection set-up. The communication between the RAA client and the subscription module may further be integrity protected end-to-end using a key derived from the shared secret. Furthermore, the subscription associated wit the subscription module 102 may have one or more PIN codes associated with it. Each of these PIN codes may be associated with access restriction to the data and services on the module.

[0058] Hence, it is an advantage of the invention that it provides protection of the connection and authentication of the RAA Client which accesses the subscription module over an air interface. If Bluetooth is used, build-in Bluetooth authentication and encryption can protect the air interface as the Bluetooth baseband security mechanism (Bluetooth Special Interest Group, “Baseband Specification”, Specification of the Bluetooth System, Core, Version 1.1, Dec. 1, 2000) allows fast authentication and encryption between two Bluetooth modules. However, this is only realised on the link level between two Bluetooth radio units and, hence, this is not an end-to-end solution with the subscription module at one end and the RAA Client at the other. Hence, it is an advantage of the invention that it provides authentication and encryption end-to-end between the subscription module and the terminal where the RAA client resides.

[0059] It is noted that, in one embodiment, the subscription module 102 may regard the RAA Server 101 as a trusted proxy. In this scenario, access control may still be realised by the subscription module 102 or it may be delegated to the processing unit 105 of the RAA Server.

[0060] FIG. 2 shows a schematic view of a subscription module according to an embodiment of the invention. The subscription module 102 comprises a processing unit 201 and memory 202 which may be divided into a ROM section 203, an EPROM section 204 and a RAM section 205. The subscription module further comprises an input/output interface 206 for communicating with the device it is inserted in. For example, the subscription module may be a smart card which may be removably inserted in the server communications terminal, e.g. a SIM card in the context of a GSM network. According to the invention, the subscription module is adapted to provide remote access security functionality 103 for protecting access to data stored in the memory 202 and the functionality of the processing unit 201. The processing unit 201 is adapted to provide a number of security functions 103a< /italic>, e.g. as part of the software executed on the processing unit or implemented in hardware. The remote access security functions 103a have access to one or more key codes 103b< /italic>-d of a key based authentication mechanism stored in the memory 202 of the subscription module. The key(s) may be stored in the ROM section 203, the EPROM section 204 and/or the RAM section 205, depending on the authentication mechanism and the lifetime of the key(s). For example, a temporary key used only for a single session may preferably be stored in the RAM section, while a permanent key may be stored in the ROM section. In a mechanism involving multiple keys, different keys may be stored in the same or in different sections.

[0061] FIG. 3 shows a schematic view of a modular server communications terminal according to an embodiment of the invention. The server communications terminal comprises a base module 301 with a subscription module 302 according to the invention. The base module 301 provides interfaces 304 and 306 to a user interface module 308 and a radio interface module 305. The user interface may provide a display for providing a graphical user interface and/or a keypad, a pointing device, or the like. The radio interface unit may comprise a radio transmitter/receiver and an aerial for connecting to a cellular network, a short-range radio transceiver and/or other wireless interfaces. The interfaces 304 and 306 may be implemented as plug-in interfaces, e.g. using a standard such as USB or the like. Alternative, the interfaces may be contact-free interfaces e.g. based on electromagnetic radiation, such as infrared or a radio link, e.g. using the Bluetooth technology or other short-range wireless communications technologies. The data communication via the interface 304 and/or the interface 306 may use a proprietary or a standard protocol. For example the base module may be implemented as a smart card, e.g. a smart card having an integrated radio interface. In another embodiment, the base module may be implemented as a unit providing the interfaces 304 and 306 and including a subscription module, e.g. as a removably insertable unit, such as a smart card. In a modular architecture as in the example of FIG. 3, an end-to-end authentication and protection of the communication to/from the subscription module is of particular importance, as the interfaces 304 and/or 306 of the base module are open and, thus, vulnerable for unauthorised access. Therefore, it is an advantage of the invention that it secures all interfaces when providing remote access to a subscription module.

[0062] FIG. 4 shows a schematic view of a key table stored in a subscription module according to an embodiment of the invention. According to one embodiment of the invention, the authentication of the client communications terminal is based on a symmetric authentication procedure based on a shared secret. Hence, the RAA Client and the subscription module need to have a shared secret in order to authenticate each other and to protect the communication. This shared secret may be a long-lived secret key stored in the subscription module and the client communications terminal, respectively. Alternatively, the shared secret may be a secret key which is created when needed and which is valid for a specific time period, for one session, or the like, i.e. it is a temporary shared secret.

[0063] If the shared secret is long-lived it may, for example, be entered into the RAA client by the RAA client user or by an operator. In the embodiment of FIG. 2, the entered shared secret may be stored in EPROM section 204 of the memory of the subscription module. The operator may also send the secret key over the air or by any other means to the RAA client using some dedicated protocol. Preferably, this protocol needs some additional security mechanism to protect the shared secret when transferred over the air. An example of such mechanism is encryption of the channel with an encryption key derived from another shared secret stored in the RAA client. This key can for example be stored in the RAA client at the time of manufacture. Alternatively, the operator may pre-configure the subscription module with a long-lived shared secret during the personalisation of the subscription module. In the embodiment of FIG. 2, Such a pre-configured shared secret may for example be stored in the ROM section 205 of the memory of the subscription module.

[0064] Referring to FIG. 4, a subscription module or a RAA Client might have several different shared secrets. One particular shared secret is used to secure the communication with one particular RAA Client or subscription module respectively. In order to identify the shared secret, each shared secret is labelled with a unique identifier. This identifier can be of any kind, but should be unique. If each subscription module has a unique ID, it is possible for all RAA Clients to distinguish between different subscription modules and to know which shared secret to use for a connection to a particular subscription module. For example, if the subscription module is implemented as a SIM card, the International Mobile Subscriber Identity (IMSI) may be used to identify the subscription module. Similarly, if each RAA Client has a unique ID, it is possible for all subscription modules to distinguish between different RAA Clients and to know which shared secret to use for a connection to particular RAA Client. Hence, in the subscription module, a table 401 may be stored comprising a number of secret key codes K-1 through K-N together with their corresponding identifiers ID-1 through ID-N, respectively. In the embodiment of FIG. 2, the table 401 may be stored in the EPROM memory section 204, thereby allowing a user to add, edit, or delete entries in the table, e.g. in order to add a new authorised client terminal, or in order to delete an old one. For example, the keys may be 128 bit symmetric keys.

[0065] FIG. 5 shows a flow diagram of an authentication procedure according to an embodiment of the invention based on a symmetric key. Initially, in step 501, a connection is established between the RAA Client and the subscription module. Preferably, this communications link is a short-range wireless communications link as illustrated by the wireless link 115 in FIG. 1. If the wireless connection uses the Bluetooth technology, the connection may be established automatically when the server communications terminal and the client communications terminal are brought within each others range of radio coverage, e.g. within a range of a few meters. In a scenario where the server communications terminal is a mobile telephone and the client communications terminal is a car phone, the connection may be established when the user approaches/enters the car. During or after the connection establishment, in step 502, the terminal exchange IDs. In the subsequent step 503, the IDs are used to look up the corresponding shared secret in a table 401 stored in the memory of the subscription module and in a corresponding table in the memory of the client communications terminal. In step 504, the shared secret is used for authenticating the client communications terminal by the subscription module and to authenticate the subscription module by the client communications device. In step 505, a new shared secret is generated and exchanged between the subscription module and the client communications terminal. Preferably, this key exchange may be a part of the authentication procedure. Alternatively, the key exchange is performed after successful authentication. The authentication and key exchange can be done in several different ways using well known state of the art solutions for shared secret based authentication and key exchange, such as PIN or password based solutions, challenge/response based solutions, a Feige-Fiat-Shamir protocol, a Schnorr protocol, etc., and Diffie-Hellman and related protocols, key exchange using public key encryption, Kerberos type protocols, etc., respectively. The authentication and key exchange may be implemented in hardware or in software. In one embodiment, the authentication further requires an approval by the user of the server communications terminal, thereby further increasing the security against misuse or accidental use. For example, the user may be required to enter a PIN code indicative of an authorisation for remotely accessing the subscription module of the server communications terminal.

[0066] After successful authentication and key exchange, the actual data exchange between the client communications terminal and the subscription module may be initiated in step 506. The data exchange may comprise the transmission of data to and/or from the subscription module, e.g. PIN codes, authorisation codes, identifiers, account numbers, or the like. Preferably, in order to protect the communication between the RAA Client and the subscription module, all messages sent between the entities are encrypted with a symmetric encryption algorithm. Messages encrypted in the PRA Client are decrypted in the subscription module. Messages encrypted in the subscription module are decrypted in the RAA client. The algorithm used to encrypt the messages may be implemented in hardware or software in the RAA client and subscription module respectively. Any standard algorithm and procedure can be used, such as the Data Encryption standard (DES), triple DES (3DES), SAFER+, Advanced Encryption Standard (AES), RC4, RC5, etc. In order to encrypt the messages the RAA client and subscription module use the new shared secret exchanged in step 505. Alternatively, a key derived from the exchanged shared secret may be used. In another embodiment, the shared secret used for authentication may also be used for encryption without further key exchange. However, the generation of an encryption key provides a higher level of security.

[0067] Furthermore, in order to further protect the communication between the RAA Client and the subscription module, all messages sent between the entities are integrity protected. The messages are protected with a symmetric authentication algorithm. A cryptographic message tag is calculated for each message in the RAA Client and checked in the subscription module. A cryptographic message tag is calculated for each message in the subscription module and checked in the RAA Client. The same procedure may be applied in the reverse direction. The algorithm used to calculate the message tag can be implemented in hardware or software in the RAA client and subscription module, respectively. Any standard algorithm and procedure may be used. The shared symmetric key used in the integrity protection may be the shared secret exchanged in step 505, or a key derived from that shared secret.

[0068] Alternatively to a long-lived shared secret, e.g. if no long-lived shared secret exists between the RAA Client and the subscription module, the RAA Server user may allow a particular RAA Client to temporarily connect to the subscription module in the RAA Server. Then a temporary shared secret between the subscription module and the RAA Client needs to be generated. This may be done in several different ways, for example:

[0069] The RAA Server user enters a shared secret value into the RAA Server. The shared secret is directly transferred to the subscription module. Then the PAA Client user enters the same secret value into the RAA Client. As a user interaction is required, a high level of security is achieved.

[0070] The subscription module generates a secret random value. This value is displayed on the RAA server. The RAA Client user enters the secret random value into the RAA Client. As a user interaction is required, a high level of security is achieved.

[0071] The subscription module sends a secret value directly to the RAA Client. The secret value may be protected using for example encryption. The key used to protect the secret value can be a common key known to a particular set of RAA Clients and subscription modules.

[0072] FIG. 6 shows a flow diagram of an authentication procedure according to an embodiment of the invention based on a public key mechanism. In the initial step 601 a connection between the client communications terminal and the server communications terminal is established as described in connection with step 501 of FIG. 5. In step 602, the public key of the RAA Client is retrieved by the subscription module. In order for the subscription module to authenticate and exchange a key with the RAA Client, the subscription module needs access to one or several trusted public keys that this RAA Client uses. The subscription module can obtain the public key(s) in several different ways providing different levels of security. Examples of mechanisms to obtain the public key(s) include:

[0073] The subscription module is pre-configured with a set of trusted public keys used by the RAA Clients. Hence, in step 602, the subscription module may retrieve the public key(s) from its memory, e.g. a ROM or EPROM section of a SIM card as described in connection with FIG. 2.

[0074] The public key(s) of the RAA Client are transmitted to the subscription module during the connection establishment between the subscription module and the RAA client. The subscription module trusts the public keys automatically or upon receipt of a user input approving the public keys. Hence, in this example, step 602 is performed as a part of the connection establishment in step 601.

[0075] The subscription module requests the RAA Client to transfer the public key(s) of the RAA Client during the connection establishment between the subscription module and RAA Client. The key(s) are transferred to the subscription module, possibly together with a public key of a trusted third party. The public key(s) of the subscription module are signed with the private key of the trusted third party.

[0076] The subscription module asks the RAA Client for the public key(s) of the Client at the connection establishment between the subscription module and RAA Client. The key(s) are transferred to the subscription module in a digital certificate. An example of a digital certificate format is the X.509 certificate format.

[0077] The RAA Server user enters at least one or several hash value of a public keys or digital certificate into the device. The hash value is directly transferred to the subscription module. Later, the subscription module receives one or several digital certificates from the RAA Client. The subscription module hashes the received public key or certificate. If the computed hash value corresponds to the hash value entered by the RAA server user, the subscription module trusts the public key. This procedure can, of course, be applied on multiple keys or certificates each having their associated hash value.

[0078] Similarly, in order for the RAA Client to authenticate and exchange a key with the subscription module using a public key mechanism, the RAA Client needs access to one or several trusted public keys belonging to the subscription module. Hence, in an embodiment where the RAA client authenticates the subscription module, step 602 further includes the step of retrieving the public key(s) of the subscription module by the RAA Client. As described above, this may be done in several different ways, for example:

[0079] The RAA Client is pre-configured with a set of trusted public key(s) belonging to the subscription module. Hence, in step 602, the RAA Client retrieves the public key(s) from its memory, e.g. a ROM or EPROM, the memory of a SIM card included in a mobile phone, a WIM card comprising public keys and certificates, or the like.

[0080] The RAA Client asks the subscription module for the public key(s) of the module at the connection establishment between the RAA Client and subscription module. The RAA Client trusts the public key(s) automatically or upon receipt of a user input approving the public keys. Hence, in this example, step 602 is performed as a part of the connection establishment in step 601.

[0081] The RAA Client asks the subscription module for the public key(s) of the module at the connection establishment between the RAA Client and the subscription module. The key(s) are transferred to the RAA client, possibly together with a public key of a trusted third party. The public key(s) of the subscription module are signed with the private key of the trusted third party.

[0082] The RAA Client asks the subscription module for the public key(s) of the module at the connection establishment between the RAA Client and subscription module. The key(s) are transferred to the RAA client in a digital certificate. An example of a digital certificate format is the X.509 certificate format.

[0083] The RAA Client user enters one or several hash values of public keys or digital certificates into the device. Later, the RAA Client receives one or several digital certificates from the subscription module. The RAA Client hashes the received public key(s) or certificate(s). If the has value(s) correspond to the hash value entered by the RAA Client user, the public key(s) are trusted by the PAA Client.

[0084] In step 604, the trusted public key(s) related to the RAA Client are used for the subscription module to authenticate the RAA Client. Similarly, the trusted public key(s) stemming from the subscription module are used to authenticate the subscription module. In step 605, a shared secret is generated and exchanged between the subscription module and the client communications terminal, resulting in a common secret key for the client communications device and the subscription module. Preferably, this key exchange may be a part of the authentication procedure. Alternatively, the key exchange is performed after successful authentication. The authentication and key exchange can be done in several different ways using well known state of the art solutions for public key based authentication and key exchange, such as PIN or password based solutions, challenge/response based solutions, a Feige-Fiat-Shamir protocol, a Schnorr protocol, etc., and Diffie-Hellman and related protocols, key exchange using public key encryption, Kerberos type protocols, etc., respectively. The authentication and key exchange may be implemented in hardware or in software. In one embodiment, the authentication further requires an approval by the user of the server communications terminal, thereby further increasing the security against misuse or accidental use. For example, the user may be required to enter a PIN code indicative of an authorisation for remotely accessing the subscription module of the server communications terminal.

[0085] After successful authentication and key exchange, the actual data exchange between the client communications terminal and the subscription module may be initiated in step 506, preferably using a symmetric encryption algorithm, as described in connection with FIG. 5. In order to encrypt the messages, the RAA client and subscription module use the shared secret exchanged in step 605. Alternatively, a key derived from the exchanged shared secret may be used. In another embodiment, the encryption may be based on a public key mechanism, thereby not requiring the exchange of a shared secret.

[0086] Furthermore, in order to further protect the communication between the RAA Client and the subscription module, all messages sent between the entities are integrity protected, as described in connection with FIG. 5. The shared symmetric key used in the integrity protection may be the shared secret exchanged in step 605, or a key derived from that shared secret.

[0087] It is noted that the invention has mainly been described in connection with a GSM network. However, it is understood that the present invention is not limited to GSM networks but may also be applied to other communications networks, e.g. other mobile telecommunications networks such as GRPS and 3^rd generation networks, such as UMTS.