FR 3051273 A1 20171117 FR 1654174 A 20160510 1 Technique d'authentification d'un dispositif utilisateur L'invention se rapporte au domaine général des télécommunications. L'invention concerne plus particulièrement une technique d'authentification d'un dispositif utilisateur auprès d'un serveur mettant en oeuvre une application. De nombreuses applications requièrent une identification d'un utilisateur. Pour pouvoir se connecter à une application, un utilisateur doit par exemple renseigner un identifiant de connexion, comprenant un identifiant d'utilisateur et un mot de passe. L'identifiant de connexion permet à l'administrateur d'un service de gérer les droits d'accès d'un utilisateur associé à cet identifiant pour cette application. Ce type d'identification nécessite que l'utilisateur crée un compte sur le serveur mettant en oeuvre l'application et mémorise un identifiant de connexion et un mot de passe. Il est également courant de se baser sur un identifiant d'un abonnement auprès d'un opérateur, typiquement le MSISDN (pour « Mobile Station Integrated Services Digital Network Number »). Cet identifiant est le numéro connu du public d'identification de l'utilisateur dans le réseau de son opérateur. C'est cet identifiant, couramment appelé numéro de téléphone, qui doit être composé afin de joindre l'utilisateur ayant souscrit à un abonnement. Lorsqu'un dispositif utilisateur est connecté sur le réseau de son propre opérateur, il existe des mécanismes réseau qui permettent à une application proposée par cet opérateur d'obtenir cet identifiant de manière fiable. Ceci permet d'authentifier implicitement l'utilisateur. Dans les autres cas, l'identifiant devrait être fourni de manière déclarative par l'utilisateur et il n'y a aucune garantie que l'identifiant fourni appartient bien à cet utilisateur. Il n'est ainsi pas possible d'authentifier un abonné d'un autre opérateur de façon implicite. Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations. Selon un premier aspect, l'invention a pour objet un procédé d'authentification d'un dispositif utilisateur auprès d'un serveur mettant en oeuvre une application, dit serveur applicatif. Ce procédé comprend : - une obtention par le dispositif d'un identifiant, dit identifiant secondaire, permettant au dispositif de recevoir des notifications relatives à l' application : - un envoi par le dispositif, identifié par un identifiant, dit identifiant principal, associé au dispositif par l'intermédiaire d'un module de sécurité, d'un message de signalisation comprenant l'identifiant secondaire ; - une réception par ledit dispositif d'une notification relative à l'application adressée au dispositif identifié par l'identifiant secondaire, ladite notification comprenant l'identifiant principal et un authentifiant, et dont l'envoi a été commandé par le serveur applicatif ; - un envoi par ledit dispositif au serveur applicatif d'une demande d'authentification, ladite demande comprenant l'identifiant principal et l'authentifiant reçus, ledit dispositif étant 3051273 2 authentifié par le serveur applicatif au moyen dudit identifiant principal en association avec ledit identifiant secondaire. Corrélativement, le procédé d'authentification d'un dispositif utilisateur auprès d'un serveur mettant en oeuvre une application, dit serveur applicatif, comprend : 5 - une obtention par le serveur applicatif d'une demande d'enregistrement dudit dispositif au moyen d'un identifiant principal et d'un identifiant secondaire, obtenus à partir d'un message de signalisation envoyé par le dispositif identifié par ledit identifiant principal, associé au dispositif par l'intermédiaire d'un module de sécurité, ledit message comprenant l'identifiant secondaire, obtenu par le dispositif pour recevoir des notifications relatives à l'application : 10 - une commande par le serveur applicatif d'un envoi d'une notification relative à l'application adressée au dispositif identifié par l'identifiant secondaire, ladite notification comprenant l'identifiant principal et un authentifiant attendu ; - une réception par le serveur applicatif d'une demande d'authentification en provenance du dispositif, ladite demande comprenant l'identifiant principal et un authentifiant, ledit dispositif 15 étant authentifié par le serveur applicatif au moyen dudit identifiant principal en association avec ledit identifiant secondaire lorsque l'authentifiant reçu correspond à l'authentifiant attendu. Il est ainsi possible à l'application, aussi bien au niveau du dispositif utilisateur que du serveur applicatif, d'obtenir de manière fiable un identifiant de l'utilisateur sans nécessiter de manipulation de l'utilisateur. Cet identifiant de l'utilisateur, appelé identifiant principal, est celui 20 qui est mémorisé dans un module de sécurité associé au dispositif utilisateur. Il est obtenu par le serveur applicatif au moyen d'un message de signalisation, qui comprend cet identifiant en tant qu'adresse d'origine du message. Le parcours client est très simplifié et sécurisé. L'utilisateur n'a pas besoin de créer un compte auprès de l'opérateur mettant en oeuvre l'application. Il n'a pas besoin de mémoriser un identifiant de connexion et un mot de passe pour cette application. De plus, 25 l'identifiant secondaire permet à l'application de pousser des informations au moyen de notifications à destination du dispositif utilisateur (mode « push » en anglais). Ces notifications sont par exemple poussées par un serveur de notification. Il est ainsi possible de réaliser une authentification implicite même lorsque l'utilisateur du dispositif utilisateur n'a pas souscrit d'abonnement auprès de l'opérateur proposant l'application. Cette technique trouve une application 30 particulièrement intéressante pour l'authentification d'objets connectés. Les différents modes ou caractéristiques de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, au procédé d'authentification tel que défini précédemment. Selon une caractéristique particulière du procédé d'authentification, l'identifiant 35 secondaire compris dans le message de signalisation est chiffré par le dispositif au moyen d'une clé partagée avec le serveur applicatif. Corrélativement, l'identifiant secondaire compris dans le 3051273 3 message de signalisation est déchiffré par le serveur applicatif au moyen d'une clé partagée avec le dispositif. Le chiffrement de l'identifiant secondaire permet de garantir au serveur applicatif que le dispositif utilisateur dispose bien de la clé partagée par le dispositif utilisateur et le serveur 5 applicatif, et ainsi exécute bien l'application. Dans un mode de réalisation particulier du procédé d'authentification, l'identifiant principal et l' authentifiant compris dans la notification sont déchiffrés par le dispositif au moyen d'une clé partagée avec le serveur applicatif. Corrélativement, l'identifiant principal et l'authentifiant compris dans la notification sont chiffrés par le serveur applicatif au moyen d'une 10 clé partagée avec le dispositif. Un équipement servant d'intermédiaire entre le serveur applicatif et le dispositif utilisateur s'il intercepte la notification ne peut décoder les informations qu'elle contient, notamment l'identifiant principal et l' authentifiant. Un autre dispositif utilisateur n' a pas de possibilité de se faire passer pour le dispositif ayant demandé à s'enregistrer. 15 Dans un mode de réalisation particulier du procédé d'authentification, la clé est déterminée par le dispositif à partir d'une adresse de contact associée à l'application et d'un identifiant de l'application. Cette clé peut également être déterminée par le serveur applicatif à partir d'une adresse de contact associée à l'application et d'un identifiant de l'application. Ceci permet de garantir que le dispositif utilisateur dispose bien de l'identifiant de 20 l' application et de l'algorithme de génération de la clé partagée. Dans un mode de réalisation particulier du procédé d'authentification, le dispositif requiert l'identifiant secondaire en fournissant un identifiant de l'application. La fourniture de l'identifiant de l'application permet ensuite au serveur applicatif de commander l'envoi de la notification à destination du dispositif utilisateur. 25 Selon un deuxième aspect, l'invention concerne également un dispositif utilisateur comprenant : - un module de communication avec un serveur de notification, agencé pour obtenir un identifiant, dit identifiant secondaire, et pour recevoir des notifications relatives à l'application adressées au dispositif identifié par l'identifiant secondaire : 30 - un module de signalisation, agencé pour envoyer un message de signalisation comprenant un identifiant secondaire et d' adresse origine un identifiant, dit identifiant principal, associé au dispositif par l'intermédiaire d'un module de sécurité ; - un module d'authentification, agencé pour extraire d'une notification relative à l'application reçue l'identifiant principal et un authentifiant et pour envoyer à un serveur applicatif 35 une demande d'authentification, ladite demande comprenant l'identifiant principal et l' authentifiant reçus, ledit dispositif étant authentifié par le serveur applicatif au moyen dudit identifiant principal en association avec ledit identifiant secondaire. 3051273 4 Ce dispositif utilisateur peut bien sûr comporter en termes structurels les différentes caractéristiques relatives au procédé d'authentification tel que décrit précédemment, qui peuvent être combinées ou prises isolément. Ainsi, les avantages énoncés pour le procédé d' authentification selon le premier aspect sont transposables directement au dispositif utilisateur. Par conséquent, ils 5 ne sont pas détaillés plus amplement. Selon un troisième aspect, l'invention concerne également un serveur mettant en oeuvre une application, dit serveur applicatif. Ce serveur comprend : - un module d'authentification, agencé pour obtenir une demande d'enregistrement d'un dispositif utilisateur au moyen d'un identifiant principal et d'un identifiant secondaire, obtenus à 10 partir d'un message de signalisation envoyé par le dispositif identifié par ledit identifiant principal, associé au dispositif par l'intermédiaire d'un module de sécurité, ledit message comprenant l'identifiant secondaire, obtenu par le dispositif pour recevoir des notifications relatives à l' application, et pour générer un authentifiant pour ledit dispositif : - un module de commande, agencé pour commander un envoi d'une notification relative à 15 l'application, adressée au dispositif identifié par l'identifiant secondaire, ladite notification comprenant l'identifiant principal et un authentifiant attendu ; ledit module d' authentification étant en outre agencé pour recevoir en provenance du dispositif ayant demandé à être enregistré une demande d' authentification, ladite demande comprenant l'identifiant principal et un authentifiant, ledit dispositif étant authentifié par le serveur applicatif au 20 moyen dudit identifiant principal en association avec ledit identifiant secondaire lorsque l' authentifiant reçu correspond à l'authentifiant attendu. Ce serveur applicatif peut bien sûr comporter en termes structurels les différentes caractéristiques relatives au procédé d'authentification tel que décrit précédemment, qui peuvent être combinées ou prises isolément. Ainsi, les avantages énoncés pour le procédé d' authentification 25 selon le premier aspect sont transposables directement au serveur applicatif. Par conséquent, ils ne sont pas détaillés plus amplement. Selon un quatrième aspect, l'invention concerne un programme pour un dispositif utilisateur, comprenant des instructions de code de programme destinées à commander l'exécution de celles des étapes du procédé d'authentification précédemment décrit mises en oeuvre par le 30 dispositif utilisateur, lorsque ce programme est exécuté par ce dispositif et un support d'enregistrement lisible par un dispositif sur lequel est enregistré un programme pour un dispositif. Les avantages énoncés pour le procédé d'authentification selon le premier aspect sont transposables directement au programme pour un dispositif utilisateur et au support d' enregistrement. 35 Selon un cinquième aspect, l'invention concerne un programme pour un serveur applicatif, comprenant des instructions de code de programme destinées à commander l'exécution de celles des étapes du procédé d'authentification précédemment décrit mises en oeuvre par le 3051273 5 serveur applicatif, lorsque ce programme est exécuté par ce serveur et un support d'enregistrement lisible par une entité de confiance sur lequel est enregistré un programme pour un serveur. Les avantages énoncés pour le procédé d'authentification selon le premier aspect sont transposables directement au programme pour un serveur et au support d'enregistrement. 5 La technique d'authentification d'un dispositif utilisateur sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers, en référence aux dessins annexés sur lesquels : la figure 1 représente un environnement dans lequel est mis en oeuvre le procédé d'authentification d'un dispositif utilisateur dans un mode de réalisation particulier ; 10 la figure 2 illustre des étapes d'un procédé d'authentification mises en oeuvre par un dispositif utilisateur et un serveur applicatif selon un mode particulier de réalisation ; la figure 3 représente un dispositif utilisateur selon un mode particulier de réalisation ; la figure 4 représente un serveur applicatif selon un mode particulier de réalisation. 15 La figure 1 représente un environnement dans lequel est mis en oeuvre le procédé d'authentification d'un dispositif utilisateur auprès d'un serveur mettant en oeuvre une application dans un mode de réalisation particulier. Sur la figure 1 sont représentés deux dispositifs utilisateur 10, 11 accédant à une 20 application par l'intermédiaire d'un réseau de communication 2. Le premier dispositif utilisateur 10 est un terminal mobile connecté au réseau de communication 2 par l'intermédiaire d'un réseau d'accès sans fil, tel qu'un réseau mobile GSM, UMTS, LTE, ... Ce premier dispositif utilisateur 10 est équipé d'un module de sécurité, associé à un abonnement auquel son utilisateur a souscrit auprès d'un premier opérateur de réseau. Le deuxième dispositif utilisateur 11 est un objet connecté 25 accédant au réseau de communication 2 par l'intermédiaire d'un réseau d'accès sans fil, tel qu'un réseau mobile GSM, UMTS, LTE, .... Ce deuxième dispositif utilisateur 11 est également équipé d'un module de sécurité, associé à un abonnement auquel son utilisateur a souscrit auprès d'un deuxième opérateur de réseau. Aucune limitation n'est attachée au nombre de dispositifs utilisateur, ni au nombre d'opérateurs de réseau. A titre illustratif, on a choisi un exemple dans lequel à chaque 30 dispositif utilisateur est associé un opérateur de réseau distinct. Toutefois, aucune limitation n'est attachée à cet exemple. Les utilisateurs des deux dispositifs peuvent notamment avoir souscrit un abonnement auprès d'un même opérateur de réseau. L'identifiant d'utilisateur ou identifiant principal Id_P correspond par exemple à un identifiant d'un abonnement auprès d'un opérateur, typiquement le MSISDN (pour « Mobile 35 Station Integrated Services Digital Network Number »). Cet identifiant est le numéro connu du public d'identification de l'utilisateur dans le réseau de son opérateur. C'est cet identifiant, couramment appelé numéro de téléphone, qui doit être composé afin de joindre l'utilisateur ayant 3051273 6 souscrit à un abonnement. Cet identifiant principal est associé au dispositif par l'intermédiaire d'un module de sécurité. Le module de sécurité peut correspondre à une carte à puce amovible de type USIM, UICC, ou bien un module logiciel sécurisé s'exécutant dans une zone mémoire sécurisée du dispositif utilisateur, ou bien encore hébergé sur un équipement du réseau. Aucune limitation n'est 5 attachée à ce module de sécurité. Le réseau de communication 2 permet notamment d'accéder à un serveur 30 mettant en oeuvre une application, dit serveur applicatif. L'application requiert une identification de l'utilisateur. L'application est par exemple un service accessible sur la toile d'araignée mondiale WVVW (pour « World Wide Web »), communément appelée le Web ou la Toile, via des échanges 10 hypertexte. Un serveur de notification 40 est également connecté au réseau de communication 2. Un tel serveur de notification permet d'envoyer des notifications relatives à une application à un ou des dispositifs utilisateur ayant souscrit à ce service de notification. Chaque dispositif utilisateur a obtenu un identifiant de notification, appelé par la suite identifiant secondaire et noté Id_S. Les 15 notifications sont transmises en mode poussé (mode « push » en anglais), c'est-à-dire sans sollicitation explicite du dispositif utilisateur. Ce serveur de notification est par exemple un serveur GCM (pour « Google Cloud Messaging ») proposé par la société Google, un serveur APNS (pour « Apple Push Notification Service ») proposé par la société Apple ou bien encore un serveur WNS (pour « Windows push Notification Service ») proposé par la société Microsoft. 20 Un serveur de médiation 20 est également connecté au réseau de communication 2. Ce serveur de médiation 20 est notamment agencé pour recevoir un message de signalisation ayant pour origine un dispositif identifié par un identifiant principal Id_P et comprenant un identifiant secondaire Id_S, pour extraire l'identifiant principal de l'entête de ce message de signalisation et l'identifiant secondaire de la charge utile (« payload » en anglais) et pour envoyer au serveur 25 applicatif 30 une demande d'enregistrement du dispositif utilisateur 10, 11, cette demande comprenant les deux identifiants, principal et secondaire, extraits. Le message de signalisation est un message court SMS (pour « Short Message Service »), tel que défini pour les réseaux de communication mobiles conformes à la norme 3GPP. On se place ici dans le cas où le serveur applicatif 30 et le serveur de médiation 20 sont distincts. Aucune limitation n'est attachée à ce 30 mode de réalisation. Il est en effet possible de prévoir un unique serveur jouant les rôles du serveur de médiation 20 et du serveur applicatif 30. Dans un autre mode de réalisation, le message de signalisation est un message USSD (pour « Unstructured Supplementary Service Data »). L'application dans ce cas doit obtenir une autorisation pour envoyer un tel message de signalisation. 35 La figure 2 illustre des étapes d'un procédé d'authentification d'un dispositif utilisateur 10 auprès d'un serveur mettant en oeuvre une application, dit serveur applicatif 30 selon un mode particulier de réalisation. 3051273 7 L'utilisateur demande par l'intermédiaire d'une interface homme-machine du dispositif utilisateur 10 un démarrage de l'application fournie par le serveur 30. Plus précisément, cette demande de démarrage s'effectue par l'intermédiaire d'un icône qui s'affiche sur un écran et avec lequel l'utilisateur peut interagir. Dans un mode de réalisation particulier, par exemple pour le 5 dispositif utilisateur 11, l'utilisateur interagit avec un bouton pour démarrer l'application. Dans une étape d'envoi El, le dispositif utilisateur 10 (plus précisément l'application s'exécutant sur le dispositif) envoie une demande M1 au serveur de notification 40 afin d'obtenir en retour un identifiant secondaire Id_S pour l'application identifiée par l'identifiant d'application Id_A. Les échanges entre le dispositif utilisateur 10 et le serveur 40 s'effectuent conformément à 10 un protocole propre au serveur de publication. Grâce à cet identifiant secondaire, le dispositif utilisateur 10 peut recevoir ensuite des notifications relatives à l'application en provenance du serveur de notification 40. Dans une étape Hl, une fois cette demande M1 reçue, le serveur de notification 40 alloue un identifiant secondaire Id_S au dispositif utilisateur 10, le mémorise en association avec l'identifiant d'application Id_A et le transmet en retour au dispositif utilisateur 10 15 dans un message M2. Dans une étape de réception E2, le dispositif utilisateur 10 obtient l'identifiant secondaire alloué Id_S pour cette application. Plus précisément, le dispositif utilisateur 10 le reçoit dans le message M2. Ces étapes El et E2 peuvent avoir été exécutées le cas échéant lors d'une première exécution de l'application et l'identifiant secondaire mémorisé par le dispositif utilisateur 10 à cette 20 occasion. Dans ce cas, l'étape E2 consiste à obtenir l'identifiant secondaire par lecture en mémoire. Dans une étape E3, le dispositif utilisateur 10 envoie un message de signalisation M3 comprenant l'identifiant secondaire Id_S. Dans ce mode de réalisation, le message de signalisation correspond à un message court SMS (pour « Short Message Service ») adressé à une adresse de contact associée à l'application. Pour envoyer ce message de signalisation, le dispositif utilisateur 25 10 est identifié par son identifiant principal Id_P, associé au dispositif par l'intermédiaire du module de sécurité 107. On rappelle ici que l'identifiant principal Id_P correspond au numéro MSISDN associé à l'utilisateur. Ainsi, le message de signalisation M3 comprend dans une entête l'identifiant principal Id_P en tant qu'adresse d'origine du message. Il est ici souligné que l'application ne renseigne pas elle-même cette adresse d'origine et n'en a pas connaissance lors de 30 l'exécution de cette étape. Ceci est effectué par un module de signalisation 105 qui renseigne l'adresse d'origine de tous les messages de signalisation qu'il envoie avec l'identifiant principal Id_P. L'identifiant secondaire Id_S est quant à lui porté par la charge utile (ou « payload » en anglais) du message M3. L'adresse de contact pour l'application permet d'acheminer le message de signalisation M3 au serveur de médiation 20. 35 Dans une étape Fl, le serveur de médiation 20 reçoit le message de signalisation M3, extrait l'identifiant principal Id_S de l'entête et l'identifiant secondaire Id_S de la charge utile. Toujours dans cette étape Fl, le serveur de médiation 20 transmet une demande d'enregistrement 3051273 8 M4 du dispositif utilisateur 10 au serveur applicatif 30. Cette demande d'enregistrement M4 comprend notamment l'identifiant principal Id_P et l'identifiant secondaire Id_S, qui ont été obtenus à partir du message de signalisation M3 envoyé par le dispositif utilisateur 10 identifié par son identifiant principal Id_P. 5 Le serveur applicatif 30 reçoit la demande d'enregistrement M4 dans une étape G1 et mémorise dans une zone mémoire 305 l'identifiant principal Id_P en association avec l'identifiant secondaire Id_S. Toujours dans cette étape G1, le serveur applicatif 30 génère par exemple de manière aléatoire un authentifiant C (également appelé « credential » en anglais). Un état associé au dispositif utilisateur 10 est « en attente d' authentification ». Dans une étape G2, le serveur 10 applicatif 30 commande par un message M5 au serveur de notification 40 un envoi d'une notification M relative à l'application adressée au dispositif identifié par l'identifiant secondaire Id_S. Cette notification M comprend l'identifiant principal Id_P et l'authentifiant attendu C. Dans une étape H2, le serveur de notification 40 reçoit la commande M5 et pousse la notification M relative à l'application vers le dispositif utilisateur 10 identifié par l'identifiant 15 secondaire Id_S (message M6). Dans une étape E4, le dispositif utilisateur 10 reçoit la notification M (message M6) et extrait de cette notification M l'identifiant principal Id_P et l'authentifiant C. L'application s'exécutant sur le dispositif utilisateur 10 obtient ainsi l'identifiant principal Id_P pour une utilisation ultérieure le cas échéant. On souligne ici que, pour les dispositifs utilisateur disponibles 20 à ce jour, il n'est pas possible pour l'application d'obtenir cet identifiant principal, aucune interface de programmation applicative API (pour « Application Programming Interface ») n'étant définie. Dans une étape E5, le dispositif utilisateur 10 (plus précisément l'application s'exécutant sur celui-ci) envoie au serveur applicatif 30 une demande d'authentification M7. Cette demande d'authentification M7 comprend notamment l'identifiant principal Id_P et l'authentifiant C. 25 Dans une étape G3, le serveur applicatif 30 vérifie que l'authentifiant C correspond bien à l'authentifiant attendu pour cet identifiant principal Id_P. Si tel est le cas, l'état associé au dispositif utilisateur 10 devient « authentifié » et le serveur applicatif 30 renvoie un message M8 au dispositif utilisateur 10 confirmant le succès de l'authentification. Si tel n'est pas le cas (non représenté sur la figure 2), c'est-à-dire si l' authentifiant reçu ne correspond pas à l'authentifiant 30 attendu pour cet identifiant principal Id_P, le serveur applicatif 30 renvoie un message au dispositif utilisateur indiquant l'échec de l'authentification. On constate ainsi, en cas de succès, que l' application a obtenu, aussi bien au niveau du dispositif utilisateur que du serveur applicatif, l'identifiant principal Id_P de manière fiable. Le dispositif utilisateur a pu s'authentifier auprès du serveur applicatif de manière simple et sécurisée. On constate également que du point de vue de 35 l'utilisateur, le parcours pour exécuter l'application est très simple à mettre en oeuvre. Il lui suffit de démarrer l'exécution de l'application. Ainsi, l'utilisateur ne doit pas mémoriser de mot de passe. L' accès s'effectue au moyen d'un dispositif utilisateur authentifié par son opérateur de réseau. Il 3051273 9 n'y a pas d'ambigüité sur l'identité de l'utilisateur. Le dispositif utilisateur joue ainsi un rôle d'élément de sécurité (ou « Secure Element » en anglais) et apporte une sécurisation du procédé d'authentification pour une exécution de l'application. L'identifiant secondaire Id_S permet en outre à l'application de transmettre ultérieurement des notifications à destination du dispositif 5 utilisateur de manière simple. La description du procédé d'authentification a été faite en se plaçant au niveau du dispositif utilisateur 10. Ce procédé est bien entendu également applicable pour une mise en oeuvre par le dispositif utilisateur 11. On rappelle ici que ce dispositif utilisateur 11 est un objet connecté, pour lequel l'utilisateur a souscrit un abonnement auprès d'un deuxième opérateur différent de 10 celui (premier opérateur) qui met en oeuvre le serveur applicatif 30. On constate que pour ce dispositif 11, l'authentification s'effectue implicitement, bien que ce dispositif ne soit pas connu du premier opérateur. L'utilisateur de ce dispositif 11 ne doit pas créer un compte auprès du premier opérateur avant de pouvoir exécuter l'application. Dans les différentes variantes, décrites ci-après, une clé de chiffrement est partagée par le 15 dispositif utilisateur 10 avec le serveur applicatif 30. Dans un premier cas, le chiffrement est symétrique et la clé partagée correspond à la clé de chiffrement. Dans un deuxième cas, le chiffrement est asymétrique. Un des deux équipements (dispositif utilisateur ou serveur applicatif) dispose de la clé publique associée à la clé privée du deuxième équipement. Dans une première variante de réalisation, à l'étape E3, l'identifiant secondaire compris 20 dans le message de signalisation est chiffré par le dispositif utilisateur 10 au moyen de la clé partagée (clé secrète dans le cas du chiffrement symétrique, clé publique du serveur applicatif dans le cas du chiffrement asymétrique). Le serveur de médiation 20 extrait alors l'identifiant secondaire Id_S chiffré et le transmet au serveur applicatif 30, qui le déchiffre alors à l'étape G1 au moyen de la clé partagée (clé secrète dans le cas du chiffrement symétrique, clé privée du serveur applicatif 25 dans le cas du chiffrement asymétrique). Ceci permet de garantir au serveur applicatif 30 que l'identifiant secondaire a bien été transmis par l'application s'exécutant sur le dispositif utilisateur 10. Dans une deuxième variante de réalisation, à l'étape Gl, la notification M est chiffrée par le serveur applicatif 30 au moyen de la clé partagée (clé secrète dans le cas du chiffrement 30 symétrique, clé publique du dispositif utilisateur dans le cas du chiffrement asymétrique). Le dispositif utilisateur 10 déchiffre alors à l'étape E4 la notification M reçue au moyen de la clé partagée (clé secrète dans le cas du chiffrement symétrique, clé privée du dispositif utilisateur dans le cas du chiffrement asymétrique). Ceci permet de garantir au dispositif utilisateur 10 que la notification a bien été préparée par le serveur applicatif 30. 35 Une troisième variante cumule les deux variantes précédentes. Plus précisément, le contenu du message de signalisation M3 et la notification M sont transmis de manière chiffrée. Cette troisième variante présente les avantages des deux variantes précédentes. 3051273 10 Dans le cas d'un chiffrement symétrique, dans un mode de réalisation particulier, la clé est déterminée par le dispositif utilisateur à partir de l'adresse de contact associée à l'application et d'un identifiant de l'application. On rappelle ici que l'adresse de contact associée à l'application correspond à l'adresse utilisée en tant qu'adresse de destination du message de signalisation M3 5 lors de l'étape E3. Plus précisément, la clé est déterminée en appliquant une fonction de hachage cryptographique, par exemple la fonction SHA-1 (pour « Secure Hash Algorithm »), de l'adresse de contact par l'identifiant d'application (ou inversement). Aucune limitation n'est attachée à cette fonction permettant de déterminer la clé, du moment que la fonction et ses paramètres sont connus aussi bien du dispositif utilisateur que du serveur applicatif. 10 Dans un mode de réalisation particulier, le dispositif utilisateur 10 fournit dans le message M1 un identifiant de l'application Id_A. Ceci permet au serveur de notification 40 d'identifier l'application qui va ensuite transmettre des notifications à destination du dispositif utilisateur. 15 La figure 3 représente un dispositif utilisateur 100 dans un mode particulier de réalisation. Le dispositif utilisateur 100 comprend notamment : - un processeur 101 pour exécuter des instructions de code de modules logiciels ; - une zone mémoire 102, agencée pour mémoriser une application qui comprend des instructions de code pour mettre en oeuvre les étapes du procédé d'authentification ; 20 - une mémoire de stockage, non représentée, agencée pour stocker des données utilisées lors de la mise en oeuvre du procédé d'authentification ; - un module d'interface 103 avec un réseau de communication, agencé pour émettre et recevoir des données ; - un module d'authentification 104, agencé pour exécuter une phase d'authentification lors du 25 démarrage de l'application ; - un module de signalisation 105, agencé pour envoyer un message de signalisation d'adresse origine un identifiant, dit identifiant principal, associé au dispositif par l'intermédiaire d'un module de sécurité 107 ; - un module de communication 106 avec un serveur de notification 40, agencé pour obtenir un 30 identifiant, dit identifiant secondaire, et pour recevoir des notifications relatives à l'application en étant adressé par l'identifiant secondaire ; - le module de sécurité 107, agencé pour mémoriser un identifiant principal Id_P. Le module d'authentification 104 est notamment agencé pour : - commander un envoi par le module de signalisation 105 d'un message de signalisation 35 comprenant un identifiant secondaire ; - extraire d'une notification relative à l'application reçue par le module de communication 106 l'identifiant principal et un authentifiant ; 3051273 11 - envoyer à un serveur applicatif 30 une demande d' authentification, ladite demande comprenant l'identifiant principal et l'authentifiant reçus, ledit dispositif étant authentifié par le serveur applicatif au moyen dudit identifiant principal en association avec ledit identifiant secondaire. Le module de signalisation 105 correspond dans un mode de réalisation particulier à un 5 module d'envoi et de réception de messages courts. Dans un mode de réalisation particulier, le dispositif utilisateur 100 comprend également un module de chiffrement. Le module d'authentification 104 demande au module de chiffrement de chiffrer l'identifiant secondaire au moyen d'une clé partagée avec le serveur applicatif et commande ensuite l'envoi de cet identifiant chiffré. 10 Dans un mode de réalisation particulier, le dispositif utilisateur 100 comprend également un module de déchiffrement. Le module d' authentification 104 demande au module de déchiffrement de déchiffrer l'identifiant principal et l'authentifiant compris dans une notification reçue au moyen d'une clé partagée avec le serveur applicatif. Dans un autre mode de réalisation particulier, le dispositif utilisateur 100 comprend un 15 module de chiffrement/déchiffrement. Les fonctions de ce module cumulent celles des modules correspondants dans les deux modes de réalisation précédemment décrits. Dans un mode de réalisation particulier, la clé de chiffrement et/ou de déchiffrement est déterminée par le module d'authentification 104 à partir d'une adresse de contact associée à l'application et d'un identifiant de l' application. 20 Dans un mode de réalisation particulier, le module de communication 106 est agencé pour requérir l'identifiant secondaire en fournissant un identifiant de l'application. Il est ici souligné que le dispositif utilisateur 100 comprend également d'autres modules de traitement, non représentés sur la figure 3, agencés pour mettre en oeuvre les différentes fonctions de dispositif utilisateur. 25 La figure 4 représente un serveur 30 mettant en oeuvre une application dans un mode particulier de réalisation. Le serveur, dit serveur applicatif, comprend notamment : - un processeur 300 pour exécuter des instructions de code de modules logiciels ; - une première zone mémoire 301, agencée pour mémoriser une application qui comprend des instructions de code pour mettre en oeuvre les étapes du procédé d' authentification ; 30 - une mémoire de stockage, non représentée, agencée pour stocker des données utilisées lors de la mise en oeuvre du procédé d'authentification ; - un module d'interface 302 avec un réseau de communication, agencé pour émettre et recevoir des données ; - un module d' authentification 303 ; 35 - un module de commande 304, agencé pour commander un envoi d'une notification relative à l'application, adressée au dispositif identifié par l'identifiant secondaire, ladite notification comprenant l'identifiant principal et un authentifiant attendu ; 3051273 12 - une deuxième zone mémoire 305, agencée pour mémoriser, pour un identifiant principal, un identifiant secondaire. Le module d'authentification 303 est notamment agencé pour : - obtenir une demande d'enregistrement d'un dispositif utilisateur 10, 11 au moyen d'un identifiant 5 principal et d'un identifiant secondaire, obtenus à partir d'un message de signalisation envoyé par le dispositif identifié par ledit identifiant principal, associé au dispositif par l'intermédiaire d'un module de sécurité, ledit message comprenant l'identifiant secondaire, obtenu par le dispositif pour recevoir des notifications relatives à l'application, - générer un authentifiant pour ledit dispositif, 10 - recevoir en provenance du dispositif ayant demandé à être enregistré une demande d' authentification, ladite demande comprenant l'identifiant principal et un authentifiant ; - authentifier le dispositif au moyen dudit identifiant principal en association avec ledit identifiant secondaire lorsque l'authentifiant reçu correspond à l'authentifiant attendu. Dans un mode de réalisation particulier, le serveur applicatif 30 comprend également un 15 module de signalisation agencé pour recevoir un message de signalisation envoyé par le dispositif identifié par un identifiant principal, associé au dispositif par l'intermédiaire d'un module de sécurité, ce message comprenant l'identifiant secondaire, obtenu par le dispositif pour recevoir des notifications relatives à l' application. Il est ici souligné que le serveur applicatif 30 comprend également d' autres modules de 20 traitement, non représentés sur la figure 4, agencés pour mettre en oeuvre les différentes fonctions de serveur. Aucune limitation n'est attachée à ces différents modes de réalisation et l'homme du métier est à même d'en définir d'autres en combinant une obtention d'un identifiant secondaire pour recevoir des notifications relatives à une application et une émission d'un message de 25 signalisation permettant à un serveur mettant en oeuvre l'application d'obtenir un identifiant principal. La technique d'authentification est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants 30 matériels et/ou logiciels, apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit précédemment pour le module concerné. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et 35 exécuté par un processeur de données d'une entité physique et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc). 3051273 13 De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou non, avec ou sans processeur intégré pour l'exécution de logiciel. Il s'agit par exemple d'un circuit intégré, d'une carte à puce, d'une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. 5 Dans un mode de réalisation particulier, les modules 104, 106 sont agencés pour mettre en oeuvre le procédé d'uathentification précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé d'authentification précédemment décrit, mises en oeuvre par un dispositif utilisateur. L'invention concerne donc aussi : 10 - un programme pour un dispositif utilisateur, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé d'authentification précédemment décrit, lorsque ledit programme est exécuté par ce dispositif utilisateur ; - un support d'enregistrement lisible par un dispositif utilisateur sur lequel est enregistré le programme pour un dispositif. 15 Dans un mode de réalisation particulier, les modules 303, 304 sont agencés pour mettre en oeuvre le procédé d'authentification précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé d'authentification précédemment décrit, mises en oeuvre par un serveur mettant en oeuvre une application. L'invention concerne donc aussi : 20 - un programme pour un serveur applicatif, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé d'authentification précédemment décrit, lorsque ledit programme est exécuté par ce serveur applicatif ; - un support d'enregistrement lisible par un serveur applicatif sur lequel est enregistré le programme pour un serveur. 25 Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication. REVENDICATIONS1. Procédé d'authentification d'un dispositif utilisateur (10, 11) auprès d'un serveur mettant en oeuvre une application, dit serveur applicatif (30), ledit procédé comprenant : - une obtention (E2) par le dispositif d'un identifiant, dit identifiant secondaire, permettant au dispositif de recevoir des notifications relatives à l'application : - un envoi (E3) par le dispositif, identifié par un identifiant, dit identifiant principal, associé au dispositif par l'intermédiaire d'un module de sécurité, d'un message de signalisation comprenant l'identifiant secondaire ; - une réception (E4) par ledit dispositif d'une notification relative à l'application adressée au dispositif identifié par l'identifiant secondaire, ladite notification comprenant l'identifiant principal et un authentifiant, et dont l'envoi a été commandé par le serveur applicatif ; - un envoi (E5) par ledit dispositif au serveur applicatif d'une demande d'authentification, ladite demande comprenant l'identifiant principal et l' authentifiant reçus, ledit dispositif étant authentifié par le serveur applicatif au moyen dudit identifiant principal en association avec ledit identifiant secondaire. 2. Procédé d'authentification selon la revendication 1, dans lequel l'identifiant secondaire compris dans le message de signalisation est chiffré au moyen d'une clé partagée avec le serveur applicatif. 3. Procédé d'authentification selon la revendication 1, dans lequel l'identifiant principal et l'authentifiant compris dans la notification sont déchiffrés au moyen d'une clé partagée avec le serveur applicatif. 4. Procédé d'authentification selon la revendication 2 ou 3, dans lequel la clé est déterminée par le dispositif à partir d'une adresse de contact associée à l'application et d'un identifiant de l' application. 5. Procédé d'authentification selon la revendication 1, dans lequel le dispositif requiert l'identifiant secondaire en fournissant un identifiant de l'application. 6. Procédé d'authentification d'un dispositif utilisateur (10, 11) auprès d'un serveur mettant en oeuvre une application, dit serveur applicatif (30), ledit procédé comprenant : - une obtention (G1) par le serveur applicatif d'une demande d'enregistrement dudit dispositif au moyen d'un identifiant principal et d'un identifiant secondaire, obtenus à partir d'un message de signalisation envoyé par le dispositif identifié par ledit identifiant principal, associé au dispositif 3051273 15 par l'intermédiaire d'un module de sécurité, ledit message comprenant l'identifiant secondaire, obtenu par le dispositif pour recevoir des notifications relatives à l'application : - une commande (G2) par le serveur applicatif d'un envoi d'une notification relative à l'application adressée au dispositif identifié par l'identifiant secondaire, ladite notification comprenant 5 l'identifiant principal et un authentifiant attendu ; - une réception (G3) par le serveur applicatif d'une demande d'authentification en provenance du dispositif, ladite demande comprenant l'identifiant principal et un authentifiant, ledit dispositif étant authentifié par le serveur applicatif au moyen dudit identifiant principal en association avec ledit identifiant secondaire lorsque l'authentifiant reçu correspond à l' authentifiant attendu. 10 7. Procédé d'authentification selon la revendication 6, dans lequel l'identifiant secondaire compris dans le message de signalisation est déchiffré au moyen d'une clé partagée avec le dispositif. 8. Procédé d'authentification selon la revendication 6, dans lequel l'identifiant principal et 15 l'authentifiant compris dans la notification sont chiffrés au moyen d'une clé partagée avec le dispositif. 9. Procédé d'authentification selon la revendication 7 ou 8, dans lequel la clé est déterminée par le serveur applicatif à partir d'une adresse de contact associée à l'application et d'un identifiant de 20 l' application. 10. Dispositif utilisateur (10, 11, 100) comprenant : - un module de communication (106) avec un serveur de notification (40), agencé pour obtenir un identifiant, dit identifiant secondaire, et pour recevoir des notifications relatives à l'application 25 adressées au dispositif identifié par l'identifiant secondaire : - un module de signalisation (105), agencé pour envoyer un message de signalisation comprenant un identifiant secondaire et d'adresse origine un identifiant, dit identifiant principal, associé au dispositif par l'intermédiaire d'un module de sécurité (107) ; - un module d'authentification (104), agencé pour extraire d'une notification relative à l'application 30 reçue l'identifiant principal et un authentifiant et pour envoyer à un serveur applicatif (30) une demande d' authentification, ladite demande comprenant l'identifiant principal et l'authentifiant reçus, ledit dispositif étant authentifié par le serveur applicatif au moyen dudit identifiant principal en association avec ledit identifiant secondaire. 35 11. Serveur mettant en oeuvre une application, dit serveur applicatif (30), ledit serveur comprenant : - un module d'authentification (303), agencé pour obtenir une demande d'enregistrement d'un dispositif utilisateur (10, 11) au moyen d'un identifiant principal et d'un identifiant secondaire, 3051273 16 obtenus à partir d'un message de signalisation envoyé par le dispositif identifié par ledit identifiant principal, associé au dispositif par l'intermédiaire d'un module de sécurité, ledit message comprenant l'identifiant secondaire, obtenu par le dispositif pour recevoir des notifications relatives à l'application, et pour générer un authentifiant pour ledit dispositif : 5 - un module de commande (304), agencé pour commander un envoi d'une notification relative à l'application, adressée au dispositif identifié par l'identifiant secondaire, ladite notification comprenant l'identifiant principal et un authentifiant attendu ; ledit module d' authentification étant en outre agencé pour recevoir en provenance du dispositif ayant demandé à être enregistré une demande d' authentification, ladite demande comprenant 10 l'identifiant principal et un authentifiant, ledit dispositif étant authentifié par le serveur applicatif au moyen dudit identifiant principal en association avec ledit identifiant secondaire lorsque l' authentifiant reçu correspond à l'authentifiant attendu. 12. Programme pour un dispositif utilisateur, comprenant des instructions de code de programme 15 destinées à commander l'exécution de celles des étapes du procédé d'authentification selon l'une des revendications 1 à 5 mises en oeuvre par le dispositif, lorsque ledit programme est exécuté par ledit dispositif. 13. Support d'enregistrement lisible par un dispositif utilisateur sur lequel est enregistré le 20 programme selon la revendication 12. 14. Programme pour un serveur applicatif, comprenant des instructions de code de programme destinées à commander l'exécution du procédé d'authentification selon l'une des revendications 6 à 9, lorsque ledit programme est exécuté par ledit serveur. 15. Support d'enregistrement lisible par un serveur applicatif sur lequel est enregistré le programme selon la revendication 14. 25 30