DOMAINE TECHNIQUE GENERAL

La présente invention concerne le domaine de l'authentification via terminal mobile. Plus précisément, elle concerne un procédé pour récupérer des données personnelles d'un utilisateur en vue de renseigner un service en ligne. ETAT DE L'ART

La technologie « Mobile Connect », développée par le Demandeur vise à permettre l'authentification d'un utilisateur auprès d'un service en ligne via un terminal mobile.

Plus précisément, au lieu d'entrer un couple login/mot de passe sur un portail d'un service en ligne (une page web), l'utilisateur sélectionne l'option MC (Mobile Connect) et il est simplement demandé de saisir simplement un identifiant personnel (qui peut être son numéro de téléphone ou un « alias » anonymisé).

Le service en ligne requiert alors, éventuellement via une plateforme API (Application Programming Interface, i.e. interface de programmation applicative), auprès d'un serveur MC de l'opérateur téléphonique de l'utilisateur les informations personnelles associées (en l'espèce le login et le mot de passe).

Le serveur MC, avant d'interroger une base de données stockant de manière cryptée les informations personnelles des utilisateurs de sorte à retourner celles demandées, envoie vers le terminal mobile de l'utilisateur une requête de validation. Une application MC s'ouvre sur le terminal mobile et invite l'utilisateur à accepter la requête. Si oui, le serveur MC retourne les informations personnelles demandées de sorte à permettre l'accès de l'utilisateur au service.

La demande brevet EP2629553 décrit un tel mécanisme d'authentification via terminal mobile.

Cette technologie apporte satisfaction, car elle évite à l'utilisateur la nécessité de retenir des dizaines de mots de passe aux différents services en ligne. Une solution était d'utiliser le même mot de passe partout, ce qui pouvait s'avérer risqué si l'un des services présentait une faille. La technologie Mobile Connect améliore ainsi in fine la sécurité en ligne. Aujourd'hui la validation utilisateur au niveau de l'application MC est simplement un « OK » de la part de l'utilisateur, c'est-à-dire l'appui sur une touche dans un délai prédéterminé.

Il serait possible de modifier l'application pour prévoir un niveau de sécurité supplémentaire pour authentifier l'utilisateur (de sorte à éviter qu'un tiers mal intentionné ayant volé le terminal mobile ne fasse l'opération), par exemple en requérant la saisie du code PIN par l'utilisateur, voire en posant une question secrète ou encore en exigeant une identification biométrique (de nombreux terminaux mobiles ont un lecteur d'empreintes digitales), et même une combinaison de plusieurs mécanismes d'authentification.

Cela pourrait s'avérer souhaitable pour l'accès à des services en ligne

« sensibles » (par exemple bancaires), mais inutilement lourd dans d'autre cas où cela freinerait tout intérêt pour la technologie qui vise avant tout à simplifier la vie de l'utilisateur.

Par ailleurs la notion de « sensibilité » d'un service est subjective : pour un utilisateur, la sécurité d'un service en ligne donné peut être critique, et pour un autre utilisateur la flexibilité peut primer.

Il serait par conséquent souhaitable de disposer d'un mécanisme astucieux permettant à l'utilisateur de trouver un compromis entre sécurité et flexibilité, et ce sans sacrifier à la sécurité globale de la technologie d'authentification via mobile.

PRESENTATION DE L'INVENTION

La présente invention se rapporte ainsi selon un premier aspect à un procédé pour renseigner des informations personnelles d'un utilisateur demandées par un service en ligne donné, le procédé comprenant la mise en œuvre par un module de traitement de données d'un serveur de sécurité d'un opérateur d'un terminal mobile de l'utilisateur d'étapes de :

(a) réception d'une requête desdites informations personnelles de l'utilisateur, comprenant un identifiant unique de l'utilisateur et un identifiant dudit service en ligne donné ;

(b) émission à destination dudit terminal mobile de l'utilisateur d'une requête d'autorisation de réponse à ladite requête desdites informations personnelles de l'utilisateur ;

(c) Si réception d'une confirmation d'autorisation de réponse depuis ledit terminal mobile, émission en réponse à la requête desdites informations personnelles de l'utilisateur de données associées auxdits identifiant unique de l'utilisateur et identifiant dudit service en ligne donné dans une base de données stockée dans un module de stockage de données ;

Caractérisé en ce que chaque couple d'un identifiant unique et d'un identifiant d'un service en ligne est également associé dans ladite base de données à un paramètre représentatif d'un niveau de sécurité requis pour confirmer l'autorisation de réponse sur ledit terminal mobile, l'étape (b) comprenant :

la détermination de la valeur dudit paramètre associée dans ladite base de données auxdits identifiant unique de l'utilisateur et identifiant dudit service en ligne donné ; et

- l'intégration de la valeur déterminée du paramètre dans ladite requête d'autorisation de réponse à ladite requête desdites informations personnelles de l'utilisateur.

L'utilisation d'un paramètre dédié pour fixer un niveau de sécurité permet à l'utilisateur lui-même de définir service par service et la carte les procédures de validation qu'il souhaite mettre en œuvre pour autoriser le renseignement d'informations, de sorte à ajuster au mieux sécurité et flexibilité.

Selon d'autres caractéristiques avantageuses et non limitatives :

· la valeur dudit paramètre représentatif d'un niveau de sécurité est choisie parmi une liste prédéterminée et hiérarchisée de valeurs de niveaux de sécurité.

• ladite liste prédéterminée comprend au moins un premier niveau de sécurité dans lequel une manipulation d'une interface du terminal mobile suffit à confirmer l'autorisation de réponse ; et un deuxième niveau de sécurité dans lequel la saisie d'un code d'authentification sur une interface du terminal mobile est nécessaire à confirmer l'autorisation de réponse ;

• le procédé comprend une étape préalable de :

réception depuis le terminal mobile (1 ) d'une requête de modification de la valeur dudit paramètre, comprenant l'identifiant unique de l'utilisateur, l'identifiant dudit service en ligne donné et la valeur modifiée dudit paramètre ;

remplacement dans ladite base de la valeur du paramètre associée auxdits identifiant unique de l'utilisateur et identifiant dudit service en ligne donné, par ladite valeur modifiée.

• ledit service en ligne donné est hébergé par un serveur tiers connecté au serveur de sécurité via le réseau internet ; • l'étape (a) comprend une demande par le serveur tiers auprès d'une plateforme API également connectée au réseau Internet, de renseignement desdites informations personnelles de l'utilisateur, ladite plateforme API générant ladite requête desdites informations personnelles de l'utilisateur ;

• ladite demande par le serveur tiers auprès d'une plateforme API de renseignement desdites informations personnelles de l'utilisateur est émise sur instructions de l'utilisateur au niveau d'un équipement via lequel l'utilisateur cherche à accéder audit service en ligne.

• Le procédé comprend une étape préalable de :

réception depuis le serveur tiers d'une requête de modification de la valeur dudit paramètre, comprenant l'identifiant dudit service en ligne donné et la valeur modifiée dudit paramètre ;

remplacement dans ladite base de la valeur du paramètre associée à chaque combinaison d'un identifiant unique et de l'identifiant dudit service en ligne donné, par ladite valeur modifiée.

• le remplacement n'est mis en œuvre que si la valeur modifiée de paramètre correspond à un niveau de sécurité supérieur à la valeur initiale ;

• à l'issue de l'étape (b), le terminal mobile émet en réponse à la requête d'autorisation de réponse la confirmation d'autorisation de réponse si l'utilisateur met en œuvre une procédure de validation dépendante de ladite valeur dudit paramètre.

Selon un deuxième aspect, l'invention concerne un serveur de sécurité pour renseigner des informations personnelles d'un utilisateur demandées par un service en ligne donné, l'utilisateur disposant d'un terminal mobile d'un opérateur le procédé comprenant la mise en œuvre par un module de traitement de données du serveur de :

Un module de réception d'une requête desdites informations personnelles de l'utilisateur, comprenant un identifiant unique de l'utilisateur et un identifiant dudit service en ligne donné, des couples d'un identifiant unique et d'un identifiant d'un service en ligne étant associés, dans une base de données stockée dans un module de stockage de données, d'une part à des informations personnelles et d'autre part à un paramètre représentatif d'un niveau de sécurité requis pour confirmer une autorisation de réponse sur ledit terminal mobile ;

Un module de détermination de la valeur dudit paramètre associée dans ladite base de données auxdits identifiant unique de l'utilisateur et identifiant dudit service en ligne donné ;

Un module d'émission à destination dudit terminal mobile de l'utilisateur d'une requête d'autorisation de réponse à ladite requête desdites informations personnelles de l'utilisateur, la valeur déterminée du paramètre étant intégrée dans ladite requête d'autorisation de réponse ;

un module d'émission en réponse à la requête desdites informations personnelles de l'utilisateur, si réception d'une confirmation d'autorisation de réponse depuis ledit terminal mobile, de données associées auxdits identifiant unique de l'utilisateur et identifiant dudit service en ligne donné dans ladite base de données.

Selon une troisième aspect est proposé un système comprenant un serveur de sécurité selon le deuxième aspect et un terminal mobile configuré pour mettre en œuvre un module d'émission en réponse à la requête d'autorisation de réponse de la confirmation d'autorisation de réponse si l'utilisateur met en œuvre une procédure de validation dépendante de ladite valeur dudit paramètre.

Selon un quatrième aspect, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon le premier aspect de l'invention pour renseigner des informations personnelles d'un utilisateur demandées par un service en ligne donné.

Selon un cinquième aspect, l'invention concerne un moyen de stockage lisible par un équipement informatique sur lequel on trouve ce produit programme d'ordinateur.

PRESENTATION DES FIGURES

D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence à la figure unique annexée qui est un schéma d'une architecture générale de réseau pour la mise en œuvre de l'invention.

DESCRIPTION DETAILLEE Architecture

En référence à la figure 1 , l'invention propose un procédé pour renseigner des informations personnelles d'un utilisateur demandées par un service en ligne donné.

En d'autres termes, on comprendra que le service en ligne demande des informations personnelles de l'utilisateur (typiquement des champs à compléter) qui peuvent être de nature variées : de façon préférée ces informations comprennent un login et/ou un mot de passe de l'utilisateur pour ce service en ligne, mais il peut s'agir par exemple de renseigner automatiquement dans un formulaire l'adresse de l'utilisateur, sa date de naissance, etc.

Par service en ligne, on entend n'importe quel service tiers que l'utilisateur souhaite utiliser, typiquement via un portail web affiché sur un équipement informatique 3 de l'utilisateur (tel qu'un PC connecté au réseau internet 20) au niveau duquel la saisie des informations personnelles est demandée. On notera que l'équipement 3 peut être confondu avec le terminal mobile 1 qui va être décrit plus loin. A titre d'exemple, on citera une banque en ligne, un site de e-commerce, un service administratif, un forum, un jeu en réseau, etc.

Le service en ligne est typiquement hébergé par un serveur 4 connecté au réseau 20. On note que plusieurs services en lignes peuvent être impliqués dans le présent procédé.

Comme dans la technologie Mobile Connect connue, au moins un serveur de sécurité 2 est également connecté au réseau 20. Comme l'on verra c'est un serveur d'un opérateur d'un terminal mobile 1 de l'utilisateur. Il comprend un module de traitement de données 21 , par exemple un processeur, et un module de stockage de données 22 tel qu'un disque dur, stockant une base de données dans laquelle on trouve lesdites données personnelles, en particulier les données personnelles d'une pluralité d'utilisateurs (partageant le même opérateur de téléphonie mobile) pour une pluralité de services en ligne. On verra la structure de cette base de données plus loin.

On note que le module de stockage de données 22 peut être distincte du serveur 2 et seulement connectée à ce dernier via le réseau. Elle peut également être pas être une base unique mais être répartie entre divers équipements. Dans tous les cas la base de données est préférentiellement cryptée et sous le contrôle du serveur 2 de sorte à éviter des failles de sécurité.

Une plateforme API 5 est de façon préférée également connectée au réseau 20. Selon un mode de réalisation préférée elle est confondue avec le serveur de sécurité 2. On comprendra qu'elle peut également être intégrée à un serveur hébergeant le service en ligne

Cette plateforme API 5 fait le lien entre les serveurs des services en ligne et le serveur de sécurité 2. Plus précisément, en cas de demande d'informations personnelles de la part d'un service en ligne, elle est capable d'identifier (en fonction de l'opérateur) et d'activer le serveur 2 via la génération d'une requête adéquate. Similairement, en cas de fourniture des informations personnelles en réponse par le serveur 2, elle est capable de « renseigner » le service en ligne en simulant la saisie de ces informations par l'utilisateur sur l'interface du service en ligne.

Enfin, l'utilisateur est muni d'un terminal mobile 1 qui peut être de n'importe quel type, en particulier smartphone ou des tablettes tactiles. Il comprend un module de traitement de données (un processeur), avantageusement un module de stockage de données 12, et une interface utilisateur (IHM) comprenant par exemple des moyens de saisie et des moyens d'affichage (par exemple un écran tactile, on verra plus loin d'autres alternatives).

Le terminal mobile 1 est avantageusement connecté à un réseau de communication mobile 10, lui-même connecté au réseau Internet 20. A noter que le terminal mobile 1 peut être directement connecté au réseau Internet 20, par exemple en Wi-Fi.

Le module de traitement de données du terminal 1 est adaptée pour mettre en œuvre une application (du type de l'application MC évoquée ci-avant pour la validation d'autorisations de fournitures d'informations personnelles), dont on verra plus loin le fonctionnement plus en détail.

De façon préférée, le terminal 1 comprend en outre un élément de sécurité. Il s'agit d'un élément adapté pour autoriser une connexion du terminal 1 à un réseau de communication mobile, en particulier une carte d'identification d'abonné. Par « carte d'identification d'abonné », on entend tout circuit intégré capable d'assurer les fonctions d'identification d'un abonné à un réseau via des données qui y sont stockées, et tout particulièrement une carte « SIM » (de l'anglais « Subscriber Identity Module »), ou une carte « e-UICC » (pour « (embedded)-Universal Integrated Circuit Card ») comprenant des moyens de traitement de données sous la forme d'un microcontrôleur et de la mémoire de type « EEPROM » (pour « Electrically-Erasable Programmable Read-Only Memory »), ou flash. Dans un autre exemple de réalisation, le module de sécurité 12 est une zone mémoire sécurisée du terminal mobile tel un composant « TEE » (de l'anglais « Trusted Execution Environment ») embarqué dans le module de traitement de données, ou un élément matériel dédié du terminal 1 (par exemple un microcontrôleur, une puce « eSE » pour « (embedded)-Secure Elément » ou n'importe quel « Secure Component GP (GlobalPIatform) »), voire un composant amovible de type microSD (« SD » pour Secure Digital).

De façon préférée, ce module de sécurité stocke une fraction de ladite base de données, en l'espèce la fraction relative aux informations personnelles de l'utilisateur du terminal 1 concerné. Cela assure une sécurité maximale pour les informations de l'utilisateur. Similairement, le serveur de sécurité 2 peut être hébergé par ce module de sécurité (en ce qui concerne l'utilisateur impliqué), la plateforme API 5 ayant ainsi le rôle de contacter directement chaque module de sécurité (i.e. directement les terminaux mobiles 1 des utilisateurs) si leurs informations personnelles sont demandées. Dans la mesure où un module de sécurité tel qu'une carte SIM est complètement verrouillé, cela prévient des piratages et des vols d'informations.

Dans la suite de la présente description on prendra l'exemple représenté sur la figure 1 d'un module de stockage centralisé 22, mais l'homme du métier saura transposer l'invention dans le cas de l'utilisation d'un module de stockage du terminal 1 pour stocker les informations personnelles

Procédé

De façon connue, le procédé pour renseigner des informations personnelles d'un utilisateur demandées par un service en ligne donné, le procédé comprenant la mise en œuvre par un module de traitement de données 21 d'un serveur de sécurité 2 d'un opérateur d'un terminal mobile 1 de l'utilisateur de trois étapes de :

(a) réception d'une requête desdites informations personnelles de l'utilisateur, comprenant un identifiant unique de l'utilisateur et un identifiant dudit service en ligne donné ;

(b) émission à destination dudit terminal mobile 1 de l'utilisateur d'une requête d'autorisation de réponse à ladite requête desdites informations personnelles de l'utilisateur ;

(c) Si réception d'une confirmation d'autorisation de réponse depuis ledit terminal mobile 1 , émission en réponse à la requête desdites informations personnelles de l'utilisateur de données associées auxdits identifiant unique de l'utilisateur et identifiant dudit service en ligne donné dans une base de données stockée dans un module de stockage de données 22. En d'autres termes, le serveur 2 doit être sollicité directement ou indirectement par le service donné pour entamer le procédé.

Pour cela, dans un exemple préféré, l'utilisateur cherche à accéder au service en ligne au niveau de l'équipement 5, et pour cela le serveur tiers 4 hébergeant ledit service lui demande de renseigner des informations personnelles.

L'utilisateur peut simplement renseigner de lui-même ces informations, mais la place il émet des instructions de recourir à l'authentification via mobile, i.e. de demander via le réseau 20 le renseignement de ces informations personnelles, par exemple en cochant une case adéquate sur le portail du service affiché via l'équipement 3. A ce stade il est nécessaire que l'utilisateur renseigne au moins, notamment par saisie, son identifiant unique (à noter qu'il peut être par exemple préenregistré par une application, telle qu'un navigateur, de l'équipement 3). Comme expliqué cet identifiant personnel peut être soit directement une adresse e-mail voire le numéro de téléphone du terminal mobile 1 de l'utilisateur, soit un « alias », c'est-à-dire un identifiant anonymisé (tel qu'un code ou un pseudonyme) si l'utilisateur souhaite éviter de donner une information telle que son numéro de téléphone au service.

En conséquence (suite aux instructions de l'utilisateur), l'étape (a) comprend alors une demande par le serveur tiers 4 auprès de la plateforme API 5 également connectée au réseau Internet 20 de renseignement desdites informations personnelles de l'utilisateur.

En d'autres termes, le serveur 4 demande à ladite plateforme API 5 de générer ladite requête desdites informations personnelles de l'utilisateur. Pour cela il lui transmet l'identifiant unique de l'utilisateur reçu ainsi qu'un identifiant du service (ou des moyens de retrouver cet identifiant). La liste des informations demandées peut également être incluse.

Comme expliqué on comprendra que le serveur 4 peut présenter les capacités de la plateforme API 5 et donc générer directement la requête pour le serveur de sécurité 2.

Sur réception de la requête, le serveur 2 a tous les éléments lui permettant de récupérer et fournir les informations personnelles de l'utilisateur, mais auparavant il va vérifier via son terminal mobile que l'utilisateur ayant demandé le renseignement automatique est bien l'utilisateur attendu.

Pour cela il génère dans l'étape (b) la seconde requête d'autorisation de réponse à ladite requête desdites informations personnelles de l'utilisateur, et l'émet à destination dudit terminal mobile 1 de l'utilisateur. En d'autres termes, il demande à l'utilisateur de valider via son terminal le transfert des informations personnelles demandées.

Ladite seconde requête peut comprendre l'identifiant du service demandeur. Sur réception de cette requête, le terminal mobile 1 affiche que les informations personnelles de l'utilisateur sont sur le point d'être fournies (le cas échéant le service demandeur est affiché pour aider l'utilisateur), et l'utilisateur utilise l'interface de son terminal pour valider ou non cette autorisation, on verra comment plus loin.

Une confirmation d'autorisation de réponse est alors émise par le terminal 1 et reçue par le serveur 2, et alors ce dernier peut émettre en réponse à la requête desdites informations personnelles de l'utilisateur les données (qui sont les informations personnelles) associées auxdits identifiant unique de l'utilisateur et identifiant dudit service en ligne donné dans la base de données stockée dans un module de stockage de données 22, ou au moins celles demandées (par exemple le couple login/mot de passe de l'utilisateur pour ce service).

Base de données

Le présent procédé se distingue entre autres en une structure particulière de la base de données.

Là où il est connu d'associer à chaque ensemble de données personnelles un couple {identifiant unique, identifiant d'un service}, le présent procédé utilise un troisième paramètre, représentatif d'un niveau de sécurité requis pour confirmer l'autorisation de réponse sur ledit terminal mobile 1 . En d'autres termes, chaque ensemble de données personnelles est associé à un triplet {identifiant unique, identifiant d'un service, niveau de sécurité}.

Plus précisément, la procédure de validation à mettre en œuvre par l'utilisateur sur son terminal mobile 1 (pour confirmer l'autorisation de réponse à la première requête) dépend de la valeur de ce paramètre représentatif d'un niveau de sécurité, c'est-à-dire que l'application mobile met en œuvre des procédures de validation différentes selon la valeur de ce paramètre, ces différentes procédure de validation correspondant à des niveaux de sécurité différents.

De façon préférée, la valeur dudit paramètre représentatif d'un niveau de sécurité est ainsi choisie parmi une liste prédéterminée et hiérarchisée de valeurs de niveaux de sécurité : niveau 1 , niveau 2, niveau 3, etc. (avec niveau i représentatif d'une sécurité moins élevée que niveau j si i<j).

L'idée est que plus le niveau de sécurité est élevé plus la procédure de validation est complexe et nécessite une authentification « forte » de l'utilisateur sur le terminal mobile 1 , et donc plus son identité est garantie, mais plus la procédure est fastidieuse. Au contraire un niveau de sécurité bas peut présenter des failles, mais autorise une procédure de validation simple, c'est-à-dire très peu contraignante et légère. Cela permet comme on va le voir une modularité du niveau de sécurité et un paradigme nouveau dans lequel c'est l'utilisateur qui définit au cas par cas sa sécurité, sans que ce soit le fournisseur de service qui l'impose comme c'est jusque-là toujours le cas.

De façon particulièrement préférée, ladite liste prédéterminée comprend au moins un premier niveau de sécurité dans lequel une manipulation d'une interface du terminal mobile 1 suffit à confirmer l'autorisation de réponse (en d'autres termes la procédure de validation consiste en l'accomplissement d'une manipulation donnée de l'interface du terminal mobile 1 ) ; et un deuxième niveau de sécurité dans lequel la saisie d'un code d'authentification sur une interface du terminal mobile 1 est nécessaire à confirmer l'autorisation de réponse (en d'autres termes la procédure de validation comprend au moins la saisie du code d'authentification sur l'interface du terminal mobile 1 ).

Par « manipulation d'une interface », on entend n'importe quelle action prédéterminée telle qu'un appui sur un bouton ou le clic (ou le toucher dans le cas d'un terminal tactile) sur une zone prédéterminée. Par exemple, appuyer sur « OK ». Un mouvement tactile tel qu'un « slide to unlock » peut être envisagé. De façon générale, il s'agit d'une validation simple signifiant que l'utilisateur est présent sur le terminal mobile 1 . En d'autres termes, aucun code ou aucune connaissance d'une information secrète particulière n'est nécessaire pour cette validation au niveau de sécurité 1 .

Si l'utilisateur n'accomplit pas ladite manipulation dans un délai prédéterminé (ou en fait une autre représentative du refus d'autorisation, telle qu'appuyer sur « CANCEL »), alors la procédure de validation n'est pas mise en œuvre correctement, l'autorisation est réputée non confirmée et le procédé s'arrête.

La validation au niveau de sécurité 2 nécessite quant à elle connaissance d'une information sécrète, en l'espèce ledit code d'authentification nécessaire. Il s'agit typiquement du code PIN, mais ce peut être par exemple un motif de déverrouillage.

Des niveaux de sécurité encore au-delà peuvent être envisagés. Par exemple, un niveau de sécurité 3 peut nécessiter une information qui ne peut être ni connue ni volée, comme une information biométrique. La procédure de validation est alors la vérification d'une empreinte digitale, d'une empreinte retienne, etc.

Un niveau de sécurité 4 peut combiner plusieurs informations biométriques et/ou secrètes, etc.

Quelles que soient les valeurs prévues de niveau de sécurité, l'étape (b) prévoit la mise en œuvre par le module de traitement de données 21 du serveur de sécurité 2 de deux sous-étapes innovantes, en l'espèce :

la détermination de la valeur dudit paramètre associée dans ladite base de données auxdits identifiant unique de l'utilisateur et identifiant dudit service en ligne donné ; et

l'intégration de la valeur déterminée du paramètre dans ladite requête d'autorisation de réponse à ladite requête desdites informations personnelles de l'utilisateur.

En d'autres termes, lorsque le serveur 2 reçoit le première requête, il interroge la base de donnée pour savoir quelle est la valeur du troisième paramètre dans le triplet {identifiant unique, identifiant d'un service, niveau de sécurité}, et il intègre cette valeur de paramètre dans la seconde requête émise vers le terminal mobile 1 (le cas échéant avec l'identifiant du service).

Et le terminal mobile 1 demande confirmation de l'autorisation de réponse à la première requête conformément au niveau de sécurité correspondant à ce paramètre, de sorte que pour ce service en ligne donné, la sécurité soit comme l'a défini l'utilisateur, typiquement au niveau 1 (validation simple par « OK ») pour les services en ligne basiques, et niveau 2 ou plus (validation par code d'authentification voire biométrie) pour les services plus critiques tels que les services bancaires.

En résumé, le présent procédé pour renseigner des informations personnelles d'un utilisateur demandées par un service en ligne donné comprend la mise en œuvre par un module de traitement de données 21 d'un serveur de sécurité 2 d'un opérateur d'un terminal mobile 1 de l'utilisateur d'étapes de :

(a) réception d'une requête desdites informations personnelles de l'utilisateur, comprenant un identifiant unique de l'utilisateur et un identifiant dudit service en ligne donné, des couples d'un identifiant unique et d'un identifiant d'un service en ligne étant associés, dans une base de données stockée dans un module de stockage de données 22, d'une part à des informations personnelles et d'autre part à un paramètre représentatif d'un niveau de sécurité requis pour confirmer une autorisation de réponse sur ledit terminal mobile 1 ;

(b) détermination de la valeur dudit paramètre associée dans ladite base de données auxdits identifiant unique de l'utilisateur et identifiant dudit service en ligne donné ; et émission à destination dudit terminal mobile 1 de l'utilisateur d'une requête d'autorisation de réponse à ladite requête desdites informations personnelles de l'utilisateur, contenant la valeur déterminée du paramètre dans ladite requête d'autorisation de réponse ;

(c) Si réception d'une confirmation d'autorisation de réponse depuis ledit terminal mobile 1 , émission en réponse à la requête desdites informations personnelles de l'utilisateur de données associées auxdits identifiant unique de l'utilisateur et identifiant dudit service en ligne donné dans ladite base de données.

Modification de niveau de sécurité Comme expliqué, le niveau de sécurité est modulable sous le contrôle de l'utilisateur, de sorte à changer la procédure de validation associée à chaque service en ligne.

Pour cela, le procédé comprend avantageusement une étape préalable de

- réception depuis le terminal mobile 1 d'une requête de modification de la valeur dudit paramètre, comprenant l'identifiant unique de l'utilisateur, l'identifiant dudit service en ligne donné et la valeur modifiée dudit paramètre ; et

remplacement dans ladite base de la valeur du paramètre associée auxdits identifiant unique de l'utilisateur et identifiant dudit service en ligne donné, par ladite valeur modifiée.

En d'autres termes, via l'application de validation, l'utilisateur peut paramétrer ses niveaux de sécurité. Ainsi l'application peut afficher le niveau de sécurité associé à chaque service en ligne, et l'utilisateur peut le modifier directement en demandant l'émission de la requête de modification de la valeur dudit paramètre.

De façon préférée, la modification n'est possible qu'à la hausse, c'est-à-dire que le remplacement (de la valeur initiale par la valeur modifiée) n'est mis en œuvre que si la valeur modifiée de paramètre correspond à un niveau de sécurité supérieur à la valeur initiale.

Par exemple, un passage du niveau de sécurité 1 (validation simple par « OK ») au niveau 2 (validation par code d'authentification) sera autorisée, mais pas l'inverse. Cela permet d'éviter une attaque complexe dans lequel un tiers mal intentionné volerait le terminal mobile 1 de l'utilisateur, puis modifierait à la baisse le niveau de sécurité, de sorte à pouvoir accéder à un service en usurpant l'identité de l'utilisateur sans connaître son code d'authentification.

Pour éviter de bloquer l'utilisateur, il peut être prévu que par défaut chaque service en ligne est associé au niveau de sécurité minimale, ce qui fait qu'a priori l'utilisateur ne peut que monter ce niveau. Si après l'avoir monté il souhaite à présent le diminuer, il peut être alors par exemple prévu qu'une telle modification à la baisse ne soit faite que dans une boutique de l'opérateur en présentant une pièce d'identité.

A noter que dans tous les cas la modification du niveau de sécurité peut être conditionnée à la manipulation requise par niveau de sécurité actuel (voire le plus élevé entre l'initial et le modifié).

Alternativement ou en complément, le fournisseur d'un service peut exiger un niveau minimal de sécurité. Comme par défaut le niveau est minimal, il peut ainsi être prévu qu'un fournisseur de service ait lui-même la possibilité de modifier à la hausse le niveau de sécurité associé à son service pour tous les utilisateurs. Pour cela, le procédé comprend une étape préalable de :

réception depuis le serveur tiers 4 d'une requête de modification de la valeur dudit paramètre, comprenant l'identifiant dudit service en ligne donné et la valeur modifiée dudit paramètre ;

remplacement dans ladite base de la valeur du paramètre associée à chaque combinaison d'un identifiant unique et de l'identifiant dudit service en ligne donné, par ladite valeur modifiée.

Comme avant, les modifications à la baisse, potentiellement frauduleuses, peuvent être bloquées ou en tout cas conditionnées à des procédures sécurisées particulières.

Serveur de sécurité et terminal

Selon un deuxième aspect, l'invention concerne le serveur de sécurité 2 pour la mise en œuvre du procédé selon le premier aspect.

Comme expliqué, ce serveur de sécurité 2 pour renseigner des informations personnelles d'un utilisateur demandées par un service en ligne donné est connecté au réseau 20, et comprend un module de traitement de données 21 mettant en œuvre :

Un module de réception d'une requête desdites informations personnelles de l'utilisateur, ladite requête comprenant un identifiant unique de l'utilisateur et un identifiant dudit service en ligne donné, des couples d'un identifiant unique et d'un identifiant d'un service en ligne étant associés, dans une base de données stockée dans un module de stockage de données 22 (qui peut être intégrée au serveur 2, ou juste lui être connectée), d'une part à des informations personnelles et d'autre part à un paramètre représentatif d'un niveau de sécurité requis pour confirmer une autorisation de réponse sur un terminal mobile 1 de l'utilisateur ;

Un module de détermination de la valeur dudit paramètre associée dans ladite base de données auxdits identifiant unique de l'utilisateur et identifiant dudit service en ligne donné ;

- Un module d'émission à destination dudit terminal mobile 1 de l'utilisateur d'une requête d'autorisation de réponse à ladite requête desdites informations personnelles de l'utilisateur, la valeur déterminée du paramètre étant intégrée dans ladite requête d'autorisation de réponse ;

un module d'émission en réponse à la requête desdites informations personnelles de l'utilisateur, si réception d'une confirmation d'autorisation de réponse depuis ledit terminal mobile 1 , de données associées auxdits identifiant unique de l'utilisateur et identifiant dudit service en ligne donné dans ladite base de données.

Est également proposé le système comprenant le serveur de sécurité 2, et un terminal mobile 1 configuré pour mettre en œuvre un module d'émission en réponse à la requête d'autorisation de réponse de la confirmation d'autorisation de réponse si l'utilisateur met en œuvre une procédure de validation dépendante de ladite valeur dudit paramètre. Produit programme d'ordinateur

Selon un quatrième et un cinquième aspects, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution (en particulier sur le module de traitement de données 21 du serveur 2) d'un procédé selon le premier aspect de l'invention pour renseigner des informations personnelles d'un utilisateur demandées par un service en ligne donné, ainsi que des moyens de stockage lisibles par un équipement informatique (le module de stockage de données 22 du serveur 2) sur lequel on trouve ce produit programme d'ordinateur.