Une authentification forte client dans le cadre de la directive DSP2 : le bon, la brute et le truand

Dans quelques jours, le 14 septembre 2019, les exigences tant attendues de l'authentification forte du client (SCA) sous PSD2 entreront enfin en vigueur. Publiées il y a environ 18 mois par la Commission européenne dans les Normes techniques de réglementation (RTS) sur l'authentification forte du client et la communication commune et sécurisée, ces exigences auront un impact sur la façon dont les consommateurs en Europe accèdent à leurs applications bancaires sur Internet, paient leurs achats en ligne et utiliser de nouveaux services financiers fournis par des fournisseurs tiers (TPP) via Open Banking.

Dans cet article, nous revenons sur SCA sous PSD2 et évaluons ce qui s'est bien passé et ce qui est nécessaire pour un déploiement ultérieur réussi de SCA en Europe.

1) Le bien

La PSD2 augmente le niveau de sécurité pour l'authentification auprès des services financiers dans toute l'Europe et harmonise la force des processus d'authentification pour les applications financières.En raison de la PSD2, les institutions financières ont progressivement éliminé les méthodes d'authentification faibles. Des exemples sont des solutions basées uniquement sur des combinaisons nom d'utilisateur / mot de passe, et des solutions basées sur des listes imprimées de codes d'authentification, telles que des listes TAN et des cartes matricielles. Comme le confirme l'avis de l'Autorité bancaire européenne (ABE) du 21 juin, ces solutions ne répondent pas aux exigences de la SCA.

PSD2 garantit que les concepts d'authentification avancés, tels que la liaison dynamique, la liaison d'appareil pour les applications mobiles, la protection des applications mobiles et l'analyse des risques de transaction deviennent des outils de sécurité standard dans les services financiers. À cet égard, la PSD2 va beaucoup plus loin que les Directives finales sur la sécurité des paiements par Internet , qui est devenue applicable le 1er août 2015 et sera remplacée par PSD2 le 14 septembre.

PSD2 accélère également l'adoption de méthodes d'authentification adaptatives, qui ajustent la manière dont l'utilisateur est authentifié au risque de ce que l'utilisateur veut faire. En tant que tel, PSD2 permet de trouver un équilibre spécifique à l'utilisateur entre la commodité et la sécurité. Cette approche a été intégrée dans le RTS grâce à l'ouverture et à l'étroite collaboration de l'ABE avec les acteurs du secteur lors de la rédaction du RTS.

2) La mauvaise

PSD2 met la responsabilité de protéger l'accès aux comptes bancaires auprès des banques, également connus sous le nom de fournisseurs de services de paiement de gestion de compte (ASPSP). Les banques étant propriétaires des comptes bancaires, cela semble logique à première vue.

Cependant, en y regardant de plus près, il devient clair que cette approche crée une complexité significative dans le contexte de l'Open Banking, comme suit:

• Tout d'abord, les utilisateurs d'applications TPP devront s'authentifier deux fois: une fois pour accéder à l'application TPP, et une seconde fois pour utiliser un certain compte bancaire via l'application TPP.

• De plus, la méthode d'authentification et le flux d'un certain compte bancaire dépendent de la banque. Par exemple, la banque A pourrait mettre en œuvre l'authentification à l'aide d'un lecteur de carte et d'une approche de «redirection», tandis que la banque B pourrait utiliser une application mobile via l'approche «découplée». L'expérience utilisateur au sein de l'application TPP dépendra donc de la banque.

En conséquence, l'expérience d'authentification globale pour l'utilisateur TPP moyen s'annonce compliquée.

Cependant, la PSD2 elle-même n'est pas à blâmer pour cela. Le problème est la conséquence d'un problème plus vaste qui transcende la PSD2, à savoir l'absence d'un système d'identité numérique paneuropéen fondé sur des identités vérifiées et dignes de confiance. L'inspiration pour de tels systèmes se trouve déjà dans plusieurs pays, tels que la Suède (Bank ID) et l'Inde (Aadhaar). Le défi est de construire un tel système au niveau européen. Un tel système est essentiel pour l'avenir de l'Open Banking.Article récent de Citi fournit une inspiration supplémentaire pour cela.

3) Le truand

Les exigences SCA de PSD2 sont censées être à l'épreuve du temps et indépendantes de la technologie. Ils offrent une certaine marge de manœuvre aux fournisseurs de services de paiement (PSP), ce qui signifie que les PSP peuvent décider de la meilleure façon de répondre à une certaine exigence.Cependant, cela peut laisser les PSP, qui doivent répondre aux exigences, dans le noir. Quelques exemples:

• Utilisation de SMS pour la liaison dynamique . L'ABE a précisé dans son avis du 21 juin que le SMS peut être considéré comme un élément de possession valide. Plus spécifiquement, la carte SIM de l'appareil mobile qui reçoit le SMS est un élément de possession valide. Cela implique que les mots de passe à usage unique (OTP) délivrés par SMS peuvent être utilisés pour construire un mécanisme d'authentification fort lorsqu'ils sont combinés avec un deuxième facteur (par exemple un mot de passe ou un code PIN). Cependant, l'avis ne précise pas si le SMS peut être utilisé pour la liaison dynamique. En effet, l'exigence de liaison dynamique de l'article 5 du RTS stipule que la confidentialité et l'intégrité des informations de paiement (par exemple, numéro de compte bancaire, montant d'argent) doivent être protégées pendant le processus d'authentification. Étant donné que le contenu d'un SMS n'est généralement pas protégé, il semble SMS ne répond pas aux exigences de liaison dynamique .

• Création d'un environnement d'exécution sécurisé pour les applications mobiles . Le RTS stipule que les PSP doivent utiliser des environnements d'exécution sécurisés pour protéger les applications mobiles. Cependant, le RTS final ne définit pas quelle un environnement d'exécution sécurisé est en fait, ou comment il pourrait être mis en œuvre. Compte tenu de l'état actuel de la sécurité des applications mobiles, la meilleure approche pour répondre à cette exigence consiste probablement à utiliser technologie de protection des applications , protégeant l'application contre les menaces telles que les superpositions, l'injection de code et l'enregistrement de frappe.

Enfin, le calendrier de mise en œuvre des exigences SCA de PSD2 a commencé à changer ces derniers mois. À l'origine, les exigences SCA pour les applications bancaires sur Internet et de commerce électronique deviendraient applicables le 14 septembre 2019. À la même date, l'obligation pour les banques de fournir une interface de communication pour l'Open Banking entrerait en vigueur. Cependant, depuis que l'ABE a publié son avis le 21 juin, les délais sont devenus plus fragmentés. Au moment de la rédaction, les délais sont les suivants:

• Date limite pour que les banques mettent en œuvre la SCA pour les services bancaires par Internet: 14 septembre 2019, sauf au Royaume-Uni où la date limite est désormais le 14 mars 2020

• Date limite de mise en œuvre du SCA pour les paiements par carte pour le commerce électronique: les délais spécifiques au pays sont autorisés

• Date limite pour que les banques proposent des interfaces Open Banking: 14 septembre 2019

En conséquence, différents PSP peuvent avoir des délais différents pour se conformer aux exigences du SCA, ce qui pourrait avoir un impact sur les paiements lorsque plusieurs PSP sont impliqués. Par exemple, si un paiement par carte est effectué entre un émetteur de carte conforme au 14 septembre 2019 et un acquéreur qui a reçu une prolongation de 6 mois, par exemple, l'acquéreur peut alors envoyer une demande de paiement sans SCA à l'émetteur, mais le L'émetteur refusera le paiement car il nécessite la SCA. En conséquence, les paiements pourraient être refusés bien que l'émetteur et l'acquéreur agissent correctement. Cela soulève clairement la nécessité pour les autorités compétentes (AC) d'accorder des prolongations de manière coordonnée. L'ABE devrait jouer ici le rôle de coordinateur entre les différentes autorités compétentes.

Dans le film épique de Sergio Leone de 1966, le bien prend l'or, le méchant meurt et le truand est sauvé par la miséricorde du bien. Espérons que le script du film s'applique également à PSD2.

WHITE PAPER

PSD2: Quelles solutions d'authentification forte et de transaction sont conformes?

Découvrez les exigences les plus importantes du RTS final et les solutions d'authentification les plus susceptibles de répondre aux exigences.

Télécharger

Une analyse plus approfondie de PSD2 et de ses exigences d'authentification forte du client est disponible ici .