EP2047704A2

EP2047704A2 - Mobile communications systems

Info

Publication number: EP2047704A2
Application number: EP07766424A
Authority: EP
Inventors: Andrew Lain Nicol; Mark Wentworth Rayne
Original assignee: Sepura Ltd
Current assignee: Sepura Ltd
Priority date: 2006-08-03
Filing date: 2007-08-03
Publication date: 2009-04-15
Also published as: WO2008015448A3; KR20090035720A; GB2441409A; WO2008015448A2; GB0715117D0

Abstract

A method of registering an identity with the network infrastructure of a mobile communications system in which a communications terminal first registers itself with the system infrastructure. Once registered, the terminal exchanges messages with the system infrastructure relating to an identity to be registered, for example, a smart card that is insertable into the terminal or a user of the terminal. The terminal, once having completed the message exchange, then registers with the system infrastructure the identity to be registered.

Description

Mobile Communications Systems

The present invention relates to mobile communications systems, and in particular, but not exclusively, to the TETRA (TErrestrial Trunked RAdio) system.

In many mobile communications systems, including the TETRA system, users are required to register with the system infrastructure in order to, e.g. use the system.

In the TETRA system, for example, a mobile station or terminal will register with the system infrastructure using the identity allocated to the mobile station (its individual terminal subscriber identity, ITSI) and an authentication (cryptographic) key, K allocated to (associated with) the mobile station. The identity, ITSI, is an identity that uniquely, for example, identifies the communications terminal to the system.

The authentication key K, used in TETRA, is, as is known in the art, a secret authentication key that is used to authenticate the mobile station, etc., to the system infrastructure and the system infrastructure to the mobile station (etc.) . It should be known only by the mobile station and the authentication centre (or similar) of the system infrastructure. The system infrastructure will typically store a database of subscriber identity (ITSI) and authentication key, K, pairs. The authentication key K can be and is also used to derive encryption keys .

It is also now possible in a TETRA system for a so-called "smart card" to be the entity which registers with the system infrastructure and to which, e.g., calls can be directed. This allows a user to have, for example, their own unique smart card that is personal to them, which they can then use in any suitable communications terminal that can receive the smart card. The smart card comprises, e.g. and as is known in the art, a module or card similar to a subscriber identity module (SIM) but which has some processing capabilities, and may act, e.g., as an encryption module, e.g., for end-to-end encryption purposes . It is portable and easily moved from one communications terminal to another, and typically fits in (can be received in) the SIM card socket (interface) of a communications terminal .

To facilitate this, the smart card is similarly allocated an identity (ITSI) and an authentication key that can be used to register the smart card with the system infrastructure. This allows the smart card to be identified, no matter which communications terminal or infrastructure it is used in. These parameters are usually stored on the smart card itself, in a secure fashion. When a user of a smart card wishes to register (the smart card) with the system infrastructure, it is necessary for the communications terminal to which the smart card is coupled to carry out the registration process. In effect, the terminal assumes the identity of the smart card and registers with the system infrastructure using the smart card's identity parameters, rather than its own, "terminal" identity.

In order to do this registration process, the communications terminal typically needs to be provided with the identity (ITSI) allocated to the smart card, and the authentication key (K) allocated to the smart card, so that it can then use these parameters to register and authenticate with the system infrastructure, as is known in the art. One way to provide the communications terminal with the identity (ITSI) and authentication key (K) of the smart card would be for the communications terminal to read those parameters from the smart card. However, the interface between a communications terminal and smart card is typically well known and vulnerable to attack, such that allowing these parameters to be available in this way could, e.g., leave them susceptible to attack from malicious third parties. If the authentication key K of the smart card becomes known, then, as is known in the art, network security can become compromised in a number of ways. For example, air-interface encryption can be decoded, exposing the signalling and (unless end-to-end encryption is employed) speech communication between the user and the system infrastructure.

It would be possible to use some form of encryption when transferring the smart card's identity and authentication key to the communications terminal in this way, but even then that may not be sufficiently secure, and/or may place additional or excessive processing burdens on the smart card. For example if using encryption across the terminal-card interface it would also be necessary to, e.g., install a suitable shared encryption key or keys in both the smart card and each communications terminal in which the card might be installed. As such a key or keys would have to be relatively widely distributed, that is a security risk.

The Applicants believe therefore that there remains scope for improvements to the process for allowing the registration of smart cards that have unique subscriber identities with the infrastructure of a communications system.

Thus, according to a first aspect of the present invention, there is provided a method of registering a smart card of a mobile communications system with the network infrastructure of the communications system, the method comprising: a Communications terminal to which the smart card is coupled first registering itself with the Communications system infrastructure; the communications terminal, once registered with the communications system infrastructure, exchanging messages relating to the smart card with the system infrastructure; and the communications terminal, once it has completed the message exchange with the system infrastructure, registering the smart card with the system infrastructure .

According to a second aspect of the present invention, there is provided a communications terminal for use with a mobile communications system, and to which a smart card can be coupled, the communications terminal comprising: means for registering itself with the communications system infrastructure; means for, once registered with the communications system infrastructure, exchanging messages relating to the smart card with the system infrastructure; and means for, once it has completed the message exchange with the system infrastructure, registering the smart card with the system infrastructure. According to a third aspect of the present invention, there is provided a mobile communications system, comprising: a system infrastructure; a communications terminal to which a smart card can be coupled, the communications terminal comprising: means for registering itself with the communications system infrastructure; means for, once registered with the communications system infrastructure, exchanging messages relating to the smart card with the system infrastructure; and means for, once it has completed the message exchange with the system infrastructure, registering the smart card with the system infrastructure; the system infrastructure further comprising: means in the system infrastructure for registering a communications terminal or a smart card using information provided by a ςommunications terminal for that purpose.

According to a fourth aspect of the present invention, there is provided a method of operating a mobile communications system that includes one or more communications terminals to which smart cards can be coupled, and a system infrastructure, the method comprising: a communications terminal to which a smart card is coupled first registering itself with the communications system infrastructure; the communications terminal, once registered with the communications system infrastructure, exchanging messages relating to the smart card with the system infrastructure; and the communications terminal, once it has completed the message exchange with the system infrastructure, registering the smart card with the system infrastructure.

In the present invention, a communications terminal that wishes to register a smart card with the communications system infrastructure first registers itself with the system infrastructure and then exchanges messages with the infrastructure to allow it to register as the smart card. This avoids the need, e.g., for the communications terminal to obtain registration information such as an ITSI (individual terminal subscriber identity) and authentication key from the smart card itself. This means that, for example, that information need never be transferred across the vulnerable communications terminal/smart card interface. The present invention thus provides a technique whereby a communications terminal can register (as) a smart card in a more secure and controllable fashion. The communications terminal can register itself with the system infrastructure in any suitable manner. It preferably does so using the conventional or normal registration techniques for the communications system in question. Thus, in the case of a TETRA system, the terminal preferably connects to and registers with the infrastructure (e.g. an authentication or registration centre of the communications system infrastructure) using its own identity (ITSI) and authentication key (K) . The terminal may also undergo an authentication process at this time, if desired.

The exchange of messages with the system infrastructure relating to the smart card can be any suitable and desired such exchange of messages. These messages are preferably exchanged with an authentication and/or trust centre of the system infrastructure.

These messages can be sent in any suitable and desired manner. For example, they could comprise new signalling messages at the same level as the existing registration or authentication signalling of the communications system. Alternatively or additionally, they could be sent as short data messages (e.g. SMS or SDS messages), e.g. comprise a new message inside a short data message of the communications system. In the case of communications systems where communications terminals can operate independently of the system infrastructure, such as in TETRA Direct Mode Operation (DMO) , and where in those circumstances a communications terminal can, and still wishes to, register with the system infrastructure when operating in that mode (e.g. in TETRA DMO) , the message exchange could, e.g., be sent, and preferably is sent, e.g. as an encrypted short data message, via a direct mode gateway into the system infrastructure. This would allow terminals that are using direct mode operation still to register a smart card (where that is possible) and then, e.g., and subsequently (e.g., subject to any required further authentication) , to be contacted from the fixed infrastructure .

The exchanged messages are preferably sent in an encrypted form. Preferably air-interface encryption is used. For example, they may be and preferably are encrypted using an encryption key of or associated with the communications terminal, or a key derived from such a key, such as, in a TETRA system, the SCK, or preferably the DCK (derived cipher key - which may be obtained as a by-product of authentication, as is known in the art), of the communications terminal.

Thus, for example, the system infrastructure (e.g. trust or authentication centre) preferably uses an (preferably unique) authentication key K (e.g. the key K) that is associated with the communications terminal, or a key derived therefrom, to seal any message that it sends to the communications terminal. This helps to ensure that only the requesting communications terminal can unseal the registration messages. When the communications terminal receives the message, it can unseal it (decrypt it) using its appropriate key. This unsealing is preferably carried out in a secure fashion, e.g., in a secure location. For example, the message (s) may be and preferably is unsealed in a secure area in the same way as sealed air interface keys are unsealed. This could be and preferably is achieved, e.g., by storing the keys and encryption algorithms in a secure processing means or device and such that they are never exposed outside that processing means or device. The encryption (aμthentication) algorithms that are used to seal and unseal the messages may be any suitable and desired such algorithms. For example, and preferably, the standard authentication algorithms (or a modified version of them) , such as the TAAl authentication algorithms in TETRA, of the communications system may be used.

The communications terminal preferably transmits with its initial message or messages to the system infrastructure, a piece of, preferably unique, information about the smart card, to allow the infrastructure (e.g. trust centre) to identify the smart card in question. This information could, e.g., comprise the unique identity of the smart card, such as its ITSI (in TETRA) . However, it preferably comprises another piece of information from which the identity of the smart card can be derived, such as, and preferably, the serial number of the smart card. The infrastructure (e.g. trust or authentication centre) would, e.g., store an association between serial numbers, and identity (e.g. ITSI) for each smart card. Using the, e.g., serial number of the smart card when making the message exchange avoids, e.g., revealing the unique identity (ITSI) and any registration information (e.g. authentication key, K) pairing during the message transaction. This enhances the security of the operation.

In one preferred embodiment, the message exchange with the system infrastructure comprises the communications terminal requesting registration information for the smart card from the system infrastructure, and the system infrastructure in response thereto providing the required registration information to the communications terminal . In this arrangement, the communications terminal will then register the smart card with the system infrastructure using the registration information for the smart card received from the system infrastructure, once it has received the requested registration information from the system infrastructure. In effect, in this arrangement, the communications terminal will register the smart card with the system infrastructure using registration information for the smart card obtained from the system infrastructure (e.g. an authentication and/or trust centre of the system infrastructure) .

In these arrangements, the registration information for the smart card that the communications terminal requests from and receives from the system infrastructure (e.g. and preferably from an authentication and/or trust centre of the system infrastructure) can comprise any suitable and desired such information. It preferably comprises information necessary for the registration procedure of the communications system in question. Thus, in the case of a TETRA system, this registration information preferably comprises the authentication key, K, associated with the smart card.

In another preferred embodiment, rather than or as well as, the system infrastructure (e.g. trust centre) returning the authentication key, K of the smart card as the registration information, it returns the identity (e.g. ITSI in TETRA) of the smart card. This could be the case where the communications terminal sends the serial number, rather than the ITSI, of the smart card to the system infrastructure. Thus the registration information that the system infrastructure sends to the terminal as well as preferably comprising an authentication key, preferably also or instead comprises an identifier for the smart card (identity) to be registered. In this arrangement, the system infrastructure could also return the authentication key K of the smart card to the communications terminal. Alternatively, it could return an authentication key K that is, e.g., simply to be used for this session, e.g., selected on a random' basis . In this case the system (infrastructure) would associate the allocated authentication key K with the identity (e.g. ITSI) of the smart card, for example by instructing an authentication centre of the system infrastructure to perform and record this association. This would allow, e.g., the system to provision a new and different authentication key K to a smart card each time, it, e.g., registers with the system.

Thus, in a preferred embodiment,, the system infrastructure sends registration information

(preferably an authentication key) that is associated with the smart card (identity) to be registered, or sends registration information (preferably an authentication key) generated for the smart card (identity) (e.g. randomly) at the time

(contemporaneously), to the terminal. In the latter case the generated registration information (e.g. authentication key) is ^'preferably associated with the identity of, or provided by the terminal for, the identity (e.g. smart card) to be registered.

In a particularly preferred embodiment, the system does not send an authentication key K to the communications terminal, but instead associates the communications terminal's authentication key K with the smart card's identity (e.g. ITSI) . This would then allow the smart card to be registered and authenticate using its identity (e.g. ITSI) and the authentication key of the communications terminal. This would then, in effect, permit the communications terminal to use its own unique key, K in association with the smart card's identity (ITSI) and thereby avoid the need, e.g., for - li ¬

the authentication key K of the smart card to be transmitted at all, to be disclosed, e.g., to a visited (foreign) network, or, indeed, even for the smart card to store and use an authentication key K at all. Thus, in a preferred embodiment, the system infrastructure associates registration information (and preferably an authentication key) of the communications terminal with the smart card's identity (with the identity to be registered) , and, preferably, the terminal then registers the smart card (identity) to be registered using the terminal's registration information (e.g. authentication key) .

It should be noted here that where, as for example happens in TETRA systems, an identity value is replaced with a transformed or different identity value (such as the ESI (encrypted short identity) which is derived in TETRA from the ITSI for use, e.g., outside the scope of air-interface encryption (e.g. in packet headers)), then any necessary identities, and associations with identities, etc., can and preferably do include such additional, e.g., derived, identities, as appropriate, and references to identities and, e.g., ITSIs, etc. herein should be interpreted accordingly.

Similarly where, as in the TETRA system, a truncated or short-form identity may be used, such as the individual short subscriber identity (ISSI) in TETRA, then again any references to identities, etc., herein are intended to encompass and include such short- form identities as appropriate. (As is known in the art, in a TETRA system, the full, individual terminal subscriber _^identity (ITSI) is made up of a so-called individual short subscriber identity (ISSI) , together with a network code and a country code. In some circumstances, such as on a terminal's home network, the individual short subscriber identity (ISSI) can be sufficient to, and is used to, identify the terminal, rather than the full individual terminal subscriber identity (ITSI) . The present invention can be applied equally in such circumstances, e.g. if and when using the ISSI as the identity in question.) In another preferred embodiment, the message exchange with the system infrastructure simply comprises the communications terminal transmitting the identity of the smart card to the system infrastructure and the system infrastructure then returning (if appropriate) permission for the communications terminal to register as the smart card. This would be suitable where, for example, the communications terminal knows (and transmits) the identity (ITSI) of the smart card. In this case, the system infrastructure could then associate the terminal's authentication key K with the ^• smart card as discussed above, or could send an alternative authentication key K to the terminal to use in association with the smart card, again as discussed above . In a particularly preferred embodiment of the present invention, the message exchange between the communications terminal and the system infrastructure comprises "an authentication process for the smart card, such as, and preferably, a challenge from the system infrastructure and a response by the smart card which the system infrastructure then checks to validate (or not) the smart card. This enhances the security of the registration process.

In this arrangement, the smart card and system infrastructure (e.g. trust centre) preferably store a pair or set of or a mutual "challenge" authentication key, and the system infrastructure sends an authentication challenge, such as a random number, which the smart card then encrypts using the challenge authentication key and returns the encrypted "challenge" to the system infrastructure, which can then decrypt it to check the validity of the smart card.

Thus, in a particularly preferred embodiment, the communications terminal sends a message identifying the smart card to the system infrastructure, the system infrastructure returns an authentication challenge message, the smart card of the communications terminal prepares a response to the challenge, and the response is returned to the system infrastructure for it to check to validate (or otherwise) the smart card. The response is preferably sent with a tag or some other form of identifier, identifying the challenge to which it relates .

In these arrangements, the challenge is preferably a non-repeating challenge, so that it is, for example, less susceptible to replay attacks.

These authentication challenges may use existing authentication processes and keys, such as keys and processes that are already present for other authentication purposes, such as air-interface authentication (in TETRA the TAAl algorithms and key K and/or a sub-set of the TAAl algorithms, such as the air-interface algorithms TAlI and TAl2) . However, in a preferred embodiment, a different set of authentication algorithms and keys are used for this purpose, such as, for example, and preferably, an individual user authentication key stored securely in the smart card (and known only to the smart card and infrastructure and never emitted from the smart card) , that is then used with an encryption algorithm, such as the AES algorithm, and a challenge (e.g. a 128-bit challenge), for this purpose.

In a particularly preferred arrangement of these embodiments of the invention, a mutual authentication process, i.e. between the system infrastructure and the smart card, such as a challenge-challenge^response protocol is carried out. This would allow the smart card to check the validity of the system infrastructure as well (to verify that it is on an authorised network) , e.g., before performing encryption. The authentication of the infrastructure by the smart card could similarly use any suitable process and algorithms, such as, and preferably, the AES algorithm or the TETRA air-interface algorithms TA21 and TA22, and/or a user authentication key as discussed above. In such arrangements, the user authentication key is preferably made "write once", as authentication of the infrastructure could then permanently prevent use of a stolen smart card on an unauthorised network, and thus could prevent unauthorised export. In particular, by making the user authentication key "write once", not only would the user of a stolen smart card not know the current authentication key, he (or the network) would also not be able to change the authentication key to a different known key to try to reactivate the smart card. This is in contrast to the arrangement where the user authentication key is "rewritable", since then, although the ser of a stolen smart card would not know the current authentication, he might be able to rewrite (change) the key to one of his own choosing and thereby be able to use the smart card) .

Where an authentication process is carried out, once the authentication has been successfully completed, then the system can proceed as desired to allow the communications terminal to register as and use the (validated) .smart card. Thus, for example, the system infrastructure could, as discussed above then send the identity (ITSI) and/or an authentication key (either the particular key of the card, or a key allocated for the present session, as discussed above) for the smart card to the communications terminal to allow the registration process to be carried out and the smart card to be used. Alternatively, once the smart card has been authenticated, the system could simply associate the authentication key K of the communications terminal with the smart card (e.g. by copying the terminal's authentication key, K, or cross-referencing it) , as discussed above, and, e.g., transmit a registration permission to the communications terminal.

, ^■ The smart card could also, e.g., refuse to perform end-to-end encryption until the registration process has been completed successfully.

In a particularly preferred embodiment where authentication of a smart card can be performed, the system infrastructure can carry out such authentication as and when it desires, as well as at the initial registration process, for example periodically and/or in response to particular, e.g., predetermined, events. This would help to enhance the security of the system.

Once the communications terminal has completed the message exchange, e.g., received, and, e.g., decrypted, the registration information, it can then perform the registration process (and,- e.g., any desired authentication process) for the smart card. This again should follow the normal registration procedure for the communications system, but the communications terminal will, in effect, assume the identity of the smart card.

As the terminal re-registers using the identity of the smart card, there can be no detectable association with the terminal which had the message exchange with the infrastructure. Once this registration has taken place, the user can be contacted directly using the identity of the smart card.

In a preferred embodiment, the communications terminal de-registers itself prior to registering the smart card with the system infrastructure (and, e.g., after receiving the registration information from the system infrastructure) . This may be required, e.g., by the infrastructure's broadcast settings. This facilitates the terminal then assuming the identity of the smart card'. Such de-registration is preferably carried out, e.g., if required by the infrastructure, or if the communications terminal or user so chooses. It preferably happens automatically, and is preferably initiated by the communications terminal, so that the user is not aware of the process. Alternatively, the communications terminal could ask permission of the user before de-registering. This would, e.g., alert the user, e.g., to a change in the smart card.

In a preferred embodiment, a, preferably predetermined, delay is imposed between the de-registration of the terminal and registration of the smart card. This will further obscure any link between the terminal and smart card (user) .

The registration process of the present invention could be carried out each time a communications terminal is, e.g., activated. However, in one preferred embodiment, the communications terminal monitors whether its smart card has changed, and only carries out the above registration process when it determines that the smart card has changed. Thus, the communications terminal can preferably interrogate its smart card to determine whether it has been changed. This could be done by the terminal reading the serial number or identity (ITSI), or both from the smart card. Such interrogation could, e.g., be performed periodically, and/or on the occurrences of particular, e.g. predetermined and/or selected, events, such as activation of the terminal, at power-up, etc.. If in these arrangements the communications terminal determines that the smart card has changed, it then preferably proceeds to follow the registration process of the present invention. The terminal could also, if desired, alert the user to the fact that the smart card has changed (and, e.g. and preferably, require a user input before continuing) . This would alert the user to the fact that the smart card has been changed .

In a preferred embodiment, a user is similarly alerted (and, e.g., a user input required) when the smart card is removed but not replaced, and/or when the terminal receives the confirmation message from the infrastructure that the smart card has been registered (has been activated) .

On the other hand, if the smart card has not changed, the terminal could and in one embodiment preferably does, register immediately using the smart card's identity (e.g. ITSI and authentication key K) (which it should already have from a previous registration session) . This^' arrangement has the advantage that the extra registration steps for registering the smart card are normally only required once per terminal-smart card pairing, and so should accordingly be a relatively rare event .

In a preferred embodiment, the system infrastructure, e.g., trust centre, can challenge and re-authenticate a smart card at any time it chooses, i.e. not just when it is detected that a smart card has changed. This further enhances the security of the system, and may, for example, help to reduce the possibility of a cloned smart card being installed in place of the true card (e.g. while the terminal is powered off) and that switch not being detected. Such

"ad-hoc" authentication challenges can preferably be carried out as desired, e.g., at random, at predefined intervals and/or on the occurrence of particular events. Preferably the smart card registration process (the activation process) includes the facility of initiating an authentication of the smart card, for this purpose. It is also preferably possible for the Communications terminal itself to be able to conduct a "local" challenge (authentication) of the smart card. This could be done in any desired manner, but preferably uses challenge and response values observed (and recorded) during the (initial) activation or authentication of the smart card by the system infrastructure. Another suitable "local" challenge arrangement would be to use, e.g., a public-key cryptographic encryption exchange whereby the terminal and smart card can validate each other, and, e.g., verify that the card is one which has been successfully authenticated in the past. Other arrangements would, of course, be possible. Preferably, if the smart card's response to the terminal's challenge does not match the expected or recorded response, the user is alerted and/or the terminal triggers a full smart card authentication and registration process by the infrastructure. An advantage of such a local, terminal-based challenge is that the initial challenge and response is particular to the terminal and smart card pair in question and therefore harder for an attacker to intercept and clone.

This will help to further enhance the security of the process, but without requiring air-interface loading for the initial challenge. Such a local, terminal-based challenge could be carried out as desired, e.g., at each power-on, and/or when it is determined that the smart card has (apparently) not been changed (such that a full authentication procedure may not (at least initially) be performed) .

It is also preferred for a smart card to be able to determine if the terminal it is installed within has changed. This would help to guard against unauthorised removal of the smart card into a different communications terminal. Preferably in this arrangement , the smart card can read the terminal ' s identity (e.g. at power-up) and compare it with a previously stored value. Other arrangements would, of course, be possible. If the smart card detects a change of terminal, it preferably can and does refuse to operate and/or offers limited services only, e.g., and preferably until such time as it has authenticated the system infrastructure again.

In a preferred embodiment, the system infrastructure (e.g. trust and/or authentication centre) can and does keep track of communications terminals and smart cards and/or controls permissions of communications terminals and smart cards, e.g., in relation to their use and/or permitted associations . For example, the system can preferably disable a terminal or module or refuse requested information, e.g., if it comes from or relates to a terminal or smart card that is marked as stolen or unauthorised. Thus, the system infrastructure (e.g. trust centre) can preferably control which communications terminals can use which smart cards. The system infrastructure (e.g. trust centre) can preferably also or instead keep track of the association between a requesting communications terminal and the corresponding smart card, so that, e.g., they can both be identified, and, e.g., if necessary, disabled.

The smart card in the present invention can be any suitable such card. As discussed above, it is preferably in the form of a removable module that can be fitted into the SIM card socket of a communications terminal. It should comprise some form of processing function. It preferably comprises an encryption module that, for example, contains the microprocessors and other electrical components necessary to encrypt and decrypt voice and data being transmitted or received by the communications terminal, for example for end-to-end encryption purposes .

The smart card is preferably removable or detachable from a communications terminal. It is preferably a module that is fitted as a separate component, such as a board or card, although this is not essential, and it could, e.g., also be part of or combined with another component. The smart card can be an external or internal module. Although the present invention has been described with particular reference to the registration of smart cards in a mobile communications system, the Applicants have recognised that techniques of the present invention would also be applied to other portable and/or, e.g., removable, devices that may be coupled to or associated with a communications terminal and that can carry a defined identity (e.g. user identity) that it may be desirable to register on the communications system and, indeed, could be applied where a user may themselves have an assigned identity that they wish to be able to use with plural different communications terminals . For example, the techniques of the present invention could be used to allow a, e.g., policeman or other user to register a communications terminal with their own personal identity (e.g. collar number) and then receive on the terminal calls addressed to this personal identity, in a similar manner to the terminal assuming the identity of the smart card as discussed above. This would provide, in effect, a method of inserting a user's identity in a terminal.

In such arrangements, the communications terminal would, as discussed above, first register itself with the communications system, and then exchange messages with the system in order to register the new, e.g., user identity with the system, in a similar manner to that discussed above for smart cards . Thus, according to a fifth aspect of the present invention, there is provided a method of registering an identity with the network infrastructure of a mobile communications system, the method comprising: a communications terminal first registering itself with the communications system infrastructure; the communications terminal, once registered with the communications system infrastructure, exchanging messages relating to the identity to be registered with the system infrastructure; and the communications terminal, once it has completed the message exchange with the system infrastructure, registering with the system infrastructure the identity to be registered with the system infrastructure. According to a sixth aspect of the present invention, there is provided a communications terminal for use with a mobile communications system, the communications terminal comprising: means for registering itself with the communications system infrastructure; means for, once registered with the communications system infrastructure, exchanging messages with the system infrastructure relating to an identity to be registered with the system infrastructure; and means for, once it has completed the message exchange with the system infrastructure, registering with the system infrastructure the identity to be registered.

According to a seventh aspect of the present invention, there .is provided a mobile communications system, comprising: a system infrastructure; a communications terminal, the communications terminal comprising: means for registering itself with the communications system infrastructure; means for, once registered with the communications system infrastructure, exchanging messages with the system infrastructure relating to an identity to be registered with the system infrastructure; and means for, once it has completed the message exchange with the system infrastructure, registering with the identity to be registered with the system infrastructure; the system infrastructure further comprising: means in the system infrastructure for registering a communications terminal or an identity using information provided by a communications terminal for that purpose.

According to an eighth aspect of the present invention, there is provided a method of operating a mobile communications system that includes one or more communications terminals, and a system infrastructure, the method comprising: a communications terminal first registering itself with the communications system infrastructure; the communications terminal, once registered with the communications system infrastructure, exchanging messages with the system infrastructure relating to an identity to be registered with the system infrastructure; and the communications terminal, once it has completed the message exchange with the system infrastructure, registering with the system infrastructure with the identity to be registered. As will be appreciated by those skilled in the art, these aspects and embodiments of the invention can and preferably do include any one or more or all of the preferred and optional features of the invention described herein, as appropriate. In these arrangements and aspects of the invention, the identity to be registered with the system infrastructure (i.e. to be assumed by the terminal), could, e.g., be the identity of or associated with, and, e.g., indicated by, a portable or removable device such as a smart card that is associated with or coupled to the communications terminal, or could, e.g., be associated with, and e.g., input, e.g., manually, by, a user of the terminal such as a user's (e.g., policeman's) assigned personal identity.

In a preferred arrangement of these aspects and embodiments of the invention, the exchange of messages with the system infrastructure includes providing the selected identity to the system infrastructure and an authentication process for the identity (e.g. device or user in question) . The authentication process could, e.g., and preferably does, comprise a challenge and response process as discussed above, and/or the provision of authentication data, such as, and preferably, a personal identification number (PIN) , by the terminal to the system infrastructure. The latter arrangement could be and preferably is used to allow, e.g., a user to authenticate themselves with the system. Thus, in a particularly preferred embodiment, the exchange of messages includes the provision of a PIN to the system infrastructure for authentication purposes. In these arrangements, the authentication algorithm is preferably standardised, e.g., in a TETRA system, by specifying the use of the TAlI and TA12 algorithms instead of AES.

Thus, in a particularly preferred embodiment of these aspects and arrangements of the invention, the communications terminal will first register itself with the system, a user will then enter their personal identity and, or subsequently, a PIN, and the system will then authenticate that user and associate the terminal in question with the user's identity. This would allow, e.g., a policeman to pick up any' communications terminal, enter their collar number (identity) and a PIN, and then be able to receive on the terminal calls addressed to their personal identity (collar number) . Thus, according to a ninth aspect of the present invention, there is provided a method of registering a user's identity with the network infrastructure of a mobile communications system, the method comprising: a communications terminal first registering itself with the communications system infrastructure; the communications terminal, once registered with the communications system infrastructure, exchanging messages relating to user's identity with the system infrastructure; and the communications terminal, once it has completed the message exchange with the system infrastructure, registering the user's identity with the system infrastructure .

According to a tenth aspect of the present invention, there is provided a communications terminal for use with a mobile communications system, the communications terminal comprising: means for registering itself with the communications system infrastructure; means for, once registered with the communications system infrastructure, exchanging messages relating to a user's identity with the system infrastructure; and means for, once it has completed the message exchange with the system infrastructure, registering the user's identity with the system infrastructure.

According to an eleventh aspect of the present invention, there is provided a mobile communications system, comprising: a system infrastructure; a communications terminal, the communications terminal comprising: means for registering itself with the communications system infrastructure; means for, once registered with the communications system infrastructure, exchanging messages relating to a user's identity with the system infrastructure; and means for, once it has completed the message exchange with the system infrastructure, registering the user's identity with the system infrastructure; the system infrastructure further comprising: 'means in the system infrastructure for registering a communications terminal or a user's identity using information provided by a communications terminal for that purpose.

According to a twelfth aspect of the present invention, there is provided a method of operating a mobile communications system that includes one or more communications terminals; and a system infrastructure, the method comprising: a communications terminal first registering itself with the communications system infrastructure; the communications terminal, once registered with the communications system infrastructure, exchanging messages relating to a user's identity with the system infrastructure; and the communications terminal, once it has completed the message exchange with the system infrastructure, registering the user's identity with the system infrastructure .

As will be appreciated by those skilled in the art, these aspects and embodiments of the invention can and preferably do include any one or more or all of the preferred and optional features of the invention described herein, as appropriate. Thus, for example, the user's identity preferably comprises an identity, such as a collar number, associated with the user, and that identity data is preferably manually input to the terminal by a user. The user's identity is preferably sent by the terminal to the system infrastructure. Similarly, the exchange of messages preferably comprises an authentication process, which authentication process preferably comprises the terminal providing to the system infrastructure authentication data, preferably in the form of a PIN (personal identification number) , provided by the user.

In these arrangements and aspects of the invention, the registered user or device identity could be, e.g., and preferably is, allocated an authentication key, K, for use in the registration process, as discussed above. This authentication key could be, e.g., selected at random, or already associated with the user's or device's identity, as discussed above.

However, in a particularly preferred embodiment, the user's or device's identity is associated with the communications terminal's authentication key, K, e.g., by temporarily copying or referencing that key onto the user's or device's identity in the appropriate system's

(e.g. trust or authentication centre's) database or databases, as discussed above. Thus, in a particularly preferred embodiment, these aspects and arrangements of the invention include a step of or means for associating registration information, and preferably an or the authentication key, used for registration purposes by the communications terminal with the separate identity of a user and/or device that may be coupled to or associated with the terminal. It is believed that the idea of temporarily associating registration information and/or a registration parameter (S) , such as an or the authentication key, used for registration of a communications terminal with another identity of the communications system (i.e. not the identity of the terminal) may be new and advantageous in its own right, since this would, for example, facilitate user portability between communications terminals.

Thus, according to a thirteenth aspect of the present invention, there is provided a method of operating a mobile communications system in which communications terminals of the system are provided with identities and registration information and/or parameters for the purposes of registering with the communications system infrastructure, the method comprising: associating registration information and/or parameter of a communications terminal of the system with another identity to be used in the system, whereby the registration information and/or parameter of the terminal may be used in association with the another identity of the system.

According to a fourteenth aspect of the present invention, there is provided a mobile communications system in which communications terminals of the system are provided with identities and registration information and/or parameters for the purposes of registering with the communications system infrastructure, the system comprising: means for associating the registration information and/or parameter of a communications terminal of the system with another identity to be used in the system, whereby the registration information and/or parameter of the terminal may be used in association with the another identity of the system. . Again, as will be appreciated by those skilled in the art, these aspects of the invention can and preferably do include any one or more or all of the preferred and optional features of the invention described herein. Thus, for example, the^' terminal ' s registration information and/or parameters preferably comprises an authentication key, and/or is preferably temporarily associated with the identity in question, and that is preferably done by copying or referencing the communications terminal's registration information and/or parameters (e.g. authentication key) onto the identity in, e.g., a database of the system. Similarly, the identity with which the registration information and/or parameters (e.g. authentication key) of the terminal is associated preferably comprises a user identity or the identity of a, preferably portable and/or removable, device that may be coupled to and/or associated with the communications terminal . The registration information and/or parameters (e.g. authentication key) of the terminal is preferably used for the purpose of registering the another identity, e.g., and preferably, with the communications system infrastructure .

The communications terminal in the present invention can take any suitable or desired form. It is preferably a mobile terminal (mobile station) of a mobile communications system. The mobile station may, e.g., be portable or, e.g., vehicle mounted, etc., as is known in the art .

The various processes, etc., of the present invention to be carried out in or by the system infrastructure can be performed in any suitable and desired components of the system infrastructure. As discussed above they are preferably performed by a trust centre or centres and/or an authentication centre or centres of or associated with the system infrastructure. The trust centre (s) will typically be, as is known in the art, a control centre for end-to-end encryption and involved in key management. They typically act as agents that can transmit and receive (SDS) messages on behalf of an authentication centre. An advantage of using a trust centre for this purpose is that it can be addressed using short data service messages (e.g. SDS or SMS messages)^', thereby avoiding the complexity of coding new air-interface messages. A trust centre can be (and in the present invention preferably is) assigned an identity (e.g. an ITSI-type address) so that messages can be addressed directly to it, and interpreted accordingly.

In a preferred embodiment, the trust centre is line-connected (to the system infrastructure) and, preferably, the authentication keys are transferred in a sealed form. This has the advantage that the process can then be transparent to the core infrastructure. In such an embodiment, the trust centre is preferably connected (to the system infrastructure) in the same way as a dispatcher workstation, and/or via a dispatcher workstation.

It would also be possible, e.g., to use a trust centre connected via^' a mobile terminal in the same way, e.g., and preferably, to support terminals visiting a foreign network. In this case, the mobile terminal would, e.g., be able to support a small population of visiting terminals. Thus, in a preferred embodiment, the trust centre is connected (to the system infrastructure) via a mobile terminal.

On the other hand, it would be possible for the functions of the present invention to be performed by an authentication centre alone, e.g., and particularly, where the authentication centre can be addressed directly. In this case a trust centre (s) may not be required. The trust centre or other component may still need some information from an authentication centre of the system, and some operations (such as associating the identity (e.g. ITSI) of the smart card with the appropriate authentication key (e.g. the key K) ) may need to be performed by an authentication centre of the system infrastructure. In this case, the trust centre, etc . , can preferably communicate with the authentication centre outside the air-interface domain, e.g., by a physical link. Such communication also preferably does not use air-interface protocols, but uses some other form of communications protocol .

Thus, the trust centre may, e.g., be an independent element connected to the infrastructure (SwMI - Switching and Management Infrastructure) that has a secure link with an authentication centre or centres, or could, e.g., 'be an integral part of the authentication centre (s). The trust and/or authentication centre preferably, as discussed above, stores a database of identities (ITSIs) and, e.g., associated identities and/or serial numbers (e.g. of smart cards and/or users) .

As will be appreciated by those skilled in the art, the present invention can be applied equally whether a communications terminal and/or smart card, etc., is operating on its home network or is roaming and visiting a foreign (host) network other than that for -which it was provisioned. Where the terminal, smart card, etc., is on its home network, then in the normal course the various authentication and registration processes, etc., would be carried out on the home network and by the home network infrastructure.

However, in the case of a terminal or smart card, etc., that is visiting a host network, then while the authentication or registration procedures, etc., could be carried out on the host network, in a preferred embodiment some or all of those procedures are still carried out on the smart card's, etc., home network. In other words, the host infrastructure preferably asks the home infrastructure to perform the authentication and/or registration, etc.. In such an arrangement, the same mechanism is preferably used to register the smart card's identity (ITSI), and then any association between the identity (ITSI) and authentication key, K, is preferably performed in the home infrastructure (e.g. in an authentication centre of the home infrastructure) . To facilitate this, a new message may then have to be sent between the host and home infrastructures in order for the host infrastructure to inform the home infrastructure that the terminal wishes to associate its own authentication key K, with the smart card's identity (ITSI) . Other arrangements and embodiments of the invention where a terminal, smart card, etc., is on a host network, rather than its home network, preferably operate^' in an analogous manner.

As will be appreciated by those skilled in the art, other alternative and preferred features of the present invention can also be implemented if desired.

For example, the smart card may refuse to perform trunked mode operation encryption but agree to perform direct mode operation encryption if no authentication has taken place. It is also preferred for the smart card to be able to inform the user, e.g., via a proactive message, if that card has been used by a different terminal, or if authorisation with a terminal has previously failed. This may demonstrate that an unauthorised access has been attempted.

A further preferred security measure is for the smart card and/or the terminal, etc., to log all, or all failed, access or registration attempts, e.g., on demand by the authorised user or personnel, e.g., via the terminal or by other equipment. Such a log could, e.g., wrap over a period of time, erasing the oldest entries. In a preferred embodiment, failures are preferentially preserved in the log, as these may be indicative of an attack. The smart card, etc., can also preferably provide evidence of tampering over the air to an authentication or trust centre, e.g., and preferably either proactively or on demand from the infrastructure.

In a preferred embodiment, validation of the smart card, device or user, etc., by the network infrastructure is required before access is given to stored mail messages, phonebook entries, etc.. Most preferably the terminal will refuse to operate with its own identity or demand a further authentication (e.g. PIN) entry should authentication of the smart card, etc., with the infrastructure fail. This would help to protect the terminal against attack by use of a "spoof" smart card (whereby entry of a known PIN on a spoof smart card, etc., could allow access to a stolen terminal) even where the terminal puts all its trust in the validity of the smart card, etc., to protect access to the terminal .

It would also be possible, for example, that some part of the authentication process may implicitly prove that the user has gained authorised access to the terminal, e.g., by entering a PIN to satisfy the smart card. This would be the case if the smart card only performs authentication once PIN entry has been successfully completed. It would be possible in these circumstances to take the successful PIN entry as being implied authority to use a smart card, such that entry of another PIN, collar number or other information may_. not be required. However, in that case that could leave the terminal susceptible to attack by use of a "spoof" smart card. Thus in a preferred embodiment, even in these circumstances, the infrastructure will request additional proof that the user is an authorised person, for example in the form of a demand for additional identifying or authorisation information.

In a particularly preferred embodiment, a record is maintained of whether a given smart card, device, or user, etc., has previously successfully authenticated with the system infrastructure in conjunction with the Communications terminal in question. Most preferably, such a successful "binding" of a terminal and smart card, etc., is verified by both the terminal and the smart card, etc., for security purposes.

In such an arrangement, the smart card, etc., will preferably only be allowed to operate with the terminal, and the terminal only operate with the card, if the card has previously successfully authenticated with the infrastructure in conjunction with that terminal.

Similarly, it is preferred to allow a smart card to perform direct mode operation work with a terminal if it can identify that terminal as having successfully participated in a successful authentication with the card in the past.

Preferably, an authentication process is used to verify the binding (i.e. previously successful authentication) of the smart card, etc., and terminal combination with the infrastructure. This would help to protect against use with a "spoof" terminal. Such a verification process could be achieved, for example, by using public-key cryptography or signature software, without transporting the shared secret in clear across the potentially vulnerable smart card and terminal interface.

In a preferred embodiment, the terminal and/or smart card, etc., can and does demand the entry of authentication data, such as a PIN, from the user, which is not based on the smart card, before allowing the terminal and card to operate. This would help to protect against the possibility of a stolen terminal being combined with a spoof smart card in order to bypass PIN entry, and the attacker then possibly substituting the valid smart card in an attempt to gain access to the terminal's normal, e.g., DMO, services or to gain access to the genuine smart card's services. In a preferred embodiment, which can also help to protect the terminal from being used in DMO with a "spoof" smart card, the terminal observes the PIN entry by the user to the smart card and records, via a one-way function, a value which can be reproduced and compared each time PIN entry is performed. The observed PIN is preferably processed in such a way as to make it impossible for the original PIN to be recovered by an attack on the terminal. Validation of the observed PIN (or the value derived from one-way processing of the PIN) would then occur when the terminal observes that the smart card has successfully authenticated with the infrastructure .

The communications system of the present invention can be any suitable such system. The present invention is particularly, but not exclusively, applicable to mobile communication systems, such as the TETRA system. Thus the present invention also extends to a communications terminal and to a method of operating a communications terminal of a mobile communications system, and to a mobile communications system and a method of operating a mobile communications system, that is in accordance with and/or that can be operated in accordance with, the present invention. The mobile communications system is preferably a TETRA system.

As will be appreciated by those skilled in the art, all of the aspects and embodiments of the present invention described herein can and preferably do include, as appropriate, any one or more or all of the preferred and optional features of the invention described herein.

The methods in accordance with the present invention may be implemented at least partially using software e.g. computer programs. It will thus be seen that when viewed from further aspects the present invention provides computer software specifically adapted to carry out the method or a method herein described when installed on data processing means, a computer program element comprising computer software code portions for performing the method or a method herein described when the program element is run on data processing means, and- a computer program comprising code means adapted to perform all the steps of a method or of the methods herein described when the program is run on a data-processing system. The invention also extends to a computer software carrier comprising such software which when used to operate a communications system or terminal comprising data processing means causes in conjunction with said data processing means said system or terminal to carry out the steps of the method of the present invention. Such a computer software carrier could be a physical storage medium such as a ROM chip, CD ROM or disk, or could be a signal such as an electronic signal over wires, an optical signal or a radio signal such as to a satellite or the like. It will further be appreciated that not all steps of the method of the invention need be carried out by computer software and thus from a further broad aspect the present invention provides computer software and such software installed on a computer software carrier for carrying out at least one of the steps of the methods set out herein.

The present invention may accordingly suitably be embodied as a computer program product for use with a computer system. Such an implementation may comprise a series of computer readable instructions either fixed on a tangible medium, such as a computer readable medium, for example, diskette, CD-ROM, ROM, or hard disk, or transmittable to a computer system, via a modem or other interface device, over either a tangible medium, including but not limited to optical or analogue communications lines, or intangibly using wireless techniques, including but not limited to microwave, infrared or other transmission techniques. The series of computer readable instructions embodies all or part of the functionality previously described herein. Those skilled in the art will appreciate that such computer readable instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Further, such instructions may be stored using any memory technology, present or future, including but not limited to, semiconductor, magnetic, or optical, or transmitted using any communications technology, present or future, including but not limited to optical, infrared, or microwave. It is contemplated that such a computer program product may be distributed as a removable medium with accompanying printed or electronic documentation, for example, shrink-wrapped software, pre-loaded with a computer system, for example, on a system ROM or fixed disk, or distributed from a server or electronic bulletin board over a network, for example, the Internet or World Wide Web.

A number of preferred embodiments of the present invention will now be described by way of example only. The preferred embodiments of the invention will be described with particular reference to a TETRA mobile communications system. However, as discussed above, while the present invention is particularly applicable to TETRA mobile communications systems, as will be appreciated by those skilled in the art, it is not exclusive to those systems and can be applied to other mobile communications systems and communications systems equally.

In the present embodiments, a mobile station of a TETRA communications system has installed in its SIM card socket a so-called TETRA "smart card" which is to be used for end-to-end encryption purposes, etc.. The smart card has its own personal individual subscriber identity (ITSI) and associated authentication key, K, so that the user (smart card) can be identified independently of the mobile station in which it is installed. This allows, for example, the user to be identified and to be communicated with via the identity ^■ of the smart card, irrespective of which mobile station the smart card is actually installed in.

As is known in the art, in order for communications to be directed to a smart card in a TETRA mobile station, it is first necessary for the smart card to be registered (and, e.g., authenticated) with the TETRA system infrastructure.

As is known in the art, and as intended herein, registration refers to the process of allowing the system infrastructure to route calls and signalling to the communications terminal, smart card, etc., e.g., allowing the ^'system to identify and locate the terminal, and to become aware of its existence, etc.. Authentication refers to the process of verifying that the communications terminal, smart card, etc., is authentic and, e.g., entitled to connect to the infrastructure (and may, e.g., typically take place after registration) , ,A first preferred embodiment for carrying out this registration process in accordance with the present invention will now be described.

In this embodiment, the mobile station first interrogates the installed smart card to determine whether it has been changed. To do this, the mobile station reads the smart card's serial number or the smart card's stored ITSI, or both, from the card.

If the smart card has not changed, the mobile station then simply proceeds to register using the individual subscriber identity (ITSI) of the smart card and authenticates using the smart card's authentication key K, using the normal TETRA registration and authentication procedures . The mobile station may read the ITSI of the smart card directly, or may read the card's serial number and remember the ITSI from a previous session.

On the other hand, if the mobile station determines that the mobile station has not preferably registered on behalf of the smart card before (e.g. because the smart card has been changed) , the mobile station then first connects to and. registers with the infrastructure using its own ITSI and authentication key K. The mobile station may also at this point check with the user as soon as it detects the presence of a new or different smart card to alert the user to that fact. Once the mobile station has itself registered with the system infrastructure, it then sends a request for registration information about the smart card to the system infrastructure. In the present embodiment, the registration information that is requested comprises the authentication key, K of the smart .card, although other information necessary for its authentication would be possible, if desired.

To request the authentication key K of the smart card from the system infrastructure, the mobile station transmits with its request a unique piece of information about the smart card, which in the present embodiment comprises the ITSI or the serial number of the smart card, to a trust centre of the system infrastructure. In the latter case, the system will rely on the lifetime association of the serial number, ITSI and authentication key K of the smart card that will be recorded at the trust centre when the smart card is programmed.

The trust centre is an extension of the authentication centre of the infrastructure, or may, e.g., be connected to the authentication centre via a secure link. It can be protected by any means required, including physical security. It could be, e.g., a single centre on the system infrastructure, or there could be plural such centres. The trust centre (s) could be arranged in a distributed fashion, if desired.

The trust centre has access to the individual subscriber identities (ITSIs) and authentication keys K of the mobile stations and smart cards, and may also, as discussed above, be able to translate from a smart card's serial number to the smart card's ITSI and/or authentication key K.

In the present embodiment, this registration information request is sent using a new message inside a TETRA SDS message. This message is encrypted using the mobile station's encryption key (e.g. using the SCK (static cipher key) or preferably the DCK (derived cipher key) of the mobile station) .

Alternatively, a new TETRA signalling message at the same level as the existing registration and authentication signalling could be used.

In the case where the mobile station is out of range of the TETRA infrastructure and is operating in direct .mode operation, and the mobile station can still register with the system infrastructure even though it is in direct mode operation, the mobile station will instead make the smart card registration information request via an encrypted SDS message sent through a gateway into the infrastructure. This is useful because the smart card may need to be moved into a mobile station that is currently using direct mode operation, and the mobile station may be inhibited from normal operation until the smart card has been identified and authenticated by the trust centre. This would also enable the user to be contacted from the fixed infrastructure, because the gateway could now register the smart card's (and therefore the user's) presence using existing TETRA gateway registration methods. Upon receipt of the registration information request from the mobile station, the trust centre of the infrastructure then sends the authentication key K (and, if necessary, the ITSI, e.g., where the mobile station makes the request using the serial number of the smart card, rather than its ITSI) of the identified smart card to the mobile station. The trust centre uses the authentication key K of the mobile station or a key derived therefrom, to seal the authentication key K, etc., of the smart card, so that only the requesting mobile station can unseal the authentication key K, etc., of the smart card. In this embodiment, the TETRA TAAl authentication algorithm is used to seal the authentication key K of the smart card. The standard TAAl algorithm process may be modified for this purpose, for example to split the authentication key K into two pieces and then sealing each part separately with the TAAl algorithm and sending each part separately. (This may be necessary if the authentication key K is longer (it is typically 128 bits long) than the key that the standard TAAl algorithm process can seal (currently 80 bits).) Alternatively, a modified version of the TAAl algorithm, or a different algorithm could be used, if desired (in this case, it may be necessary for the terminal's authentication key, K, to be used to perform this sealing operation, so that the terminal can unseal the smart card's key, K, on receipt) .

Once the mobile station has received the authentication key K (and, e.g., the ITSI, if necessary) of the smart card from the trust centre of the system infrastructure, the mobile station can then unseal that key (and the identity, if necessary) , using the appropriate unsealing algorithm (such as the TAAl authentication algorithm, or a modified version of that algorithm or a new algorithm) .

The mobile station preferably unseals the received authentication key K, etc., of the smart card in a secure area, for example in the same way as sealed air interface keys are unsealed. In the present embodiment this is done by storing the authentication key K of the mobile station, the authentication key K of the smart card, and the TAAl (or other) authentication algorithm in a secure processing means or device (such as a microprocessor, digital signal processor (DSP) or a custom made integrated circuit with appropriate security controls for preventing egress of sensitive information) and such that they are never exposed outside this processing means. In this way, the received authentication key K of the smart card is protected in the same way as the authentication key K of the mobile station.

Once it has received the authentication key K from the trust centre, if required by the infrastructure, or if the mobile station or user chooses, the mobile station then de-registers at this point in order to assume the identity of the smart card. In the present embodiment this happens automatically, and is initiated by the mobile station, so that the user is not aware of the process. Alternatively, the mobile station could ask the user for permission before de-registering, so as to provide a check that the user is aware that the smart card has been changed. The user could also be prompted for a, code entry, e.g. a PIN, at this stage (or at some earlier stage) , to be validated by the smart card. This would provide a check that an authorised user has inserted the smart card in the mobile station. Once the mobile station has unsealed the authentication key K for the smart card sent by the trust centre and, if necessary, de-registered, the mobile station can then perform a normal registration but assuming the identity of the smart card (i.e. using the ITSI and authentication key K of the smart card, which the mobile station now has) . The mobile station can then operate normally using the identity of the smart card, using the authentication key K of the smart card to generate air interface-derived encryption keys, and seal keys transmitted by over the air re-keying and over the air control signals such as disable, etc.. The user can be contacted directly via the ITSI of the smart card. This enables, for example, the user to be called on whichever mobile station he happens to be using at the time.

It should be noted here that as this registration process is only followed when the mobile station determines that the smart card has been changed, the additional registration steps in this embodiment are only required once per terminal-card pairing, and so should be a relatively rare event. In an alternative embodiment, the trust centre of the system infrastructure, rather than returning the authentication key K as the registration information to the requesting mobile station, instead returns the identity (ITSI) of the smart card to the mobile station (where, e.g., the mobile station makes the request using the serial number of the smart card, rather than its ITSI) , together with an indication that the mobile station is authorised to register using the smart card's ITSI, or, alternatively, where, for example, the mobile station has already sent the ITSI in its request, simply returns a confirmation to the mobile station that it may now register with the ITSI of the smart card (which the mobile station in this case would already know) .

In this case the trust centre also operates to associate the mobile station's authentication key K with the ITSI of the identified smart card, so that the mobile station will then use the authentication key K of the mobile station together with the ITSI of the smart card for registration and authentication purposes. It may also, if required, provide this association to the authentication centre of the infrastructure so that the authentication centre is then aware of the association.

This arrangement avoids the need to transmit at all over the air interface the authentication key K of the smart card. Furthermore, since the mobile station will use its own authentication key K with the identity

(ITSI) of the smart card when registering as the smart card, the smart card would not then in fact need even to store or use at all its own interface authentication key K. In another preferred embodiment, rather than the mobile station simply transmitting the identity of a smart card and receiving registration information or a registration permission in response thereto, the system also or instead operates to allow the trust centre to first authenticate the smart card. This will provide, for example, improved protection against forms of attack where, for example, a malicious user simply transmits the serial number of a smart card which is not actually present. In this embodiment, instead of simply transmitting the sealed 'authentication key K of the smart card or associating the authentication key K of the mobile station with the identity (ITSI) of the smart card, the trust centre first sends a random challenge to the smart card via the mobile station. In response to this challenge, the smart card generates and sends a response based on its own unique secret key (which is known by the trust centre) . The response is then checked by the trust centre in order to authenticate or not the smart card. If the smart card is authenticated by its response to the challenge, then the trust centre can _

proceed to transmit the authentication key K of the smart card (or any other desired authentication key) to the mobile station, or simply associate the authentication key K of the mobile station with the identity of the smart card, as above. However, in this case there would first be a check that the smart card is authentic.

In this arrangement, the smart card would contain its own authentication key KC, that is known only to the card and the trust centre of the infrastructure, in order to enable the trust centre to check the card's presence and validity.

The authentication challenge could comprise, for example, the authentication centre or trust centre of the system infrastructure sending back a randomly chosen number (e.g. 64 bits or 128 bits long) as a challenge. The mobile station would then pass this challenge into the smart card, and the smart card would encrypt the challenge using its secret authentication key KC and an internal encryption algorithm. (This algorithm could, for convenience be the normal encryption algorithm for which the card is provided, or could be an independent algorithm only for this purpose. The latter may be beneficial in that normal encryption algorithms could then be changed in use, without the need to make changes or use multiple algorithms in the authentication centre) .

The encrypted challenge would then be sent by the mobile station as a response back to the authentication centre or trust centre, for the authentication centre or trust centre to check its validity. The response could include, for example, the four least significant bits of the challenge to link the response to the challenge. In these arrangements, the smart card secret key used for the authentication challenge would only be used to generate a response to the infrastructure challenge, and therefore need not be broadcast outside the smart card, nor would it need to be related in any way to any authentication key K of the smart card or mobile station. 'If the response to the challenge is found to be valid, the authentication centre could then effectively authorise the smart card and, e.g., send to the mobile station the identity (ITSI) of the smart card corresponding to the smart card's serial number. In this arrangement, once the smart card is authenticated, the trust centre could also send back the authentication key K for the smart card, but could also, in the alternative, send a different authentication key K that it associates with the card's ITSI. This would allow the trust centre to change the authentication key K for the card (its ITSI) whenever the card re-registers, for example on a random basis.

Alternatively, the trust centre could in fact send no authentication key K over the air interface, but instead copy or link the mobile station's authentication key K to the identity (ITSI) of the authenticated smart card in the authentication centre's database. Then when the mobile s'tation re-registers as the smart card (using the smart card's ITSI), it would use its own authentication key K with the smart card's ITSI. In an alternative arrangement, the initial registration, challenge and response could be done more directly (i.e. with the mobile station acting as an intermediary, for transmitting and receiving the SDS messages, but not looking inside them, except to note that the received SDS message (e.g. its protocol identifier) indicates that the message should be passed into the smart card) between the smart card and the trust centre by having the card create an SDS message for the authentication centre that it asks the mobile station to send. The authentication centre would then send the challenge to the smart card in an SDS message, with the card sending its response in an SDS message back. The authentication centre would then send the smart card's ITSI to the mobile station. A further refinement of these arrangements would be to make the authentication mutual, such that there is basically a challenge-challenge-response protocol between the trust centre in the infrastructure and the smart card. Only once mutual authentication has been successfully performed would the smart card then allow end-to-end encrypted calls and the infrastructure permit registration and use of the smart card on the network. In a preferred embodiment where an authentication challenge to the smart card can be made by the trust centre (system infrastructure) , then the system infrastructure can preferably test a smart card in this way whenever it desires, for example periodically, or on the occurrence of particular, preferably predetermined, events, such as each time the mobile station is activated or the card is registered with the system.

This would help to reduce the risk that a mobile station may be spoofed into thinking that the same smart card is still active and installed within it, even after' the original smart card has been removed. For example, if the smart card is replaced by another smart card that presents the same serial number (i.e. a clone) while the terminal is powered off, the terminal (and user) may not observe that the smart card has been replaced. Allowing the infrastructure (e.g. trust centre) to re-authenticate the smart card any time it chooses (e.g. by the user registration (activation) protocol including a means for the infrastructure to initiate an authentication of the card) will help to guard against this. In a preferred embodiment, if, at power-on, the communications terminal observes that the smart card does not appear to have changed, the terminal conducts a local challenge of the smart card using challenge and response values observed and recorded during initial authentication of the smart card. If the smart card's response differs from the recorded response, the terminal alerts the user and initiates a full reactivation of the smart card connection. Although this arrangement does not provide guaranteed protection against covert smart card replacement, it means that any attacker has to record the exchanges on ^' the present smart card-terminal interface and store the response in the replacement (cloned) smart card before he can insert the cloned smart card in the terminal . (This is because whereas the smart card's serial number is independent of the communications terminal and can be recorded from the card at any time, the challenge and response is particular to the smart card and terminal pair and can only be recorded on the smart card and terminal interface in question) . It would also be possible for the terminal's

"local" challenge to the smart card to, e.g., use a public-key encryption exchange, e.g., based on verifying that the card is one that has been successfully authenticated in the past. Other arrangements would, of course, be possible.

It is also preferred for the smart card to detect a communications terminal change by reading the terminal ' s identity (e.g. TEI) at power-up and comparing it with a previously stored value. If the smart card detects a terminal change (e.g. by this method or by a cryptographic method) , it refuses to operate or offers only limited service's until it has authenticated the system infrastructure again. This will help to protect a smart card against unauthorised removal into a different communications terminal. ^• As is known in the art, TETRA systems can operate in what is known as "direct mode", i.e. where terminals communicate directly with each other. The present invention can be applied to such direct mode operation, and in this case, the following features are preferred and/or preferably taken into account.

Firstly, if the smart card is inserted in the communications terminal when the terminal is in range of the V+D (trunked, voice+data) system, the terminal can collect its encryption keys (e.g. SCKs) for use in direct mode operation (DMO) , and any end-to-end encryption keys in the normal way.

On the other hand, if the communications terminal powers-up in DMO after the smart card is inserted, or the terminal is switched to DMO before the attachment of the smart card to the terminal has been activated, it may not be possible to register the smart card and so the terminal may be unable to use the smart card's , identity in DMO (unless the terminal, e.g., can read the smart card's identity (ITSI) directly from the smart card) . In such a situation, the smart card could, e.g., be configured to refuse to supply its identity to the terminal (such that registration would not be possible) , or it could, e.g., be permitted to supply its identity (without prior authentication) only in these circumstances, so that registration can still occur in this situation.

If the communications terminal has been previously used in DMO by another user from the same group, the terminal may already hold the required encryption keys

(SCKs) , so the terminal may use DMO air-interface encryption. However, the terminal may be unable to use end-to-end encryption in DMO unless the smart card already stores the relevant end-to-end encryption keys, or it is possible for the smart card to receive OTAK

(over-the-air keying) messages in DMO. The smart card may also be able to derive encryption keys by communicating by short message (SDS) service with the smart card at the other end of the direct mode radio link. It would also be possible to (and may be desirable to) permit the smart card to operate without authentication in DMO, e.g., and preferably, with some limit on its capabilities. This might be desirable where it is not possible to authenticate the smart card in direct mode operation.

Additionally or alternatively, the smart card registration, authentication and activation protocol could be implemented via SDS signalling. This would provide a mechanism to activate and authenticate a smart card via a DMO gateway.

As will be appreciated from the above, in a particularly preferred embodiment of the present invention, the system will operate as follows when it is desired to register a smart card with the system. The communications terminal will first register as itself with the communications system and then commence the message exchange by sending the system infrastructure (e.g. trust centre) a user activation request message (PDU) containing the smart card's identity e.g., ITSI or, preferably, serial number. If the system infrastructure recognises the identity (e.g. ITSI or serial number), it (e.g., the trust centre) sends the terminal a challenge for the smart card. (This is to ensure that the indicated smart card is truly present in the terminal.) The. communications terminal passes on the challenge to the smart card via the unencrypted communications terminal interface and receives a response from the smart card-terminal which the terminal sends back to the trust centre, etc.. If the system (e.g. trust centre) decides that it received the correct response, the trust centre, etc., instructs the authentication centre to associate the communications terminal's authentication key K with the smart card's identity (ITSI) (e.g. by copying the terminal's key, K, or cross referencing it) . When this has been completed, the, e.g., trust centre sends the communications terminal a user activation result message (PDU) that contains the smart card's identity (ITSI) and indicates that the SwMI (Switching and Management Infrastructure) has activated the attachment of the user to the communications terminal.

When the communications terminal receives a successful user activation result message (PDU) , it de-registers its own identity (ITSI) and registers and authenticates using the smart card's identity (ITSI) and the communications .terminal's authentication key K. A delay is preferably imposed between de-registration of the terminal and registration of the user (smart card) to further obscure the link between the terminal and user (smart card) . The communications terminal can now operate normally using the identity of the smart card and the authentication key, K, of the terminal to, e.g., generate a derived cipher key (DCK) , unseal keys received by OTAR (over the air rekeying) and authenticate over-the-air signalling such as enable/disable of the smart card's identity (ITSI) or the communications terminal's identity (TEI). The user can be contacted directly via the identity (ITSI) of the card. This enables the user to be called by his own identity (ITSI), no matter which communications terminal he or she is using at the time.

If the trust centre objects to the proposed activation (e.g. if the smart card identity (e.g. serial number) was invalid or recorded as stolen, or restricted to certain specific communications terminals), it can ask the infrastructure to disable the communications terminal, or it could proceed with the activation and then arrange for the smart card to be sent a disabling, e.g., "stun", OTAK message, or the infrastructure (e.g. trust centre) could simply reject or ignore the request. The system infrastructure (trust centre) knows

(from the transaction with the communications terminal) which terminal is associated with the smart card identity, so if any security breach or theft takes place, both the terminal and smart card can be identified and disabled.

As discussed above, the techniques of the present invention, at least in its preferred embodiments, also offer a method of providing user portability between communications terminals by the process of temporarily copying or referencing the communications terminal's authentication key K onto the user's identity (ITSI) within the authentication centre's database. Any portable electronic device carrying a user identity or user serial number can use this method. In such arrangements, the authentication algorithm to be used in the device is preferably standardised (e.g. by specifying TAlI and TAl2, instead of AES) . It would also be possible to configure the registration and authentication process to permit a PIN to be sent back to the trust centre as an alternative to the authentication challenge response. That would then allow manual entry of a user serial number with manual authentication by PIN to register a user on the system. Addition of a manual method of activating temporary K duplication in the authentication centre might also provide a means of overcoming present difficulties surrounding the RUSRN/Aliassing mechanism in TETRA. The process of temporarily copying the terminal's authentication key K onto the user's identity (ITSI) makes it unnecessary for the TETRA. base stations to check every incoming identity (ITSI) for an alias - only the authentication centres are affected, and only during authentication.

It can be seen from the above that the present invention provides an arrangement whereby a mobile station can obtain registration for a smart card (e.g. encryption module), user, etc., in a secure and controllable fashion.

The present invention, in its preferred embodiments at least, can avoid, for example, the need to transfer the authentication key K of the smart card across the subscriber identity module interface (and accordingly avoids the need for the use of encryption across this interface and for long-term vulnerable, sealing keys for this purpose) . It can also, in some embodiments at least, avoid the need to transmit the authentication key K over the air-interface, and, indeed, for that key to be stored or used by the smart card at all.

The present invention can also be used to avoid limitations as to who manufactures radios to interface with a smart card. There can also in preferred embodiments of the invention be no need for core infrastructure (e.g. SwMI) modifications, or for any changes to the card software, or for extra loading on the card interface (e.g. to encrypt the link), or for extra work configuring a smart card (e.g. to provision common cipher keys) .

In the preferred embodiments at least, all permissions are under control of a trust centre of the system infrastructure which can be protected by any means required, including physical security.

The trust centre knows (from the transaction with the mobile station) which mobile station is associated with which smart card and/or user identity, so if any security breach or theft takes place, both the mobile station and smart card or user can be identified and disabled if required. For example, if a requesting mobile station is marked as stolen or unauthorised to use the smart card, it can be disabled or refused the requested information. Similarly, if a mobile station requests information about a stolen smart card, the mobile station can be disabled, or can even be asked to disable the smart card. If a radio is suspect, it can be wiped from the authentication database.

This is a significant advantage over a technique where, for example, the smart card would deliver its authentication key K and identity ITSI directly into a mobile station, because in those methods, the trust centre of the infrastructure would not know which communications terminal the smart card is using at any time . The trust centre can also control which mobile stations are permitted to use a smart card or can be used by a given user. An ability to control which mobile stations are permitted to use which smart cards, etc., is desirable, for example, for compatibility problems, security approval of radio types, preventing use of a smart card outside a radio owned by the card user's organisation, for billing purposes, etc..

Furthermore, even if the trust centre does not restrict which mobile stations may be used by a smart card or user, the trust centre can still identify and record which mobile station is being used, which may be useful for tracking stolen mobile stations and vehicles, and for gathering evidence, etc..

If the mobile station asks for information about the smart card by serial number, the pairing of the smart card's ITSI with its authentication key K is not revealed by the request/reply transaction. Furthermore, as the terminal re-registers using the ITSI of the smart card, there is no detectable association with the mobile station which requested the information. This makes it difficult for any malicious users to associate the authentication key K of the smart card with the smart card itself.

Claims

CLAIMS :

1. A method of registering an identity with the network infrastructure of a mobile communications system, the method comprising: a communications terminal first registering itself with the communications system infrastructure; the communications terminal, once registered with the communications system infrastructure, exchanging messages relating to the identity to be registered with the system infrastructure; and the communications terminal, once it has completed the message exchange with the system infrastructure, registering with the system infrastructure the identity to be registered.

2. The method of claim 1, wherein the message exchanging step comprises: the communications terminal transmitting information relating to the identity to be registered to the system infrastructure.

3. The method of claim 1 or 2 , wherein the message exchanging step comprises: the system infrastructure providing registration information relating to the identity to be registered to the communications terminal .

4. The method of claim 3, wherein the registration information provided to the communications terminal comprises an authentication key and/or an identifier for the identity to be registered.

5. The method of any one of the preceding claims, comprising the system infrastructure associating the - -

identity to be registered with registration information used to register the communications terminal.

6. The method of claim 5, wherein the registration information used to register the communications terminal comprises an authentication key.

7. The method of any one of the preceding claims, wherein the message exchanging step further comprises encrypting the messages that are exchanged.

8. The method of any one of the preceding claims , wherein the message exchanging step further comprises

/ the system infrastructure authenticating the communications terminal and/or the identity to be registered.

9. The method of any one of the preceding claims, further comprising the communications terminal de- registering itself from the communications system infrastructure prior to registering with the system infrastructure the identity to be registered.

10. A method of operating a mobile communications system in which communications terminals of the system are provided with identities and registration information for the purposes of registering with the communications systems infrastructure, the method comprising: associating an authentication key for a communications terminal of the system with another identity to be registered in the system, whereby the authentication key of the terminal may be used in association with the another identity of the system.

11. The method of any one of the preceding claims, wherein said identity to be registered comprises the identity of a smart card that is associated with or coupled to the communications terminal.

12. The method of claim 11, further comprising the communications terminal interrogating the smart card and/or the smart card interrogating the communications terminal to determine if the other has changed.

13. The method of any one of claims 1 to 10, wherein the identity to be registered comprises the identity of a user of the communications terminal .

14. The method of claim 13, further comprising the communications terminal interrogating the user to determine if the user has changed.

15. A communications terminal for use with a mobile communications system, the communications terminal ■ comprising: means for registering itself with the communications system infrastructure; means for, once registered with the communications system infrastructure, exchanging messages with the system infrastructure relating to an identity to be registered with the system infrastructure; and means for, once it has completed the message exchange with the system infrastructure, registering with the system infrastructure the identity to be registered.

16. The communications terminal of claim 15, wherein the means for exchanging messages with the system infrastructure comprises means for providing the system ZJ O

infrastructure with information relating to the identity to be registered.

17. The communications terminal of claim 15 or 16, further comprising: means for authenticating itself and/or the identity to be registered with the system infrastructure.

18. The communications terminal of claim 15, 16 or 17, further comprising: means for encrypting the messages exchanged with the system infrastructure.

19. The communications terminal of any one of claims 15 to 18, further comprising: means for, once it has completed the message exchange with the system infrastructure, de-registering itself from the communications infrastructure prior to registering with the system infrastructure the identity to be registered.

20. The communications terminal of any one of claims 15 to 19, wherein said identity to be registered comprises a smart card that is associated with or couplable to the communications terminal.

21. The communications terminal of claim 20, further comprising: means for interrogating the smart card to determine if the smart card has changed.

22. The communications terminal of claim 20 or 21, further comprising a smart card, said smart card comprising: means for interrogating the communications terminal to determine if the communications terminal has changed. - -

23. The Communications terminal of any one of claims 15 to 19, wherein the identity to be registered comprises the identity of a user of the communications terminal .

24. The communications terminal of claim 23, further comprising: means for interrogating the user to determine if the user has changed.

25. The communications terminal of any one of claims 15 to 24, wherein the communications terminal is for use in a TETRA mobile communications system.

26. A mobile communications system, comprising: a system infrastructure; and one or more communications terminals as claimed in any one of claims 15 to 25; the system infrastructure comprising means for registering a communications terminal or an identity using information provided by a communications terminal for that purpose.

27. The mobile communications system of claim 26, wherein the system infrastructure further comprises means for providing registration information relating to an identity to be registered to the communications terminal .

28. The mobile communications system of claim 27, wherein the means for providing registration information relating to the identity to be registered comprises means for providing an authentication key, and/or an identifier for the identity to be registered, to the communications terminal.

29. The mobile • Communications system of claim 26, 27 or 28, wherein the system infrastructure further comprises means for associating the identity to be registered with registration information used to register the communications terminal .

30. The mobile communications system of claim 29, wherein the means for associating the identity to be registered with registration information used to register the communications terminal comprises means for associating the identity to be registered with an authentication key of the communications terminal .

31. A mobile communications system in which communications terminals of the system are provided with identities and authentication keys for the purposes of registering with the communications system infrastructure, the system comprising: means for associating an authentication key for a communications terminal of the system with another identity to be registered in the system, whereby the authentication key of the terminal may be used in association with the another identity of the system.

32. The mobile communications system of any one of claims 26 to 31, wherein the mobile communications system is a TETRA mobile communications system.

33. A computer program element comprising computer software code portions for performing the method of any one of claims 1 to 14 when the program element is run on data processing means.

34. A. method of registering an identity with the network infrastructure of a mobile communications system substantially as hereinbefore described.

35. A method of operating a mobile communications system substantially as hereinbefore described.

36. A communications terminal for use with a mobile communications system substantially as hereinbefore described.

37. A mobile communications system substantially as hereinbefore described.