L’entrée en vigueur du deuxième “volet” de la DSP2 : vers la sécurisation des Fintechs ?

‍

© https://hello-finance.com/tout-savoir-sur-la-dsp2/

‍

Le développement des Fintechs, ayant recourt à la pratique sauvage du web scraping ainsi que l’accroissement des fraudes aux paiements en ligne, qui représente aujourd’hui environ 1 euro de fraude pour 620 euros de transaction, a rendu nécessaire l’encadrement des Fintechs dont l’activité se trouvait jusqu’alors dans un vide juridique.

C’est chose faite depuis l’adoption de la Directive sur les services de paiement (DPS2) et l’entrée en vigueur du Regulatory Technical Standards (RTS), régissant les exigences techniques de la DSP2, le 14 septembre dernier.

Notions clés

‍

Directive sur les services de paiement (DSP2) : La Directive met en place des exigences générales tandis que les normes techniques de réglementation sur l’authentification et les communications sécurisées sont définies par l’Autorité Bancaire Européenne (ABE).

‍

Figure 1 : Timeline du parcours législatif de la DSP2 et des RTS

‍

La DSP2 a deux ambitions principales : imposer des exigences de sécurité accrues aux banques, notamment concernant les paiements en ligne et d’ouvrir l’accès aux données bancaires aux TPP (Third Party Providers) et Fintechs.

‍

‍

Le champ d’application de la DSP2 se limite aux services de paiement fournis au sein de l’Union européenne ; c’est-à-dire, lorsque le prestataire de services de paiement du client et celui du e-commerçant se situent dans l’Union. En outre, la Directive ne s’applique qu’aux comptes de paiement et ne concerne pas les transactions effectuées depuis un compte épargne.

‍

Figure 3 : Schéma des services de paiement au sens de la DSP2

‍

Fintech ou TPP (Third Party Provider) : apparues dans les années 80–90 et ayant connu un réel essor après la crise financière de 2007, les technologies de la finance désignent le plus souvent des start-ups innovantes dans le domaine des services financiers et bancaires. Ces entreprises proposent des services alternatifs comme les Paytech (ex : Paypal), Insurtech (ex : Breega, Newalpha) ou Néobanques (ex : N26).

La DSP2 a étendu le statut de prestataire de services de paiement (PSP) jusqu’alors uniquement applicable aux banques, à certains de ces acteurs afin d’encadrer leur activité :

Payment Initiation Services Provider (PISP) : initiateur de paiement, agit comme un prestataire de services qui va transmettre un ordre de paiement, au nom et pour le compte de ses clients, à l’établissement de paiement adéquat.
Account Information Service Provider (AISP) : agrégateur de compte qui fournit à ses clients disposant de plusieurs comptes (dans la même banque ou chez plusieurs établissements) une vision d’ensemble, ou dashboard de l’état de ses comptes et opérations

Figure 4 : Schéma PSP pré et post intégration des Fintech

‍

Web scraping : ou capture de données d’écran en français, n’est pas ici entendue comme une attaque informatique mais comme le procédé utilisé par les Fintechs afin d’accéder puis d’agréger les données bancaires de leurs clients. Le client va transmettre aux TPP ses identifiants qui seront utilisés par des bots afin d’accéder aux données bancaires. Ce procédé empêche les banques de savoir si le compte est accédé par le client ou le prestataire de services.

API « ouverte » : une API (Application Programming Interface ou interface de programmation) « ouverte » permet à plusieurs systèmes indépendants d’interagir et d’échanger des données entre eux (ex : lorsque Facebook ou Google proposent de se connecter à une plateforme tierce via vos comptes associés).

‍

Quelles sont les exigences de sécurité pour les paiements en ligne ?

‍

Avant l’entrée en vigueur de la DSP2, le choix de déclencher une authentification forte pour les paiements en ligne dépendait du e-commerçant et non de la banque de l’acheteur. La DSP2 inverse ici les rôles : il reviendra à la banque de l’acheteur de déclencher ou non l’authentification forte en fonction de certains critères fixés par la DSP2.

Le RTS (Regulatory Technical Standards), Bible de la DSP2 en matière d’exigences de sécurité, a deux objectifs principaux. D’une part, la mise en place d’une authentification à double facteurs pour les opérations en ligne (et sans contact) à partir d’un certain montant et d’autre part, la création d’API « ouvertes » et sécurisées permettant aux PISP et PAISP d’avoir accès aux données bancaires de leurs clients.

L’authentification forte

Quelles sont les exigences des RTS en termes d’authentification forte ?

L’authentification forte permet de renforcer la sécurité des transactions effectuées auprès de e-commerçants. En effet, l’indépendance des éléments d’authentification permet, en cas de compromission d’un des facteurs, de garantir l’intégrité du second.

Le RTS ajoute une exigence supplémentaire : l’authentification doit utiliser un One-Time-Password (OTP) ou mot de passe aléatoire à usage unique. Concrètement, lorsque l’authentification forte a recours à un code confidentiel, celui-ci ne doit être valable que pour une transaction unique. Par conséquent, toute modification de la transaction en question générera un nouvel OTP.

‍

Figure 5 : Fonctionnement du système d’authentification SMS-OTP

‍

L’OTP le plus utilisé par 71% des e-commerçants en France est l’envoi d’un mot de passe aléatoire par SMS sur un téléphone (via le protocole 3D Secure). Ce procédé permet d’identifier le client détenteur du téléphone et de manifester le consentement du client au paiement en ligne. Toutefois, le SMS-OTP n’est pas exempt de risques de sécurité puisqu’il fait l’objet, comme nous le verrons, de différentes attaques.

La mise en place de ces nouvelles procédures est d’une part, lourde à implémenter pour les PSP qui devront s’assurer que leurs infrastructures disposent de la capacité nécessaire de calcul et de traitement de ces nouveaux flux d’informations, et d’autre part, pour les clients, qui verront le temps de validation de leurs transactions sensiblement allongé.

Cependant, la DSP2 prévoit une liste exhaustive des exceptions à l’exigence d’authentification forte, devant être interprétée strictement :

Opérations récurrentes de paiement (d’un même montant et vers le même bénéficiaire). Dans cette hypothèse, seule la première opération exigera une authentification forte ;
Virements depuis et vers un compte détenu par la même personne physique ou morale au sein d’une même banque ;
Consultation de comptes, lorsque la dernière authentification forte date de moins de 90 jours ;
Les paiements de faible montant (cf. tableau des plafonds) ;
D’autres exceptions existent, pour des cas de figure très particuliers.

‍

Figure 6 : Tableau des différentes exceptions à l’authentification forte en fonction des montants de transaction

‍

Il faut cependant rappeler que cette nouvelle exigence de sécurité ne s’applique que lorsque le donneur d’ordre et le e-commerçant exercent une activité sur le territoire de l’UE. En effet, lorsque l’un ou l’autre (ou bien ni l’un ni l’autre) ne se trouvent pas sur le territoire de l’Union, la DSP2 n’a pas vocation à s’appliquer.

La Directive laisse ainsi un vide juridique et de potentiels points d’entrées à des attaquants ; la sécurisation des transactions en ligne n’est donc que partielle.

Quelle différence entre l’authentification à multi-facteurs et l’authentification forte ?

L’authentification à multi-facteurs est un procédé d’authentification utilisant au moins deux éléments d’authentification parmi éléments suivants : ce que je suis le seul à connaître, ce que je suis le seul à posséder et qui je suis (éléments inhérents à l’utilisateur). En fonction du couple d’éléments d’authentification utilisé, le procédé d’authentification sera considéré une authentification forte ou simplement multi-facteurs :

‍

Figure 7 : Tableau des différentes combinaisons de facteurs d’authentification

‍

Risques liés à l’utilisation d’un mécanisme d’authentification à double facteurs

Le couple de facteurs d’authentification le plus usité en France est l’usage d’un mot de passe et l’envoi d’un code de vérification par SMS. Cependant, cette méthode présente des vulnérabilités connues, notamment l’interception de SMS via le protocole SS7. Cette vulnérabilité consiste à rediriger les SMS (contenant le code pour l’authentification à double facteurs) vers un attaquant. Cette même vulnérabilité a été exploitée à de nombreuses reprises, notamment à l’encontre de grandes entreprises comme Reddit (USA), Metro Bank (UK), etc.

De plus, si le smartphone est compromis (ex : vol du périphérique déverrouillé), le second facteur d’authentification devient inutile.

D’autres méthodes d’authentification à double facteurs, telles que l’envoi d’un code par mail, sont également vulnérables. En effet, un e-mail peut être intercepté si celui-ci n’est pas chiffré. C’est pourquoi le choix d’une bonne solution d’authentification à double facteurs est primordial.

Enfin, lors du choix de la solution biométrique pour authentifier un utilisateur, les risques liés au « Deepfake » (falsification de la voix ou du visage) doivent également être pris en compte.

Quels mécanismes pour l’authentification forte ?

‍

Figure 8 : Tableau non-exhaustif des mécanismes d’authentification forte

‍

Entrée en vigueur de l’authentification forte retardée pour plus de 10 pays de l’UE

La France, l’Allemagne, l’Italie, l’Espagne, le Royaume-Uni et d’autres pays de l’UE ont accordé un délai supplémentaire aux banques et e-commerçants pour mettre en place les solutions permettant de s’aligner sur les exigences d’authentification forte de la DPS2 (qui aurait dû entrer en vigueur le 14 septembre dernier).

En attendant l’entrée en vigueur du RTS, le seul système d’authentification « forte » exigé par la DSP2 reste l’envoi d’un code confidentiel par le procédé SMS-OTP. Il semble que les acteurs de ce marché (banques et e-commerçants) ne soient toujours pas en mesure d’apporter les garanties de sécurité exigées par le RTS puisque plus de 20 pays de l’UE ont accordé un report à l’entrée en application de cette disposition. A ce jour, seuls la France et le Royaume-Uni ont indiqué le temps accordé aux commerçants et aux banques pour se mettre en conformité vis-à-vis des exigences de la Directive : 36 mois (au total) pour la France et 18 mois pour le Royaume-Uni.

Toutefois, l’entrée en vigueur de cette disposition reste incertaine car l’ABE (Autorité Bancaire Européenne) souhaite un délai harmonisé et « raisonnable » sans pour autant définir ce délai raisonnable de manière explicite.

Sécurité des communications : l’exigence d’API « ouvertes » et sécurisées

Le second pan de la DSP2 en termes de sécurité est la mise en place d’API (interface de programmation) innovantes et sécurisées afin d’ouvrir les données bancaires aux Fintechs (qui n’ont plus le droit d’avoir recours au web scraping engendrant des risques pour le client d’un TPP).

En effet, le client devait fournir les codes d’accès à son compte bancaire au TPP ; or, la communication de ces codes d’accès peut faire l’objet d’attaques si le canal de communication utilisé n’est pas sécurisé.

Les API développées par les banques devront non seulement ouvrir les données bancaires aux tiers (PISP et AISP) mais également assurer l’intégrité, la confidentialité et la non-répudiation des paiements en ligne.

Si la mise en place d’API permet de mettre fin à une pratique à risques, centraliser les flux de données sur une API peut créer un goulot d’étranglement en cas d’attaque. Par conséquent, les banques ne pourront pas se limiter à un niveau de sécurité minimum.

‍

© https://www.certeurope.fr/blog/certificats-dsp2-la-solution-pour-un-ecosysteme-open-banking-de-confiance/

‍

Afin de garantir le niveau de sécurité exigé par la DSP2 et d’assurer la traçabilité des échanges entre les différents acteurs (banques, PISP et AISP), ces derniers devront utiliser deux certificats électroniques issus du Règlement eIDAS (sur l’identification électronique et les services de confiance pour les transactions électroniques au sein du marché intérieur) :

Le certificat eIDAS QWAC (Qualified Authentication Certificate) permettant aux serveurs d’un PSP / d’une banque d’effectuer une authentification mutuelle, ainsi que le chiffrement des communications de bout en bout ;
Le certificat eIDAS QSealC (Qualified Electronic Seal Certificate) permettant aux serveurs des PSP / d’une banque de sceller le contenu d’une transaction.

La question majeure qui vient à se poser avec l’entrée en vigueur du RTS est l’articulation des différentes normes relatives à la sécurité des communications, transactions financières et données à caractère personnel. En effet, certaines dispositions de la norme PCI-DSS, du Règlement eIDAS ou encore du RGPD (notamment son article 32 relatif à l’obligation de sécurité des données à caractère personnel) peuvent entrer en conflit. S’il est de principe que la loi spéciale déroge à la loi générale, qu’en est-il lorsque les normes en conflit mélangent droit dur et droit mou ?

On constate depuis 2016 que le marché des Fintech atteint progressivement sa phase de maturité (rythme de créations des fintechs qui se stabilise, recherche de fonds et scale-up) et l’entrée en vigueur (même partielle) de la DPS2 participe au développement de l’Open Banking. Si l’élargissement de l’accès aux données bancaires à un plus large public est bénéfique pour les Fintech, cela crée cependant de nouvelles menaces auxquelles devront faire face les banques (et qui seront traitées dans un prochain article).

Forte de ses dix ans d’expérience en conseil et audit, OWN peut vous accompagner tout au long de votre processus de mise en conformité à la DSP2 ; tant par le biais d’audits de conformité (techniques et organisationnels), que dans l’intégration de la sécurité dans les développements (formations) ainsi que dans l’implémentation de solutions d’authentification forte (certifiées eIDAS ou non) et des processus et de l’organisation liés.

‍

Sources :

‍

Partager l'article :