Un cadre officiel pour la sécurité de Square et cie

Lentement mais sûrement, le modèle d'acceptation des paiements par carte sur un smartphone, inventé par Square et largement copié et décliné depuis, gagne sa reconnaissance par le reste du secteur. Nouvelle étape dans cette progression, le PCI SSC, l'organisme en charge des standards de sécurité, a publié ses recommandations ^[PDF] pour les développeurs.

Malgré quelques choix et orientations discutables, ce document semble marquer un véritable tournant dans la position "officielle" adoptée face aux solutions qui se sont multipliées ces derniers mois. Ainsi, dès les premières lignes, le pragmatisme est de mise : l'organisme reconnaît que des commerçants utilisent leurs propres appareils pour accepter les règlements par carte et choisit donc de diffuser ce qu'elle considère comme l'ensemble minimal de bonnes pratiques à respecter pour limiter les risques encourus avec ces systèmes.

En premier lieu, naturellement, le danger que représentent les mobiles dans l'écosystème des paiements est rappelé, mettant en avant les multiples "portes" d'accès qu'ils ouvrent (radio cellulaire, bluetooth, WiFi, NFC...) ainsi que le fait qu'ils sont utilisés pour de multiples applications, contrairement aux terminaux spécialisés. Ces deux caractéristiques sont sources de failles possibles et la première recommandation offerte est d'utiliser de préférence un dispositif externe, dont la conformité PCI a été validée, utilisant le téléphone uniquement pour transmettre les données (chiffrées dès l'origine) vers les serveurs de traitement.

Si cette solution n'est pas acceptable, il reste à passer aux "vraies" recommandations, réparties en 2 groupes : celles qui concernent directement les transactions et celles qui touchent plus généralement à l'intégrité du terminal et de l'application d'encaissement. En pratique, ces règles s'adressent principalement aux développeurs d'applications, bien que certaines soient présentées comme ciblant les fabricants de mobiles ou les fournisseurs de système d'exploitation et que d'autres puissent impliquer les commerçants ou les processeurs de paiement.

Dans le premier groupe, les préconisations visent à atteindre 3 objectifs, couvrant l'ensemble du cycle de traitement :

• Prévenir l'interception des données "à l'entrée" du mobile, ce qui implique d'authentifier le lecteur et de protéger le canal de transmission des données de la carte (par exemple par chiffrement dans le cas d'un lecteur bluetooth). Les failles logicielles classiques doivent également être évitées (une évidence !). Un interdit majeur subsiste : il est hors de question de saisir le code PIN sur le téléphone ou la tablette.

• Éviter que les données de compte puissent être compromises sur le terminal, ce qui semble, au premier abord, se traduire par des contraintes lourdes, tels que des traitements réalisés exclusivement dans un environnement d'exécution sécurisé et la protection des informations stockées temporairement (avec des exigences "extrêmes" sur les informations qui seraient stockées après autorisation de la transaction).

• Enfin, empêcher l'interception des données "sortant" du mobile, en les chiffrant, selon les standards existants (cf. PCI DSS 4), avant leur transmission depuis l'environnement d'exécution sécurisé.

Concrètement, qu'impliquent ces exigences (au demeurant légitimes, dans l'ensemble) pour les fournisseurs ? Tout d'abord, la limitation sur la saisie du code PIN va impliquer son report sur le lecteur, dont le coût sera inévitablement alourdi par l'ajout d'un clavier. Une fois de plus, ce sont donc les systèmes de paiement en mode "CNP" ("Carte Non Présente", comme une transaction en ligne, sans saisie de code) qui se voient implicitement privilégiés malgré leur insécurité.

En revanche, les exigences de chiffrement des données ne devraient pas présenter de réelles difficultés (en supposant qu'un stockage post-autorisation n'est pas nécessaire, ce qui ne me paraît pas choquant). Reste la question de "l'environnement d'exécution sécurisé", qui manque de précision et pourrait constituer un énorme point bloquant. Je préfère considérer, à ce stade, que les mécanismes d'isolation des systèmes d'exploitation modernes correspondent à la définition donnée. Dans ce cas, la seule contrainte à respecter (rappelée dans la deuxième section) est de contrôler que le système n'a pas été "débridé".

Le second groupe comprend 15 recommandations génériques dont la grande majorité est une collection de bonnes pratiques (presque élémentaires) de développement d'applications sécurisées, telles qu'elles existent aujourd'hui, notamment dans les banques. Il faut tout de même déplorer quelques formulations malheureuses, des exemples et suggestions d'implémentations parfois mal choisis et, surtout, deux ou trois règles qui sont entièrement inapplicables.

Sans entrer dans les détails, voici quelques exemples :

• Il est incongru d'évoquer un mécanisme de geofencing pour protéger le terminal dont la caractéristique principale est d'être mobile. Pourtant, utilisée à bon escient (sous le contrôle de l'utilisateur), l'idée de limiter la zone géographique d'utilisation est une bonne pratique de lutte contre la fraude.

• Recommander de détecter si le mobile a été jailbreaké ou rooté (c'est-à-dire débridé, pour simplifier), part d'un principe sain mais s'avère irréalisable, dans la réalité.

• Exiger la mise en place d'une politique de mise à jour des logiciels ou l'installation de produits d'authentification des applications est inadapté au contexte envisagé.

Au final, en dépit de ses quelques défauts et imprécisions, le guide fourni par le PCI SSC se révèle utilisable et devrait faire date dans l'histoire des dispositifs d'acceptation de règlements par carte, même si l'organisme rappelle que l'application de ses recommandations ne préjuge pas d'une autorisation d'opérer, selon les réseaux de paiement et les pays. Les solutions telles que celle de Square, dont je ne doute pas qu'elle applique déjà ces préconisations, ont désormais une existence officielle !