Programme d'authentification par puce

Le programme d'authentification à puce (CAP) est une initiative de MasterCard et une spécification technique pour l'utilisation de cartes à puce bancaires EMV pour authentifier les utilisateurs et les transactions dans les services bancaires en ligne et par téléphone. Il a également été adopté par Visa sous le nom d'authentification par code d'accès dynamique (DPA). La spécification CAP définit un appareil portatif ( lecteur CAP ) doté d'un emplacement pour carte à puce, d'un clavier numérique et d'un écran capable d'afficher au moins 12 caractères (par exemple, un écran en étoile ). Les clients bancaires qui ont reçu un lecteur CAP de leur banque peuvent insérer leur carte à puce et code PIN ( EMV ) dans le lecteur CAP afin de participer à l'un des nombreux protocoles d'authentification pris en charge . Le CAP est une forme d' authentification à deux facteurs , car une carte à puce et un code PIN valide doivent être présents pour qu'une transaction réussisse. Les banques espèrent que le système réduira le risque que des clients sans méfiance saisissent leurs coordonnées sur des sites Web frauduleux après avoir lu des e-mails de phishing .

La spécification CAP prend en charge plusieurs méthodes d'authentification. L'utilisateur insère d'abord sa carte à puce dans le lecteur CAP et l'active en saisissant le code PIN. Un bouton est ensuite enfoncé pour sélectionner le type de transaction. La plupart des lecteurs proposent à l'utilisateur deux ou trois types de transaction sous différents noms. Voici quelques exemples d'implémentations connues :

Coder/identifier

Sans nécessiter aucune saisie supplémentaire, le lecteur CAP interagit avec la carte à puce pour produire un mot de passe décimal à usage unique , qui peut être utilisé, par exemple, pour se connecter à un site Web bancaire.

Réponse

Ce mode implémente l'authentification par défi-réponse , où le site Web de la banque demande au client de saisir un numéro de « défi » dans le lecteur CAP, puis de copier le numéro de « réponse » affiché par le lecteur CAP sur le site Web.

Signe

Ce mode est une extension du précédent, où non seulement une valeur de « défi » aléatoire, mais également des détails de transaction cruciaux tels que la valeur transférée, la devise et le numéro de compte du destinataire doivent être saisis dans le lecteur CAP.

Les types de transaction mentionnés ci-dessus sont implémentés à l'aide de l'un des deux modes. L'un de ces modes peut fonctionner sous deux formes, créant ainsi trois modes distincts, bien qu'ils ne soient pas nommés de cette façon dans la spécification.

Mode1

Il s'agit du mode de transaction monétaire normal, comme un achat en ligne auprès d'un commerçant. Le montant de la transaction et la devise sont inclus dans le calcul du cryptogramme. Si la carte ne l'exige pas ou si le terminal ne le prend pas en charge, le montant et la devise sont alors mis à zéro.

Mode2

Ce mode peut être utile pour authentifier un utilisateur dans lequel aucune transaction n'est en cours, comme la connexion à un système bancaire en ligne. Aucune valeur de transaction, devise ou autre donnée n'est incluse, ce qui rend ces réponses très faciles à précalculer ou à réutiliser.

Avec la signature des données de transaction (TDS)

Ce mode peut être utilisé pour des transactions plus complexes, comme un transfert de fonds entre comptes. Plusieurs champs de données relatifs à la transaction sont concaténés puis hachés avec un cryptogramme Mode2 comme clé pour l'algorithme de hachage. Le hachage résultant est utilisé à la place du cryptogramme calculé dans une opération Mode2 non TDS.

Le mode 1 ressemble beaucoup à une utilisation spécifique du mode 2 avec TDS, mais il existe une différence essentielle. Dans le fonctionnement du mode 1, les données de transaction (montant et type de devise) sont utilisées dans le calcul du cryptogramme en plus de toutes les valeurs utilisées dans le mode 2 sans TDS, alors que le mode 2 inclut ses données de transaction dans une étape successive plutôt que de les inclure dans l'étape de calcul du cryptogramme. S'il n'y avait pas cette différence, toutes les opérations pourraient être généralisées en une seule opération avec des données de transaction facultatives variables.

Dans les trois modes, le lecteur CAP demande à la carte EMV de générer un paquet de données confirmant l'annulation d'une transaction de paiement EMV fictive, qui implique les détails saisis par l'utilisateur. Ce message de confirmation contient un code d'authentification de message (généralement CBC-MAC / Triple DES ) qui est généré à l'aide d'une clé secrète spécifique à la carte stockée de manière sécurisée dans la carte à puce. De tels messages d'annulation ne posent aucun risque de sécurité pour l'application de paiement EMV classique, mais peuvent être vérifiés de manière cryptographique et sont générés par une carte EMV uniquement après la saisie du code PIN correct. Cela a fourni aux concepteurs du CAP un moyen de créer une preuve cryptographique solide qu'une carte EMV activée par code PIN est présente et a vu certaines données d'entrée données, sans avoir à ajouter de nouvelles fonctions logicielles aux cartes EMV déjà utilisées.

Une carte à puce EMV contient un compteur de transactions (généralement de 16 bits) qui est incrémenté à chaque paiement ou transaction CAP. La réponse affichée par un lecteur CAP se compose essentiellement des différentes parties de la réponse de la carte (compteur de transactions d'application, MAC, etc.) qui est ensuite réduite à des bits spécifiques déterminés par l'enregistrement de l'indicateur d'authentification de l'émetteur (IAI) stocké dans la carte (cela est défini pour chaque émetteur, bien que si un émetteur le souhaite, il puisse être défini de manière aléatoire pour chaque carte à condition qu'une base de données de l'IAI de chaque carte soit conservée), enfin, après que les bits indésirables ont été éliminés (essentiellement, la position absolue des bits n'est pas pertinente, un bit dans l'IAI qui est 0 signifie que le bit correspondant dans la réponse de la carte sera supprimé plutôt que d'être simplement défini sur 0). Enfin, la valeur est convertie du binaire en un nombre décimal et affichée à l'utilisateur. Un exemple tronqué est fourni ci-dessous :

1. Le périphérique CAP sélectionne l'application EMV, lit les informations IAI de la carte et l'utilisateur sélectionne une action à effectuer (dans cet exemple, IAI sera 111011011000 ₂ ).
2. Après une saisie réussie du code PIN, le périphérique CAP envoie le défi 011100111010 ₂ en tant que transaction de cryptogramme de demande d'autorisation (ARQC).
3. La carte à puce donne une réponse de 110101110110 ₂ et le dispositif CAP annule la fausse transaction.
4. Le périphérique CAP utilise le masque IAI : 111011011000 ₂ pour supprimer des bits ; les bits qui correspondent à un 0 dans le masque sont supprimés.
5. La réponse finale est donc 1100110 ₂ ou 102 en décimal.

Le processus du monde réel est bien sûr un peu plus complexe puisque la carte peut renvoyer l'ARQC dans l'un des deux formats (soit le format de modèle de message de réponse simple de type 1 (id. 80 ₁₆ ) ou le format de modèle de message de réponse plus complexe 2 (id. 77 ₁₆ ) qui divise les données ARQC en valeurs TLV distinctes qui doivent être réassemblées séquentiellement pour correspondre à celles du format de type 1.

En mode identification, la réponse dépend uniquement des bits requis par l'IAI car le montant et le numéro de référence sont définis sur zéro ; cela signifie également que la sélection de répondre et la saisie d'un nombre de 00000000 généreront en fait une réponse d'identification valide. Plus inquiétant cependant, si une demande de réponse est émise par une banque, l'utilisation du mode signature avec le même numéro et un montant de 0,00 ¤ générera à nouveau un résultat valide, ce qui crée une possibilité pour un fraudeur de demander à un client d'effectuer une réponse de défi « test » pour un montant de 0,00 ¤ qui sera en fait utilisé par le fraudeur pour vérifier une commande de réponse afin de s'ajouter comme bénéficiaire sur le compte de la victime ; ces attaques ont pu être menées contre des banques qui utilisaient des dispositifs d'authentification forts qui n'annulaient pas les activités jusqu'à ce qu'un montant d'au moins 0,01 soit saisi. La probabilité de ce type d'attaques a été abordée en 2009 lorsque de nouvelles générations d'appareils ont été déployées, mettant en œuvre une fonctionnalité de séparation de domaine sécurisée conforme à la note d'application MasterCard datée d'octobre 2010. De même, bien sûr ; une banque qui implémente la commande d'identification permet à un fraudeur de demander à une victime d'effectuer une transaction de réponse « test » en utilisant 00000000 comme référence, et pourra ensuite se connecter avec succès au compte de la victime.

Le même compteur de tentatives de saisie du code PIN intégré à la carte est utilisé que pour les autres transactions EMV. Ainsi, tout comme dans un distributeur automatique ou un terminal de paiement, la saisie d'un code PIN incorrect trois fois de suite dans un lecteur CAP bloquera la carte.

La spécification CAP d'origine a été conçue pour utiliser des transactions EMV normales, de sorte que l'application CAP puisse être déployée sans mettre à jour le micrologiciel des cartes EMV existantes si nécessaire. L'implémentation préférée utilise une application distincte pour les transactions CAP. Les deux applications peuvent partager certaines données, telles que le code PIN, tandis que d'autres données ne sont pas partagées dans les cas où elles ne sont applicables qu'à une seule application (c'est-à-dire les données de gestion des risques du terminal pour EMV) ou lorsqu'il est avantageux d'en avoir une distincte (c'est-à-dire un compteur de transactions, de sorte que les transactions EMV et CAP incrémentent des compteurs distincts qui peuvent être vérifiés plus précisément). Le lecteur transporte également des données spécifiques à l'implémentation, dont certaines peuvent être remplacées par des valeurs dans la carte. Par conséquent, les lecteurs CAP ne sont généralement pas compatibles avec les cartes de différentes banques émettrices.

Cependant, la plupart des banques britanniques qui émettent des lecteurs de cartes se conforment à un sous-ensemble CAP défini par l'APACS , ce qui signifie que, dans la plupart des cas, les cartes émises par une banque britannique peuvent être utilisées dans un lecteur de cartes émis par une autre banque.

Les chercheurs de l'Université de Cambridge, Saar Drimer, Steven Murdoch et Ross Anderson, ont mené des recherches sur la mise en œuvre du protocole CAP, soulignant un certain nombre de vulnérabilités dans le protocole et la variante britannique des lecteurs et des cartes. De nombreuses faiblesses ont été découvertes. Les chercheurs de l'Université Radboud ont découvert une vulnérabilité dans le e.dentifier2 néerlandais d'ABN AMRO , permettant à un attaquant de commander à un lecteur connecté par USB de signer des transactions malveillantes sans l'approbation de l'utilisateur.

La plupart des grandes banques belges (dont Belfius , BNP Paribas Fortis , ING , KBC Bank ) proposent un tel lecteur de carte. Il est utilisé pour deux raisons principales :

• Authentification sur le site Web eBanking de la banque. Afin d'accéder à des informations privées telles que la vérification du solde.
• Signature d'une transaction. Par exemple dans le commerce électronique (3DS) pour acheter des biens ou des services auprès d'un commerçant en ligne, ou pour effectuer un virement bancaire . Le commerçant demande les informations de la carte bancaire, puis redirige l'utilisateur vers le site Web de la banque où une page Web s'affiche avec des instructions à suivre pour vérifier la transaction. La banque redirige ensuite l'utilisateur vers la page du commerçant avec un succès ou un échec.

L'appareil est équipé d'un port USB en option, ces deux opérations peuvent être utilisées sans connecter le câble sur un ordinateur.

C'est la méthode la plus utilisée pour payer en ligne, offrant une méthode de vérification similaire au code PIN dans les POS. Depuis la large acceptation des smartphones, les banques proposent une alternative en utilisant une application locale sur le téléphone, en utilisant un QR-Code à scanner ou en utilisant l' application populaire

L'appareil est également compatible avec la carte eID belge pour accéder aux services gouvernementaux tels que la déclaration d'impôts, les informations sur l'assurance médicale, le chômage, etc. Ces services sont également généralement disponibles via Itsme.

• Nordea utilise CAP en novembre 2007. La solution Nordea eCode est utilisée par Nordea à la fois pour l'e-banking, l'e-commerce (3DS) et également pour l'e-ID. Le lecteur, qui dispose de fonctionnalités plus avancées qui étendent CAP, rend les implémentations CAP de Nordea plus sûres contre les chevaux de Troie et les attaques de l'homme du milieu . Lorsqu'il est utilisé pour l'e-ID, l'utilisateur peut remplir sa « déclaration fiscale » en ligne ou toute fonction de gouvernement électronique implémentée. L'appareil est également équipé d'un port USB, qui permet à la banque d'effectuer la signature de ce que vous voyez pour l'approbation des transactions sensibles.

• L' administration des paiements du Royaume-Uni a défini un sous-ensemble CAP à l'usage des banques britanniques. Il est actuellement utilisé par :
  • Banque Barclays
  • Banque d'Ulster
  • NatWest
  • Banque coopérative et Smile
  • Banque Royale d'Écosse
  • Banque Lloyds
  • À l'échelle nationale
• Les lecteurs CAP de Barclays, Lloyds Bank, Nationwide, NatWest, Co-operative Bank/Smile et RBS sont tous compatibles.
• Barclays a commencé à émettre des lecteurs CAP (appelés PINsentry ) en 2007. Leur site Web de banque en ligne utilise le mode d'identification pour la vérification de la connexion et le mode de signature pour la vérification des transactions. Le mode de réponse est utilisé dans le cadre de la nouvelle application de paiement mobile PingIt pour authentifier les détails du compte. L'appareil est désormais également utilisé dans les agences, remplaçant les appareils traditionnels à puce et code PIN afin de prévenir davantage les tentatives de fraude.
• Les cartes bancaires émises par HBOS sont techniquement compatibles avec le système, bien que HBOS n'ait pas (encore) introduit de lecteurs CAP à utiliser avec ses services bancaires en ligne.

Il existe une implémentation logicielle écrite en Python supportant le Mode 1, le Mode 2 et le Mode 2 avec TDS à utiliser uniquement à des fins pédagogiques. La fonction d'identification (sans challenge) correspond à la fonction m1 avec le challenge "00000000".

Notez que l'utilisation de ce logiciel pour des opérations financières réelles peut entraîner certains risques. En effet, l'avantage d'utiliser un lecteur autonome est d'isoler la carte bancaire des malwares potentiellement localisés sur le PC. L'utiliser dans un lecteur non sécurisé, c'est prendre le risque qu'un keylogger intercepte le code PIN, et qu'un malware du point de vente accède aux détails de la carte, voire intercepte une transaction pour la modifier ou opère sa propre transaction.