Brevet FR2912856A1 — publié le 20080822

SECURISATION DES TRANSACTIONS D'UN PRESTATAIRE SUR UN TELEPHONE MOBILE Problématique Il s'agit de supporter des transactions sécurisées sur 5 mobiles : - en accès à des informations (simple authentification) - en validation de transactions (non répudiation) - en protégeant la confidentialité des informations 10 échangées (chiffrement). Ces transactions concernent un prestataire différent de l'opérateur mobile, typiquement une banque. Les transactions utiliseront les différents modes d'interaction supportés et 15 notamment les messages SMS, l'USSD et le WAP. L'idée est de s'appuyer sur la sécurité mise en place par l'opérateur au travers de la carte SIM dont il est propriétaire et qui reste sous son contrôle, mais sans que le 20 prestataire ait à dépendre entièrement de l'opérateur pour la sécurité des transactions. De fait, on cherche une solution à sécurité forte reposant sur 2 facteurs complémentaires : - l'un étant de la responsabilité de l'opérateur, typiquement il s'agit de l'implication de la carte SIM dans les transactions sécurisées, autrement dit un dispositif matériel en possession de l'utilisateur - l'autre, sous responsabilité du prestataire, peut typiquement être un mot de passe connu du seul utilisateur (et du prestataire). L'objectif est de pouvoir ouvrir le service du prestataire à ses clients utilisateurs sans que ceux-ci aient à changer de SIM ou à le faire repersonnaliser et encore moins à changer de téléphone mobile. Etat de l'art préalable Le prestataire peut déléguer à l'opérateur la responsabilité de la sécurité des transactions. Mais cela n'est ni souhaitable ni même raisonnable notamment lorsque le prestataire est une banque qui offre des services de paiement et / ou de banque à distance. Le besoin de séparer les responsabilités de l'opérateur et du prestataire a parfois été pris en compte. La solution proposée alors consiste à personnaliser la carte SIM du client utilisateur en y introduisant de façon sécurisée : - d'une part, un ou des secrets de l'opérateur - et d'autre part et de façon autonome, un ou des secrets du prestataire.35 Mais de telles solutions supposent : - de compléter la personnalisation de la carte SIM après adhésion du client aux services du prestataire ou pire encore de remplacer la carte SIM par une nouvelle génération de carte SIM, ce qui n'est guère commode lorsque l'adhésion au service du prestataire n'intervient qu'après l'adhésion au service de téléphonie mobile de l'opérateur (ou l'inverse) -ou d'effectuer une post-personnalisation de la carte SIM "Over The Air" OTA, ce qui reste possible mais risque de ne pas présenter toutes les garanties de sécurité suffisantes lorsque cette post-personnalisation n'était pas prévue à l'origine, c'est à dire préalablement à la conception et à l'émission des cartes SIM de l'opérateur. A noter qu'en revanche, l'installation OTA de nouveaux services sur la carte SIM et / ou dans le téléphone mobile reste possible sans dangers excessifs lorsque l'opérateur conditionne cette installation à une vérification d'intégrité et d'origine des services à installer. En fait, une telle installation ne garantit pas la confidentialité du code et des données du ou des services installés, seules des données (typiquement des clés) introduites lors de la personnalisation initiale de la carte SIM en usine peuvent être sérieusement protégées en confidentialité et en utilisation. Présentation générale de la solution objet de la présente invention : On suppose que l'opérateur a fourni à chacun de ses utilisateurs une carte SIM comportant au moins une clé permettant l'authentification de l'utilisateur. On suppose aussi que ces cartes SIM permettent l'installation OTA de nouveaux services, ces services étant typiquement développés avec le "SIM Toolkit". On suppose enfin que l'opérateur et le prestataire, typiquement une banque ou groupe de banques, concluent un accord autorisant le prestataire à offrir de nouveaux services susceptibles de bénéficier d'une sécurité renforcée par implication de la carte SIM de l'opérateur, chaque nouveau service étant identifié par un code service attribué par l'opérateur. La commercialisation de ces nouveaux services par le prestataire se traduit par la création d'un lien chez le prestataire entre : - d'une part, un identifiant client auprès du prestataire, par exemple un identifiant de compte bancaire ou de carte bancaire - d'autre part, un identifiant client auprès de l'opérateur, typiquement un numéro de téléphonie mobile. On découvre ainsi un premier trait caractéristique de cette solution : -le prestataire peut organiser la commercialisation du nouveau service en toute autonomie - sans que l'ouverture de ces nouveaux services nécessite d'intervention non automatisable de l'opérateur, en particulier, pas besoin de changer de carte SIM ou de la post-personnaliser et encore moins besoin de faire changer au client son téléphone mobile (sauf peut-être en cas d'obsolescence excessive de la carte SIM ou du téléphone mobile). Le prestataire convient avec son client du mot de passe qui contribue en tant que second facteur à l'authentification de ce dernier auprès du prestataire à l'occasion de l'utilisation des nouveaux services commercialisés par le prestataire. Un autre trait caractéristique de cette solution est que ce mot de passe n'a pas à être connu à aucun moment d'aucune tierce partie, l'opérateur y compris. De même, le ou les secrets de la carte SIM qu'utilise l'opérateur pour la mise en oeuvre du premier facteur d'authentification n'a pas à être connu d'aucune tierce partie, le prestataire y compris. En fait, la solution est ainsi faite que le client s'authentifie auprès du prestataire au moyen d'un protocole à 20 divulgation nulle ("zero-knowledge"). Un trait caractéristique supplémentaire de cette solution est la possibilité pour le prestataire de choisir entre deux niveaux d'authentification, selon ses critères propres, en 25 principe selon la nature des transactions et des montants en jeu - un premier niveau où l'authentification repose sur le seul premier facteur qu'est l'intervention de la carte 30 SIM - un second niveau où l'authentification de premier niveau est complétée par l'utilisation du second facteur qu'est le mot de passe du client. La solution respecte ainsi un partage de responsabilités cohérent et équilibré entre le prestataire et l'opérateur : - l'intervention de la carte SIM reste entièrement sous la responsabilité de l'opérateur et la clé cachée dans la carte SIM n'est divulguée à aucune tierce partie, le prestataire y compris - le mot de passe reste au contraire entièrement sous la seule responsabilité du prestataire et il n'est divulgué à aucune tierce partie, l'opérateur y compris. Le coeur de la présente solution repose sur une "fonction de confiance" que l'opérateur devra installer dans la carte SIM ou plus généralement dans le téléphone mobile du client commun en préalable à l'accès par le client aux nouveaux services du prestataire. Cette installation se fait typiquement OTA. Cette "fonction de confiance" concourt au support des nouveaux services mais si elle n'en est qu'un élément, il s'agit d'un élément structurant en matière de sécurité des transactions. Rôle et modalités de l'établissement d'une session entre la "fonction de confiance" et le serveur du prestataire 30 Commençons par décrire comment est établi une session entre la "fonction de confiance" dans le mobile et le serveur du prestataire avant d'apporter toutes explications utiles à la compréhension de cette invention. 25 35 10 15 20 30 Mobile Opérateur Prestataire Tirage d'un aléa a Calcul de A = a chiffré / clé publique prestataire 5 Transmission demande de session 4 Demande session avec code service + A 4 Reconnaissance du client 4 ID opérateur code service 4 Prestataire Transmission demande de session enrichie 4 Demande session enrichie avec code service + ID opérateur + A 4 code service + ID opérateur 4 ID prestataire Calcul de a = A déchiffré / clé privée prestataire Tirage aléa b Calcul de k = a XOR b Transmission réponse F Réponse avec b F Calcul de B = b chiffré / clé secrète SIM Transmission réponse enrichie F Réponse enrichie avec B F Calcul de b = B déchiffré / clé secrète SIM Calcul de k = a XOR b La communication entre l'opérateur et le prestataire se fait via une liaison sécurisée; de ce fait, la réponse n'a pas autrement besoin d'être protégée en confidentialité. La "fonction de confiance" pilote l'établissement de la session et se compose de code et de données mais ne comporte aucun secret critique quant à la sécurité de cette solution. Ainsi, la clé publique prestataire est une donnée faisant partie intégrante de la "fonction de confiance" telle qu'installée par l'opérateur dans la carte SIM ou plus généralement dans le mobile. On voit aussi qu'aucune donnée personnalisée par rapport au client n'est nécessaire. La "fonction de confiance", installée par l'opérateur, doit avoir accès à une clé, typiquement une clé secrète cachée dans la SIM par l'opérateur (il pourrait aussi s'agir d'une clé privée mais cela n'est pas indispensable). Suite à l'échange décrit, la "fonction de confiance" sur le mobile et pour compte du client, et le serveur du prestataire pour le compte de ce dernier, partagent une clé de session k qui est un secret fort et dynamique. Ce secret ne pourra être connu d'aucun tiers, l'opérateur y compris. En effet, l'établissement de session se fait en divulgation nulle : même l'interception des messages émis et reçus par le mobile et leur analyse ne permettent à quiconque d'en déduire la clé de session k ou les aléas a et b ou encore les clés utilisées, à savoir d'une part, la clé privée prestataire et la clé secrète SIM. La clé de session permet ensuite de poursuivre le déroulement du nouveau service. Selon la nature du service et des montants en jeu, le prestataire peut exiger l'enrichissement de la clé de session par prise en compte du mot de passe du client. On va alors calculer, aussi bien dans la "fonction de confiance" que sur le serveur du prestataire, une clé de session de second niveau à partir de la clé de session initiale, qui est une clé de session de premier niveau, et du mot de passe du client. La clé de session de second niveau est typiquement déterminée à partir d'un HMAC calculé sur la donnée constituée par la clé de session de premier niveau et en utilisant le mot de passe comme clé pour le calcul du HMAC. Cela suppose que du côté du mobile, la "fonction de confiance" sollicite du client la saisie du mot de passe et que du côté du serveur du prestataire, celui-ci récupère d'une base de donnée le mot de passe correspondant à l'identifiant ID prestataire. A partir de là, l'utilisation de la clé de session de premier ou de second niveau, selon le choix du prestataire, permet au prestataire, selon ses besoins : - d'authentifier le client (authentification) - de vérifier l'accord du client portant sur les données caractéristiques d'une transaction (non répudiation) - d'échanger des données chiffrées avec le mobile (confidentialité). Tout ceci étant réalisé selon l'état de l'art considéré. Ainsi l'invention concerne un procédé d'authentification et/ou de validation de transactions et / ou 35 de sécurisation de données échangées entre un utilisateur et un serveur appartenant à un prestataire de services, par le biais d'un téléphone portable muni d'une carte à puce fournie par un opérateur de téléphonie mobile, et le procédé comprenant les étapes suivantes : - dans le téléphone mobile, on génère et on chiffre un nombre aléatoire, ou aléa, a, en utilisant une clé publique appartenant au prestataire de services, - on transmet l'aléa a chiffré au prestataire de services, par le biais d'une liaison sécurisée entre l'opérateur et le serveur appartenant au prestataire de services, - on déchiffre, dans le serveur, l'aléa a chiffré, en utilisant une clé privée du destinataire, pour obtenir un nombre aléatoire déchiffré adechiff - dans le serveur, on génère un nombre aléatoire b, - on calcule une première clé de session à partir des aléas adechiff et b, - on calcule une seconde clé de session par dérivation de la première clé de session et d'un mot de passe de l'utilisateur, tel que connu du prestataire, - on transmet l'aléa b à l'opérateur par le biais de la liaison sécurisée, - on chiffre l'aléa b en utilisant une clé secrète préalablement enregistrée par l'opérateur dans une mémoire de la carte à puce de l'utilisateur, - on transmet l'aléa b chiffré au téléphone mobile, - on déchiffre dans le téléphone mobile l'aléa b chiffré, en utilisant la clé secrète enregistrée dans une mémoire de la carte à puce, pour obtenir un nombre aléatoire déchiffré bdechiff, -dans le téléphone mobile, on calcule une première clé de session à partir des nombres aléatoires a et bdechiff, - on sollicite de l'utilisateur la saisie sur le téléphone mobile d'un mot de passe, - on calcule une seconde clé de session par dérivation de la première clé de session et du mot de passe, - l'utilisation sur le téléphone mobile et dans le serveur de la première ou de la seconde clé de session permet au serveur d'authentifier l'utilisateur ou de valider une transaction initiée par l'utilisateur sur le téléphone mobile ou de chiffrer toutes données échangées entre l'utilisateur et le serveur. L'invention concerne également un système comprenant tous les moyens nécessaires à la mise en oeuvre d'un procédé selon l'invention. Conclusion Les avantages, non limitatifs, de cette invention sont à l'évidence multiples : - permettre un partage de responsabilités équilibré entre l'opérateur et le prestataire et notamment compatible avec les exigences de l'exercice d'une activité de banque - permettre une désynchronisation des actions commerciales et de gestion entre l'opérateur, notamment en matière d'abonnement téléphonique et de mise à disposition et de renouvellement des cartes SIM, et du prestataire en matière de commercialisation et de gestion des nouveaux services propres à son domaine d'activité, notamment dans le domaine bancaire; en particulier, il n'y a pas besoin de remplacer ou de post-personnaliser la carte SIM d'un client de l'opérateur qui souscrit aux nouveaux services du prestataire - permettre au prestataire de choisir pour chacun de ses nouveaux services entre une sécurité forte à deux facteurs ou une sécurité élémentaire mais de force significative même si limitée à un seul facteur. Cette deuxième possibilité est particulièrement indiquée lorsque les impératifs de rapidité et d'ergonomie priment sur la sécurité (économie de temps et d'effort dans la saisie du mot de passe). Détaillons enfin ce qui fait la force de la sécurité apportée : - l'aléa b empêche toute tentative de rejeu d'une ancienne transaction -l'utilisation d'une liaison sécurisée entre l'opérateur et le prestataire garantit l'intervention effective de l'opérateur - l'utilisation de la clé secrète SIM garantit l'implication effective de la carte SIM - l'aléa a et son chiffrement par la clé publique du prestataire protègent contre les tentatives de trouver le mot de passe par tests systématiques de toutes les combinaisons possibles ou par dictionnaire, y compris par l'opérateur - dans une variante de cette invention, la "fonction de confiance" met en oeuvre une protection locale contre les "keyloggers" et autres "spywares" - finalement, on constate que la solution est capable aussi bien de résister aux attaques de type "phishing" qu'aux attaques de type "man in the middle".30 REVENDICATIONS 1. Procédé d'authentification et/ou de validation de transactions et/ou sécurisation de données échangées entre un utilisateur et un serveur appartenant à un prestataire de services, par le biais d'un téléphone portable muni d'une carte à puce fournie par un opérateur de téléphonie mobile, et le procédé comprenant les étapes suivantes : - dans le téléphone mobile, on génère et on chiffre un nombre aléatoire, ou aléa, a, en utilisant une clé publique appartenant au prestataire de services, - on transmet l'aléa a chiffré au prestataire de services, par le biais d'une liaison sécurisée entre l'opérateur et le serveur appartenant au prestataire de services, - on déchiffre, dans le serveur, l'aléa a chiffré, en utilisant une clé privée du destinataire, pour obtenir un nombre aléatoire déchiffré adechiff - dans le serveur, on génère, - on calcule une première clé de session à partir des aléas adechiff et b, - on calcule une seconde clé de session par dérivation de la première clé de session et d'un mot de passe de l'utilisateur, tel que connu du prestataire, - on transmet l'aléa b à l'opérateur par le biais de la liaison sécurisée, - on chiffre l'aléa b en utilisant une clé secrète préalablement enregistrée par l'opérateur dans une mémoire de la carte à puce de l'utilisateur, - on transmet l'aléa b chiffré au téléphone mobile, - on déchiffre dans le téléphone mobile l'aléa b chiffré, en utilisant la clé secrète enregistrée dans une mémoire de la carte à puce, pour obtenir un nombre aléatoire déchiffré bdechiff, - dans le téléphone mobile, on calcule une première clé de session à partir des nombres aléatoires a et bdechiff, - on sollicite la saisie d'un mot de passe par l'utilisateur sur le téléphone mobile, - on calcule une seconde clé de session par dérivation de la première clé de session et du mot de passe, - dans le serveur on authentifie l'utilisateur et/ou on valide une transaction initiée par l'utilisateur sur le téléphone mobile et/ou on chiffre des données échangées entre l'utilisateur et le serveur, à partir des premières et secondes clés de session utilisées dans le téléphone mobile et dans le serveur. 2. Système d'authentification et/ou de validation de transactions et/ou sécurisation de données échangées entre un utilisateur et un serveur appartenant à un prestataire de services, mettant en oeuvre un procédé conforme à la revendication 1.