WO2004098144A1 - Dispositif et procede de protection des communications - Google Patents
Dispositif et procede de protection des communications Download PDFInfo
- Publication number
- WO2004098144A1 WO2004098144A1 PCT/EP2003/004350 EP0304350W WO2004098144A1 WO 2004098144 A1 WO2004098144 A1 WO 2004098144A1 EP 0304350 W EP0304350 W EP 0304350W WO 2004098144 A1 WO2004098144 A1 WO 2004098144A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- message
- algorithms
- user station
- protection
- information
- 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.)
- Ceased
Links
Classifications
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/12—Detection or prevention of fraud
- H04W12/121—Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
- H04W12/122—Counter-measures against attacks; Protection against rogue devices
-
- 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/67—Risk-dependent, e.g. selecting a security level depending on risk profiles
Definitions
- 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.
- a switching serving node communicating with a user station over a radio access network which comprises an interface to the switching serving node.
- 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.
- 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.
- 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.
- the invention relates to increasing the security for communication in a communication system.
- SGSN or MSC/BTS support 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.
- 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.
- encryption is then provided for between the user station and for example SGSN or the user station (MS) and the BTS.
- 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.
- user station e.g. MS or UE
- SGSN/CGSN or MSC respectively which here are denoted switching serving nodes, may support different algorithms.
- the older the terminal the less secure encryption algorithms are supported by the MS, and similar for the switching serving node.
- still communication has to be allowed, and preferably, in each case, as securily as possible .
- 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.
- 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.
- 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.
- signalling messages as well as user plane messages can 1 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.
- GSM A-interface
- GPRS Gb-interface
- GERAN GPRS Enhanced Radio Access Network
- 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 .
- 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.
- 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), K c or any other key.
- IK Integrity Key
- CK Cipher Key
- 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.
- 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.
- 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
- MAC integrity algorithms
- 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.
- MAC integrity algorithms
- 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
- a BSC Base Station Controller
- GSM MSC/VLR Mobile Switching Center/Visitor Location Register
- HLR Home Location Register
- HSS Home Subscriber Server
- SGSN Serving GPRS Support Node
- PS packet switched communication
- GSM Global System for Mobile Communications
- PS packet switched data
- CS circuit switched communication
- 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.
- 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 G b interface, but it is likewise applicable for circuit switched communication over the A-interface between BSC and MSC/VLR.
- 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.
- a USIM-card should be used since the security level with the SIM-card is lower than that for a USIM-card.
- SIM 2G card
- USB 3G card
- 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.
- 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.
- 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 .
- 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 K c (Cipher Key for 2G) to the mobile station MS which over GERAN communicates with an SGSN.
- CK Cipher Key
- IK Integrity Key
- K c Cipher Key for 2G
- 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.
- MSG 1 comprising an Attach Request
- MSG 2 comprising an Authentication and Ciphering Request
- RES Authentication and Ciphering Response
- 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, K c for UMTS and K c 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.
- the inventive concept is based on the assumption of keeping the signalling flow intact, i.e. keeping it a three-way handshake protocol.
- the SGSN should be able to verify whether secure negotiation was possible.
- 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.
- a date (or an event) is given at the occurrence of which insecure negotiation is not allowed.
- these solutions should also function satisfactorily for legacy user stations or UEs and SGSNs (or MSCs etc. ) .
- 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) .
- the algorithms proposed by the UE should be repeated, but now protected with a MAC.
- the SGSN 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.
- AES Advanced Encryption Standard
- CBC MAC cipher block code
- HMAC SHA1 HMAC SHA1.
- 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.
- 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 .
- SGSN when SGSN receives message M', SGSN has to choose algorithm A and SGSN then sends it towards the user station along with the challenge.
- 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.
- AES MAC MAC algorithm identifier
- 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.
- 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.
- the message, the third message, from the user station towards the SGSN, could be secured.
- 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 G b interface with an SGSN.
- the user station sends a first message, MSG 1 comprising an Attach Request to the SGSN.
- MSG 1 comprising an Attach Request to the SGSN.
- 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.
- both the user station and the SGSN support algorithms A4 and B2 and therefore these algorithms are selected.
- MSGSN then sends a message MSG 2 to the user station comprising a challenge and information about the selected algorithms, i.e. A4, B2.
- 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.
- the calculations and encryptions are performed by the user station (e.g. MS) and/or the subscriber information holding means (e.g. USIM, UICC).
- MSG 3 is encrypted as well as RES using B2 and e.g. IK/CK.
- 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.
- the algorithms included in the messages are encryption algorithms, A1-A4 and information protection codes BI, B2.
- 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
- UE Advanced Encryption Standard
- 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
- the switching serving node (or SGSN) 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 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.
- the user station supports algorithms A1-A5, of which A5 has a key length of 128 bits.
- information protection code it supports AES.
- 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.
- 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.
- 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.
- 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.
- 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) .
- cipher IV Initialisation Vector
- AKA Authentication and Key Agreement
- insecure negotiation 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.
- 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 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.
- 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.
- 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 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.
- 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.
- 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.
- SGSN stores Ml and selects common and the most secure algorithms (or according to any policy) , here for example D, AES-MAC.
- MSG 2 towards UE comprising a challenge with D, RAND, AES-MAC, and a cryptographic checksum
- AES-MAC e.g. CK and/or IK, ES-MAC, Ml
- the session is proceeded, otherwise it is terminated.
- 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.
- 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.
- MSG Access Request
- Ml the supported encryption algorithms
- 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.
- 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.
- Fig. 10 is a flow diagram schematically describing an embodiment in which integrity algorithms are used.
- 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-
- SGSN 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.
- M2 ⁇ RAND, AES- MAC, AES-MAC (IK, D, RAND, AES-MAC, Mli*)
- M3 ⁇ RES
- A-MAC IK, RES
- AES- MAC IK, RES
- the key length 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.
- a flag should be added in the USIM indicating if the terminal should accept that the SGSN is using insecure negotiation.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| AU2003242524A AU2003242524A1 (en) | 2003-04-25 | 2003-04-25 | An arrangement and a method relating to secure communication |
| PCT/EP2003/004350 WO2004098144A1 (fr) | 2003-04-25 | 2003-04-25 | Dispositif et procede de protection des communications |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/EP2003/004350 WO2004098144A1 (fr) | 2003-04-25 | 2003-04-25 | Dispositif et procede de protection des communications |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2004098144A1 true WO2004098144A1 (fr) | 2004-11-11 |
Family
ID=33395681
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/EP2003/004350 Ceased WO2004098144A1 (fr) | 2003-04-25 | 2003-04-25 | Dispositif et procede de protection des communications |
Country Status (2)
| Country | Link |
|---|---|
| AU (1) | AU2003242524A1 (fr) |
| WO (1) | WO2004098144A1 (fr) |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006081712A1 (fr) * | 2005-02-07 | 2006-08-10 | Zte Corporation | Méthode de commutation de niveau de texte normal et de texte chiffré pendant une conversation |
| WO2006134505A1 (fr) * | 2005-06-17 | 2006-12-21 | Nokia Corporation | Procede, systeme et elements de reseau pour l'etablissement d'une protection multimedia a travers des reseaux |
| DE102006028938B3 (de) * | 2006-06-23 | 2008-02-07 | Siemens Ag | Verfahren zur Übertragung von Daten |
| WO2010027314A1 (fr) * | 2008-09-05 | 2010-03-11 | Telefonaktiebolaget L M Ericsson (Publ) | Négociation sécurisée de capacités d'authentification |
| WO2010135292A3 (fr) * | 2009-05-22 | 2011-02-03 | Microsoft Corporation | Authentification multiniveau basée sur un modèle |
| EP2371155A1 (fr) * | 2008-11-26 | 2011-10-05 | Alcatel-Lucent USA Inc. | Prévention d'attaque de dégradation de protection dans un système de communication |
| EP2484137A4 (fr) * | 2009-09-28 | 2014-12-31 | Unwired Planet Internat Ltd | Négociation de fonction de sécurité entre réseau et terminal utilisateur |
| EP1864427A4 (fr) * | 2005-03-17 | 2016-04-20 | Korea Electronics Telecomm | Procede permettant la negociation de fonctions se rapportant a la securite d'une station d'abonne, dans un systeme internet portable sans fil |
| WO2017031420A1 (fr) * | 2015-08-20 | 2017-02-23 | Alibaba Group Holding Limited | Procédé, appareil, dispositif de terminal et système de génération de clé partagée |
| JP2018526905A (ja) * | 2015-08-13 | 2018-09-13 | ホアウェイ・テクノロジーズ・カンパニー・リミテッド | メッセージ保護方法、ならびに関連デバイスおよびシステム |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5371794A (en) * | 1993-11-02 | 1994-12-06 | Sun Microsystems, Inc. | Method and apparatus for privacy and authentication in wireless networks |
| EP1005244A1 (fr) * | 1998-11-25 | 2000-05-31 | ICO Services Ltd. | Authentification d'une connexion dans un réseau mobile |
| DE10025271A1 (de) * | 2000-05-22 | 2001-11-29 | Siemens Ag | Verfahren zum Aufbau einer Verbindung zwischen einem Endgerät und einem bedienenden Mobilfunknetz, Mobilfunknetz und Endgerät dafür |
| US20020066011A1 (en) * | 2000-11-28 | 2002-05-30 | Nokia Corporation | System for ensuring encrypted communication after handover |
-
2003
- 2003-04-25 WO PCT/EP2003/004350 patent/WO2004098144A1/fr not_active Ceased
- 2003-04-25 AU AU2003242524A patent/AU2003242524A1/en not_active Abandoned
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5371794A (en) * | 1993-11-02 | 1994-12-06 | Sun Microsystems, Inc. | Method and apparatus for privacy and authentication in wireless networks |
| EP1005244A1 (fr) * | 1998-11-25 | 2000-05-31 | ICO Services Ltd. | Authentification d'une connexion dans un réseau mobile |
| DE10025271A1 (de) * | 2000-05-22 | 2001-11-29 | Siemens Ag | Verfahren zum Aufbau einer Verbindung zwischen einem Endgerät und einem bedienenden Mobilfunknetz, Mobilfunknetz und Endgerät dafür |
| US20020066011A1 (en) * | 2000-11-28 | 2002-05-30 | Nokia Corporation | System for ensuring encrypted communication after handover |
Cited By (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006081712A1 (fr) * | 2005-02-07 | 2006-08-10 | Zte Corporation | Méthode de commutation de niveau de texte normal et de texte chiffré pendant une conversation |
| EP1864427A4 (fr) * | 2005-03-17 | 2016-04-20 | Korea Electronics Telecomm | Procede permettant la negociation de fonctions se rapportant a la securite d'une station d'abonne, dans un systeme internet portable sans fil |
| WO2006134505A1 (fr) * | 2005-06-17 | 2006-12-21 | Nokia Corporation | Procede, systeme et elements de reseau pour l'etablissement d'une protection multimedia a travers des reseaux |
| DE102006028938B3 (de) * | 2006-06-23 | 2008-02-07 | Siemens Ag | Verfahren zur Übertragung von Daten |
| EP1870308A3 (fr) * | 2006-06-23 | 2009-11-04 | Siemens Aktiengesellschaft | Procédé destiné à la transmission de données |
| WO2010027314A1 (fr) * | 2008-09-05 | 2010-03-11 | Telefonaktiebolaget L M Ericsson (Publ) | Négociation sécurisée de capacités d'authentification |
| US9668139B2 (en) | 2008-09-05 | 2017-05-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Secure negotiation of authentication capabilities |
| JP2012502548A (ja) * | 2008-09-05 | 2012-01-26 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | 認証能力のセキュアなネゴシエーション |
| EP2371155A1 (fr) * | 2008-11-26 | 2011-10-05 | Alcatel-Lucent USA Inc. | Prévention d'attaque de dégradation de protection dans un système de communication |
| JP2012510232A (ja) * | 2008-11-26 | 2012-04-26 | アルカテル−ルーセント ユーエスエー インコーポレーテッド | 通信システムにおける競り下げ攻撃の防止 |
| AU2010249698B2 (en) * | 2009-05-22 | 2014-10-30 | Microsoft Technology Licensing, Llc | Model based multi-tier authentication |
| CN102439898A (zh) * | 2009-05-22 | 2012-05-02 | 微软公司 | 基于模型的多层验证 |
| CN102439898B (zh) * | 2009-05-22 | 2016-04-20 | 微软技术许可有限责任公司 | 基于模型的多层验证方法和系统 |
| US9544147B2 (en) | 2009-05-22 | 2017-01-10 | Microsoft Technology Licensing, Llc | Model based multi-tier authentication |
| WO2010135292A3 (fr) * | 2009-05-22 | 2011-02-03 | Microsoft Corporation | Authentification multiniveau basée sur un modèle |
| EP2484137A4 (fr) * | 2009-09-28 | 2014-12-31 | Unwired Planet Internat Ltd | Négociation de fonction de sécurité entre réseau et terminal utilisateur |
| JP2018526905A (ja) * | 2015-08-13 | 2018-09-13 | ホアウェイ・テクノロジーズ・カンパニー・リミテッド | メッセージ保護方法、ならびに関連デバイスおよびシステム |
| WO2017031420A1 (fr) * | 2015-08-20 | 2017-02-23 | Alibaba Group Holding Limited | Procédé, appareil, dispositif de terminal et système de génération de clé partagée |
| CN106470104A (zh) * | 2015-08-20 | 2017-03-01 | 阿里巴巴集团控股有限公司 | 用于生成共享密钥的方法、装置、终端设备及系统 |
| US10050781B2 (en) | 2015-08-20 | 2018-08-14 | Alibaba Group Holding Limited | Method, apparatus, terminal device and system for generating shared key |
| CN106470104B (zh) * | 2015-08-20 | 2020-02-07 | 阿里巴巴集团控股有限公司 | 用于生成共享密钥的方法、装置、终端设备及系统 |
| TWI710244B (zh) * | 2015-08-20 | 2020-11-11 | 香港商阿里巴巴集團服務有限公司 | 用於產生共用金鑰的方法、裝置、終端設備及系統 |
Also Published As
| Publication number | Publication date |
|---|---|
| AU2003242524A1 (en) | 2004-11-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4688808B2 (ja) | 移動体通信システムにおける暗号化の強化セキュリティ構成 | |
| CN110945886B (zh) | 无线通信网络中检测漫游活动的反引导的方法和系统 | |
| US8260259B2 (en) | Mutual authentication with modified message authentication code | |
| US8881235B2 (en) | Service-based authentication to a network | |
| EP1338169B1 (fr) | Procede et appareil destines a contrer la menace de surcouche indesirable a l'aide de la derivation d'une cle locale | |
| US9668139B2 (en) | Secure negotiation of authentication capabilities | |
| KR20070112260A (ko) | Sim/uicc 키 설정을 위한 네트워크 지원 단말기 | |
| US20110004754A1 (en) | Method And Apparatuses For Authentication And Reauthentication Of A User With First And Second Authentication Procedures | |
| EP1758417B1 (fr) | Procede d'authentification | |
| US12231586B2 (en) | UE challenge to a network before authentication procedure | |
| KR100755394B1 (ko) | Umts와 무선랜간의 핸드오버 시 umts에서의 빠른재인증 방법 | |
| WO2004098144A1 (fr) | Dispositif et procede de protection des communications | |
| US8457313B2 (en) | Protocol expansion of a signaling message | |
| Blanchard et al. | Wireless security | |
| CN100579274C (zh) | 安全密钥的设置方法 | |
| Bluszcz | UMTS Security UMTS Security | |
| WP | Project Title USECA: UMTS Security Architecture | |
| HK1095689B (en) | Enhanced security design for cryptography in mobile communication systems | |
| HK1164019A (en) | Service-based authentication to a network | |
| KR20150135715A (ko) | 이동통신 시스템에서 사용자의 프라이버시를 보호하는 장치 및 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW |
|
| AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
| 122 | Ep: pct application non-entry in european phase | ||
| NENP | Non-entry into the national phase |
Ref country code: JP |
|
| WWW | Wipo information: withdrawn in national office |
Country of ref document: JP |