05/03/2013

Accepter un paiement avec un téléphone portable


Le PCI SSC vient de sortir un nouveau guide sur l'utilisation d'un téléphone portable pour accepter un paiement. 

Il s'agit donc ici d'une vision orienté "marchand". Nous sommes donc dans un scénario de paiement comme dans les magasins Apple où le client glisse sa carte dans l'iPhone du vendeur. Le guide s'adresse aux marchands qui veulent remplacer leurs TPE classiques par des téléphones portables capables de recevoir une carte bancaire.

Le guide ne couvre pas le cas où l'utilisateur (client) utilise son propre téléphone pour payer.


Le sujet est divisé en 3 volets : transaction, téléphone et application.

J'en propose ici une synthèse.


Volet "Sécurité des transactions"

  • Utiliser un clavier certifié PCI PTS (si le code PIN est demandé), ne pas saisir le PIN sur le clavier du téléphone.
  • Utiliser un lecteur de carte agréé (si le lecteur est pluggé sur le téléphone, façon Apple Store).
  • Protéger le téléphone contre le vol (antivol, le ranger lorsqu'il n'est pas utilisé).
  • Chiffrer les communications entre le téléphone et les réseaux (ex: SSL).
  • Sécuriser l'éventuel réseau WiFi du magasin si le téléphone l'utilise (pas de mot de passe par défaut, chiffrement WPA2...)

Volet "Sécurité du téléphone lui-même"

  • Utiliser des téléphones dédiés (par ceux des employés, pas de BYOD).
  • Forcer l'utilisation d'un mot de passe sur le téléphone.
  • Activer le chiffrement intégral du téléphone (contre le bypass par le câble de synchro).
  • Installer un logiciel anti-malware.
  • Empêcher l'utilisation des markets alternatifs (source de malware pour mobiles, surtout sur Android).
  • Interdire et détecter le "root" (Android) et le JailBreak (Iphone).
  • Ne pas installer des logiciels inutiles à l'activité commerçante.
  • Demander à l'éditeur de fournir des alertes et des mises à jour de sécurité (OS et application).
  • Utiliser un logiciel d'analyse de la sécurité sur le téléphone (vérification des permissions sur les applications, mots de passe, etc). L'éditeur du logiciel de paiement doit implémenter une fonction d'analyse de la sécurité et qui donne un indicateur (un "voyant") à l'utilisateur pour lui dire si le téléphone peut être utilisé de façon sécurisée.
  • Désactiver les fonctions de communications inutiles à l'activité (Bluetooth, IR, RFID, Airplay, Wifi, 3G..)
  • Noter dans un cahier les vendeurs qui utilisent l'appareil (date, heure, nom).
  • Avoir un inventaire et étiqueter les téléphones avec un système fiable (tag ultra-violet ou RFID par exemple)
  • Détecter le vol ou la perte, avec par exemple le GPS intégré. 
  • Implémenter une fonction de désactivation et d'effacement à distance du téléphone (en cas de perte et vol).

Voler "Sécurité de l'application de paiement"


  • S'assurer que la partie hébergée de la solution de paiement est hébergée dans un environnement certifié conforme au PCI DSS par un auditeur QSA.
  • S'assurer que le fournisseur de paiement (le PSP) derrière la solution de paiement mobile soit certifié PCI DSS.
  • Réaliser des autorisations "online" (directement, sans délai), par opposition à des autorisations offline.
  • S'assurer que la solution permet une traçabilité des opérations réalisées.
  • S'assurer que le PAN est tronqué dans toutes les formes de tickets (papiers, emails, SMS...)

Conclusion


Finalement, pas d'exigences incroyables. Il faut s'assurer que la solution repose sur des tiers certifiés PCI DSS, que les risques de malware/backdoor sur les téléphones soient pris en comptes, que le réseau soit chiffré. 

On sent tout de même la création d'un besoin de "scanner de sécurité pour le téléphone". Il faut que l'application de paiement détecte l'éventuelle compromission du téléphone et l'indique à l'utilisateur ! J'aurai aimé une checklist précise ici, le PCI SSC laisse l'éditeur faire sa propre checklist de contrôle de sécurité du téléphone.

Je regrette aussi l'absence de recommandations sur le protocole entre le téléphone et le PSP (Web Services authentifiés, certificat client..), l'absence de règles sur l'utilisation des fichiers locaux du téléphone, le flou sur la signature des binaires ou sur les permissions à appliquer sur les ressources systèmes...



Aucun commentaire:

Enregistrer un commentaire