FR 2831362 A1 20030425 FR 0113523 A 20011019 puce d'un téléphone cellulaire. 1 2831362 PROCEDE DE TRANSACTION SECURISEE ENTRE UN TELEPHONE MOBILE EQUIPE D'UN MODULE D' IDENTIFICATION D'ABONNE (CARTE SIM) ET UN SERVEUR D'APPLICATION La présente invention concerne le domaine des transactions entre un serveur d' application et un équipement mobile, notamment un téléphone, équipé d'un module d' identification d'abonné, par exemple une carte SIM. De tels équipements permettent d'échanger des données numériques sous une forme sécurisée, par exemple sous la forme de paquet de commande selon un format défini par la norme GSM 03.48. Le but de l' invention est de proposer un procédé permettant d' assurer des échanges et transactions numériques entre un serveur d'application et un téléphone identifiés avec un haut degré de sécurité, par: - une authentification de l'utilisateur par le serveur (paiement) - une authentification du serveur par l'utilisateur (réception de commandes) une protection des droits (copyright) lors de l'exécution de MIDLET - une certification de la MIDLET par l'intermédiaire d'une signature. A cet effet, l' invention concerne selon son acception la plus générale un procédé de transaction sécurisé entre un téléphone mobile équipé d'un module d' identification d' abonné (carte SIM) et un serveur d' application, caractérisé en ce qu'il comporte une étape d'échange sécurisé des clés publiques entre le serveur et l'abonné et d'enregistrement par l'abonné de la clé publique Ks_pub du serveur, et d'enregistrement sur le serveur de la clé publique Ku_pub de l'abonné, une étape d'achat d' applications téléchargeables 2 2831362 consistant à préparer un fichier numérique de demande sur l'équipement mobile, et à transmettre au serveur d'une part ledit fichier numérique sous forme d'un message et d'autre part de transmettre un condensat chiffré, une étape de transmission de commande par le serveur à l'abonné sous forme de fichier numérique signé et sous forme d'un condensat dudit fichier, et une étape de transmission par le serveur à l'abonné d'une application téléchargeable [MIDLET] comprenant une partie seulement codée. La présente invention sera mieux comprise à la lecture de la description d'un exemple non limitatif de réalisation, faisant référence aux dessins annexés o: - la figure 1 représente une vue générale de l' architecture du système mis en _uvre par l' invention; - la figure 2 représente une vue schématique de la transmission de la clé publique de l'abonné au serveur - la figure 3 représente une vue schématique de la transmission de la clé publique du serveur à l'abonné - La figure 4 représente une vue schématique de l'opération de paiement - La figure 5 représente une vue schématique de l'opération de réception de commandes - Les figures 6 et 7 représentent des vues schématiques des opérations de protection des droits - Les figures 8 et 9 représentent des vues schématiques des opérations de vérification de la provenance et de l'intagrité des applications chargées. L' invention met en _uvre un serveur d' application (1) comprenant un serveur de messages courts (SMS) via un réseau de télécommunication exploité par un opérateur (2). L'abonné destinataire des services fournis par le serveur d' application (2) est équipé d'un équipement mobile, par 3 2831362 exemple un téléphone mobile (3) équipé de façon connue par un module d' identification de l'abonné (4) sous forme de carte SIM. L'abonné et le serveur procèdent à un échange de leurs clés publiques respectives. Une première étape consiste à identifier l'abonné par le serveur d' application. Pour relier, de facon certaine, un nom de client à une clé publique, on transmet au serveur la clé publique calculée par la carte grâce à un SMS sécurisé. Cette-technique présente l'avantage de ne jamais faire sortir la clé publique de la carte. Si le SMS sécurisé n'est pas utilisable, on pourra utiliser des certificats de tierce partie. L'échange de clés s'effectue de manière aléatoire. La figure 2 représente une vue schématique de l'opération de génération des clés publiques et privées de l'abonné. Le module d' identification de l'abonné (4) génère une bi-clé comportant: - une clé privée Ku_priv - une clé publique Ku-pub. Cette génération de bi-clé est réalisée dans la carte SIM, et n'est pas transmise à l'environnement de la carte. La clé publique Ku_pub est transmise au serveur (1) dans le paquet de commande conforme à la norme GSM 03.48, dans le champ "DATA", sous forme de message court SMS sécurisé. Le serveur génère également un bi-clé Ks-priv, Ks_pub comme représenté en figure 3. La clé publique Ks_pub est chiffré avec la clé publique Ku_pub de l'abonné est est transmise à l'abonné sous forme de message court SMS. Le moteur d'application JAVA JAM de l'équipement mobile déchiffre le paquet de commande et enregistre sur la 4 2831362 mémoire de l'équipement mobile la clé publique Ks_pub du serveur. Le procédé comporte des opérations d'achat d' application téléchargeable [MIDLETs]. L'achat de MIDLETs doit être sécurisé. Le but est de s' assurer que c'est bien le bon client qui donne l'ordre d'acheter. On doit donc signer la demande. La demande est émise par le canal modem. En effet pour acheter des MIDLETS l'utilisateur se servira du PACKAGE MANAGER qui initialise le modem. La figure 4 représente une vue schématique de l'opération de paiement. La demande de l'abonné prend la forme d'un fichier numérique qui est transmis au serveur (1) par le canal MODEM. Parallèlement, l'équipement mobile calcule un condendat (5) [HASH] qui est transmis au serveur sous une forme chiffrée par une fonction de chiffrement F(RES, Ku_priv) avec la clé privée de l'abonné. Le serveur vérifie l'intégrité de la demande et authentifie l'émetteur de la demande par recalcul du condensat du fichier numérique recaoit sur le canal Modem et par comparaison avec le condensat déchiffré avec la clé publique Ku_publique de l'utilisateur, précédemment enregistrée. La réception de commandes est décrite en référence à la figure 5. Les commandes sont des instructions de service émises par le serveur (1) à l' intention d'un ou de plusieurs abonnées. I1 s'agit par exemple d'une commande de chargement d'une application [MIDLET] sur un équipement abonné, ou d'effacement d'un telle application. Les commandes provenant du RFS par le canal SMS doivent être signées, pour être sûr qu'une commande, 'EFFACE' par exemple, a bien été envoyée par l'opérateur. 2831362 Le serveur (l) prépare un fichier numérique correspondant à la commande et la transmet par le canal Modem ou sous forme de message court SMS à l'abonné, sous une forme signé par une fonction de signature F(Sign, Ks_pub). Il calcule par ailleurs un condensat transmis à l'abonné. La carte SIM de labonné procède à un test de validité et exéaute la commande si le test est positif. Les figures 6 et 7 représentent des vues schématiques des opérations de protection des droits. Cette opération permet d'éviter qu'une application [MIDLET] ne puisse être utilisée que par la personne qui l'a achetée. Le serveur génère une clé symétrique aléatoire lors du chargement d'un fichier. Cette clé sert à crypter certaines parties de la MIDLET. La MIDLET est ensuite envoyée avec la clé symétrique cryptée par la clé publique du client. La clé symétrique est alors décryptée dans la carte qui stocke un couple [MIDLETID, clé symétrique] A chaque demande d'utilisation d'une MIDLET le moteur d'application JAVA JAM demande à la carte de décrypter (en utilisant la clé symétrique) les morceaux codés. On ne code pas toute la MIDLET car la bande passante entre la mémoire vive du téléphone et la carte SIM est assez faible. Les figures 8 et 9 représentent des vues schématiques des opérations de vérification de la provenance et de l'intégrité des applications chargées. On doit assurer la provenance et l'intégrité de la MIDLET. La vérification de la provenance est effectuée au chargement, et la vérification de l'intégrité à chaque utilisation. Au chargement le serveur envoie la MIDLET et sa signature. 6 2831362 La carte décrypte la signature et sauvegarde le résultat de la fonction de HASH en association avec une ID de la MIDLET La carte vérifie ensuite la validité de la signature et communique le résultat à la JAM Au chargement le serveur envoie la MIDLET et sa signature. La carte décrypte la signature est sauvegarde le résultat de la fonction de HASH en association avec une ID de la MIDLET La carte vérifie ensuite la validité de la signature et communique le résultat à la JAM 7 2831362 REVENDICATIONS 1 - Procédé de transaction sécurisée entre un télophone mobile équipé d'un module d'identification d'abonné (carte SIM) et un serveur d' application, caractérisé en ce qu'il comporte une étape d'échange sécurisé des clés publiques entre le serveur et l'abonné et d'enregistrement par l'abonné de la clé publique Ks_pub du serveur, et d'enregistrement sur le serveur de la clé publique Ku_pub de l'abonné, une étape d'achat d' applications téléchargeables consistant à préparer un fichier numérique de demande sur l'équipement mobile, et à transmettre au serveur d'une part ledit fichier numérique sous forme d'un message et d'autre part de transmettre un condensat chiffré, une étape de trasmission de commande par le serveur à l'abonné sous forme de fichier numérique signé et sous forme dun condensat dudit fichier, et une étape de transmission par le serveur à l'abonné d'une application téléchargeable [MIDLET] comprenant une partie seulement codée. 2 - Procédé de transaction sécurisée selon la revendication 1, caractérisé en ce que l'étape d'échange sécurisé des clés publiques comporte une étape de génération par le module d' identification de l'abonné (4) d'une bi-clé comportant une clé privée Ku_priv et une clé publique Ku-pub et une opération de transmission de la clé publique Ku_pub au serveur (1) sous forme de message court sécurisé, et une opération de génération d'une bi-clé Ks-priv, Ks_pub, puis de transmission par le serveur à l'abonné de ladit clé publique Ks_pub chiffrée avec la clé publique Ku_pub de sous forme de message court. 3 - Procédé de transaction séaurisée selon la revendication 1 ou 2, caractérisé en ce que l'étape d'achat 8 2831362 d' application téléchargeable [MIDLETs] comporte une opération de transmission au serveur d'un fichier numérique par le canal MODEM et de calcul par l'équipement mobile émetteur de la commande d'un condendat (5) [HASH] qui est transmis au serveur sous une forme chiffrée par une fonction de chiffrement F(RES, Ku_priv) avec la clé privée de l'abonné et une opération de vérification de l'intégrité de la demande et d'authentification par l'émetteur de la demande par recalcul du condensat du fichier numérique reçoit sur le canal Modem et par comparaison avec le condensat déchiffré avec la clé publique Ku_publique de l'utilisateur, précédemment enregistrée. 4 - Procédé de transaction sécurisée selon la revendication 1, caractérisé en ce que l'étape de transmission d'une commande comporte une opération de préparation par le serveur (1) d'un fichier numérique correspondant à la commande et de transmission par le canal Modem ou sous forme de message court SMS à l'abonné, sous une forme signé par une fonction de signature F(Sign, Ks_pub) et de calcul d'un condensat transmis à l'abonné. - Procédé de transaction sécurisée selon la revendication 1, caractérisé en ce que l'étape de protection des droits consiste à générer, par le serveur, d'une clé symétrique aléatoire lors du chargement d'un fichier, ladite clé servant à crypter certaines parties de la MIDLET. 6 - Procédé de transaction sécurisée selon la revendication 5, caractérisé en ce que l 'application [MIDLET] est ensuite envoyée avec la clé symétrique cryptée par la clé publique du client, la clé symétrique étant ensuite décryptée