ES2357564T3 - USER AUTHENTICATION METHOD AND SYSTEM IN RESPONSE TO INSTANCE. - Google Patents

Abstract

An instance-response based method for the authentication of a user in a communications system, which has at least the user associated with an authentication center, characterized by the steps of: - generating (S12), in the authentication center (50, 150, 550), an expected response by means of a response function (14), from a secret key, shared with the user, and a random instance (S11); - generating (S14), in said authentication center, an expected masked response by means of a masking function (16), in response to said expected response; - transmitting (S21) said expected masked response and said random instance to an intermediate or intermediary party (200); - so that the intermediary part transmits (S31) said random instance to the user (400); - generating (S32), in said user, a response by said response function in response to said secret key and said random instance; - transmitting (S33) said user response to said intermediary party; generate (S42), in said intermediate part, a masked user response by means of the same masking function as that of said authentication center, in response to said user response; - in such a way that said intermediate part authenticates the user in response to a positive result of the verification that said masked user response corresponds to said expected masked response (S51, D52).

Description

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to authentication procedures in communication systems and, more particularly, to user authentication in response to an instance, which involves a third party in addition to the user and the authentication center to which the user is associated .

BACKGROUND OF THE INVENTION

Many current communication systems, including mobile communication systems, remote location systems as well as wireless or wireless data networks and cable lines, use authentication and encryption or encryption procedures for the purpose of improving security and security. system robustness.

In mobile communication systems, for example, users are authenticated for the network and / or service providers in order to access network services, and authentication also serves as a basis for billing to the users. The basic security protocol for modem communication systems [modulator-demodulator] normally involves an authentication procedure in response to instance, in most cases based on secret key cryptography. Authentication in response to instance is well known in the art and there are several rules on basic authentication in response to instance, for example, for GSM networks (Global System for Mobile Communications - “Global System for Mobile Communications”) and UMTS (Universal Mobile Telecommunications System).

As illustrated in Figure 1, a typical scenario in a modem communication system not only involves the user and the authentication center with which the user is associated, but also an intermediate part

or intermediary, such as an independent network operator or other service provider. Typically, the authentication center is related to a domestic operator with whom the user has a trust relationship, for example, established through a subscription or a prepaid account. This established trust relationship is typically embodied in a cryptographic relationship, for example, through a shared secret key (symmetric cryptography). The home operator authentication center, or, more specifically, the home network operator, may have a service agreement with the intermediary party, an agreement that is typically embodied or materialized by a similar cryptographic relationship. However, the relationship between the user and the intermediary is generally considered as an induced trust relationship that is established when the services offered by the intermediary party are requested or otherwise initiated.

Figure 2 is a schematic diagram of an authentication procedure in response to a typical instance of the prior art, which involves a user, an associated domestic operator authentication center and an intermediary party. For example, the conventional AKA (Authentication and Key Agreement) procedure that is used in communications systems such as GSM and UMTS networks includes an instance response procedure based on a key secret The secret key, denoted by Ki, is usually the subscription key associated with a user-operator subscription or subscription, or a key obtained from it. The intermediary can be, for example, a network node that manages a network within which the user is traveling on a mobile journey, or another type of service provider that offers services in relation to the user.

For the authentication of a given user in the intermediary part, the user is normally requested to send a user ID to the intermediary party, which, in turn, sends this ID to the home operator authentication center in a data request Authentication In order to assist user authentication, the home authentication center generates an expected response XRES ("expected response") based on the secret key Ki associated with this particular user and a random instance RAND ("random") as inputs for a given function g. Normally, the authentication center may also generate additional information such as a confidentiality key, an integrity key and an authentication tab. In the GMS AKA, no integrity key or authentication token is used, but the basic procedure of response to instance is the same. The instance RAND and the expected response XRES, together with the additional information, are sent to the intermediary party that wishes to authenticate the user. The intermediary party sends the instance RAND and possibly the authentication card to the user. The user, preferably with the help of a subscriber identity module (SIM  "subscriber identity module" US or USIM), generates a RES response based on the shared secret key Ki (stored securely in the SIM or the USIM) , and the RAND of the received instance, as inputs for the same function g that is used by the authentication center. The user then sends the RES response received back to the intermediary party. To authenticate the user, the intermediary party simply verifies that the RES response received from the user is equal to the expected XRES response received from the authentication center.

The transmission of authentication parameters between the authentication center and the intermediary party can be cryptographically protected. In the UMTS, for example, the MAPSec security protocol can be used. The MAPSec protocol has been standardized in 3GPP [3rd Generation Partnership Project - “3rd Generation Partnership Project”], but it has not been developed.

It is normally required that it is possible to distribute the authentication data in advance and that it is possible to carry out the authentication procedure further, without a renewed contact with the authentication center.

There are two main threats to the previous basic authentication procedure in response to instance. The first danger is that a malicious third party, such as an independent network operator or other service provider, may request authentication data from the authentication center and subsequently falsely claim that a user has been roaming within the network or has otherwise used services offered, and finally require payment of the services. The authentication center cannot ask for any proof to substantiate it, since the current systems have no capacity for such a function.

The second danger is that authentication parameters can be intercepted when they are sent from the authentication center to the intermediary party, or read in an illegally intervened or "pirated" node of the intermediary party. The subtracted authentication parameters can then be used to authenticate fraudulently as the user to which the parameters are associated. Such an attack is based on the ability to steal the authentication data and use it before the real user does it. For example, such an attack is possible when a user is roaming between networks and the authentication parameters are stored for further use in the network from which the user is leaving.

RELATED TECHNIQUE

US Patent No. 5,596,641 describes a method of authenticating a mobile mobile traveling unit in mobile communication systems. The method comprises two stages: a preliminary authentication stage and a main authentication stage. In the preliminary stage, a plurality of pairs of first instances and expected responses are sent from a home network to a network in which an itinerant shift is being made. Third instances formed by the coupling of second instances and the first instances, are transmitted to the mobile unit in itinerant displacement, which calculates and transmits responses to the network in which the itinerant displacement is taking place. In the main authentication stage, the mobile units are then authenticated using a pair of second instances and calculated responses.

In US Patent No. 5,537,474 and in US Patent No. 5,668,875 a method and an apparatus for authenticating a subscriber on roaming movement in a communication system are described. A subscriber and its associated home system use instances and responses of a home system authentication protocol, and a system in which roaming is performed uses a corresponding local authentication protocol. The subscriber converts any instance received from the system in which the traveling itinerary is performed in a format compatible with the home system protocol. A generated user response is converted to the local authentication protocol before being transmitted to the system in which the roaming move is being performed. The instance and the user response are then sent from the system in which the itinerant move is made to the home system, in which a similar conversion is carried out before authenticating the subscriber based on the user response and the expected response .

US Patent No. 5,991,407 describes an authentication procedure in a GSM-based mobile communications system, which uses an A3 algorithm to calculate a signed response from an instance and an authentication key within a mobile unit. A CAVE algorithm (Cellular Authentication and Voice Encryption -) is used as the A3 algorithm. Parameter adaptation functions are provided between the CAVE algorithm input and the authentication key instance and input, as well as between the CAVE algorithm output and the signed response output.

US Patent No. 6,389,536 B1 discloses a device that verifies qualifications for the use of programming or software distributed from a content provider to a user device. In order to carry out or execute the software obtained, the user apparatus is first authenticated by means of three instruments for inclusion in the verification device. An instrument for issuing test support information, arranged in the content provider, issues test support information, for example, in the form of a ticket sent to a test instrument located in the user apparatus, when an execution is requested of software. The test instrument generates response information based on the test support information, together with an instance obtained from a verification instrument embedded or included in the software. This response information is transmitted to the verification instrument and used for authentication purposes. If it has been authenticated correctly, the verification instrument allows the user device to run the software.

The aforementioned patents are affected by the same or similar problems as the prior art response procedure set forth with reference to Figure 2.

WO-A-01 76134 refers to a method for mutual authentication of a mobile node and a packet data network, which comprises an instance response procedure involving a mobile node and a packet data network. The mobile node and the packet data network share a secret. The mobile node is provided with a protection code and sends a mobile node identity and protection code to the network. The network generates a session secret corresponding to the identity, based on the shared secret and an instance. The network forms cryptographic information using at least the protection code and the session secret. The network sends the instance and the cryptographic information to the mobile node, whereby the mobile node can verify the cryptographic information using the instance and the shared secret, generate the session secret and generate a corresponding response to the instance, based on the shared secret The generated response is sent to the network for authentication of the mobile node.

In US-A-5,491,750 a method is disclosed for identifying parties in communication by virtue of which an intermediary acts by deducting from long-term secret keys, provided in advance to the intermediary party and to a specific party in communication, a key of short life. After that, the intermediary party, upon receiving a communication request between the participants in the communication, acts by distributing the short-lived key to the participants in the communication, so that the distribution is protected by masking the cutting key life using the long-term key of the respective party in communication. The intermediary party, on the other hand, carries out the authentication of the parties in communication and, by placing in it the trust of each party in communication, allows, therefore, that the parties in communication induce trust in each other.

A characteristic property of the method comprises the fact that the intermediary has the trust of the parties in communication and is provided with long-term secret keys shared with the corresponding participants.

Document US-A-6,058,480 discloses a system and method for authenticating users and services in communication through an unsecured network. Each of a user and a service has a pass phrase that is kept secret throughout the authentication procedure based on response to an instance. An authentication entity provides authentication support by receiving authentication data from a service for verification, which includes user authentication data received from a user in communication. The authentication entity knows the pass phrase of the users and services, which makes it possible to verify the response data obtained from the respective pass phrase. More specifically, the authentication parties exchange random instances for the generation of the respective response. The user sends the response to the service, which sends its own response and the user's response to the authentication body.

SUMMARY OF THE INVENTION

The present invention overcomes these and other disadvantages of the prior art arrangements.

It is a general purpose of the present invention to provide an improved instance response authentication procedure. In particular, it is desirable to provide an authentication procedure that allows an intermediate or intermediary party to present valid evidence that a user has actually been authenticated. This would effectively prevent malicious service providers from falsely claiming that users have accepted and made use of their services, and also prevents non-repudiation of authentication by users. It may also be important to avoid and / or disrupt interception attacks.

It is a purpose of the invention to provide an improved method and system for authenticating a user and an intermediate party based on a response procedure before a secret key instance (symmetric cryptography).

It is also a purpose of the invention to provide an improved authentication center to assist in the authentication of an associated user and an intermediary party.

Still another purpose of the invention is to provide an intermediary network node managed by the service provider for the authentication of a user associated with an authentication center.

These and other purposes are achieved by means of the invention as defined by the accompanying Patent claims.

In order to improve the basic authentication procedure in response to a secret key instance (symmetric cryptography), a basic idea is to mask the expected response generated by the authentication center, by means of a masking function, and transmit the expected masked response , instead of the expected response itself, to an intermediary party in which the actual authentication takes place. The intermediary party receives a user response from the corresponding user and also generates a masked user response using the same masking function as the authentication center. In order to authenticate the user, the intermediary party then verifies that the masked user response corresponds to the expected masked response that has been received from the authentication center.

The previous response procedure before the instance makes it possible for the intermediary party to demonstrate that the user has been properly authenticated, and, at the same time, prevents and / or disrupts interception attacks as a result of masking the expected response.

The idea behind the proposed solution is that an attacker, such as an authorized user who intercepts authentication parameters or a malicious intermediary party, should not know the answer beforehand. It is only the legitimate user and the authentication center who initially know the response and the expected response, respectively. Accordingly, the idea is to prevent both interception attackers and the intermediary party from accessing the expected response, but still allow the intermediary party to authenticate the user based on the user's response subsequently transmitted from the user. . As explained above, this can be achieved by masking the expected response in the authentication center before transmitting it to the intermediary party, and generating a corresponding masked user response in the intermediary party in order to allow authentication. With this procedure, the intermediary party can now use the response received from the user as well as the corresponding user identification information, preferably together with the associated instance that has been used to generate the response, to demonstrate that this particular user has actually been authenticated Consequently, intermediary parties, for example, service providers, may be urged to provide response values or response-instance pairs in order to demonstrate that users have actually been present in the network and / or used other services, before Payments are transferred.

As already mentioned above, an attacker who intercepts the authentication parameters between the authentication center and the intermediary party may obviously not use these parameters directly to impersonate a legitimate user.

A user's authentication test can be managed in an offline or online connection procedure, or online. In the first case, authentication test information is stored, which includes at least the user's response received from the user and, preferably, also the corresponding instance, in a storage location from which it can be subsequently retrieved by the intermediary part and presented as evidence of user authentication. In the latter case, the authentication test information is sent more or less directly from the intermediary party to the authentication center, which makes it possible to test online or online. Based on the authentication proof information presented, the authentication center can then carry out a relevant calculation (s) and / or comparison (comparisons) in order to verify whether the intermediary party has actually authenticated to a given user.

The masking function may be a private function known only to the authentication center and the intermediary party, or a publicly known function, and generally has one-way, or non-invertible, and / or distributive properties. For increased security, especially to restrain or stop pre-computing attacks, the calculation of the expected masked response and the calculation of the masked user response can be carried out based on a random instance of common masking, denoted as SALT. The common random masking instance, SALT, can be completely random, independent of the random instance, denoted as RAND ["random challenge"], which is used to generate the expected user response / response, and therefore be transmitted together with the RAND to the intermediary party.

However, in order to avoid an additional exchange of signals between the entities involved, the random instance of masking SALT can be deduced from the random instance RAND. In this case, the random RAND instance is transmitted, as usual, to the intermediary party and sent to the user. The random instance of SALT masking can then be calculated from the RAND transmitted in the intermediate part, and subsequently used to generate the masked user response. An effective solution in this regard is to simply reuse the random RAND instance as a random instance of SALT masking.

In order to allow smooth migration in relation to existing infrastructures, it is recommended that the intermediary party be notified about whether or not the masking function has been used when calculating the expected distributed response. Thus, the protocol for distributing authentication parameters is extended or extended, preferably, with such an indication.

An additional threat is that a malicious intermediary party may send the test information to another party that, in turn, presents the test information to the authentication center in a request for payment (presumably, for more expensive services). In addition, it may also be possible for an attacker to read the test information on a node of the service provider illegally intervened or "hacked" and use the information to request payment for services. This particular problem can be solved by associating authentication data data generated by the authentication center for a given user, to the intermediary party that participates in the user's authentication, in order to link corresponding test information to the intermediary party. . Preferably, the authentication data is interrelated, in the authentication center, with an indication of the intermediary party, and the authentication data is subsequently compared, in the authentication center, with test information received (or a representation thereof) ), in order to verify that the test information is associated with the intermediary party.

The invention has proved particularly useful in mobile communication systems, such as GSM or UMTS networks, although they are not limited by them.

The invention, which, as a whole, constitutes a certainly elegant solution, offers the following advantages:

-

 Allow intermediary parties, such as service providers, to demonstrate that users have actually been authenticated;

-

 Prevent malicious service providers from falsely claiming that users have accepted their services;

- Prevent non-repudiation of user authentication by users;

-

 Derail interception attacks effectively, since the masking function (s) makes it virtually impossible to subtract real authentication data;

-

 Possibility of linking test information with a given intermediary party; Y

-

 Provide easy migration with existing infrastructure.

Other advantages offered by the present invention will be appreciated by reading the following description of embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention, together with additional objects and advantages thereof, will be better understood with reference to the following description, taken in combination with the accompanying drawings, in which:

Figure 1 is a global or set of a communications system illustrating the relevant parts of the authentication procedure and their mutual relationships;

Figure 2 is a schematic diagram of an authentication procedure in response to a typical instance of the prior art, illustrating the transmission of information between the relevant parties;

Figure 3 is a flow chart of a general authentication procedure in response to an instance according to the invention;

Figure 4 is a schematic diagram of an example of an authentication procedure in response to an instance according to the invention, illustrating the transmission of information between the relevant parties;

Figure 5A is a flowchart that illustrates in greater detail the expected response generation and masking stage of Figure 3;

Figure 5B is a flowchart illustrating in greater detail the masked expected response transmission stage of Figure 3;

Figure 5C is a flow chart illustrating in greater detail the stage of user response generation and transmission of Figure 3;

Figure 5D is a flowchart illustrating in greater detail the masked user response generation stage of Figure 3;

Figure 5E is a flow chart illustrating in more detail the verification stage of Figure 3;

Figure 6 is a schematic block diagram of an example of an authentication center according to a preferred embodiment of the invention;

Figure 7 is a schematic block diagram of an example of an intermediate part according to a preferred embodiment of the invention;

Figure 8 is a schematic block diagram of an exemplary embodiment provided of an authentication system illustrated as a home network system with an associated mobile unit that travels roaming within a visited network system;

Figure 9 is a schematic block diagram of another embodiment provided by way of example of a home network system according to the invention, with the home authentication algorithm and the HLR (Home Position Register - "Home Location Register") implemented in different network nodes;

Figure 10 is a schematic block diagram of yet another embodiment provided by way of example of a home network system according to the invention, with the home authentication algorithm distributed among several network nodes; Y

Figure 11 is a schematic diagram illustrating a broker that acts as an authentication center for a number of different network operators.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

The same reference characters for corresponding or similar elements will be used throughout the drawings.

In order to arrive at a basic and intuitive understanding of the invention, we will begin by describing a basic authentication procedure in response to an instance with reference to Figure 3. It is assumed here that the parties involved include a user, an authentication center to which the user is associated, and an intermediate or intermediary party that wishes to authenticate the user. In this example, it is further assumed that the global authentication is based on a response procedure before the instance in which the authentication center generates an expected response and the user subsequently generates a corresponding response. A basic idea is to introduce a masking function, which masks the expected response generated (S1). The generated masked response is then transmitted to the intermediary part (S2). The user generates and transmits a corresponding user response in a conventional manner (S3). The intermediary party receives, in this way, an expected response masked from the authentication center, as well as the usual user response from the user. The intermediary part then generates a masked user response by means of the same masking function (S4) and, finally, compares the expected masked response and the masked user response in order to verify user authentication (S5). In this way, the intermediary party is able to demonstrate that the user has been authenticated, bearing in mind that it is only the legitimate authentication user / center that initially knows the expected response / response. A malicious service provider or an unauthorized user cannot know the answer beforehand. Accordingly, by masking the expected response at the authentication center before transmitting it to the intermediary party, the intermediary party as well as the interception attackers are prevented from obtaining access to the expected unmasked response. The generation of a corresponding masked user response, however, continues to allow the intermediary party to authenticate the user. This means that the intermediary party can use the response received from the user, preferably in conjunction with the associated instance used to generate the response, to demonstrate that this particular user has actually been authenticated. Consequently, intermediary parties, for example, service providers, may be urged to provide response values or, preferably, response-instance pairs in order to demonstrate that users have actually been present in the network and / or have used other services, before payments are transferred.

Apparently, the authentication center and the intermediary party have a relationship that implies that the masking function has been exchanged between the authentication center and the intermediary party. This is also true for similar information and / or functions that have to be common to both parties.

It should be understood that the expression "authentication center" is a generic expression, not limited to the Authentication Center node (AuC - "Authentication Center") that is usually found in mobile modem communication systems. The authentication center according to the invention may, in fact, be any center that manages or otherwise participates in the authentication of a user in the manner described herein. For example, the authentication center may, of course, be a home operator authentication center, possibly involving an AAA server (Authorization, Authentication and Accounting - “Authorization, Authentication and Accounting”) that may or may not be located in conjunction with the authentication center. However, it can also be a broker that acts as a general authentication center, or identity center, for a number of different network operators or service providers.

The intermediary part may be any intermediary part in which the user has been authenticated in accordance with the present invention, including a network node that manages a "visited" network within which the user, a provider, is roaming of web services, a content provider and, in fact, even the MSC / VLR (Mobile Switching Center / Visited Positions Registry  “Mobile Switching Center” / “Visited Location Register”) of the domestic operator.

In the case of a visited network in which a user is traveling in an itinerant way, the operator of the visited network can also offer other services, such as web services or even digital content, in addition to the basic network access services . However, if the web service provider and / or the content provider are independent of the visited network operator, the situation becomes somewhat more complex. The operator of the visited network may, of course, have some relationship with the other service providers, which can ask the operator for confirmation that a given user has already been authenticated by the operator. Alternatively, however, the authentication procedure in response to an instance proposed by the invention is repeated for each independent intermediary party, such as a network access provider, a web service provider and a content provider. In the latter case, each service provider will then obtain its own authentication proof information.

The MSC / VLR of the domestic operator itself can also act as an intermediary party that interacts with the authentication center, such as the home operator authentication center or a general identity center, in the authentication of users wishing to access the network . If the MSC / VLR and the authentication center are managed by the same domestic operator, it is generally not necessary for the MSC / VLR to store authentication proof information. Instead, the main purpose of masking is to protect the expected response transmitted between the authentication center and the MSC / VLR node against interception attacks. On the other hand, if the authentication center is a general identification center that acts as a corridor of the authentication center for the user's home operator, it is certainly interesting that the MSC / VLR of the home operator stores user authentication test information. , which can be used later to demonstrate that a given user has actually been authenticated in the MSC / VLR. It may also be convenient to have a standardized authentication procedure that is the same regardless of whether the intermediary party is managed by the domestic operator or by a third party or external party. In the case of services other than the basic network access services, the required signal exchange generally occurs at the application level of the protocol stack. In this case, it is typically an application located in the user terminal that initiates the authentication procedure (and agreement on password). General information on the mechanisms to allow terminal applications to start the AKA can be found in the disclosure of H. Haverinen: “EAP SIM Authentication”, Internet Draft of the Internet Engineering Task Force [ Internet Draft of the Internet Engineering Working Group].

As already mentioned, the intermediary part can also be a web service provider, or a content provider that distributes data in digital information support media such as audio, video, images, e-books and software or programming to an user. In the case of the content provider, authentication according to the invention is preferably carried out prior to the download or generation of actual data streams of user information support means.

In fact, any party that provides services such as network access services, web services, content services or payment brokerage services, can act as an intermediary part as used in this description.

For a better understanding of the invention, a more complete example of an authentication example according to the present invention will be described below, with reference to Figure 4, which illustrates the transmission of authentication information between the relevant parties, as well as to the flowcharts of Figures 5A-E.

In general, global authentication is initiated by a user by transmitting a user ID to an intermediary party, which, in turn, sends the user ID to an associated authentication center, as a request for authentication data. Based on the user ID received, the authentication center identifies a symmetric / shared secret key Ki associated with the particular user. For example, the Ki key may be a subscription or subscription key, in the event that the user has a subscription with a domestic operator, or a cryptographic key associated with a prepaid account. The authentication center generates a random instance RAND (“random challenge”) (S11) and calculates an expected response XRES (“expected response”) (S12) based on the secret key Ki and the random instance RAND, as inputs for a given function g. The authentication center then preferably generates a random instance of masking SALT (S13), for example, as a completely independent random value or based on the random instance RAND, and uses this random instance of masking SALT and the expected response calculated XRES as inputs for a masking function f, in order to calculate an expected masked response XRES '(S14). Subsequently, the expected masked response XRES ’and the random instance RAND are transmitted (S21), possibly together with the optional random masking SALT (S22), to the intermediary party.

For an intermediary party that is completely external to the authentication center or independent of it, it is also usually required that the intermediary party receive information from the user that can be used to determine the identity of the authentication center with which the authentication is associated. user and, more specifically, the identity of the user's home operator. This allows the intermediary party to send the authentication data request to the relevant authentication center / domestic operator, bearing in mind that the authentication center may be the authentication center of a particular domestic operator or a broker that acts as a center for general authentication or identity center. In the latter case, the identity of the domestic operator is normally required to find relevant secret key information, as will be explained later with reference to Figure 11.

Once received, the intermediary party sends the random RAND instance to the user (S31). The user then calculates a user RES response (S32) with the random instance RAN and the user's copy of the shared secret key Ki, as inputs to the same function g that the authentication center has used to calculate the expected response XRES. The user RES response obtained is transmitted to the intermediary party (S33) for use in subsequent authentication.

If the optional random masking instance SALT was not explicitly transmitted from the authentication center, the intermediary party may deduct it (S41) before the authentication verification, preferably based on the random RAND instance. A masked user response RES ’is calculated by the intermediary party (S42), by means of the user RES response and the optional random masking instance, received or deducted, SALT, as inputs for the masking function f. After that, the intermediary party compares (S51) the masked user response calculated RES ’with the expected masked response XRES’ obtained from the identification center. If the masked user response RES ’corresponds to the expected masked response XRES’, the intermediary party has authenticated the user (S52).

As mentioned briefly in the above, the random instance of SALT masking is optional and can be omitted from the authentication procedure. In this case, no random instance SALT is introduced into the masking function f to calculate the expected masked response XRES ’and the masked user response RES’, respectively. However, in order to increase security and, in particular, to stop pre-computing attacks, the random instance of SALT masking is preferably included as an input of the masking function. In this way, the random instance of masking SALT can be generated as a completely random value in the authentication center and subsequently transmitted to the intermediary part together with the expected masked response XRES ’and the random RAND instance. However, in order to avoid an additional exchange of signals between the authentication center and the intermediary part, the random instance of masking SALT can, alternatively, be deduced from the random instance RAND. In this case, the authentication center preferably generates the random instance of masking SALT by means of some function h of the random instance RAND. Consequently, it is not necessary to transmit any random instance of SALT masking to the intermediary party, which, instead, can use the same function h to generate the random instance of SALT masking from the random RAND instance. An example of a random masked instance SALT that can be used is simply to reuse the random instance RAND as a masked random instance SALT, such that h is represented as a unit function.

The function h may be a public function or a function associated and distributed with the commercial agreement between the intermediary part and the legal part (such as a domestic operator) of the authentication center, of which various aspects will be discussed in detail later.

The masking function f used, on the one hand, by the authentication center to generate the expected masked response and, on the other hand, by the intermediary part to calculate the masked user response, can be a one-way function or not invertible, and / or distributive. Preferably, the masking function is a cryptographic distributive function that has a one-way or non-invertible functional application and properties that make it impossible to find two different inputs that are fragmented into a common value.

For additional information on non-invertible functions and distributive functions, reference is made to the disclosure of AJ Menezes, PC van Oorschot and SC Vanstone: “Handbook of Applied Cryptography”, CRC Press, chapter 1, pages . 1-48.

The masking function f may be a public function or a private function known to the authentication center and the intermediary party. In the latter case, the private masking function may be associated with a commercial agreement between the legal party, such as a given domestic operator, the authentication center and the intermediary party, such as a service provider. If the legal part of the authentication center, for example, a domestic operator, has such a commercial agreement with several different service providers, a corresponding private function can be used by the domestic operator for each service provider, that is, each agreement of operator-provider is embodied in a private masking function. However, alternatively, it is possible to use the same public masking function for all service providers.

If the masking function is known, it is possible, at least in theory, to look for a user response that causes the masking function to perform an evaluation on the expected masked response received from the authentication center. A malicious intermediary party, such as a service provider, can then deploy such an attack to "prove" that a user has been authenticated even if no user authentication has been carried out. This is solved simply by a careful choice of the properties of the authentication parameters. For example, if the user's response is chosen so that it is n bits and the expected response masked so that it is m bits, with n> m, the average number of user responses to be checked before finding The one that is associated with an expected masked response present, is approximately 2m-1. In addition, the probability that this is the correct user response is only 2- (n-m). For a UMTS mobile communications system, standardized parameter sizes allow n to be 96 and m to be 80, which gives rise to the impossible task of checking 279 different user responses and a correct user response probability of only 2-16 .

It is also possible to mask the expected user response / response differently depending, for example, on the actual service obtained from the intermediary party. This means that for some a certain type of masking is used, for example, a first masking function, while for other services a second different masking function is used. In such a case, some form of information is preferably included in the transmission between the authentication center the intermediate part in order to notify the masking function to be used in the particular user authentication.

In order to allow a smooth migration in relation to the existing infrastructure, the intermediary is preferably informed about whether or not the masking function has been used when calculating the expected distributed response. Thus, the protocol for the distribution of authentication parameters is preferably extended or extended with such indication. Similarly, an indication about which masking function to use may be included in the protocol, if a choice between different masking functions is present, as explained above.

The intermediary party may use the response received from the user and some other user identification information, such as a user ID, preferably together with the random instance used to generate the response, as test information to demonstrate that this particular user has been really authenticated In this way, the intermediary part conveniently stores the received user response, the user ID and the random instance in a position suitable for subsequent recovery, if necessary, as evidence of user authentication. In this offline or offline procedure for demonstrating user authentication, the user's response and the user's ID, preferably together with the corresponding random instance, can be stored in the intermediary part, in some other accessible position.

When urged by the authentication center or some other related party, to provide proof of the authentication of a given user, the intermediary party may transmit the test information, such as the user RES response, the corresponding RAND random instance and the user ID to the authentication center. Preferably, the authentication center then retrieves the secret key Ki associated with the given user and calculates the expected response value XRES based on the received RAND and the secret key Ki, and finally compares the received RES value with the XRES value calculated in order to verify if the user has actually been authenticated in the intermediary part. If the RES value matches the XRES value, the test information is considered valid.

Intermediary part: RAND, RES, user ID

Authentication Center: User ID  XRES

g (Ki, RAND)  XRES

?

    check: XRES  RES

Alternatively, the intermediary part simply transmits the RES value and the user ID of a given user to the intermediary part. In this case, the authentication center typically needs to store XRES values, or RAND values, so that the corresponding XRES values can be calculated for users so that it can make a comparison between RES and XRES.

If an online or online procedure is desired, the user response and the user ID, preferably together with the corresponding random instance, are sent more or less directly from the intermediary party to the authentication center, thereby making it possible The demonstration of authentication.

Association of authentication test information to a specific intermediary party

An additional threat is that a malicious intermediary party sends may send the test information to another party that, in turn, presents the test information to the authentication center in a payment request (assuming, for example, that the services of the another part are more expensive than those of the intermediary part). Furthermore, it may also be possible for an attacker to read the test information, including, for example, the user ID, the user RES response and the corresponding random instance RAND, from an illegitimately intervened node of the intermediary party. This attacker could then present the test information received to the authentication center, falsely stating that the user has accessed a service and requesting payment. If deemed necessary or otherwise important, this particular problem can be solved by associating authentication data, generated in the authentication center for a given user, with the intermediary party that participates in the user authentication in order to link the information of corresponding proof with the intermediary part.

In the initial stages of the global authentication procedure of the invention, the intermediary party sends a user ID, together with a request for authentication data, to the authentication center. In general, the user ID is accompanied by information that identifies the intermediary party requesting authentication data. In order to allow further linking of authentication test information to a specific intermediary party, the authentication center may store the user ID and generated authentication data, such as RAND, SALT and / or XRES, with a reference to which intermediate part authentication data has been sent to. If at least part of the authentication data generated for a given user is interrelated at the authentication center with an identification of the intermediary party that requested the authentication data, the corresponding test information cannot be used by any other party .

When the intermediary party is urged to provide test information to the center of

5

10

fifteen

twenty

25

30

35

40

Four. Five

authentication, this also transmits its own identity, which is also referred to as the service provider identity, denoted as IDSP, to the authentication center. Upon receiving test information, the authentication center compares the user RES response obtained from the intermediary party with an expected XRES response stored or regenerated, in order to verify that a user has been authenticated. However, the authentication center can now also compare test information received with stored authentication data, having a reference with respect to the intermediary part to which the authentication data was transmitted, in order to verify whether the test information is really associated with the intermediate part that presents the test information.

Another possible solution to link test information to an intermediary party is to associate the generation of the random instance of SALT masking located in the authentication center with the intermediary part IDSP. The authentication center may have a set of different h functions that are used to generate SALT from RAND, and preferably assigns each intermediate party a unique or exclusive hSP function. This hSP function is used by the authentication center to generate the random instance of masking SALT from the RAND, and the generated SALT is transmitted to the intermediary party. To means that SALT values are stored with a reference to the corresponding IDSP in the authentication center, the hSP functions are preferably kept secret by the authentication center. When test information, including RES, RAND and user ID, is presented to the authentication center, the intermediary party is also required to transmit its associated IDSP and the previously received random masking instance SALT. Based on the IDSP received, the authentication center identifies a relevant hSP function and calculates a random instance of expected masking XSALT based on the random RAND instance received. In order to verify that the test information originates from the correct intermediary part, XSALT is compared with the SALT received from the intermediary part. A coincidence between them is a verification or corroboration of the correct origin of the test information. Keeping the specific single function of the intermediate party secret makes it impossible for another party to use the test information.

 Intermediary party: RAND, SALT, RES, user ID, IDSP

Authentication Center: User ID  Ki

g (Ki, RAND)  XRES

     IDSP  hSP

hSP (RAND)  XSALT

     checks:

?

     XRES  RES

?

     XSALT  SALT

Instead of using a single hSP function for the intermediary party in the generation of the random instance of masking SALT, it is possible to use a common function h by the authentication center for various or all intermediate parties. However, function h has both the random RAND instance and the intermediate part IDSP as inputs. In this way, the authentication center calculates the SALT based on the IDSP received, together with the user ID, in the initial stages of the authentication procedure. In the same manner as described above, the intermediate party is requested to include the IDSP and a copy of the SALT received in the test information. Once received, the authentication center calculates a random instance of expected masking XSALT based on the IDSP and the RAND received, and the h function. XSALT is then compared with the SALT transmitted from the intermediary party, and a coincidence between them verifies the correct origin of the test information. Keeping the common function h secret makes it impossible for another party to present valid test information based only on the RES and RAND.

Intermediary party: RAND, SALT, RES, user ID, IDSP

Authentication Center: User ID  Ki

g (Ki, RAND)  XRES

h (RAND, IDSP)  XSALT

     checks:

?

       XRES  RES

?

       XSALT  SALT

In yet another alternative embodiment, the generation of the random RAND instance may be based on the IDSP of the intermediate part. When a user authentication is requested, the authentication center generates a random RAND ’pre-instance and calculates the RAND instance through the RAND’ and the intermediate IDSP,

5 as inputs for a function r.

RAND = r (IDSP, RAND ’)

This random RAND instance is subsequently used to generate the expected RES response and is sent to the intermediate party along with the XRES ’masked expected response. The authentication center stores RAND ’with a reference to the associated user ID and the intermediary party IDSP. To

10 time to verify that a user has certainly been authenticated by the intermediary party, the authentication center calculates an expected random instance XRAND with the IDSP and the RAND ’stored, as inputs for the r function. XRAND is then compared to the RAND received from the intermediate party, and if they match, the authentication center can verify that the test information is transmitted from the correct intermediary party. The verification of the user's authentication is also carried out by means of the RES and the XRES, as follows.

15 This solution is especially applicable when no random instance of SALT masking is used in the user authentication procedure.

Intermediary party: RAND, RES, user ID, IDSP

Authentication Center: User ID  Ki

g (Ki, RAND)  XRES

20 IDSP  RAND ’

r (RAND ’, IDSP)  XRAND

     checks:

?

       XRES  RES

?

       XRAND  RAND

25 The functions described above h, hSP and r preferably have a one-way or non-invertible functional application, with properties that make it impossible to find two different inputs that fragment into a common value.

In general, the XRES-RES comparison verifies if a given user, with a user ID, has been authenticated, and the XSALT-SALT / XRAND-RAND comparison verifies whether the user has been authenticated by the intermediary part 30 that has IDSP identity.

Optional cryptographic aspects

While not illustrated in Figure 4, additional information, such as a confidentiality key, an integrity key and an authentication token, can be generated in the authentication center, and transmitted to the intermediary party. In this case, this additional information, for example, the confidentiality key and the

35 integrity, can be modified by the response before use. For example, the authentication center can cryptographically protect the confidentiality key and the integrity key based on the expected expected response. The keys are then transmitted encrypted or encrypted to the intermediary party, which performs any interception of the distributed keys that are not useful for the secret connection or puncture of cable and decryption. The intermediary party then extracts the confidentiality key and the integrity key from the

40 encrypted information using the response received from the user.

In addition, information other than the keys obtained from the AKA can be cryptographically protected, by means of the expected response, before being transmitted between the authentication center and the intermediary party.

In general, the transmission of authentication parameters, including the expected response

45 masked, the random instance and the random masked instance, between the authentication center and the intermediary part, can be cryptographically protected. In UMTS applications, for example, the MAPSec protocol can be used for parameter protection.

Aspects of practical application

The steps, actions and algorithms described above can be implemented in software / hardware or in any combination of these. For implementations on physical devices or hardware, ASIC (Application Specific Integrated Circuit) or any other conventional circuit technology may be used. Although special hardware, resistant to tampering may be preferred, for security reasons, properly protected software implementations are often more convenient.

Figure 6 schematically illustrates an example of an authentication center according to a preferred embodiment of the invention. Authentication center 50 generally includes an authentication algorithm unit 10, intended to generate authentication data that is used to authenticate a user, a test verification unit 20 and a database 30. Unit 10 of Authentication algorithm comprises an instance data generator 12, an XRES generator 14 and a masking function unit 16. As its name implies, the instance data generator 12 generates instance data, including the random instance and, optionally, also the random masking instance. The XRES generator 14 generates the expected XRES response based on the instance data and a secret key associated with the user, from the database 30. The masking function unit 16 generates the masked expected response based on the random instance. of optional masking and in the expected response, respectively, from the instance data generator 12 and the XRES generator 14. The test verification unit 20 is also preferably implemented in the authentication center 50 to verify the test information received from the intermediary party.

This test verification unit 20 preferably uses data stored in the database 30 for the test verification. The database 30 may optionally include, in addition to information on the user ID and the associated secret key Ki, authentication data and / or similar data stored with reference to IDSP information identifying the intermediary party. The authentication center 50 also comprises a transmitter / receiver 40, with its associated circuits, for communication with the intermediary part and with the user.

Figure 7 schematically illustrates an example of an intermediate part according to a preferred embodiment of the invention. The intermediate part 200 includes an authentication algorithm unit 210 for user authentication. Authentication algorithm unit 210 comprises a masked response generator 212 and a comparison unit 214. The masked response generator 212 generates a masked user response based on a masking function and the user response received from the user. The comparison unit 214 is used to compare the masked user response from the generator 212 with the expected masked response that is transmitted from the authentication center. A storage / referral unit 270 is also preferably arranged in the intermediate part 200, in order to store and / or send test information that includes the user's response and the user ID, as well as, preferably, data of instance received from the authentication center or generated by the authentication algorithm unit 210. This test information from the storage and / or referral unit 270 is transmitted to the authentication center, for example, upon request or as soon as the test information is obtained by the intermediary part 200. The intermediate part 200 also comprises a 240 transmitter / receiver with its associated circuits, for communication with the authentication center and with the user.

Application example - mobile communication system

While the invention is generally applicable to any system of response to a secret key instance, the invention has proved particularly useful in mobile communication systems. The invention will be described below with reference to an application and a particular one provided by way of example, namely a mobile communication system in which the intermediary part is a network node that manages a mobile / cellular network within which a mobile unit (user) is moving around. In this particular example, the authentication center is a home operator authentication center (AuC). The mobile unit is associated, for example, through a subscription or a prepaid account, with a home operator that manages a home network system. This user-operator relationship is typically embodied in a SIM card of those used in GSM mobile units, or in a UMTS SIM card (USIM - “UMTS SIM”) of those used in UMTS mobile units. It should be understood, however, that in a more general mobile communications application, the intermediary part may be any type of service provider, including a visited network node, the MSC / VLR node of the home operator itself, a service provider Web, a provider of information media support content, as well as a payment broker.

Figure 8 is a schematic block diagram of an exemplary embodiment provided of an authentication system, which is illustrated as a home network system with an associated mobile unit that is roaming within a network system. visited. The home system 100 generally comprises one or more network nodes 160, of which one is illustrated. For example, network node 160 may consist of an MSC (Mobile Switching Center -) or a base station (BS - "base station"). In the example of Figure 8, the network node 160 comprises an HLR (Home Positions Registry) 130. This HLR 130 includes information, for example, user ID and corresponding secret subscription key Ki, of the users associated with the system domestic 100. The HLR 130 may optionally include authentication data and / or similar data stored with reference to the identification of the intermediary party. In addition, the network node 160 also comprises an authentication center (AuC) 150 that manages and participates in the authentication of the users. The AuC 150 comprises an authentication algorithm unit 10 that implements an authentication algorithm, as well as a test verification unit 20, intended for the verification of test information from the visited system 200. When executed, the authentication algorithm generates the relevant authentication data of the invention. The home network node 160 is additionally equipped with a transmitter / receiver 140, with its associated circuits, to transmit the generated random instance, the expected masked response and, possibly, the masked random instance, to a network node 260 of a system visited or itinerantly traveled 200.

The visited system 200 comprises, in the same way, one or more network nodes 260, of which one is illustrated in Figure 8. The network node 260 of the visited system 200 preferably comprises a VLR (Position Registration Visited) 230 and an authentication algorithm 210. On the other hand, a transmitter / receiver 240 has been arranged to receive the authentication parameters from the home system 100 and forward the random instance received to the mobile unit on roaming 400, so as to transmit test information to authentication center 150 of the home system.

The visited network node 260 also preferably comprises a storage and / or referral unit 270 intended to store the user response received from the mobile unit 400 and, possibly, the random instance from the home system 100. However, the Storage of the user response can, alternatively or in a complementary manner, be provided in another location which can be accessed by the operator of the visited system 200 for further retrieval of the information in a user authentication test procedure. The data stored in this unit 260 is transmitted to the authentication center when requested by it.

In the particular example of Figure 8, the user is a mobile mobile unit 400 that is being authenticated by a network node 260 of the network system 200 that is roamed or visited. As mentioned above, the mobile unit 400 preferably comprises a SIM (USIM) 480 equipped with the secret key Ki 415 and an authentication algorithm unit 410. This authentication algorithm implemented in unit 410 may be, for example, algorithm A3 of the AKA protocol in GSM and in UMTS. When executed, the authentication algorithm calculates a user response based, preferably, on the random instance sent from the visited system 200 and the secret key Ki of SIM 480. The mobile unit 400 then sends the user's response to node 260 network of the visited system, where final authentication is carried out.

Figure 9 illustrates another exemplary embodiment provided of a home network system 300 that includes an AuC 150 according to the invention. In this embodiment, the home system 300 has been illustrated with two network nodes 360, 356, each of which is equipped with a respective transmitter / receiver 340, 345. A first node 360 comprises the HLR 130, while the AuC 150, with the authentication algorithm unit 10 and the test verification means 20, is arranged in a second node 365. The first node 360 may be an MSC, so that the second node 365 materializes as a BS. Alternatively, both the first node 360 and the second node 365 can be MSC or BS, or the first node 360 can be a BS and the second node 365 an MSC.

Figure 10 is a schematic block diagram of yet another example provided by way of a home network system according to the invention, such that the home authentication algorithm is distributed among various network nodes. In Figure 10 two network nodes 560, 565 have been explicitly illustrated. In this embodiment, the AuC 550 is distributed between the two nodes 560, 565. This means that part 510 of the global authentication algorithm has been implemented in the first node 560, while the remaining part 515 of the authentication algorithm has been implemented in a second node 565, or in various other nodes. The test verification unit 20 of the AuC 550 has preferably been implemented in the network node 560 that is hosting the HLR 130, whereby it has access to the data stored in the HLR 130.

The visited system can, in the same way, have the VLR and the authentication algorithm spread over different network nodes, and / or have the authentication algorithm distributed among different nodes.

For additional detailed information on general authentication procedures in mobile communication systems, reference is made to the disclosure of J. Arkko and H. Haverinen: “EAP AKA Authentication”, Internet Draft of the Internet Engineering Task Force [Internet Draft of the Internet Engineering Working Group], and the Internet Draft previously mentioned: “EAP SIM Authentication”, by H. Haverinen.

Example - A broker acting as an authentication center

As indicated above, the authentication center is not necessarily the authentication center of a particular domestic operator, but can be a broker 750 that acts as a general authentication center, or identity center, for a certain number from different network operators, as schematically illustrated in Figure 11. In this case, the corridor 750 of the authentication center, or identity center, is generally entrusted with user identification information and information of secret code 730, 735 from the different network operators, thus making it possible for the broker 750 to help authenticate users in various intermediate parts 200-1 to 200-N.

Generally, when a user 400 wishes to authenticate himself / herself to a given intermediary part 200, the user sends his user ID and, if required, some information representing the IDOP identity of the domestic operator, to The intermediary part. The intermediary party then sends the user ID and the IDOP, together with information identifying the IDSP of the intermediary party, to the broker 750 of the authentication center, in a request for authentication data. The authentication center corridor 750 identifies, based on the received IDOP and user ID, the secret key Ki associated with the user 400 and then generates the authentication data (masked) in accordance with the authentication algorithm of the invention. The rest of the authentication procedure (and proof verification) corresponds essentially to the above description of the invention.

In a typical scenario or context, user 400 first needs to authenticate with his own operator, and therefore sends his user ID to the MSC / VLR node (which acts here as an intermediary part) of the domestic operator, which sends the user ID and its own ID to the broker 750 of the authentication center, in a request for authentication data. The corridor 750 of the authentication center generates the authentication data required for authentication. Once the user has finally been authenticated, the MSC / VLR can store the corresponding test information for further retrieval, if necessary, as evidence of the user's authentication. If the user subsequently wishes to access, for example, some web service offered by a web service provider, the user is requested to transmit his user ID and information representative of the IDOP identity of the domestic operator to the provider of web services If the web service provider is independent (another intermediary part) of the domestic operator, it may, however, have a certain relationship with the domestic operator and ask the domestic operator about information about whether the user has been authenticated. Alternatively, the web service provider transmits the IDOP and user ID to broker 750 at its own request for authentication data, and stores its own test information later. Correspondingly, a similar procedure can be carried out for a content provider, a visited network node or any other intermediary party.

A broker that acts as a general authentication center can also be used to deduce keys for end-to-end encryption or encryption between a user and an intermediary party. In such a case, these deduced keys can be kept secret from the network operator. The user can then obtain the end-to-end encryption key, for example, in a subscription to the services offered by the intermediary party or with the payment of services used.

The above-described embodiments have been provided merely by way of examples, and it should be understood that the present invention is not limited by them. The accompanying claims define the scope of the invention.

Claims (35)

1. A method based on instance-response for the authentication of a user in a communications system, which has at least the user associated with an authentication center, characterized by the steps of:

-

 generate (S12), at the authentication center (50, 150, 550), an expected response by means of a response function (14), from a secret key, shared with the user, and a random instance (S11 );

-

 generate (S14), in said authentication center, an expected masked response by means of a masking function (16), in response to said expected response;

-

 transmitting (S21) said expected masked response and said random instance to an intermediate or intermediary party (200);

- so that the intermediary part transmits (S31) said random instance to the user (400);

-

 generate (S32), in said user, a response by said response function in response to said secret key and said random instance;

-

 transmitting (S33) said user response to said intermediary party; generate (S42), in said intermediate part, a masked user response by means of the same masking function as that of said authentication center, in response to said user response;

-

 such that said intermediate part authenticates the user in response to a positive result of the verification that said masked user response corresponds to said masked expected response (S51, D52).

2.

The method according to claim 1, characterized by the additional step that said intermediary part (200) manages the authentication test information, including at least said user response received from said user (400) and user identification information corresponding, in order to allow said intermediary party to demonstrate that said user has been identified.

3.

The method according to claim 2, characterized in that said authentication test information additionally includes said random instance.

Four.

The method according to claim 1, characterized in that said steps of generating an expected masked response and generating a masked user response are also carried out in response to a common random masking instance for increased security.

5.

The method according to claim 4, characterized in that said random masking instance deduces said random instance received.

6. The method according to claim 2, characterized by the additional steps of: - transmit, by said intermediary party (200), authentication test information to said authentication center (50, 150, 550); Y - verify, by said authentication center, if said user has been authenticated in said intermediary party based on said received test information.

7.

The method according to claim 6, characterized in that said verification step comprises the step of comparing the user response of said received test information with a corresponding expected response provided by said authentication center.

8.

The method according to claim 7, characterized in that said authentication test information additionally includes said random instance, and said method further comprises the steps of recovering, in said authentication center, said secret key based on said user identification, and re-compute said expected response from said received secret key and said random instance.

9.

The method according to claim 2, characterized by the additional step of associating said intermediary part with identification data generated for a given user, by said authentication center, in order to link to said intermediary part corresponding test information.

10.

The method according to claim 9, characterized in that said authentication data is interrelated, in said authentication center, with identification information identifying said intermediary part, and said authentication data is subsequently compared, in said authentication center, with a representation of test information received, in order to verify that said test information is associated with said intermediary party.

eleven.

The method according to claim 10, characterized in that said authentication data includes at least one of said random instance, said expected response and a random masking instance used to generate said expected masked response and said masked user response.

12.

The method according to claim 10, characterized in that said authentication data includes random instance data, and the generation of said instance data is interrelated with said intermediate part.

13.

The method according to claim 12, characterized in that said instance data is generated by a function that is unique or exclusive to said intermediate part.

14.

The method according to claim 12, characterized in that said instance data is generated based on identification information identifying said intermediate part.

15. The method according to claim 1, characterized by the additional steps of:

-

 encrypt or encrypt data transmitted from said authentication center to said intermediary party by means of said expected response; Y

-

 decrypt or decrypt said encrypted data in said intermediate party by means of said user response received.

16.

The method according to claim 1, characterized in that said authentication center and said intermediate part are located in network nodes (260, 160) of a mobile communications system.

17.

The method according to claim 1, characterized in that said authentication center is a broker (750) that acts as a general authentication center, or identity center.

18.

A user authentication system based on response to an instance, for a communications system, which has at least one user (400) associated with an authentication center (50, 150, 550), characterized by:

- means (14) for generating, in the authentication center, an expected response by means of a response function from a secret key, shared with the user, and a random instance; - means (16) for generating, in said authentication center, an expected masked response by means of a masking function, in response to said expected response;

-

 means (40), located in said authentication center, for transmitting said expected masked response and said random instance to an intermediate party;

-

 means (240), located in the intermediate part, for transmitting said random instance to a user;

-

 means (410) for generating, in said user, a response by said response function in response to said secret key and said random instance;

- means for transmitting said user response to said intermediary party;

-

 means (212) for generating, in said intermediate part, a masked user response, by means of the same masking function as that of said authentication center, in response to said user response; Y

-

 means (214) to verify, in said intermediate part, that said masked user response corresponds to said masked expected response, thereby authenticating the user.

19.

The system according to claim 18, characterized by additional means for managing, in said intermediate part, authentication test information that includes at least said user response received from said user, and corresponding user identification information, for the purpose to allow said intermediary party to demonstrate that said user has been authenticated.

twenty.

The system according to claim 19, characterized in that said authentication test information additionally includes said random instance.

twenty-one.

The system according to claim 18, characterized in that said means for generating an expected masked response and said means for generating a masked user response operate based on a random instance of common masking, for increased security.

22. The system according to claim 19, characterized by:

-

 means (240) for transmitting authentication proof information from said intermediary party to said authentication center; Y

-

 means (20) for verifying, in said authentication center, if said user has been authenticated in said intermediary party based on said received test information.

2. 3.

The system according to claim 22, characterized in that said verification means comprise means for comparing the user response of said received test information with a corresponding expected response provided by said authentication center.

24.

The system according to claim 23, characterized in that said authentication test information additionally includes said random instance, and said system additionally comprises means for recovering, in said authentication center, said secret key based on said identification of user, and means for re-computing, in said authentication center, said expected response from said recovered secret key and said random instance.

25.

The system according to claim 19, characterized by additional means for associating said intermediary part with authentication data generated for a user given by said authentication center in order to link corresponding test information with said intermediary part.

26. The system according to claim 18, characterized by:

-

 means for encrypting or encrypting data transmitted from said authentication center to said intermediary party by means of said expected response; Y

-

 means for decrypting or decrypting said encrypted data in said intermediary part by means of said user response received.

27. An authentication center to assist in the identification of an associated user in an intermediary party, capable of carrying out a response procedure before the instance with the user, such that said authentication center is characterized by:

-

 means (14) for generating a response expected at least partially by the application of a response function on a secret key, shared with said user, and a random instance;

-

 means (16) for masking said expected response by means of a masking function in order to generate an expected masked response; Y

-

 means (40) for transmitting said random instance and said expected masked response in response to said intermediary party, which is, after that, capable of authenticating the user in response to a positive verification that a resulting masked user response corresponds to said response expected masked.

28.

The authentication center according to claim 27, characterized in that said masking means are capable of being operated to mask said expected response based on a random instance of common masking, for increased security.

29.

The authentication center according to claim 27, characterized by additional means for cryptographically protecting data transmitted from said authentication center to said intermediate party by means of said expected response.

30. The authentication center according to claim 27, characterized by:

-

 means (30) for interrelating authentication data generated for a given user with identification information identifying said intermediary party; Y

-

 means (20) for comparing said authentication data with a representation of test information received from said intermediary party in order to verify that said test information is associated with said intermediary party.

31.

The authentication center according to claim 27, characterized in that said authentication center is a broker (750) that acts as a general authentication center or identity center.

32

An intermediary network node (260), managed by a service provider and interconnected with an authentication center (50, 150, 550) to authenticate a user, associated with the authentication center, in accordance with a procedure of response before instance, said intermediate node network node characterized by:

- means (240) for receiving from said authentication center a random instance and an expected response generated by a response function (14) from a secret key, shared with the user, and the random instance, and then masked by a masking function;

-

 means for transmitting the random instance to the user;

-

 means for receiving from said user a user response also generated by said function

5 response in response to said secret key and said intermediate instance, corresponding to said expected response; - means (212) for generating a user response masked by said masking function; Y - means (214) for authenticating the user in response to a positive verification result that said masked user response corresponds to said masked expected response. 33. The network node according to claim 32, characterized by additional means for managing, in said intermediate part, authentication test information, including at least said user response received from said user and corresponding user identification information, in order to allow said intermediate party to demonstrate that said user has been authenticated. The network node according to claim 33, characterized in that said authentication test information additionally includes said random instance in order to help demonstrate that said user has been authenticated by said intermediary party. 35. The network node according to claim 32, characterized in that said generation means are capable of being operated to generate said masked user response based on 20 a random masking instance, such that said random masking instance is also used by said authentication center to mask said expected response. 36. The network node according to claim 32, characterized by additional means for transmitting test information from said intermediate part to said authentication center.