Accepter des paiements avec son iPhone personnel, c’est un peu le BYOD du marchand. La chose n’est toutefois pas entièrement nouvelle : les  Apple Store facturent déjà à l’aide d’un iPhone – même s’il n’est pas personnel – et de nombreux éditeurs proposent des solutions afin de traiter des paiements sur smartphone ou d’accepter les cartes bancaires). Mais tout cela se pratiquait jusqu’à présent en dehors du cadre réglementaire de PCI-DSS. En juin 2011 le conseil PCI s’était saisi de la tendance et donné un an pour plancher sur la question.

Dont acte : le Conseil propose aujourd’hui une série de bonnes pratiques destinées aux éditeurs de ces solutions, afin de les aider à s’intégrer dans un contexte de certification PCI-DSS.

Outre toutes les vulnérabilités déjà connues sur les autres plateformes, le document reconnaît que les smartphones sont exposés à de nouveaux risques, liés essentiellement à leur plus grande connectivité (CDMA, GSM, Bluetooth, infrarouge, RFID…) et un plus grand nombre d’intervenants dans la chaîne de fabrication et de distribution où chacun (jusqu’à l’opérateur) est à même d’introduire de nouveaux logiciels ou pilotes. Dans un tel contexte, « il est compliqué de décider qui est responsable en vue de la certification PCI-DSS« , précise le document. Voilà qui commence bien !

Le Conseil PCI propose toutefois des pistes concrètes en trois points :

– A la saisie des informations de paiement. Il déconseille la saisie directe du code PIN sur le terminal et prône plutôt un clavier externe sécurisé (« PCI PTS-approved PIN entry device or EPP (encrypting PIN pad)) ». Et bien entendu le clavier (ou lecteur de carte) doit être en mesure de s’authentifier auprès de l’application de paiement sur le smartphone.

– Au sein de l’application, sur le terminal. L’exécution doit pouvoir être isolée (processus et mémoire) et le stockage des données – même temporaires – se faire dans une zone protégée. L’utilisateur ne doit pas pouvoir copier-coller, imprimer ou faire de capture d’écran des informations de paiement (ce qui, en fonction du système d’exploitation mobile peut s’avérer impossible…). Si des données de compte demeurent sur le terminal après la transaction, celles-ci doivent être rendues illisibles (PCI 3.4) ou chiffrées et les clés gérées selon PCI 3.5 (bon courage sur un terminal mobile non-contrôlé !)

– En sortie du terminal, vers la plateforme de paiement. Comme l’on peut s’y attendre, la préconisation se limite ici au chiffrement des données sortantes (PCI 4)

Si ces quelques recommandations semblent couler de source, elles présentent déjà des défis aux développeurs d’applications mobiles. Mais le PCI Council n’en reste pas là, et la suite de ses recommandations réserve d’autres surprises.

Selon le PCI-Council il sera en effet nécessaire de pouvoir contrôler l’accès au terminal et à son contenu via le chiffrement intégral du disque et la désactivation du mode de débogage USB. Mais il faudra aussi que les terminaux soient capables d’empêcher l’utilisateur de réactiver le mode débogage USB et qu’ils puissent donner l’alerte en cas de tentative de Jailbreak (une recommandation certainement destinée à empêcher le Jailbreak silencieux, à l’insu de l’utilisateur). Autant dire que le concours actifs des fabricants sera nécessaire…

Il est également conseillé de pouvoir tuer l’application à distance en cas de vol de l’appareil, et de forcer des ré-authentifications régulières de l’utilisateur afin de limiter l’impact d’une perte du terminal. Mieux : le conseil PCI prévoit d’avoir recours au géo-fencing afin de donner l’alerte si le terminal sort d’une zone géographique données (celle d’utilisation quotidienne). Avec ce dernier point, c’est la mobilité du terminal censé être mobile qui en prend un coup !

Le document conseille également sans rire l’installation d’un antivirus / antispyware sur le smartphone. Cela est certes en accord avec l’exigence PCI DSS 5.1, mais ce n’est peut-être pas tout à fait en phase avec la réalité de l’offre (ni d’ailleurs de la demande !)

Enfin, l’application de paiement sur l’appareil ne devra pas être capable de procéder à une autorisation hors-ligne si elle ne parvient pas à contacter son serveur, ce qui en situation de mobilité peut s’avérer être un problème.

En bref, dans un contexte PCI, autant l’appareil que son application de paiement seront soumis à des restrictions d’usage fortes (clavier sécurisé physique à connecter, pas de mode hors-ligne, nécessité de dépendre des fabricants pour certaines fonctionnalités, mobilité limitée par le geo-fencing…).

Il est finalement peut-être plus légitime de se demander si la norme PCI-DSS est tout simplement applicable aux terminaux mobiles personnels multi-usages grand public de type iPhone ou Android . Et d’en rester aux bons vieux terminaux spécialisés !