Brevet FR2985058A1 — publié le 20130628

Traitement de données pour l'authentification d'un terminal utilisateur La présente invention vise un traitement de données pour l'authentification d'un terminal utilisateur. En particulier, la présente invention vise un traitement de données permettant d'authentifier un terminal utilisateur vis-à-vis d'un serveur de service, dans un réseau de télécommunication comportant un coeur de réseau de type sous-système multimédia IP (ou « IMS » ci-après). On appelle « coeur de réseau » la partie principale d'un réseau de télécommunication, qui concentre et transporte les flux de données entre des réseaux affluents. En d'autres termes, l'IMS joue le rôle de plan de contrôle du réseau et de plan de service pour des services d'opérateurs (par exemple voix sur IP (VoIP)). Un procédé d'authentification peut être mis en oeuvre pour authentifier un terminal utilisateur vis-à-vis d'un serveur de service avant de permettre l'accès du terminal utilisateur au service. Certains procédés d'authentification sont liés à une ligne physique (hertzienne/cuivre/fibre). Dans ce cas, lorsque la ligne est partagée, ce qui est commun dans le cadre des réseaux haut-débits fixes et mobiles, l'authentification est également partagée par les différents utilisateurs de la ligne. On connait également des procédés d'authentification par mot de passe. Cependant, s'il n'y a pas de cryptage associé, le couple identifiant/mot de passe peut être intercepté et réutilisé. En outre, ces procédés nécessitent un couple identifiant/mot de passe par utilisateur et par service, ce qui nécessite l'utilisation d'un grand nombre de couples identifiant/mot de passe et freine la convergence des services mais également l'usage (QoE). On connait également des procédés d'authentification utilisant des tunnels chiffrés. Ces procédés d'authentification sont particulièrement fiables mais rigides, notamment dans les contextes de nomadisme. Ils sont en outre coûteux en termes de ressources, en particulier lorsqu'ils sont mis en oeuvre par les serveurs de service. On connait également des procédés d'authentification par adresse IP. Cependant, ces procédés posent des problèmes de sécurité liés à l'usurpation de l'adresse IP du terminal utilisateur. De plus, ces procédés nécessitent une réauthentification dans le cadre du nomadisme de l'utilisateur d'une infrastructure vers une autre (changement de réseau IP) et limitent donc la transparence du réseau vis-à-vis du serveur de service. La présente invention vient améliorer la situation. A cet effet, l'invention propose un procédé d'authentification d'un terminal utilisateur pour permettre l'accès du terminal utilisateur à un service hébergé dans un serveur de service, comprenant des étapes : /1/ authentifier le terminal utilisateur dans un réseau de type sous-système multimédia IP, /2/ transmettre au serveur de service, depuis un équipement du réseau de type sous-système multimédia IP, des informations relatives à l'authentification du terminal utilisateur, /3/ authentifier le terminal utilisateur vis-à-vis du serveur de service en utilisant les informations transmises. La solution proposée dans cette invention peut ainsi permettre d'authentifier et d'identifier un équipement utilisateur vis-à-vis d'un serveur de service tiers de façon transparente et sécurisée en faisant appel à une infrastructure de type IMS. Elle permet en outre de mutualiser entre plusieurs services hétérogènes l'authentification et l'identification des utilisateurs, ce qui peut permettre la convergence de ces services. L'étape /1/ peut comprendre la transmission, à destination du terminal utilisateur, d'un jeton. On appelle jeton, ou nonce, une donnée secrète partagée entre le terminal utilisateur, l'équipement du réseau de type sous-système multimédia IP, et le serveur de service. L'étape /2/ peut comprendre la transmission, à destination du serveur de service, du jeton associé à une identité publique du terminal utilisateur. L'étape /2/ peut comprendre en outre la transmission, à destination du serveur de service, d'informations relatives à un profil utilisateur. Le réseau de type sous-système multimédia IP est géré par un opérateur de télécommunications disposant d'informations sur les profils des utilisateurs (tranche d'âge, sexe, thèmes préférés, etc.). Grâce à l'invention, l'opérateur peut transmettre certaines de ces informations au serveur de service afin que celui-ci adapte son service ou le personnalise en fonction du profil utilisateur. Le procédé peut en outre comprendre une étape de transmission au serveur de service, depuis un équipement du réseau de type sous-système multimédia IP, d'un message de contrôle indiquant que le couple jeton/identité publique est expiré. L'étape /3/ peut comprendre l'émission par l'équipement utilisateur, à destination du serveur de service, d'une requête contenant une identité publique du terminal utilisateur et un condensat obtenu par l'application d'une fonction de hachage sur la requête, l'identité publique, le jeton et un compteur. L'étape /3/ peut comprendre en outre des opérations, mises en oeuvre dans le serveur de service : - déterminer un condensat par l'application de ladite fonction de hachage sur des informations transmises par l'équipement du réseau de type sous-système multimédia IP, puis - comparer le condensat déterminé avec le condensat reçu du terminal utilisateur. Le terminal utilisateur peut comprendre un client IMS, configuré pour communiquer avec le réseau de type sous-système multimédia IP, et un client service, configuré pour communiquer avec le serveur de service. Dans ce cas, avantageusement, l'étape /1/ comprend une authentification du client IMS dans le réseau de type sous-système multimédia IP et l'étape /3/ comprend une authentification du client service vis-à-vis du serveur de service en utilisant les informations transmises. Le procédé peut également comprendre une opération d'authentification du client service vis-à-vis du client IMS. Le client IMS du terminal utilisateur est placé en coupure, interposé, entre le client service du terminal et le réseau de type sous-système multimédia IP. L'authentification du client service vis-à-vis du client IMS permet de s'assurer que le client service utilisé par le terminal est reconnu et approuvé par l'opérateur du réseau de type sous-système multimédia IP. L'invention propose également un programme informatique comportant des instructions pour la mise en oeuvre du procédé précité lorsque ce programme est exécuté par un processeur. L'invention propose également un système comportant un ou plusieurs équipement(s) d'un réseau de type sous-système multimédia IP, configuré(s) pour : - authentifier un terminal utilisateur, et - transmettre à un serveur de service des informations relatives à l'authentification du terminal utilisateur. Les informations transmises peuvent être utilisées ultérieurement par le serveur de service pour authentifier le terminal utilisateur vis-à-vis du serveur de service. D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels : - la Figure 1 est un schéma fonctionnel montrant un réseau de télécommunication, selon un mode de réalisation de l'invention ; et la Figure 2 est un organigramme illustrant les étapes d'un procédé d'authentification d'un terminal utilisateur du réseau de télécommunication selon un mode de réalisation de l'invention, cet organigramme pouvant représenter l'algorithme général du programme informatique au sens de l'invention. La figure 1 représente un réseau de télécommunication comportant un coeur de réseau 1 de type sous-système multimédia IP (ou « IMS » ci-après). L'IMS 1 comprend notamment un serveur CSCF (Call Session Control Function) 10, un serveur HSS (Home Subscriber Server) 11 et un serveur d'application (AS) 12. Le réseau de télécommunication comporte également un ensemble de serveurs de service 3-1 à 3-N, hébergeant des services. Les serveurs de service 3-1 à 3-N sont configurés pour communiquer avec l'IMS 1 via un canal sécurisé 5. Le réseau de télécommunication comporte également un terminal utilisateur 2. Le terminal utilisateur 2 comprend un client IMS 20 configuré pour communiquer avec l'IMS 1 via un canal de communication sécurisé 4. Le terminal 2 comprend en outre un ensemble de clients service 21-1 à 21-N configurés pour communiquer respectivement avec les serveurs de service 3-1 à 3-N, via un canal de communication non sécurisé. Le client IMS 20 est en outre configuré pour signaler tout changement relatif à un jeton vers les clients service 21-1 à 21-N. Le jeton, également appelé nonce, est ici une donnée secrète partagée entre le client IMS 20 du terminal utilisateur 2, l'AS 12 et le ou les serveurs de service 3-1 à 3-N. La figure 2 représente les étapes d'un procédé d'authentification d'un terminal utilisateur pour permettre l'accès du terminal utilisateur à un service hébergé dans un serveur de service, selon un mode de réalisation de l'invention. On suppose par exemple que le client service 21-N du terminal utilisateur 2 doit s'authentifier vis-à-vis du serveur de service 3-N, pour accéder à un service hébergé dans le serveur de service 3-N. Pour s'authentifier vis-à-vis du serveur de service 3-N, le client service 21-N a besoin d'un jeton formant un identifiant unique, par exemple au format UUID (Universally Unique Identifier). Le client service 21-N transmet donc une demande de jeton au client IMS 20, comme symbolisé par la flèche Fl sur la figure 1. Lorsque le client IMS 20 possède déjà un jeton valide, il le livre au client de service 21-N, comme symbolisé par la flèche F2 sur la figure 1. Sinon, le procédé comporte une étape 51 d'enregistrement. A l'étape Sl, le terminal utilisateur 2 s'authentifie vis-à-vis de l'IMS 1, pour obtenir un jeton valable. L'authentification est réalisée par le client IMS 20 du terminal utilisateur 2. Le client IMS 20 transmet au CSCF 10 une requête d'enregistrement, comme symbolisé par la flèche F3 sur la figure 1. Le CSCF 10 récupère alors des données relatives au profil utilisateur associé au terminal 2, par exemple en les téléchargeant dans l'HSS 11, comme symbolisé par la flèche F4 sur la figure 1. Le CSCF 10 est configuré pour informer l'AS 12 des enregistrements/réenregistrements/désenregistrements des clients, comme défini dans les normes 3GPP 23.218 et 24.229. En particulier, à l'étape S1, le CSCF 10 informe l'AS 12 de l'enregistrement du client service 21-N, comme symbolisé par la flèche F5 sur la figure 1. Puis, l'AS 12 livre un jeton valable au client IMS 20, comme symbolisé par la flèche F6 sur la figure 1. Par exemple, le jeton est renvoyé par l'AS 12 à l'aide d'un message SIP. Le client IMS 20 livre le jeton reçu au client service 21-N (flèche F2). Le client service 21-N va ainsi pouvoir utiliser le jeton pour générer des messages à destination du serveur de service 3-N, et ainsi accéder au service. La communication entre le client IMS 20 et l'IMS 1 est réalisée en utilisant un canal sécurisé, symbolisé par le cylindre 4 sur la figure 1. Le protocole utilisé est par exemple le protocole SIP. A l'étape S2, l'IMS 1 transmet au serveur de service 3-N un message d'information contenant des informations relatives à l'authentification du terminal utilisateur 2, comme symbolisé par la flèche F7 sur la figure 1. Par exemple, le message d'information est transmis par l'AS 12 et contient le jeton livré au client IMS 20 associé à une identité publique IMPU du client IMS 20. Le serveur de service 3-N peut renvoyer vers l'AS 12 un message SIP de type « 200 OK » pour accuser la réception, ou une réponse de type « 40x » en cas d'erreur, comme symbolisé par la flèche F8 sur la figure 1. La communication entre l'IMS 1 et le serveur de service 3-N est réalisée en utilisant un canal sécurisé, symbolisé par le cylindre 5 sur la figure 1. L'étape S2 peut en outre comprendre la transmission d'informations relatives à un profil utilisateur. Les informations de profil utilisateur comprennent par exemple des informations relatives au sexe de l'utilisateur, à une tranche d'âge de l'utilisateur, à des thèmes préférés de l'utilisateur, etc. Le serveur de service 3-N peut ainsi s'adapter à l'utilisateur, notamment en faisant des recommandations pertinentes et/ou en adaptant le service au profil utilisateur. L'étape S2 peut être répétée de manière similaire pour plusieurs serveurs de service 3-1 à 3-N. A l'étape S3, le client service 21-N du terminal utilisateur 2 accède au service hébergé dans le serveur de service 3-N. Le client service 21-N transmet au serveur de service 3-N une requête de traitement, comme symbolisé par la flèche F9 sur la figure 1. La requête de traitement est complétée avec l'identité publique IMPU du client service 21-N et un condensat obtenu par l'application d'une fonction de hachage H définie par : H(requête, identité publique, jeton, compteur) La fonction H est une fonction à sens unique sans brèche secrète. Le compteur (par exemple entier sur 32 bits) est propre à chaque service N. Il commence à la valeur 0 et est incrémenté des deux côtés (serveur de service 3-N et client service 21-N) à chaque nouvelle requête, dans le cadre des protocoles en mode connecté, afin d'éviter le rejeu. Dans le cadre des services portés sur des protocoles transport en mode non connecté, un canal de synchronisation du compteur est en outre utilisé. Le compteur est remis à zéro des deux côtés quand le jeton change L'ensemble formé par la requête de traitement, l'identité IMPU et le condensat forme une requête étendue. Le serveur de service 3-N reçoit la requête étendue et détermine un condensat par l'application de la fonction de hachage H à des données mémorisées dans une base de données locale du serveur de service 3-N. Les données mémorisées dans la base de données sont des données transmises au préalable par l'IMS 1. Puis, le serveur de service 3-N compare le condensat déterminé avec le condensat reçu du terminal utilisateur 2. Si les condensats sont identiques, le serveur de service 3-N détermine que le client service 21-N peut accéder au service. Le serveur de service 3-N répond alors à la requête de traitement, comme symbolisé par la flèche F10 sur la figure 1. La communication entre le client service 21-N et le serveur de service 3-N est réalisée en utilisant un canal non sécurisé pour préserver la Qualité d'Expérience (QoE) du service et les interactions du client de service avec les équipements à proximité en lui permettant de se rattacher au même réseau IP que son environnement. L'étape S3 peut être répétée de manière similaire pour plusieurs serveurs de service 3-1 à 3-N. Le jeton reste valide tant que le client IMS 20 reste enregistré sur l'IMS 1. Lorsque le CSCF 10 détermine que le jeton est expiré, le procédé passe à l'étape S4. A l'étape S4, le CSCF 10 transmet à l'AS 12 un message indiquant l'expiration du jeton. L'AS 12 transmet alors au serveur de service 3-N un message de contrôle indiquant que le couple jeton/identité publique n'est plus valide, c'est-à-dire est expiré, comme symbolisé par la flèche Fll sur la figure 1. Le serveur de service 3-N peut ainsi mettre à jour sa base de données. Le serveur de service 3-N peut en outre renvoyer vers l'AS 12 un accusé de réception, comme symbolisé par la flèche F12 sur la figure 1. L'étape S4 peut être répétée de manière similaire pour plusieurs serveurs de service 3-1 à 3-N. Le procédé permet ainsi d'authentifier un client service de manière sécurisée et mutualisée. En effet, cette solution repose sur une infrastructure IMS pour l'authentification mais est utilisable pour des serveurs de service tiers non IMS. Cette solution est en outre utilisable dans un contexte de nomadisme, et permet d'authentifier un utilisateur sur plusieurs serveurs de service avec un seul couple identifiant/mot de passe, de façon transparente. Le procédé peut en outre comprendre une étape d'authentification du client service 21-N vis-à-vis du client IMS 20. L'authentification est par exemple réalisée par le biais d'un mécanisme de certification. Le client IMS 20 est en coupure entre le client service 21-N et l'IMS 1, qui est géré par l'opérateur du réseau IMS. Le client IMS 20 connaît l'identifiant IMS de l'utilisateur et gère le jeton. Ainsi, cette étape d'authentification permet de s'assurer que la brique logicielle formée par le client service 21-N est reconnue et approuvée par l'opérateur. Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemples ; elle s'étend à d'autres variantes. REVENDICATIONS1. Procédé d'authentification d'un terminal utilisateur (2) pour permettre l'accès du terminal utilisateur à un service hébergé dans un serveur de service (3), comprenant des étapes : /1/ authentifier le terminal utilisateur dans un réseau de type sous-système multimédia IP (1), /2/ transmettre au serveur de service, depuis un équipement du réseau de type sous-système multimédia IP, des informations relatives à l'authentification du terminal utilisateur, /3/ authentifier le terminal utilisateur vis-à-vis du serveur de service en utilisant les informations transmises. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape /1/ comprend la transmission, à destination du terminal utilisateur (2), d'un jeton. 3. Procédé selon la revendication 2, caractérisé en ce que l'étape /2/ comprend la transmission, à destination du serveur de service (3), du jeton associé à une identité publique du terminal utilisateur. 4. Procédé selon la revendication 3, caractérisé en ce que l'étape /2/ comprend en outre la transmission, à destination du serveur de service (3), d'informations relatives à un profil utilisateur. 5. Procédé selon la revendication 3, caractérisé en ce qu'il comprend une étape : /4/ transmettre au serveur de service (3), depuis un équipement du réseau de type sous-système multimédia IP, un message de contrôle indiquant que le couple jeton/identité publique est expiré. 6. Procédé selon la revendication 2, caractérisé en ce que l'étape /3/ comprend l'émission par l'équipement utilisateur (2), à destination du serveur de service (3), d'une requête étendue contenant une requête de traitement, une identité publiquedu terminal utilisateur et un condensat obtenu par l'application d'une fonction de hachage sur la requête de traitement, l'identité publique, le jeton et un compteur. 7. Procédé selon la revendication 6, caractérisé en ce que l'étape /3/ comprend en outre des opérations, mise en oeuvre dans le serveur de service : - déterminer un condensat par l'application de ladite fonction de hachage sur des informations transmises par l'équipement du réseau de type sous-système multimédia IP, puis - comparer le condensat déterminé avec le condensat reçu du terminal utilisateur. 8. Procédé selon la revendication 1, caractérisé en ce que le terminal utilisateur (2) comprend un client IMS (20), configuré pour communiquer avec le réseau de type sous-système multimédia IP, et un client service (21), configuré pour communiquer avec le serveur de service (3), et en ce que l'étape /1/ comprend une authentification du client IMS dans le réseau de type sous-système multimédia IP et l'étape /3/ comprend une authentification du client service vis-à-vis du serveur de service en utilisant les informations transmises 9. Procédé selon la revendication 8, caractérisé en ce qu'il comprend en outre une opération d'authentification du client service (21) vis-à-vis du client IMS (20). 10. Programme informatique comportant des instructions pour la mise en oeuvre du procédé selon la revendication 1 lorsque ce programme est exécuté par un processeur. 11. Système comportant un ou plusieurs équipement(s) d'un réseau de type sous-système multimédia IP (1), configuré(s) pour : - authentifier un terminal utilisateur, et - transmettre à un serveur de service (3) des informations relatives à l'authentification du terminal utilisateur, les informations transmises pouvant être utilisées ultérieurement par le serveur de service pour authentifier le terminal utilisateur vis-à-vis du serveur de service.