PSD2 : Créer un environnement d'exécution sécurisé pour les applications bancaires mobiles
La directive révisée sur les services de paiement, également connue sous le nom de PSD2, accorde beaucoup d'attention à la sécurité des applications bancaires mobiles, des applications de paiement mobile, des portefeuilles mobiles et d'autres applications qui offrent des fonctionnalités de paiement.
Les exigences les plus importantes relatives à la sécurité des applications mobiles sont présentes à l'article 9 des normes techniques réglementaires finales (RTS) sur l'authentification des clients forts (SCA) et la communication commune et sécurisée (CSC), un addenda à PSD2. Cet article exige des institutions financières (IMF), qui utilisent des appareils mobiles pour authentifier le payeur ou les transactions financières, pour « atténuer les risques résultant de la compromission de l'appareil mobile ». L'article énumère un certain nombre de mesures atténuantes que les IMF devraient adopter, y compris « l'utilisation d'environnements d'exécution sécurisés séparés » sur l'appareil mobile, ainsi que des mécanismes de détection et de défense contre les altérations de l'appareil mobile.
Ces mesures atténuantes dans le RTS final sont assez vagues. Toutefois, ils s'appliquent aux applications bancaires mobiles et autres applications avec des fonctionnalités de paiement, comme le mécanisme d'authentification de ces applications repose sur l'appareil mobile. En conséquence, les applications bancaires mobiles doivent s'exécuter à l'intérieur d'environnements d'exécution sécurisés et être protégées contre toute modification de leurs fonctionnalités.
Dans cet article, nous explorons plus en détail les exigences de sécurité des applications mobiles de PSD2 et discutons de la façon dont les banques peuvent s'assurer que leurs applications mobiles sont conformes à ces exigences.
Guide de
Une sécurité discrète pour les services bancaires mobiles
Téléchargez ce guide et apprenez à utiliser des techniques de protection superposées, à identifier et bloquer les attaques de logiciels malveillants en temps réel, à intégrer l'authentification biométrique, à fortifier la chaîne d'authentification de l'application à l'appareil et à sécuriser l'application mobile avec une sécurité invisible.
TéléchargerQu'est-ce qu'un environnement d'exécution sécurisé ?
Le RTS final stipule que les institutions financières doivent utiliser des environnements d'exécution sécurisés pour protéger les applications mobiles. Toutefois, le RTS final ne définit pas ce qu'est réellement un environnement d'exécution sécurisé, ni comment il pourrait être mis en œuvre. Le RTS ne fournit pas ce niveau de détail afin d'être à l'épreuve de l'avenir et indépendant de la technologie, qui sont des raisons qui ont du sens. Cependant, il laisse également les F, qui ont besoin de mettre en œuvre un environnement d'exécution sécurisé dans la pratique, dans l'obscurité sur ce qu'est un tel environnement d'exécution devrait ressembler. De même, il fournit des orientations limitées aux autorités nationales compétentes, qui doivent décider si l'approche d'une institution financière à l'égard de la sécurité des applications mobiles répond effectivement aux exigences du RTS final.
Essayons donc d'abord de trouver une définition utile de « l'environnement d'exécution sécurisé » (SEE). Dans le monde de l'informatique digne de confiance, un SEE est généralement défini comme un environnement de traitement protégé par l'intégrité, composé de capacités de traitement, de mémoire et de stockage. En tant que tel, le SEE est isolé de l'environnement de traitement "normal" de l'appareil mobile, et il garantit que les applications mobiles peuvent être exécutées sans interférence d'autres processus ou applications mobiles (par exemple les logiciels malveillants) résidant sur le même appareil.
Ces SEE peuvent être réalisées à l'aide d'architectures matérielles telles que ARM TrustZone ou basées sur les spécifications de GlobalPlatform's Trusted Execution Environment (TEE). Cependant, à partir d'aujourd'hui, l'adoption de telles architectures de sécurité basées sur le matériel est faible.
La bonne nouvelle, c'est que la définition de SEE dans le RTS permet clairement aux EE qui ne reposent pas sur des mécanismes de sécurité matérielle. Une première version provisoire de la RTS indiquait que « l'environnement d'exécution sécurisé » pouvait être construit à l'aide de mécanismes de sécurité uniquement logiciels, et qu'il n'avait pas à s'appuyer sur des mécanismes de sécurité basés sur le matériel. Les versions antérieures de la RTS utilisaient le libellé « environnement d'exécution de confiance » plutôt que « environnement d'exécution sécurisé », mais cela a été modifié afin de souligner que les mécanismes non matériels suffisent également.
Une définition plus pragmatique de SEE pourrait donc être la suivante: un SEE est un environnement d'exécution qui offre une protection contre les attaques connues contre les applications mobiles. Cette approche examine les attaques que les banques rencontrent sur le terrain aujourd'hui, et considère un environnement d'exécution sécurisé s'il offre une protection raisonnable contre ces attaques. En tant que tel, la définition de l'environnement d'exécution sécurisé évolue au fil du temps à mesure que le paysage des menaces pour les applications bancaires mobiles évolue.
À l'heure actuelle, les menaces les plus importantes à la sécurité bancaire mobile que nous observons sont les suivante :
- Attaques de la reïe : Malware sur l'appareil mobile affiche une fenêtre sur le dessus de l'application bancaire authentique qui ressemble étroitement à l'application bancaire. Le malware vise à capturer les informations d'identification bancaires de l'utilisateur (par exemple nom d'utilisateur, NIP). Les familles de logiciels malveillants Android courantes telles que Marcher et BankBot sont connues pour de telles attaques.
- Injection ou crochet de code : Malware tente de modifier la fonctionnalité d'une application bancaire mobile. Par exemple, l'application peut être modifiée pour enregistrer le code PIN de l'utilisateur, ou pour manipuler le bénéficiaire d'une transaction financière. Des cadres d'accrochage tels que Frida et Xposed sont librement mis à la disposition des fraudeurs pour cela.
- Keylogging: Les logiciels malveillants sur l'appareil mobile interceptent les frappes ou les gestes afin de voler des données sensibles telles que les NIP.
- Interception des SMS : Les sms sont interceptés avec des codes d'authentification à l'aide de logiciels malveillants sur le téléphone de l'utilisateur. Il s'agit d'une caractéristique populaire de nombreuses familles de logiciels malveillants mobiles Android de nos jours.
Comment créer un environnement d'exécution sécurisé
Afin de créer un environnement d’exécution sécurisé pour les applications bancaires mobiles, nous vous recommandons de les protéger à l’aide de la technologie de blindage des applications, également appelée runtime Application Self-Protection ou sécurité RASP. Cette technologie protège une application mobile contre plusieurs types de menaces de durée d'exécution. En tant que tel, il crée un environnement d'exécution sécurisé virtuel pour l'application, leur permettant d'être exécutés même sur des appareils mobiles peu fiables.
Le blindage d'applications protège les applications mobiles en utilisant une combinaison d'approches préventives, policières et réactives. Il empêche les menaces de temps d'exécution, par exemple, en obscurcissant le code pour rendre l'ingénierie inverse plus difficile. Il détecte les attaques à l'exécution, telles que les tentatives de falsification de l'application ou d'exécuter l'application à l'intérieur d'un émulateur. Enfin, il peut réagir aux attaques en cours d'exécution de différentes manières, telles que l'alerte des moteurs de risque côté serveur de la banque, ou même l'arrêt de l'application.
En savoir plus sur la façon d'identifier et de bloquer les attaques de logiciels malveillants en temps réel avec ce livre blanc:
https://www.onespan.com/solutions/invisible-mobile-banking-channel-security
Cet article, rédigé par Frederik Mennes, Senior Manager Market - Security Strategy au OneSpan Security Competence Center, est apparu pour la première fois le 06/2018 en allemand sur IT Finanzmagazin.
