EP2871615A1 - Méthode d'authentification d'un utilisateur par un module d'authentification - Google Patents

Méthode d'authentification d'un utilisateur par un module d'authentification Download PDF

Info

Publication number
EP2871615A1
EP2871615A1 EP20130192404 EP13192404A EP2871615A1 EP 2871615 A1 EP2871615 A1 EP 2871615A1 EP 20130192404 EP20130192404 EP 20130192404 EP 13192404 A EP13192404 A EP 13192404A EP 2871615 A1 EP2871615 A1 EP 2871615A1
Authority
EP
European Patent Office
Prior art keywords
authentication
user
value
data
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP20130192404
Other languages
German (de)
English (en)
Inventor
Salvatore BOCCHETTI
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nagravision SARL
Original Assignee
Nagravision SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nagravision SA filed Critical Nagravision SA
Priority to EP20130192404 priority Critical patent/EP2871615A1/fr
Publication of EP2871615A1 publication Critical patent/EP2871615A1/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/30—Individual registration on entry or exit not involving the use of a pass
    • G07C9/32—Individual registration on entry or exit not involving the use of a pass in combination with an identity check

Definitions

  • the present invention relates to a method of authenticating a user by an authentication module managing access to a plurality of services.
  • the authentication of a user is a complex problem which must take into account several contradictory parameters such as in particular the security and the ease of use.
  • authentication data is stored in an authentication module associated with the service provider.
  • Authentication data can be classified into three categories. One of the categories contains something that the user knows (password, answer to a secret question, secret rule, ..). Another category contains something that the user owns (mobile phone, smart card, ...) and the last category contains something that the user is, that is to say essentially the biometric data and the data. related to the usual behavior of the user (fingerprint, conformation of the eye, how to type a password, ..).
  • the security level is set in advance and the system is not flexible.
  • access to a service is done in a binary way, that is to say that a data is considered either just or false. For example, if the password entered by the user is false, access to the service is prohibited.
  • the authentication of a user wishing to access a service is very flexible.
  • the security level may in particular be adapted to the service to which the user wishes to access and other conditions related to the environment, such as for example the time of day.
  • a high level of security may be required for services such as payments or any services for which identity theft can have significant consequences, while a lower level of security may be required for services in which spoofing is required. identity has few consequences.
  • the user and the authentication module can share several secrets or authentication data. At least one of these authentication data is in principle introduced into the authentication module during an initialization phase, for example at the conclusion of a subscription. As explained in detail below, it is possible that a single authentication datum is not sufficient to access all the services offered by a provider. It is possible to introduce additional secrets or authentication data at the same time as the first authentication data, or subsequently, for example when the user wishes to be able to access additional services. Some authentication data may be acquired without the active and informed participation of the user. Thus, the behavior of the user can be stored without the latter being informed or not aware of it, this behavior forming a secret or an authentication data used in the context of the present invention.
  • the user can choose on the basis of which authentication data he wishes to access the service. For example, if a user can access a service by means of a smart card, a password or biometric data, he will have the choice of the type of data and will be able to access the service itself. it does not have the smart card available, for example by choosing to use the biometric data.
  • the authentication data to be provided to the authentication module may vary according to the type of services required. Some choice may however be left to the user. By way of example, access to a service for which identity theft will have little consequence may be authorized with, at the user's choice, information from a password, a smart card or a card. given biometric. Access to a service requiring a higher level of security may for example be done only with a password combined with a smart card or the password combined with a biometric data.
  • the data provider can suggest or impose on the user the authentication data that the latter must use to access the required service.
  • the provider may propose to use sufficient authentication data to access the required service, but having the lowest value possible for a third party intercepting this data. Indeed, the higher the value is for the user, the higher it is also for a usurper. It may therefore be interesting to use the information which is sufficient to access the service in question, but which has the least possible value for a usurper.
  • the method of the invention makes it possible to efficiently use authentication data for which the verification of the conformity between what is received by the authentication module and what is expected can be difficult to evaluate in a binary manner. .
  • This can be the case for example by analyzing the behavior of the user when introducing a password or a passphrase.
  • a given user will generally have a way to write his password reproducibly.
  • the time required to write the password, the interval between two consecutive keys, will be very close from one time to another. Another user entering the same password will most likely behave differently.
  • This type of data may be used in the method of the invention.
  • the minimum level of security is in principle set by the service provider. However, it is possible for the user to set a higher security level than this minimum level. This can be done by each user individually. This increase in the level of security is usually at the expense of ease of use. Each user will be able to adapt the level of security and ease of use according to their desires, within the framework set by the service provider. In general, however, a user can not set a security level below the minimum security level set by the service provider for the service.
  • the present invention relates to a method for authenticating a user who wishes to access a service. This authentication is done by means of an authentication module, using an interface between the user and the authentication module.
  • This interface can be a keyboard such as an alphanumeric keyboard by means of which the user can enter an access code, a password, a passphrase, a value resulting from a calculation, ...
  • the interface can also include a sensor and a processing device, the sensor can be used for the detection of biometric information such as fingerprints, facial recognition, retinal recognition, ...
  • the interface generally comprises a display allowing the user to read instructions for him.
  • the user may have to enter data in an active way (password, PIN code, ...) or let the interface acquire the data (fingerprints, retinal recognition, voice recognition, %)
  • the method of the invention can be used to access a specific service provider, this provider offering access to one or more services.
  • a service provider may for example be a bank, in which case the services may be consulting one or more accounts, transferring money, payments, withdrawals, etc.
  • Another provider could be a provider of access to pay-TV events or other events such as news, stock market information, weather, ...
  • the method of the invention can also be used to access services offered by a device such as a tablet, a car, etc.
  • the authentication module is integrated into the device or device offering the required service.
  • the authentication module Before starting an authentication procedure, the authentication module usually requires an identification of the user. This allows this module to determine which data and parameters to use to authenticate the user. This identification can be done for example by asking the user to enter a name (user name) or a personal code (PIN code). Of course, other ways of identifying a user can be considered.
  • this supplier or this apparatus asks the user to indicate first, the service to which he wishes to access. It is also possible that the service provider or the device requests this information in a second time only or that it does not ask for it at all.
  • the authentication module may, for example, indicate to the user which services he / she may have access to as long as authentication succeeds.
  • the interface acquires a first authentication data corresponding to the user.
  • This first authentication data may be for example a password typed on a keyboard by the user. It can also be a biometric data such as an image of the retina of the user, etc.
  • the first authentication data can also be a combination of several elements, for example a response to a calculation that the user must pronounce aloud, this calculation can be displayed on the screen or result from a secret rule agreed between the service provider and the user. In this case, voice recognition can be used as authentication data, possibly in addition to the secret rule.
  • This initial authentication data is associated with at least two values, one of the values being associated with the correct introduction of the authentication data and the other value being associated with the incorrect introduction of this authentication data. It should be noted that these values are not necessarily static. According to a preferred embodiment, the value associated with the correct introduction of the authentication data is positive. The value associated with the incorrect introduction of the authentication data may be zero or negative, for example. It could be positive, but less than the value associated with introducing a valid authentication value.
  • an authentication datum is associated with more than two values. This could be the case of an authentication datum using the behavior of the user. Since this behavior is not strictly reproducible from one time to the next, different values can be associated with the authentication data, with the rule that the more the behavior measured during a connection attempt moves away from the memorized behavior. by the authentication module, the lower the assigned value.
  • Several values could also be associated with a password or passphrase, which would, to a certain extent, allow a user to enter a password or passphrase with a typo. The fact of having several values associated with an authentication datum is particularly interesting in cases where the authentication data is biometric data.
  • a limit value is set. If, for a number of points greater than the limit value, the measured elements and the stored data match, the authentication is considered to be correct. If the number of matching data is less than the limit value, the authentication is considered incorrect.
  • the association between an authentication datum and an authentication value can be done in different ways. For example, it is possible to define a fixed value per type of authentication data. Generally, the more the type of authentication data is easy to forge, the lower the value. Thus, a password will generally have less value than a biometric data. In the case of assigning a fixed value per data type, a password will always have the same value regardless of the password.
  • the authentication value for a given authentication data may also depend on other parameters such as for example the time of day and / or the day of the week.
  • the same password that allows access to payment services for businesses could have a high value during business hours and a lower value outside those periods. This makes it possible to take into account the fact that a request for access to the service outside working hours is more likely to be the act of an usurper than the same access request during the opening hours of the service. business. These hours of operation could be defined by the company itself, so individualized and would not necessarily be common to all services and service users of a specific provider.
  • the authentication value may also depend on the user's history or access request.
  • the introduction for the first time of a fake password could be associated with a first negative value.
  • the introduction for the second time during the same access request, of a false password could be associated with a second negative value, different from the first value and having an absolute value greater than that of the first value. .
  • a weight could be associated with unsuccessful connection attempts.
  • a weight of 1 could for example be associated with the introduction of a first false authentication datum, a weight of 1.2 at the introduction of a second false authentication datum and a weight of 1.5 at the same time. introducing a third false authentication data.
  • the authentication module assigns an authentication value to this datum. For this, the authentication module determines which are the different possible values for this authentication data, what are the conditions associated with these possible values and what specific condition, the authentication data introduced by the user filled.
  • the conditions can be the allocation of the maximum value if the authentication data input is identical to the authentication data stored or expected by the authentication module and a null value in the opposite case .
  • the authentication module determines which threshold value must be reached to access the service required by the user.
  • This threshold is stored by the authentication module may be fixed for a service or on the contrary depend on different parameters. These parameters can be, for example, a period in the day or certain days of the week. They can also consider the location from which a user wishes access a service. The place from which the access request originates could also be considered as an authentication datum.
  • the authentication module checks whether the initial authentication value reached by the user is greater than or equal to the threshold value for the service in question. If the answer to this question is positive, access to the service is allowed.
  • the method continues by searching for additional authentication data for that user.
  • the authentication module has, for each user, a directory of the available authentication data.
  • authentication data that has already been used during the current login procedure is marked as unavailable or unused. The authentication module is therefore able to know if other authentication data are available for the user in question.
  • the interface acquires such authentication data. This acquisition is similar to the acquisition of the initial authentication data.
  • the user chooses which authentication data he wishes to use.
  • a usage order is defined and the authentication module sticks to this order.
  • the authentication module chooses additional authentication data that will allow the user to access the service if the authentication is successful, but which will have the weakest possible authentication value to allow the user to access the service. access to this service.
  • This can be interesting because, in principle, the more authentication data has a high authentication value, the more interesting it will be to intercept for a usurper. It is therefore wise to use, and potentially to disclose, information having the lowest value possible to achieve the desired goal, namely to access a specific service.
  • an authentication value is assigned to it as before.
  • This value is named here additional authentication value.
  • This additional authentication value is combined with the stored authentication value, which is the initial authentication value.
  • the combination could be simply the addition of both values. This addition is however not the only possible solution. For example, it is possible to add a "weight" to each authentication value.
  • the weight could be 1 for the initial value, 0.9 for the first additional value, 0.8 for the second additional value, etc. It is clear that the invention is not limited to the combinations described here.
  • the result of this combination is called the combined authentication value, which value is stored either in place of the initial authentication value or in addition to this value.
  • the combined authentication value is compared to the threshold value. If the threshold is reached or exceeded, access to the service is allowed. Otherwise, as before, the authentication module determines whether it still has additional authentication data for this user.
  • the method continues thus, combining at each turn, the stored authentication value and the additional authentication value. This method terminates either when the combined authentication value reaches or exceeds the threshold, or when all authentication data available for this user were used, without the threshold value being reached.
  • the service provider offers two services. Access to the first service is allowed as soon as the authentication value exceeds a fixed threshold, for example 80.
  • the threshold for the authentication value for accessing the second service is set to 120 in our example.
  • the authentication module when the user wishes to access the service, the authentication module indicates to the user that he must provide authentication data.
  • the user may have the choice of the type of data that he wishes to introduce or on the contrary, this choice may be imposed by the authentication module.
  • an initial authentication value of 60 is assigned to this user.
  • This initial authentication value is compared with the threshold value, which is 80 in the example considered, for the first service. The initial authentication value is less than the threshold value. Access to the first service is not allowed at this stage.
  • the authentication module then checks whether another authentication data is available for this user.
  • This other data may be a password or any other authentication data, but must of course be different from the authentication data already used. For this, the authentication data already used during a connection attempt is marked as used or unavailable.
  • three other authentication data are available, namely a password, a secret rule and a biometric data.
  • the user has the choice of the type of data that he wishes to use among the possible data not yet used.
  • the authentication module imposes the type of data.
  • the authentication module will impose the type of data that has the lowest possible value to reach the threshold value.
  • the user will use the password. If this password is entered correctly and corresponds to what is expected by the authentication module, an additional authentication value is assigned to the user. In the example, this value is 40.
  • the initial authentication value (60) and the additional authentication value (40) are combined.
  • This combined authentication value is compared with the threshold value which is 80 in the example.
  • the combined authentication value is greater than the threshold value. As a result, access to the first service is allowed.
  • the user wants to access the second service, which requires an authentication value greater than or equal to 120, it may for example use the secret rule, which is to multiply by 4, the value displayed on the interface.
  • the secret rule which is to multiply by 4
  • the user introduces a wrong result in response to the secret rule. This erroneous result is associated with a value of -50.
  • the value obtained is also lower than the threshold value for the first service.
  • the threshold value of the first service is not controlled and the user continues to have access to this first service. service.
  • the threshold value is checked during each use of an authentication data item. Since the combined authentication value (50) is less than the threshold value (80) for the first service, access to this service is disabled and the user must use a new one. authentication data to access the services, whether the first or the second service.
  • the authentication module still has an authentication data available for this user, namely a biometric data.
  • the user who chooses to access the second service allows the interface to acquire the biometric data. If the authentication is done correctly, the authentication value of these biometric data, which is 70 in the example.
  • the combination of the additional authentication value linked to the biometric data with the stored combined authentication value, linked to the other three data used, gives a value of 50 + 70 120. This combined authentication value is equal to the threshold 120 to access the second service. Access is therefore allowed to this user.
  • the user it is possible for the user to be authorized to access a service despite the fact that at least one of the authentication data does not correspond to the expected result.
  • the authentication values are stored during the running of the method.
  • the authentication data or secrets already used can not be used during this connection to a service, otherwise it would be possible to reach any value by entering the same data, for example a correct password. , a sufficient number of times. An authentication data already correctly used is therefore marked as such. Authentication data that the user has tried to use, unsuccessfully, such as an incorrect password, may be marked as unusable for this login attempt. It may also not be marked or marked as usable. In this case, the user can try as many times as he wishes, to use the authentication data. Finally, according to a preferred embodiment, each attempt to use authentication data is stored and the number of attempts during a connection session is limited, for example to three.
  • the authentication data does not have could be used, depending on the implementation chosen, access to the services is blocked, even if other authentication data are still available, or on the contrary, only the use of the authentication data that led to a failure is blocked, the other authentication data is still usable.
  • the authentication module when verifying the existence of additional authentication data for this user will find that it has authentication data. Suppose the user enters a false result when using the secret rule.
  • the authentication module will check if it has other authentication data. In a first embodiment, the authentication module will ask the user to use this data by introducing additional authentication data.
  • the authentication module before asking the user to enter additional authentication data, the authentication module will check whether the combination of the current combined authentication value (-40) and the value authentication that the user can obtain with all the authentication data available to this authentication module (70), is sufficient to reach the threshold value. If this is not the case, it will indicate to the user that access to the service is denied.
  • the user has a current combined authentication value of -40.
  • the authentication module has only one authentication data for this user, the value of which is 70. Regardless of the value obtained during the authentication using this additional data, the combined authentication value will not reach not the threshold value and access will be denied. It is therefore both useless and risky to ask the user to enter the last authentication data. Indeed, this data could be memorized by a usurper.
  • a first threshold for a first service could be associated with the consultation of the user's accounts.
  • a second threshold, generally higher than the first threshold could be associated with transfers from one user account to another account of the same user.
  • a third threshold could be associated with payments of less than a certain amount, and a fourth threshold could be associated with payments in excess of that amount.
  • a first threshold could be associated with access to one channel or set of determined channels and a second threshold could be associated with another set of pay-TV events. canals.
  • the user must indicate, for example before introducing the first authentication data, which service he wishes to access. It can also indicate the service just after the introduction of the first authentication data, before the introduction of the additional authentication data. The rest of the process proceeds in the same manner as described above, the threshold used depending on the service to which the user wishes to access.
  • the user does not indicate to which service he wishes to access, but the authentication module indicates a list of services that the user can access based on the combined authentication value achieved.
  • This list may increase as the user enters correct authentication data or on the contrary, decrease if incorrect data is entered. The user can stop entering authentication data as soon as the service he wishes to access is available.
  • the authentication module can also indicate to the user all the services offered, this indication being in the form of two lists.
  • One of the lists may contain the services to which the user has access, in particular taking into account the combined authentication value reached by the user and the other list containing the services to which the user does not have access .
  • the lists can be distinguished by colors, for example green for accessible services and red for others or black for accessible services and gray for others.
  • the authentication data as well as the services offered, are not necessarily communicated by the authentication module. This results in the possibility for the latter to collect authentication data (including "behavior” or biometric) without the knowledge of the user and then use this data to develop the authentication value.
  • the combined value acquired by the user during a session is stored.
  • the user has introduced enough authentication data to view his accounts in a bank, but not allowed to make a payment, he will have to introduce additional authentication data when he wants to make a payment.
  • access to a service could be granted to a user as soon as the authentication value has reached the threshold, but the behavior of the service provider could be different depending on this authentication value. For example, access to a service could be granted once the authentication value has reached 50. However, if the authentication value has not exceeded 80, information for example relating to the operations performed or to a place or logical address from which operations are performed, are stored.
  • the present invention provides several variants for managing the authentication of a user. These variants can be combined with each other.
  • This invention offers great flexibility, which allows the user to access services in a manner that suits him best.
  • This user can also set to a certain extent, the level of security he wants.
  • the provider imposes a minimum value of 80 for access to a certain service
  • the user can define that for this specific service, the combined authentication value should be 90 instead of 80.
  • the user who chooses to increase the level of security, it will be ready to accept a decrease in ease of use that generally results.
  • the provider defines a certain range, for example between 70 and 90, that it sets a certain value by default, for example 80 and that the user can specify the value that he wishes to use, in the range of values defined by the provider.

Abstract

La présente invention concerne une méthode d'authentification d'un utilisateur par un module d'authentification, ledit module d'authentification gérant l'accès à une pluralité de services et comprenant un seuil d'authentification pour chaque service, au moins deux données d'authentification étant associées audit utilisateur, ladite méthode comprenant les étapes d'acquisition d'au moins une donnée d'authentification de l'utilisateur, au moyen d'une interface entre cet utilisateur et ledit module d'authentification; et de vérification de ladite au moins une donnée d'authentification et attribution d'une valeur d'authentification à l'utilisateur, en fonction du résultat de la vérification; de comparaison de la valeur d'authentification avec la valeur de seuil pour le service requis. Si la valeur d'authentification est égale ou supérieure à la valeur de seuil, l'accès au service requis par l'utilisateur est autorisé. Si la valeur d'authentification est inférieure à la valeur de seuil, vérification si une donnée d'authentification non utilisée est disponible pour cet utilisateur; si aucune donnée d'authentification non utilisée n'est disponible pour cet utilisateur, refus de l'accès au service requis. Si au moins une donnée d'authentification non utilisée est disponible pour cet utilisateur, la méthode est répétée en acquérrant une donnée d'authentification différente de celle(s) présentée(s) antérieurement et en combinant les valeurs d'authentification, la comparaison étant faite entre la valeur de seuil et la combinaison des valeurs d'authentification.

Description

    DOMAINE TECHNIQUE
  • La présente invention concerne une méthode d'authentification d'un utilisateur par un module d'authentification gérant l'accès à une pluralité de services.
    • TECHNIQUE ANTERIEURE
  • L'authentification d'un utilisateur est un problème complexe qui doit prendre en compte plusieurs paramètres contradictoires tels qu'en particulier la sécurité et la facilité d'utilisation.
  • Les méthodes actuelles sont basées sur une ou plusieurs caractéristiques que l'utilisateur et le fournisseur de services ont dû convenir au préalable. Ces caractéristiques ou secrets, dénommés ci-après données d'authentification, sont mémorisées dans un module d'authentification associé au fournisseur de services. Les données d'authentification peuvent être classées en trois catégories. L'une des catégories contient quelque chose que l'utilisateur connaît (mot de passe, réponse à une question secrète, règle secrète,..). Une autre catégorie contient quelque chose que l'utilisateur possède (téléphone portable, carte à puce,...) et la dernière catégorie contient quelque chose que l'utilisateur est, c'est-à-dire essentiellement les données biométriques et les données liées au comportement habituel de l'utilisateur (empreinte digitale, conformation de l'oeil, manière de taper un mot de passe, ..).
  • Dans les systèmes d'authentification actuels, pour accéder à un service sécurisé proposé par un fournisseur de services ou accessible depuis un dispositif ou un appareil, une ou plusieurs données d'authentification sont demandées à l'utilisateur. Les réponses données par l'utilisateur sont transmises à un module d'authentification dans lequel elles sont comparées aux réponses attendues par ce module d'authentification. Si les réponses concordent, l'accès au service est autorisé.
  • Il arrive, dans certaines circonstances ou dans certains systèmes, que plusieurs données d'authentification soient demandées à l'utilisateur et qu'une réponse partielle ne soit pas suffisante pour accéder au service. Ceci peut être le cas lors de l'utilisation de certaines applications demandant un niveau de sécurité élevé où par exemple un mot de passe est demandé en plus d'informations biométriques. Cela peut également être le cas lorsque le module d'authentification détecte quelque chose d'inhabituel tel que par exemple une tentative de connexion à un serveur depuis une adresse IP inhabituelle. Dans ce cas, le module d'authentification peut, après avoir reçu un mot de passe correct, demander une confirmation en demandant par exemple la réponse à une question secrète ou une adresse e-mail de "secours", mémorisée lors d'une phase d'initialisation.
  • Dans tous les cas, le niveau de sécurité est fixé à l'avance et le système n'est pas flexible. De plus, l'accès à un service se fait de façon binaire, c'est-à-dire qu'une donnée est considérée soit comme juste, soit comme fausse. Par exemple, si le mot de passe introduit par l'utilisateur est faux, l'accès au service est interdit.
  • Les méthodes actuelles destinées à vérifier l'authenticité d'un utilisateur souhaitant accéder à un service sont donc peu flexibles en ce sens qu'elles ne permettent pas d'être adaptées au niveau de sécurité requis par le service et/ou à certains souhaits de l'utilisateur. Si le niveau de sécurité est trop élevé, la facilité d'utilisation risque d'être faible et la procédure d'authentification peut être contraignante ou même rédhibitoire pour l'utilisateur. Au contraire, si l'accès est simple pour l'utilisateur, la sécurité pourrait être trop faible.
  • Il est donc souhaitable d'avoir une méthode flexible, dans laquelle le niveau de sécurité peut être varié facilement, par exemple en fonction du service demandé ou en fonction de choix de l'utilisateur ou du fournisseur.
    • EXPOSE DE L'INVENTION
  • Le but de l'invention est atteint par une méthode d'authentification d'un utilisateur par un module d'authentification, ledit module d'authentification gérant l'accès à une pluralité de services et comprenant un seuil d'authentification pour chaque service, au moins deux données d'authentification étant associées audit utilisateur, ladite méthode comprenant les étapes suivantes :
    1. a) acquisition d'au moins une donnée d'authentification de l'utilisateur, au moyen d'une interface entre cet utilisateur et ledit module d'authentification;
    2. b) vérification de ladite au moins une donnée d'authentification et attribution d'une valeur d'authentification à l'utilisateur, en fonction du résultat de la vérification;
    3. c) comparaison de la valeur d'authentification avec la valeur de seuil pour le service requis;
    4. d) si la valeur d'authentification est égale ou supérieure à la valeur de seuil, accorder l'accès au service requis par l'utilisateur;
    5. e) si la valeur d'authentification est inférieure à la valeur de seuil, vérification si une donnée d'authentification non utilisée est disponible pour cet utilisateur;
    6. f) si aucune donnée d'authentification non utilisée n'est disponible pour cet utilisateur, refus de l'accès au service requis;
    7. g) si au moins une donnée d'authentification non utilisée est disponible pour cet utilisateur, répétition des étapes a) à f) en acquérrant une donnée d'authentification différente de celle(s) présentée(s) antérieurement et en combinant les valeurs d'authentification, ladite comparaison étant faite entre la valeur de seuil et la combinaison des valeurs d'authentification.
  • Selon la présente méthode, l'authentification d'un utilisateur souhaitant accéder à un service se fait de façon très souple. Le niveau de sécurité peut en particulier être adapté au service auquel l'utilisateur souhaite accéder et à d'autres conditions liées à l'environnement, telles que par exemple l'heure du jour. Un niveau de sécurité élevé peut être requis pour des services tels que des paiements ou tous services pour lesquels une usurpation d'identité peut avoir des conséquences importantes, alors qu'un niveau de sécurité plus bas peut être requis pour des services dans lesquels une usurpation d'identité a peu de conséquences.
  • Selon cette invention, l'utilisateur et le module d'authentification peuvent partager plusieurs secrets ou données d'authentification. Au moins l'une de ces données d'authentification est en principe introduite dans le module d'authentification lors d'une phase d'initialisation, par exemple à la conclusion d'un abonnement. Comme cela est expliqué en détail ci-dessous, il est possible qu'une seule donnée d'authentification ne soit pas suffisante pour accéder à tous les services proposés par un fournisseur. Il est possible d'introduire des secrets ou des données d'authentification supplémentaires en même temps que la première donnée d'authentification, ou par la suite, par exemple lorsque l'utilisateur souhaite pouvoir accéder à des services supplémentaires. Certaines données d'authentification peuvent être acquises sans la participation active et éclairée de l'utilisateur. Ainsi, le comportement de l'utilisateur peut être mémorisé sans que ce dernier en soit informé ou ne s'en rende compte, ce comportement formant un secret ou une donnée d'authentification utilisable dans le cadre de la présente invention.
  • Selon un mode de réalisation de l'invention, l'utilisateur peut choisir sur la base de quelle donnée d'authentification il souhaite accéder au service. A titre d'exemple, si un utilisateur peut accéder à un service au moyen d'une carte à puce, d'un mot de passe ou de données biométriques, il aura le choix du type de données et pourra accéder au service même s'il n'a pas la carte à puce à disposition, par exemple en choisissant d'utiliser les données biométriques.
  • Selon une variante, les données d'authentification à fournir au module d'authentification pourront varier en fonction du type de services requis. Un certain choix pourra toutefois être laissé à l'utilisateur. A titre d'exemple, l'accès à un service pour lequel l'usurpation d'identité aura peu de conséquences pourra être autorisé avec, au choix de l'utilisateur, une information parmi un mot de passe, une carte à puce ou une donné biométrique. L'accès à un service requérant un niveau de sécurité plus élevé pourra par exemple se faire seulement avec un mot de passe combiné avec une carte à puce ou le mot de passe combiné avec une donnée biométrique.
  • Selon une variante, le fournisseur de données peut suggérer ou imposer à l'utilisateur, les données d'authentification que celui-ci doit utiliser pour accéder au service requis. Dans cette variante, le fournisseur peut proposer d'utiliser un donnée d'authentification suffisante pour accéder au service requis, mais ayant la valeur la plus faible possible pour un tiers interceptant cette donnée. En effet, plus la valeur est élevée pour l'utilisateur, plus elle est également élevée pour un usurpateur. Il peut donc être intéressant d'utiliser les informations qui sont suffisantes pour accéder au service considéré, mais qui ont le moins de valeur possible pour un usurpateur.
  • La méthode de l'invention permet d'utiliser de façon efficace, des données d'authentification pour lesquelles la vérification de la conformité entre ce qui est reçu par le module d'authentification et ce qui est attendu peut être difficile à évaluer de façon binaire. Ceci peut être le cas par exemple en analysant le comportement de l'utilisateur lors de l'introduction d'un mot de passe ou d'une phrase secrète (passphrase). Un utilisateur donné aura généralement une manière d'écrire son mot de passe de façon reproductible. En particulier, le temps requis pour écrire le mot de passe, l'intervalle entre deux touches consécutives,.. seront très proches d'une fois à l'autre. Un autre utilisateur introduisant le même mot de passe aura très vraisemblablement un comportement différent. Ce type de données pourra être utilisé dans la méthode de l'invention.
  • Le niveau de sécurité minimal est en principe fixé par le fournisseur de services. Il est possible toutefois pour l'utilisateur de fixer un niveau de sécurité plus élevé que ce niveau minimal. Ceci peut être fait par chaque utilisateur, de façon individualisée. Cette augmentation du niveau de sécurité se fait généralement au détriment de la facilité d'utilisation. Chaque utilisateur pourra adapter le niveau de sécurité et la facilité d'utilisation selon ses désirs, dans le cadre fixé par le fournisseur de services. En règle générale, un utilisateur ne pourra toutefois pas fixer un niveau de sécurité en dessous du niveau de sécurité minimal fixé par le fournisseur de services pour le service considéré.
    • DESCRIPTION SOMMAIRE DES DESSINS
  • La présente invention et ses avantages seront mieux compris en référence aux figures annexées et à la description détaillée d'un mode de réalisation particulier, dans lesquelles :
    • la figure 1 illustre sous forme de schéma bloc, le déroulement de la méthode de l'invention;
    • la figure 2 représente de façon schématique, un exemple de réalisation de l'invention.
    MANIERES DE REALISER L'INVENTION
  • La présente invention concerne une méthode pour authentifier un utilisateur qui souhaite accéder à un service. Cette authentification se fait au moyen d'un module d'authentification, en utilisant une interface entre l'utilisateur et le module d'authentification.
  • Cette interface peut être un clavier tel qu'un clavier alphanumérique au moyen duquel l'utilisateur peut introduire un code d'accès, un mot de passe, une phrase secrète, une valeur résultant d'un calcul, ... L'interface peut également comporter un capteur et un dispositif de traitement, le capteur pouvant être utilisé pour la détection d'informations biométriques telles que les empreintes digitales, la reconnaissance faciale, la reconnaissance rétinienne,... L'interface comporte généralement un affichage permettant à l'utilisateur de lire des instructions qui lui sont destinées.
  • L'utilisateur peut être amené à introduire des données de façon active (mot de passe, code PIN,...) ou laisser l'interface acquérir les données (empreintes digitales, reconnaissance rétinienne, reconnaissance vocale, ...)
  • Le procédé de l'invention peut être utilisé pour accéder à un service spécifique d'un fournisseur, ce fournisseur proposant un accès à un ou plusieurs services. Un tel fournisseur de services peut par exemple être une banque, auquel cas les services peuvent être la consultation d'un ou plusieurs comptes, le transfert d'argent, les paiements, les retraits, etc. Un autre fournisseur pourrait être un fournisseur d'accès à des événements de télévision à péage ou à d'autres événements tels que des nouvelles, des informations boursières, la météo,...
  • Le procédé de l'invention peut également être utilisé pour accéder à des services proposés par un appareil tel qu'une tablette, une voiture, etc. Dans ce cas, le module d'authentification est intégré au dispositif ou à l'appareil offrant le service requis.
  • Avant de démarrer une procédure d'authentification, le module d'authentification requiert généralement une identification de l'utilisateur. Ceci permet à ce module de déterminer quelles sont les données et les paramètres à utiliser pour authentifier l'utilisateur. Cette identification peut se faire par exemple en demandant à l'utilisateur d'introduire un nom (user name) ou un code personnel (PIN code). Bien entendu, d'autres manières d'identifier un utilisateur peuvent être envisagées.
  • Dans le cas où le fournisseur ou l'appareil donne accès à plusieurs services différents, il est possible que ce fournisseur ou cet appareil demande à l'utilisateur d'indiquer en premier lieu, le service auquel il souhaite accéder. Il est également possible que le fournisseur d'accès ou l'appareil demande cette information dans un deuxième temps uniquement ou qu'il ne le demande pas du tout.
  • Lorsque l'utilisateur s'est identifié, le module d'authentification peut par exemple indiquer à l'utilisateur quels sont les services auxquels il pourrait avoir accès pour autant qu'une authentification réussisse.
  • Si le module d'authentification demande à quel service l'utilisateur souhaite accéder, cet utilisateur entre sa réponse par exemple au moyen de l'interface. Si le module d'authentification ne demande pas à quel service l'utilisateur souhaite accéder, l'interface acquiert une première donnée d'authentification correspondant à l'utilisateur. Cette première donnée d'authentification peut être par exemple un mot de passe tapé sur un clavier par l'utilisateur. Elle peut également être une donnée biométrique telle qu'une image de la rétine de l'utilisateur, etc. La première donnée d'authentification peut également être une combinaison de plusieurs éléments, par exemple une réponse à un calcul que l'utilisateur doit prononcer à haute voix, ce calcul pouvant être affiché à l'écran ou résulter d'une règle secrète convenue entre le fournisseur de services et l'utilisateur. Dans ce cas, la reconnaissance vocale peut être utilisée comme donnée d'authentification, éventuellement en plus de la règle secrète.
  • Cette donnée d'authentification initiale, de même que toutes les autres données d'authentification, est associée à au moins deux valeurs, l'une des valeurs étant associée à l'introduction correcte de la donnée d'authentification et l'autre valeur étant associée à l'introduction incorrecte de cette donnée d'authentification. Il est à noter que ces valeurs ne sont pas nécessairement statiques. Selon un mode de réalisation préféré, la valeur associée à l'introduction correcte de la donnée d'authentification est positive. La valeur associée à l'introduction incorrecte de la donnée d'authentification peut être nulle ou négative par exemple. Elle pourrait être positive, mais moins grande que la valeur associée à l'introduction d'une valeur d'authentification correcte.
  • Selon une variante, une donnée d'authentification est associée à plus de deux valeurs. Ceci pourrait être le cas d'une donnée d'authentification utilisant le comportement de l'utilisateur. Ce comportement n'étant pas strictement reproductible d'une fois à l'autre, différentes valeurs peuvent être associées à la donnée d'authentification, avec comme règle que plus le comportement mesuré lors d'une tentative de connexion s'éloigne du comportement mémorisé par le module d'authentification, plus la valeur attribuée est faible. Plusieurs valeurs pourraient également être associées à un mot de passe ou une phrase secrète, ce qui permettrait, dans une certaine mesure, d'accepter qu'un utilisateur introduise un mot de passe ou une phrase secrète avec une faute de frappe. Le fait d'avoir plusieurs valeurs associées à une donnée d'authentification est particulièrement intéressant dans les cas où les données d'authentification sont des données biométriques. Généralement, lors de l'utilisation de données biométriques, un nombre relativement important d'éléments sont mesurés et une correspondance est recherchée entre les éléments mesurés et les données correspondantes mémorisée pour l'utilisateur concerné. Dans les systèmes de l'art antérieur, une valeur limite est fixée. Si, pour un nombre de points supérieur à la valeur limite, les éléments mesurés et les données mémorisées concordent, l'authentification est considérée comme correcte. Si le nombre de données concordantes est inférieur à la valeur limite, l'authentification est considérée comme incorrecte.
  • Dans la présente invention, il est possible d'attribuer une valeur dépendant du nombre de points de concordance, selon une échelle beaucoup plus fine que dans les systèmes existants.
  • L'association entre une donnée d'authentification et une valeur d'authentification peut se faire de différentes façons. Par exemple, il est possible de définir une valeur fixe par type de donnée d'authentification. Généralement, plus le type de données d'authentification est facile à falsifier, plus la valeur est faible. Ainsi, un mot de passe aura généralement moins de valeur qu'une donnée biométrique. Dans le cas de l'attribution d'une valeur fixe par type de donnée, un mot de passe aura toujours la même valeur quel que soit le mot de passe.
  • Il est également possible d'attribuer une valeur ne dépendant pas uniquement du type de donnée, mais également de la donnée elle-même. Dans ce cas là, un mot de passe court tiré du vocabulaire courant aura une valeur moins grande qu'un mot de passe long comprenant des majuscules et des minuscules, des caractères particuliers et des chiffres.
  • La valeur d'authentification pour une donnée d'authentification déterminée peut également dépendre d'autres paramètres tels que par exemple l'heure du jour et/ou le jour de la semaine. Un même mot de passe permettant par exemple l'accès à des services de paiement destinés à des entreprises, pourrait ainsi avoir une valeur élevée pendant les heures d'ouverture de l'entreprise et une valeur plus faible en dehors de ces périodes. Ceci permet de tenir compte du fait qu'une demande d'accès au service en dehors des heures ouvrables a plus de risques d'être le fait d'un usurpateur que la même demande d'accès pendant les heures d'ouverture de l'entreprise. Ces heures d'ouverture pourraient être définies par l'entreprise elle-même, de façon individualisé et ne serait pas nécessairement commune à tous les services et tous les utilisateur de services d'un fournisseur déterminé. La valeur d'authentification peut également dépendre de l'historique de l'utilisateur ou de la demande d'accès. Ainsi, l'introduction pour la première fois, d'un mot de passe faux pourrait être associée à une première valeur négative. L'introduction pour la deuxième fois lors de la même demande d'accès, d'un mot de passe faux pourrait être associée à une deuxième valeur négative, différente de la première valeur et ayant une valeur absolue plus grande que celle de la première valeur.
  • Selon une variante, un poids pourrait être associé aux tentatives de connexion échouées. Ainsi, un poids de 1 pourrait par exemple être associé à l'introduction d'une première donnée d'authentification fausse, un poids de 1.2 à l'introduction d'une deuxième donnée d'authentification fausse et un poids de 1.5 à l'introduction d'une troisième donnée d'authentification fausse.
  • Selon la méthode de l'invention, lorsque l'interface a acquis une donnée d'authentification, le module d'authentification attribue une valeur d'authentification à cette donnée. Pour ceci, le module d'authentification détermine quels sont les différentes valeurs possibles pour cette donnée d'authentification, quelles sont les conditions associées à ces valeurs possibles et quelle condition spécifique, la donnée d'authentification introduite par l'utilisateur rempli.
  • Selon un mode de réalisation simple, les conditions peuvent être l'attribution de la valeur maximale si la donnée d'authentification introduite est identique à la donnée d'authentification mémorisée ou attendue par le module d'authentification et une valeur nulle dans le cas contraire.
  • Le module d'authentification détermine ensuite quelle valeur de seuil doit être atteinte pour accéder au service requis par l'utilisateur. Ce seuil est mémorisé par le module d'authentification est peut être fixe pour un service ou au contraire dépendre de différents paramètres. Ces paramètres peuvent être par exemple une période dans la journée ou certains jours de la semaine. Ils peuvent également tenir compte du lieu à partir duquel un utilisateur souhaite accéder à un service. Le lieu d'où provient la demande d'accès pourrait également être considéré comme une donnée d'authentification.
  • Dans l'étape suivante de la méthode, le module d'authentification vérifie si la valeur d'authentification initiale atteinte par l'utilisateur est supérieure ou égale à la valeur de seuil pour le service considéré. Si la réponse à cette question est positive, l'accès au service est autorisé.
  • Si la réponse à cette question est négative, la méthode se poursuit par la recherche d'une donnée d'authentification supplémentaire pour cet utilisateur. Le module d'authentification dispose, pour chaque utilisateur, d'un répertoire des données d'authentification disponibles. De plus, les données d'authentification qui ont déjà été utilisées lors de la procédure de connexion en cours sont marquées comme non disponibles ou utilisées. Le module d'authentification est donc en mesure de savoir si d'autres données d'authentification sont disponibles pour l'utilisateur en question.
  • Si aucune donnée d'authentification supplémentaire n'est disponible et que la valeur d'authentification n'a pas atteint le seuil, l'accès au service est refusé. Si au contraire, une ou des données d'authentification supplémentaires sont disponibles, l'interface acquiert une telle donnée d'authentification. Cette acquisition se fait de manière similaire à l'acquisition de la donnée d'authentification initiale.
  • Il est à noter que si plusieurs données d'authentification sont disponibles, plusieurs variantes sont envisageables. Selon une variante, l'utilisateur choisi quelle donnée d'authentification il souhaite utiliser. Selon une autre variante, un ordre d'utilisation est défini et le module d'authentification s'en tient à cet ordre. Selon une autre variante, le module d'authentification choisi une donnée d'authentification supplémentaire qui permettra à l'utilisateur d'accéder au service si l'authentification est réussie, mais qui aura la valeur d'authentification la plus faible possible pour permettre l'accès à ce service. Ceci peut être intéressant du fait qu'en principe, plus une donnée d'authentification a une valeur d'authentification élevée, plus elle sera intéressante à intercepter pour un usurpateur. Il est donc judicieux d'utiliser, et potentiellement de divulguer, une information ayant la valeur la plus faible possible pour atteindre le but recherché, à savoir accéder à un service déterminé. Dans ce contexte là, il est également possible d'indiquer à l'utilisateur quelle est la valeur d'authentification qu'il a atteint, quelle valeur de seuil il doit atteindre et quelles sont les valeurs d'authentification des différentes données d'authentification dont il dispose. Ainsi, il pourra choisir au mieux, la donnée d'authentification qu'il utilisera.
  • Lorsque cette donnée d'authentification est choisie et acquise par le module d'authentification au moyen de l'interface, une valeur d'authentification lui est attribuée comme précédemment. Cette valeur est nommée ici valeur d'authentification supplémentaire. Cette valeur d'authentification supplémentaire est combinée à la valeur d'authentification mémorisée, qui correspond à la valeur d'authentification initiale.
  • La combinaison pourrait être simplement l'addition des deux valeurs. Cette addition n'est toutefois pas la seule solution possible. Il est par exemple possible d'ajouter un "poids" à chaque valeur d'authentification. Le poids pourrait être de 1 pour la valeur initiale, de 0.9 pour la première valeur supplémentaire, 0.8 pour la deuxième valeur supplémentaire, etc.. Il est clair que l'invention n'est pas limitée aux combinaisons décrites ici.
  • Le résultat de cette combinaison est nommé valeur d'authentification combinée, cette valeur étant mémorisée soit à la place de la valeur d'authentification initiale, soit en plus de cette valeur. La valeur d'authentification combinée est comparée à la valeur de seuil. Si le seuil est atteint ou dépassé, l'accès au service est autorisé. Sinon, comme précédemment, le module d'authentification détermine s'il dispose encore de données d'authentification supplémentaires pour cet utilisateur.
  • La méthode se poursuit ainsi, en combinant à chaque tour, la valeur d'authentification mémorisée et la valeur d'authentification supplémentaire. Cette méthode prend fin soit lorsque la valeur d'authentification combinée atteint ou dépasse le seuil, soit lorsque toutes les données d'authentification disponibles pour cet utilisateur ont été utilisées, sans que la valeur de seuil soit atteinte.
  • Il est également possible de limiter le nombre de tours de la méthode en imposant un nombre maximal de données d'authentification par tentative de connexions. Ainsi, même si le module d'authentification dispose par exemple de cinq données d'authentification ou cinq secrets pour un utilisateur donné, un maximum de trois données peuvent être utilisées pour l'accès au service. Si le seuil n'est pas atteint après l'utilisation de ces trois données d'authentification, l'accès est refusé
  • Selon un exemple concret illustré par la figure 2, supposons que l'utilisateur ait à sa disposition quatre éléments associés à des données d'authentification, à savoir :
    • une carte à puce associée à une valeur de 60 lorsque cette carte donne un résultat correct et une valeur de -10 si la carte donne un résultat erroné;
    • un mot de passe correspondant à une valeur de 30 lorsqu'il est introduit correctement et de zéro s'il est introduit de façon incorrecte;
    • une donnée biométrique associée à la reconnaissance faciale de l'utilisateur, cette donnée étant associée à une valeur de 70 si la reconnaissance vocale est totalement réussie, de zéro si elle est partiellement réussie et de -50 si l'authentification échoue; et
    • une règle secrète, consistant pour l'utilisateur, à multiplier par 4, la valeur que le fournisseur indique à l'utilisateur. Cette règle secrète est associée à une valeur de 55 si la réponse de l'utilisateur est juste et de -10 si elle est fausse
  • Dans un premier exemple d'utilisation de l'invention, le fournisseur de services propose deux services. L'accès au premier service est autorisé dès le moment où la valeur d'authentification dépasse un seuil fixé, par exemple 80. Le seuil pour la valeur d'authentification permettant d'accéder au deuxième service est fixé à 120 dans notre exemple.
  • Selon cet exemple de réalisation, lorsque l'utilisateur souhaite accéder au service, le module d'authentification indique à l'utilisateur qu'il doit fournir une donnée d'authentification. Selon l'implémentation, l'utilisateur peut avoir le choix du type de donnée qu'il souhaite introduire ou au contraire, ce choix peut être imposé par le module d'authentification.
  • Supposons ici que le choix soit laissé à l'utilisateur et que ce dernier choisisse d'utiliser la carte à puce. Si les données lues à partir de la carte à puce par l'interface correspondent aux données attendues par le module d'authentification, une valeur d'authentification initiale de 60 est attribuée à cet utilisateur. Cette valeur d'authentification initiale est comparée à la valeur de seuil, qui est de 80 dans l'exemple considéré, pour le premier service. La valeur d'authentification initiale est inférieure à la valeur de seuil. L'accès au premier service n'est alors pas autorisé à ce stade.
  • Le module d'authentification vérifie ensuite si une autre donnée d'authentification est disponible pour cet utilisateur. Cette autre donnée peut être un mot de passe ou toute autre donnée d'authentification, mais doit bien entendu être différent de la donnée d'authentification déjà utilisée. Pour ceci, les données d'authentification déjà utilisées lors d'une tentative de connexion sont marquées comme utilisées ou non disponibles.
  • Dans l'exemple décrit, trois autres données d'authentification sont disponibles, à savoir un mot de passe, une règle secrète et une donnée biométrique. Selon un premier mode de réalisation, l'utilisateur a le choix du type de données qu'il souhaite utiliser parmi les données possibles non encore utilisées. Selon un deuxième mode de réalisation, le module d'authentification impose le type de données. Dans un mode de réalisation avantageux, le module d'authentification imposera le type de données qui a la valeur la plus faible possible pour atteindre la valeur de seuil.
  • Dans notre exemple, l'utilisateur utilisera le mot de passe. Si ce mot de passe est introduit correctement et correspond à ce qui est attendu par le module d'authentification, une valeur d'authentification supplémentaire est attribuée à l'utilisateur. Dans l'exemple, cette valeur est de 40.
  • La valeur d'authentification initiale (60) et la valeur d'authentification supplémentaire (40) sont combinées. Dans le cas d'une combinaison correspondant à une addition, le résultat de la combinaison est dénommé valeur d'authentification combinée et serait de 60 + 40 = 100, selon l'exemple.
  • Cette valeur d'authentification combinée est comparée à la valeur de seuil qui est de 80 dans l'exemple. La valeur d'authentification combinée est supérieure à la valeur de seuil. Il en résulte que l'accès au premier service est autorisé.
  • Il va de soi que qu'il est possible de définir que l'accès au service est autorisé dès que la valeur de seuil est atteinte ou au contraire, d'imposer que cette valeur de seuil soit dépassée.
  • Si l'utilisateur souhaite accéder au deuxième service, qui requiert une valeur d'authentification supérieure ou égale à 120, il pourra par exemple utiliser la règle secrète, qui consiste à multiplier par 4, la valeur affichée sur l'interface. Dans l'exemple considéré, illustré par la figure 2, imaginons que l'utilisateur introduise un résultat erroné en réponse à la règle secrète. Ce résultat erroné est associé à une valeur de -50. En reprenant le cas où la combinaison est une adition des valeurs d'authentification, la valeur d'authentification combinée sera de 100 - 50 = 50. Cette valeur étant inférieure à la valeur de seuil pour le deuxième service, l'utilisateur n'y aura pas accès.
  • Il est à noter que la valeur obtenue est également inférieure à la valeur de seuil pour le premier service. Dans ce cas, plusieurs variantes sont possibles. Dans une première variante, comme l'utilisateur avait accès précédemment au premier service, aussi longtemps que cet utilisateur ne se déconnecte pas, la valeur de seuil du premier service n'est pas contrôlée et l'utilisateur continue d'avoir accès à ce premier service.
  • Dans une autre variante, la valeur de seuil est contrôlée lors de chaque utilisation d'une donnée d'authentification. Comme la valeur d'authentification combinée (50) est inférieure à la valeur de seuil (80) pour le premier service, l'accès à ce service est désactivé et l'utilisateur doit utiliser une nouvelle donnée d'authentification pour accéder aux services, que ce soit le premier ou le deuxième service.
  • Dans l'exemple choisi, le module d'authentification dispose encore d'une donnée d'authentification disponible pour cet utilisateur, à savoir une donnée biométrique. L'utilisateur qui choisit d'accéder au deuxième service laisse l'interface acquérir les données biométriques. Si l'authentification se fait de façon correcte, la valeur d'authentification de ces données biométriques, qui est de 70 dans l'exemple. La combinaison de la valeur d'authentification supplémentaire liée à la donnée biométrique avec la valeur d'authentification combinée mémorisée, liée aux trois autres données utilisées, donne une valeur de 50 + 70 = 120. Cette valeur d'authentification combinée est égale au seuil de 120 permettant d'accéder au deuxième service. L'accès est donc autorisé à cet utilisateur.
  • Comme on peut le voir dans cet exemple, il est possible que l'utilisateur soit autorisé à accéder à un service malgré le fait qu'au moins une des données d'authentification ne corresponde pas au résultat attendu. Comme on peut également le voir de cet exemple, les valeurs d'authentification sont mémorisées lors du déroulement de la méthode.
  • Les données d'authentification ou les secrets déjà utilisés ne peuvent plus être utilisés lors de cette connexion à un service, faute de quoi il serait possible d'atteindre n'importe quelle valeur en introduisant une même donnée, par exemple un mot de passe correct, un nombre suffisant de fois. Une donnée d'authentification déjà utilisée de façon correcte est donc marquée comme telle. Une donnée d'authentification que l'utilisateur a cherché à utiliser, sans succès, par exemple un mot de passe incorrect, peut être marquée comme inutilisable pour cette tentative de connexion. Elle peut également ne pas être marquée ou marquée comme utilisable. Dans ce cas, l'utilisateur peut tenter autant de fois qu'il le souhaite, d'utiliser la donnée d'authentification. Finalement, selon un mode de réalisation préféré, chaque tentative d'utiliser une donnée d'authentification est mémorisée et le nombre de tentatives pendant une session de connexion est limité, par exemple à trois. Si après trois tentatives échouées, la donnée d'authentification n'a pas pu être utilisée, selon l'implémentation choisie, l'accès aux services est bloqué, même si d'autres données d'authentification sont encore disponibles, ou au contraire, uniquement l'utilisation de la donnée d'authentification ayant conduit à un échec est bloquée, les autres données d'authentification étant encore utilisables.
  • Il est à noter qu'un mélange de ces variantes est possible. Par exemple, pour la consultation de comptes bancaires, trois erreurs de code PIN entraînent une interdiction d'utiliser ce code PIN pendant la connexion en cours, cette connexion étant toujours possible au moyen d'une carte à puce. Par contre, pour les retraits d'argent d'une somme supérieure à X, trois erreurs aboutissent à un blocage de la connexion.
  • Supposons maintenant que l'utilisateur qui cherche à accéder à un service introduise d'abord une carte à puce reconnue comme valide, puis le mot de passe de façon erronée. Dans cet exemple, le mot de passe erroné est associé à une valeur de -50. Le module d'authentification, lors de la vérification de l'existence de données d'authentification supplémentaires pour cet utilisateur constatera qu'il dispose bien de données d'authentification. Supposons que l'utilisateur introduise un résultat faux lors de l'utilisation de la règle secrète. La valeur d'authentification combinée sera de 60 - 50 - 50 =-40, en appliquant les principes décrits ci-dessus. Le module d'authentification vérifiera s'il dispose d'autres données d'authentification. Dans un premier mode de réalisation, le module d'authentification demandera à l'utilisateur d'utiliser ces données en introduisant des données d'authentification supplémentaires. Dans un deuxième mode de réalisation avantageux, avant de demander à l'utilisateur d'introduire des données d'authentification supplémentaires, le module d'authentification vérifiera si la combinaison de la valeur d'authentification combinée actuelle (-40) et de la valeur d'authentification que l'utilisateur peut obtenir avec toutes les données d'authentification dont dispose ce module d'authentification (70), est suffisante pour atteindre la valeur de seuil. Si tel n'est pas le cas, il indiquera à l'utilisateur que l'accès au service est refusé.
  • Dans l'exemple ci-dessus, l'utilisateur a une valeur d'authentification combinée actuelle de -40. Le module d'authentification dispose d'une seule donnée d'authentification pour cet utilisateur, dont la valeur est de 70. Quelle que soit la valeur obtenue lors de l'authentification utilisant cette donnée supplémentaire, la valeur d'authentification combinée n'atteindra pas la valeur de seuil et l'accès sera refusé. Il est donc d'une part inutile et d'autre part risqué, de demander à l'utilisateur d'introduire la dernière donnée d'authentification. En effet, cette donnée pourrait être mémorisée par un usurpateur.
  • Selon un mode de réalisation concret, si le fournisseur de services est par exemple un établissement financier, un premier seuil pour un premier service pourrait être associé à la consultation des comptes de l'utilisateur. Un deuxième seuil, généralement plus élevé que le premier seuil pourrait être associé à des transferts d'un compte de l'utilisateur à un autre compte du même utilisateur. Un troisième seuil pourrait être associé à des paiements d'un montant inférieur à une certaine somme et enfin un quatrième seuil pourrait être associé à des paiements supérieurs à cette somme.
  • Dans le cas où le fournisseur est un fournisseur d'événements de télévision à péage par exemple, un premier seuil pourrait être associé à l'accès à un canal ou un ensemble de canaux déterminés et un deuxième seuil pourrait être associé à un autre ensemble de canaux.
  • Dans ces cas, plusieurs variantes de la méthode de l'invention peuvent être utilisées. Selon une première variante, l'utilisateur doit indiquer, par exemple avant d'introduire la première donnée d'authentification, à quel service il souhaite accéder. Il peut également indiquer le service juste après l'introduction de la première donnée d'authentification, avant l'introduction de la donnée d'authentification supplémentaire. La suite du procédé se déroule de la même manière que ce qui a été décrit précédemment, le seuil utilisé dépendant du service auquel l'utilisateur souhaite accéder.
  • Selon une deuxième variante, l'utilisateur n'indique pas à quel service il souhaite accéder, mais le module d'authentification indique une liste des services auxquels l'utilisateur peut accéder en fonction de la valeur d'authentification combinée atteinte. Cette liste peut augmenter au fur et à mesure que l'utilisateur introduit des données d'authentification correctes ou au contraire, diminuer si des données incorrectes sont introduites. L'utilisateur peut arrêter d'introduire des données d'authentification dès lors que le service auquel il souhaite accéder est disponible.
  • Le module d'authentification peut également indiquer à l'utilisateur tous les services proposés, cette indication se faisant sous la forme de deux listes. L'une des listes peut comporter les services auxquels l'utilisateur a accès, en particulier en tenant compte de la valeur d'authentification combinée atteinte par l'utilisateur et l'autre liste contenant les services auxquels l'utilisateur n'a pas accès. Les listes peuvent être distinguées par des couleurs, par exemple vert pour les services accessibles et rouge pour les autres ou noir pour les services accessibles et gris pour les autres.
  • Il est à noter que les données d'authentification, ainsi que les services proposés, ne sont pas nécessairement communiqués par le module d'authentification. Il en découle la possibilité pour ce dernier de collecter des données d'authentification (notamment de type "comportement" ou biométrique) à l'insu de l'utilisateur et d'utiliser ensuite ces données pour élaborer la valeur d'authentification.
  • Selon une variante, la valeur combinée acquise par l'utilisateur lors d'une session est mémorisée. Ainsi, si l'utilisateur a introduit suffisamment de données d'authentification pour consulter ses comptes dans un établissement bancaire, sans toutefois être autorisé à faire un paiement, il devra introduire des données d'authentification additionnelles lorsqu'il souhaitera faire un paiement.
  • Selon une autre variante, l'accès à un service pourrait être accordé à un utilisateur dès lors que la valeur d'authentification a atteint le seuil, mais le comportement du fournisseur de services pourrait être différent en fonction de cette valeur d'authentification. A titre d'exemple, l'accès à un service pourrait être accordé dès lors que la valeur d'authentification a atteint 50. Toutefois, si la valeur d'authentification n'a pas dépassé 80, des informations par exemple relatives aux opérations effectuées ou à un lieu ou une adresse logique à partir desquelles les opérations sont effectuées, sont mémorisées.
  • La présente invention propose plusieurs variantes pour la gestion de l'authentification d'un utilisateur. Ces variantes peuvent être combinées entre elles.
  • Cette invention offre une grande souplesse, ce qui permet à l'utilisateur d'avoir accès à des services selon une procédure qui lui convient le mieux.
  • Cet utilisateur peut également paramétrer dans une certaine mesure, le niveau de sécurité qu'il souhaite avoir. Ainsi, si le fournisseur impose une valeur minimale de 80 pour l'accès à un certain service, l'utilisateur pourra définir que, pour ce service spécifique, la valeur d'authentification combinée doit être 90 au lieu de 80. Etant donné que dans ce cas, c'est l'utilisateur qui choisit d'augmenter le niveau de sécurité, il sera prêt à accepter une diminution de la facilité d'usage qui en résulte généralement.
  • Il est également possible de prévoir que le fournisseur définisse une certaine plage, par exemple entre 70 et 90, qu'il fixe par défaut une certaine valeur, par exemple 80 et que l'utilisateur puisse préciser la valeur qu'il souhaite utiliser, dans la plage de valeurs définie par le fournisseur.
  • Dans les différents exemples et modes de réalisation décrits ci-dessus, il est possible d'afficher, à l'attention de l'utilisateur, les valeurs d'authentification. Ainsi, il est par exemple possible à chaque instant, d'afficher la valeur d'authentification actuelle ainsi que la valeur d'authentification de chaque donnée disponible pour cet utilisateur. Au contraire, il est également possible de ne rien afficher et d'avoir une méthode d'authentification totalement transparente pour l'utilisateur. Il est également possible d'afficher uniquement une partie des informations liées à l'authentification.

Claims (11)

  1. Méthode d'authentification d'un utilisateur par un module d'authentification, ledit module d'authentification gérant l'accès à une pluralité de services et comprenant un seuil d'authentification pour chaque service, au moins deux données d'authentification étant associées audit utilisateur, ladite méthode comprenant les étapes suivantes :
    a) acquisition d'au moins une donnée d'authentification de l'utilisateur, au moyen d'une interface entre cet utilisateur et ledit module d'authentification;
    b) vérification de ladite au moins une donnée d'authentification et attribution d'une valeur d'authentification à l'utilisateur, en fonction du résultat de la vérification;
    c) comparaison de la valeur d'authentification avec la valeur de seuil pour le service requis;
    d) si la valeur d'authentification est égale ou supérieure à la valeur de seuil, accorder l'accès au service requis par l'utilisateur;
    e) si la valeur d'authentification est inférieure à la valeur de seuil, vérification si une donnée d'authentification non utilisée est disponible pour cet utilisateur;
    f) si aucune donnée d'authentification non utilisée n'est disponible pour cet utilisateur, refus de l'accès au service requis;
    g) si au moins une donnée d'authentification non utilisée est disponible pour cet utilisateur, répétition des étapes a) à f) en acquérrant une donnée d'authentification différente de celle(s) présentée(s) antérieurement et en combinant les valeurs d'authentification, ladite comparaison étant faite entre la valeur de seuil et la combinaison des valeurs d'authentification.
  2. Méthode d'authentification selon la revendication 1, caractérisée en ce que la valeur d'authentification attribuée à une donnée d'authentification dépend de la concordance entre la donnée d'authentification acquise par ladite interface et la donnée d'authentification correspondante mémorisé par ledit module d'authentification.
  3. Méthode d'authentification selon la revendication 1, caractérisée en ce que la combinaison des valeurs d'authentification est une addition desdites valeurs d'authentification.
  4. Méthode d'authentification selon la revendication 1, caractérisée en ce que chaque donnée d'authentification est associée à au moins deux valeurs d'authentification distinctes.
  5. Méthode d'authentification selon la revendication 4, caractérisée en ce que l'une des valeurs d'authentification associée à une donnée d'authentification est attribuée en cas d'identité entre la donnée d'authentification acquise par l'interface et la donnée d'authentification correspondante mémorisée par le module d'authentification, une autre des valeurs d'authentification étant attribuée en cas de différence entre la donnée d'authentification acquise par l'interface et la donnée d'authentification correspondante mémorisée par le module d'authentification.
  6. Méthode d'authentification selon la revendication 1, caractérisée en ce que les données d'authentification sont associées à au moins trois valeurs d'authentification distinctes, et en ce que plus il y a de différences entre une donnée d'authentification acquise par l'interface et la donnée d'authentification correspondante mémorisée par le module d'authentification, plus la valeur d'authentification attribuée est basse.
  7. Méthode d'authentification selon la revendication 1, caractérisée en ce que chaque service étant associé à une valeur de seuil différente.
  8. Méthode d'authentification selon la revendication 1, caractérisée en ce que le module d'authentification indique à l'utilisateur la donnée d'authentification que cet utilisateur doit utiliser.
  9. Méthode d'authentification selon la revendication 8, caractérisée en ce que le module d'authentification choisi, en fonction du seuil correspondant au service requis par l'utilisateur et en fonction de la valeur d'authentification atteinte par l'utilisateur, le service ayant la valeur d'authentification la plus faible possible permettant l'accès audit service.
  10. Méthode d'authentification selon la revendication 1, caractérisée en ce que le module d'authentification indique à l'utilisateur au moins la valeur de seuil pour l'accès audit service, la valeur d'authentification combinée atteinte par l'utilisateur et la valeur d'authentification des données d'authentification non utilisées, disponibles pour ledit utilisateur.
  11. Méthode d'authentification selon la revendication 1, caractérisée en ce qu'au moins trois données d'authentification sont associées audit utilisateur et dans laquelle ledit utilisateur peut accéder à un service soit en utilisant une seule donnée d'authentification parmi lesdites au moins trois données d'authentification, soit en utilisant au moins deux autres données d'authentification parmi les données d'authentification différentes de la donnée d'authentification permettant à elle seule, l'accès audit service.
EP20130192404 2013-11-12 2013-11-12 Méthode d'authentification d'un utilisateur par un module d'authentification Withdrawn EP2871615A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP20130192404 EP2871615A1 (fr) 2013-11-12 2013-11-12 Méthode d'authentification d'un utilisateur par un module d'authentification

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP20130192404 EP2871615A1 (fr) 2013-11-12 2013-11-12 Méthode d'authentification d'un utilisateur par un module d'authentification

Publications (1)

Publication Number Publication Date
EP2871615A1 true EP2871615A1 (fr) 2015-05-13

Family

ID=49582581

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20130192404 Withdrawn EP2871615A1 (fr) 2013-11-12 2013-11-12 Méthode d'authentification d'un utilisateur par un module d'authentification

Country Status (1)

Country Link
EP (1) EP2871615A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040189441A1 (en) * 2003-03-24 2004-09-30 Kosmas Stergiou Apparatus and methods for verification and authentication employing voluntary attributes, knowledge management and databases
US20070177768A1 (en) * 2005-09-02 2007-08-02 Intersections, Inc. Method and system for confirming personal identity
WO2009097179A1 (fr) * 2008-01-31 2009-08-06 First Data Corporation Procédé et système d'authentification d'identités de clients

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040189441A1 (en) * 2003-03-24 2004-09-30 Kosmas Stergiou Apparatus and methods for verification and authentication employing voluntary attributes, knowledge management and databases
US20070177768A1 (en) * 2005-09-02 2007-08-02 Intersections, Inc. Method and system for confirming personal identity
WO2009097179A1 (fr) * 2008-01-31 2009-08-06 First Data Corporation Procédé et système d'authentification d'identités de clients

Similar Documents

Publication Publication Date Title
WO2013021107A9 (fr) Procede, serveur et systeme d'authentification d'une personne
FR2864289A1 (fr) Controle d'acces biometrique utilisant un terminal de telephonie mobile
US8327420B2 (en) Authentication system and method
FR3058243A1 (fr) Procede de controle d'identite d'un utilisateur au moyen d'une base de donnees publique
FR2747208A1 (fr) Procede de dissimulation d'un code secret dans un dispositif d'authentification informatique
EP3729307B1 (fr) Procédés et dispositifs pour l'enrôlement et l'authentification d'un utilisateur auprès d'un service
FR2852471A1 (fr) Dispositif d'authentification du type utilisant un mot de passe a usage unique et dispositif generateur de mot de passe associe
EP2871615A1 (fr) Méthode d'authentification d'un utilisateur par un module d'authentification
EP2492834A1 (fr) Procédé d'authentification d'un utilisateur
EP2813962A1 (fr) Méthode de contrôle d'accès à un type de services spécifique et dispositif d'authentification pour le contrôle de l'accès à un tel type de services.
WO2021122186A1 (fr) Procédé et dispositif de contrôle d'accès anonyme à une plateforme collaborative d'anonymisation
FR3051944A1 (fr) Procede pour renseigner des informations personnelles d'un utilisateur demandees par un service en ligne donne
EP2048592B1 (fr) Procédé d'authentification biométrique, système d'authentification, programme et terminal correspondants
FR3093225A1 (fr) Procédé de gestion d’accès d’un utilisateur à un service vocal, dispositif, système et programmes correspondants
FR3114714A1 (fr) Procédé d’accès à un ensemble de données d’un utilisateur.
WO2018029564A1 (fr) Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central
EP3926499A1 (fr) Procédé d'authentification d'un utilisateur sur un équipement client avec un système d'archivage sécurisé de justificatifs d'identité
WO2022184726A1 (fr) Procédé pour permettre à des utilisateurs de déployer des contrats intelligents dans une chaîne de blocs au moyen d'une plateforme de déploiement
WO2007113409A1 (fr) Procede et dispositif de gestion des instances d'une application informatique
EP3395042B1 (fr) Serveur d'authentification pour le contrôle d'accès a un service
FR2913551A1 (fr) Methode d'authentification mutuelle et recurrente sur internet.
EP2911083B1 (fr) Méthode d'accès aux données d'au moins une personne physique ou morale ou d'un objet
EP3394780A1 (fr) Procede et dispositif de connexion a un serveur distant
EP3012996A1 (fr) Évaluation d'un niveau de confiance dans la récolte d'informations par un terminal de communication par rapport des empreintes
CA2910708C (fr) Procede pour generer au moins une identite derivee

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20131112

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20151114