Programme d'authentification par puce - Chip Authentication Program

Un appareil Gemalto EZIO CAP avec style Barclays PINsentry

Le programme d'authentification par puce (CAP) est une initiative de MasterCard et une spécification technique pour l'utilisation des cartes à puce EMV bancaires 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 en tant qu'authentification par code d'accès dynamique (DPA). La spécification CAP définit un dispositif portable ( lecteur CAP ) avec une fente pour carte à puce, un clavier numérique et un affichage capable d'afficher au moins 12 caractères (par exemple, un affichage en étoile ). Les clients bancaires qui ont reçu un lecteur CAP par leur banque peuvent insérer leur carte à puce et 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 .

Principe de fonctionnement

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 ont deux ou trois types de transactions disponibles pour l'utilisateur sous une variété de noms. Certaines implémentations connues sont:

Code / 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 d'entrer un numéro de «défi» dans le lecteur CAP, puis de copier le numéro de «réponse» affiché par le lecteur CAP dans 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 mis en œuvre en utilisant l'un des deux modes. L'un de ces modes a deux formes dans lesquelles il peut fonctionner, créant trois modes distincts, bien qu'ils ne soient pas nommés de cette façon dans la spécification.

Mode1

C'est le mode pour les transactions monétaires normales telles qu'un achat en ligne via un commerçant. Une valeur de transaction et une devise sont incluses dans le calcul du cryptogramme. Si la carte ne l'exige pas ou si le terminal ne la prend pas en charge, le montant et la devise sont mis à zéro.

Mode2

Ce mode peut être utile pour authentifier un utilisateur dans lequel aucune transaction n'a lieu, comme la connexion à un système bancaire sur Internet. 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 signature des données de transaction (TDS)

Ce mode peut être utilisé pour des transactions plus complexes, telles qu'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.

Mode1 ressemble beaucoup à une utilisation spécifique du Mode2 avec TDS, mais il y a une différence critique. En fonctionnement Mode1, 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 en Mode2 sans TDS, alors que Mode2 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.

Détails du protocole

Un lecteur de code électronique Nordea

Dans les trois modes, le lecteur CAP demande à la carte EMV de sortir un paquet de données qui confirme l'annulation d'une transaction de paiement EMV fictive, ce 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 en toute sécurité dans la carte à puce. De tels messages d'annulation ne posent aucun risque pour la sécurité de l'application de paiement EMV classique, mais peuvent être vérifiés par cryptographie et ne sont générés par une carte EMV qu'après la saisie du code PIN correct. Cela a fourni aux concepteurs de CAP un moyen de créer des preuves cryptographiques solides 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 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 (Application Transaction Counter, MAC, etc.) qui est ensuite réduite à des bits spécifiques comme déterminé par l'enregistrement de l'indicateur d'authentification de l'émetteur (IAI) stocké dans la carte ( ceci est défini sur une base par émetteur, bien que si un émetteur le désire, il pourrait ê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 sont rejetés (essentiellement la position absolue des bits est non pertinent, un bit dans l'IAI qui vaut 0 signifie que le bit correspondant dans la réponse de la carte sera abandonné au lieu d'être simplement mis à 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. L'appareil 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. Une fois la saisie du code PIN réussie, le dispositif CAP envoie le défi 011100111010 _{2 en} tant que transaction ARQC (Authorization Request Cryptogram).
3. La carte à puce donne une réponse de 110101110110 ₂ et le dispositif CAP annule la fausse transaction.
4. Le dispositif 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 car 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 ₁₆ ), soit le format de modèle de message de réponse 2 plus complexe (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.

Dans le mode d'identification, la réponse dépend uniquement des bits requis de l'IAI car la quantité et le numéro de référence sont mis à zéro; cela signifie également que la sélection de répondre et la saisie d'un nombre 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 de signature avec le même numéro et un montant de 0,00 € générera à nouveau un résultat valide qui crée la possibilité pour un fraudeur de demander à un client de faire un "test "challenge response pour un montant de 0,00 € qui va en fait être utilisé par le fraudeur pour vérifier une commande de réponse afin qu'il s'ajoute lui-même en tant que 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 forte qui n'annulaient pas les activités jusqu'à ce qu'un montant d'au moins 0,01 ait été 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 identifier permet à un fraudeur de demander à une victime d'effectuer une transaction de réponse «test» en utilisant 00000000 comme référence, et pourra alors se connecter avec succès au compte de la victime.

Le même compteur de tentatives de code PIN sur la carte est utilisé que dans les autres transactions EMV. Ainsi, tout comme dans un guichet automatique ou un terminal de point de vente, la saisie d'un code PIN incorrect trois fois de suite dans un lecteur CAP bloquera la carte.

Incompatibilité

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 s'appliquent qu'à une seule application (c'est-à-dire, les données de gestion des risques du terminal pour EMV) ou des avantages à avoir séparé (c'est-à-dire, un compteur de transactions, donc que les transactions EMV et CAP incrémentent des compteurs séparés qui peuvent être vérifiés avec plus de précision). Le lecteur porte également des données spécifiques à l'implémentation, dont certaines peuvent être remplacées par des valeurs de la carte. Par conséquent, les lecteurs CAP ne sont généralement pas compatibles avec les cartes de différentes banques émettrices.

Cependant, les lecteurs de cartes émis par la plupart, voire toutes, des banques britanniques sont conformes à un sous-ensemble CAP défini par 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 carte émis par une autre banque.

Vulnérabilités

Les chercheurs de l'Université de Cambridge , Saar Drimer, Steven Murdoch et Ross Anderson, ont mené des recherches sur la mise en œuvre de 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é trouvées. Les chercheurs de l'Université Radboud ont découvert une vulnérabilité dans le fichier néerlandais ABN AMRO e.dentifier2, permettant à un attaquant de commander à un lecteur connecté USB de signer des transactions malveillantes sans l'approbation de l'utilisateur.

Utilisateurs

Suède

• Nordea utilise CAP en novembre 2007. La solution Nordea eCode est utilisée par Nordea à la fois pour l'eBanking, le commerce électronique (3DS) et également avec l'eID. Le lecteur, qui a des fonctionnalités plus avancées qui étendent CAP, rend les implémentations CAP de Nordea plus sécurisées contre les chevaux de Troie et les attaques de l'homme du milieu . Lorsqu'il est utilisé pour l'eID, l'utilisateur peut déposer sa «déclaration fiscale» en ligne ou toute fonction e-gouvernement implémentée. L'appareil est également équipé d'un port USB, qui permet à la banque d'effectuer Sign-What-You-See pour l'approbation des transactions sensibles.

Royaume-Uni

Un dispositif CAP national avec une pièce de 20 pence à l'échelle

Un dispositif Natwest CAP avec une pièce de 10 pence à l'échelle

• L' Administration britannique des paiements 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 sourire
  • Royal Bank of Scotland
  • Lloyds Bank
  • Dans tout le pays
• 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 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 PingIt Mobile Payment pour authentifier les détails du compte. L'appareil est également maintenant utilisé dans les succursales, remplaçant les dispositifs traditionnels à puce et à broche 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.

Implémentations logicielles

Il existe une implémentation logicielle écrite en Python prenant en charge le mode 1, le mode 2 et le mode 2 avec TDS à utiliser à des fins éducatives uniquement. La fonction identifier (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. Son utilisation dans un lecteur non sécurisé prend le risque qu'un keylogger intercepte le code PIN et qu'un logiciel malveillant de point de vente accède aux détails de la carte, voire intercepte une transaction pour la modifier ou opère sa propre transaction.

Voir également

• 3-D Secure

Les références