Brevet FR2817108A1 — publié le 20020524

Paiements électroniques sur réseau GSM/GPRS et UMTS 1 Domaine technique d'intervention Cette application se situe dans les transactions sécurisées et notamment dans le champ d'application de la monétique. Elle concerne les applications de paiements électroniques à travers un terminal mobile de nature GSM ou de personnel assistant si celui-ci comporterait un lecteur de carte à puce. 2 Exposé du problème A partir d'une signature électronique émise par la carte SIM d'un terminal mobile GSM, il est possible d'effectuer des paiements de nature bancaire avec une excellente sécurité transactionnelle. L'objectif du concept est d'offrir une authentification destinée au grand public à travers les mobiles GSM existants en utilisant la carte SIM intégrée au terminal. La carte SIM calcule des certificats équivalents à la carte bancaire CB. Par ce biais un fournisseur de services agréé par les banques ou le back office bancaire peut faire le lien entre ce certificat et le numéro de carte bancaire du client. Deux modes de paiements peuvent être pris en compte : Paiement en tapant sur le mobile GSM son numéro de carte bancaire et sa date de validité Paiement via une signature électronique (authentification forte de l'usager) Bien que la carte SIM soit identifiée par l'opérateur télécommunications à chaque communication, cela ne suffit pas en terme de sécurité à entrer dans les nouveaux services offerts par l'Internet Mobile. Le concept de sécurité transactionnelle s'établi entre deux points, d'un côté une machine logicielle intégrée à la carte SIM permet de faire des authentifications à la volée avec plusieurs clés de signature et de l'autre un serveur de reconnaissance, calcule et compare les signatures reçues. La carte SIM intègre différentes applications avec des niveaux de sécurité adaptés à chaque service. En supplément la carte à puce peut calculer des signatures électroniques à la volée suivant des clés de longueurs variables cohabitant sur la même carte. Les services possibles : * Accès sécurisé et paiements à un bouquet de services de nature Mobile Commerce (banques à distance, ordres de bourses, réservations,...) 'Rechargement de cartes prépayées pour des services opérateurs télécommunications, Applications B to B, B to C, B to E.... Paiements bancaires sans carte bancaire * Transformation ventes à distance en ventes de proximité A notre connaissance, il n'existe pas de services de Commerce électronique ou autres, à travers le mobile utilisant ces concepts sur le marché. 3 Description des applications Eléments constitutifs de l'offre. Références numériques : . Carte SIM =11 Terminal Mobile ou poste client =12 Serveur d'information WAP du commerçant =3 Banque =9 * Bibliothèque de certification =14 Applets sur carte SIM=15 * Usager ou client final=16 . Application=17 Code Code personnel=18 # Zone mémoire du serveur de contrôle =19 # Zone mémoire de la carte SIM=20 Clé mère =21 # Clé diversifiée=22 Réseau de téléphonie mobile GSM/GPRS/UMTS=23 Canal de signalisation SMS ou données =24 3. 1 Paiements par transfert sécurisé du PAN (numéro de carte bancaire) (fig1) 3.1. 1 Description L'application de paiement est hébergée dans la carte SIM sous la forme d'une applet SIM Toolkit. Le paiement se déroule de la façon suivante : 1. Le client saisi sa commande sur le site WAP (3) du commerçant 2 Le commerçant (3) envoie son offre par SMS. 3. L'offre (2) s'affiche sur le mobile du client (12) qui la valide par saisie d'un code porteur de paiement. Ce code n'est pas le PIN de sa carte SIM (11), et pas non plus celui de sa carte CB. 4. La transaction ainsi que le numéro de carte CB du client sont signés par une clé triple DES diversifiée. Le numéro de carte peut être saisi lors de l'opération, pré-saisi lors d'une phase de configuration de l'applet (15). Ce numéro de carte est de toute façon chiffré par cette même clé et l'ensemble des éléments de la transaction (4) (données commerçant, signature et numéro de carte chiffrés) sont retournés au commerçant (3). 5. Le commerçant (3) ne dispose pas de la clé de signature et de déchiffrement du numéro de carte CB. Il ré-route l'ensemble vers une plate-forme gérée par la banque (9). 6. La banque (9), qui détient la clé maître de l'application de paiements, déchiffre le numéro de carte et contrôle la signature. Si la signature des éléments est correcte, elle peut ensuite appliquer la stratégie voulue face au risque encouru (simple contrôle du numéro de carte, contrôle de l'approvisionnement du compte, etc...) 7. La banque (9) indique au commerçant (3) son acceptation (tout était OK) ou son refus de la transaction (7) (la signature était fausse, le numéro de carte incorrect, ou les contrôles de risque refusés). 8. Le commerçant (3) signale au client (16) par une page WAP l'acceptation ou le refus (8) de sa commande. 3. 2 Paiements via une authentification forte de l'usager (fig 2) Références numériques : # Carte SIM = 11 Terminal Mobile ou poste client =12 Code porteur 13 Site ou Serveur d'information WAP du commerçant =3 Certificat =4 cas n 1 ou 4'cas n 2 # Banque (9) Bibliothèque iothèquedecertification=14 Applets sur carte SIM=15 # Usager ou client final=16 # Application=17 # Zone mémoire du serveur de contrôle = 19 # Zone mémoire de la carte SIM=20 Clé mère =21 Clé diversifiée= 22 . Réseau de téléphonie mobile GSM/GPRS/UMTS= 23 . Canal de signalisation SMS ou données =24 L'application de paiements est hébergée dans la carte SIM (11) sous la forme d'une applet SIM Toolkit (15). Le paiement se déroule de la façon suivante : 1. Le client saisi sa commande sur le site WAP du commerçant (3). 2. Le site du commerçant (3) envoie son offre par SMS (texte), accompagné de données techniques (date, aléa). 3. L'offre s'affiche sur le terminal mobile (12) du client qui la valide par saisie d'un code porteur (13) de paiement. Ce code n'est ni le code PIN de sa carte SIM, ni celui de sa carte bancaire. 4. Les éléments reçus sont signés par une clé triple DES et retoumés au commerçant (3). 5. Si le commerçant (3) dispose de la clé de contrôle du certificat reçu (4) cas non), il peut assurer la réconciliation entre le certificat contrôlé correct et un numéro de carte CB (qu'il détient dans une base de données renseignée lors d'une procédure d'enregistrement préalable). Si le commerçant (3) ne dispose pas de la clé de contrôle du certificat reçu (4) (ou s'il n'est pas autorisé à stocker des numéros CB cas n2), il peut transférer l'ensemble des éléments reçus à une plate-forme bancaire qui réalisera la réconciliation avec un numéro CB. 6. La plate-forme qui détient la clé maître de l'application de paiement (commerçant (3) pour le cas 1, ou banque (9) pour le cas no 2), contrôle le certificat (4) et opère une procédure standard de vente à distance basée sur le numéro de carte CB. 7. La plate-forme commerçant (3) (ou banque (9) via le commerçant (3)) signale au client (16) l'acceptation ou le refus de sa commande (8). La banque (9) indique au commerçant (3) son acceptation (tout était OK) ou son refus de la transaction (7), (la signature était fausse, le numéro de carte incorrect, ou les contrôles de risque refusés). L'offre produit se compose 1. d'un ensemble de logiciels (apples1 transfert du PAN et apples 2 authentification forte de l'usager), adaptée à toutes les versions de carte SIM actives du marché 2. d'un ensemble de bibliothèques de certification utilisée par un serveur du commerçant ou de la banque permettant le dialogue par SMS avec l'applet. Elles permettent : * le calcul sur le téléphone mobile de certificats dynamiques (utilisables une seule fois, donc non re-jouables), après saisie par l'usager un code porteur applicatif, * ta modification des clés par des fonctions disponibles sur le mobile (fonction Over The Air) * ta modification par l'usager de son code porteur application. 3.3 Gestion des clés (fig 3) La gestion des clés est un élément essentiel du système puisqu'elle permet le partage de l'applet entre plusieurs applications, tout en assurant l'étanchéité entre celles-ci. 3.4 Partage du système entre plusieurs applications L'applet (5) gère jusqu'à 16 clés, identifiées par leur indice (0 à 15). Chaque clé appartient à une application, et chaque application gère un code porteur spécifique, différent du CHV1 demandé lors de la mise sous tension du mobile (2). Exemple : Application 1 Code porteur 1 Clé 0 Application 2 Code porteur 2 Clé 3 Clé 4 On peut alors gérer plusieurs applications simultanément comme l'accès à un paiement à distance (Application 1) et l'accès à un Intrant sécurisé (Application 2). L'usager saisit un code porteur différent selon le service auquel il accède, mais il a toujours la possibilité d'attribuer la même valeur à ses deux codes porteurs. Une'application peut détenir deux clés au sein de la même carte SIM : la première pour gérer les certificats actuels, et la seconde en réserve pour de futurs services. Il est alors possible du jour au lendemain de faire calculer les certificats avec une autre clé. Une autre utilisation des clés multiples consiste à gérer plusieurs familles d'utilisateurs d'un même service, ceux qui ont la clé 3 ont par exemple plus de droits que ceux qui ont la clé 4. 3.5 Modification des clés Les valeurs des clés de calcul des certificats peuvent être modifiées, grâce à l'usage d'une clé spécifique, unique dans la carte, appelée clé de gestion, et qui n'est utilisée que pour cet usage. Si cette clé est présente sur le serveur (dans la bibliothèque de certification 4), il est alors possible de changer la valeur d'une clé d'indice donné. Cette clé doit donc être détenue par une entité particulière, gestionnaire du système, et garante de son bon fonctionnement. 3. 6 Typage des clés Les clés peuvent être de deux types : simple DES (56 bits) ou triple DES (112 bits). Les premières permettent des calculs plus rapides mais sont plus faibles d'un point de vue cryptographique. L'usage des secondes génère des temps de calculs légèrement supérieurs mais avec une force cryptographique supérieure. Si les clés de certification peuvent être simple DES, il est recommandé que la clé de gestion soit triple DES. 3.7 Diversification des clés Tous les usagers d'un même service ont des valeurs de clé différentes. La clé 0 de l'usager A n'est pas la même que la clé 0 de l'usager B. C'est d'ailleurs cette particularité qui permet d'être certain lors du contrôle d'un certificat correct que l'usager qui l'a renvoyé est bien le bon (si tous les usagers avaient les mêmes clés, ils renverraient tous le même certificat, ce qui permettrait difficilement de les distinguer donc de les authentifier). Les clés stockées dans les cartes SIM sont des clés diversifiées. Seule la bibliothèque de certification dispose des clés racine ou maître d'une application 3.8 Modification des codes L'usager peut modifier ses codes porteurs par l'interface du mobile, en saisissant l'ancien code, puis le nouveau. 3. 9 Evolutivité Aujourd'hui, l'applet (15) fonctionne sur le canal SMS, seul canal utilisable pour dialoguer avec une applet (15). Demain, l'usage de protocoles plus rapides (GPRS) déjà prévus par les normes GSM et prochainement intégrés aux mobiles permettront des performances d'authentification bien supérieures, sans rien remettre en cause de l'architecture de sécurité proposée. 3. 10 Intégration dans un environnement existant Le coeur de la sécurité côté serveur est la bibliothèque de certification (14). Développée en C ANSI elle peut être intégrée à n'emporte quel environnement. Elle peut être fournie sous plusieurs formes : * Fichiers sources intégrables par le client dans son système. Adaptation dans un autre environnement logiciel (DLL Windows, API Java, etc...) Avec un PC communiquant par un protocole propriétaire sur IP. Revendications Procédé de paiement électronique mettant en oeuvre des réseaux de téléphonie mobile (23) de type GSM/GPRS et UMTS ; ledit procédé étant tel que : - on calcule des signatures à la volée, lors d'une session voix ou données, en utilisant, via un canal de signalisation (14) notamment un canal SMS ou données, au moins une clé mère (21) et des clés diversifiées issues de ladite clé mère (22) ; ladite clé mère et lesdites clés diversifiés étant respectivement enregistrées : 'dans une zone mémoire (19) d'un serveur protégé (3) et 'dans une zone mémoire (20) de la carte SIM (11) d'un téléphone mobile (12) ; l'accès à ladite zone mémoire de la carte SIM (20) étant contrôlé par un code d'identification personnel (13).