Title:
AN ARRANGEMENT AND A METHOD RELATING TO SECURE COMMUNICATION
TECHNICAL FIELD
The present invention relates to an arrangement in a communication system, which comprises a switching serving node communicating with a user station over a radio access network which comprises an interface to the switching serving node. In the user station means are provided for holding subscriber information and it supports a first set comprising a number of information protection algorithms, whereas the switching serving node supports a second set comprising a number of information protection algorithms. The invention also relates to a user station communicating with the switching serving node over a radio access network with an interface to said node, wherein the user station is provided with means for holding subscriber information and supports a first set comprising a number of information protection algorithms. Further yet the invention relates to a switching serving node interfacing an access network over an interface and which supports a number of information protection algorithms forming a second set for the purposes of algorithm negotiation between the said node and the user station.
Still further the invention relates to a method for enabling secure negotiation of information protection algorithms between a user station and a switching serving node over a radio access network in a communication system, wherein the user station supports a first set of information protection algorithms and
the switching serving node supports a second set of information protection algorithms.
Generally the invention relates to increasing the security for communication in a communication system.
STATE OF THE ART
In known systems, for circuit switched communication encryption is provided between a mobile station and a BTS (Base Transceiver Station) of a BSS (Base Station Subsystem) . For packet switched communication encryption is provided for between a mobile station or a user equipment (UE) and, in GPRS, a SGSN (Serving GPRS Support Node) . However, in current existing GSM networks there are no security measures taken whatsoever to ensure that a user station or a terminal and the network are able to agree on the strongest encryption algorithm that the terminal and the network have in common, i.e. that is supported by both. By strongest is here meant the algorithm that both the user station and the switching server node, i.e. SGSN or MSC/BTS support, and which provides the highest degree of security that is possible bearing in mind what the terminal and the node support. An attacker, also called a man in the middle, can at any time interfere during the algorithm negotiation, and neither the network nor the terminal is able to detect an attacker, or a man in the middle, modifies a message sent between them. In order to determine the strongest algorithm for encryption, algorithm negotiation takes place between the user station, e.g. an MS or a user equipment UE and SGSN (or CGSN) for GPRS or between MS and MSC for a GSM system. As referred to above, encryption is then provided for between the user station and for example SGSN or the user station (MS) and the BTS.
For GPRS, GPRS encryption algorithms are known such as for example GEA1 and GEA2, both comprising 64 bit key. A new GPRS encryption algorithm GEA3 is released and will be put into practice later on which comprises a 64-128 bit key, e.g. depending on what the networks supports. Depending on user station, e.g. MS or UE, and SGSN/CGSN or MSC respectively, which here are denoted switching serving nodes, may support different algorithms. Generally, the older the terminal, the less secure encryption algorithms are supported by the MS, and similar for the switching serving node. However, still communication has to be allowed, and preferably, in each case, as securily as possible .
In the existing BSS it is very easy for a man in the middle, or an attacker, to change a proposed algorithm from the user station and hence being successful in a bidding down attack i.e. making the user station and the node agree on a weaker, or less protective, algorithm than necessary.
In today available specifications the signalling for negotiation of algorithms between the user station and for example the SGSN is handled using a three way handshake protocol. This consists in the sending of a first message from the terminal or user station towards (here) the SGSN, comprising an Attach Request including information about which algorithms the terminal supports. When this first message is received in SGSN, SGSN will choose a selected algorithm (common to the terminal and SGSN) and sends a second message comprising a challenge to the terminal in an Authentication and Ciphering Request. When the second message is received in the user station, it calculates a response and sends it towards the SGSN (message three) and the SGSN will then check that the response is valid. When these three messages have been successfully processed, signalling
messages as well as user plane messages can1 be encrypted with the selected algorithm. Algorithm negotiation could be protected in different ways. However, apart from security issues having to be resolved, there are issues that relate to backward compatibility which need to be considered.
In today known systems an attacker can modify any of the three messages, he can for example modify the first message sent from the user station, indicating that algorithms 1, 2, 3 are supported, by simply modifying the message and excluding algorithms 2 and 3, thus making the SGSN (or whichever is the node) believe that the user station only supports algorithm 1. In similar ways the second and third messages can be manipulated and an attacker may actually make the user station and the node agree on the weakest algorithm that they have in common.
SUMMARY OF THE INVENTION
It is therefore an object of the present invention to provide an arrangement, as initially referred to, through which algorithm negotiation can be protected. Particularly it is an object to provide for secure, or as secure as possible, communication between a user station and a switching serving node (with the terminology introduced in this application) . Particularly it is an object of the invention to increase the security level for algorithm negotiation, particularly to increase the security level for the A-interface (GSM) and/or the Gb-interface (GPRS) in a radio access network, particularly GERAN (GPRS Enhanced Radio Access Network) . Particularly it is an object of the invention to achieve an improvement as to the security for algorithm negotiation for the interfaces referred to above while still reusing existing protocols and mechanisms, particularly without introducing any new signalling messages between the user station and the core network. It is an object to leave the
signalling flow as unaffected as possible due to legacy reasons, i.e. to keep it as a three-way handshake protocol. Particularly it is an object to prevent, or at least as much as possible complicate, the possibility of attacks during algorithm negotiation. A particular object is to enable for the switching serving node, e.g. SGSN, to verify whether secure negotiation was used or not. Particularly the node should be able to verify that secure negotiation was possible to use. It is also an object of the invention to suggest a solution that is applicable for legacy user stations and switching server nodes. A particular object of the invention is to provide for protection of negotiation of encryption algorithms and/or of integrity algorithms .
To solve the problems it might e.g. be suggested that the user station include a set of MAC (Message Authentication Code) algorithms in the first message 1 and that when the first message 1 is received in for example the SGSN, the latter would select the algorithm to be used and signal that back to the user station in a second message 2. In the third message 3 the user station might retransmit the algorithms that were proposed in the first message, but now protected with a MAC by using a key e.g. IK (Integrity Key) and/or CK (Cipher Key), Kc or any other key. It should be noted that Kc is the cipher key for 2G, GSM, communications, whereas CK is the cipher key for 3G. If the MAC is correct, if the algorithm match the ones sent by the user station, the SGSN can be certain that the user station and the SGSN have agreed on the strongest possibly encryption algorithm. The SGSN however needs to accept that legacy terminals use insecure negotiation. Even if SGSN is aware of the acceptability of insecure negotiation or not, this signalling flow can still be attacked by a man-in-the-middle as follows: It is supposed that an attacker first removes all information that includes MAC
algorithms in the first message 1. When SGSN receives message 1, it can only select an encryption algorithm which possibly or potentially might be the weakest one as determined by the attacker. In message 2 the attacker can then add a MAC algorithm which is included in the message when sent towards the terminal. When the user station, or the terminal, receives message 2 and possibly verifies if insecure negotiation is allowed, everything seems to be in order from the user station point of view. The user station then uses the added MAC algorithm in message 3 towards the SGSN. However, the attacker removes all MAC protection before forwarding the message to the SGSN. Such an attack would mean that the attacker is able to circumvent this protocol forcing the user station and the SGSN to agree on the weakest common algorithm. This possible attempt to a solution is given to highlight the problem. Thus, better solutions are needed.
Therefore the invention suggests an arrangement as initially referred to having the features of the characterizing part of claim 1.
The invention further suggests a user station as also initially referred to having the characterizing features of claim 19. Still further the invention suggests a switching serving node as initially referred to having the characterizing features of claim 26, as well as a method as initially referred to having the characterizing features of claim 30.
Particular and advantageous embodiments are given by the appended sub-claims .
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will in the following be further described, in a non-limiting manner, and with reference to the accompanying drawings, in which:
Fig. 1 very schematically illustrates a GSM/GPRS communication system in which the inventive concept can be implemented,
Fig. 2 illustrates the current three-way signalling between a user station, with a USIM, and an SGSN for 3G,
Fig. 3 illustrates options that are available when a USIM is used as subscriber information holding means,
Fig. 4 schematically illustrates a general embodiment of the inventive concept,
Fig. 5 illustrates one embodiment in which cipher block codes are used as information protection codes in the algorithm negotiation,
Fig. 6 illustrates a second embodiment in which cipher block codes are used as protection codes,
Fig. 7 illustrates a first embodiment in which integrity algorithm (MAC) are used as protection codes,
Fig. 8 illustrates a second embodiment in which integrity algorithms (MAC) are used and a checksum is calculated,
Fig. 9 is a schematical flow diagram illustrating an implementation when a cipher block code is used and when indication is provided for indicating whether insecure negotiation is acceptable or not, and
Fig. 10 is a schematical flow diagram illustrating an implementation with integrity algorithms (MAC) and when an indication is provided as to whether insecure negotiation is acceptable or not.
DETAILED DESCRIPTION OF THE INVENTION
Fig. 1 schematically illustrates a communication system to which the inventive concept could be implemented. The figure illustrates a user station, here a mobile station MS with subscriber holding means in the form of a SIM-card (it could also be a USIM, UICC
(UMTS Inter Chip Card, hardware with applications SIM or USIM) ) . It provides for circuit switched communication, CS, over a BTS
(Base Transceiver Station) and a BSC (Base Station Controller) with a GSM MSC/VLR (Mobile Switching Center/Visitor Location Register) in turn communicating with a HLR (Home Location Register) or an HSS, (Home Subscriber Server) . Alternatively it might communicate with a SGSN (Serving GPRS Support Node) (packet switched communication, PS) in turn communicating with a GGSN
(Gateway GPRS Support Node) whereby said SGSN is in communication with a HLR (HSS) . As an alternative to an SGSN and a GGSN, the functionality of both these nodes can be included in a node denoted CGSN; the functioning will still be the same. BSC communicates with MSC/VLR over the A-interface whereas the Gb interface is used between BSC and SGSN. For GSM, encryption is provided for between MS and BTS whereas for GPRS or packet switched data (PS) encryption is provided for between MS and SGSN. For circuit switched communication (CS) algorithm negotiation takes place between MS and MSC/VLR (although encryption, or
protection, only is provided up to BTS from MS) . For packet switched communication encryption is provided for between MS (US,UE) and SGSN.
In the standard body 3GPP it is worked on enhancing the security level for the A-interface/Gb interface in GERAN (GPRS Enhanced Radio Access Network) . The present invention can with advantage be used in GERAN for example when operators want to provide for a smooth migration and increase the security as compared to the existing security level. Established encryption algorithms are for example, for GPRS, GPRS encryption algorithms GEA1 and GEA2 both with 64 bit keys. A new GEA, GEA3, comprises 64-128 bit keys. For GSM the corresponding algorithms are A5/1, A5/2, A5/3. The inventive concept is of course applicable to any future algorithms .
The inventive concept will in the following mainly be discussed with reference to packet switched communication over the Gb interface, but it is likewise applicable for circuit switched communication over the A-interface between BSC and MSC/VLR. As referred to above, according to the inventive concept, a solution is suggested which is based on reusing existing protocols and mechanisms between the user station and the respective switching serving node, e.g. SGSN, CGSN or MSC, without introducing any new signalling. Preferably, but not necessarily instead of a SIM-card a USIM-card should be used since the security level with the SIM-card is lower than that for a USIM-card. A shift from a 2G card (SIM) to a 3G card (USIM) would strongly assist in facilitating the provision of security. An UICC may of course also be used advantageously, but not necessarily, it (USIM or UICC) would be preferred as it would present an easier way to progress considering the different options available in 3GPP TS 33.102. Advantageously
the key length should be increased from 64 bits to 128 bits for all different options in said 33.102, which would have a big impact on the communication between HLR and SGSN as well as in the terminal etc. However, also legacy terminals/nodes have to be accepted.
The GEA3 algorithm has been designed such that it can support up to 128-bit keys. However, this characteristic is not signalled between the UE and SGSN in the current specifications. The technical specification 3GPP TS 55.216 specifies the length of a key being 64-128 bits long. The length of the key can be signalled in the MS Network Capability (a new field is required), cf. technical specification TS 24.008. Also the SGSN needs to send the information back, i.e. what algorithm and potentially what key length it has chosen in the Authentication and Ciphering Request, which would mean that a new field is required. 3GPP TS 55.216-219 are herewith incorporated herein by reference .
In Fig. 2 an overview of the signalling between an MS and an SGSN is given. It is here supposed that an USIM is used instead of an ordinary SIM-card. It is supposed that said USIM is able to provide the keys CK (Cipher Key) , IK (Integrity Key) and Kc (Cipher Key for 2G) to the mobile station MS which over GERAN communicates with an SGSN. It is supposed that the MS sends a first message MSG 1 comprising an Attach Request to the SGSN, which responds with a second message MSG 2 comprising an Authentication and Ciphering Request (RAND) , whereupon the MS responds with a third message, MSG 3, comprising an Authentication and Ciphering Response (RES) to the SGSN. The SGSN receives a Quintet comprising CK, IK, AUTN, RAND and XRES . The Attach Request is further described in GPRS technical specification TS 24.008 10.5.5.12 whereas the Authentication and
Ciphering Request is described TS 23060 6.8.1.1 which herewith are incorporated herein by reference.
Fig. 3 shows the different options when a USIM is inserted in the mobile station. The different options are defined in 3G TS 33.102, which also is incorporated herein by reference. It should be noted a case when a Quintet is delivered to a Release 99+ SGSN for GSM BSS access and ME is AKA (Authentication and Key Agreement) capable. The USIM calculates keys and puts them in the mobile station, the keys being CK, IK, Kc for UMTS and Kc for GSM and terminals are denoted R99+ ME for UMTS and R98- ME or RE99+ ME or R98- ME* for GSM. SRES is relevant for 2G, and corresponds to XRES of 3G, i.e. expected response. As referred to above, this is further explained in 3G TS 33.102.
As referred to above, it is easy for a man-in-the-middle to change a proposed algorithm from the user station MS, UE and thus being successful in a bidding down attack.
One way to solve the problem would be to encrypt the third message (MSG 3) including the RES and the proposed algorithms utilising a cipher. A suitable MAC (Message Authentication Code) of appropriate length to protect the negotiation phase might be a feasible way. This will be further discussed below.
The inventive concept is based on the assumption of keeping the signalling flow intact, i.e. keeping it a three-way handshake protocol. Preferably the SGSN should be able to verify whether secure negotiation was possible. Advantageously the home operator should be able to control the use of insecure negotiation by means of a flag in the subscriber information holding means, e.g. USIM. Alternatively a date (or an event) is given at the occurrence of which insecure negotiation is not
allowed. Preferably these solutions should also function satisfactorily for legacy user stations or UEs and SGSNs (or MSCs etc. ) .
As an example, a (an integrity algorithm) MAC could be used as a information protection code. Then the UE and the SGSN (for example) should also negotiate the MAC algorithms, i.e. in the Attach Request the UE would not only indicate the encryption algorithms it supports, but also the integrity algorithms it supports (new fields would be required) . In the third message (MSG 3 referred to above) , the algorithms proposed by the UE should be repeated, but now protected with a MAC. Upon reception of this message, the SGSN should check the authenticity of the message and only accept it if the result of the checkup is successful, otherwise the message should be discarded. Since legacy terminals cannot support this feature, the SGSN has to accept that message three sometimes might be unprotected. In order to facilitate some home control, it should be possible for the operator to set a flag in the USIM, such that the terminal is able to decide whether insecure negotiation is acceptable or not .
MAC algorithms that could be used could for example be AES (Advanced Encryption Standard) , which is cipher block code, in CBC MAC as defined in IS09797 and HMAC SHA1. Hence the third message might contain the algorithms proposed by the terminal in message 1 as well as a MAC of for example 96-128 bit calculated over appropriate parts of this message. The appropriate key to use for the MAC could for example be the IK of (Integrity Key) with 128 bits.
One way of using a MAC could as be follows: (Assuming that the terminal supports secure negotiation and algorithms A, B, C, D
being the algorithms GEA1, GEA2, GEA3 with each a 64 bit key, and GEA3 with a 128 bit key respectively) . However, a straightforward protocol would not solve the problems with the bidding down attack as illustrated below, if for example the user station sends the following algorithms in the first message, (here an attacker is assumed to act as a man-in-the-middle) :
Attach Request (A,B,C,D, AES MAC, HMAC SHAl), i.e. the message M would read A,B,C,D, AES MAC, HMAC SHAl. There algorithms may use specific parameters, and if so, they should also be sent. A block cipher might e.g. need an Initialisation Vector (IV). Then these parameters also have to be sent. This is not shown in the figures .
It is here supposed that the man-in-the-middle removes algorithms B,C,D, AES MAC and HMAC SHAl algorithm identifiers from the message M, and consequently SGSN will receive a message M'=A, thus making SGSN believe that the user station only supports algorithm A.
As a consequence thereof, when SGSN receives message M', SGSN has to choose algorithm A and SGSN then sends it towards the user station along with the challenge. Here SGSN does not know whether the user station supports secure negotiation or not. An attacker may for example add a MAC algorithm identifier, for example AES MAC to the second message subsequently sent by the SGSN. Such an attack cannot be detected by the terminal. The terminal calculates the response RES and the keys IK and CK based on the challenge received from SGSN and selects algorithm A as encryption algorithm. The terminal also calculates a MAC using IK and AES MAC protecting the necessary parts, i.e. the repeated algorithms . The attacker can now remove the MAC tag and all the repeated algorithms sent towards the SGSN. SGSN will not
detect the attack. When SGSN receives this message it will just check the RES and assume that algorithm A had been chosen.
This scheme could, according to the invention, be modified if the protocol should provide secure negotiation between the terminal and the SGSN. The above example illustrates that the SGSN was not able to establish or verify that it would have been possible to use secure negotiation since the attacker could bid down. This means that the SGSN does not know what the policy in the user station mandates. According to the invention a MAC tag could be added to third message, which then would be calculated over CK and/or IK or any other key and message M. An attacker could still remove this part, but then the flag in the USIM should indicate if this message (without any MAC algorithm indication nor MAC itself) is acceptable or not. The added value by using MAC itself, i.e. adding MAC itself, would be that the UE would be certain that if the MAC is present, the SGSN did actually receive the proposed algorithms in the first message M. Alternatively the message, the third message, from the user station towards the SGSN, could be secured. In the example above SGSN cannot be certain if UE is capable of secure negotiation or not and should accept that insecure negotiation could take place. Such an implementation will be discussed further down.
Fig. 4 illustrates a general implementation of the inventive concept. The figure illustrates the user station communicating over GERAN and the Gb interface with an SGSN. Hence the user station sends a first message, MSG 1 comprising an Attach Request to the SGSN. It is here supposed that the user station supports algorithms Al, A2, A3, A4 and BI, B2. SGSN stores the algorithms A1-A4 and BI, B2 and thereupon selects algorithms after having compared which algorithms in the attached request that itself supports, i.e. algorithms that are in common are
supported both by the user station and the SGSN, preferably the algorithms providing the highest security. It is here supposed that both the user station and the SGSN support algorithms A4 and B2 and therefore these algorithms are selected. SGSN then sends a message MSG 2 to the user station comprising a challenge and information about the selected algorithms, i.e. A4, B2. On the user station side the RES as well as the keys CK and IK are calculated or established. This is done based on the challenge with the assistance, in one implementation, of the subscriber holding means, which for example may be an USIM. According to different implementations the calculations and encryptions are performed by the user station (e.g. MS) and/or the subscriber information holding means (e.g. USIM, UICC). Subsequently MSG 3 is encrypted as well as RES using B2 and e.g. IK/CK. Subsequently the user station sends the third message, MSG 3 comprising a response and the original message encrypted with e.g. IK/CK using B2. SGSN comprises decrypting means for decrypting MSG 3 and thereupon it performs a comparing operation to establish whether the algorithms in MSG 3 are the same as the algorithm in MSG 1. If yes, the session proceeds, otherwise it is terminated. If the algorithms are not the same, the session should only proceed if it is explicitly indicated that insecure negotiation is acceptable. If there is no indication possibility as to that effect, the procedure is generally terminated unless there is a general agreement that insecure negotiation should be allowed as far as some kind of indication is provided to the user station and/or the SGSN that insecure negotiation actually does take place. Various alternatives are possible.
In the embodiment above the algorithms included in the messages are encryption algorithms, A1-A4 and information protection codes BI, B2. Alternatively it also may be provided for integrity protection, i.e. also integrity algorithms may be
protected by protection codes. This could mean that the first message comprises encryption algorithms A1-A5, integrity algorithms A6-A7, and that protection codes are B1,B2 to protect the negotiation of A1-A7.
Fig. 5 shows one particular implementation in which the information protection codes are cipher block code algorithms. One particular example relates to a block cipher comprising AES
(Advanced Encryption Standard) which is a cipher block code. It is also here supposed that the user station, here UE, supports AES. This makes it possible for the user station to protect the third message by encrypting repeated algorithms as well as the RES. Thus, it is here supposed that UE sends MSG 1 comprising an Attach Request with supported encrypted algorithms A1-A4 and cipher block code AES and potential parameters, e.g. IV, to SGSN
(or SGSN) . When the switching serving node (SGSN/CGSN) receives MSG 1, it stores MSG 1, selects, in this case, algorithms D and AES (on condition that they are supported by the node as well) and sends those with a challenge back towards the UE including the selected algorithms and RAND.
The user station or UE (subscriber holding means or actual MS) then calculates IK and CK as well as RES, and encrypts the repeated algorithms, i.e. the algorithms of the first message, MSG 1 using AES, preferably it also adds an indication that MSG 3 is encrypted. The third message may be encrypted with key IK using AES, and particularly RES as well as the original message is encrypted. When MSG 3 is received in SGSN, which preferably already at an earlier stage has been provided with CK, IK and the expected response XRES from the associated HLR, although this is indicated as taking place at this stage, SGSN decrypts MGS 3 and then it compares MSG 1 with MSG 3 and RES
with XRES to establish if they are equal. If this is the case, the session proceeds, otherwise it should be terminated.
In the following an embodiment will be disclosed in which a flag is added in the USIM (supposing that USIM is used instead of SIM) such then the user station US (or more particularly UE) gets the RAND or challenge without any indication that secure negotiation is used, it can terminate the session based on the home operator policy, hence forcing a terminal to use secure negotiation. Over the time or in the long run it is feasible to require that SGSNs or CGSNs support secure negotiation of algorithms. An attack as discussed earlier in the application would not be successful. An attacker can no longer tamper with the message since the RES as well as the set of algorithms are encrypted. Hence, in Fig. 6, US sends MSG 1 comprising an Attach Request to SGSN/CGSN. It is here supposed that the user station supports algorithms A1-A5, of which A5 has a key length of 128 bits. In addition thereto, as information protection code it supports AES. As in the preceding case, SGSN/CGSN stores MSG 1 and selects the highest protective and common algorithms, which here are supposed to be A5 (128) and AES. MSG 2 is then sent to US comprising A5 (128), AES, RAND. A flag is included in USIM indicating secure negotiation which is provided to US. On the user station side IK, CK and RES are calculated. MSG 3 is encrypted as well as RES using AES with e.g. IK or CK. A flag is provided to indicate encryption, i.e. that the message has been encrypted. Then the third message MSG 3 is sent towards SGSN/CGSN and it is, as referred to above, encrypted with AES using for example IK, and A1-A5, AES, RES are encrypted.
It is supposed that CK, IK, XRES are provided to SGSN/CGSN from HLR. SGSN/CGSN decrypts MSG 3, compares MSG 1 with MSG 3 and
compares RES with XRES. If equal, the session proceeds, otherwise it is terminated.
It should be noted that the user station shall signal the cipher IV (Initialisation Vector) or any other paramter(s), which will create a need for sending additional bits. It should also be considered that there might be attacks against the cipher, but the AKA (Authentication and Key Agreement) protocol would be untouched since the SGSN checks the RES (against XRES) .
The flag as to the allowability of insecure negotiation or not is relevant since there might be old equipment on the market, that still do not support secure negotiation and that it for some time still must be accepted that insecure negotiation takes place. It is however important to know if secure negotiation actually is possible, and if still insecure algorithms are proposed or selected, this might be an indication that there has been an attack. If secure negotiation would be possible, then a session should, at an as early stage as possible be terminated, since an attack is plausible. It is also important for users, operators etc. to actually be aware of the fact that the communication might be insecure so that this knowledge may influence their acting.
Fig. 7 relates to another implementation as was briefly discussed above in an example on attacks when MAC algorithms are used as protection codes, i.e. instead of block cipher codes integrity algorithms can be used. In Fig. 7 it is supposed that user station US sends MSG 1 comprising an Attach Request to SGSN/CGSN indicating the algorithms supported by US, here algorithms A, B,C,D, and integrity algorithms AES-MAC, HMAC SHAl. The set of algorithms is here indicated M. SGSN then stores MSG ,1 (M) , and selects for example D and AES MAC, on condition
that these are supported also by SGSN. From HLR it receives a Quintet as discussed in Fig. 2 above comprising IK, CK, RAND, XRES, AUTN. The quintet may be provided/requested upon reception of MSG1, or an "old" quintet might already present in SGSN/CGSN. SGSN then sends MSG 2 towards the US comprising a challenge with D, AES-MAC, RAND. It is here also supposed that the subscriber information holding means comprises an USIM, which (here) is responsible for calculating RES, IK, CK using RAND and providing RES, IK, CK to US. It is here supposed that some kind of indication is available to the fact that, in this case, US supports secure negotiation and that secure negotiation is to be used. US then sends an MSG 3 comprising AES-MAC (IK, RES, M) wherein M is the message MSG 1. An attacker could not tamper with this message, since a failure would occur in the SGSN. The SGSN upon receiving MSG 3 calculates AES-MAC (IK, XRES, M) and compares this value with MSG 3. If MSG 3 = XMSG 3, the session proceeds, otherwise it is interrupted or terminated. Thus, if the messages are equal or correct, which means that the user station or UE has been authenticated and it can be concluded that also M was correct, the session proceeds. SGSN can now be certain that the user station was capable of secure negotiation. Preferably the length of the MAC is as long as RES, at least 32 bits, but in an advantageous implementation it should be at least 96 bits as required for example HMAC-SHAl. It should be noted that this scheme might change the AKA protocol.
Fig. 8 illustrates an alternative implementation based on using MAC. This case it is supposed that an UE sends MSG 1 comprising an Attach Request, with supported encryption algorithms A,B,C,D, and supported integrity algorithms, AES-MAC, HMAC SHAl constituting message Ml to SGSN/CGSN. As in the proceeding embodiments, SGSN stores Ml and selects common and the most secure algorithms (or according to any policy) , here for example
D, AES-MAC. Thereupon it sends MSG 2 towards UE comprising a challenge with D, RAND, AES-MAC, and a cryptographic checksum
(e.g. 96 or 128 bits but also fewer or more bits are possible) AES-MAC (e.g. CK and/or IK, ES-MAC, Ml) . UE checks if AES-MAC is present, i.e. if the message indicates a selected MAC. If not, UE should abort the message since it is probably under attack. This could be controlled by the operator using a flag in the USIM allowing for a period that legacy SGSNs do not support secure negotiation. Otherwise, the UE derives RES and IK from RAND. It then verifies the MAC tag using the selected algorithm and the message Ml it sent initially. In this embodiment it verifies the checksum, and if it is in order, the session is proceeded, otherwise the message is aborted since this is an indication of an attack, e.g. due to the fact that the SGSN might have received a faked Ml in the first step or that the response in MSG 2 was faked. Otherwise the UE responds by RES, AES-MAC (IK, RES and possibly Ml). AES-MAC (...) is here denoted the MAC-UE. This case SGSN verifies the received message by comparing AES-MAC-SGSN (XRES) and MAC-UE, and also if RES = XRES
(wherein XRES is received from HLR or HSS as explained above) . If the result of these comparisons is affirmative, the session proceeds, otherwise it is terminated. This scheme is secure since UE is able to detect an attack at an earlier stage. In a similar alternative a message MSG 3' is sent (indicated with a dashed line in the figure) . In this case RES is included in the checksum and it is thus not sent open (as in the preceding case) . This is still more advantageous than the previous case in which RES was sent open. In this case AES-MAC-SGSN (M,XRES, IK) is compared to MAC-UE comprising the whole MSG 3'. If the result of the comparison is affirmative, the session is proceeded, otherwise it is terminated. In the embodiment discussed in Fig. 7, the scheme is secure since the SGSN would detect the attack, whereas in the embodiment of Fig. 8 the attack or an attack
could be detected earlier (in UE) . This is advantageous although it requires some extra overhead, since a MAC value has to be added from the SGSN which however might be insignificant.
In Fig. 9 one implementation of the inventive procedure is described in the form of a flow diagram. In a first step, 100, UE sends a first MSG (Attach Request) to SGSN with the supported encryption algorithms (e.g. A,B,C,D) and the supported cipher algorithms, e.g. AES. This message is denoted Ml. When received in SGSN, SGSN establishes which encryption algorithms and which cipher algorithms that are supported by SGSN and which are common with the algorithms supported by UE and received in Ml. These algorithms (Ml) are also stored, 101. Subsequently SGSN selects algorithms according to a given policy, here it is supposed that SGSN selects for example D, AES, 102. SGSN then sends a second message comprising RAND (challenge) with D, AES to UE, 103. Subsequently it is established if secure negotiation is requested, 104. If yes, it is established whether there is an indication that secure negotiation actually is used, 105. If not, the session is terminated. If the response was negative in step 104, i.e. secure negotiation is not requested, or if there was an indication that secure negotiation was used (and requested) , the session proceeds and UE calculates RES, IK, CK using RAND and encrypts Ml with AES and IK (RES,Ml) to provide a third message M3 and it also provides an indication that M3 is encrypted, 106. When M3 is received in SGSN, SGSN decrypts M3, 107, and subsequently it examines if RES is equal to XRES (received from HLR) and if Ml = M3, 108. If yes, the session is proceeded 108A. If not, the session is terminated, 108B.
Fig. 10 is a flow diagram schematically describing an embodiment in which integrity algorithms are used. First, 200, UE sends a first message (Attach Request) to SGSN with supported encryption
algorithms (here e.g. A,B,C,D) and supported integrity algorithms, e.g. AES-MAC, HMAC SHAl, noted message Mli- When received in SGSN (Mli*) , SGSN establishes which encryption and integrity algorithms that are supported by SGSN and establishes which algorithms are common with the algorithms provided in Mli*. SGSN stores Mli*, 201. Subsequently SGSN selects algorithms according to a given policy, e.g. D, AES-MAC, 202. SGSN calculates a checksum and sends a second message M2ι = RAND, AES- MAC, AES-MAC (IK, D, RAND, AES-MAC, Mli*), 203. As in the preceding embodiment, also in this case it is established if secure negotiation is requested, 204. If yes, it is established whether there is an indication about the use of secure negotiation, 205. If there is no such indication, the session is terminated, 205A. Otherwise, or if no secure negotiation was requested, the session proceeds and SGSN verifies whether AES- MAC of UE = AES-MAC of SGSN and if the checksum is correct, 206. If not, the session is terminated, 206A, if yes, UE sends a third message (M3ι) = RES, A-MAC (IK, RES) or alternatively AES- MAC (IK, RES) to SGSN, 207. In the second case RES is sent open, only included in the checksum, which might be advantageous. When M3ι is received in SGSN, SGSN calculates and checks if AES-MAC SGSN (XRES) = MAC-UE, and if RES = XRES or alternatively if AES- MAC SGSN (Ml, XRES, IK) = MAC-UE, 208. If yes, the session proceeds, 209, otherwise the session is terminated.
Preferably it should be possible to increase the key length to support any range from 64 bits to 128 bits long keys. One way to do this would be reassume that only the use of USIMs can be granted the increased security level over BSS accesses including the use of a Release 99+ version of the HLR/AuC, the SGSN and the ME. It is then assumed that the terminal could indicate e.g. in a new field that it supports a key length of e.g. 128 bits, or more. Alternatively it could be signalled as a new algorithm.
By mandating that a terminal supports enhanced security for Gb to protect message 3 with a cipher, e.g. AES, an increased security for agreeing on the strongest possible algorithm in common is facilitated. Advantageously a flag should be added in the USIM indicating if the terminal should accept that the SGSN is using insecure negotiation.
Considering that all schemes for secure negotiation are intended to increase the security level it should be noted that the embodiments in which a block cipher code is used, this would not change the AKA protocol, whereas the alternatives being based on integrity algorithms to some extent would do so.
It should be clear that the concept likewise is applicable to the A-interface to MSC/VLR for circuit switched communication.
It should also be clear that the invention is not limited to the explicitly illustrated embodiments, but that it can be varied in a number of ways without departing from the scope of the appended claims.