RU2386220C2 - Method and device for authentication and confidentiality - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: initial download server function (IDSF) is specified, which creates authentication voucher announcing authentication for network application function NAF. IDSF generates keys Ks and Ks NAF with according identifiers B-TID and B-TID-NAF keys. In order to prevent tracking of user by means of collusion between several objects of NAF, B-TID-NAF and voucher may be unique for each NAF. Ua interface is additionally protected by coding with application of Ks key, and Ub interface is additionally protected against attacks by connection with substitute by application of signatures with key Ks and provision of update.

EFFECT: improved level of confidentiality and authentication protection.

23 cl, 8 dwg

Description

FIELD OF THE INVENTION

The present invention relates to a method and apparatus for authenticating user entities in a communication network. In particular, the invention relates to improved security in a communication network implementing a generalized authentication architecture / generalized bootstrap architecture, OAA / OANZ.

State of the art

3rd Generation Partnership Project Authentication Infrastructure (PP3P), including PP3P Authentication Center (TsAU), Universal Subscriber Identity Identification Module (UMIA) card or Internet Protocol Multimedia Identity Identification Module (IP) (MIMUP), and protocol of agreement on authentication and key (SAC) PP3P, performed between them, are a very valuable asset of PP3P operators. It was recognized that this infrastructure can be used at a new level, providing the ability for application functions on the network and on the user side to install shared keys. Therefore, PP3P specified a “generalized bootstrap architecture” (OANZ), which provides the ability to distribute shared secret keys to user equipment (OP) and network application functions (FSP) using NAC-based mechanisms ([1], [2]). Figure 1 depicts a simple reference model according to the link [2] for the initial loading of keys in the FSF and OP with support from a new component of the network infrastructure, the functions of the bootstrap server (FSNZ) and home subscriber system (DAS). With reference to FIG. 1, the flowchart of FIG. 2 explains the bootstrap steps of the prior art. At step 210, the user equipment of the UE accesses the network application function of the FSF via the Ua interface. At step 220, it is determined whether the call included an identifier on authentication data that is already available. If so, the process continues at step 270. Otherwise, at step 230, the FSF prompts the OP to initiate bootstrapping using the OANZ method to generate shared keys. The OP redirects the request to the Federal Security Service via the Ub interface. The boot request may be the result of a command redirect from the FSF, as described here, or, otherwise, may be executed before the OP executes the call to the FSF in step 210. The configuration of the OP determines which case to apply. At step 240, the FSS requests an authentication vector from the DAS over the Zh interface. At step 250, the FSWS authenticates the UAS with the UE through the Ub interface using the authentication vector. The shared key Ks is generated, and the FSS, in addition, creates a transaction B-TID that identifies the credential information generated by the FSS. At step 260, the B-TID is transmitted to the FSF through the UEs via the Ub and Ua interfaces. At step 270, the FSF accesses the FSWS through the Zn interface, providing the B-TID, whereby the FSW responds with the corresponding credential information. At step 280, the FSF responds to the initial request at step 210, including the authentication result.

At this point, the FSF may use distributed mandates. This information can be used for additional end-user authentication, which the FSF can initiate, for example, the http-digest procedure, as defined in [3], using distributed shared secret keys. Mandates can also be used for purposes other than authentication, for example, for integrity, confidentiality, or to obtain a key.

PP3P proposes the use of OANZ for authentication of the end user, defining the so-called "generalized authentication architecture" of the OAA, as described in reference [1]. OAA is re-applying OANZ procedures to establish shared secret keys on the OP and the FSF, so these credentials can be additionally used as the basis for subsequent end-user authentication mechanisms executed between the FSF and the OP.

PP3P also investigated the use of OANZ in the system of the multimedia subsystem PI (PMPI), for example, reference [4].

There are two fundamental problems with the OAA / OANZ:

• It has weak support for user privacy, and collusion is possible, since two or more independent third-party applications can track the user through the Ua interface.

• The current OAA / OANZ architecture does not provide explicit support for end-user authentication. If the application uses the OAA / OANZ architecture exclusively for authentication, the FSF application needs to implement additional end-user authentication mechanisms based on the originally loaded key. In addition, the user will be authenticated, in fact, twice: once through the FSNZ and then through the FSF.

Regarding confidentiality, it is noted that the same B-TID is used for each FSF. This fact can be used to build a user profile indicating the signed services, thus violating the requirements of confidentiality. This type of privacy attack is known as collusion. Being a small problem for applications that are provided by the same operator, it becomes a serious problem when third parties provide applications, or when the operator hosts the services of a third party in their possessions.

Further, the OAA / OANZ architecture has the problem that wildcard attacks are possible, whereby a fraudulent user may request a credential belonging to someone else.

Basically, the OAA / OANZ architecture is a key distribution architecture based on a Subscriber Identity Module (MIA). The term "MIA" here is meant either as UMIA (3rd generation), or MIMUP. OAA / OANZ is not generalized with respect to the supported authentication mechanisms, since it involves MIA-based authentication. In addition, the OAA / OANZ is not authentication oriented, as the provided keys may or may not be used for authentication.

The disadvantage of the OAA / OANZ is that it requires applications to implement the following mechanisms in order to become compatible with the OAA / OANZ:

- Key management for the safe storage of the provided key, tracking the authenticity of the key, associating the key with the given user and application, updating the keys when the validity expires.

- A protocol for fetching keys from the Federal Security Service, for example, Diameter.

- Authentication protocol for user authentication.

- Secure channels to protect key distribution.

The burden of implementing all of these OAA / OANZ mechanisms, especially the need to implement a key distribution procedure, is high for applications that often only require verification of user identity.

Many applications cannot even implement mechanisms for user authentication due to the load of managing user credentials, such as passwords. In fact, the problem of password management (storage, protection, updating, loss, unreliability, theft) was defined as an obstacle to the deployment of the application.

Other disadvantages of the OAA / OANZ architecture of the prior art relate to the operator:

- Delegation of service authorization to the application, while centralized authorization may be preferable.

- There is no support for collecting statistics due to the lack of control over the use of the application.

- There is no automatic mechanism for declaring an invalid subscription to a service.

Therefore, there is a need for an improved OAA / OANZ architecture that overcomes the problems and disadvantages of the prior art system and provides additional privacy protection and authentication support.

SUMMARY OF THE INVENTION

The present invention addresses the disadvantages of prior art devices.

Basically, it is an object of the present invention to use the new OAA / OANZ infrastructure to improve privacy protection and authentication support, minimizing changes to the existing OAA / OANZ procedure.

The objective of the invention is to provide an authentication voucher announcing user authorization in a communication network that implements the OAA / OANZ architecture.

Another task is to provide the identifier B_TID_NAF of the key associated with the user object of the OP, which is unique for each node of the network application of the FSF.

Another task is to prevent attacks with a wildcard connection on the Ua interface and to enable the FSES to check the sender of the boot identifier B_TID_NAF.

Another task is to organize communication between the FSF and the Federal Security Service in order to verify that the requirements of the FSF for user authentication are met without revealing such data in the connection that allows the user object to be tracked.

Another object of the invention is the group generation of keys Ks_NAF and the corresponding identifiers B_TID_NAF associated with many functions of the FSF network application.

The objective of the invention is to provide an authentication voucher so that it is unique for each FSF, thereby eliminating collusion between several objects of the FSF in relation to user tracking.

A specific objective is to provide a method and system for improved privacy protection and authentication support in a communication network implementing the OAA / OANZ architecture.

It is also a specific task to provide the FSNZ network node to support enhanced privacy protection and authentication.

These and other objectives are achieved by the method and device according to the attached claims.

In short, the invention includes a bootstrap server (FSNS) function, which creates, at the request of a user, an authentication voucher announcing that the user has been authenticated using any authentication method. Following the standard procedure, reference [2], the FSES generates the keys Ks and Ks_NAF, the latter for use in communication between the user and the network application function of the FSF. The Ks_NAF key is identified by the Ua interface according to the invention by means of the B_TID_NAF identifier, which is unique for each FSF, as opposed to the standard procedure in which the same B_TID is used for any FSF. A user accessing the function of the FSP network application provides the identifier B_TID_NAF, which allows the FSP to obtain the address of its home FSS from the identifier and request an authentication voucher from the FSS. In response to the identifier B_TID_NAF, the FSS can identify the authentication voucher for establishing the authentication status of the OP. Using the unique identifier B_TID_NAF prevents the creation of a user profile and increases privacy.

Additional optional confidentiality enhancements according to the invention are achieved, for example, by signing the B_TID_NAF (or alternatively B_TID) identifier using the Ks key known to the Federal Security Service and the user of OP. This prevents attacks with a wildcard connection on the interface between the user of the OP and the function of the network application of the FSF. The encryption of the transmission of the credential between the user of the OP and the FSES via the Ub interface by using the Ks key is another example of how to further enhance system security.

In an exemplary embodiment, any information that makes user tracking possible can be deleted from the authentication voucher, and it can only provide an announcement that user authentication has occurred. If the FSF has additional requirements for the authentication procedure, the FSF can submit these requirements to the FSZ, and the FSZ responds to them with confirmation of those requirements that are met.

In another exemplary aspect of the invention, the FSS sends an authentication voucher to the user of the UE over the Ub interface. The user submits the FSF authentication voucher that he is accessing. According to the invention, the FSP relies on the Federal Security Service to verify the authenticity of the authentication voucher before accepting an additional transfer from the user. The identification B_TID_NAF can also be used to extract the Ks_NAF key from the FSES, if the FSF additionally, for example, requires the establishment of session keys with the OP.

The invention is generally applicable to the existing OAA / OANZ infrastructure to improve privacy protection and authentication. Since OANZ is now being discussed for use in PHD systems, application of the invention in such systems is predicted.

The main advantage of the invention is the provision of a user authentication method without the need to implement, in the function of the network application of the FSF, support for key management.

Another advantage of the invention is the provision of improved privacy protection for the current OAA / OANZ infrastructure, including protection against collusion of FSP objects and wildcard attacks.

Other advantages offered by the present invention will be apparent from reading the following detailed description of several embodiments of the invention together with the accompanying drawings, and which are considered as examples only, and it will be apparent to those skilled in the art that numerous other possible embodiments are possible without departing from the main objectives of the invention.

Brief Description of the Drawings

The invention, together with its additional objectives and advantages, is easier to understand by reference to the following description, considered together with the accompanying drawings, in which:

figure 1 depicts a simple network model of objects included in the principle of bootstrapping, according to the prior art;

FIG. 2 is a flowchart of a bootstrapping procedure according to the prior art; FIG.

3 illustrates a block diagram of related parts of an exemplary boot server according to an embodiment of the invention;

4 is a flowchart of a bootstrapping procedure according to an embodiment of the invention;

5 is a flowchart that depicts a user object accessing a network application function;

6 is another embodiment that depicts a user object accessing a network application function;

7 depicts another embodiment, in which a user entity accesses a network application function;

FIG. 8 illustrates an embodiment in which an authentication voucher is unique to each function of a network application.

Detailed Description of Exemplary Preferred Embodiments

In a first exemplary aspect of the invention, an additional boot identifier is introduced to the B_TID currently defined in the OAA / OANZ specifications. B_TID and key Ks are generated according to the OAA standard. However, according to the invention, B_TID is used only between the OP and the FSES, i.e. on the Ub interface, while the additional boot identifier B_TID_NAF is usually used between the OP and the FSF on the Ua interface. B_TID_NAF differs from B_TID and is characteristic for each FSF.

According to the OAA / OANZ standard, an OP does not need to contact the Federal Tariff Service every time a new FSF is accessed, since B_TID is sufficient to determine the location of the FSF and identify the user's credential. However, as explained above, this approach compromises the confidentiality of the FSF facilities. Therefore, according to an exemplary preferred embodiment of the invention, additional signaling with the FSES for each new FSF is introduced. However, the signaling volume can be reduced by a group procedure, which is further described below.

The FSES maintains the relationship between the identification of the OP, B_TID, Ks and the set of identifiers B_TID_NAF and the associated keys Ks_NAF generated for the corresponding set of FSF objects.

Using a unique B_TID_NAF for each FSF prevents user tracking on the Ua interface.

Whenever the user wants to contact the FSF application, which requires only the identification / authentication of the user, the FSF will be sent to the Federal Security Service, which then acts as the authentication center / authority.

According to an exemplary preferred embodiment of the invention, the SSF generates an authentication voucher verifying that the user has been authenticated. The authentication voucher is identified by the B_TID over the Ub interface. On the Ua interface, an authentication voucher is identified by B_TID_NAF. The FSF can access the voucher by providing the identifier B_TID_NAF via the Zn interface.

Figure 3 depicts at 300 an exemplary block diagram of the function of the FSNZ bootstrap server according to the invention. Figure 3 depicts only those parts of the FSES that are related to the invention.

At 310, input / output means for communicating with other units is provided. The internal bus system 370 interconnects means of various functions. Under 320, means for generating keys and corresponding key identifiers, for example, key Ks and identifier B_TID, is shown. At 330, means for generating an authentication voucher is shown, and at 340, means for verifying the authenticity of an authentication voucher. An encryption / decryption tool is shown at 380. Random numbers are generated by the means 390. The storage means 360 stores the generated information, such as user identification data, Ks key, B_TID_NAF keys, key identifiers, and associates data related to a particular user. The processing means 350 controls the execution of the internal operations of the block 300. It is understood that the means of functions of the node 300 may be implemented in the form of hardware, software, or a combination of both.

An exemplary method for initially authenticating a user and creating bootstrap information according to the invention is clearer from FIG. 4, which depicts a signal flow diagram for an exemplary connection between an OP, FSNZ, DAS and FSP.

At stage 1, the OP initiates bootstrapping procedures by sending a request to the FSW. The request can be sent using the OP as a result of setting the configuration before accessing any FSF.

Alternatively, according to the standard, reference [2], the request may arise as a result of the FSP redirection command in response to the initial call attempt, and the FSP determines that the data of the previous bootstrap does not exist or has expired.

The request may include explicitly specified user identification data, for example, an international mobile station identifier (MIMS) or a personalized multimedia identifier PI (PIMP), link [5]. At least one B_TID_NAF identifier is generated that identifies the generated data for a particular FSF, for example, a key related to the FSF.

If the request concerns an operation involving a previously generated key Ks, for example, to generate a key obtained from Ks, Ks_NAF related to a given FSF, or to retrieve a previously generated key Ks_NAF, the request includes a B_TID instead of an explicit user identifier and at least identifier of one specific FSF. It is noted that B_TID is sufficient for the FSES to retrieve the OP identifier. This procedure is introduced in order to increase the confidentiality of the user identification in the additional signaling introduced according to the invention.

The request may also include the specification “spec”, providing additional requirements for the request. For example, such a specification may relate to specific requirements that the FSF may have, for example, whether a Ks_NAF key, an authentication voucher, or both are required, otherwise, should the specified authentication method be used, exemplary authentication based on the UMIA card.

In step 2, the FSES initiates a user authentication procedure if there is no valid boot key Ks for the user, as indicated by the user identifier (ID) or B_TID. As an example, the NAC authentication procedure may be performed, as is well known in the art, or the authentication procedure may use a public key algorithm.

At stage 3, the FSNC generates the initially loaded key Ks and, in addition, an authentication voucher. An authentication voucher, for example, may include information about:

• authentication time,

• authentication method, and / or

• authentication validity time.

Typically, the validity period of the authentication voucher and the initially loaded Ks is the same, but it can be set individually.

Information about the authentication method indicates, for example, whether the user has a UMIA or MIMUP card, or whether there was user authentication such as OANZ-mo based on mobile equipment, or OANZ-u based on a universal smart card (USK).

Next, at this stage, a B_TID is generated, and the Ks_NAF keys with the corresponding B_TID_NAF are retrieved. It also sets the expiration time for various objects, such as Ks, Ks_NAF keys, and an authentication voucher.

In step 4, the identifiers B_TID, (B_TID_NAF) n and the duration of the boot information are returned to the OP.

5 illustrates an exemplary process in which an OP refers to the FSF, requesting services. At stage 1, the OP addresses the FSF, presenting the identifier B_TID_NAF, which allows the FSF to extract the mandate of the OP from the FSN.

If required, or is otherwise suitable, the B_TID_NAF can be protected during transfers between entities, for example, using the Transport Layer Security Protocol (ROM) / Secure Connection Protocol (BSS). Additional application-specific data (msg) may also be included.

The FSF submits a request for user authentication in step 2 by sending the received B-TID-NAF identifier. To eliminate the need for FSF applications that are only interested in user authentication to support and implement additional key management and user authentication mechanisms, the FSF application may request the FSN to submit only a user authentication voucher. Thus, in step 2, the FSF can include information (info), for example, to indicate the need for an authentication voucher, the key Ks_NAF or wallpaper these objects.

At stage 3, the FSES returns to the FSF the requested information. The response of the FSES to the FSF can be protected by some protection of the transport layer, for example, PZTU / PBS. In addition, at least part of the user profile (Prof), key lifetime (Key Lifetime), authentication voucher and response message (respmsg) can be included. The authentication voucher enables the FSF to verify user authentication. As mentioned in relation to FIG. 4, the FSS may also include instructions for redirecting the OP request to the FSS to generate a new mandate if it is absent or has expired.

Alternatively, only the authentication voucher is returned to the FSF, for example, FSF applications that are only interested in user authentication.

In step 4, the FSF typically stores at least some of the received information. In particular, the FSF may not need to store an authentication voucher after verification. This means that if only an authentication voucher has been returned, it may not be necessary to store any information. If the key Ks_NAF was accepted, it can be used during subsequent calls by the OP as long as the key lifetime is valid. The FSF preferably checks the information in the authentication voucher to verify the authentication status of the end user. However, as will become apparent from the description of alternative embodiments below, verification of the authentication voucher can, alternatively, be performed on the FSES.

In step 5, the FSF may respond to the initial request in step 1, indicating whether the OP needs to request a new mandate from the FSES in accordance with FIG. 4. In this case, the identifier B_TID is used in step 1 of FIG. 4.

In a second exemplary aspect of the invention, an authentication voucher is sent to the user equipment of the UE via the Ub interface. The OP represents the FSP voucher when requesting services from the FSP. With reference to FIG. 4, according to this second aspect of the invention, step 4 preferably includes an authentication voucher, or, alternatively, is sent separately. 6 illustrates an example of an OP accessing the FSF using an authentication voucher. At stage 1, the OP sends a request to the FSF, including a voucher. At stage 2, the FSF extracts from B_TID_NAF the address for the FSNZ and, for example, checks the validity of the voucher when communicating with the FSNZ. This is indicated by a dashed line in FIG. 6.

If the voucher is valid, the FSF may request, at step 3, the key from the FSES, as indicated by B_TID_NAF. In step 4, the FSWS typically responds with a key (Ks_NAF), key lifetime (Key Lifetime), and preferably also at least a portion of the profile information (Prof). The key request and response in steps 3 and 4 can also be included in step 2 as part of the transfer between the FSF and the FSES in the process of checking the voucher. At step 5, the received information is stored, and at step 6, the response is provided to the user object of the OP. It is again noted that the Ks_NAF key request is optional, and that, only for authentication, a voucher is sufficient.

Exemplary Alternative Embodiments

In an exemplary embodiment of the invention, B_TID and B_TID_NAF of FIG. 4, step 4 is encrypted by Ks. Since the OP has the same key, it can decrypt these objects.

According to another exemplary embodiment, a plurality of NAF_IDs may be included in the query of FIG. 5, step 1, to simultaneously generate a corresponding plurality of Ks_NAF keys and B_TID_NAF identifiers, thereby reducing the amount of signaling by eliminating a specific request from each individual FSF.

7 illustrates another exemplary embodiment in which, to prevent wildcard attacks on the Ua interface, the identifier B_TID_NAF is characterized in that it is only one-time. As an example, B_TID_NAF is signed using the Ks key, known only to the OP and the Federal Security Service. The signature may include a sign of renewal. The signature according to this embodiment, included in steps 1 and 2, as shown in FIG. 5, is included as an example in a message parameter (msg).

At step 3 of FIG. 7, the signature and update are verified at the FSES using the key Ks.

Steps 4-6 are similar to steps 3-5 in FIG. 5.

According to an alternative embodiment of the first aspect of the invention, the authentication voucher is limited to the message that authentication has been completed. It is noted that some information, as indicated in the first aspect of the invention, such as an authentication method and time for authentication, can be used to track a user, and thus to carry out a privacy attack. According to an alternative embodiment, the information contained in the voucher is limited to information that does not allow any such tracking. If the FSF requires additional information in order to receive an authentication announcement, it can send these requirements to the FSS, after which the FSS then checks the requirements that are met. As an example, the FSF may require that the user authenticate based on the UMIA card. This question / answer dialog can be included in steps 2 and 3 of FIG. 5, in which the parameters (info) and (respmsg), respectively, can contain the requirements of the Federal Tariff Service and the answer to them of the Federal Security Service.

As for the second aspect of the invention, step 2 of FIG. 6 may be implemented as described in the following alternative embodiments.

In one embodiment, the key Ks encrypts the authentication voucher, and the verification is performed by the FSF sending the encrypted authentication voucher to the FSNS. The Federal Security Service has the key Ks and can decrypt the authentication voucher and verify its authenticity. Thus, with reference to FIG. 6, in step 1, an authentication voucher is encrypted. The transmission indicated by the dashed line in step 2 of FIG. 6 now includes sending the encrypted authentication voucher to the Federal Security Service for verification.

It is noted that, in previous embodiments of the second aspect of the invention, each FSP accepts the same authentication voucher, thereby providing some possibility of collusion of FSP objects to track a user. This problem is solved in another embodiment depicted in FIG. According to this embodiment, the authentication voucher is unique for each FSF.

With reference to FIG. 8, step 1, the OP sends a request to access the FSF1 including an encrypted authentication voucher, whereby the encryption function (Encr) mainly depends on the encryption key Ks, the encrypted data, i.e. authentication voucher, and random number (Rand1). Basically, encryption has the form Encr (Ks, voucher, Rand1). In one particular embodiment, Rand1 is concatenated with the voucher and the encryption is Encr (Ks, Rand1 || voucher), where “||” means the clutch.

Since the FSF does not have the Ks key and cannot decrypt the authentication voucher, the FSF sends the FSN message in step 2 for verification.

At step 3, the Federal Security Service decrypts the message, retrieves the authentication voucher, and checks the authenticity of the authentication voucher. After that, the Federal Security Service determines the second random number (Rand2) and performs double encryption using the Ks key, an authentication voucher, according to the formula:

Encr (Ks, Encr (Ks, Voucher, Rand2)).

At step 4, the Federal Security Service sends back a message to FSF1 about the verification result, which includes a double encryption authentication voucher. FSF1 sends the feedback message to OP at step 5. At step 6, OP decrypts once the message with double encryption and receives:

Уравнение(1)Encr (Ks, Voucher, Rand2)

Equation (1)

In the upcoming call, for example, to FSP2 in step 7, the OP provides an encrypted authentication voucher according to equation (1), now including a second random number (Rand2). The same procedure as before is repeated, as shown in step 8. Thus, each call to the FSF will use a unique authentication voucher, preventing user tracking.

References

Claims (23)

1. The method of establishing the authentication status of a user object in a communication network that implements OAA / OANZ (generalized authentication architecture / generalized bootstrap architecture), and in which the network node (120) FSNS (functions of the bootstrap server) performs the initial steps, at least comprising authorization of the user object of the OP (140) and the establishment of at least one security key shared with the OP, containing the first key Ks and the associated identifier B_TID of the key, and at least one second The swarm key Ks_NAF obtained from Ks and associated with at least one function of the network application of the FSF (130), for improved privacy protection and authentication support, comprises the steps of:
additional generation by the FSNZ network node of an authentication voucher announcing that the OP has been authenticated;
generating at least one key identifier B_TID_NAF associated with said at least one second key received, wherein the key identifier is unique to each FSF;
sending by the network node FSNZ identifiers B_TID and at least one identifier B_TID_NAF on the OP;
providing the FSP network application function, in response to an OP request for services, including at least one B_TID_NAF identifier, at least the mentioned B_TID_NAF identifier for the FSS;
identification by the network node of the FSNZ, in response to the said identifier B_TID_NAF, of the OP authentication voucher for the possibility of establishing the OP authentication status. 2. The method according to claim 1, in which the user object OP is identified, on the Ub interface between FSN3-OP, the mentioned identifier B_TID. 3. The method according to claim 1, wherein the step of sending the identifier B_TID of the key and at least one identifier B_TID_NAF from the FSES to the OP further comprises encrypting the identifiers using the key Ks. 4. The method according to claim 1, in which the authentication voucher is unique to each FSF and is identified by the said at least one identifier B_TID_NAF. 5. The method according to claim 1, wherein the step of providing further includes providing a signature of B_TID_NAF, wherein the signature is created by the OP using the key Ks and is included in said request for services. 6. The method according to claim 5, in which the signature includes a sign of renewal. 7. The method according to claim 5, further comprising the step of verifying the FSES signature B_TID_NAF. 8. The method according to any one of claims 1 to 5, further comprising the step of establishing the FSP authentication status by requesting an authentication voucher from the FSNZ network node. 9. The method according to any one of claims 1 to 5, further comprising the step of establishing an authentication status of the FSN by analyzing the authentication voucher. 10. The method according to any one of claims 1 to 5, in which the FSF with the said provision further includes requesting a key Ks_NAF. 11. The method according to any one of claims 1 to 5, in which the authentication voucher includes information about at least one of: validity time, time for authentication, and authentication method. 12. The method of claim 8, further comprising the steps of:
submission of FSP for the FSNZ network node of additional requirements to confirm the authenticity of authorization;
inspections of the Federal Security Service for the Federal Tariff Service, which of the additional requirements are met. 13. The method according to any one of claims 1 to 3, further comprising the step of sending the FSNS to the OP authentication voucher, together with sending identifiers or separately from them. 14. The method according to item 13, in which the authentication voucher is unique for each FSF and is identified by the mentioned at least one identifier B_TID_NAF. 15. The method according to 14, in which the authentication voucher is unique by encrypting its FSS using the key Ks and a selected random number (Rand), different for each FSP, according to the formula Encr (Ks, voucher, Rand), where Encr is an encryption function, and wherein said method further comprises establishing an authentication status by:
sending encrypted FSNZ authentication voucher;
decryption FSNZ voucher authentication and verification of its authenticity;
selection of a new random number by the Federal Security Service (Rand2) and re-encryption of the authentication voucher for the second time with the key Ks as follows: Encr (Ks, Encr (Ks, voucher, Rand2));
return of the FSNZ re-encrypted authentication voucher to the OP through the FSF;
decrypting the OP of the received authentication voucher once to receive: Encr (Ks, voucher, Rand2);
use of OP decrypted authentication voucher once upon subsequent access to the FSF. 16. The network node FSNZ (120) in a communication network that implements the OAA / OANZ architecture authenticates the user object OP (140) and negotiates the shared key Ks with the OP (140), and the network node FSNZ (120) additionally contains:
means (320) for generating the identifier B_TID associated with Ks;
means (320) for generating at least one received key Ks_NAF associated with at least one function of the network application of the FSF (130) and for generating at least the corresponding identifier B_TID_NAF, the identifier being unique for each FSF (130);
means (330) for generating an authentication voucher announcing that the OP has been authenticated;
means (360) for storing keys, key identifiers and an authentication voucher and for linking these objects to the OP;
means (310) for sending a B_TID and at least one B_TID_NAF to an OP;
means (360) for retrieving, in response to receiving at least one identifier B_TID_NAF, related to the user equipment of the OP, the corresponding authentication voucher for the possibility of establishing the authentication status of the OP. 17. The network node according to clause 16, further comprising means (380) for encryption using the key Ks and the encryption algorithm (Encr). 18. The network node according to claim 17, comprising means (390) for generating a random Rand number, and wherein said encryption means (380) is used to encrypt the authentication voucher in the form of Encr (Ks, voucher, Rand). 19. The network node according to clause 16, comprising means (310) for receiving and responding to a request from the FSF regarding authentication details of the user object of the UE received from means (340) that analyzes the authentication voucher. 20. The network node of claim 19, wherein said request relates to any or all of an authentication time, an authentication method, or an authentication validity time. 21. A system for providing improved protection of confidentiality and authentication in a communication network that implements infrastructure (100) 0АА / 0АНЗ, the system comprising:
the function of the FSNZ bootstrap server (120), which provides an authentication voucher declaring the authentication of the user OP object (140), and the identifiers B_TID_NAF of the keys Ks_NAF associated with at least one function of the network application of the FSF, and the identifiers are unique for each FSF (130) ;
an Ub interface between the FSNZ (130) and the OP (140), which is further protected by encryption using the key Ks shared by the FSNZ (130) and the OP (140);
the Ua interface between the OP (140) and the FSF (130), which is additionally protected against attacks by a wildcard connection by signing messages using the Ks key and the update sign;
at least one function of the network application FSP (130), designed to communicate with the Federal Security Service (120) regarding the validity of the authentication voucher, so as to prevent collusion of several FSP (130) in order to track the user object OP (140). 22. The system of claim 21, which further comprises: means (330) for restricting information in the authentication voucher to only declaring that authentication has taken place;
means for providing the FSF (130) for setting additional requirements related to user authentication, and means (340) for the FSES (130) to verify that each additional requirement is met. 23. The system according to item 21, which further comprises means (380) for encrypting the authentication voucher using the key Ks and depending on a random number, so as to generate a unique authentication voucher for each FSP (130).

Images