La présente invention se rapporte au domaine technique de la sécurisation de l'accès à des ressources en ligne, et plus particulièrement à l'authentification d'un utilisateur souhaitant accéder à un service en ligne depuis un réseau informatique public tel qu'Internet.

Par « authentification » dans les systèmes informatiques, on entend, ici, la vérification de l'identité d'une entité (une personne, un ordinateur, un processus informatique par exemple) afin d'autoriser l'accès de cette entité à des ressources (services, réseaux, systèmes, applications par exemple). On désigne, ci-après, ces entités par le terme « utilisateur ».

La mise en ligne de ressources sur des réseaux informatiques publics du type internet présente d'énormes avantages, que ce soit pour les utilisateurs ou pour les sociétés, notamment celles à caractère commercial (e-banking, e-commerce par exemple). Le nombre croissant ainsi que l'usage grandissant des services en ligne en témoignent.

Ceci a naturellement éveillé l'intérêt des cybercriminels (« hackers »), et le nombre de programmes conçus pour dérober des données permettant d'accéder frauduleusement à des ressources en ligne a fortement augmenté. A cet égard, des techniques d'authentification robustes sont plus que jamais nécessaires, tant pour les utilisateurs que pour les sociétés. En effet, d'une part un utilisateur doit pouvoir être certain qu'il accède bien au serveur du service qu'il sollicite (et auquel il va peut-être transmettre des données personnelles telles que des coordonnées bancaires) et d'autre part ce serveur doit être aussi certain que cet utilisateur corresponde bien à celui qui s'est préalablement enregistré auprès de lui et qu'il ne s'agit donc pas d'un fraudeur. Un tiers mal intentionné se faisant passer pour un utilisateur légitime pour effectuer, par exemple, une transaction bancaire en ligne ne peut certainement plaire ni à l'utilisateur légitime ni à la banque proposant ce service en ligne.

On distingue dans l'état de l'art différentes méthodes permettant de vérifier l'authenticité d'un utilisateur travaillant dans un environnement en mode client/serveur et sollicitant l'accès à une ressource en ligne. Une authentification peut se faire sur plusieurs facteurs :

- une donnée connue par l'utilisateur telle qu'un mot de passe ;

- un objet que possède l'utilisateur, par exemple une carte magnétique ou une carte à puce ;

- une action que seul sait faire l'utilisateur, par exemple une signature manuscrite sur un écran tactile ;

- une caractéristique physique propre à l'utilisateur, telle qu'une empreinte digitale. Actuellement, la méthode la plus largement employée pour effectuer une authentification d'un utilisateur auprès d'un serveur distant se base sur un mot de passe statique combiné avec un identifiant (login). L'avantage d'une telle méthode est qu'elle peut être implémentée entièrement par logiciel, évitant donc un coût matériel (hardware) supplémentaire. Cependant, l'espionnage des connexions réseaux dans le but de recueillir des identités d'utilisateurs légitimes handicape cette méthode. Des identités ainsi usurpées peuvent être ultérieurement utilisées. Les techniques de hachage ou de cryptage des mots de passe ne peuvent résoudre complètement cette problématique parce qu'ils ne font que déporter la menace depuis le lien réseau vers le terminal utilisateur, où il n'est désormais pas rare de trouver de nombreuses applications malveillantes (malware).

Les techniques d'authentification basées sur des moyens fournis aux utilisateurs, tels qu'un jeton d'authentification, une carte à puce, une carte intelligente, ou une clé USB ont l'inconvénient de nécessiter un coût hardware supplémentaire.

Par ailleurs, les méthodes biométriques d'authentification sont généralement complexes et demandent une étape de caractérisation préalable fastidieuse. Pour palier les limites des méthodes d'authentification à un seul facteur, notamment l'utilisation de mots de passe statiques, sont apparues des solutions d'authentification combinant deux facteurs : une donnée connue par l'utilisateur (par exemple un mot de passe) et un item que possède l'utilisateur (tel qu'un numéro de téléphone ou une adresse électronique). On parle dans ce cas d'authentification forte. Parmi ces méthodes existent la solution d'authentification basée sur des mots de passe à usage unique (aussi dits OTP pour One-Time Password).

Comme son nom l'indique, le mot de passe à usage unique (OTP) ne peut être utilisé comme moyen d'authentification que pour une seule session. Ainsi, un nouvel OTP est généré, généralement d'une manière aléatoire ou pseudo-aléatoire, et ensuite communiqué à l'utilisateur à chaque nouvelle demande d'accès émise par l'utilisateur auprès du serveur distant. L'utilisateur soumet cet OTP au serveur distant comme une preuve de l'authenticité de son identité, qu'il a déclarée à l'aide de son login/mot de passe par exemple. Par conséquent, l'usurpation des logins/mots de passe statiques, que ce soit depuis le terminal utilisateur ou depuis le lien réseau reliant le terminal utilisateur au serveur, devient superflu puisque qu'un OTP devient caduc dès lors qu'il a été utilisé.

Pour garantir une réelle sécurité, un OTP est généralement communiqué à l'utilisateur via un autre canal que celui établi entre le terminal utilisateur et le serveur. En effet, un OTP est généralement envoyé à l'utilisateur par SMS (Short Service Message), par MMS (Multimedia Messaging Service) ou par message vocal en utilisant le deuxième facteur d'authentification, à savoir le numéro de téléphone que l'utilisateur possède et qu'il a préalablement fourni au serveur distant.

Toutefois, l'envoi d'un OTP (par SMS, par MMS ou par message vocal par exemple) sur un téléphone engendre certainement un coût financier supplémentaire pour les fournisseurs des services en ligne (ceci n'étant pas gratuit à ce jour). On comprendra que l'envoi des OTPs par SMS à un millier de clients utilisant mensuellement un service en ligne proposé par une PME représente une charge financière non négligeable pour cette entreprise.

Un objet de la présente invention est de remédier aux inconvénients précités. Un autre objet de la présente invention est de déployer une solution d'authentification forte à plus faible coût.

Un autre objet de la présente invention est de réduire le coût financier nécessaire à garantir la sécurité des sites marchands. Un autre objet de l'invention est de permettre à un utilisateur, typiquement un internaute, d'accéder à des services en ligne de manière simple et sécurisée.

Un autre objet de la présente invention est de proposer une méthode d'authentification forte permettant de sécuriser les accès aux ressources en ligne depuis un réseau non sécurisé.

A cette fin, l'invention se rapporte, selon un premier aspect, à un procédé d'authentification par mot de passe à usage unique d'un utilisateur pourvu d'un terminal informatique et d'un terminal téléphonique et souhaitant accéder à une ressource en ligne auprès d'un système d'information, ce procédé incluant une étape de déclenchement d'un appel vers ledit terminal téléphonique avec un identifiant de l'appelant comprenant le mot de passe à usage unique.

L'invention se rapporte, selon un deuxième aspect, à un système d'authentification par mot de passe à usage unique d'un utilisateur pourvu d'un terminal informatique et d'un terminal téléphonique et souhaitant accéder à une ressource en ligne auprès d'un système d'information, ce système incluant un autocommutateur téléphonique privé agencé pour déclencher un appel vers ledit terminal téléphonique avec un identifiant de l'appelant comprenant le mot de passe à usage unique. L'invention se rapporte, selon un troisième aspect, à un produit programme d'ordinateur implémenté sur un support mémoire, susceptible d'être mis en œuvre au sein d'une unité de traitement informatique et comprenant des instructions pour la mise en œuvre du procédé résumé ci-dessus.

D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement et de manière concrète à la lecture de la description ci-après de modes de réalisation préférés, laquelle est faite en référence à la figure 1 annexée qui illustre schématiquement une représentation fonctionnelle d'un mode de réalisation.

Sur la figure 1 on a représenté un utilisateur 10 souhaitant accéder à distance, via un terminal informatique 11, à une ressource en ligne mise à sa disposition par un système d'information 20.

Le terminal informatique 11 peut être tout équipement utilisateur permettant à un utilisateur 10 de se connecter à un réseau informatique, notamment Internet, à partir duquel la ressource en ligne proposée par le système d'information 20 est accessible. Un ordinateur fixe/portable personnel/public, un PDA (Personal Digital Assistant), ou un Smartphone (un téléphone intelligent) sont des exemples de terminal informatique 10.

Le système d'information 20 peut être tout moyen informatique matériel et/ou logiciel mettant à la disposition de l'utilisateur 10 une ressource en ligne, notamment un service en ligne, accessible depuis un terminal informatique 11. Un serveur d'application, un serveur Web hébergeant un site Web e-commerce, ou une pluralité de serveurs coopératifs sont des exemples de système d'information 20.

L'utilisateur 10 dispose également d'un terminal téléphonique 12 associé à au moins un numéro d'appel (numéro de téléphone). Ce terminal téléphonique 12 est, par exemple, un téléphone mobile, un Smartphone ou un PDA comprenant une carte SIM (Subscriber Identity Module) ou USIM (Universal Subscriber Identity Module) ;

un téléphone fixe analogique ou numérique ;

- un Softphone ayant un numéro de téléphone (par exemple Skype™ In).

Dans une mise en œuvre avantageuse, le terminal téléphonique 12 est un téléphone mobile ou un Smartphone. Ce cas n'est bien entendu pas limitatif. Le terminal téléphonique 12 permet la présentation à l'appelé du numéro de l'appelant (en anglais, Calle D pour Caller Identification ou CLIP pour Calling Line Identification Présentation). Autrement dit, le terminal téléphonique 12 fournit à l'appelée le numéro, ou plus généralement l'identifiant de l'appelant. L'identifiant de l'appelant peut être affiché sur l'écran du terminal téléphonique 12, s'il en a un, ou sur un appareil à part. En variante ou en combinaison, l'identifiant d'un appel entrant au terminal téléphonique 12 peut être

- affiché depuis un répertoire compris dans ce terminal (journal des appels, appels manqués, appels en absence par exemple), et/ou

- obtenu en composant un certain numéro (par exemple, pour un abonné France Telecom™, composer le 3131 pour avoir le numéro du dernier appelant).

Notamment, le terminal informatique 11 et le terminal téléphonique 12 peuvent être compris dans un seul équipement utilisateur tel que : un ordinateur fixe/mobile comprenant un Softphone ; ou

- un Smartphone ou un PDA permettant un service de données (DATA) en plus de sa fonction en tant que téléphone.

Dans une mise en œuvre d'un mode de réalisation illustré sur la figure 1, l'utilisateur 10 souhaite accéder à une ressource mise en ligne par le système d'information 20 et nécessitant une authentification forte (étape 1 sur la figure 1). A titre d'exemple, l'utilisateur 10 souhaite effectuer une transaction (virement, achat, vente par exemple) en ligne sur un site Web (bancaire, ou e-commerce par exemple) hébergé par le système d'information 20. Pour se connecter au système d'information 20 distant du site Web auquel il veut accéder, l'utilisateur 10 utilise le terminal informatique 11 de manière classique en entrant l'adresse Web du site.

S'agissant d'une ressource en ligne nécessitant une authentification forte, le système d'information 20 est agencé pour vérifier l'authenticité de l'identité de l'utilisateur 10 que ce dernier a déclaré, par exemple, à l'aide d'un login/mot de passe. Pour cela, le système d'information 20 (étape 2 sur la figure 1 ) mémorise la demande de l'utilisateur 10 ; recherche le numéro de téléphone (c.à.d. le deuxième facteur d'authentification) que l'utilisateur 10 a préalablement fourni au cours d'une session antérieure. Bien entendu, ceci suppose que l'utilisateur 10 a préalablement renseigné son profil (au moins, un login, un mot de passe et un numéro de téléphone) auprès du système d'information 20 en y indiquant le numéro de téléphone de son terminal téléphonique 12 ;

- génère un OTP que l'utilisateur 10 ne peut connaître à l'avance. Cet OTP est généralement généré d'une manière aléatoire ou pseudo- aléatoire.

Ensuite, le système d'information 20

- communique (étape 31 sur la figure 1) ΙΌΤΡ généré et le numéro de téléphone de l'utilisateur 10 à l'autocommutateur téléphonique privé 30, aussi dit PBX ou PABX pour Private Automatic Branch eXchange, et

informe (étape 32 sur la figure 1) l'utilisateur 10

o qu'il va instantanément recevoir un appel sur le numéro de téléphone qu'il a préalablement fourni (c.à.d. le numéro de téléphone du terminal téléphonique 12 en sa possession) ; et o qu'il doit lui soumettre (retourner) l'identifiant de l'appelant

(CallerJD).

Le PABX 30 peut être aussi un PABX IP, qui est une évolution vers ΙΊΡ (Internet Protocol) du BAPX traditionnel.

Avantageusement, une des fonctionnalités natives du PABX 30 est de pouvoir changer le numéro de l'appelant (CalleMD) à la demande.

De ce fait, en utilisant le numéro de téléphone et l'OTP qui lui sont transmis depuis le système d'information 20, le PABX 30 est agencé pour (étape 4 sur la figure 1) déclencher un appel sur le terminal téléphonique 12 de l'utilisateur 10 tout en présentant l'OTP dans l'identifiant de l'appelant (c'est-à-dire dans le CalleMD). Il en résulte que l'OTP est transporté directement sur l'afficheur du terminal téléphonique 12, en lieu et place de la présentation du numéro de l'appelant. Il est à noter que l'appel déclenché par le PABX 30 vers le terminal téléphonique 12 vise à fournir ΙΌΤΡ et non pas à établir une conversation. Cet appel ne prend donc que le temps nécessaire et suffisant pour fournir ΙΌΤΡ au terminal téléphonique 12, autrement dit, avant que l'utilisateur 10 ne décroche. Par conséquent, le PABX 30 est programmé pour interrompre l'appel émis dès la première ou la deuxième sonnerie par exemple.

L'utilisateur 10 saisit (étape 5 sur la figure 1) l'identifiant de l'appelant (Caller_ID) qui lui est affiché sur son terminal téléphonique 12 conformément à ce que lui a été demandé par le système d'information 20. A titre d'exemple, l'utilisateur 10 saisit l'identifiant de l'appelant dans une zone dédiée (un certain champ dans un formulaire électronique par exemple), et le soumet au système d'information 20.

En variante, le système d'information 20 demande à l'utilisateur 10 de ne lui retourner qu'une partie précise de l'identifiant de l'appelant d'un appel entrant qu'il va instantanément recevoir sur son terminal téléphonique 12.

Le système d'information 20 vérifie (étape 6 sur la figure 1) la validité du message qui lui est soumis en retour par l'utilisateur 10 et, en conséquence, autorise ou refuse l'accès sollicité par l'utilisateur 10. Pour cela, le système d'information 20 comprend des moyens permettant de vérifier la concordance entre le message soumis par l'utilisateur 10 et l'OTP qui a été généré et communiqué au PABX 30. En cas de concordance du contenu soumis par l'utilisateur 10 (étape 5 sur la figure 1) avec celui généré par le système d'information 20, l'utilisateur 10 est authentifié de manière certaine par le système d'information 20. Le système d'information 20 dirige, dans ce cas, l'utilisateur 10 vers la ressource sollicitée.

L'utilisateur 10 est informé du résultat de son authentification (étape 7 sur la figure 1 ).

Dans une mise en œuvre illustrative du procédé décrit ci-dessus, l'internaute 10 émet un message de demande d'accès depuis son ordinateur 11, vers un serveur d'application 20 hébergeant un site bancaire afin d'effectuer une certaine transaction (étape 1 sur la figure 1); le serveur d'application 20 mémorise la requête de l'internaute 10, retrouve le numéro de téléphone de ce dernier (deuxième facteur d'authentification de l'internaute 10), et génère un mot de passe à usage unique (OTP) (étape 2 de la figure 1);

- le serveur d'application 20 communique le mot de passe à usage unique généré et le numéro de téléphone de l'internaute 10 au PABX 30 (étape 31 de la figure 1) ;

le serveur d'application 20 informe l'internaute 10 qu'il va recevoir, dans un instant, un appel - sur le numéro de téléphone qu'il a précédemment renseigné - dont l'identifiant de l'appelant (Calle D) est le mot de passe à usage unique qu'il doit lui soumettre (étape 32 sur la figure 1 );

le PABX 30 émet un appel vers le numéro de téléphone de l'internaute 10 en affichant dans l'identifiant de l'appelant le mot de passe à usage unique généré par le serveur d'application 20;

l'internaute 10 soumet l'identifiant de l'appelant qui lui est affiché sur son téléphone 11 (étape 5 sur la figure 1);

le serveur d'application 20 vérifie la concordance entre le mot de passe à usage unique qu'il a généré et celui qui lui a été soumis par l'internaute 10 (étape 6 sur la figure 1);

le serveur d'application 20 informe l'internaute 10 du succès/échec de son authentification (étape 7 sur la figure 1).

Dans une autre mise en œuvre illustrative d'un mode de réalisation, l'utilisateur 20 est pourvu d'un équipement utilisateur combinant un terminal téléphonique et un terminal informatique tel qu'un Smartphone, ou un ordinateur fixe/portable par exemple. Dans ce cas, l'utilisateur 10

- se connecte au serveur distant 20 à partir de son Smartphone (par exemple, ouvre la page Web d'un service en ligne proposé par le serveur distant 20);

- s'identifie auprès du serveur distant 20 à l'aide d'au moins un identifiant qui lui est propre (un login et un mot de passe par exemple) ;

requière la connexion au service en ligne auprès du serveur distant 20 (requière la réalisation d'une transaction en ligne par exemple); le serveur distant 20 recherche le numéro de téléphone associé à l'identité déclarée par l'utilisateur 10, ces informations lui étant communiquées lors d'une phase préalable (une phase d'inscription au service en ligne par exemple) ;

le serveur distant 20 génère un OTP ;

le serveur distant 20 transmet le numéro de téléphone de l'utilisateur 20 et l'OTP généré au PABX 30 ;

le serveur distant 20 demande à l'utilisateur de lui soumettre l'identifiant de l'appelant (CalleMD) de l'appel qu'il va recevoir dans un instant ;

le PABX 30 déclenche un appel au numéro de téléphone qui lui est transmis en présentant l'OTP dans l'identifiant de l'appelant (CallerJD) ;

l'utilisateur 10 saisie l'identifiant de l'appelant (CalleMD) de l'appel qu'il vient de recevoir et le soumet au serveur distant 20 (l'utilisateur 20 saisie l'identifiant de l'appelant (CalleMD) dans un formulaire qu'il soumet au serveur distant par exemple) ;

le serveur distant 20 vérifie la concordance entre le message soumis par l'utilisateur et l'OTP généré, et informe l'utilisateur du résultat (c'est-à-dire, le succès ou l'échec de son authentification).

Dans un mode préféré de réalisation, lorsque le terminal informatique 11 et le téléphonique 12 sont compris dans un seul équipement utilisateur (notamment un ordinateur ou un Smartphone), une application logicielle est agencée pour récupérer l'identifiant de l'appelant du dernier appel entrant afin de le soumettre au serveur distant. Dans une mise en œuvre particulière, cette application logicielle est lancée par l'utilisateur depuis le formulaire électronique donnant accès au service en ligne. En variante, cette application est lancée automatiquement dès que l'utilisateur a requis l'accès au service en ligne.

Dans un mode de réalisation, l'application logicielle est jointe au formulaire électronique d'accès au service en ligne. Avantageusement, cette application logicielle permet de réduire les interventions de l'utilisateur dans le procédé d'authentification. Dans un autre mode de réalisation, lorsque le terminal téléphonique 12 et le terminal informatique 11 ne sont pas compris dans un seul équipement utilisateur (c'est-à-dire deux terminaux utilisateurs indépendants), l'application logicielle, répartie entre les deux terminaux 11 et 12, permet de faire parvenir au terminal informatique 11 l'identifiant de l'appelant du dernier appel entrant au terminal téléphonique 11. Pour cela, l'application logicielle peut utiliser, par exemple, une interface de communication radio de courte portée (Bluetooth™ par exemple) partagée par le terminal informatique 11 et le terminal téléphonique 12. II est à noter qu'un OTP, selon la présente invention, peut être généré suivant toute méthode connue dans l'état de l'art (logicielle, matérielle, aléatoire/pseudo-aléatoire, dépendant/indépendant des facteurs d'authentification par exemple).

Dans un mode de réalisation, l'identifiant de l'appelant (Calle D) affiché à l'utilisateur 10 permet d'en extraire ou d'en déduire l'OTP (à l'aide d'une fonction de sélection ou de décryptage par exemple) généré par le système d'information 20. Cette fonction est apportée à l'utilisateur 10 sur son terminal informatique 11 et/ou son terminal téléphonique 12.

Notamment, le procédé d'authentification par mot de passe à usage unique décrit ci-dessus peut être déployé en combinaison avec d'autres méthodes de sécurisation (protocoles d'échange sécurisé tels que SSH, ou SSL par exemple).

Le procédé qui vient d'être décrit présente un certain nombre d'avantages. Il permet en effet - d'assurer une authentification mutuelle entre l'utilisateur 10 et le système d'information 20 ;

- de réduire le coût d'une authentification par OTP : à encontre d'un SMS/MMS, un appel est généralement gratuit ;

- d'assurer la sécurité du procédé d'authentification : l'identité de l'utilisateur (login/mot de passe par exemple) et l'OTP sont transmis sur deux canaux de communication différents.