La PSD2
Dans le cadre de la directive n. 2366 de 2015 de l’Union Européenne, connue aussi comme PSD2, et adressée aux intermédiaires de services de paiement, il y a un article qui prévoit l’obligation pour les établissements bancaires de se doter de procédures d’Authentification Forte pour l’accès aux comptes et pour la réalisation d’opérations de paiements par les clients. Les normes techniques de référence sont contenues dans le document EBA-Op-2019-06 de l’E.B.A. (Autorité Bancaire Européenne). Il prévoit l’utilisation, en particulier, d’au moins deux des trois éléments appartenant aux catégories : « inhérence », « possession » et « connaissance ». L’ « Inhérence » est liée à des caractéristiques personnelles de l’utilisateur lui-même, une caractéristique biométrique telle que l’empreinte digitale, la voix ou une lecture de l’iris, par exemple. La « possession » se réfère à des objets matériels ou immatériels que seul l’utilisateur possède, comme, par exemple un logiciel configuré de manière unique, une carte à puce, un téléphone mobile et la carte à microprocesseur sur laquelle il reçoit un code de validation par SMS de type OTP. La « connaissance », enfin, est un mot de passe, un code PIN, ou des informations mnémoniques que seul l’utilisateur connaît.
Pour les banques qui ont une vision à long terme, la PSD2 est l’occasion d’améliorer leurs systèmes intérieurs et leurs services, au profit de renforcer la compétitivité du marché. Toutefois, la directive laisse une grande marge de flexibilité pour la partie relative à l’authentification forte. Par conséquent, cette question peut être abordée avec un minimum d’efforts ou avec des efforts considérables. Dans les deux cas, elle est pleinement conforme à la législation. Toutes les options prévues par la directive peuvent être combinées de multiples façons, y compris par tirage au sort (le moindre effort). En revanche, les combinaisons qui garantissent un niveau de sécurité très élevé et simultanément un niveau considérable de privacy sont très peu nombreuses et ils doivent être mises en œuvre avec une extrême attention (les efforts considérables). Je vais essayer de mieux argumenter ce sujet dans le paragraphe suivant.
Les problèmes de privacy du consommateur et la faiblesse de l’utilisation du mot de passe statique et de sms OTP.
Actuellement, de nombreuses banques se sont adaptées à la PSD2 de différentes manières. La plupart d’entre elles ont en commun des codes PIN et/ou des mots de passe et/ou des questions secrètes qui sont associés à d’autres éléments, tels que :
- OTP reçu par SMS
- Token software (sur le smartphone et la tablette)
- Token hardware fourni par la banque (les porte-clés token matériels)
- Données biométriques (notamment les empreintes digitales obtenues à partir de smartphones/tablettes)
Malheureusement, il y a toujours des cas de fraude des opérations de paiement électronique, même pour les établissements de crédit qui se sont conformés à la directive (il suffit de chercher sur le web les nouvelles sur ce sujet à l’aide du mot-clé « sim swap », par exemple). A cet égard, les banques pourraient affirmer que l’une des difficultés majeures, à savoir le clonage des cartes SIM, n’est pas de leur responsabilité et que les opérateurs téléphoniques tardent encore à renforcer les mesures pour contenir ce phénomène, par exemple par l’adoption des « eSIM », etc., etc. En effet, il est peut-être vrai qu’une partie de la responsabilité du clonage des cartes SIM incombe aux opérateurs téléphoniques, mais je n’ai pas suffisamment d’éléments pour entrer dans le vif du sujet. Je voudrais plutôt souligner les faiblesses évidentes des quatre exemples d’authentification forte énumérés ci-dessus.
Tout d’abord, la « connaissance », c’est-à-dire la mesure commune à presque tous les systèmes d’authentification des banques (le mot de passe, le code PIN, les questions secrètes - appelons-les par simplicité « mots d’ordre »), a pour point faible l’utilisateur lui-même. Si vous choisissez des « mots d’ordre » faibles ou si ceux-ci sont délibérément fournis à quelqu’un d’autre ou s’ils sont insérés en répondant à un e-mail de phishing, voici les remèdes sont très peu nombreux. Heureusement, on peut se sauver in extremis en les changeant une fois qu’on s’est rendu compte de ses erreurs ou de sa naïveté, à condition que les autres facteurs (inhérence et/ou possession) soient bien appliqués.
L’ « OTP » sur SMS, comme cela a déjà été dit, est aussi vulnérable parce qu’il est possible de cloner une carte SIM (ce qui n’est pas facile du tout, mais cela arrive parfois, selon les nouvelles). Mais, même si le clonage était compliqué, par exemple avec les eSim ou encore mieux avec des systèmes de vérification des documents d’identité présentés (comparaison avec la photographie du document original, accès au système d’information SCIPAFI, etc.), il pourrait toujours y avoir un point de vente qui clone les cartes SIM.
Le « token software » est généralement activé par une procédure d’enregistrement qui crée une clé liée à l’identifiant unique d’un appareil (par exemple un smartphone ou une tablette). Cela signifie que seuls ceux qui sont en possession de ce dispositif peuvent effectuer l’authentification. Ce système est faible. La première faiblesse réside dans la phase d’enregistrement, qui prévoit généralement l’utilisation de combinaisons d’OTP sur des messages et des mots de passe de différents types. Ce processus expose à des problèmes de clonage des cartes SIM, de phishing ou d’autres fraudes basées sur la « connaissance ». La deuxième faiblesse est la protection du dispositif. Si l’utilisateur n’active pas une protection solide (comme un code PIN avec cryptage de la mémoire) sur son appareil et que celui-ci est volé, cela peut avoir des conséquences regrettables. Ensuite, si vous avez également enregistré les informations d’accès (par exemple, dans un APP pour écrire des notes), le désastre est assuré.
Le « token hardware » est probablement le média globalement le moins faible de tous (tant au niveau de la sécurité que de la privacy). Il est clair qu’il entraîne des coûts d’approvisionnement considérables pour les banques, en particulier lorsqu’il s’agit de producteurs haut de gamme. Cette dernière option est indispensable si l’on veut maximiser les niveaux de sécurité des consommateurs. La seule faiblesse possible, réside dans la méthode de génération des clés de cryptage dont seul le fabricant du logiciel est au courant, et qui doit être capable de le protéger avec une extrême prudence.
Les « données biométriques » ont un niveau de sécurité très élevés. Les empreintes digitales, le timbre vocal et une lecture de l’iris sont assez compliqués à reproduire. Il est également très difficile de soustraire ces informations à un individu sans que celui-ci ne s’en rende compte. Mais, si par hasard la donnée biométrique était volée, alors vous serez menacées par des attaques d’usurpations d’identité (une application spéciale pourrait être utile pour se rappeler de ce qui reste : vous avez encore à disposition huit doigts, une rétine, votre voix et le profil gauche). Qui donnerait à des tiers ses propres données biométriques ? Il est clair que le destinataire - une banque dans ce cas - ne le déposerait pas dans ses archives, mais les traiterait avec des opérations opportunes de hashing qui empêcheraient de reconstruire la donnée originale. Mais il faut se demander : si par hasard, pour une seule fois, à cause d’une erreur matérielle, vous le mémorisez en clair lettre ? Et si cette donnée était volée par une cyber-intrusion ? Dans cette dernière hypothèse, une donnée écrit non claire pourrait également être sensible, dans la mesure où la possibilité de reconstituer les données d’origine a été démontrée par certains chercheurs (voir divers articles sur le web). Donc, pour résumer, le vrai problème des données biométriques n’est pas tant la sécurité (en théorie, en effet, n’importe quel type de données peut être volé) mais la privacy, parce qu’on s’expose à la soustraction de données sensibles, le patrimoine irremplaçable d’un individu.
En ce qui concerne les cas de soustraction des données de sécurité personnalisées d’un utilisateur, j’ai décrit, dans ce paragraphe, ceux qui se produisent très fréquemment, ceux d’extrême rareté, ainsi que des cas, si plausibles, qui n’ont, peut-être, jamais eu lieu jusqu’à présent. Ces derniers ne doivent pas être sous-estimés, en particulier dans ce contexte, car, lorsqu’il s’agit de soustraire de l’argent, les cybercriminels sont toujours prêts à se surpasser.
Deux solutions à haute sécurité et pour la protection de la privacy des clients
Parmi les solutions pour l’authentification forte, conformes à la PSD2 et capables de garantir la sécurité et la privacy aux niveaux les plus élevés actuellement disponibles, je peux en proposer en grandes lignes seulement deux. Il faut affirmer que les deux solutions doivent être fondées sur l’élément « connaissance », et que la privacy du client est protégée par le fait qu’il n’est pas prévu d’acquérir des données biométriques ou d’autres informations sensibles.
La première solution, déjà indirectement énoncée ci-dessus, prévoit l’adoption de « tokens hardware » protégés par le code PIN. En cas de vol ou de perte des données de sécurité personnalisées d’un utilisateur, la protection d’un code PIN peut empêcher les risques de fraude (un client a peut-être noté les informations d’accès sur le « token », mais, on espère qu’il n’a pas noté le même code PIN, et, à ce moment-là, comme l’exige la PSD2, la banque ne serait pas coupable). Les « token hardware » doivent être de haute qualité, connus pour leur durabilité et leur excellente autonomie. Ils doivent être synonymes de performances et de fiabilité afin de garantir la robustesse du mécanisme cryptographique. Cette dernière a toujours une durée limitée dans le temps. Il est convenable, donc, de remplacer périodiquement les dispositifs par de nouveaux. Toutes ces exigences sont coûteuses, mais, elles garantissent des niveaux de protection très élevés (et une protection maximale pour les banques en cas de recours de la part des clients).
La deuxième solution est, peut-être, plus intéressante que la première, car elle garantit le même niveau de sécurité mais ne nécessite pas d’approvisionnement coûteux. Cependant, cela demande un certain temps à consacrer à la procédure d’authentification des clients et des visites sporadiques à la banque. Il s’agit d’un « token software » dans lequel la phase d’enregistrement est modifiée. L’utilisateur ne sera plus autonome d’enregistrer le « token » à l’intérieur de son appareil, mais, il devra se rendre à la banque au moins la première fois ou s’il change d’appareil. Cela signifie que l’envoi typique d’un message (afin de prévenir le clonage d’une carte SIM) est remplacé par une opération à effectuer en personne dans sa filiale de référence, après la reconnaissance du client par l’employé de banque. Dans la plupart des appareils (généralement des smartphones et des tablettes), on peut obtenir un code d’identification unique du dispositif lui-même, tandis que d’autres pas. Dans le premier cas, le client peut enregistrer son appareil une seule fois (en plus de toutes les autres fois où il change l’appareil). Dans le deuxième cas, l’identifiant serait créé lors de l’installation de l’APP de la banque, de sorte que le client devra faire l’enregistrement, ainsi que dans les circonstances prévues par le premier cas, chaque fois qu’il désinstalle et réinstalle l’APP dans l’appareil. Cela peut paraître laborieux, mais, des niveaux de sécurité élevés coûtent chers et si la banque ne paie pas le coût du « token », ce sont les clients qui en feront les frais même si la banque devra également investir un peu de temps de sa main-d’œuvre dans l’assistance à ces clients. Il y a beaucoup de façons d’appliquer ce type de « token ». Je peux en proposer un qui peut minimiser les inconvénients. Une fois que l’APP de la banque est installé, on envoie automatiquement un message au serveur en lui communiquant un « hash » identifiant (l’identifiant est unique de l’appareil ou associé à l’installation de l’application). Le serveur répondra par un numéro séquentiel correspondant à l’id de l’enregistrement de la base de données, et, cette donnée est enregistrée hors ligne dans l’APP pour que le client puisse la communiquer à l’employé de banque. Le fait que le client communique un nombre entier relativement petit plutôt que le « hash » de l’identifiant de l’appareil, est conçu, de manière banale, pour éviter d’avoir à dicter une chaîne compliquée avec des centaines de caractères. Le « token » est alors activé, en associant le « hash » au client, toujours dans la base de données de la banque.
Conclusions
Presque toujours, le maillon le plus faible de la chaîne de sécurité est l’utilisateur final et il est compliqué de prévenir les comportements incorrects de sa part tout comme il est compliqué de diffuser la culture informatique et les bonnes normes de sécurité. Par conséquent, je considère que la protection des clients, même de soi, est une responsabilité normale des banques. Il peut être considéré comme un complément indispensable à la protection des dépôts, de l’épargne, des investissements dont s’occupent habituellement les établissements de crédit. Au moment où un client subit une fraude des opérations de paiement électronique, la banque pourra documenter qu’elle a fait tout son possible pour le prévenir et la seule cause est la négligence du client. La communication claire des modalités et des précautions minimales d’utilisation (ne jamais fournir d’informations d’identification à des tiers, ne jamais emporter les données d’identification écrites sur un support papier, protéger les appareils avec des codes PIN, installer des anti-logiciels malveillants, etc.) en font un exemple. La chaîne de gestion de la sécurité doit, donc, comporter au moins deux maillons :
- Recommandations initiales à la clientèle lors de la délivrance des données d’identifiants d’accès aux systèmes informatiques en ligne, ainsi qu’à toute mise à jour ultérieure (ceci implique aussi une formation spécifique et ponctuelle des employés sur le sujet)
- adoption de mesures de sécurité élevée
Le point 2 exige des coûts potentiellement considérables. Je suppose que pour le réduire il est admissible que la banque insère un maillon intermédiaire à la chaîne précédente. C’est-à-dire le choix individuel d’un niveau élevé de sécurité (moins cher) ou très élevé de sécurité (plus cher) effectué par chaque client, mais toujours aidé par l’employé de banque. Par exemple, le niveau élevé est représenté par les données biométriques - qui pourrait être apprécié par les clients qui préfèrent les implications d’ordre pratique à la privacy. Il pourrait également inclure le « token software » par SMS qui pourrait être suffisant pour les clients expérimentés qui préviennent avec les précautions nécessaires, phénomènes de phishing, le clonage des cartes SIM, codes PIN, infections de logiciels malveillants, etc. Le niveau très élevé de sécurité pourrait inclure les deux solutions que j’ai décrites dans le paragraphe précédent. Ils sont plus coûteuses et adaptées aux utilisateurs peu familiarisés avec l’informatique et aux entreprises avec un profil de risque plus élevés (entreprises moyennes-grandes, organismes publics, associations importantes, etc.) qui exigent un niveau de protection majeur.
Les banques jouent un rôle actif et déterminant dans un scénario qui amènera les entreprises à se focaliser de plus en plus dans la lutte contre les cyberattaques. Les systèmes d’authentification robustes ne représentent pas la seule solution au potentiel vol des données. Mais c’est précisément l’authentification forte du client qui est autour de plusieurs débats. Je pense qu’il faut en prendre le plus grand soin et j’espère que cet article fournira des éléments de réflexion, tant pour les banques que pour leurs clients.
Enfin, tous les avis sur les sujets abordés dans ces pages, surtout s’ils sont bien constructifs, sont les bienvenus. Vous pouvez m’écrire à mon adresse e-mail écrit en bas de page.
(traduction de l'italien de Verangela Viscuso)