[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

EP2047704A2 - Systémes de communications mobiles - Google Patents

Systémes de communications mobiles

Info

Publication number
EP2047704A2
EP2047704A2 EP07766424A EP07766424A EP2047704A2 EP 2047704 A2 EP2047704 A2 EP 2047704A2 EP 07766424 A EP07766424 A EP 07766424A EP 07766424 A EP07766424 A EP 07766424A EP 2047704 A2 EP2047704 A2 EP 2047704A2
Authority
EP
European Patent Office
Prior art keywords
identity
smart card
communications
terminal
infrastructure
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP07766424A
Other languages
German (de)
English (en)
Inventor
Andrew Lain Nicol
Mark Wentworth Rayne
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sepura Ltd
Original Assignee
Sepura Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB0615449A external-priority patent/GB0615449D0/en
Priority claimed from GB0618223A external-priority patent/GB0618223D0/en
Application filed by Sepura Ltd filed Critical Sepura Ltd
Publication of EP2047704A2 publication Critical patent/EP2047704A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/062—Pre-authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/71—Hardware identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • H04W76/45—Connection management for selective distribution or broadcast for Push-to-Talk [PTT] or Push-to-Talk over cellular [PoC] services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/08—Trunked mobile radio systems

Definitions

  • the present invention relates to mobile communications systems, and in particular, but not exclusively, to the TETRA (TErrestrial Trunked RAdio) system.
  • TETRA TErrestrial Trunked RAdio
  • 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.
  • ITSI subscriber identity
  • K authentication key
  • the authentication key K can be and is also used to derive encryption keys .
  • 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 .
  • SIM subscriber identity module
  • 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.
  • ITSI identity
  • an authentication key that can be used to register the smart card with the system infrastructure.
  • the communications terminal 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.
  • 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.
  • 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.
  • a method of registering a smart card of a mobile communications system with the network infrastructure of the communications system 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 infrastructure e.g. an authentication or registration centre of the communications system infrastructure
  • ITSI authentication or registration centre of the communications system infrastructure
  • K authentication key
  • 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.
  • SMS or SDS messages e.g. comprise a new message inside a short data message of the communications system.
  • the exchanged messages are preferably sent in an encrypted form.
  • air-interface encryption is used.
  • 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.
  • the system infrastructure e.g. trust or authentication centre
  • K 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.
  • K an authentication key
  • 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.
  • the message (s) may be and preferably is unsealed in a secure area in the same way as sealed air interface keys are unsealed.
  • the encryption (a ⁇ thentication) algorithms that are used to seal and unseal the messages may be any suitable and desired such algorithms.
  • the standard authentication algorithms 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) .
  • 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
  • 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.
  • ITSI unique identity
  • K authentication key
  • 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 .
  • 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.
  • 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) .
  • the registration information for the smart card that the communications terminal requests from and receives from 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.
  • this registration information preferably comprises the authentication key, K, associated with the smart card.
  • the system infrastructure e.g. trust centre
  • the identity e.g. ITSI in TETRA
  • the communications terminal sends the serial number, rather than the ITSI, of the smart card to the system infrastructure.
  • 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.
  • the system infrastructure could also return the authentication key K of the smart card to the communications terminal.
  • the system could return an authentication key K that is, e.g., simply to be used for this session, e.g., selected on a random' basis .
  • the system infrastructure
  • the system 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.
  • the system infrastructure sends registration information
  • 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.
  • 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) .
  • the smart card e.g. ITSI
  • 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) .
  • 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.
  • a truncated or short-form identity such as the individual short subscriber identity (ISSI) in TETRA
  • any references to identities, etc., herein are intended to encompass and include such short- form identities as appropriate.
  • ITSI individual short subscriber identity
  • 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.
  • ISSI individual short subscriber identity
  • ISSI individual short subscriber identity
  • ISSI 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 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.
  • the communications terminal knows (and transmits) the identity (ITSI) of the smart card.
  • 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 .
  • 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.
  • the smart card and system infrastructure e.g. trust centre
  • the smart card and system infrastructure 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.
  • an authentication challenge such as a random number
  • 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
  • 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 .
  • 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) .
  • 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
  • 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.
  • a mutual authentication process i.e. between the system infrastructure and the smart card, such as a challenge-challenge ⁇ response protocol is carried out.
  • 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.
  • 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.
  • 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.
  • 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) .
  • the system can proceed as desired to allow the communications terminal to register as and use the (validated) .smart card.
  • 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.
  • 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.
  • 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.
  • the communications terminal 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.
  • the terminal 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.
  • 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'.
  • 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.
  • 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.
  • 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.
  • 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..
  • ITSI serial number or identity
  • 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 .
  • 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) .
  • 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) .
  • the smart card's identity e.g. ITSI and authentication key K
  • 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 .
  • the system infrastructure e.g., trust centre
  • “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.
  • the smart card registration process includes the facility of initiating an authentication of the smart card, for this purpose.
  • 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.
  • 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.
  • 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) .
  • a smart card 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.
  • 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.
  • the system infrastructure e.g. trust and/or authentication centre
  • the system infrastructure 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 .
  • 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.
  • the system infrastructure e.g. trust centre
  • the system infrastructure e.g. trust centre
  • the system infrastructure 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.
  • 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.
  • a method of registering an identity with the network infrastructure of a mobile communications system 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the identity to be registered with the system infrastructure i.e.
  • 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.
  • a user's e.g., policeman's assigned personal identity.
  • 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.
  • PIN personal identification number
  • the latter arrangement could be and preferably is used to allow, e.g., a user to authenticate themselves with the system.
  • the exchange of messages includes the provision of a PIN to the system infrastructure for authentication purposes.
  • 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.
  • 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) .
  • a method of registering a user's identity with the network infrastructure of a mobile communications system 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 .
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • S registration parameter
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • SDS short data service messages
  • SMS short data service 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.
  • 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.
  • the trust centre is preferably connected (to the system infrastructure) in the same way as a dispatcher workstation, and/or via a dispatcher workstation.
  • the trust centre is connected (to the system infrastructure) via a mobile terminal.
  • the functions of the present invention may be performed by an authentication centre alone, e.g., and particularly, where the authentication centre can be addressed directly.
  • a trust centre 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.
  • 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 .
  • 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) .
  • ITSIs identities
  • associated identities and/or serial numbers e.g. of smart cards and/or users
  • 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.
  • the host infrastructure preferably asks the home infrastructure to perform the authentication and/or registration, etc..
  • 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) .
  • 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) .
  • ITSI smart card's identity
  • 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.
  • 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..
  • 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.
  • PIN e.g. PIN
  • 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.
  • 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.
  • 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.
  • a smart card 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.
  • 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.
  • 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.
  • 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.
  • authentication data such as a PIN
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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 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.
  • ITSI personal individual subscriber identity
  • K authentication key
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • ITSIs subscriber identities
  • authentication keys K of the mobile stations and smart cards
  • 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) .
  • a new TETRA signalling message at the same level as the existing registration and authentication signalling could be used.
  • the mobile station 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.
  • the trust centre of the infrastructure 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.
  • 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).)
  • 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) .
  • 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 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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) .
  • ITSI identity
  • 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.
  • 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.
  • the system 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.
  • the trust centre 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 _
  • 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.
  • 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.
  • ITSI identity
  • 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.
  • 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.
  • 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.
  • an authentication challenge to the smart card can be made by the trust centre (system infrastructure)
  • 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.
  • the communications terminal 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.
  • 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 .
  • the smart card 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.
  • 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.
  • 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.
  • SCKs serial mode operation
  • DMO direct mode operation
  • 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) .
  • 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.
  • the terminal may already hold the required encryption keys
  • the terminal may use DMO air-interface encryption.
  • 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
  • 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.
  • SMS short message
  • 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.
  • 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.
  • the system infrastructure e.g. trust centre
  • PDU user activation request message
  • 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) .
  • ITSI smart card's identity
  • the 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.
  • PDU user activation result message
  • ITSI smart card's identity
  • SwMI Switching and Management Infrastructure
  • 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.
  • PDU user activation result message
  • ITSI smart card's identity
  • K 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).
  • DCK derived cipher key
  • ITSI smart card's identity
  • TEI communications terminal's identity
  • 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.
  • the trust centre 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 knows
  • the techniques of the present invention 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.
  • ITSI user's identity
  • Any portable electronic device carrying a user identity or user serial number can use this method.
  • 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.
  • 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.
  • a smart card e.g. encryption module
  • 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) .
  • core infrastructure e.g. SwMI
  • 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.
  • 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..
  • 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..
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un procédé d'enregistrement d'une identité avec l'infrastructure de réseau d'un système de communication mobile dans lequel un terminal de communications s'enregistre tout d'abord lui-même auprès de l'infrastructure de système. Une fois qu'il est enregistré, le terminal échange des messages avec l'infrastructure de système concernant une identité devant être enregistrée, par exemple, une carte à puce qui peut être introduite dans le terminal ou un utilisateur du terminal. Le terminal, une fois qu'il a terminé l'échange de messages, enregistre ensuite auprès de l'infrastructure de système l'identité devant être enregistrée.
EP07766424A 2006-08-03 2007-08-03 Systémes de communications mobiles Withdrawn EP2047704A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB0615449A GB0615449D0 (en) 2006-08-03 2006-08-03 Mobile communications systems
GB0618223A GB0618223D0 (en) 2006-09-15 2006-09-15 Mobile communications systems
PCT/GB2007/002952 WO2008015448A2 (fr) 2006-08-03 2007-08-03 Systémes de communications mobiles

Publications (1)

Publication Number Publication Date
EP2047704A2 true EP2047704A2 (fr) 2009-04-15

Family

ID=38529225

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07766424A Withdrawn EP2047704A2 (fr) 2006-08-03 2007-08-03 Systémes de communications mobiles

Country Status (4)

Country Link
EP (1) EP2047704A2 (fr)
KR (1) KR20090035720A (fr)
GB (1) GB2441409A (fr)
WO (1) WO2008015448A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1035994C (zh) * 1989-02-16 1997-10-01 希尔斯股份公司 制备纤维级对苯二甲酸二甲酯的方法

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2545674A2 (fr) 2010-03-10 2013-01-16 SRA International, Inc. Cryptage de la voix à une chambre forte
EP2875004B1 (fr) 2012-07-23 2018-07-18 Merck Patent GmbH Fluorènes et dispositifs electroniques les contenant

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4799061A (en) * 1985-11-18 1989-01-17 International Business Machines Corporation Secure component authentication system
FI104681B (fi) * 1997-06-04 2000-04-14 Sonera Oyj Menetelmä tilaajaidentiteettimoduulin hallitsemiseksi tietoliikennejärjestelmässä ja tietoliikennejärjestelmä
US6778828B1 (en) * 1999-04-12 2004-08-17 Lucent Technologies Inc. Personal mobility registration system for registration of a user's identity in a telecommunications terminal
DE60109585D1 (de) * 2001-05-08 2005-04-28 Ericsson Telefon Ab L M Sicherer Zugang zu einem entfernten Teilnehmermodul
CN1281086C (zh) * 2002-03-12 2006-10-18 斯伦贝谢（北京）智能卡科技有限公司 用户识别模块卡、空中激活用户识别模块卡的方法和系统
WO2004015968A1 (fr) * 2002-08-13 2004-02-19 Thomson Licensing S.A. Protection d'identite de terminal mobile par modification d'enregistreur de location nominale
ATE539567T1 (de) * 2003-10-03 2012-01-15 Hewlett Packard Development Co Netzwerk und verfahren zur anmeldung mobiler geräte und zur verwaltung der mobilen geräte
US7505756B2 (en) * 2003-10-15 2009-03-17 Microsoft Corporation Dynamic online subscription for wireless wide-area networks

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2008015448A2 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1035994C (zh) * 1989-02-16 1997-10-01 希尔斯股份公司 制备纤维级对苯二甲酸二甲酯的方法

Also Published As

Publication number Publication date
WO2008015448A3 (fr) 2008-03-27
GB0715117D0 (en) 2007-09-12
KR20090035720A (ko) 2009-04-10
WO2008015448A2 (fr) 2008-02-07
GB2441409A (en) 2008-03-05

Similar Documents

Publication Publication Date Title
JP5579938B2 (ja) ローミングネットワークにおけるアクセス端末識別情報の認証
JP4816161B2 (ja) 無線通信装置、ｍａｃアドレス管理システム、無線通信方法及び無線通信プログラム
US20040157584A1 (en) Method for establishing and managing a trust model between a chip card and a radio terminal
EP1828931B1 (fr) Authentification d'identite terminal collaborative securisee entre un dispositif de communication sans fil et un operateur sans fil
JP4712871B2 (ja) サービス提供者、端末機及びユーザー識別モジュールの包括的な認証と管理のための方法及びその方法を用いるシステムと端末装置
JP4763368B2 (ja) 通信カード、機密情報処理システム、機密情報転送方法およびプログラム
US11882442B2 (en) Handset identifier verification
US20020187808A1 (en) Method and arrangement for encrypting data transfer at an interface in mobile equipment in radio network, and mobile equipment in radio network
CA2545159A1 (fr) Methode d'authentification d'applications
CN104395937A (zh) 用于控制车辆访问权限和/或驾驶权限的装置和方法
US8230218B2 (en) Mobile station authentication in tetra networks
CN101163013A (zh) 网络中无线终端和设备之间建立安全会话的方法
WO2006079282A1 (fr) Procede pour le reglage de la cle et reglage du code de securite initial dans le terminal mobile
KR100847145B1 (ko) 불법 액세스 포인트 검출 방법
CN100353787C (zh) 一种移动终端内存储的资料信息的安全保障方法
JP4833745B2 (ja) センサノードのデータ保護方法、センサノードを配布するための計算機システム及びセンサノード
TW200527877A (en) Method and application for authentication of a wireless communication using an expiration marker
KR20030082449A (ko) 무효화 시스템
CN101262669B (zh) 一种移动终端内存储的资料信息的安全保障方法
JP3761432B2 (ja) 通信システムおよびユーザ端末およびｉｃカードおよび認証システムおよび接続および通信の制御システムおよびプログラム
JP2011028522A (ja) ホスト装置、認証方法、並びに、コンテンツ処理方法及びそのシステム
EP3550765B1 (fr) Fourniture de services
JP7404540B2 (ja) プライバシー情報伝送方法、装置、コンピュータ機器及びコンピュータ読み取り可能な媒体
WO2008015448A2 (fr) Systémes de communications mobiles
US7933597B2 (en) Method of registering a network, and mobile station and communication system using the same

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090130

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

RIC1 Information provided on ipc code assigned before grant

Ipc: H04W 4/00 20090101AFI20090316BHEP

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20100225

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20100908