FR2888437A1 - Procede et systeme de controle d'acces a un service d'un fournisseur d'acces implemente sur un serveur multimedia, module, serveur, terminal et programmes pour ce systeme - Google Patents

Abstract

Ce procédé de contrôle d'accès à un service d'un fournisseur de services implémenté sur un serveur multimédia comporte :- avant même qu'un utilisateur ait choisi un service qu'il souhaite utiliser, une étape (100) de téléchargement dans un terminal multimédia de jetons de validation signés dont au moins un est utilisable par ce terminal multimédia pour valider l'accès au service choisi, et- une étape (108) lors de laquelle le terminal multimédia choisit le ou les jetons de validation à envoyer dans une requête de validation en fonction de renseignements acquis sur le service choisi, parmi l'ensemble des jetons de validation téléchargés.

Description

La présente invention concerne un procédé et un système de contrôle

d'accès à un service d'un fournisseur d'accès implémenté sur un serveur multimédia. L'invention concerne également un module de validation, un serveur, un terminal multimédia et des programmes d'ordinateur pour ce

procédé et ce système.

Ici, le terme service désigne un ensemble de tâches ou de fonctions réalisées par un serveur multimédia. Typiquement, un service correspond à des fonctionnalités du serveur multimédia qui sont uniquement accessibles après autorisation par un tiers de confiance, ici un serveur de validation. Ces fonctionnalités sont, par exemple, le déclenchement de la livraison d'informations sur le terminal multimédia de l'utilisateur ou de la livraison d'un produit chez l'utilisateur du terminal multimédia.

Il existe des procédés de contrôle d'accès dans lesquels le terminal multimédia est raccordé au serveur multimédia par un réseau grande distance de transmission d'informations et dans lesquels le contrôle d'accès s'effectue à l'aide d'un serveur de validation indépendant du serveur multimédia. Le serveur de validation est raccordé au terminal multimédia par l'intermédiaire du réseau grande distance de transmission d'informations.

Ces procédés existants comportent, par exemple, les étapes suivantes: 20 a) une étape d'acquisition par le terminal multimédia de renseignements sur le service choisi par l'utilisateur, b) une fois ces renseignements acquis, une étape d'émission d'une requête de validation de l'accès à ce service vers le serveur de validation, cette requête contenant au moins un jeton de validation de l'accès à ce service, ce ou ces jetons étant signés à l'aide d'une clé cryptographique secrète unique propre à un utilisateur du terminal multimédia ou au fournisseur de services, c) une étape de vérification par le serveur de validation de l'authenticité du ou de chaque jeton de validation contenu dans la requête à l'aide de la signature de chacun de ces jetons, d) si l'authenticité du ou de chaque jeton est établie, une étape d'envoi par le serveur de validation d'une réponse à la requête de validation contenant un accord ou un refus de validation déterminé en fonction du ou des jetons de validation envoyés lors de l'étape b), e) une étape de réception par le terminal multimédia de cette réponse, et f) un étape (144) d'autorisation de l'accès à ce service, si cette réponse contient un accord ou au contraire une étape (142) d'interdiction de l'accès à ce service, si la réponse contient un refus.

Dans ces procédés existants, les jetons de validation sont: 1) soit construits à l'intérieur du terminal multimédia en fonction des renseignements acquis lors de l'étape a) ; 2) soit construits par le serveur multimédia puis envoyés après l'étape a) au terminal multimédia, par exemple en réponse à une demande de service du terminal multimédia au serveur multimédia effectuée entre les étapes a) et b), en fonction des renseignements acquis.

Dans le cas 1), cela suppose que le terminal multimédia soit équipé de fonctions cryptographiques pour signer les jetons. De plus, l'exécution de ces fonctions cryptographiques sur le terminal multimédia ralentit le procédé de contrôle d'accès au service.

Dans le cas 2), les jetons construits par le serveur multimédia doivent être envoyés vers le terminal multimédia après l'étape a), puis, le terminal multimédia les renvoie au serveur de validation. Cette façon de procéder ralentit également le procédé de contrôle d'accès au service.

L'invention vise à remédier à cet inconvénient en proposant un procédé de contrôle d'accès à un service plus rapide.

L'invention a donc pour objet un contrôle d'accès à un service dans lequel: - avant l'étape a), et avant même que l'utilisateur ait choisi le service qu'il souhaite utiliser, le procédé comporte une étape g) de téléchargement dans le terminal multimédia de jetons de validation signés dont au moins un est utilisable par ce terminal multimédia pour valider l'accès au service choisi, et - entre les étapes a) et b) le procédé comporte une étape h) lors de laquelle le terminal multimédia choisit le ou les jetons de validation à envoyer dans la requête de validation en fonction des renseignements acquis sur le service choisi, parmi l'ensemble des jetons de validation téléchargés lors de l'étape g).

Dans le procédé ci-dessus, au moment où l'accès au service doit être validé, le ou les jetons de validation correspondant à ce service sont déjà dans le terminal multimédia et peuvent donc être envoyés immédiatement au serveur de validation. Il n'est donc plus nécessaire d'attendre que ces jetons soient construits par le terminal multimédia ou encore d'attendre que ces jetons soient transmis par le serveur multimédia au terminal multimédia. Ce procédé permet donc une validation plus rapide de l'accès à un service choisi par l'utilisateur du terminal multimédia.

Les modes de réalisation de ce procédé peuvent comporter la caractéristique suivante: si l'authenticité du ou des jetons est établie, le procédé comporte entre les étapes c) et d) une étape de présentation à l'utilisateur d'informations sur le service choisi, ces informations étant extraites des renseignements acquis lors de l'étape a) et/ou des renseignements compris dans le ou les jetons de validation envoyés lors de l'étape b), puis en réponse, une étape de réception par le serveur de validation d'une autorisation, donnée par l'utilisateur, de poursuivre à l'étape d), et le serveur de validation procède à l'étape d) uniquement si cette autorisation est reçue.

Ces modes de réalisation du procédé de contrôle d'accès présentent en outre les avantages suivants: - avec l'utilisation de jetons de validation comme messages précalculés d'un protocole de contrôle d'accès existant, le procédé permet de simplifier ce protocole existant sans modifier le serveur de validation; - la présentation à l'utilisateur des renseignements contenus dans les jetons permet à l'utilisateur de vérifier les renseignements sur la base desquels l'accès au service va être contrôlé ; et - l'acquisition d'une autorisation donnée par l'utilisateur à poursuivre permet à l'utilisateur d'interrompre le procédé si les renseignements sur la base desquels le contrôle d'accès va être effectué sont erronés.

L'invention a également pour objet un système de contrôle d'accès à un service d'un fournisseur de services implémenté sur un serveur multimédia, à partir d'un terminal multimédia distant raccordé au serveur multimédia par l'intermédiaire d'au moins un réseau grande distance de transmission d'informations, le système comportant: - un module de validation apte à s'exécuter sur le terminal multimédia pour acquérir des renseignements sur le service choisi par l'utilisateur, et une fois ces renseignements acquis, pour émettre une requête de validation de l'accès à ce service vers un serveur de validation, cette requête contenant au moins un jeton de validation de l'accès au service choisi, ce ou ces jetons étant signés à l'aide d'une clé cryptographique secrète unique propre à l'utilisateur du terminal multimédia ou au fournisseur de services, - le serveur de validation raccordé au terminal multimédia par l'intermédiaire du réseau grande distance et indépendant du serveur multimédia, ce serveur de validation étant apte à vérifier l'authenticité du ou de chaque jeton de validation contenu dans la requête de validation à l'aide de la signature de chacun des jetons et, si l'authenticité du ou de chaque jeton est établie, à envoyer une réponse à la requête de validation contenant un accord ou un refus de validation déterminé en fonction du ou des jetons de validation envoyés par le module de validation, - une application multimédia apte à s'exécuter sur le terminal multimédia, cette application étant apte à recevoir la réponse et à autoriser l'accès au service choisi si la réponse contient un accord ou au contraire à interdire l'accès au service choisi si la réponse contient un refus, dans lequel le module de validation comporte, avant même que l'utilisateur n'ait choisi un service qu'il souhaite utiliser, un ensemble de jetons de validation téléchargés dont au moins un est utilisable par ce module pour valider l'accès au service choisi, et le module de validation est apte à choisir le ou les jetons de validation à envoyer dans la requête de validation en fonction des renseignements acquis sur le service choisi, parmi l'ensemble des jetons de validation téléchargés.

Les modes de réalisation de ce système de contrôle d'accès peuvent comporter une ou plusieurs des caractéristiques suivantes: - le module de validation est apte à présenter à l'utilisateur du terminal multimédia des informations sur le service choisi, ces informations étant extraites des renseignements acquis et/ou des renseignements compris dans le ou les jetons de validation envoyés au serveur de validation, et à acquérir en réponse une autorisation, donnée par l'utilisateur, de poursuivre le contrôle d'accès, et le serveur de validation est uniquement apte à poursuivre le contrôle d'accès si l'autorisation de poursuivre acquise par le module de validation est reçue; - une passerelle raccordée au réseau grande distance de transmission d'informations apte à insérer automatiquement un alias correspondant à un identifiant du terminal multimédia sur le réseau grande distance dans tout message échangé entre le terminal multimédia et le serveur multimédia sur lequel est implémenté le fournisseur de services et/ou dans tout message échangé entre le terminal multimédia et le serveur de validation; - le ou chaque jeton de validation est invariant en fonction du service choisi et le module de validation est apte à faire varier le nombre de jetons de validation contenus dans la requête de validation en fonction des renseignements acquis sur le service choisi; - le ou chaque jeton contient au moins un identifiant choisi dans le groupe composé d'un identifiant de service, d'un identifiant de fournisseur de services, d'un identifiant d'utilisateur, et d'un identifiant d'application multimédia, et le module de validation est apte à choisir le ou les jetons de validation à utiliser en fonction d'au moins l'un de ces identifiants; - l'application multimédia est apte à présenter plusieurs services différents susceptibles d'être choisis par l'utilisateur; - l'application multimédia et le module de validation sont des modules logiciels indépendants l'un de l'autre aptes à communiquer l'un avec l'autre par l'intermédiaire d'une interface API ( Application Program Interface ) standardisée.

Ces modes de réalisation du système de contrôle d'accès présentent en outre les avantages suivants: - le remplacement d'un identifiant du terminal multimédia sur le réseau grande distance par un alias permet de conserver l'anonymat de l'utilisateur du terminal multimédia, l'utilisation de jetons de validation invariant en fonction du service choisi, permet de créer des jetons standards aptes à permettre la validation d'un service quelconque, en faisant simplement varier leur nombre; - l'utilisation de jetons contenant un identifiant du fournisseur de services, un identifiant d'application multimédia, un identifiant de service ou un identifiant d'utilisateur, permet de limiter l'usage de ces jetons respectivement à un fournisseur de services particulier, à une application multimédia particulière, à un service particulier ou à un utilisateur particulier; - le fait que l'application multimédia et le module de validation soient des modules logiciels indépendants l'un de l'autre permet que le module de validation soit conçu et réalisé par une entité indépendante du serveur multimédia et de l'utilisateur du terminal multimédia pour assurer sa neutralité dans ce contrôle d'accès.

L'invention a également pour objet un module de validation, un serveur, un terminal multimédia et des programmes d'ordinateurs aptes à être utilisés dans le procédé ou le système de contrôle d'accès ci-dessus.

L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins sur lesquels: - la figure 1 est une illustration schématique de l'architecture d'un système de contrôle d'accès à un service; - la figure 2 est un organigramme d'un premier procédé de contrôle d'accès mis en oeuvre dans le système de la figure 1; et - la figure 3 est un organigramme d'un second procédé de contrôle d'accès mis en oeuvre dans le système de la figure 1.

La figure 1 représente un système 2 de contrôle d'accès à un service d'un fournisseur de services implémenté sur un serveur multimédia 4 à partir de terminaux multimédias.

Pour simplifier la figure 1, seul un terminal multimédia 6 est représenté.

Les autres terminaux multimédias sont aptes à mettre en oeuvre les mêmes fonctionnalités que celles qui sont décrites pour ce terminal 6.

Le terminal 6 est un téléphone mobile, par exemple.

Le terminal 6 est raccordé au serveur 4 par l'intermédiaire d'un réseau grande distance 8 de téléphonie mobile et de la toile d'araignée mondiale 10 appelée ici réseau Internet. Les réseaux 8 et 10 sont interconnectés l'un à l'autre par l'intermédiaire d'une passerelle 12.

Le serveur 4 est un fournisseur de services, par exemple, apte à rendre un service de consultation de météo marine. A cet effet, il est raccordé à une mémoire 20 contenant une application multimédia 22 propre à être téléchargée sur le terminal 6 et à s'exécuter sur ce terminal. Cette application 22 est apte: - à présenter une carte géographique des différentes régions maritimes dont la météo est consultable, et - à déclencher automatiquement le téléchargement d'un module de validation à partir d'un serveur de validation 26.

A cet effet, l'application 22 comporte l'adresse Internet ou adresse IP (Internet Protocol) du serveur 26, ainsi qu'un identifiant AMM-ID de l'application 22 et un identifiant M-ID du fournisseur de services implémenté sur le serveur 4.

Le serveur 4 est un serveur informatique apte à exécuter un programme d'ordinateur comprenant des instructions pour la mise en oeuvre du procédé de la figure 2 ou 3. Le programme d'ordinateur est, par exemple, enregistré dans la mémoire 20.

Le terminal 6 est apte à échanger des informations par l'intermédiaire du réseau 8. Pour cela, il est notamment équipé d'une carte SIM (Subscriber Identity Module) 32 contenant notamment un numéro de téléphone du terminal 6 sur le réseau 8.

Le terminal 6 est également apte à télécharger l'application 22 à partir du serveur 4 et à exécuter celle-ci. A cet effet, il comprend un microprocesseur 34 et une interface homme/machine 36 formée, ici, d'un écran 38 et d'un clavier 40.

La copie ou l'instance de l'application 22 exécutée sur le terminal 6 porte la référence 42.

Comme représenté schématiquement sur la figure 1, lorsque l'un des procédés de contrôle d'accès des figures 2 et 3 est exécuté, le terminal 6 comprend l'application 42 et un module 44 de validation téléchargé à partir du serveur 26. Le module 44 est équipé d'une interface API (Application Program Interface) 46 standardisée permettant à l'application 42 et au module 44 de communiquer l'un avec l'autre.

Le module de validation 44 comprend des jetons 48 de validation signés à l'aide d'une clé cryptographique secrète C-Ks associée à l'identifiant CID d'un utilisateur du terminal 6. L'identifiant C-ID du terminal 6 est, par exemple, le numéro de téléphone enregistré dans la carte SIM 32.

Ici, chaque jeton 48 contient en plus de la signature, un identifiant d'application multimédia AMM-ID, un identifiant de fournisseur de services M-ID et un identifiant de service P-ID. Cet identifiant de service est à comprendre au sens large et peut contenir toute information utile, et en particulier une description du service intelligible pour un esprit humain.

Le terminal 6 est ici réalisé à partir de calculateurs programmables conventionnels aptes à exécuter des programmes d'ordinateur comportant des instructions de code pour la mise en oeuvre du procédé de la figure 2 ou 3. Le programme d'ordinateur est, par exemple, enregistré dans une mémoire 49.

Dans ce mode de réalisation, le serveur 26 remplit à la fois la fonction de serveur de validation propre à authentifier un jeton puis à autoriser ou à refuser un accès à un service du fournisseur de services et la fonction de synthétiseur de module de validation et de jetons téléchargeables sur le terminal 6.

Pour la première de ces fonctions, le serveur 26 comporte un module 50 de vérification de signature et une base de données 52 associant à chaque identifiant C-ID une clé cryptographique secrète unique C-Ks permettant de vérifier la signature des jetons 48.

Pour la seconde de ces fonctions, le serveur 26 comprend un synthétiseur 54 de module de validation et de jetons. A cet effet, le module 54 est associé à un catalogue 56 contenant les identifiants P-ID de chaque service accessible auprès du fournisseur de services dont l'identifiant est M-ID et en utilisant l'application multimédia dont l'identifiant est AMM-ID. Un prix du service est également associé à chaque identifiant PID dans le catalogue. Le synthétiseur 54 utilise la base de données 52 pour la signature des jetons créés.

La base de données 52 et le catalogue 56 sont enregistrés dans une mémoire 58 raccordée au serveur 26.

La mémoire 58 contient également un code 60 de module de validation permettant de construire un module de validation contenant des jetons.

Le code 60 est, par exemple, écrit dans le langage de programmation Java 8 et permet de traiter les échanges de données entre le module 44 et le serveur 26.

Le serveur 26 est un serveur informatique apte à exécuter un programme d'ordinateur comprenant des instructions pour la mise en oeuvre du procédé de la figure 2 ou 3. Le programme d'ordinateur est, par exemple, enregistré dans la mémoire 58.

L'interface API du module 44 comporte notamment une routine PAY standardisée susceptible d'être appelée par toute application multimédia, et donc notamment par l'application 42. La routine PAY est une routine paramétrable à l'aide de quatre identifiants et d'un prix et permet à une application multimédia de communiquer ces paramètres au module 44 pour déclencher l'envoi d'une requête de validation vers le serveur 26.

Les différentes fonctionnalités de l'application 42 et du module 44 sont décrites plus en détail en regard du procédé de la figure 2.

Enfin, la passerelle 12 est équipée d'un module 70 d'ajout de l'identifiant C-ID dans chaque message transmis par le terminal 6 à destination du serveur 26 et d'un module 72 d'insertion d'un alias de l'identifiant C-ID dans chaque message transmis du terminal 6 vers le serveur 4 pour préserver l'anonymat du terminal6.

Le fonctionnement du système 2 va maintenant être décrit en regard du procédé de la figure 2.

Lorsqu'un utilisateur souhaite consulter la météo marine d'une région, il se connecte, lors d'une étape 90, à l'aide du terminal 6 au serveur 4 et télécharge, lors de cette étape, une instance de l'application 22 référencée ici sous le numéro 42.

Le microprocesseur 34 exécute alors, lors d'une étape 92, l'application 42.

Avant même que l'application 42 commence à présenter les différents services accessibles auprès du fournisseur de services implémenté sur le serveur 4, celle-ci déclenche automatiquement, lors d'une étape 94, le téléchargement du module 44. A cet effet, lors de l'étape 94, un message de téléchargement du module 44 est envoyé au serveur 26. Ce message contient, par exemple, l'identifiant AMM-ID de l'application 22 et l'identifiant M-ID du fournisseur de services.

Lorsque ce message traverse la passerelle 12, le module 70 détecte que ce message est destiné au serveur 26, par exemple à l'aide de l'adresse IP du serveur 26 contenu dans ce message, et ajoute automatiquement à ce message l'identifiant C-ID du terminal 6, lors d'une étape 96.

En réponse à ce message de téléchargement, lors d'une étape 98, le serveur 26 construit les jetons de validation destinés au terminal 6 en utilisant le catalogue 56 et la base de données 52. Plus précisément, lors de cette étape 98, pour chaque identifiant de service P-ID associé dans le catalogue 56 aux identifiants M-ID et AMM-ID correspondant à ceux reçus dans le message de téléchargement, le serveur 26 construit un jeton contenant l'identifiant C-ID, l'identifiant P-ID, le prix de ce service, et les identifiants M-ID et AMM-ID. Ces renseignements sont signés avec la clé C-Ks de l'utilisateur extraite de la base de données 52.

Ensuite, lors d'une étape 100, le terminal 6 télécharge le module 44 contenant les jetons 48 construits lors de l'étape 98 à partir du serveur 26.

L'application 42 commence alors à interagir, lors d'une étape 102, avec l'utilisateur par le biais de l'interface 36 et présente notamment à ce dernier une liste de plusieurs services payants. Par exemple, ici, l'application 42 présente une carte de différentes régions maritimes, chaque région comportant un lien pour activer le téléchargement de la météo maritime correspondant à cette région.

Lors d'une étape 104, l'utilisateur choisit l'un de ces services payants. Le module 44 acquiert alors, lors d'une étape 106, des renseignements sur le service payant choisi par l'utilisateur. Les renseignements comportent les identifiants C-ID, M-ID, AMM-ID, l'identifiant P-ID du service choisi et le prix du service choisi. Par exemple, lors de l'étape 106, l'application 42 appelle la routine PAY paramétrée avec les identifiants cités ci-dessus et le prix du service de manière à transmettre ces renseignements au module 44.

Ensuite, le module 44 choisit, lors d'une étape 108, parmi l'ensemble des jetons téléchargés 48 lors de l'étape 100, ceux à envoyer au serveur 26 pour valider l'accès au service payant choisi. Par exemple, ici, le module 44 choisit uniquement un jeton contenant les mêmes identifiants et le même prix que ceux acquis lors de l'étape 106. Ceci permet de limiter l'utilisation d'un jeton à un service particulier ayant un prix donné fourni par un fournisseur de services particulier en utilisant une application multimédia particulière et pour un utilisateur donné.

Si aucun jeton ne correspond aux renseignements acquis lors de l'étape 106, l'accès au service est, par exemple, directement refusé lors d'une étape 110.

Dans le cas contraire, le module 44 envoie, lors d'une étape 112, au serveur 26 une requête de validation contenant le jeton choisi lors de l'étape 108. Cette requête est, par exemple, une requête HTTP (Hyper Text Transfer Protocol). Cette requête est transmise à la passerelle 12 qui ajoute, lors d'une étape 114, l'identifiant C-ID à cette requête.

Le serveur 26 reçoit la requête de validation et le module 50 vérifie, lors d'une étape 116, l'authenticité du jeton de validation qu'elle contient à l'aide de la signature de ce jeton.

Dans le cas où ce jeton n'a pas été signé avec la clé C-Ks correspondant à l'identifiant C-ID ou si l'un des identifiants ou le prix a été falsifié alors le procédé s'interrompt lors d'une étape 118 et l'accès au service payant est refusé.

Dans le cas contraire, le serveur 26 envoie au module 44, lors d'une étape 120, une demande d'autorisation client contenant le prix et l'identifiant P- ID extraits du jeton authentifié.

Le module 44 reçoit, lors d'une étape 122, cette demande d'autorisation client et présente à l'utilisateur, lors d'une étape 124, les informations contenues dans la demande d'autorisation client, par exemple, par le biais de l'interface 36. Typiquement, l'étape de présentation 124 consiste ici à afficher sur l'écran 38 le prix et l'identifiant P-ID extraits du jeton authentifié ainsi que des touches valider et annuler . Comme il a été dit plus haut, l'identifiant P-ID affiché peut en particulier contenir une description du produit intelligible pour un esprit humain.

Si l'utilisateur active la touche annuler le procédé s'interrompt lors d'une étape 126.

Si le prix et l'identifiant P-ID présentés lors de l'étape 124 correspondent à ceux attendus, alors l'utilisateur confirme qu'il souhaite accéder au service ainsi identifié et au prix ainsi indiqué en activant la touche valider . Le module 44 2888437 12 acquiert alors, lors d'une étape 130, une autorisation de l'utilisateur à poursuivre, correspondant à l'activation de la touche valider et transmet cette autorisation au serveur 26.

Lorsque le serveur 26 reçoit cette autorisation, il détermine, lors d'une étape 132, si l'accès au service choisi doit être accordé ou refusé en appliquant des règles prédéterminées. Par exemple, l'accès au service est uniquement autorisé si l'identifiant C-ID de l'utilisateur est associé à un compte bancaire créditeur sur lequel peut être débité le prix du service choisi. Toutefois, tout autre type de règles est applicable.

Ensuite, le serveur 26 envoie, lors d'une étape 134, une réponse au module 44 contenant un accord ou un refus d'accès au service choisi.

Lors d'une étape 136, le module 44 reçoit cette réponse et la transmet à l'application 42 par l'intermédiaire de l'interface API 46.

L'application 42 reçoit cette réponse, lors d'une étape 140, et refuse, lors d'une étape 142, l'accès au service choisi si la réponse contient un refus. Dans le cas contraire, lors d'une étape 144, l'application 42 autorise l'accès au service choisi et envoie, lors d'une étape 146, au serveur 4 une demande de livraison du service choisi.

La passerelle 12 intercepte cette demande de livraison et insère un alias de l'identifiant C-ID, lors d'une étape 148, avant de retransmettre cette demande de livraison au serveur 4.

Le serveur 4 traite, lors d'une étape 150, cette demande de livraison et communique directement avec l'application 42 par l'intermédiaire de la passerelle 12. Lors de l'étape 150, le serveur 4 reçoit uniquement les alias pour identifier l'utilisateur du terminal 6, de sorte que l'anonymat de l'utilisateur est préservé.

La figure 3 représente un second procédé de contrôle d'accès susceptible d'être mis en oeuvre dans le système 2 à la place ou en plus du procédé de la figure 2. Ce procédé de la figure 3 diffère de celui de la figure 2 uniquement par le fait que le jeton de validation contient uniquement un prix signé à l'aide de la clé secrète C-Ks. Ce jeton est donc le même quel que soit l'identifiant de produit P-ID, quel que soit l'identifiant de fournisseur de service M-ID et quel que soit l'identifiant d'application multimédia AMM-ID, de sorte qu'il est utilisable pour valider l'accès à un service quelconque fourni par un fournisseur de services quelconque utilisant une application multimédia quelconque. Dans ce mode de fonctionnement, chaque jeton présente des similarités avec une pièce de monnaie.

Seules les différences par rapport au procédé de la figure 2 sont décrites ici.

L'étape 98 est remplacée par une étape 160 de construction de jetons contenant uniquement un prix, par exemple, 2 euros et signés avec les clés C-Ks correspondants à l'identifiant C-ID, des jetons différents pouvant évidemment contenir des prix différents.

L'étape 106 est remplacée par une étape 162, lors de laquelle le seul renseignement acquis par le module 44 est le prix du service choisi par l'utilisateur. L'étape 108 est remplacée par une étape 164, lors de laquelle le module 44

choisit automatiquement un nombre de jetons téléchargés pour que le cumul des prix contenus dans ces jetons choisis corresponde au prix acquis lors de l'étape 162. La requête de validation envoyée lors de l'étape 112 contient donc un à plusieurs jetons.

Lors de l'étape 120, le prix transmis dans la demande d'autorisation client correspond au cumul des prix individuels extraits de chacun des jetons authentifiés.

Les autres étapes du procédé sont inchangées.

De nombreux autres modes de réalisation du système 2 sont possibles. Par exemple, en variante, le terminal 6 est remplacé par un ordinateur de bureau fixe raccordé au réseau 10 par l'intermédiaire d'un fournisseur d'accès Internet. Dans cette variante, le fournisseur d'accès Internet joue le rôle de la passerelle 12 et comporte donc les modules 70 et 72.

Ici, le module 44 a été décrit comme étant uniquement utilisable avec l'application 42. En variante, le module 44 est commun à plusieurs applications multimédia différentes exécutées en parallèle ou successivement sur le terminal 6.

Il a été dit également que l'instance 42 de l'application 22 est téléchargée lorsque l'utilisateur se connecte lors de l'étape 90 au serveur multimédia 4. En variante, l'application peut être déjà présente sur le terminal 6, soit qu'elle ait été téléchargée lors d'une connexion précédente, soit qu'elle ait été installée auparavant sur le terminal 6, par l'utilisateur ou avant la vente de ce terminal à l'utilisateur.

En variante, l'application multimédia présente sur le terminal multimédia demande le téléchargement du module de validation à un moment quelconque de son fonctionnement.

Dans le procédé de contrôle d'accès de la figure 2, à l'exception du prix et/ou de l'identifiant P-ID, tous les autres paramètres du jeton de validation sont facultatifs. Les paramètres facultatifs sont supprimés en fonction du niveau de sécurité souhaité pour l'utilisation de chaque jeton.

La demande d'autorisation client a été décrite comme envoyée par le serveur de validation 26, lors de l'étape 120, puis transmise à l'utilisateur par le module de validation 44, lors de l'étape 124. En variante, la demande d'autorisation client peut être présentée à l'utilisateur après l'étape 106 d'acquisition par le module de validation et avant l'étape 112. Par exemple, le procédé comporte entre les étapes 106 et 112 une étape de présentation à l'utilisateur d'informations sur le service choisi, gérée par le module de validation du terminal multimédia, ces informations étant extraites des renseignements sur le service obtenu lors de l'étape 106, puis en réponse, une étape d'acquisition par le module de validation d'une autorisation donnée par l'utilisateur de poursuivre, en procédant à l'étape 112. Le module de validation procède à l'étape 112 uniquement si une autorisation de l'utilisateur a été acquise. Les étapes 120 à 130 sont supprimées. Les étapes 132 et 134 ont donc lieu juste après les étapes 112 et 114.

Une étape 146 de demande de livraison effectuée par l'application 42 au serveur 4 a été décrite. En variante, l'accès au service accordé par l'application 42 ne nécessite pas de transfert d'informations à partir du serveur 4, parce que l'étape 144 d'autorisation de l'accès au service consiste pour l'application 42 non pas à livrer simplement une information, mais plus largement à ouvrir l'accès à une partie de ces propres fonctionnalités, indéfiniment ou pendant un intervalle de temps limité, dont la durée est déterminée par le fonctionnement interne de l'application 42, fonctionnalités qui étaient demeurées auparavant inaccessibles pour l'utilisateur, ces fonctionnalités pouvant évidemment comporter des étapes de téléchargement d'informations à partir du serveur 4.

Le terminal 6 a été décrit comme étant un téléphone mobile. En variante, il peut s'agir d'un ordinateur portable ou fixe ou encore d'un PDA (Personal Digital Assistant) raccordé à un réseau grande distance de transmission d'informations.

En variante, le synthétiseur 54 est implémenté dans la passerelle 12. Dans cette variante, la passerelle 12 est associée à une mémoire contenant le catalogue 56 et le code 60, ainsi qu'une copie de la base de données 52 pour la signature des jetons créés..

Dans le cas où l'identifiant M-ID du fournisseur de service est contenu dans le jeton alors, le jeton peut être signé à l'aide d'une clé secrète M-Ks unique propre au fournisseur de services à la place de la clé C-Ks. Dans cette variante, la base de données 52 associe à chaque identifiant MID la clé secrète M-Ks correspondante permettant d'authentifier la signature du jeton.

Les jetons peuvent également être construits directement par le fournisseur de services, lorsque ceux-ci sont signés à l'aide de la clé MKs. Dans cette variante, le serveur 4 incorpore le synthétiseur 54 et la mémoire 20 contient le catalogue 56 et le code 60, ainsi qu'une copie de la base de données 52 pour la signature des jetons créés. Lors du fonctionnement de cette variante, l'application 42 et le module 44 sont simultanément téléchargées sur le terminal 6 à partir du serveur 4.

Lorsque le terminal 6 télécharge l'application 42, il est possible de prévoir que le serveur 4 requiert auprès du serveur 26 la construction du module 44 et de jetons signés avec la clé M-Ks. Le serveur 26 transmet alors le module 44 avec ses jetons au serveur 4 par l'intermédiaire du réseau 10. Lors de la réception du module 44, le serveur 4 prépare alors un progiciel combinant l'application 42 et le module 44 qui est téléchargé dans le terminal 6.

Lorsque le module de vérification 50 du serveur de validation 26 vérifie un jeton de validation, il utilise la clé secrète C-Ks propre à l'utilisateur, respectivement la clé secrète M-Ks propre au fournisseur de services, ce qui signifie que le mécanisme cryptographique de signature utilisé est à clé partagée. En variante, le mécanisme cryptographique utilisé est un mécanisme de signature à clé publique, et le module 50 de vérification de signature du serveur de validation n'utilise plus la base de données 52, ou une copie de celle-ci, mais une base de données distincte, associant à l'identifiant C-ID la clé publique C-Kp correspondant à C-Ks, et utilise cette clé C-Kp pour la vérification de la signature produite par le module 54, respectivement associant à l'identifiant M-ID la clé publique M-Kp correspondant à M-Ks, et utilise cette clé M-Kp pour la vérification de la signature produite par le module 54.

Enfin, le système 2 a été décrit ici dans le cas particulier où seul un fournisseur de services est implémenté sur le serveur 4. En variante, plusieurs fournisseurs de services sont implémentés sur le serveur 4, de sorte que différentes applications multimédia peuvent être téléchargées à partir du même serveur. Il est également possible, en variante, que le système 2 comporte plusieurs serveurs multimédia tel que le serveur 4, de manière à augmenter le nombre de services potentiellement utilisables à partir du terminal 6.

Claims (1)

17 REVENDICATIONS

1. Procédé de contrôle d'accès à un service d'un fournisseur de services implémenté sur un serveur multimédia, à partir d'un terminal multimédia distant raccordé au serveur multimédia par l'intermédiaire d'au moins un réseau grande distance de transmission d'informations, le contrôle d'accès s'effectuant à l'aide d'un serveur de validation indépendant du serveur multimédia et également raccordé au terminal multimédia par l'intermédiaire du réseau grande distance de transmission d'informations, le procédé comportant: a) une étape (106; 162) d'acquisition par le terminal multimédia de renseignements sur le service choisi par l'utilisateur, b) une fois ces renseignements acquis, une étape (112) d'émission d'une requête de validation de l'accès à ce service vers le serveur de validation, cette requête contenant au moins un jeton de validation de l'accès à ce service, ce ou ces jetons étant signés à l'aide d'une clé cryptographique secrète unique propre à un utilisateur du terminal multimédia ou au fournisseur de services, c) une étape (116) de vérification par le serveur de validation de l'authenticité du ou de chaque jeton de validation contenu dans la requête à l'aide de la signature de chacun de ces jetons, d) si l'authenticité du ou de chaque jeton est établie, une étape (134) d'envoi par le serveur de validation d'une réponse à la requête de validation contenant un accord ou un refus de validation déterminé en fonction du ou des jetons de validation envoyés lors de l'étape b), e) une étape (140) de réception par le terminal multimédia de cette réponse, et f) un étape (144) d'autorisation de l'accès à ce service, si cette réponse contient un accord ou au contraire une étape (142) d'interdiction de l'accès à ce service, si la réponse contient un refus, caractérisé en ce que: - avant l'étape a), et avant même que l'utilisateur ait choisi le service qu'il souhaite utiliser, le procédé comporte une étape g) (100) de téléchargement dans le terminal multimédia de jetons de validation signés dont au moins un est utilisable par ce terminal multimédia pour valider l'accès au service choisi, et -entre les étapes a) et b) le procédé comporte une étape h) (108; 164) lors de laquelle le terminal multimédia choisit le ou les jetons de validation à envoyer dans la requête de validation en fonction des renseignements acquis sur le service choisi, parmi l'ensemble des jetons de validation téléchargés lors de l'étape g).

2. Procédé selon la revendication 1, caractérisé en ce que si l'authenticité du ou des jetons est établie, le procédé comporte entre les étapes c) et d) une étape (124) de présentation à l'utilisateur d'informations sur le service choisi, ces informations étant extraites des renseignements acquis lors de l'étape a) et/ou des renseignements compris dans le ou les jetons de validation envoyés lors de l'étape b), puis en réponse, une étape de réception par le serveur de validation d'une autorisation, donnée par l'utilisateur, de poursuivre à l'étape d), et en ce que le serveur de validation procède à l'étape d) uniquement si cette autorisation est reçue.

3. Système de contrôle d'accès à un service d'un fournisseur de services implémenté sur un serveur multimédia, à partir d'un terminal multimédia distant raccordé au serveur multimédia par l'intermédiaire d'au moins un réseau grande distance de transmission d'informations, le système comportant: - un module (44) de validation apte à s'exécuter sur le terminal multimédia pour acquérir des renseignements sur le service choisi par l'utilisateur, et une fois ces renseignements acquis, pour émettre une requête de validation de l'accès à ce service vers un serveur de validation, cette requête contenant au moins un jeton (48) de validation de l'accès au service choisi, ce ou ces jetons étant signés à l'aide d'une clé cryptographique secrète unique propre à l'utilisateur du terminal multimédia ou au fournisseur de services, - le serveur (26) de validation raccordé au terminal multimédia par l'intermédiaire du réseau grande distance et indépendant du serveur multimédia, ce serveur de validation étant apte à vérifier l'authenticité du ou de chaque jeton de validation contenu dans la requête de validation à l'aide de la signature de chacun des jetons et, si l'authenticité du ou de chaque jeton est établie, à envoyer une réponse à la requête de validation contenant un accord ou un refus de validation déterminé en fonction du ou des jetons de validation envoyés par le module de validation, - une application multimédia (42) apte à s'exécuter sur le terminal multimédia, cette application (42) étant apte à recevoir la réponse et à autoriser l'accès au service choisi si la réponse contient un accord ou au contraire à interdire l'accès au service choisi si la réponse contient un refus, caractérisé en ce que le module de validation (44) comporte, avant même que l'utilisateur n'ait choisi un service qu'il souhaite utiliser, un ensemble de jetons (48) de validation téléchargés dont au moins un est utilisable par ce module pour valider l'accès au service choisi, et en ce que le module de validation est apte à choisir le ou les jetons de validation à envoyer dans la requête de validation en fonction des renseignements acquis sur le service choisi, parmi l'ensemble des jetons de validation téléchargés.

4. Système selon la revendication 3, caractérisé en ce que le module de validation (44) est apte à présenter à l'utilisateur du terminal multimédia des informations sur le service choisi, ces informations étant extraites des renseignements acquis et/ou des renseignements compris dans le ou les jetons de validation envoyés au serveur de validation (26), et à acquérir en réponse une autorisation, donnée par l'utilisateur, de poursuivre le contrôle d'accès, et en ce que le serveur de validation est uniquement apte à poursuivre le contrôle d'accès si l'autorisation de poursuivre acquise par le module de validation est reçue.

5. Système selon la revendication 3 ou 4, caractérisé en ce qu'il comporte une passerelle raccordée au réseau grande distance de transmission d'informations apte à insérer automatiquement un alias correspondant à un identifiant du terminal multimédia sur le réseau grande distance dans tout message échangé entre le terminal multimédia et le serveur multimédia sur lequel est implémenté le fournisseur de services et/ou dans tout message échangé entre le terminal multimédia et le serveur de validation.

6. Système selon l'une quelconque des revendications 3 à 5, caractérisé en ce que le ou chaque jeton de validation est invariant en fonction du service choisi et en ce que le module de validation (44) est apte à faire varier le nombre de jetons de validation contenus dans la requête de validation en fonction des renseignements acquis sur le service choisi.

7. Système selon l'une quelconque des revendications 3 à 5, caractérisé en ce que le ou chaque jeton contient au moins un identifiant choisi dans le groupe 2888437 20 composé d'un identifiant de service, d'un identifiant de fournisseur de services, d'un identifiant d'utilisateur, et d'un identifiant d'application multimédia, et en ce que le module de validation (44) est apte à choisir le ou les jetons de validation à utiliser en fonction d'au moins l'un de ces identifiants.

8. Système selon l'une quelconque des revendications 3 à 7, caractérisé en ce que l'application multimédia (42) est apte à présenter plusieurs services différents susceptibles d'être choisis par l'utilisateur.

9. Système selon l'une quelconque des revendications 3 à 8, caractérisé en ce que l'application multimédia et le module de validation sont des modules logiciels indépendants l'un de l'autre aptes à communiquer l'un avec l'autre par l'intermédiaire d'une interface API ( Application Program Interface ) standardisée.

10. Module de validation apte à être utilisé dans un système conforme à l'une quelconque des revendications 3 à 9, caractérisé en ce que le module de validation comporte, avant même que l'utilisateur n'ait choisi le service qu'il souhaite utiliser, un ensemble de jetons de validation téléchargés dont au moins un est utilisable pour valider l'accès au service, et en ce que le module de validation est apte à choisir le ou les jetons de validation à envoyer dans la requête de validation en fonction des renseignements acquis sur le service choisi, parmi l'ensemble des jetons de validation téléchargés contenus dans le module de validation.

11. Serveur (26, 4) apte à être raccordé à un terminal multimédia par l'intermédiaire d'un réseau grande distance, caractérisé en ce qu'il comprend un programme d'ordinateur apte à réaliser l'étape suivante: avant l'étape a), et avant même que l'utilisateur ait choisi le service qu'il souhaite utiliser, le serveur télécharge dans le terminal multimédia des jetons de validation signés dont au moins un est utilisable par ce terminal multimédia pour valider l'accès au service choisi.

12. Terminal multimédia caractérisé en ce qu'il comprend un module de validation tel que défini dans la revendication 10.

13. Programme d'ordinateur apte à être mis en oeuvre dans un serveur (26, 4) tel que défini dans la revendication 11, ledit programme comprenant des instructions de code qui, lorsque ledit programme est exécuté sur ledit serveur (62, 4), réalisent l'étape suivante: - avant l'étape a), et avant même que l'utilisateur ait choisi le service qu'il souhaite utiliser, le serveur télécharge dans le terminal multimédia des jetons de validation signés dont au moins un est utilisable par ce terminal multimédia pour valider l'accès au service choisi.

14. Programme d'ordinateur apte à être mis en oeuvre dans un terminal multimédia (4) tel que défini dans la revendication 12, caractérisé en ce que lorsque ledit programme est exécuté sur ledit terminal multimédia, il réalise l'étape suivante: - entre les étapes a) et b) le terminal multimédia choisit le ou les jetons de validation à envoyer dans la requête de validation en fonction des renseignements acquis sur le service choisi, parmi l'ensemble des jetons de validation téléchargés lors de l'étape e).