GB2365688A

GB2365688A - Authentication process using arrays of sequence numbers

Info

Publication number: GB2365688A
Application number: GB0019068A
Authority: GB
Inventors: Stephen Hugh Babbage; Peter Thomas Howard
Original assignee: Vodafone Ltd
Current assignee: Vodafone Ltd
Priority date: 2000-08-03
Filing date: 2000-08-03
Publication date: 2002-02-20
Anticipated expiration: 2020-08-03
Also published as: GB0019068D0; GB2365688B

Abstract

A process for authenticating communication between a Third Generation (3G) telecommunications network and a user service identity module (USIM) involves the generation of sequence numbers having values which advance between a start value and an end value in a sequence and are transmitted to the USIM intending to become authenticated in a network. Each USIM compares the value of each received sequence number with the value of the highest value sequence number previously accepted, and accepts the received number, and confirms part of the authentication process, only if its value is higher than the value of that previously accepted sequence number. A mobile station (MS) 16 in the cell of a node 14A can request a batch of authentication vectors from an authorisation centre (AuC) 22, each such vector comprising information, including a respective sequence number, for carrying out a single authentication of that USIM. If before the USIM has used all the authentication vectors, it moves to the cell of another node 14B, that node will also request a batch of authentication vectors from the AuC 22 which will contain respective sequence numbers more advanced in the sequence. The sequence numbers for a particular USIM are given specific identifiers dependent on the identity of the node 14A,14B requesting the respective batch and each accepted sequence number is stored according to its specific identity. During authentication, each USIM compares the value of each newly received sequence number with the value of the highest value sequence number previously accepted with the same specific identifier. In the case where the telecommunications system allows each MS to be authenticated simultaneously in different domains (e.g. voice and data), each sequence number for a particular user device can in addition or instead have a specific identifier dependent on the domain in which the USIM is to be authenticated, allowing a common sequence of numbers to be used for authentication in both ( or all) domains.

Description

<Desc/Clms Page number 1> TELECOMMUNICATIONS SYSTEMS AND METHODS The invention relates to telecommunication systems and methods. Telecommunication systems embodying the invention, and to be described in more detail below by way of example only, are systems, such as radio telecommunication systems, in which an authentication process is carried out when a user wishes to become active in the system- According to the invention, there is provided a telecommunication system, comprising a telecommunication network arrangement including a plurality of nodes of respectively different types and a plurality of user devices each for communication within the network arrangement using at least one of the nodes after completion of an authentication process with that node, the network arrangement including number generating means for generating numbers (sequence numbers) having values which advance from a start value towards an end value in a sequence, means for allocating sequence numbers to the nodes for use in authenticating the user devices, the sequence numbers for authenticating a particular one of the user devices in relation to a particular one of the nodes all being associated with the same specific identifier which is different from the specific identifier associated with the sequence numbers for authenticating that user device in relation to any other one of the nodes, comparison means in each user device for carrying out a check of the value of each received sequence number before acceptance thereof to determine whether to accept it, and means responsive to acceptance of the received sequence number for confirming at least part of the authentication process for that user device in

relation to that node.

According to the invention, there is also provided a telecommunication method for use in authenticating communication between a telecommunication network arrangement and a plurality of nodes of respectively different types in a telecommunication network arrangement and a plurality of user devices each for communication within the network arrangement using at least one of the nodes after completion of an authentication process with that node, in which numbers (sequence numbers) having values which advance from a start value towards an end value in a sequence are generated, the sequence numbers are allocated to the nodes for use in authenticating the user devices, the sequence numbers for authenticating a particular one of the user devices in relation to a particular one of the nodes all being associated with the same specific identifier which is different from the specific identifier associated with the sequence numbers for authenticating that user device in relation to any other one of the nodes, in each user device a comparison step carries out a check of the value of each transmitted sequence number before acceptance thereof to determine whether to accept it, and acceptance of the received sequence number confirming at least part of the authentication process for that user device in relation to that node.

Mobile telecommunication systems, networks and methods according to the invention will now be desen'bed, by way of example only, with reference to the accompanying diagrammatic drawings in which:

Figure 1 is a block diagram of one of the networks; Figure 2 is a block diagram of part of a network in one of the systems; and Figure 3 is a block diagram of an array in a smart card module used in the system.

The network to be described with reference to Figure I is a cellular telecommunications network, more particularly a Third Generation (3G) or UMTS network. However, the invention is not restricted to such a network.

As shown in Figure 1, the network comprises a switching centre (MSC) 10 which controls a plurality of radio network controllers (RNC), of which one is shown at 12 in Figure 1. Each RNC 12 controls several base transceiver stations (BTS) 14. Each BTS 14 communicates with a plurality of mobile stations (MS) 16 - that is, mobile telephone handsets for example. The network includes a home location register (HLR) 20 with which is associated an authentication centre (AuC) 22. Communication between each BTS 14 and the MS 16 is non-nally by means of a wire-less link.

Each BTS 14 has a respective service area or cell 24 having a particular size (which vanes according to the radio range of the BTS, the local terrain and the local propagation charactenistics). Conununication can take place between the BTS and an MS within the cell. As an MS moves out of the area of the cell of one BTS and into the area of the cell

of another BTS, communication is handed over from the first to the second BTS as is known in cellular telecommunication technology.

Users of the network are provided with smart cards (known as User Services Identity Modules, UNITS Subscriber Identity Modules or Universal Subscriber Identity Modules - USIMs). Each USIM carries data identifying the user and other data relating to the user such as the type of service to which the user is entitled, and also data, including algorithms, for authentication purposes. When a user wishes to become active in the network, he inserts his USIM into a suitable terminal such as a telephone handset. When the handset has been activated and the USIM has been authenticated within the network, he can then make and receive calls (which may be voice or data calls).

When a telephone handset containing a customer's USIM is switched on, radio communication will be established between that MS and the BTS 14 covering the area or cell in which the MS is currently located (assuming, of course, that the NIS is within range of a BTS). An authentication process then takes place.

The main purpose of the authentication process is to enable the serving network to corroborate the identity of the user's USIM - that is, that the USIM is genuine and authon'sed to use the particular network. Secondly, the authentication process establishes on behalf of the user that he is connected to a serving network that is authorised to provide him with services. Thus, for example, if the user is roaming in areas covered by

networks other than his home network (that is, the network with which he is registered), this part of the authentication process establishes that the particular network with which he is in communication is one of the networks authorised by his home network to offer roaming services.

The authentication process is initially controlled by the AuC 22. It involves the issue of a challenge by the AuC to the USIM. At the same time, the AuC generates the correct response to the challenge. During the authentication process, that response is compared with the actual response received from the USIM. If the correct response is received, then this part of the authentication process is satisfactorily completed.

In addition, the authentication process includes the generation of a "sequence number", and the transmission of this sequence number to the USIM. The sequence numbers are generated by the AuC and advance sequentially in a given direction from a start value towards an end value: in a simple case, for example, the numbers could be considered to be generated by a counter and to increase progressively. They could, for example, be linked to a global clock. Each sequence number would therefore comprise a part according to the actual date which would obviously be incremented each day and a part which would be a seri'al number in a series which increases from a datum value (e.g. zero) each day to a maximum value and then repeated the next day. In principle, though, sequence numbers could instead advance in the sequence by decreasing in value from a high value towards zero.

Each sequence number (contained within an Authentication Token AUTN) is transmitted with a Message Authentication Code (MAC) by means of wh c e I I I h th US M can check that the AUTN has been issued by a genuine network (that is, the USIM camies out this check independently of checking the value of the sequence number). The USIM then checks the sequence number for "freshness". The aim of the freshness check is to determine if the sequence number has previously been recovered by the USIM. This check can be cam'ed out using various methods.

According to one method, the USIM is satisfied that a sequence number is fresh (that is, it achieves the required quality of "freshness") if the sequence number is further advanced in the sequence than the most advanced sequence number in the sequence that it has previously received and accepted. Normally, the sequence will be a sequence of increasing numbers. Therefore, a USIM will only determine that a received sequence number is "fresh" if it is higher in value than the highest sequence number that was previously accepted as being fresh.

If the sequence is a decreasing sequence, a sequence number will be considered to be more advanced in the sequence than a previous accepted sequence number if it is lower in value than the sequence number previously accepted as being fresh.

If the USIM determines that a received sequence number has the required quality of freshness, then that part of the authentication process has been satisfactonily completed.

The use of sequence numbers, and the process of checking their value by the USIM, helps to protect against a non-authonsed network "replaying" a previous authentication process and thus "capturing" that user.

Other methods can be used by the USIM to detern-iine freshness of a newly received sequence number. For example, the sequence numbers could be generated in batches and the numbers in a batch could be used in any order. In such a case, the USIM would regard a received sequence number as fresh if it was more advanced in the sequence than the values of the sequence numbers of the preceding batches and had not already been received. Other methods are possible.

If the USIM determines that a received sequence number does not have freshness, then it indicates a failure of authentication (a "synchronisation failure") to the AuC. The authentication process will be repeated. The AuC will issue another sequence number, further advanced in the sequence, and the USIM will repeat the check for freshness. Such re-synchronisation will obviously cause delay in the authentication process and is to be avoided where possible. One particular circumstance in which there is a risk of synchronisation failure and which the invention overcomes will now be described with reference to Figure 2.

Figure 2 assumes that the MS 16 with its USIM is roaming outside its home network into another network (visited network). Figure 2 shows the MS 16 temporarily located within

the cell 24A of a BTS or node 14A of the visited network. After successful authentication of the NIS 16, the user's details will be copied from the Home Location Register 20 of the user's home network to the Visitor Location Register 26 of the visited network where they are temporarily stored for use when the user makes or receives calls in the visited network.

The authentication process for authenticating the MS16 in the visited network is in principle the same as described above. Thus, in response to a registration request by the MS16, the node 14A requests authentication information to enable the authentication process to be carried out. This information will have to be obtained from the AuC 22 in the user's home network and transmitted to node 14A. As described, the authentication process involves a challenge and response procedure and the issuance of a sequence number by the AuC22 to the node 14A and thence to the MS 16 and the checking by the MS16 of this sequence number for "freshness", all as described above. Upon success of the authentication procedure including the freshness check, the MS becomes registered with the node 14A.

It is likely, of course, that the MS will make a number of authentication requests while present in the visited network - for example, each time the MS is switched on and each time it makes or receives a new call. Each such authentication process requires a new challenge/response and a new sequence number from the AuC 22. In order to avoid or reduce the time delay in obtaining such authentication information each time, the AuC 22

is arranged, in response to the first registration request by the MS the visited network, to generate a batch (for example, five) of "authentication vectors" which are transmitted to the requesting node (node 14A in this example) in the visited network. Each authentication vector includes all the information required for carrying out a single authentication process. Thus, each authentication vector includes data relating to a particular challenge and the corresponding response, and data relating to a particular sequence number. Therefore, when the MS 16 next requires to register with the node 14A, the required authentication data is immediately available in the node 14A and does not have to be sought from the AuC 22 in the home network.

As an example, it will be assumed that a batch of five authentication vectors are stored in node 14A for the particular MS 16, and that the sequence numbers in these vectors are, respectively, 11,12,13,14 and 15 (part of a sequence of increasing numbers) and that, during a previous authentication process (e.g. when in the home network), the MS 16 has successfully achieved authentication with the sequence number 10 (that is, at that time sequence number 10 was found to have the required quality of freshness).

During the next authentication process, therefore, MS 16 will receive a sequence number I I from node 14A - which is derived from the first authon*sation vector stored therein. MS 16 will therefore determine that this sequence number is fresh - because it is greater than the highest previously stored sequence number (10). Synchronisation is therefore deemed to occur.

It will also be assumed that MS 16 carries out two more authorisation processes with node 14A, successfully determining in the first one of such authentications that the next sequence number (12) issued by node 14A is fTesh and, in the second of such authentications, that the third sequence number (13) issued by node 14A is fresh.

If MS 16 now moves out of the cell of node 14A but into the cell of another node 14B (in the same visited network) and attempts to register there, node 14B will request authentication data from the AuC 22 in the home network. The AuC will thus respond in the same way as previously described and will send a batch of five (in this example) authentication vectors to node 14B for use in the currently requested authentication and ready for four subsequent authentications. The AuC will include the next available sequence numbers in these vectors. It will be assumed that these sequence numbers are, respectively, 16,17,18,19 and 20. In response to the authentication request, node 14B will transmit the sequence number 16 to NIS 16. MS 16 will then carry out the usual fteshness check on the sequence number - and will clearly determine that the sequence number 16 is fresh, because it is greater than the highest value previously accepted sequence number (13).

However, a problem could arise if the MS16 now returns to the cell of node 14A and requests registration there. Node 14A will start the authentication process with the next authentication vector which it is still storing (from the five original vectors previously transmitted from the AuC 22). The sequence number in this vector will be 14. It is clear,

therefore, that the freshness check carried out on this sequence number by the MS 16 will fall - because the new sequence number (14) is clearly lower in value than the highest value sequence number previously accepted (which is 16). There will therefore be a synchronisation failure. In response to this, node 14A will issue the next sequence number which it stores (15), but, again, synchronisation will fall. In response to this second failure, node 14A will request one or more further author-isation vectors from the AuC 22 in the home network. These will include sequence numbers greater in value than the sequence numbers in the authentication vectors temporarily stored in node 1413, and MS 16 will therefore eventually be able to achieve synchronisation. However, this will involve excessive and unacceptable time delay.

It has been proposed that this problem can be overcome by arranging for the USIM in the MS 16 to store previously accepted sequence numbers in an "array". Figure 3 shows such an array indicated at 30. This array has (in this example) nine storage locations I to IX When the AuC 22 issued a batch of authentication vectors, it associates a specific identifier or an "index number" with each sequence number in that batch - that is, all five sequence numbers in that batch of authonisation vectors would have the same index number. The index number determines the particular storage location (I to IX) in the array 30 in which the USIM stores those sequence numbers when it has successfully carried out the freshness checks on them. Thus, for example, five sequence numbers sent by the AuC 22 to node 14A could all carry the index III. In the example described above, where MS16 carries out three authentication processes with node 14A, therefore, the

sequence numbers 11, 12 and 13 would all be stored in location III of the array 30. When issuing the next group of five authentication vectors (the group of vectors for node 14B in the above example), the AuC 22 would allocate a different index number to them, such as, for example, index VII. Therefore, the sequence number used in the first authentication check cam*ed out between NIS 16 and node 14B would be stored in location VII of the array 30.

When the NIS 16 returns to the cell of node 14A and requests a new authentication check, it will note that the next sequence number issued by node 14A (sequence number 14 in the above example) has the index number 111. In carrying out its freshness check, the USIM of MS 16 will therefore compare the value of this sequence number 14 with the highest sequence number previously stored in location III of the array. It will thus now determine that the new sequence number 14 is indeed higher than the sequence numbers already stored in location 111, and synchronisation will be achieved.

The index numbers allocated to the sequence numbers in each batch are vanied cyclically by the AuC. Because the size of the array is finite, and not large, there is therefore a probability that the synchronisation problem desenibed above will still occur, though less often than if the array 30 is not provided.

In order to reduce this probability of synchronisation failure, the invention proposes that

the AuC 22 will allocate the index numbers in a manner which is dependent on the identity of the particular node which is requesting the authentication vectors. Thus, for example, when requesting a batch of authentication vectors from the AuC 22 the node (e.g. node 14A) could transmit information uniquely identifying itself. The index number allocated by the AuC 22 to the sequence numbers in the batch sent by the AuC to that node could then be specific to that node. Such an arrangement considerably reduces the probability of synchronisation failure - as compared (a) with a system as described above in which the array 30 is not used and the USIM compares each new sequence number with the highest value sequence number of all the sequence numbers previously accepted, when carrying out a freshness check, and (b) a system which uses the array 30 but where the AuC does not know anything about the identity of the requesting node and the index numbers are generated cyclically or in some similar fashion. In the case of (a) synchronisation failures can easily occur, as discussed above. In the case of (b), the probability of synchronisation failure will be less than in (a), but nevertheless significant, particularly if the NIS roams to many different nodes. By basing the index for the sequence numbers of each batch at least in part on the identity of the requesting node, the probability of synchronisation failure is significantly decreased.

Instead of storing the whole address of each requesting node, the AuC may reduce the storage space required by storing part, only, of the address - though this may, of course, increase the possibility of synchromsation failure if a large number of nodes are involved because the stored part of the address may be duplicated. The stored part of the address

could be used as a component of the index.

However, it is not essential that the requesting node uniquely identifies itself to the AuC when requesting a batch of sequence numbers. What the AuC needs to know, in response to each request for a batch of authentication vectors, is whether the request is the first request on behalf of a par-ticular USIM for that particular node. If it is, it allocates a particular index to each of the sequence numbers in the batch which it produces in response to that request. When that node then makes a request for a further batch of authorlisation vectors for the same USIM, the AuC merely needs to know this (e.g. that it is the second, third etc. such request) and can then ensure that it allocates the same index to the sequence numbers in the new batch.

An MS 16 may be operated in two or more different "domains". For example, one domain might relate to voice calls, and a second domain might relate to data calls (e.g. receiving and sending emails). An MS 16 might be registered simultaneously in both such domains (for example, so that the user could make an immediate voice call in response to an email Just received). Accordingly, the MS16 would be registered simultaneously with two different nodes each serving the same cell such as a circuit- switched node for voice calls and a packet switched node for data calls. In such a system, the MS will have to be authenticated separately in each domain, each authentication process being generally the same as described above and involving the use of the sequence numbers and the freshness checks carried out by the MS16. For ease of

processing, a single sequence of sequence numbers is used for authenticating the USIM in each domain, When the user attempts to register in one domain in a particular cell, the node in that cell appropriate to that domain will obtain a batch of sequence numbers from the AuC in the manner explained and the first one will be used for authentication. If the user then attempts to register in the same cell but in another domain, the node appropriate to that domain will obtain a batch of sequence numbers and will then be authenticated using the first of these. It will be apparent, though, that synchronisation failure will occur if the user then attempts to re-register in the first domain because the next sequence number used will be lower than the last one accepted as fresh.

However, if the node requesting a batch of authentication vectors from the AuC transmits information indicating the domain to which the node belongs, the AuC can allocate an appropriate index to the sequence numbers of the batch of vectors issued so that, again, when accepted by the USIM, they are stored in the same location in the array 30. When the USIM carries out a freshness check for authentication in one particular domain, it will compare the value of the new sequence number received with the highest value sequence number previously accepted for registration in that same domain - because it will check in a particular location in the array determined by the particular index issued by the AuC. In this way, therefore, synchromsation failures when a particular USIM registers in more than one domain in the same cell are eliminated. Clearly, the arrangement can be applied to systems with more than two domains: all that is required is that the array in each USIM has a sufficiently large number of storage locations.

The domains can be of any desired type - and could include, for example, an IM domain type (an IP-based multi-media sub-system).

It will be appreciated that both aspects of the invention can be used together - that is, (a) each request for a batch of authentication vectors by a particular node can indicate (at least) whether it is the first or subsequent request from that node in relation to a particular USIM - so that sequence numbers for authenticating a particular USIM in a particular cell will all have the same index (thus reducing the probability of synchronisation failure when a user moves between different cells), and (b) each request for a batch of vectors by a particular node can indicate the domain of the node - so as to eliminate synchronisation failures when a user registers in two or more different domains in the same cell.

When the AuC allocates indexes to the sequence numbers, it can allocate them in ranges. For example, a range of index values may be referred for one domain and another range for the second domain. Within such a range, index values can then be allocated according to the identities (or some function of the identities) of the requesting nodes. The allocation within the ranges can be made in a cyclic fashion. The size of the ranges can be varied dynamically - for example, one range can be decreased and the other increased according to the number of requesting nodes in each domain.

Although the invention has been described above with reference to a user roaming in a

visited network, it is not limited to such a situation. It can be used whenever a sequence number is issued by the AuC but is not immediately used for authentication and is thus potentially liable to cause a synchronisation failure if used at a later time - after a later- issued and higher value sequence number has been used for authentication.

Claims

CLAIMS I A telecommunication system, comprising a telecommunication network arrangement including a plurality of nodes of respectively different types and a plurality of user devices each for communication within the network arrangement using at least one of the nodes after completion of an authentication process with that node, the network arrangement including number generating means for generating numbers (sequence numbers) having values which advance from a start value towards an end value in a sequence, means for allocating sequence numbers to the nodes for use in authenticating the user devices, the sequence numbers for authenticating a particular one of the user devices in relation to a particular one of the nodes all being associated with the same specific identifier which is different from the specific identifier associated with the sequence numbers for authenticating that user device in relation to any other one of the nodes, comparison means in each user device for carrying out a check of the value of each received sequence number before acceptance thereof to determine whether to accept it, and means responsive to acceptance of the received sequence number for confirming at least part of the authentication process for that user device in relation to that node.
2. A system according to claim 1, in which the comparison means carries out the said check by addressing whether the transmitted sequence number has previously been accepted with the same specific identifier and only accepts it if it decides that it has not previously been accepted with that specific identifier.

<Desc/Clms Page number 19>
3. A system according to claim I or 2, in which the comparison means comprises means for comparing the value of each received sequence number before acceptance thereof with the value of the previously accepted sequence number having the same specific identifier and having the most advanced value in the sequence of the accepted sequence numbers with that specific identifier, and including means in the user device for accepting that received sequence number only if its value is more advanced in the sequence than that previously accepted sequence number
4. A system according to any preceding claim, in which the nodes of the respectively different types are nodes of respectively different domains (e.g. voice and data communication).
5. A system according to any preceding claim, in which the telecommunication network arrangement is a cellular telecommunication network arrangement and the nodes of the different types are respectively the nodes of different cells.
6. A system according to any preceding claim, in which each user device includes storage means for storing accepted sequence numbers in different locations according to their respective specific identifiers.
7. A system according to any preceding claim, including means responsive to an authentication request from a particular one of the user devices to a particular one of the

<Desc/Clms Page number 20>

nodes for producing a batch of the sequence numbers at least some of which are ily stored for use in subsequent I temporan authentications of that user device in relation to that node, each of the sequence numbers of the batch having the same specific identifier.
S. A telecommunication method for use in authenticating communication between a telecommunication network arrangement and a plurality of nodes of respectively different types in a telecommunication network arrangement and a plurality of user devices each for communication within the network arrangement using at least one of the nodes after completion of an authentication process with that node, in which numbers (sequence numbers) having values which advance from a start value towards an end value in a sequence are generated, the sequence numbers are allocated to the nodes for use in authenticating the user devices, the sequence numbers for authenticating a particular one of the user devices in relation to a particular one of the nodes all being associated with the which is different from the specific identifier associated with the same speci ic I I I I I I sequence numbers for authenticating that user device in relation to any other one of the nodes, in each user device a comparison step carries out a check of the value of each transmitted sequence number before acceptance thereof to deter-mine whether to accept it, and acceptance of the received sequence number confirming at least part of the authentication process for that user device in relation to that node.
9. A method according to claim 8, in which the compan'son step carries out the said check by assessing whether the sequence number has previously been accepted with the

<Desc/Clms Page number 21>

same specific identifier and only accepts it if it decides that it has not previously bee accepted with specific identifier.
10. A method according to claim 9, in which the comparison step compares the value of each received sequence number before acceptance thereof with the value of the previously accepted sequence number having the same specific identifier and having the most advanced value in the sequence of the accepted sequence numbers with that specific identifier, the user device accepting that received sequence number only if its value is more advanced in the sequence than that previously accepted sequence number,
11. A method according to any one of claims 8 to 10, in which the nodes of the respectively different types are known of respectively different domains (e.g. voice and data communication).
12. A method according to any one of claims 8 to 11, in which the telecommunication network arrangement is a cellular telecommunication network arrangement and the nodes of the different types are respectively the nodes of different cells.
13. A method according to any one of claims 9 to 12, in which each user device includes storage means for storing accepted sequence numbers in different locations according to their respective specific identifiers.

<Desc/Clms Page number 22>
14. A method according to any one of claims 9 to 13, including the step of responding to an authentication request from a particular one of the user devices to a particular one of the nodes by producing a batch of the sequence numbers at least some of which are temporanly stored for use in subsequent authentications of that user device in relation to that node, each of the sequence numbers of the batch having the same specific identifier.
15. A telecommunication system, substantially as descnibed with reference to the accompanying drawings.
16. A telecommunication method, substantially as described with reference to the accompanying drawings-