Authentification par carte SIM, fin du mot de passe

Authentification par carte SIM : se connecter aux services sans mot de passe

L’authentification par carte SIM consiste à utiliser l’élément sécurisé embarqué dans le terminal mobile (UICC, eUICC ou iSIM) et la session réseau établie par l’opérateur comme preuve d’identité, en remplacement ou en complément d’un mot de passe. Le secret cryptographique utilisé n’est jamais transmis sur l’interface radio, n’est pas saisissable par l’utilisateur, et ne peut donc être ni deviné, ni rejoué, ni hameçonné par un formulaire falsifié.

La problématique centrale est double. D’une part, le couple identifiant/mot de passe reste le principal vecteur de compromission des comptes en ligne, par réutilisation, par fuite de base de données ou par hameçonnage. D’autre part, le facteur de repli le plus déployé pour y remédier, le code à usage unique envoyé par SMS (OTP), hérite des faiblesses du canal SMS : interception par signalisation SS7, détournement de ligne par échange frauduleux de carte SIM (SIM swap), lecture par un logiciel malveillant, et surtout retransmission par l’utilisateur lui-même sur une page d’hameçonnage en temps réel. L’authentification par carte SIM déplace la vérification de l’écran de l’utilisateur vers le cœur de réseau de l’opérateur, où le facteur de possession est vérifiable cryptographiquement.

Comment fonctionne l’authentification par carte SIM : mécanismes cryptographiques et flux réseau

Réponse directe : L’authentification par carte SIM repose sur un mécanisme de défi-réponse (AKA, Authentication and Key Agreement) entre l’élément sécurisé de la carte et le cœur de réseau de l’opérateur, à partir d’une clé symétrique partagée jamais exposée. Les services tiers exploitent ensuite cette authentification réseau déjà réalisée, soit par dérivation de clés applicatives (GBA, AKMA, EAP-AKA’), soit par interrogation d’une API réseau qui confirme le numéro associé à la session de données en cours.

L’élément sécurisé : clé Ki, IMSI et algorithmes Milenage ou TUAK

Une carte SIM est une carte à puce exécutant un système d’exploitation dédié sur un élément sécurisé certifié + IA. À la personnalisation, elle reçoit deux données essentielles :

• L’IMSI (International Mobile Subscriber Identity) : identifiant d’abonné composé du MCC (code pays), du MNC (code réseau) et du MSIN (numéro d’abonné), utilisé pour localiser l’abonné dans le registre de l’opérateur.
• La clé Ki (ou K en 4G/5G) : clé symétrique de 128 bits inscrite simultanément dans la carte et dans le registre d’authentification de l’opérateur (AuC adossé au HLR en 2G/3G, HSS en 4G, UDM/ARPF en 5G). Cette clé ne quitte jamais ces deux points.

Les calculs cryptographiques sont réalisés à l’intérieur de la puce par des jeux d’algorithmes normalisés : Milenage (spécifications 3GPP TS 35.205 à 35.208, fondé sur AES) ou TUAK (TS 35.231, fondé sur Keccak). L’opérateur ajoute une constante de personnalisation propre à son parc (OP, dérivée en OPc et stockée dans la carte) afin que deux opérateurs utilisant le même algorithme ne produisent pas les mêmes sorties pour une même clé.

En 5G, une couche supplémentaire protège l’identifiant lui-même : le SUPI (Subscription Permanent Identifier, successeur de l’IMSI) n’est plus émis en clair mais chiffré en SUCI (Subscription Concealed Identifier) au moyen d’une clé publique du réseau domestique selon un schéma ECIES. Cette concealment neutralise les IMSI-catchers passifs qui exploitaient la diffusion en clair de l’identifiant lors de l’attachement.

Le mécanisme AKA : un défi-réponse exécuté à chaque attachement

Le protocole AKA est rejoué à chaque attachement au réseau et à chaque renouvellement de contexte de sécurité. Sa séquence est la suivante :

1. Le terminal transmet son identifiant (IMSI, SUCI, ou identité temporaire GUTI/5G-GUTI) au réseau visité.
2. Le réseau domestique génère un aléa RAND et calcule, à partir de la clé K, un vecteur d’authentification contenant la réponse attendue XRES, le jeton d’authentification réseau AUTN, et les clés de session CK (confidentialité) et IK (intégrité).
3. Le réseau envoie RAND et AUTN au terminal, qui les transmet à la carte SIM.
4. La carte vérifie AUTN, ce qui authentifie le réseau auprès du terminal et bloque les faux relais radio, puis calcule la réponse RES ainsi que CK et IK.
5. Le terminal renvoie RES ; le réseau compare avec XRES. En cas d’égalité, l’abonné est authentifié et la session chiffrée est établie.

L’authentification est donc mutuelle depuis la 3G, à sens unique en 2G, et la clé K ne transite jamais. C’est cette propriété qui fait de la carte SIM un authentificateur matériel déjà déployé à plusieurs milliards d’exemplaires, sans aucun enrôlement supplémentaire à réaliser par le service en ligne.

Réutiliser l’authentification réseau au niveau applicatif : GBA, AKMA et EAP-AKA’

Trois familles de standards permettent à une application tierce de s’appuyer sur le résultat de l’authentification AKA plutôt que de créer son propre secret.

• GBA (Generic Bootstrapping Architecture, 3GPP TS 33.220) : un serveur d’amorçage (BSF) exécute un AKA avec la carte, en dérive une clé maîtresse Ks et un identifiant de transaction B-TID, puis distribue à l’application (NAF) une clé dérivée. Historiquement déployé pour l’IMS, la télévision mobile et certaines cartes bancaires virtuelles, il est resté marginal côté web.
• AKMA (Authentication and Key Management for Applications, TS 33.535, Release 17) : successeur 5G de GBA, adossé à une fonction d’ancrage AAnF. Il fournit à un serveur applicatif une clé K_AF liée à un identifiant A-KID, sans échange supplémentaire avec l’utilisateur. Sa cible principale est l’IoT industriel et les applications opérateur, moins le grand public.
• EAP-SIM (RFC 4186), EAP-AKA (RFC 4187) et EAP-AKA’ (RFC 5448) : méthodes d’authentification EAP transportant les vecteurs AKA sur un réseau non cellulaire. Elles permettent l’authentification automatique sur un réseau Wi-Fi (offload opérateur, Wi-Fi Passpoint/Hotspot 2.0, réseaux d’entreprise 802.1X) et l’accès non-3GPP au cœur 5G. EAP-AKA’ ajoute une liaison de la dérivation de clés au nom du réseau demandeur, ce qui limite la réutilisation d’un vecteur d’un domaine à un autre.

L’authentification silencieuse par API réseau : le mécanisme dominant côté web et mobile

Le mécanisme aujourd’hui le plus déployé pour les services grand public ne repose pas sur la dérivation de clés mais sur l’association entre l’adresse IP d’une session de données mobile et l’abonné. Lorsqu’un terminal établit une session de données, le cœur de réseau paquet (GGSN, PGW en 4G, SMF/UPF en 5G) connaît de façon certaine le couple adresse IP attribuée / abonné authentifié par AKA. La séquence d’authentification silencieuse, dite Silent Network Authentication, en découle :

1. L’application ou le site déclenche une requête HTTPS forcée sur le réseau cellulaire, en contournant explicitement le Wi-Fi (API Network.bindSocket sur Android, NWParameters avec interface cellulaire sur iOS, ou redirection vers un domaine dédié résolu côté opérateur).
2. La requête atteint la passerelle d’authentification de l’opérateur, qui résout l’identité de l’abonné à partir de l’adresse IP source et de l’horodatage de la session.
3. L’opérateur compare le numéro (MSISDN) déduit de la session au numéro déclaré par le service, ou renvoie ce numéro selon le périmètre du consentement.
4. Le service reçoit un jeton signé, ou une simple réponse booléenne devicePhoneNumberVerified, et ouvre la session applicative.

Cette vérification s’exécute typiquement en quelques centaines de millisecondes, sans saisie, sans code, et sans notification visible. Elle est standardisée par le projet CAMARA (Linux Foundation) sous les API Number Verification et Device Phone Number, exposées commercialement dans le cadre de l’initiative GSMA Open Gateway. Ce cadre standardise l’accès aux capacités réseau des opérateurs sur plus de 300 réseaux mobiles dans 85 pays. Les API de vérification de numéro et d’authentification silencieuse y sont positionnées comme substitut aux codes SMS et aux contrôles d’identité manuels.

Il faut distinguer ce mécanisme de l’ancien header enrichment, qui consistait pour l’opérateur à injecter le MSISDN dans un en-tête HTTP en clair. Cette pratique, incompatible avec HTTPS généralisé et exposée à l’usurpation d’en-tête, est abandonnée au profit des flux authentifiés par API.

Mobile Connect et l’intégration OpenID Connect

Au-dessus de ces mécanismes réseau, la GSMA a spécifié Mobile Connect, un profil d’OpenID Connect dans lequel l’opérateur joue le rôle de fournisseur d’identité. Le service (Relying Party) redirige l’utilisateur vers l’opérateur, qui exécute l’authentification (silencieuse, par applet SIM, ou par confirmation dans l’application opérateur), puis retourne un jeton d’identité id_token contenant un identifiant pseudonymisé et persistant (PCR), et non le numéro de téléphone en clair.

Deux flux OpenID Connect sont pertinents :

• Authorization Code Flow : l’utilisateur est redirigé, le service échange ensuite un code contre un jeton. Adapté au web et aux applications mobiles.
• CIBA (Client Initiated Backchannel Authentication) : le service demande l’authentification par un canal arrière, sans redirection du navigateur. Adapté à l’authentification d’une opération initiée sur un autre appareil (validation d’un paiement en caisse, d’un appel au support, d’une session sur téléviseur connecté).

Une variante historique complémentaire existe côté carte : l’applet SIM Toolkit (STK), qui affiche un message de confirmation généré par la carte elle-même et signe la réponse. Ce mécanisme, robuste car indépendant du système d’exploitation du terminal, impose une distribution de cartes spécifiques et reste réservé à certains marchés bancaires et à la monnaie mobile.

Sécurité comparée : carte SIM, OTP SMS, TOTP et passkeys FIDO2

Réponse directe : L’authentification par carte SIM apporte un facteur de possession matériel non extractible, sans saisie utilisateur, donc insensible à l’hameçonnage par formulaire, contrairement à l’OTP SMS et au TOTP. Elle reste toutefois vulnérable au détournement de la ligne (SIM swap, portabilité frauduleuse), ce qui impose de la coupler à un contrôle de changement de SIM ou à un second facteur d’inhérence.

Tableau comparatif des méthodes d’authentification

Critère	Authentification SIM (API réseau)	OTP par SMS	TOTP (application)	Passkey / FIDO2	Mot de passe
Facteur couvert	Possession (élément sécurisé + ligne)	Possession (ligne)	Possession (secret logiciel)	Possession (+ inhérence si biométrie)	Connaissance
Secret transmis à l’utilisateur	Aucun	Code à 4-8 chiffres	Code à 6 chiffres	Aucun	Le secret lui-même
Résistance à l’hameçonnage temps réel	Élevée (rien à retransmettre)	Nulle	Nulle	Très élevée (liaison à l’origine)	Nulle
Résistance à l’interception réseau	Élevée (pas de canal SMS)	Faible (SS7, Diameter, malware)	Élevée	Élevée	Variable
Résistance au SIM swap	Faible sans contrôle associé	Faible	Élevée	Élevée	Sans objet
Enrôlement requis	Aucun	Aucun	Installation et appairage	Création de clé par appareil	Création de compte
Friction utilisateur	Nulle (transparent)	Moyenne (attente, saisie)	Moyenne	Faible	Élevée
Fonctionne hors couverture cellulaire	Non	Non (SMS)	Oui	Oui	Oui
Coût unitaire pour le service	Appel API facturé	SMS A2P facturé	Nul	Nul	Nul
Dépendance à un tiers	Opérateur mobile	Opérateur + agrégateur SMS	Aucune	Fabricant / gestionnaire de clés	Aucune
Taux de couverture du parc	Élevé mais partiel (voir limites)	Quasi universel	Élevé	En progression	Universel

Les vecteurs d’attaque spécifiques et leurs contre-mesures

L’authentification par carte SIM déplace la surface d’attaque du terminal vers la chaîne opérateur. Les vecteurs à traiter explicitement sont les suivants :

• SIM swap frauduleux : obtention d’une carte de remplacement par ingénierie sociale auprès du service client. Contre-mesure : interrogation de l’API SIM Swap avant toute opération sensible, qui retourne la date du dernier changement de SIM ou un booléen sur une période donnée. Les quatre opérateurs français ont lancé conjointement les API KYC Match et SIM Swap au format CAMARA, la France étant le premier pays où les quatre opérateurs majeurs proposent KYC Match.
• Portabilité frauduleuse du numéro (port-out) : transfert du numéro vers un autre opérateur. Contre-mesure : contrôle de l’ancienneté de la ligne (API de type Tenure), verrouillage de portabilité côté opérateur, et repli sur un second facteur en cas de changement récent.
• Exploitation de la signalisation SS7 ou Diameter : interception ou détournement de SMS et localisation d’abonné. Contre-mesure structurelle : ne plus faire transiter de secret par SMS, ce qui est précisément l’objet de l’authentification silencieuse.
• Faux relais radio (IMSI-catcher) : dégradation forcée vers la 2G pour supprimer l’authentification mutuelle. Contre-mesure : désactivation de la 2G côté terminal ou côté réseau, et déploiement du SUCI en 5G.
• Malware sur terminal compromis : un terminal rooté ou infecté peut initier des sessions légitimes. Contre-mesure : attestation d’intégrité du terminal, analyse comportementale, et exigence d’un facteur d’inhérence pour les opérations à fort enjeu.
• Terminal perdu ou volé non verrouillé : la possession physique suffit. Contre-mesure : code PIN de la carte SIM actif, verrouillage biométrique du terminal, et liaison dynamique de la transaction.

Ce que l’authentification par carte SIM ne couvre pas

Elle prouve qu’une requête provient d’une session de données rattachée à une ligne donnée. Elle ne prouve pas :

• Qui manipule le terminal à cet instant, sauf ajout d’un facteur d’inhérence (biométrie locale) ou de connaissance (code applicatif).
• L’identité civile du titulaire, sauf recours complémentaire à une API de type KYC Match, qui compare les données déclarées par le client aux données contractuelles détenues par l’opérateur, sans les divulguer.
• L’intégrité du terminal, qui relève de mécanismes d’attestation distincts.

Pour cette raison, dans un contexte réglementé, l’authentification par carte SIM se qualifie comme élément de possession au sens de l’authentification forte, à combiner avec un second élément d’une catégorie différente.

Mise en œuvre : cas d’usage, séquence d’intégration et limites opérationnelles

Réponse directe : L’intégration s’effectue par appel à une API réseau normalisée CAMARA exposée par un opérateur, un agrégateur ou un CPaaS, avec obtention préalable d’un jeton d’accès et déclenchement d’une requête forcée sur le réseau mobile. Le déploiement doit systématiquement prévoir un parcours de repli, car la vérification échoue en Wi-Fi seul, sur certains terminaux double SIM et sur les lignes non couvertes par l’opérateur interrogé.

Cas d’usage analysés sous l’angle technique

• Services financiers et conformité DSP2 : la vérification silencieuse constitue l’élément de possession de l’authentification forte du client (SCA), associé à la biométrie locale pour l’élément d’inhérence. L’interrogation de l’API SIM Swap avant validation d’un virement traite le risque de prise de contrôle de compte consécutive à un détournement de ligne, et supprime la latence et le coût du SMS A2P.
• Inscription et onboarding applicatif : la vérification du numéro à l’inscription supprime l’étape de saisie du code reçu par SMS, source majeure d’abandon dans les tunnels de conversion. La plateforme Cabify a intégré l’API Number Verification pour accélérer l’inscription au Brésil et réduire les abandons en cours de parcours.
• Commerce en ligne et lutte contre la fraude : la vérification s’exécute en tâche de fond au moment du paiement et alimente un moteur de risque avec un signal réseau difficile à falsifier, plutôt que de dépendre uniquement d’heuristiques d’appareil.
• Espaces client télécom et MVNO : l’utilisateur connecté sur le réseau de son propre opérateur est identifié sans saisie, ce qui supprime le mot de passe des applications de gestion de ligne, de recharge et de souscription d’options.
• Réseaux Wi-Fi opérés et entreprises : EAP-SIM et EAP-AKA’ permettent l’association automatique d’un terminal à un réseau Wi-Fi Passpoint ou 802.1X sur la seule base de la carte SIM, sans portail captif ni identifiants distribués manuellement.
• IoT et M2M : pour les objets sans interface utilisateur, AKMA et les certificats provisionnés via l’eUICC permettent d’authentifier une machine auprès d’une plateforme applicative en réutilisant l’authentification réseau. À noter que de nombreuses cartes SIM IoT sont dépourvues de MSISDN, ce qui exclut les API fondées sur le numéro de téléphone.

Séquence d’intégration technique

1. Contractualiser l’accès auprès d’un fournisseur : opérateur en direct, agrégateur multi-opérateurs, ou plateforme CPaaS exposant les API CAMARA. Vérifier la couverture réelle par opérateur et par MVNO du marché cible.
2. Obtenir les identifiants OAuth 2.0 (client ID, secret) et implémenter l’acquisition de jeton d’accès, avec le périmètre correspondant (number-verification:verify pour une comparaison, number-verification:device-phone-number:read pour une lecture).
3. Implémenter le déclenchement côté client en forçant l’interface cellulaire. C’est le point d’échec le plus fréquent : sans liaison explicite au réseau mobile, la requête part en Wi-Fi et la corrélation d’adresse IP devient impossible.
4. Appeler l’API de vérification en transmettant le numéro à contrôler, de préférence sous forme de condensat, et traiter la réponse booléenne plutôt que de récupérer le numéro lorsque le cas d’usage ne l’exige pas : c’est la variante la plus économe en données personnelles.
5. Chaîner les contrôles de risque : interrogation SIM Swap et, le cas échéant, KYC Match pour les opérations sensibles.
6. Journaliser les décisions avec l’horodatage, le fournisseur interrogé, le code de retour et le résultat, sans conserver les identifiants réseau bruts au-delà de la durée nécessaire.
7. Implémenter le repli de manière déterministe et mesurée, avec suivi du taux de succès par opérateur, par type de terminal et par système d’exploitation.

Limites opérationnelles et parades

Limite	Cause technique	Parade
Terminal en Wi-Fi uniquement	Absence de session de données mobile exploitable	Forcer l’interface cellulaire ; à défaut, basculer sur un autre facteur
Données mobiles désactivées ou hors couverture	Aucune adresse IP attribuée par le réseau	Repli explicite, sans message d’erreur bloquant
Terminal double SIM ou multi-profil eSIM	Le numéro actif pour les données peut différer du numéro déclaré	Vérifier le numéro effectivement porteur de la session ; proposer la sélection du profil
Ligne en itinérance internationale	Ancrage de la session dans le réseau domestique ou local selon l’architecture	Tester le comportement en roaming avant mise en production
MVNO non exposé	L’hébergeur de réseau n’expose pas les lignes du MVNO ou les expose partiellement	Cartographier la couverture par opérateur ; recourir à un agrégateur multi-réseaux
Ligne fixe, VoIP ou numéro virtuel	Aucune carte SIM associée	Exclure ces numéros du parcours silencieux
Carte SIM IoT sans MSISDN	Profil data-only	Recourir à AKMA ou à une authentification par certificat
VPN actif sur le terminal	L’adresse IP vue par l’opérateur n’est plus celle de la session applicative	Détecter l’échec et basculer sur le repli
Navigateur web sans SDK natif	Impossibilité de forcer l’interface réseau depuis la page	Redirection vers un domaine opérateur, ou usage du flux OpenID Connect

Conformité RGPD, consentement et minimisation

Le numéro de téléphone, l’IMSI, l’ICCID et l’historique de changement de SIM sont des données à caractère personnel. Le déploiement doit intégrer :

• Une base légale explicite : consentement de l’utilisateur, ou intérêt légitime documenté pour la prévention de la fraude, avec analyse d’impact lorsque le traitement est systématique.
• La minimisation : privilégier la vérification par comparaison, qui retourne un booléen, plutôt que la récupération du numéro. Transmettre un condensat plutôt que le numéro en clair lorsque l’API le permet.
• La transparence : information de l’utilisateur sur l’interrogation de son opérateur, y compris lorsqu’elle est silencieuse, dans la politique de confidentialité et au moment du parcours.
• La limitation de conservation : durées définies pour les journaux d’authentification et les résultats de contrôle anti-fraude.
• L’encadrement des sous-traitants : agrégateur et CPaaS interviennent comme sous-traitants au sens du RGPD, avec les clauses et les localisations de traitement afférentes.

Questions fréquentes

L’authentification par carte SIM remplace-t-elle les passkeys FIDO2 ?

Non, les deux approches sont complémentaires. Les passkeys offrent la meilleure résistance à l’hameçonnage grâce à la liaison cryptographique à l’origine du site, mais exigent un enrôlement par appareil et une récupération de compte à concevoir. L’authentification par carte SIM ne demande aucun enrôlement et fonctionne dès le premier contact, ce qui la rend pertinente pour l’inscription, la récupération de compte et la vérification de possession, tandis que les passkeys conviennent à l’authentification récurrente.

Une eSIM change-t-elle le niveau de sécurité de ce mécanisme ?

Non sur le principe cryptographique : une eSIM eUICC exécute le même protocole AKA avec les mêmes algorithmes. Elle modifie en revanche le modèle de menace du provisionnement, puisque le profil est téléchargé à distance depuis un serveur SM-DP+ selon les spécifications GSMA SGP.22 ou SGP.32, ce qui déplace le risque d’ingénierie sociale vers la procédure de transfert de profil.

Que se passe-t-il si l’utilisateur change d’opérateur en conservant son numéro ?

La portabilité ne rompt pas le mécanisme, mais elle change l’opérateur qui doit répondre à la requête. L’appel doit donc être routé vers le bon réseau, ce que gèrent les agrégateurs par consultation des bases de portabilité. Une portabilité récente est en revanche un signal de risque à traiter au même titre qu’un changement de carte SIM.

Cette méthode fonctionne-t-elle sur un ordinateur de bureau ?

Pas directement, faute de session de données mobile. Le parcours consiste alors à utiliser un flux OpenID Connect avec confirmation sur le terminal mobile, ou un flux CIBA par canal arrière, l’authentification étant réalisée sur le mobile et son résultat consommé par la session de bureau.

Conclusion : points de contrôle avant déploiement

• Vérifier la couverture réelle du parc cible, opérateur par opérateur et MVNO par MVNO, et non la couverture théorique annoncée par le fournisseur.
• Mesurer le taux de succès par système d’exploitation, par version applicative et par type de réseau avant de retirer tout autre facteur d’authentification.
• Forcer explicitement l’interface cellulaire côté client et tester le comportement avec Wi-Fi actif, VPN actif et données mobiles désactivées.
• Définir un parcours de repli déterministe, non bloquant, et instrumenté, plutôt qu’un message d’erreur générique.
• Coupler systématiquement la vérification de numéro à un contrôle de changement de SIM pour toute opération à enjeu financier ou juridique.
• Traiter la portabilité récente et l’ancienneté de ligne comme des signaux de risque à part entière.
• Retenir la variante d’API la plus minimisante, c’est-à-dire la comparaison retournant un booléen plutôt que la lecture du numéro.
• Documenter la base légale, informer l’utilisateur de l’interrogation de son opérateur et fixer des durées de conservation pour les journaux.
• Tester le comportement en itinérance internationale et sur terminaux double SIM avant la mise en production.
• Ne jamais considérer la seule possession de la ligne comme une authentification forte : ajouter un facteur d’inhérence ou de connaissance pour les opérations sensibles.
• Prévoir la trajectoire technologique : extinction progressive de la 2G et de la 3G, généralisation du SUCI en 5G, et montée en charge des API AKMA pour les usages machine.