Forum de questions-réponses PSD2

L'un des objectifs d'EBA dans son RTS était de rester technologiquement neutre pour laisser autant de place que possible à l'innovation. Le défi était de ne pas être très normatif lors de la spécification des exigences. En fin de compte, aucune technologie spécifique n'est interdite par RTS, cependant, certaines des pratiques existantes ne seront plus entièrement conformes aux exigences SCA. On peut dire que le SMS peut être considéré comme un élément de possession, car il ne peut normalement être lu que par le destinataire prévu du message SMS. Donc, en théorie, SMS remplit l'exigence d'élément de possession, et il peut donc être utilisé comme bloc de construction d'une solution de signature de transaction.

Afin de répondre aux exigences de Dynamic Linking, le message SMS doit inclure les informations de paiement, c'est-à-dire le montant d'argent et des informations sur le bénéficiaire, en plus du code d'authentification. Les exigences relatives au lien dynamique indiquent également que la confidentialité et l'intégrité des informations de paiement doivent être protégées. Cela pourrait impliquer que les informations de paiement doivent être cryptées. Cependant, décrypter le contenu d'un SMS nécessiterait une application sur la carte SIM du téléphone mobile ou sur le téléphone lui-même, ce qui n'est pas pratique.

Au final, l'utilisation du SMS implique d'avoir un haut niveau de sécurité pour l'appareil de l'utilisateur, une protection contre la fraude par échange de carte SIM, une protection contre d'éventuelles interceptions et abus de SMS. En réalité, aujourd'hui, ce sont des défis très difficiles. Différentes autorités compétentes ont actuellement des opinions différentes sur l'utilisation des SMS. Plusieurs autorités découragent l'utilisation des SMS, tandis que d'autres l'autorisent. Nous surveillons ces avis et mettrons à jour cette FAQ lorsqu'il y aura une décision claire.

Selon PSD2, le mécanisme d'authentification doit être construit à partir de deux des trois éléments d'authentification possibles, c'est-à-dire quelque chose que seul l'utilisateur possède, quelque chose que seul l'utilisateur connaît et ce que seul l'utilisateur est.

Le code d'authentification doit toujours être utilisé pour authentifier un utilisateur. Le code d'authentification doit être généré par un mécanisme d'authentification qui est construit à partir de deux des trois éléments d'authentification possibles, c'est-à-dire quelque chose que seul l'utilisateur possède, quelque chose que seul l'utilisateur connaît et ce que seul l'utilisateur est.

3D Secure est en effet un protocole qui peut être utilisé par les PSP pour construire une solution conforme aux exigences SCA pour les paiements par carte.

L'utilisateur reçoit le message SMS normalement sur un téléphone personnel, il s'agirait donc d'un élément de possession.

PSD2 couvre les paiements par navigateur et mobiles.

L'authentification comportementale de OneSpan est une extension de OneSpan Mobile Security Suite. L'authentification comportementale permet non seulement de prouver de manière précise et transparente l'identité de l'utilisateur, mais également de détecter des comportements spécifiques, par exemple les attaques de bots. Plus d'informations sont disponibles ici.

Les clients de OneSpan Mobile Security Suite peuvent tirer parti de leur implémentation existante en ajoutant uniquement les nouveaux composants nécessaires de la solution. Pour obtenir la meilleure combinaison de sécurité et de convivialité, il est important aujourd'hui de combiner les trois éléments :

1. Sécurité des applications mobiles avec collecte de données sur les appareils clients
2. Cadre d'authentification multifacteur et biométrique et canal sécurisé pour une communication sécurisée
3. Logiciel d'analyse de fraude et de risque pour analyser les entrées des utilisateurs, les appareils, le comportement et appliquer la prise de décision en temps réel sur plusieurs canaux. La suite de solutions OneSpan couvre tous ces domaines.

Plus d'infos sur Conformité PSD2 .

Les normes techniques réglementaires (RTS) sur l'authentification forte du client ne précisent pas si la vérification biométrique doit être effectuée côté client ou côté serveur. Les deux options sont donc autorisées.

À l'heure actuelle, il n'existe pas de programme de certification formel pour des produits spécifiques dans le cadre de la PSD2. En tant que tel, il n'est pas possible pour OneSpan d'obtenir une assurance formelle. Cependant, OneSpan discute de la conformité de ses produits de manière informelle avec les autorités compétentes afin de s'assurer que nous interprétons correctement le RTS et que nos produits sont conformes.

OneSpan ne prévoit pas actuellement de le faire. De plus, il n'existe pas de programme de certification formel pour les solutions d'authentification forte sous PSD2.

Les exigences de liaison dynamique dans le RTS stipulent que le code d'authentification doit être calculé sur certaines informations de transaction, y compris le montant d'argent et des informations sur le bénéficiaire (par exemple, le numéro de compte bancaire du bénéficiaire).

De plus, le payeur doit être informé de ces informations de transaction. Enfin, la confidentialité, l'intégrité et l'authenticité des informations de transaction doivent être protégées à tout moment. Sur la base de ces exigences, nous pouvons dire ce qui suit à propos de l'utilisation de périphériques matériels d'authentification par clavier PIN :

• Cet appareil offre un très haut niveau de sécurité des éléments de possession et de connaissance
• Cet appareil permet à l'utilisateur final de saisir le montant et les détails du bénéficiaire et de les inclure dans la génération d'un code d'authentification unique
• L'utilisateur est au courant des actions avec un tel appareil. Ainsi, le Digipass matériel avec PIN-pad, s'il est utilisé avec le mode de signature des données de transaction, est conforme aux exigences de liaison dynamique.

Oui c'est le cas. Le terme « liaison dynamique » est utilisé par PSD2 et le RTS sur SCA.

Il est de la responsabilité du PSP d'effectuer une authentification forte de ses utilisateurs. OneSpan peut fournir aux PSP des produits et services pour effectuer une authentification forte.

La version finale du RTS n'exige plus la ségrégation des canaux. Comme indiqué dans les commentaires du projet final de RTS, ce langage a été supprimé du projet de RTS, car il prêtait à confusion.

Pour les paiements groupés, le code d'authentification doit être calculé sur la base du montant total de tous les paiements combinés et sur la base des numéros de compte de tous les bénéficiaires.

Aujourd'hui, OneSpan fournit des solutions d'authentification à plus de 2 000 banques dans le monde, avec divers cas d'utilisation, besoins commerciaux, groupes d'utilisateurs et exigences réglementaires. C'est possible, car OneSpan propose une très large gamme de solutions pouvant couvrir tous les besoins possibles. Par exemple, OneSpan fournit des appareils compatibles PSD2 très simples à utiliser avec de grands écrans, des boutons et même des commandes vocales pour les utilisateurs âgés : Digipass 301

En option, dans l'espace SWYS, une option populaire consiste à utiliser l'un des appareils haut de gamme avec un clavier en caoutchouc robuste : Digipass 770

Cet appareil n'a pas besoin de saisie approfondie de l'utilisateur, ne nécessite que l'approbation du client et une courte saisie du code PIN. Les études d'acceptation des utilisateurs menées par les clients OneSpan montrent un taux d'adoption très élevé et une baisse essentielle des appels au service d'assistance des utilisateurs lors du passage à cette technologie.

Notre interprétation des exigences de liaison dynamique dans le projet final de RTS est en effet que les informations de paiement doivent être incluses dans le message SMS pour l'authentification du paiement.

Ceci est très probablement conforme à la version finale du RTS.

En général, les Go-tokens ne génèrent pas de codes d'authentification sur les informations de paiement (telles que le montant d'argent). Pour cette raison, il ne peut pas être utilisé pour le Dynamic Linking, qui est toujours requis pour les paiements supérieurs à 500 euros.

En général, les utilisateurs peuvent saisir des informations de paiement, telles que le montant d'argent et le numéro de compte du bénéficiaire, dans des jetons matériels. Cela peut se faire via le clavier du token, via un câble USB ou en scannant un code visuel. Le jeton matériel peut ensuite utiliser les informations de paiement pour calculer un code d'authentification en fonction des exigences de liaison dynamique.

« Voir ce que vous signez » sur les jetons matériels peut être utilisé pour se conformer à l'exigence de liaison dynamique, mais ce n'est pas la seule option. L'affichage des données dans une application mobile est également très probablement acceptable.

Le projet final de RTS précise qu'en cas de paiements groupés, le code d'authentification doit être calculé sur le montant total des paiements, ainsi que des informations sur les bénéficiaires des différents paiements.

Non, le couplage dynamique n'est pas requis pour les paiements inférieurs à 30 EUR, tant que le montant cumulé ou le nombre d'opérations de télépaiement antérieures initiées par le payeur depuis la dernière demande d'authentification forte du client n'excède pas respectivement 100 ou 5 EUR transactions individuelles consécutives de paiement électronique à distance.

C'est aussi notre compréhension.

Le RTS sur SCA fournit des exigences de sécurité minimales pour l'authentification des utilisateurs. Dans le cas des services bancaires aux entreprises, les utilisateurs effectuent généralement des paiements de montants relativement élevés. Par conséquent, nous attendons des banques qu'elles protègent leurs applications bancaires d'entreprise avec des mécanismes d'authentification plus stricts que ceux requis par le RTS sur SCA.

Comme indiqué à l'article 13 du projet final de RTS, la SCA n'est pas requise pour les paiements aux bénéficiaires de confiance. Pour les conditions précises, veuillez consulter l'article lui-même.

L'article 10 du projet final de RTS précise que les prestataires de services de paiement ne sont pas dispensés de l'application de l'authentification forte du client aux payeurs qui souhaitent s'informer sur leur solde ou consulter leur historique de paiement des 90 derniers jours si l'une des conditions suivantes est remplie :

• L'utilisateur de services de paiement accède pour la première fois en ligne au solde de son compte ou à l'historique des paiements des 90 premiers jours du paragraphe 1
  
• La dernière fois que l'utilisateur de services de paiement a accédé en ligne à son historique de paiement des 90 derniers jours du paragraphe 1 et l'authentification forte du client a été appliquée il y a plus de 90 jours.

L'article 13 du projet final de RTS permet au prestataire de services de paiement de ne pas procéder à une authentification forte du client si le payeur initie une opération de paiement où le bénéficiaire est inscrit sur une liste de bénéficiaires de confiance préalablement créée. Voir l'article 13 pour les détails.

Il y a deux parties de cette question :

• Chaque fois que la PSP est sur le point de publier son application mobile sur le marché des applications, un blindage d'application doit être appliqué pour que l'application soit protégée. La bonne nouvelle est que le wrapping du blindage de l'application prend plusieurs secondes et n'affecte donc pas les cycles de publication des applications de la PSP.
   
• Étant donné que la solution OneSpan Mobile App Shielding est régulièrement mise à jour pour se défendre contre l'évolution des menaces mobiles, il est également recommandé aux PSP de protéger leurs applications avec la dernière version afin d'assurer le niveau de protection le plus élevé possible.

OneSpan Mobile Security Suite fournit une fonction de liaison de périphérique qui offre une protection contre le clonage pour les applications mobiles.

L'appareil mobile sur lequel le SMS arrive peut également contenir une application d'authentification (dans le scénario 1aa ou 2aa), où le SMS doit être saisi. Cette application devrait être protégée à l'aide d'un blindage d'application mobile.

À notre avis, ce sont deux approches tout aussi sûres qui reposent en fin de compte sur la même technologie sous-jacente de canal de communication sécurisé. Nous les voyons être optimales avec différents modèles d'utilisation. De nombreuses banques mettront en œuvre l'application d'authentification qui fonctionnerait dans la configuration suivante :

Lorsque la transaction est initiée dans l'application bancaire mobile, le lien de communication App2App sera établi vers l'application d'authentification installée sur le même appareil. Cela offre la possibilité de basculer automatiquement entre deux applications, ce qui améliore l'expérience utilisateur.

Lorsque la transaction est initiée sur le navigateur web depuis un autre appareil (PC ou tablette), la notification PUSH sera envoyée vers l'application d'authentification installée sur l'appareil mobile de l'utilisateur. Alternativement, avec presque la même expérience utilisateur, le processus de numérisation et de signature optique peut être utilisé.

Vous pouvez trouver plus d'informations sur les solutions Cronto ici : Signe Cronto

Pour App2App avec canal de communication sécurisé, l'échange de données entre les applications se fait via le backend dans un format crypté.

Les techniques de sandboxing de la plate-forme Windows universelle (UWP) sont similaires à celles d'Android et d'iOS. UWP a adopté de nombreux concepts d'Android et d'iOS. Windows 10 Mobile n'autorise que l'exécution d'applications UWP, de sorte que les mécanismes de sandboxing sont d'une force comparable à celle d'Android et iOS ici. Windows 10 standard permet d'exécuter à la fois des applications UWP et Windows standard, de sorte que le sandboxing est moins puissant qu'Android ou iOS.

Lorsque l'utilisateur utilise une application TPP, nous voyons très probablement l'un des trois cas d'utilisation suivants :

• Notification PUSH de la banque à l'application d'authentification fournie par l'institution financière. Cela ne nécessite pas d'intégration spécifique entre les parties.
   
• Communication App2App entre une application TPP et une application d'authentification fournie par l'institution financière. Cela nécessite une intégration minimale du service d'authentification entre le TPP et l'institution financière. 
   
• Cadre de sécurité mobile intégré dans l'application TPP. Cela implique que le TPP ne s'appuiera pas sur la mise en œuvre de l'authentification par l'institution financière mais fournira la sienne.

Dans les trois options, les TPP et les institutions financières devront collecter les données d'entrée des appareils des utilisateurs et effectuer une analyse approfondie sur plusieurs applications, canaux et points de terminaison pour une évaluation complète des risques. La meilleure option consiste à mettre en œuvre un logiciel de gestion des risques dédié, tel que OneSpan Risk Analytics, qui fournit :

• Détection en temps réel des fraudes sophistiquées
  
• Traitement de grandes quantités de points de données pour détecter les comportements anormaux des utilisateurs, les transactions suspectes et la navigation atypique dans l'application de paiement
  
• Notation précise des risques et atténuation des menaces sur tous les appareils mobiles courants (par exemple, téléphones mobiles et tablettes)
  
• Opérations invisibles pour les utilisateurs finaux, limitant la fraude tout en offrant la meilleure expérience utilisateur possible
  

Le sandboxing est appliqué par le système d'exploitation (par exemple Android ou iOS) de l'appareil mobile à chaque application exécutée sur l'appareil. Le blindage des applications mobiles doit être appliqué à l'application d'authentification.

Oui, c'est le cas.

La fonctionnalité de communications sécurisées de OneSpan Mobile Security Suite offre la possibilité de créer un canal de communication sécurisé entre l'application et le serveur, protégeant la confidentialité, l'intégrité et l'authenticité de toutes les informations de paiement. OneSpan Mobile Security Suite est fourni avec des SDK côté client et côté serveur pour établir le canal sécurisé. De cette façon, les PSP peuvent facilement configurer un canal sécurisé sans avoir à gérer eux-mêmes la complexité du canal sécurisé.

Nous vous recommandons d'utiliser des algorithmes HMAC standard, tels que HMAC-SHA256 ou HMAC-SHA3.

L'application d'authentification doit être protégée par un blindage d'application mobile. L'application bancaire peut être protégée, mais elle n'est pas requise dans le projet final de RTS.

Oui, nous voyons cela comme un élément d'inhérence possible. Les commentaires de l'ABE sur le projet final de RTS indiquent également que cela est possible.

Oui, OneSpan Mobile Security Suite prend en charge l'authentification biométrique basée sur les empreintes digitales, le scan du visage et le comportement de l'utilisateur.

En cas de paiements groupés, le code d'authentification pour SCA doit être calculé sur la base du montant total de tous les paiements combinés et sur la base des numéros de compte de tous les bénéficiaires. Il n'y a pas de dispositions spécifiques concernant la TRA pour les paiements groupés.

Oui, OneSpan Risk Analytics peut être utilisé pour analyser les transactions pour différents types de canaux de paiement.

OneSpan Risk Analytics est disponible sur site ainsi que dans le cloud. La version cloud est hébergée par OneSpan.

Oui, OneSpan Risk Analytics peut effectuer une analyse des risques de transaction conformément aux exigences de la version finale du RTS.

En effet, les PSP doivent toujours utiliser TRA même s'ils utilisent SCA. TRA fournit une deuxième couche de sécurité à côté de SCA. TRA est utile pour se protéger contre les attaques d'ingénierie sociale, par lesquelles un adversaire essaie de convaincre l'utilisateur réel de confirmer un paiement à l'aide de SCA lorsque le paiement est réellement frauduleux.

Le projet final de RTS indique que la procédure d'authentification devrait inclure, en général, des mécanismes de surveillance des transactions pour détecter les tentatives d'utilisation des informations d'identification de sécurité personnalisées d'un utilisateur de services de paiement qui ont été perdues, volées ou détournées. Cela s'applique à toutes les solutions d'authentification, pas seulement à celles de la catégorie 2aa ou 1aa.