WO2014154634A1 - Procede d'authentification mutuelle entre un element de securite d'un terminal de telecommunications et un element d'un reseau de telecommunications de type gsm - Google Patents

Procede d'authentification mutuelle entre un element de securite d'un terminal de telecommunications et un element d'un reseau de telecommunications de type gsm Download PDF

Info

Publication number
WO2014154634A1
WO2014154634A1 PCT/EP2014/055840 EP2014055840W WO2014154634A1 WO 2014154634 A1 WO2014154634 A1 WO 2014154634A1 EP 2014055840 W EP2014055840 W EP 2014055840W WO 2014154634 A1 WO2014154634 A1 WO 2014154634A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
security element
value
authentication
telecommunications
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
Application number
PCT/EP2014/055840
Other languages
English (en)
Inventor
Jean-Yves Fine
Philippe Proust
Marcel Robert
Vincent Dany
Aline Gouget
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales DIS France SA
Original Assignee
Gemalto SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gemalto SA filed Critical Gemalto SA
Publication of WO2014154634A1 publication Critical patent/WO2014154634A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys

Definitions

  • the field of the invention is that of telecommunications in GSM (2G) type cellular networks.
  • the present invention relates to a method of mutual authentication between on the one hand a security element of a telecommunications terminal and on the other hand an element of a second generation cellular telecommunications network.
  • GSM 2G networks
  • UMTS 3G networks
  • LTE 4G networks
  • These security elements are usually in the form of cards extractable from their terminals, usually constituted by mobile phones, smartphones, PDAs, etc. There are also security elements integrated in modems that are part of terminals or devices. machines (therefore not extractable), these machines being vehicles, vending machines, etc.
  • This type of communications between machines makes it possible to perform remote meter readings (water, electricity, etc.) or to interact with motor vehicles (for example to open their doors remotely, start the vehicle, start The air conditioning, etc. It also makes it possible to open remote gates, close electric shutters, or more generally to perform domotic type functions.
  • 2G networks therefore allow M2M-type communications where a user can activate a function on a remote terminal.
  • GSM second generation networks
  • Authentication makes it possible to verify that the identity (IMSI or TMSI) transmitted by the terminal communicating with the SIM card on the radio channel is correct in order to protect a the operator against the fraudulent use of its resources, and secondly the subscribers by prohibiting unauthorized third parties from using their accounts.
  • Subscriber authentication may be required of the mobile by the network at each location update, call setup (incoming or outgoing) and before enabling or disabling certain additional services. It is also requested during the implementation of the encryption key on certain dedicated channels.
  • GSM authentication is based on a challenge / response protocol as well as on secret key cryptography algorithms.
  • the network authenticates the SIM card but the SIM card does not authenticate the network.
  • the SIM card of the terminal is therefore not able to verify the identity and validity of the network to which the mobile is attached. Attacks by false base stations are therefore possible and have been observed, particularly in the M2M domain, where vehicle doors equipped with SIM applications could be opened remotely.
  • M2M uses GSM mechanisms and not UMTS or LTE mechanisms for their authentication. There is therefore no mutual authentication mechanism in M2M type communications.
  • Figure 1 shows the authentication mechanism used for GSM.
  • a terminal comprising a security element such as a SIM card 10 communicates with its HLR / AuC 12 via a VLR 1 1.
  • the SIM card 10 transmits its IMSI (or TMSI) to the VLR 1 1 which retransmits it to the HLR / AuC 12.
  • the latter retrieves the unique key Ki corresponding to this IMSI (TMSI) and generates a random value RAND of length 128 bits (16 bytes).
  • An algorithm called A3 generates a SRES value from the key Ki and the random value RAND.
  • Another algorithm, called A8, generates an encryption key Kc from Ki and RAND. This key Kc serves as an encryption key for user traffic and signaling traffic between the terminal and the base station (BTS).
  • the HLR / AuC 12 transmits the RAND, SRES and Kc values to the VLR 11 which retransmits only the random value RAND to the SIM card 10 in an authentication AuthCmd (Rand) command.
  • the SIM card 10 comprises the key K 1 used by the HLR 12 and calculates, using the algorithm A3, an XRES value, using the random value RAND received. It also calculates the encryption key Kc using the same elements.
  • the SIM card 10 then sends the VLR 1 1 the locally calculated value XRES.
  • the VLR compares SRES and XRES. If the two results are identical, the subscriber is authenticated. Otherwise, access to the network is denied to the terminal.
  • Authentication and Key Agreement (AKA) authentication is, as in GSM, based on a shared key Ki that is only present in the HLR and the USIM card. Since the HLR never communicates directly with the terminal, the VLR of the MSC server performs the authentication procedure.
  • AKA Authentication and Key Agreement
  • One to five authentication vectors are downloaded by the MSC server from the HLR when the MSC server receives an attachment request from the terminal.
  • the parameters present in the AV are:
  • RAND the challenge that serves as one of the input parameters to generate the other 4 parameters of the AV.
  • RAND is 128-bit coded
  • Ik an integrity key (128 bits) intended to protect the integrity of the signaling between the terminal and the RNC ("Radio Network Controller" in English, the element of the UMTS network which controls the radio transmissions of base stations - the RNC manages the distribution of the radio resource, the encryption of the data before sending it to the terminal, as well as part of the location of the subscribers).
  • RNC Radio Network Controller
  • Algorithms f1 to f5 are used to generate these parameters (see Figure 2).
  • a MAC 64 bits is also generated (to help the terminal to authenticate the network, not necessarily the VLR).
  • AK is an anonymity key generated from RAND and Ki.
  • the AuC generates an authentication vector from the key Ki that it shares with the USIM of the terminal as well as two other parameters which are: a sequence number
  • SQ Network is a counter arranged in the HLR / AuC and is individual for each
  • SQuicc is the largest sequence number that the USIM has accepted.
  • the authentication vector generated has five parts: the random value (RAND), the result (SRES) that will be requested in the challenge / response procedure with the USIM, the authentication token (AUTN) which allows the authentication of the network to the USIM, the session key (Kc) that will be used for encryption, and the integrity check key (Ik) that will be used to protect the integrity of the signaling messages.
  • RAND random value
  • SRES result
  • AUTN authentication token
  • Kc session key
  • Ik integrity check key
  • the authentication token AUTN is equal to:
  • AUTN (SQ Network ⁇ AK, AMF, MAC)
  • AK f5 (RAND, Ki) and AMF (16 bits) an authentication management field.
  • the VLR 1 upon receiving the quintuplet (RAND, AUTN, SRES, Kc, Ik), transmits the challenge RAND and the token of AUTN authentication that he has received from HLR at USIM and is waiting for an XRES response from USIM.
  • the quintuplet RAND, AUTN, SRES, Kc, Ik
  • AUTN is deconcatenated to recover MAC, AMF and
  • SQuicc is not too far from SQ Network (included in the above range)
  • f1 Ki, RAND, SQ Network
  • MAC MAC
  • the USIM also calculates XRES by applying RAND and Ki to the f2 algorithm.
  • the session key Kc is also calculated by applying RAND and the key Ki of the USIM to the algorithm f3.
  • the challenge / response procedure can be summarized as follows:
  • the USIM is authenticated by the VLR 1 1 if the XRES result calculated by the USIM and transmitted to the VLR is identical to the SRES received from the HLR / AuC 12.
  • the authentication token AUTN therefore allows the USIM to check whether the 'AuC is genuine and it is not a man-in-the-middle attack by the access network. On the other hand, if SRES is equal to XRES, the VLR considers that mutual authentication has succeeded. This provides mutual authentication between the network and the USIM.
  • This authentication mechanism is described in 3GPP TS 31.102 (for example in version 10.5.0 dated March 2012). It is based on the exchange of data in http (IP protocol).
  • the problem that the present invention proposes to solve is to allow mutual authentication between a security element (SIM card) and its network, in a GSM network, where the terminal cooperating with the security element can not correspond with the network. only by SMS.
  • This mutual authentication aims that a security element of GSM type does not connect to a false BTS.
  • a first problem to be solved to achieve this objective is to transmit to the SIM entity (detachable or not) cooperating with the terminal, not only the execution command of the authentication algorithm (AuthCmd (Rand)) including the value RAND random, but also an AUTN so that it can authenticate the element of the network which addresses itself to it.
  • This network element is either a VLR or an HLR / AuC.
  • a GSM security element receives only 128 bits of the network (length of RAND) and therefore does not accept to receive a 128-bit RAND and a 128-bit AUTN also.
  • a second problem solved by the present invention is that a simple authentication of the security element is optional in a network. It is the operator who decides whether to request authentication. Thus, if a security element of GSM type (SIM card for example) does not receive an authentication command, while it is in communication with the network, it can receive commands from this network without having been authenticated or without have authenticated the network. Malicious actions can then be launched from fake base stations.
  • GSM type SIM card for example
  • a third problem is that in a GSM network, the security element can correspond with the network only by SMS. If it has not been authenticated by the network after sending XRES (Fig.1), the network rejects any new message from this security element. It is therefore not possible to transmit, as in a UMTS network, a SQuicc resynchronization value to this network, as long as the security element has not been authenticated.
  • the present invention aims to solve these disadvantages.
  • the present invention proposes a method of mutual authentication between a security element of a telecommunications terminal and an element of a telecommunications network, the method applying in a GSM-type telecommunications network.
  • the method consists in:
  • a) Check that the value of a counter of the safety element is greater than a limit value and, if so: b) transmitting an SMS from the telecommunications terminal to the element of the telecommunications network, this SMS including the value of the sequence counter of the security element;
  • the method consists of retransmitting a new execution command of the authentication algorithm after step c) to the security element, this new command comprising the value of the sequence counter of the security element.
  • the method according to the invention consists in informing the user of the security element if the authentication key is not recognized by the security element and / or no longer responding to any command from the security network. telecommunications.
  • the security element calculates a value, transmits this value to the telecommunications network element and decrements the counter of the security element of a unit.
  • the method according to the invention advantageously consists in detecting that the telecommunications terminal is connected to the telecommunications network and that if the security element has not received an authentication request, the method consists in informing the user of the security element that the authentication request has not been received and / or to no longer respond to any command of the telecommunications network.
  • the method consists in informing the user of the security element and / or no longer responding to any command of the telecommunications network if the value of the counter of the security element is less than the limit value.
  • the authentication token is obtained from an AES comprising the random value.
  • the authentication token is equal to:
  • Ki the shared key between the network and the security element
  • CST a 16-byte constant
  • RNG a number occupying between 16 -
  • the authentication token is equal to:
  • AUTN Truncation (AES [Ki ® CST] (SQ Network
  • Ki the key shared between the network and the security element
  • CST a constant 16 bytes
  • SQ Network network sequence counter and RNG a number occupying between 16 -
  • Figure 1 shows the authentication procedure implemented in a GSM network
  • FIGS. 2 and 3 show the authentication procedure implemented in a UMTS network
  • FIG. 4 represents a mutual authentication procedure implemented in a GSM network according to the present invention.
  • FIG. 4 represents a mutual authentication procedure implemented in a GSM network according to the present invention.
  • the present invention proposes to perform mutual authentication between a security element, such as a card having a SIM functionality (extractable or integrated in a terminal, for example in an M2M terminal), and an element of a telecommunications network, this element can be an HLR / AuC or a VLR, in a GSM network.
  • a security element such as a card having a SIM functionality (extractable or integrated in a terminal, for example in an M2M terminal)
  • this element can be an HLR / AuC or a VLR, in a GSM network.
  • the invention proposes first to transmit instead of the RunGSMAIgo command (RAND), in a GSM network, an authentication command of the security element, this command comprising an AUTN which is a function of the shared key Ki and the sequence counter SQreseau.
  • RAND RunGSMAIgo command
  • AUTN which is a function of the shared key Ki and the sequence counter SQreseau.
  • the challenge to be addressed by the present invention is therefore to transmit an authentication command comprising an AUTN whose length does not exceed that of RAND traditionally used in GSM (16 bytes).
  • the secret key Ki used to calculate the authentication token AUTN is also used to calculate SRES and Kc. This avoids a decrease of security on this secret key.
  • AUTN In a first mode of implementation, implementing AES (Advanced Encryption Standard or AES) encryption, in ENC mode, the value of AUTN is equal to:
  • AUTN AES [Ki ⁇ CST] (SQ Network
  • SRES and the key Kc (which is a 64-bit session key used to encrypt OTA communication at the terminal in response to the received random value and its key Ki using the algorithm A8) is generally used in GSM to produce a figure of 16 bytes.
  • AUTN is also used as a random value RAND to calculate SRES and Kc. This does not represent a security problem since the AES is not used for SRES and Kc calculations.
  • the security element can decrypt AUTN to retrieve SQ Network
  • the interval must be chosen small enough that a random value of AUTN can be accepted by the security element with a high probability.
  • the constant CST is introduced to modify the key Ki deterministically when this key is used for the purpose of authenticating the network.
  • the introduction of this constant CST thus makes it possible to distinguish this joint use of the key
  • Ki and AES block ciphering system for other possible uses that might have different purposes.
  • RNG can be generated from a pseudo random generator. In this case, the acceptable distance between SQ Network and SQuicc can be chosen low. The value of
  • RNG can also be generated from including SQseau and allow to check a consistency in the input message. In this case, there is really no need to define a notion of distance between SQ Network and SQuicc and therefore the tolerance can be much more important. Finally, in a third mode of implementation, RNG can contain a predictable formatting / padding.
  • Valid AUTN is approximately 60/2
  • an AES block cipher is used to construct a MAC message authentication code associated with a message block:
  • AUTN which is here between 4 and 8 bytes.
  • AUTN is here transmitted in the concatenated RunGSMAIgo command with a RAND 'value which notably contains the value of SQreseau.
  • the value of RAND is obtained by the concatenation of AUTN and SQreseau, optionally with part of the binary string corresponding to RNG.
  • a part of the RNG bit string can be obtained by truncating the "padding" (bit adding) that is defined by formatting, for example, it may be the 0x8000 padding format * .
  • the SIM can verify AUTN, thanks to the knowledge of Ki and SQseau
  • the constant CST is introduced for the same reason as previously invoked.
  • a random selection of AUTN will only produce a valid AUTN for 1/2 of the cases, if the AUTN is 32 bits in length.
  • An element of the telecommunications network calculates (step 40) the value AUTN as previously indicated from SQ Network and the key Ki, and transmits an authentication command AuthCmd (AUTN) to the security element 10.
  • This command is called in the previously mentioned GSM standard RunGSMAIgo.
  • the security element 10 checks in a loop, during a step 41, if it received this command, until the reception thereof. Upon receipt of the authentication command, the security element 10 verifies, in a step 42, whether the received AUTN is correct, using SQsim and the key Ki stored locally.
  • SQsim is the sequence counter of the security element 10 and corresponds to the SQuicc sequence counter used in UMTS.
  • a step 43 it is checked whether the key Ki received from the network is correct. If it is not (step 44), the security element 10 enters a security state (refuses any further communication) and / or informs the user that an anomaly has occurred (because it has been be the object of an attack by a false base station).
  • the security element 10 verifies, in a step 45, that the sequence counter SQsim is within a certain interval with respect to the value of the network sequence counter SQseau .
  • the network (SQsetwork) and the security element 10 (SQsim) must be resynchronized. Before proceeding with this resynchronization, it is verified that the value of a counter C of the security element is greater than a limit value, during a step 46. If this limit value has been reached (for example the value the counter has reached 0), the security element 10 goes into a security state (step 44) and no longer accepts any network command. Incidentally, the security element informs the user through the human-machine interface of the equipment in which it is located.
  • the security element 10 calculates, during a step 47, the value XRES from its key Ki and the received AUTN. It also decrements the value of the previously mentioned counter C by one unit. The value of XRES is transmitted to the network during a step 48 and the network verifies that XRES is equal to SRES during a step 49. If equality is verified, it means that the security element knows the key Ki and mutual authentication is verified. The network and the security element are then ready to communicate (step 50).
  • the security element calculates, in a step 51, an AUTSsim value which is a function of SQsim and Ki.
  • This value is, according to the invention, encapsulated in an SMS and transmitted to the network (HLR / AuC). The latter then resynchronizes its SQseau with the value of SQsim received during a step 52.
  • the network then retransmits a new AUTN to the security element 10 in a new authentication command. Steps 41 to 48 are then reproduced and, in principle, an XRES should be transmitted to the network (step 48) during this new pass.
  • the security element 10 After execution of step 51, the security element 10 considers that it is ready to enter into communication (step 53) and expects from the VLR a message of acceptance of the requested service (transmission of voice, data or setting up an SMS service for example). This acceptance message will however be transmitted to the telecommunications terminal only when the mutual authentication is completed.
  • the counter C of the security element is provided in the present invention to allow the security element to transmit several SMS to the telecommunications network element (HLR). In theory, two SMSs are sufficient but more can be expected, depending on how long it will take the network to synchronize its SQ network with the received SQsim.
  • the invention also proposes a mandatory authentication of the network by the security element 10. For this purpose, it is proposed to verify, during a step 54, that the security element 10 is attached to the network. If it is not attached to the network, the step 41 of detection of reception of the authentication command is launched (RunGSMAIgo (AUTN) or AuthCmd (AUTN)). If the security element is attached to the network, it is verified in a step 55 that the network has been authenticated. If this is the case, the terminal waits for the requested service (step 53). In the opposite case, the security element 10 goes into a state where it no longer accepts commands from the network and / or possibly informs the user that the network has not been authenticated (step 56). This forces the network to authenticate to the security element, otherwise the security element becomes inoperative.
  • the invention requires only modifications at the level of the HLR / AuC and at the level of the security element, it is therefore without consequences at the terminals communicating with these security elements, for example at the level of vehicles or machines which embark them. Only the introduction of an AUTN in the authentication request command of the terminal 2G is introduced (with the known RAND), which does not require modification of the 2G protocols.

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

L'invention concerne un procédé d'authentification mutuelle entre un élément de sécurité (10) d'un terminal de télécommunications et un élément d'un réseau de télécommunications (11/12), le procédé s'appliquant dans un réseau de télécommunications de type GSM, le procédé consistant à: Transmettre du réseau de télécommunications à l'élément de sécurité (10) une commande d'exécution d'un algorithme d'authentification comprenant un jeton d'authentification (AUTN) élaboré par l'élément du réseau de télécommunications à partir d'une clé d'authentification (Ki) et la valeur d'un compteur de séquence réseau (SQréseau); Exécuter l'algorithme au niveau de l'élément de sécurité (10) et, si la clé d'authentification (Ki) est reconnue par l'élément de sécurité (10), vérifier qu'une valeur de compteur de séquence (SQsim) de l'élément de sécurité (10) est comprise dans un intervalle déterminé par rapport à la valeur du compteur de séquence réseau (SQréseau) et, si la valeur du compteur de séquence réseau (SQréseau) n'est pas comprise dans l'intervalle déterminé: a) Vérifier que la valeur d'un compteur de l'élément de sécurité (10) est supérieure à une valeur limite et, si oui: b) Transmettre un SMS du terminal de télécommunications à l'élément du réseau de télécommunications (11/12), cet SMS comprenant la valeur du compteur de séquence (SQsim) de l'élément de sécurité (10); c) Au niveau de l'élément du réseau de télécommunications (11/12), synchroniser la valeur du compteur de séquence réseau (SQréseau) avec la valeur du compteur de séquence (SQsim) de l'élément de sécurité (10).

Description

Procédé d'authentification mutuelle entre un élément de sécurité d'un terminal de télécommunications et un élément d'un réseau de télécommunications de type GSM
Le domaine de l'invention est celui des télécommunications dans des réseaux cellulaires de type GSM (2G).
Plus précisément, la présente invention concerne un procédé d'authentification mutuelle entre d'une part un élément de sécurité d'un terminal de télécommunications et d'autre part un élément d'un réseau de télécommunications cellulaire de seconde génération.
Plusieurs générations de réseaux de télécommunications cellulaires coexistent actuellement : les réseaux 2G (GSM), les réseaux 3G (UMTS) et les réseaux 4G (LTE).
Tous ces réseaux ont notamment pour vocation de permettre d'établir des communications entre des terminaux communiquant avec des éléments de sécurité (cartes SIM, UICC, USIM,...).
Ces éléments de sécurité se présentent habituellement sous la forme de cartes extractibles de leurs terminaux, habituellement constitués par des téléphones mobiles, des smartphones, des PDAs,... Il existe également des éléments de sécurité intégrés dans des modems faisant partie de terminaux ou de machines (donc non extractibles), ces machines étant des véhicules, des distributeurs de boissons, etc ..
Les communications dans des réseaux de télécommunications ont évolué depuis plusieurs années : elles étaient (et sont toujours) essentiellement dédiées aux communications entre personnes physiques disposant de terminaux portables par exemple . Depuis quelques années, on assiste à une augmentation de communications entre machines, aussi appelées M2M (« Machine To Machine » en anglais).
Ce type de communications entre machines permet notamment d'effectuer des relevés de compteurs à distance (eau, électricité,..) ou d'interagir avec des véhicules automobiles (par exemple pour ouvrir leurs portes à distance, démarrer le véhicule, mettre en marche la climatisation,...). Il permet également d'ouvrir des portails à distance, fermer des volets électriques, ou plus généralement d'effectuer des fonctions de type domotique.
Les réseaux 2G permettent donc des communications de type M2M où un utilisateur peut activer une fonction sur un terminal distant.
Un des problèmes de ces communications M2M dans des réseaux de deuxième génération (GSM) est que seuls les éléments de sécurité sont authentifiés par les réseaux avec lesquels ils communiquent : il n'y a pas d'authentification du réseau par l'élément de sécurité en GSM.
L'authentification permet de vérifier que l'identité (IMSI ou TMSI) transmise par le terminal communiquant avec la carte SIM sur la voie radio est correcte afin de protéger d'une part l'opérateur contre l'utilisation frauduleuse de ses ressources, et d'autre part les abonnés en interdisant à des tierces personnes non autorisées d'utiliser leurs comptes. L'authentification de l'abonné peut être exigée du mobile par le réseau à chaque mise à jour de localisation, établissement d'appel (entrant ou sortant) et avant d'activer ou de désactiver certains services supplémentaires. Elle est également demandée lors de la mise en oeuvre de la clé de chiffrement sur certains canaux dédiés.
L'authentification GSM est basée sur un protocole de type challenge/response ainsi que sur des algorithmes de cryptographie à clé secrète. Cependant, comme déjà indiqué précédemment, dans un schéma GSM, le réseau authentifie la carte SIM mais la carte SIM n'authentifie pas le réseau. La carte SIM du terminal n'est donc pas en mesure de vérifier l'identité et la validité du réseau auquel le mobile est rattaché. Des attaques par de fausses stations de base sont donc possibles et ont d'ailleurs été observées, notamment dans le domaine M2M, où des portes de véhicules équipés d'applications SIMs ont pu être ouvertes à distance.
On se référera notamment à l'article intitulé « M2M Security - War texting Attacks » disponible à l'adresse suivante : http://m2m.gemalto.com/news-info/whitepapers.html.
Une solution à ce problème serait d'utiliser un mécanisme d'authentification de type 3G (UMTS) où une authentification mutuelle entre l'USIM (Universal SIM) et le réseau est réalisée. Cette solution ne s'applique cependant pas dans le cadre d'applications M2M car les modules M2M utilisent essentiellement une technologie GSM et non pas UMTS.
Le problème est donc que de très nombreux dispositifs actuels, notamment en M2M, utilisent des mécanismes GSM et non pas des mécanismes UMTS ou LTE pour leur authentification. Il n'existe donc pas de mécanisme d'authentification mutuelle dans les communications de type M2M.
La figure 1 représente le mécanisme d'authentification retenu pour le GSM.
Un terminal comprenant un élément de sécurité tel qu'une carte SIM 10 communique avec son HLR/AuC 12 par l'intermédiaire d'un VLR 1 1. La carte SIM 10 transmet son IMSI (ou TMSI) au VLR 1 1 qui le retransmet au HLR/AuC 12. Celui-ci récupère la clé Ki unique correspondant à cet IMSI (TMSI) et génère une valeur aléatoire RAND de longueur 128 bits (16 octets). Un algorithme appelé A3 permet de générer une valeur SRES à partir de la clé Ki et de la valeur aléatoire RAND. Un autre algorithme, appelé A8, génère une clé de chiffrement Kc à partir de Ki et de RAND. Cette clé Kc sert de clé de chiffrement pour le trafic de l'usager et le trafic de signalisation entre le terminal et la station de base (BTS). Le HLR/AuC 12 transmet les valeurs RAND, SRES et Kc au VLR 1 1 qui retransmet uniquement la valeur aléatoire RAND à la carte SIM 10 dans une commande d'authentification AuthCmd(Rand). La carte SIM 10 comprend la clé Ki utilisée par le HLR 12 et calcule, à l'aide de l'algorithme A3, une valeur XRES, à l'aide de la valeur aléatoire RAND reçue. Elle calcule par ailleurs la clé de chiffrement Kc à l'aide des mêmes éléments. La carte SIM 10 renvoie alors au VLR 1 1 la valeur XRES calculée localement. Le VLR procède alors à la comparaison de SRES et de XRES. Si les deux résultats sont identiques, l'abonné est authentifié. Dans le cas contraire, l'accès au réseau est refusé au terminal.
Nous décrivons ci-après le mécanisme d'authentification mis en œuvre dans un réseau 3G (UMTS).
L'authentification 3G (AKA pour Authentication and Key Agreement) est, comme en GSM, basée sur une clé partagée Ki qui est uniquement présente dans le HLR et la carte USIM. Comme le HLR ne communique jamais directement avec le terminal, le VLR du serveur MSC réalise la procédure d'authentification.
Un à cinq vecteurs d'authentification (AV, Authentication Vector) sont téléchargés par le serveur MSC à partir du HLR lorsque le serveur MSC reçoit du terminal une demande d'attachement.
Les paramètres présents dans l'AV sont :
• RAND - le challenge qui sert en tant qu'un des paramètres d'entrée pour générer les 4 autres paramètres de l'AV. RAND est codé sur 128 bits ;
• SRES - le résultat attendu, utilisé par le réseau pour l'authentification de l'USIM (32 à 128 bits) ;
• AUTN - le jeton d'authentification utilisé par l'USIM pour l'authentification réseau (128 bits) ;
• Kc - la clé de session utilisée pour le chiffrement des communications (128 bits) ;
• Ik - une clé d'intégrité (128 bits) destinée à la protection de l'intégrité de la signalisation entre le terminal et le RNC (« Radio Network Controller » en anglais, l'élément du réseau UMTS qui contrôle les transmissions radio des stations de base - le RNC gère la répartition de la ressource radio, le chiffrement des données avant l'envoi au terminal, ainsi qu'une partie de la localisation des abonnés).
Des algorithmes f1 à f5 sont utilisés pour générer ces paramètres (voir figure 2). Un MAC (64 bits) est également généré (pour aider le terminal à authentifier le réseau, pas nécessairement le VLR). AK est une clé d'anonymat générée à partir de RAND et de Ki.
L'AuC génère un vecteur d'authentification à partir de la clé Ki qu'il partage avec l'USIM du terminal ainsi que deux autres paramètres qui sont : un numéro de séquence
SQréseau (48 bits) et le nombre pseudo aléatoire RAND.
SQréseau est un compteur disposé dans le HLR/AuC et est individuel pour chaque
USIM. De son côté, l'USIM garde trace d'un compteur de séquences appelé par la suite
SQuicc qui est le plus grand numéro de séquences que l'USIM a accepté. Le vecteur d'authentification généré comporte cinq parties : la valeur aléatoire (RAND), le résultat (SRES) qui sera demandé dans la procédure challenge/response avec l'USIM, le jeton d'authentification (AUTN) qui permet l'authentification du réseau auprès de l'USIM, la clé de session (Kc) qui servira pour le chiffrement, et la clé de contrôle d'intégrité (Ik) qui servira à la protection de l'intégrité des messages de signalisation.
Le jeton d'authentification AUTN est égal à :
AUTN = (SQréseau © AK, AMF, MAC)
Avec AK = f5(RAND, Ki) et AMF (16 bits) un champ de gestion d'authentification.
Comme représenté sur la figure 3, après transmission de l'IMSI au HLR/AuC 12, le VLR 1 1 , à la réception du quintuplé (RAND, AUTN, SRES, Kc, Ik), transmet le challenge RAND et le jeton d'authentification AUTN qu'il a reçu du HLR à l'USIM et attend une réponse XRES de ce dernier.
Au niveau de l'USIM, AUTN est déconcaténé pour récupérer MAC, AMF et
SQréseau © AK. Il calcule alors f5(RAND, Ki) = AK et en déduit SQréseau.
Si SQuicc est trop éloigné de SQréseau (non compris dans une certaine plage), l'USIM procède à une phase de resynchronisation avec le réseau.
Si SQuicc n'est pas trop éloigné de SQréseau (compris dans la plage précitée), il calcule f1 (Ki, RAND, SQréseau) = XMAC et le compare à MAC. S'ils sont égaux, le réseau est authentifié par l'USIM.
L'USIM calcule également XRES en appliquant RAND et Ki à l'algorithme f2. La clé de session Kc est également calculée en appliquant RAND et la clé Ki de l'USIM à l'algorithme f3.
La procédure challenge/response peut donc être résumée comme suit :
L'USIM est authentifiée par le VLR 1 1 si le résultat XRES calculé par l'USIM et transmis au VLR est identique à SRES reçu du HLR/AuC 12. Le jeton d'authentification AUTN permet donc à l'USIM de vérifier si l'AuC est authentique et qu'il ne s'agit pas d'une attaque de type « man in the middle » par le réseau d'accès. Par ailleurs, si SRES est égal à XRES, le VLR considère que l'authentification mutuelle a abouti. On réalise ainsi une authentification mutuelle entre le réseau et l'USIM.
Ce mécanisme d'authentification est décrit dans 3GPP TS 31.102 (par exemple dans sa version 10.5.0 datée de mars 2012). Il repose sur l'échange de données en http (protocole IP).
Le problème que se propose de résoudre la présente invention est de permettre une authentification mutuelle entre un élément de sécurité (carte SIM) et son réseau, dans un réseau GSM, où le terminal coopérant avec l'élément de sécurité ne peut correspondre avec le réseau que par des SMS. Cette authentification mutuelle a pour but qu'un élément de sécurité de type GSM ne se connecte pas à une fausse BTS. Un premier problème à résoudre pour atteindre cet objectif est de transmettre à l'entité SIM (détachable ou non) coopérant avec le terminal, non seulement la commande d'exécution de l'algorithme d'authentification (AuthCmd(Rand)) comprenant la valeur aléatoire RAND, mais aussi un AUTN pour que celle-ci puisse authentifier l'élément du réseau qui s'adresse à elle. Cet élément du réseau est soit un VLR soit un HLR/AuC.
Le problème est qu'un élément de sécurité GSM ne reçoit que 128 bits du réseau (longueur de RAND) et n'accepte donc pas de recevoir un RAND de 128 bits et un AUTN de 128 bits également.
Un deuxième problème résolu par la présente invention est qu'une simple authentification de l'élément de sécurité est facultative dans un réseau. C'est l'opérateur qui décide s'il demande une authentification. Ainsi, si un élément de sécurité de type GSM (carte SIM par exemple) ne reçoit pas de commande d'authentification, alors qu'elle est en communication avec le réseau, elle peut recevoir des commandes de ce réseau sans avoir été authentifiée ou sans avoir authentifié le réseau. Des actions malveillantes peuvent alors être lancées à partir de fausses stations de base.
Un troisième problème est que, dans un réseau GSM, l'élément de sécurité ne peut correspondre avec le réseau que par SMS. S'il n'a pas été authentifié par le réseau après l'envoi de XRES (Fig.1 ), le réseau rejette tout nouveau message de cet élément de sécurité. Il n'est donc pas possible de transmettre, comme dans un réseau UMTS, une valeur de resynchronisation SQuicc à ce réseau, aussi longtemps que l'élément de sécurité n'a pas été authentifié.
La présente invention a pour objectif de résoudre ces inconvénients.
Plus précisément, la présente invention propose un procédé d'authentification mutuelle entre un élément de sécurité d'un terminal de télécommunications et un élément d'un réseau de télécommunications, le procédé s'appliquant dans un réseau de télécommunications de type GSM. Selon l'invention, le procédé consiste à :
Transmettre du réseau de télécommunications à l'élément de sécurité une commande d'exécution d'un algorithme d'authentification comprenant un jeton d'authentification élaboré par l'élément dudit réseau de télécommunications à partir d'une clé d'authentification et la valeur d'un compteur de séquence réseau ;
Exécuter l'algorithme au niveau de l'élément de sécurité et, si la clé d'authentification est reconnue par l'élément de sécurité, vérifier qu'une valeur de compteur de séquence de l'élément de sécurité est comprise dans un intervalle déterminé par rapport à la valeur du compteur de séquence réseau et, si la valeur du compteur de séquence réseau n'est pas comprise dans l'intervalle déterminé :
a) Vérifier que la valeur d'un compteur de l'élément de sécurité est supérieure à une valeur limite et, si oui : b) Transmettre un SMS du terminal de télécommunications à l'élément du réseau de télécommunications, ce SMS comprenant la valeur du compteur de séquence de l'élément de sécurité ;
c) Au niveau de l'élément du réseau de télécommunications, synchroniser la valeur du compteur de séquence réseau avec la valeur du compteur de séquence de l'élément de sécurité.
Préférentiellement, le procédé consiste à retransmettre une nouvelle commande d'exécution de l'algorithme d'authentification après l'étape c) à l'élément de sécurité, cette nouvelle commande comprenant la valeur du compteur de séquence de l'élément de sécurité.
Avantageusement, le procédé selon l'invention consiste à informer l'utilisateur de l'élément de sécurité si la clé d'authentification n'est pas reconnue par l'élément de sécurité et/ou à ne plus répondre à aucune commande du réseau de télécommunications.
Préférentiellement, si la valeur du compteur de séquence réseau est comprise dans l'intervalle déterminé, l'élément de sécurité calcule une valeur, transmet cette valeur à l'élément du réseau de télécommunications et décrémente le compteur de l'élément de sécurité d'une unité.
Le procédé selon l'invention consiste avantageusement à détecter que le terminal de télécommunications est connecté au réseau de télécommunications et que si l'élément de sécurité n'a pas reçu de demande d'authentification, le procédé consiste à informer l'utilisateur de l'élément de sécurité que la demande d'authentification n'a pas été reçue et/ou à ne plus répondre à aucune commande du réseau de télécommunications.
Préférentiellement, le procédé consiste à informer l'utilisateur de l'élément de sécurité et/ou à ne plus répondre à aucune commande du réseau de télécommunications si la valeur du compteur de l'élément de sécurité est inférieure à la valeur limite.
Avantageusement, le jeton d'authentification est obtenu à partir d'un AES comprenant la valeur aléatoire.
Dans un mode de mise en œuvre préférentiel, le jeton d'authentification est égal à :
AUTN = AES [Ki © CST] (SQréseau || RNG)
avec Ki la clé partagée entre le réseau et l'élément de sécurité, CST une constante sur 16 octets, SQréseau le compteur de séquence réseau, RNG un nombre occupant entre 16 - |SQréseau| octets et AUTN sur 16 octets.
Dans un autre mode de mise en œuvre préférentiel, le jeton d'authentification est égal à :
AUTN = Truncation (AES [Ki ® CST] (SQréseau || RNG) avec AUTN compris entre
4 et 8 octets, avec Ki la clé partagée entre le réseau et l'élément de sécurité, CST une constante sur 16 octets, SQréseau le compteur de séquence réseau et RNG un nombre occupant entre 16 - |SQréseau| octets.
D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante d'un mode de mise en œuvre préférentiel, donné à titre illustratif et non limitatif, et des figures annexées, dans lesquelles :
La figure 1 représente la procédure d'authentification mise en œuvre dans un réseau GSM ;
Les figures 2 et 3 représentent la procédure d'authentification mise en œuvre dans un réseau UMTS ;
- La figure 4 représente une procédure d'authentification mutuelle mise en œuvre dans un réseau GSM selon la présente invention.
Les figures 1 à 3 ont été décrites précédemment en référence à l'état de la technique.
La figure 4 représente une procédure d'authentification mutuelle mise en œuvre dans un réseau GSM selon la présente invention.
La présente invention propose de réaliser une authentification mutuelle entre un élément de sécurité, tel qu'une carte ayant une fonctionnalité SIM (extractible ou intégrée dans un terminal, par exemple dans un terminal M2M), et un élément d'un réseau de télécommunications, cet élément pouvant être un HLR/AuC ou un VLR, dans un réseau GSM.
A cette fin, l'invention propose d'abord de transmettre à la place de la commande RunGSMAIgo (RAND), dans un réseau GSM, une commande d'authentification de l'élément de sécurité, cette commande comprenant un AUTN qui est fonction de la clé partagée Ki et du compteur de séquences SQréseau.
Le challenge auquel se propose de répondre la présente invention est donc de transmettre une commande d'authentification comprenant un AUTN dont la longueur ne dépasse pas celle de RAND traditionnellement utilisée en GSM (16 octets).
Les considérations préliminaires sont prises en compte dans la présente invention : La clé secrète Ki utilisée pour calculer le jeton d'authentification AUTN est également utilisée pour calculer SRES et Kc. Ceci permet d'éviter une baisse de sécurité sur cette clé secrète.
Dans un premier mode de mise en œuvre, mettant en œuvre un chiffrement AES (Advanced Encryption Standard ou AES (soit « standard de chiffrement avancé » en français), en mode ENC, la valeur d'AUTN est égale à :
AUTN = AES [Ki © CST] (SQréseau || RNG) avec Ki la clé partagée sur 16 octets, CST une constante sur 16 octets, SQréseau un nombre occupant entre 4 et 16 octets, RNG un nombre occupant entre 16 - |SQréseau| octets et AUTN sur 16 octets, soit la longueur d'un RAND en GSM.
Le calcul de SRES et de la clé Kc (qui est une clé de session de 64 bits utilisée pour chiffrer la communication OTA au niveau du terminal en réponse à la valeur aléatoire reçue et de sa clé Ki en utilisant l'algorithme A8) est généralement utilisé en GSM pour produire un chiffre de 16 octets.
Les considérations prises en compte sont les suivantes :
La valeur d'AUTN est également utilisée en tant que valeur aléatoire RAND pour calculer SRES et Kc. Ceci ne représente pas de problème de sécurité à partir du moment que l'AES n'est pas utilisé pour les calculs de SRES et de Kc.
L'élément de sécurité peut déchiffrer AUTN pour récupérer SQréseau || RNG, vérifier que SQréseau est dans le bon intervalle et choisir de ne pas calculer SRES et Kc.
L'intervalle doit être choisi suffisamment petit pour qu'une valeur aléatoire d'AUTN puisse être acceptée par l'élément de sécurité avec une grande probabilité.
La constante CST est introduite afin de modifier la clé Ki de manière déterministe lorsque cette clé est utilisée dans le but d'authentifier le réseau. L'introduction de cette constante CST permet donc de pouvoir distinguer cette utilisation conjointe de la clé
Ki et du système de chiffrement par bloc AES d'autres utilisations éventuelles qui pourraient avoir des buts différents.
RNG peut être généré à partir d'un générateur pseudo aléatoire. Dans ce cas, la distance acceptable entre SQréseau et SQuicc pourra être choisie faible. La valeur de
RNG peut également être générée à partir notamment de SQréseau et permettre de vérifier une consistance dans le message d'entrée. Dans ce cas, il n'y a pas vraiment besoin de définir une notion de distance entre SQréseau et SQuicc et donc la tolérance peut être beaucoup plus importante. Enfin, dans un troisième mode de mise en œuvre, RNG peut contenir un formatage/padding prédictible.
Afin de générer un AUTN valable, il est nécessaire de générer un AES chiffré valable associé à un message en clair valable. En considérant par exemple 60 messages en clair (60 bits étant la longueur de SQréseau), la probabilité d'un attaquant de générer un
128
AUTN valable est approximativement de 60/2
Une recherche exhaustive de la clé Ki à partir de la connaissance d'AUTN 127
nécessite 2 recherches en moyenne.
Dans un deuxième mode de mise en œuvre, on utilise un chiffrement par bloc AES afin de construire un code d'authentication de message MAC associé à un bloc de message:
L'AUTN peut se calculer de la façon suivante : AUTN = Truncation (AES [Ki © CST] (SQréseau || RNG)
avec les valeurs précédemment indiquées, sauf pour l'AUTN qui est ici compris entre 4 et 8 octets. AUTN est ici transmis dans la commande RunGSMAIgo concaténé avec une valeur RAND' qui contient notamment la valeur de SQréseau.
Les calculs de SRES et de Kc sont effectués comme précédemment.
Les considérations à prendre en compte sont ici les suivantes :
La valeur de RAND est obtenue par la concaténation d'AUTN et de SQréseau, avec optionnellement une partie de la chaîne binaire correspondant à RNG. A titre d'exemple, une partie de la chaîne binaire de RNG peut être obtenue en effectuant une troncation du « padding » (ajout de bits) qui est définit par le formatage, par exemple, il peut s'agir du format de padding 0x8000*.
La valeur de SQréseau est transmise en clair.
La SIM peut vérifier AUTN, grâce à la connaissance de Ki et de SQréseau || RNG. La constante CST est introduite pour la même raison que précédemment invoquée.
32
- Un choix aléatoire d'AUTN ne produira un AUTN valable pour 1/2 des cas, si l'AUTN est de longueur 32 bits.
La connaissance d'un seul AUTN ne permet pas de retrouver une clé Ki unique.
Les deux solutions précédemment exposées utilisant l'AES permettent donc d'assurer une protection maximale en cas d'attaque par une fausse BTS.
D'autres solutions sont bien sûr possibles, le demandeur ayant présenté les solutions les plus optimales pour transmettre un AUTN au terminal dans un réseau GSM, en tant que nombre aléatoire ou en même temps qu'un nombre aléatoire RAND', sans aucune modification des protocoles standardisés en 2G. Comme dans un réseau 3G, AUTN est calculé à partir de SQréseau et de la clé Ki.
En regard de la figure 4, le procédé d'authentification mutuelle selon l'invention est présenté.
Un élément du réseau de télécommunications, soit un VLR 1 1 , soit le HLR/AuC 12 du réseau auquel l'utilisateur de l'élément de sécurité 10 est abonné, calcule (étape 40) la valeur AUTN comme précédemment indiqué à partir de SQréseau et de la clé Ki, et transmet une commande d'authentification AuthCmd(AUTN) à l'élément de sécurité 10. Cette commande s'appelle dans le standard GSM précédemment mentionné RunGSMAIgo. L'élément de sécurité 10 vérifie en boucle, lors d'une étape 41 , s'il a reçu cette commande, jusqu'à la réception de celle-ci. A réception de la commande d'authentification, l'élément de sécurité 10 vérifie, lors d'une étape 42, si l'AUTN reçu est correct, à l'aide de SQsim et de la clé Ki stockée localement. SQsim est le compteur de séquences de l'élément de sécurité 10 et correspond au compteur de séquences SQuicc utilisé en UMTS. D'abord, lors d'une étape 43, il est vérifié si la clé Ki reçue du réseau est correcte. Si elle ne l'est pas (étape 44), l'élément de sécurité 10 se met en état de sécurité (refuse toute nouvelle communication) et/ou informe l'utilisateur qu'une anomalie s'est produite (car elle a pu être l'objet d'une attaque par une fausse station de base).
Ensuite, si la clé Ki reçue du réseau est correcte, l'élément de sécurité 10 vérifie, lors d'une étape 45, que le compteur de séquences SQsim est compris dans un intervalle déterminé par rapport à la valeur du compteur de séquence réseau SQréseau.
Si le compteur de séquences SQsim n'est pas compris dans l'intervalle déterminé, il faut resynchroniser le réseau (SQréseau) et l'élément de sécurité 10 (SQsim). Avant de procéder à cette resynchronisation, il est vérifié que la valeur d'un compteur C de l'élément de sécurité est supérieure à une valeur limite, lors d'une étape 46. Si cette valeur limite a été atteinte (par exemple la valeur du compteur est arrivée à 0), l'élément de sécurité 10 se met en état de sécurité (étape 44) et n'accepte plus aucune commande du réseau. Accessoirement, l'élément de sécurité informe l'utilisateur par l'interface homme-machine de l'équipement dans lequel il se trouve.
Si la valeur limite n'a pas été atteinte, l'élément de sécurité 10 calcule, lors d'une étape 47, la valeur XRES à partir de sa clé Ki et de l'AUTN reçu. Il décrémente également la valeur du compteur C précédemment mentionné d'une unité. La valeur de XRES est transmise au réseau lors d'une étape 48 et le réseau vérifie que XRES est égal à SRES lors d'une étape 49. Si l'égalité est vérifiée, cela signifie que l'élément de sécurité connaît la clé Ki et l'authentification mutuelle est vérifiée. Le réseau et l'élément de sécurité sont alors prêts à communiquer (étape 50).
Si la valeur du compteur C de l'élément de sécurité n'a pas atteint la valeur limite et si SQsim n'est pas dans l'intervalle déterminé, l'élément de sécurité calcule, lors d'une étape 51 , une valeur AUTSsim qui est fonction de SQsim et de Ki. Cette valeur est, selon l'invention, encapsulée dans un SMS et transmise au réseau (HLR/AuC). Ce dernier resynchronise alors son SQréseau avec la valeur de SQsim reçue, lors d'une étape 52. Le HLR/AuC et l'élément de sécurité comprennent alors les mêmes valeurs de compteur de séquence (SQsim = SQréseau). Le réseau retransmet alors un nouveau AUTN à l'élément de sécurité 10 dans une nouvelle commande d'authentification. Les étapes 41 à 48 sont alors reproduites et, en principe, un XRES devrait être transmis au réseau (étape 48) lors de cette nouvelle passe.
Après exécution de l'étape 51 , l'élément de sécurité 10 considère qu'il est prêt à entrer en communication (étape 53) et attend de la part du VLR un message d'acceptation du service demandé (transmission de voix, données ou mise en place d'un service SMS par exemple). Ce message d'acceptation ne sera cependant transmis au terminal de télécommunications que lorsque l'authentification mutuelle sera achevée. Le compteur C de l'élément de sécurité est prévu dans la présente invention pour permettre à l'élément de sécurité de transmettre plusieurs SMS à l'élément du réseau (HLR) de télécommunications. En théorie, deux SMS sont suffisants mais on peut en prévoir plus, ceci dépendant du temps que mettra le réseau pour synchroniser son SQréseau avec le SQsim reçu.
L'invention propose également une authentification obligatoire du réseau par l'élément de sécurité 10. A cet effet, il est proposé de vérifier, lors d'une étape 54, que l'élément de sécurité 10 est bien attaché au réseau. S'il n'est pas attaché au réseau, l'étape 41 de détection de réception de la commande d'authentification est lancée (RunGSMAIgo (AUTN) ou encore AuthCmd (AUTN)). Si l'élément de sécurité est attaché au réseau, on vérifie, lors d'une étape 55, que le réseau a été authentifié. Si c'est le cas, le terminal attend le service demandé (étape 53). Dans le cas contraire, l'élément de sécurité 10 passe dans un état où il n'accepte plus de commandes du réseau et/ou informe éventuellement l'utilisateur que le réseau n'a pas été authentifié (étape 56). Ceci oblige le réseau à s'authentifier auprès de l'élément de sécurité, sans quoi ce dernier devient inopérant.
L'invention ne nécessite que des modifications au niveau du HLR/AuC et au niveau de l'élément de sécurité, elle est donc sans conséquences au niveau des terminaux communiquant avec ces éléments de sécurité, par exemple au niveau de véhicules ou de machines qui les embarquent. Seule l'introduction d'un AUTN dans la commande de demande d'authentification du terminal 2G est introduite (avec le RAND connu), ce qui ne nécessite pas de modification des protocoles 2G.

Claims

REVENDICATIONS
1 . Procédé d'authentification mutuelle entre un élément de sécurité (10) d'un terminal de télécommunications et un élément (1 1/12) d'un réseau de télécommunications, ledit procédé s'appliquant dans un réseau de télécommunications de type GSM, ledit procédé consistant à :
Transmettre dudit réseau de télécommunications audit élément de sécurité (10) une commande d'exécution d'un algorithme d'authentification comprenant un jeton d'authentification (AUTN) élaboré par ledit élément (1 1/12) dudit réseau de télécommunications à partir d'une clé d'authentification (Ki) et la valeur d'un compteur de séquence réseau (SQréseau) ;
Exécuter ledit algorithme au niveau dudit élément de sécurité (10) et, si ladite clé d'authentification (Ki) est reconnue par ledit élément de sécurité (10), vérifier qu'une valeur de compteur de séquence (SQsim) dudit élément de sécurité (10) est comprise dans un intervalle déterminé par rapport à ladite valeur dudit compteur de séquence réseau (SQréseau) et, si ladite valeur dudit compteur de séquence réseau (SQréseau) n'est pas comprise dans ledit intervalle déterminé :
a) Vérifier que la valeur d'un compteur dudit élément de sécurité (10) est supérieure à une valeur limite et, si oui :
b) Transmettre un SMS dudit terminal de télécommunications audit élément
(1 1/12) dudit réseau de télécommunications, ledit SMS comprenant ladite valeur dudit compteur de séquence dudit élément de sécurité (SQsim) ;
c) Au niveau dudit élément dudit réseau de télécommunications (1 1/12), synchroniser la valeur dudit compteur de séquence réseau (SQréseau) avec ladite valeur dudit compteur de séquence dudit élément de sécurité (SQsim).
2. Procédé selon la revendication 1 , caractérisé en ce qu'il consiste à retransmettre une nouvelle commande d'exécution dudit algorithme d'authentification après l'étape c) audit élément de sécurité (10), ladite nouvelle commande comprenant ladite valeur dudit compteur de séquence (SQsim) dudit élément de sécurité (10).
3. Procédé selon l'une des revendications 1 et 2, caractérisé en ce qu'il consiste à informer l'utilisateur dudit élément de sécurité (10) si ladite clé d'authentification (Ki) n'est pas reconnue par ledit élément de sécurité (10) et/ou à ne plus répondre à aucune commande dudit réseau de télécommunications.
4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que si ladite valeur dudit compteur de séquence réseau (SQréseau) est comprise dans ledit intervalle déterminé, ledit élément de sécurité (10) calcule une valeur (XRES), transmet cette valeur audit élément dudit réseau de télécommunications (1 1/12) et décrémente ledit compteur dudit élément de sécurité (10) d'une unité.
5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce qu'il consiste à détecter que ledit terminal de télécommunications est connecté audit réseau de télécommunications et que si ledit élément de sécurité (10) n'a pas reçu de demande d'authentification, ledit procédé consiste à informer l'utilisateur dudit élément de sécurité (10) que ladite demande d'authentification n'a pas été reçue et/ou à ne plus répondre à aucune commande dudit réseau de télécommunications.
6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce qu'il consiste à informer l'utilisateur dudit élément de sécurité (10) et/ou à ne plus répondre à aucune commande dudit réseau de télécommunications si ladite valeur dudit compteur dudit élément de sécurité est inférieure à ladite valeur limite.
7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que ledit jeton d'authentification est obtenu à partir d'un AES comprenant ladite valeur aléatoire (RAND).
8. Procédé selon la revendication 7, caractérisé en ce que ledit jeton d'authentification est égal à :
AUTN = AES [Ki © CST] (SQréseau || RNG)
avec Ki la clé partagée entre ledit réseau et ledit élément de sécurité (10), CST une constante sur 16 octets, SQréseau ledit compteur de séquence réseau, RNG un nombre occupant entre 16 - |SQréseau| octets et AUTN sur 16 octets.
9. Procédé selon la revendication 7, caractérisé en ce que ledit jeton d'authentification est égal à :
AUTN = Truncation (AES [Ki ® CST] (SQréseau || RNG) avec AUTN compris entre 4 et 8 octets, avec Ki la clé partagée entre ledit réseau et ledit élément de sécurité (10), CST une constante sur 16 octets, SQréseau ledit compteur de séquence réseau et RNG un nombre occupant entre 16 - |SQréseau| octets.
PCT/EP2014/055840 2013-03-25 2014-03-24 Procede d'authentification mutuelle entre un element de securite d'un terminal de telecommunications et un element d'un reseau de telecommunications de type gsm Ceased WO2014154634A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP13305364.5A EP2785090A1 (fr) 2013-03-25 2013-03-25 Procédé d'authentification mutuelle entre un élément de sécurité d'un terminal de télécommunications et un élément d'un réseau de télécommunications de type GSM
EP13305364.5 2013-03-25

Publications (1)

Publication Number Publication Date
WO2014154634A1 true WO2014154634A1 (fr) 2014-10-02

Family

ID=48236819

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2014/055840 Ceased WO2014154634A1 (fr) 2013-03-25 2014-03-24 Procede d'authentification mutuelle entre un element de securite d'un terminal de telecommunications et un element d'un reseau de telecommunications de type gsm

Country Status (2)

Country Link
EP (1) EP2785090A1 (fr)
WO (1) WO2014154634A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017128542A1 (fr) * 2016-01-29 2017-08-03 宇龙计算机通信科技(深圳)有限公司 Procédé de résidence dans un réseau, système de résidence dans un réseau, et terminal

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109714310A (zh) * 2018-11-07 2019-05-03 苏州蜗牛数字科技股份有限公司 一种sim卡的侧信道抗攻击方法
EP3651489A1 (fr) * 2018-11-08 2020-05-13 Thales Dis France SA Procédé d'authentification d'un élément sécurisé coopérant avec un terminal, applet, système et serveur correspondants

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002069560A1 (fr) * 2001-02-23 2002-09-06 Nokia Inc. Systeme et procede pour une authentification forte realisee en un unique aller-retour
WO2006084183A1 (fr) * 2005-02-04 2006-08-10 Qualcomm Incorporated Amorçage securise pour communications sans fil

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002069560A1 (fr) * 2001-02-23 2002-09-06 Nokia Inc. Systeme et procede pour une authentification forte realisee en un unique aller-retour
WO2006084183A1 (fr) * 2005-02-04 2006-08-10 Qualcomm Incorporated Amorçage securise pour communications sans fil

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FANIAN A ET AL: "A new mutual authentication protocol for GSM networks", ELECTRICAL AND COMPUTER ENGINEERING, 2009. CCECE '09. CANADIAN CONFERENCE ON, IEEE, PISCATAWAY, NJ, USA, 3 May 2009 (2009-05-03), pages 798 - 803, XP031477434, ISBN: 978-1-4244-3509-8 *
M2M SECURITY - WAR TEXTING ATTACKS, Retrieved from the Internet <URL:http://m2m.gemalto.com/news-info/whitepapers.html>

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017128542A1 (fr) * 2016-01-29 2017-08-03 宇龙计算机通信科技(深圳)有限公司 Procédé de résidence dans un réseau, système de résidence dans un réseau, et terminal

Also Published As

Publication number Publication date
EP2785090A1 (fr) 2014-10-01

Similar Documents

Publication Publication Date Title
US8285990B2 (en) Method and system for authentication confirmation using extensible authentication protocol
CN107409305B (zh) 通信设备与网络设备之间的通信安全设置
JP4663011B2 (ja) 通信コネクションを保護するために少なくとも１つの第１の通信加入者と少なくとも１つの第２の通信加入者との間で秘密鍵を一致させるための方法
EP3523998B1 (fr) Procédé d&#39;authentification mutuelle entre un équipement utilisateur et un réseau de communication
CN114765534A (zh) 基于国密标识密码算法的私钥分发系统
US11228429B2 (en) Communication with server during network device during extensible authentication protocol—authentication and key agreement prime procedure
EP1976322A1 (fr) Procédé d&#39;authentification
US20060059344A1 (en) Service authentication
EP2747368A1 (fr) Procédé de personnalisation d&#39;un élément de sécurité
JP2012110009A (ja) エンティティの認証と暗号化キー生成の機密保護されたリンクのための方法と構成
AU2017313215B2 (en) Authentication server of a cellular telecommunication network and corresponding UICC
EP1769650B1 (fr) Procédé de sécurisation d&#39;un protocole d&#39;authentification et distribution de clés
US20160044505A1 (en) Method to establish a secure voice communication using generic bootstrapping architecture
EP3613186A1 (fr) Système et procédé de communications
EP2912818A1 (fr) Procede d&#39;authentification mutuelle entre un terminal et un serveur distant par l&#39;intermediaire d&#39;un portail d&#39;un tiers
CN107750470A (zh) 替换用于认证安全元件的至少一个认证参数的方法和相应的安全元件
EP2785090A1 (fr) Procédé d&#39;authentification mutuelle entre un élément de sécurité d&#39;un terminal de télécommunications et un élément d&#39;un réseau de télécommunications de type GSM
FR2864410A1 (fr) Telephone portable et procede associe de securisation de son identifiant.
CN102026184B (zh) 一种鉴权方法及鉴权系统以及相关设备
CN106304061B (zh) 一种故障弱化状态下的用户鉴权方法
WO2012068801A1 (fr) Procédé d&#39;authentification pour un terminal mobile et terminal mobile
Liu et al. Security analysis of camera file transfer over Wi-Fi
CN120835295A (zh) 一种安全通信方法及装置、网络设备、计算机存储介质及程序产品
WO2025051888A1 (fr) Connexion sécurisée d&#39;une station à un point d&#39;accès d&#39;un réseau de télécommunication sans-fil
CN119211914A (zh) 一种基于kem实现量子安全mqtt的方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14712293

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14712293

Country of ref document: EP

Kind code of ref document: A1