FR2943482A1 - Procede et systeme de securisation de demandes applicatives - Google Patents

Abstract

La présente invention vise à permettre une traçabilité des téléchargements des clients et de sécuriser les accès aux interfaces API des applications par l'authentification des éditeurs qui ont des droits sur ces API. L'opérateur peut alors contrôler qui utilise quoi et où, puis valider le fait que le client ayant téléchargé l'application est bien celui qui utilise l'application. Pour ce faire, la présente invention propose de stocker, vérifier, et utiliser l'ensemble des identifiants ou adresses des briques élémentaires du processus de demandes applicatives. Dans un procédé de sécurisation de demandes applicatives, une demande applicative est acheminée au Webservice d'un opérateur de télécommunications (4), et comprend une étape initiale de téléchargement par le client (2) auprès de l'éditeur (1). Selon l'invention, en liminaire de chaque étape d'utilisation de l'application, au moins l'un parmi des codes d'identification (IDediteur, IDclient), d'adresses réelle (URLappli) et virtuelle (URLvirt) de l'application (1a), respectivement pour l'éditeur (1) et le client (2), ainsi que de sécurisation temporels (DATElast, DATEdown) de l'application et relationnel unique (IDjeton) entre l'éditeur et le client, est demandé par l'opérateur pour des vérifications de cohérence et de conformité des codes d'identification, d'adresses et/ou de sécurisation, tant du client et de l'éditeur que de l'application.

Description

15 20 PROCEDE ET SYTEME DE SECURISATION DE DEMANDES APPLICATIVES L'invention se rapporte à un procédé de sécurisation de demandes applicatives, c'est-à-dire de demandes de connexion à une application gérée par un éditeur, ainsi qu'à un système de mise en oeuvre de ce procédé de sécurisation. 10 La présente invention concerne le domaine de la sécurisation des communications de données servant aux transactions entre deux équipements communicants différents, par exemple entre le téléphone mobile d'un client utilisateur et le réseau Internet d'un opérateur mobile.

La sécurisation des communications consiste à s'assurer que les applications téléchargées par le client utilisateur proviennent bien d'une source fiable, et qu'elles correspondent bien à la demande du client.

Nombreuses sont les méthodes actuelles de sécurisation des communications pour éviter, en particulier, les applications nuisibles crées ou modifiées pour détourner les services afin d'en extraire - sans autorisation - des informations confidentielles (vol de données, achats frauduleux, usurpation d'identité, ...). 25 II est par exemple connu du document de brevet WO 2004/062248 que l'interface de programmation d'une application de client (API), lorsqu'il existe un besoin de paiement, de localisation, ou de modification de données, se connecte à un serveur distant et lui envoie les informations nécessaires (identifiant de l'application demandée, date d'accès, mot de 3o passe, etc.). Le serveur reçoit ces informations et les compare avec une table d'autorisation contenant la liste des applications, leur niveau de sécurité, à savoir : détail des données auxquelles les applications ont accès, et détail sur la possibilité de modification de ces données par les applications. Il est aussi connu du document de brevet US2007204044 que 35 le serveur distant analyse la demande reçue de l'équipement communiquant d'un client pour vérifier la présence d'un jeton de sécurité. Si ce jeton n'est pas trouvé, le serveur distant re-route le client vers une page d'authentification où le client doit renseigner son identifiant et son mot de passe. Après identification correcte du client, son équipement communiquant reçoit un nouveau jeton de 40 sécurité, et les transactions demandées par le client peuvent s'effectuer. 20 Cependant, ces méthodes ne permettent pas de vérifier si l'application et l'éditeur de l'application sont autorisés - afin d'éviter des diffusions d'applications nuisibles - ni de surveiller toute utilisation anormale de l'application, par exemple une demande de souscription de services toutes les secondes. En particulier ces documents ne permettent pas de vérifier si l'utilisateur a souscrit une application qui aurait usurpé une autre identité. Ces inconvénients ont comme conséquence de permettre à un site mal intentionné, ~o qui héberge une application nuisible, de distribuer - par le téléchargement demandé par les clients - des applications déguisées qui permettent de récupérer auprès des clients des informations secrètes ou de déclencher des actes d'achat contre leur gré. Il est ainsi utile de garantir à un éditeur que son application piratée ne sera pas fonctionnelle si elle est distribuée par un site 15 indélicat.

La présente invention vise à pallier les inconvénients ci-dessus de l'état de la technique dans le domaine de la sécurisation de demandes applicatives, en palliant au moins aux risques connus de piratage. Pour ce faire, la présente invention propose de stocker, vérifier, et utiliser l'ensemble des identifiants ou adresses des briques élémentaires du processus de demandes applicatives.

25 Plus précisément, la présente invention a pour objet un procédé de sécurisation de demandes applicatives entre un client et un éditeur d'application, une demande applicative étant acheminée au Webservice d'un opérateur de télécommunications selon une étape initiale de téléchargement par le client auprès de l'éditeur En liminaire de chaque étape d'utilisation de 3o l'application, au moins l'un parmi des codes d'identification (IDediteur, IDclient), d'adresses réelle (URLappli) et virtuelle (URLvirt) de l'application, respectivement pour l'éditeur et le client, ainsi que de sécurisation temporels (DATEIast, DATEdown) de l'application et relationnel unique (IDjeton) entre l'éditeur et le client, est demandé par l'opérateur pour des vérifications de 35 cohérence et de conformité des codes d'identification, d'adresses et/ou de sécurisation, tant du client et de l'éditeur que de l'application. II est ainsi vérifié qu'une application utilisée par le client est l'application délivrée par l'éditeur, que l'utilisation de l'application par le client 15 20 est conforme à des normes prédéfinies et que la date de téléchargement de l'application ne soit pas périmée. Selon des modes de mise en oeuvre particuliers : - l'opérateur compare le code identifiant de l'application demandée par le client au code identifiant de cette application qu'il stocke lui-même, afin de vérifier que le client demande une application référencée par l'opérateur ; cette identification permet de vérifier que l'utilisateur a bien téléchargé cette application ; - l'opérateur compare le code de date de la demande actuelle ~o d'utilisation de l'application par le client, au code de date de la dernière utilisation de l'application par le client, pour vérifier la conformité de l'utilisation de l'application par le client à une norme prédéfinie ; la conformité peut être une date de téléchargement récente et une date de dernière utilisation non renseignée ; - l'opérateur compare un jeton présenté par le client pour demander l'utilisation de l'application au jeton de sécurisation temporel unique référencé par l'opérateur, pour vérifier que la demande de connexion par une application initiée par le client provient bien de l'application téléchargée par le client et non pas d'une application nuisible ; - une détection d'anormalité entraîne le renvoi par le Webservice de l'opérateur au client d'un message d'erreur et redirige le client vers l'adresse virtuelle de l'application pour un nouveau téléchargement.

L'invention concerne également un système de mise en oeuvre 25 du procédé défini ci-dessus. Un tel système comporte un équipement de service réseau ou Webservice d'un opérateur incorporant un registre de stockage de codes d'identification et d'adresses d'une application d'un éditeur, ainsi qu'un registre de stockage de codes de sécurisation concernant l'utilisation de l'application par le client. 30 Selon un mode particulier, les identifiants éditeur et client sont stockés dans des registres distincts des registres de stockage des codes.

Cette infrastructure permet de tracer les téléchargements des clients et de sécuriser les accès aux API par l'authentification des éditeurs qui ont des droits sur ces API. L'opérateur peut ainsi contrôler finement qui télécharge quoi et où. H peut alors gérer les éditeurs et les clients, puis valider le fait que le client ayant téléchargé l'application est bien celui qui utilise l'application. 15 20 Toute opération concernant les instructions de mise en place d'applications entre éditeurs et clients étant contrôlée par l'opérateur, celui-ci devient garant de la sécurité. Le processus est ainsi rendu plus simple pour l'éditeur : cette méthode n'est pas un frein pour l'éditeur au développement d'applications mobiles.

Dans ces conditions, si un éditeur indélicat est détecté, il est possible de bloquer les appels au WebService de toutes ses applications en to éliminant tous les identifiants d'application lui appartenant. Si certains clients utilisent abusivement le WebService (utilisation anormale détectée), il est alors possible de permettre à l'opérateur de ne plus leur fournir de code unique de jeton et de forcer le téléchargement selon une mise à jour.

D'autres caractéristiques et avantages de l'invention ressortiront à la lecture qui suit d'exemples de réalisation détaillés, en référence aux figures, qui représentent respectivement : - la figure 1, le schéma d'un exemple de création d'un compte éditeur en liaison avec un registre d'une application à télécharger ; - la figure 2, le schéma d'un exemple de création dans le webservice d'un opérateur d'un compte client en liaison avec un registre client dans un système selon l'invention, suivi du téléchargement de l'application par le client ; - la figure 3, un schéma d'exemples d'utilisation de 25 l'application par le client dans le système selon l'invention, et - la figure 4, un exemple de fonctionnement du système selon l'invention lors de l'utilisation d'une application nuisible. Le schéma de la figure 1 illustre un exemple de relations entre 3o l'éditeur 1 et les services fournis par le réseau de l'opérateur 4 (appelé Webservice), au cours d'étapes de référencement de l'éditeur 1 et de son application la auprès du webservice 4. Dans une première étape, l'éditeur 1 lorsqu'il n'est pas encore 3s référencé auprès de l'opérateur 4, crée un compte auprès du Webservice de l'opérateur 4. L'opérateur crée alors un identifiant pour l'éditeur 1, appelé IDediteur , dans un registre 14 et en informe l'éditeur 1 suivant la voie de communication 6. L'éditeur 1 fournit à l'opérateur 4 pour cette application la une URL (adresse Internet) de téléchargement URLappli , suivant la voie de communication 8 afin de permettre le téléchargement ultérieur auprès de clients. L'URL de téléchargement URLappli est renseignée dans un registre d'application 18 du Webservice 4. L'opérateur 4 crée alors, pour cette application la, une URL virtuelle nommée URLVirt , stockée également dans le registre d'application io 18, et communiquée à l'éditeur 1 suivant la voie de communication 6. Cette adresse virtuelle pourra être utilisée provisoirement par le client 2 dans une phase transitoire. L'opérateur 4 crée également, pour cette application 1 a, un identifiant unique d'application IDappli , stocké dans le registre d'application 15 18, et communiqué à l'éditeur 1 selon la voie 6. Le client 2 est identifié dans un registre 16 du Webservice 4 et des informations concernant l'utilisation de l'application la par ce client seront stockées dans un registre 20. Les informations qui seront renseignés dans ce registre concernent trois informations relatives à la relation clientùapplication 20 (identifiant de l'application et dates de téléchargement et de dernière utilisation) et une information de sécurisation de l'accès à l'application sous la forme d'un jeton dans l'exemple illustré.

Le schéma de la figure 2 montre un exemple de relations entre 25 l'éditeur 1, le client utilisateur 2 et l'opérateur de Webservice 4, au cours du téléchargement initial de l'application 1 par le client 2. L'éditeur 1 communique d'abord à tous ses clients 2 l'URL virtuelle URLvirt de l'application 1 a, selon la voie d'information 22. Le client 2 s'adresse alors à l'opérateur 4, selon la voie de 3o communication 12, et se fait connaître par son identifiant client IDclient non falsifiable, que l'opérateur reconnaît dans son registre 16. Cet identifiant est par exemple un code infalsifiable de l'équipement du client 2: MSISDN ( Mobile Subscriber ISDN : numéro d'abonné mobile sur réseau RNIS), adresse MAC modem, etc. Le client 2 s'adresse ensuite à l'opérateur 4 selon la voie de communication 12 pour télécharger l'application la, et lui demande à être connecté à l'URL virtuelle URLvirt renseignée dans le registre 18 de l'opérateur 4. 20 25 3o Pour l'identifiant client IDclient 16, l'opérateur 4 note les informations suivantes dans le registre client 20 : l'identifiant de l'application demandée IDappli et la date de téléchargement Datedown . Le client 2 est 5 alors redirigé par l'opérateur 4 vers I'URL réelle URLappli de l'application la, cette URL ayant été renseignée dans le registre 18.

Le client télécharge alors une version client 1 b de l'application la, selon la voie de communication 22.

Le schéma de la figure 3 illustre un exemple de relations qui s'établissent entre l'éditeur 1, le client 2 et l'opérateur de Webservice 4, au cours des différentes étapes d'utilisation de l'application la par le client 2. La succession d'étapes est adaptée au cas d'une première utilisation de 15 l'application la, d'une utilisation ultérieure ou d'une utilisation anormale de l'application la.

Dans le cadre de la toute première utilisation de l'application la par le client, les étapes sont les suivantes : - d'abord, le client 2 s'identifie par son identifiant client IDclient 16 - ensuite, l'application client 1 b interroge le Webservice de l'opérateur 4, selon la voie de communication d'informations 12, en lui fournissant l'identification de l'application stockée dans le registre 20 ; - l'opérateur 4 analyse alors, pour l'identifiant client 16, l'information DATEdown qu'il a renseigné précédemment en son registre 20, pour vérifier si la date de téléchargement n'est pas périmée (le paramétrage initial de la date de péremption est fourni par l'éditeur 1 ou l'opérateur 4) ; - le client demande l'adresse URL du Webservice d'accès aux services de l'opérateur 4, selon la voie de communication 12 ; - l'opérateur 4 constate, du fait qu'il s'agit d'une première utilisation, qu'il n'a pas renseigné en son registre 20 de date de dernier accès à l'application DATElast ni d'information de sécurité sous forme de jeton IDjeton ; - pour l'identifiant client 16, l'opérateur renseigne alors ces données dans son registre 20 : la date DATElast se rapportant à la date de demande d'accès par cette application client 1 b au Webservice de l'opérateur 4, ainsi qu'un jeton IDjeton ; - le client 2 ayant demandé l'exécution du service de l'opérateur 4 reçoit le résultat du service demandé selon la voie 10 ; - le jeton IDjeton est communiqué par l'opérateur 4 au client 2, selon la voie 10.

Dans le cadre d'une quelconque utilisation ultérieure de l'application client lb, les étapes suivantes se succèdent. io Le client 2 s'identifie auprès de l'opérateur 4 par son identifiant client IDclient 16. L'application client lb interroge alors le Webservice ou services de l'opérateur 4, selon la voie de communication 12, en lui fournissant l'identification IDappli de l'application, et le jeton IDjeton que l'opérateur 15 4 lui a précédemment communiqué. L'opérateur 4 analyse ensuite, pour l'identifiant client IDclient 16, les informations suivantes dans son registre 20: o l'information DATEdown : pour vérifier si la date de téléchargement de l'application indique que la version de l'application est toujours valide (paramétrage initial de date de péremption à saisir par l'éditeur 20 1 ou opérateur 4) ; o la date du dernier accès DATElast au Webservice 4, pour cette application client lb : pour vérifier si cette date n'est pas trop récente, auquel cas il s'agirait d'une utilisation anormale (voir ci-après) ; o la comparaison du jeton IDjeton renseigné en son 25 registre 20 avec celui fourni par l'application client 1 b : si ces deux jetons ne sont pas identiques, il s'agit alors d'une application client nuisible et non de l'application prévue 1 b, qui tente de se connecter. Si les conditions d'utilisation ne sont pas hors norme, et s'il ne s'agit pas d'une application client nuisible, le client ayant demandé l'accès au 3o WebService de l'opérateur reçoit en retour le résultat de sa demande par la voie 10. Enfin, l'opérateur 4 met à jour et mémorise, dans le registre 20, la date DATElast de dernier accès de l'application client 1 b et un nouveau jeton IDjeton. Le nouveau jeton IDjeton est en outre communiqué par l'opérateur 4 au client 2, par la voie 10.

Le cas particulier d'une utilisation anormale de l'application la est décrit ci-après. Comme précédemment, l'identification du client 2 auprès de l'opérateur 4 est réalisée par son identifiant client IDclient 16. L'identification IDappli de l'application client 1b demandée par le Webservice de l'opérateur 4 est fournie par la voie d'information 12, accompagnée du jeton IDjeton que l'opérateur 4 lui a précédemment communiqué. Le Webservice 4 analyse pour l'identifiant client 16, les informations suivantes renseignées dans son registre 20:

o l'information de téléchargement DATEdown , o la date du dernier accès DATElast au Webservice de io l'opérateur 4, par l'application client 1 b, o la comparaison du jeton IDjeton renseigné dans son registre 20 avec celui fourni par l'application client 1 b. Une situation anormale existe lorsque l'identification client IDclient est reconnue, le jeton IDjeton présenté par le client 2 est identique à is celui renseigné dans le registre 20 de l'opérateur, mais certaines données sortent de norme d'utilisation définies préalablement, par exemple : date de dernier accès trop proche, statistiques d'utilisation montrant un usage incorrect de l'application, ou date de téléchargement d'application périmée. Dans le cas d'une utilisation anormale de l'application la, le 20 Webservice de l'opérateur 4 renvoie alors au client 2 un message d'erreur, selon le sens d'information 10, et redirige le client, qui demande a priori l'exécution d'un WebService, vers l'adresse virtuelle de l'application pour un nouveau téléchargement, sans émission d'un nouveau jeton.

25 Le schéma de la figure 4 illustre un exemple de relations entre l'éditeur 1, le client 2, et l'opérateur de Webservices 4, dans le cas d'une application nuisible. Par la voie de communication 12, le client 2 s'est identifié auprès de l'opérateur 4 par son identifiant client IDclient 16. Une application 3o nuisible X demande à utiliser le WebService de l'opérateur 4, en fournissant un identifiant d'application existant 1 b ou fictif X. L'application nuisible X fournit parfois également un jeton. L'opérateur 4 traite ce cas comme une anomalie lorsqu'il constate : - une absence de correspondance chez l'opérateur 4 entre ce client 2 et l'identification de l'application IDappli demandé par l'application nuisible X, - une identification d'application IDappli inconnu 35 - un jeton absent ou incorrect, c'est-à-dire non identique à celui renseigné dans le registre 20 de l'opérateur 4.

Le Webservice 4 renvoie alors au client 2 un message d'erreur, s par la voie de communication 10, et redirige le client, qui demandait a priori l'utilisation du WebService, vers l'adresse virtuelle de l'application pour un nouveau téléchargement, sans émission d'un nouveau jeton.

L'invention n'est pas limitée aux exemples de réalisation décrits ~o et représentés. Il est également possible de prévoir une architecture logicielle de l'opérateur pour plusieurs applications pour le même éditeur, et plusieurs applications utilisées par le même client. II est possible d'alerter, d'informer ou de confirmer par SMS au client l'usage d'un WebService pour certaines actions sensibles comme l'achat 15 ou la souscription. II est également possible de d'informer ou de confirmer le téléchargement de l'application la par SMS afin d'éveiller les soupçons du client en cas de téléchargement à son insu. II est aussi possible, pour éviter les mécanismes de 20 téléchargements masqués et factices visant à débloquer l'accès au Webservice de l'opérateur, de demander une confirmation manuelle du téléchargement de l'application la via la saisie d'un code ou d'un mécanisme de reconnaissance faisant intervenir l'humain ( captcha ,...). Si un éditeur indélicat est détecté, il est possible de bloquer les 25 appels au WebService de toutes ses applications en éliminant tous les identifiants d'applications lui appartenant. De même, si la sollicitation de l'utilisateur est nécessaire, l'opérateur peut envisager l'usage de codages particuliers (captcha) empêchant l'utilisation de l'application par des robots malfaisants, par exemple demander à 3o l'utilisateur de répondre à une question simple (par exemple : combien font trois plus cinq, répondez par chiffre), de renvoyer les lettres contenues dans une image déformée ou de décrypter par écrit une phrase contenue dans un message sonore. L'invention peut aussi s'appliquer au réseau fixe, dans le cas 3 de la demande de connexion d'un ordinateur à une application via une connexion à Internet par ADSL, Wifi, ou câble.

Claims (9)

1. REVENDICATIONS1. Procédé de sécurisation de demandes applicatives entre un client (2), un éditeur (1) d'une application (la), une demande applicative étant acheminée au Webservice d'un opérateur de télécommunications (4), comprenant une étape initiale de téléchargement par le client auprès de l'éditeur et caractérisé en ce qu'en liminaire de chaque étape d'utilisation de to l'application, au moins l'un parmi des codes d'identification (IDediteur, IDclient), d'adresses réelle (URLappli) et virtuelle (URLvirt) de l'application (la), respectivement pour l'éditeur (1) et le client (2), ainsi que de sécurisation temporels (DATEIast, DATEdown) de l'application et relationnel unique (IDjeton) entre l'éditeur et le client, est demandé par l'opérateur (4) pour des ts vérifications de cohérence et de conformité des codes d'identification, d'adresses et/ou de sécurisation, tant du client et de l'éditeur que de l'application.
2. 2. Procédé de sécurisation selon la revendication 1 dans 20 lequel l'utilisation de l'application par le client est conforme à des normes prédéfinies incluant des dates de téléchargement de l'application non périmées.
3. 3. Procédé de sécurisation selon la revendication 1 ou 2, 25 dans lequel l'opérateur (4) compare le code identifiant (IDappli) de l'application demandé par le client (2) avec le code identifiant de cette application qu'il stocke lui-même (2), afin de vérifier que le client (2) demande bien une application (la) référencée par l'opérateur (4). 3o
4. 4. Procédé de sécurisation selon l'une quelconque des revendications 1 à 3, dans lequel l'opérateur (4) compare le code de date de la demande actuelle d'utilisation de l'application (la) par le client (2), au code (DATEIast) de date de la dernière utilisation de l'application (1a) par le client (2), pour vérifier la conformité de l'utilisation de l'application (1a) par le client (2) à une norme définie précédemment.Il
5. 5. Procédé de sécurisation selon la revendication précédente, dans lequel la conformité peut être une date de téléchargement récente (DATEdown) et une date de dernière utilisation (DATEIast) non renseignée.
6. 6. Procédé de sécurisation selon l'une quelconque des revendications précédentes, dans lequel l'opérateur (4) compare un jeton présenté par le client (2) pour demander l'utilisation de l'application (la) au jeton unique de sécurisation relationnel (IDjeton) référencé par l'opérateur (4), l o pour vérifier que la demande de connexion à l'application (la) par le client provient bien de l'application (1 b) téléchargée par le client (2) et non pas d'une application nuisible.
7. 7. Procédé de sécurisation selon l'une quelconque des 15 revendications précédentes, dans lequel une détection d'anormalité entraîne le renvoi par le Webservice de l'opérateur (4) au client (2) d'un message d'erreur (10) et redirige le client (2) vers l'adresse virtuelle de l'application (la) pour un nouveau téléchargement. 20
8. 8. Système de sécurisation de mise en oeuvre du procédé selon l'une quelconque des revendications précédentes, comportant un équipement de service Webservice (4) d'un opérateur incorporant un registre de stockage (18) de codes d'identification et d'adresses (IDappli, URLappli, URLvirt) de l'application (la) de l'éditeur (1), ainsi qu'un registre de stockage 25 (20) de codes de sécurisation (IDappli, DATEIast, DATEdown, IDjeton) concernant l'utilisation de l'application (la) par le client (2).
9. 9. Système de sécurisation selon la revendication précédente, dans lequel les identifiants éditeur (IDediteur) et client (IDclient) 3o sont stockés dans des registres (14, 16) distincts des registres de stockage des codes (18, 20).