Directive DSP2 : effectuer une authentification dynamique qui soit conforme et pratique

L’une des exigences les plus discutées des normes techniques de régulation (RTS) finales sur l’authentification forte du client (SCA) et la norme commune et sécurisée de communication (CSC) dans le cadre de la directive DSP2 est l’obligation de réaliser une « authentification dynamique » pour authentifier une transaction financière.

L’exigence d'une authentification dynamique comporte trois parties. En premier lieu, elle impose au payeur qu’il authentifie une transaction financière en générant un code d’authentification relatif à certaines données de la transaction (au moins le montant et certaines informations identifiant le bénéficiaire), de sorte que le code d’authentification soit associé à ces données. En deuxième lieu, la confidentialité et l’intégrité des données de la transaction doivent être protégées tout au long du processus d’authentification. En troisième lieu, l’utilisateur des services bancaires en ligne doit connaître les données de transaction qu’il authentifie. Cette dernière exigence est souvent appelée « Ce que vous voyez est ce que vous signez » (WYSIWYS). Cela signifie que le simple fait de montrer un hachage des données de la transaction ou un identifiant de session ne suffit pas.

Les législateurs européens qui ont rédigé la directive DSP2 ont ajouté l’exigence de l'authentification dynamique pour contrer les « attaques de l'intercepteur », par lesquelles un attaquant modifie les détails d’une transaction après que le payeur l'a authentifiée. Une telle attaque pourrait transformer un virement authentique de 100 euros à un ami en un virement frauduleux de 1 000 euros à un imposteur, sans que le véritable payeur ne s’en aperçoive. L’exigence WYSIWYS vise à éviter les attaques de piratage psychologique, par lesquelles un payeur est convaincu d’authentifier des données qu’il ne comprend pas, et qui s’avèrent par la suite représenter une transaction frauduleuse. Ainsi, la directive DSP2 va plus loin que les directives finales de l’ABE sur la sécurité des paiements sur Internet, qui s’appliquent actuellement dans la plupart des États membres de l’UE et n’exigent pas d'authentification dynamique.

Pour les banques, le respect des exigences de la directive DSP2 soulève plusieurs questions. Comment une banque peut-elle mettre en place une authentification dynamique dans son application bancaire en ligne ou mobile de manière à ce qu'elle soit pratique pour le client ? Les SMS peuvent-ils être utilisés pour mettre en œuvre une authentification dynamique ? Et qu'en est-il des transactions par lots ?

Examinons ces questions.

Authentification dynamique pratique

Imaginons le scénario dans lequel un utilisateur engage une transaction financière via une application bancaire en ligne s'exécutant dans le navigateur de son PC, à l'aide d'un jeton matériel dédié, ou une application bancaire mobile pour authentifier la transaction.

L'un des moyens pratiques de mettre en œuvre l'authentification dynamique consiste à utiliser des codes QR ou des codes Cronto. Lorsque l'utilisateur souhaite engager une transaction, il doit réaliser les étapes suivantes :

1. Saisir les données de la transaction dans l’application de services bancaires en ligne du navigateur. Sur la base de ces données, le serveur bancaire génère un code couleur, représentant les données cryptées de la transaction, et l’affiche dans le navigateur.
    
2. Scanner, à l’aide de l'appareil photo, le code couleur de son jeton matériel ou de son appareil mobile. L’appareil décode le code couleur, décrypte les données de la transaction et affiche les données de la transaction en clair à l’écran du client.
    
3. S’authentifier auprès de son appareil (par exemple, en saisissant le code PIN de l’appareil), et générer le code d’authentification sur les données de la transaction à l’aide d’une clé cryptographique stockée sur l’appareil.

Cette approche répond à toutes les exigences de l'authentification dynamique décrites ci-dessus et n’impose pas non plus à l’utilisateur de saisir manuellement les données de transaction sur l’appareil.

Une autre approche, uniquement pour le mobile, consiste à transférer les données de transaction du serveur bancaire à l’application bancaire mobile en utilisant un message de notification push crypté. En voici le principe :

• L’utilisateur reçoit un message de notification push sur son téléphone.
• Lorsqu’il l’accepte, l’application bancaire mobile s’ouvre et affiche les données de la transaction à l’utilisateur.
• L’utilisateur s’authentifie à l’aide d’une empreinte digitale ou d’une reconnaissance faciale, par exemple.
• L’appareil calcule le code d’authentification sur les données de la transaction.
• L’application bancaire mobile renvoie le code d’authentification au client via l’Internet.

Cette approche est également conforme aux exigences d'authentification dynamique et ne nécessite pas que l’utilisateur saisisse manuellement des données sur l’appareil mobile.

Transactions par lots

L’exigence d'une authentification dynamique s’applique également aux transactions par lots ou aux paiements groupés, dans lesquels plusieurs transactions vers différents bénéficiaires sont combinées. Plus précisément, les RTS finales stipulent que, pour les transactions par lots, le code d’authentification doit être spécifique à la fois au montant total de toutes les transactions combinées et aux différents bénéficiaires.

Si le nombre de bénéficiaires est important, il n’est pas pratique de les montrer tous à l’utilisateur pour validation. Les approches suivantes peuvent alors être utilisées pour équilibrer la sécurité et le confort de l’utilisateur :

1. Montrer à l’utilisateur les bénéficiaires correspondant aux transactions présentant le plus grand risque.
    
2. Montrer à l’utilisateur les bénéficiaires sélectionnés au hasard.
    
3. Ne pas montrer à l’utilisateur les bénéficiaires de la liste blanche.

Dans tous les cas, il est judicieux d’inclure un hachage de toutes les transactions dans le calcul du code d’authentification afin de protéger l’intégrité de toutes les transactions.

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 authentification dynamique par SMS ?

La question se pose également de savoir si l'authentification dynamique pourrait être mise en œuvre par SMS. Dans ce cas, l’utilisateur recevrait un message SMS contenant les données de la transaction ainsi que le code d’authentification calculé sur les données de la transaction.

Compte tenu de la nécessité de protéger la confidentialité et l’intégrité des données de transaction, il serait alors nécessaire de crypter les données de transaction contenues dans un message SMS. Il n’est pas évident de comprendre comment le message pourrait ensuite être décrypté sur l’appareil mobile sans utiliser une application dédiée. La nécessité d’une application mobile pour traiter les messages SMS sape l’un des principaux avantages des SMS.

Informations complémentaires

En résumé, les banques devraient aborder la directive DSP2 sans se limiter à la question de la conformité. En effet, il est important d’examiner comment optimiser l’expérience utilisateur au moyen de procédures pratiques d’authentification forte et d'authentification dynamique. Pour plus d’informations, téléchargez : DSP2 : Quelles sont les solutions d’authentification forte et de surveillance des transactions qui répondent à la nouvelle réglementation ?