WO2009080854A1 - System for remotely authenticating the identity of users by means of network-based smart cards - Google Patents

Abstract

The invention relates to a system for remotely authenticating the identity of users by means of smart cards, comprising: a smart card (10) which provides a user authentication certificate (C.X.509.U_AUT), an access point (20) for the smart card, and a remote authentication server (30) for authenticating said smart card. According to the invention, the smart card (10) is configured as an independent authentication requester in order to respond to a stack of network protocols, in relation to which a remote, smart-card-controlled authentication mechanism is implemented, and the access point is configured as a network access server in order to act as an authentication intermediary (A) between the smart card and the remote authentication server. In response to a remote mutual authentication between the remote authentication server and the smart card, an end-to-end secure channel (40) is maintained using a session key (Ksk, KSA/eID) and defined between the smart card and the remote authentication server and the identity of the user is authenticated by means of said secure channel using the authentication certificate (C.X.509.U_AUT).

Description

 REMOTE AUTHENTICATION SYSTEM OF THE IDENTITY OF USERS THROUGH INTELLIGENT NETWORK CARDS.

Field of the Invention The present invention is encompassed within the centralized systems of

People Identification using cryptographic hardware tokens. More specifically, in smart cards (or smart cards), and their use for the remote validation of identity credentials.

Background of the Invention

The definition of identity can be specified in the set of features of an individual or a community that characterize them in front of others or, beyond, as the awareness that a person has to be himself and different from the rest. Thus, the identification can be considered as the action that allows to recognize if a person is who is supposed.

Identity management and related security services have come to represent an important challenge. A certain person (with a specific identity, therefore) is authorized to perform certain actions to the extent that an entity with the corresponding authority relies on its behavior according to certain expectations associated with said person. In this way, from the techniques of "authorization", as well as those of "access control", an important set of challenges for identity management are derived. From a broad perspective, the inclusion of identification should be understood as another element for risk mitigation in the management of security systems.

The electronic identity credentials are those logical elements whose main function is to associate a set of attributes with the identifying elements of a subject. The process by which a subject proves his identity is Authentication. In this way and in a general way, identity credentials can be logical or physical structures that operate together, or separately, in order to provide such identity to the holder of a given credential.

There are several characteristics of a logical type that an electronic identity card may contain: a PIN or password to access secure information or authentication codes (hash, CRC, etc.), keys and certificates under PKI infrastructures, keys based on algorithms used to encrypt / decrypt data or validation cryptograms, as well as biometric identifiers.

One of the most effective means for the portability of the electronic identity credentials associated with individuals is the cryptographic hardware devices (eg USB, smart cards or smart cards, etc.) which, in addition to their widespread use in a multitude of scenarios, its size and shape facilitate its manageability. Specifically, smart cards are considered as secure devices whose application in identification schemes have been extended universally in recent years in the form of "electronic identification cards" or "ID-cards" (equivalent to the Spanish electronic ID) or electronic passports. In general, these systems allow both off-line (local) authentication processes between the smart card and the Terminal (which incorporates the card reader) and on-line (remote) processes. These remote identification systems based on electronic cards (ID cards, hereinafter D) can be presented on the basis of different schemes depending on the objectives pursued (digital signature, authentication, personalization, etc.). Figure 1 shows a generic scheme of remote identification with smart card, consisting of the following elements: - User, U

User X.509v3 Authentication Certificate, C.X509.U_AUT [Note: An X.509v3 authentication certificate is characterized by the "Digital Signature" type in the "KeyUsage" field, as opposed to a recognized signature certificate that is of type "contentCommitment". The keys for said authentication certificate must be generated in the cryptographic card itself, which must meet a security level

CC EAL4 +. The control over the associated private key and the authentication certificate itself constitute the "identity card"].

Smart Card supporting the identity card, eID Smart Card Component Certificate, C. elD.AUT (mandatory in unreliable environments) [Note: this is a Verifiable Card certificate according to

ISO 7816-8]

Terminal or Host (incorporates the card reader functionality), H Host Component Certificate, C_CV.H.AUT (optional, although mandatory in unreliable environments, according to regulations) Servidor Remoto de Authentication, SA.

In this way, the identification of a user is carried out by means of an authentication protocol in which, basically, he must present the authentication certificate C.X509.U_AUT and encrypt with the private key associated with this certificate a challenge (challenge) sent by the entity on the other side of the communication (eg, the remote authentication server SA).

This usual scheme of the use of C.X509.U_AUT for remote identification is included in the CWA 14890-2 "Application Interface for smart cards used as Secure Signature Creation Devices. Pari: 2: Additional Services", CEN, EUROPEAN COMMITTEE FOR STANDARDIZARON, May 2004, under the heading "Client / Sen / er Authentication" and is represented in the authentication scheme of the identity of the user of Figure 1; in this case, with the objective of establishing a secure session with the SSL protocol between H and SA, although other protocols are possible (WTLS or Kerberos). At this point it is worth noting the difference between authentication between devices ("Device Authentication") and the authentication of user identity. Although for the first one, shared secrets (symmetric cryptography) or component certificates (asymmetric cryptography) are used - own devices and interpretable by an eID -, in the second one authentication certificates are used according to the X.509v3 standard, issued to each user and specific for identification before the system. Said certificate, although it cannot be verified by the eID, is carried on it and used, on demand, in user identification processes. Therefore, even if a process of the type "device authentication" could derive - after mutual device authentication - in an end-to-end tunnel between eID and SA, by not requiring the authentication certificate C.X509.U_AUT does not constitute itself same a user identification process.

Although the scheme of Figure 1 requires user authentication remotely, the ultimate goal is not its identification but to provide a mechanism for establishing secure communication between a Terminal

(on the user side) and a remote server. Thus, the use of this scheme for the identification of users has the following drawbacks, and therefore, possibilities for improvement: 1) There is a clear decoupling between the authentication processes eID-H and H-SA: decouple in the plane of communication (layers) and in the authentication itself. Consequently, the D has no information on the result of the authentication between H and SA (application layer), and even the SA does not have information on the result of the authentication between eID-H (device layer). At the same time, D and SA do not authenticate directly; that is to say, there is neither communication nor mutual authentication in this plane.

2) It is necessary to previously authenticate the eID-H devices (mandatory requirement in an unreliable environment). A failure to update the component certificate of H, for example, would temporarily block the communication of eID with the system and therefore, the identification of the user. In this case, the eID does not have sufficient resources (flexibility) to face certain incidents in this authentication process. At the same time, the remote process is subject to a large extent to this local process.

3) Once the corresponding authentications have been carried out in Interface 1 and in Interface 2, different session keys have been established in both interfaces. Host H decrypts and encrypts the traffic in both directions of the communication, but would access the information that passes through it clearly. This fact prevents, for example, that this scheme can send commands from the SA to eID through a single secure channel, so that a double tunneling, after an additional process of mutual authentication would be necessary

4) Terminal H, as the end of both communications, derives and controls the session keys (SK1 and SK2) corresponding to both interfaces. That is, excessive role is given to the role played by Terminal H, which is undesirable in an unreliable environment. 5) The authentication process and the establishment of the secure channel in Ia

Interface 2 is directed by H that needs the user authentication certificate C.X509.U_AUT, stored in the D for its establishment (normally, support on host H of the PKCS # 11 and CSP standards is required). This eID-H collaboration (which behaves as a single client against SA) in the U authentication process is undesirable and may result in man-in-the-middle attacks, originating in H.

6) A public terminal is characterized, not only by being "untrustworthy" a priori but also because, often, the user does not have control over this device to validate in a safe and reliable way (for example through the OCSP protocol) certificate received from the remote server.

Unlike the approach presented in Figure 1, recent advances in smart card technology have made it possible to start treating these devices with functionalities similar to those of any other host within a network. Thus, the so-called "network smart card" (for example, in

Montgomery, M., AIi, A. and Lu H. K., "Secure Network Card. Implementation of a

Standard Network Stack in a Smart Card ", In Proc. Of 4 ^th IFIP Smart Card Research and Advanced Application Conference, CARDIS '04, Toulouse, FR, Kluwer

Academic Publishers, August 23-26, 2004) could communicate securely with other computers in the network using the most common communication protocols such as TCP / IP and SSL / TLS.

However, this specific approach of network smart cards, which in theoretical terms guarantees its general purpose, obliges the complete implementation of the TCP / IP protocol stack plus other higher layer security protocols, which implies an overload (approximate 80%) computational, memory and bandwidth, so that its implementation becomes impracticable for application in the identification of users.

The present invention takes all these inconveniences and deficiencies as challenges and provides an effective and safe solution, applied to the identification of people. The following section describes the essential elements of this invention.

Thus, the electronic identification systems based on smart cards for the remote authentication of the identity of users currently employed suffer from the following aspects: - They have excessive confidence regarding the role played by the

Terminal in said authentication processes.

This fact becomes especially latent when observing that according to the technology used so far, the Terminal cooperates or collaborates in the process and authentication of the smart card; therefore it is necessary to highlight the dependence of the card with respect to the Terminal, and consequently the lack of autonomy of the smart card in said process, which at that time should be considered the electronic representation of its holder.

The smart card does not behave like a device integrated in the network, due to the lack of interoperability of the protocols that it implements and, therefore, it lacks the flexibility that any network node must have for its operation with the system in a transparent way, allowing its adaptation to the rapid changes to which This one is subjected. - Given the exceptional circumstance (for example, maintenance or repair) that a remote authentication server is not available, local user identification mechanisms must be provided based on different techniques that would force the smart card and Terminal to support a different strategy to guarantee the availability of the identification service. - An implementation according to the known "network smart card" concept, based on a complete protocol stack - such as TLS / TCP / IP or similar - implies a cost of computing, memory and bandwidth not only unnecessary but also impracticable.

Description of the Invention

The invention relates to a remote authentication system of a user according to claim 1. Preferred embodiments of the system are described in the dependent claims.

The deficiencies mentioned above are overcome with the system of the invention, since it is a system in which the authentication is performed remotely between smart card and remote authentication server, without collaboration in the authentication process between smart card and Terminal ( access point). The smart card in the present invention behaves as an autonomous client ("by itself") against the remote authentication server in the process of user authentication. This minimizes the chances of man-in-the-middle attacks, originating from the access point (or Terminal).

According to a first aspect of the invention, this refers to a remote authentication system of an identity of a user, comprising: a smart card that provides a certificate of authentication of said user (such as, CX509.U_AUT) , an access point or Terminal for said smart card, a remote authentication server to authenticate said smart card,

According to the invention, in the remote authentication system: said smart card is configured as an authentication requestor independent, and responds to a network protocol stack that implements a remote authentication mechanism controlled by said smart card; said access point is configured as a network access server and to act as an authentication intermediary between the smart card and the remote authentication server; and in response to a remote and mutual authentication between said remote authentication server and smart card, an end-to-end secure channel is established by a session key, said secure channel being defined between said smart card and said remote authentication server; and - through said secure channel an authentication of the user's identity is executed by means of said authentication certificate.

Preferably said secure channel defined between smart card and remote authentication server is unique, establishing a single session key. Said end-to-end secure channel defined between the smart card and the remote authentication server can be established by authentication of both parties by asymmetric cryptography, based on a first and second component certificates associated with said smart card and said remote authentication server, respectively. Said end-to-end secure channel defined between the smart card and the remote authentication server can also be established by authentication of both parties by symmetric cryptography, based on a first and second shared secret keys associated with said smart card and said remote authentication server. respectively. In addition, mutual network authentication can be carried out between the access point and the remote authentication server.

In addition, a session key can be established, different from the session key for the secure channel defined between smart card and remote authentication server, to encrypt traffic between the smart card and the access point.

Preferably in the system the type of mechanism is established to make use of the authentication certificate stored in the smart card; Said mechanism may be based on biometric techniques or verification techniques of a user's PIN. The domain of employment of said user authentication certificate may also be established in the system, which may be corporate (in which case said user is a member of a company) or governmental (in which the user is a citizen or individual). The remote authentication system of the present invention implies the following technical advantages:

1) Eliminates the decoupling between the smart card (elD) -Terminal (H) and Terminal (H) authentication server (SA) authentication processes (included in the communication plane). Entities have implicit information about the result of authentication processes.

2) It is not necessary to authenticate previously smart card-Terminal; however, the level of security that is necessary in unreliable environments is preserved. The information initially exchanged does not compromise the security of the system. The possibilities of blocking authentication processes are reduced, in case of incidents with the status of component certificates. In short, the smart card is provided with the resources to undertake a robust authentication process - although elastic in the event of possible incidents -, resting on the remote server SA, instead of relying on the Terminal or host H. At the same time, before certain exceptional circumstances - and always in a controlled way - the Terminal could incorporate the functionality of the SA in the temporary absence of the latter, without the need to change the protocols in any of the entities and always transparently to the smart card and its user.

3) A single KSK session key is established for a single tunnel in the defined interface between smart card and SA authentication server (interface A), although the possibility of subsequently deriving a different session key for the defined interface between Terminal-card in order to encrypt the traffic between the two, and therefore for purposes other than those of user authentication.

4) Terminal H does not derive or control the KSK session key in the new Interface A, but it is the smart card and the authentication server that can derive and control said key, as authentic communication ends. The interest of said secure channel through this session key not only lies in the need to use said channel to safely carry out the identification of the user but also in the possibility of using it in additional or complementary authentication processes (through an additional authentication factor, re-authentication processes, recognized digital signature, etc.)

5) The authentication process and the establishment of the secure channel in Interface A from the user side is directed by the smart card that provides the user certificate C.X509.U_AUT that it stores. There is no Card-Terminal collaboration in the authentication process, therefore the smart card behaves as an autonomous and independent client in front of the authentication server SA, in the process of user authentication U. In this way the possibilities of minimizing man-in-the-middle attacks, originating in Terminal H.

6) Additionally, under the authentication scheme of the present invention, other functionalities intimately related to it could be accommodated, such as authorization and accounting, in a transparent integration, complementing the benefits of previous schemes. 7) An implementation for this system minimizes, while making it feasible, the requirements of the smart card in terms of computing, memory and bandwidth, compared to proposals of the "network smart card" type indicated in the Background of the Invention .

Brief description of the drawings

Next, a series of drawings that help to better understand the invention and that are presented as illustrative but not limiting examples thereof are described very briefly.

Figure 1 shows a diagram of a standard user identification process by means of the smart card-based remote authentication of the D that stores its authentication certificate, for the establishment of a secure channel between H and SA.

Figure 2 schematically shows the elements of the developed architecture. Figure 3 shows in more detail the different elements of the system architecture of the invention with their corresponding protocols.

Figure 4 shows a diagram of an example of the exchange of messages in the authentication process of the invention.

Figures 5 and 6 show two examples of application of the process described in Figure 4 with asymmetric and symmetric cryptography, respectively, and detailing the possible implementation of protocols A, B and C.

Detailed description of a preferred embodiment of the invention

As described in the Background of the Invention, Figure 1 shows a scheme of a standard remote authentication process with a smart card D. Specifically, this scheme reflects the process described in the CWA 14890-2: 2004 regulation, under the heading "Client / Server authentication".

As already indicated, in this scheme it can be seen how the card is a mere credential support (in the form of certificate X.509v3) of the user that will be required in the process of establishing a secure SSL / TLS channel between the Terminal o Host (a PC in this case) and a remote SA server. Once this phase is over, this channel will allow the exchange of secure information between both entities (H and SA). The communication between the eID card and the Terminal is carried out according to what is established in ISO 7816. That is, it is a system in which the authentication takes place in a single phase, with the aim of authenticating the User for access via channel Secure to remote services. In addition, there can be local authentication between devices and establishment of a secure channel between them, on ISO 7816 technology. In Figure 2 the essential elements that compose can be identified

The architecture of the system of the invention. These elements are:

ID-NSCard 10 card: this is an eID smart card, which responds to a specific protocol stack for the remote authentication process and, therefore, incorporates a specific authentication method for this architecture. It participates as a support and store for the identity credentials of the users, as well as an element that autonomously implements the authentication and communication mechanisms with the system remotely.

Access Point 20 for ID-NSCard: it is a Terminal or Host that is a version adapted to this architecture of the traditional controllers and smart card readers ISO 7816. This adaptation in its protocol stack is given by the functionality as Authenticator (authenticator) and that has the access point within the authentication scheme.

Remote Authentication Server 30 for ID-NSCard: responds to a stack of standardized secure protocols, also incorporating the method of authentication. In Figure 3 the architecture of the invention is explained in more detail, with the different protocols of each element.

Protocol A means a standardized protocol in network systems, point-to-point connection between two devices (layer 2). This protocol can provide a spectrum of services, once connectivity is available in the link layer, since it must allow the encapsulation of datagrams of different protocols, which can be incorporated as an upper layer, for additional purposes. Although protocol A includes within its specification its own authentication mechanisms, it must be able to be extended by means of a protocol B that improves or extends said mechanisms.

On the other hand, the choice of this protocol A must be made to the extent that it allows, due to its characteristics, the interoperation with the original protocols of an ISO 7816 smart card, regardless of the physical layer used: with or without contacts. Thus, said protocol must be able to work with physical layers that operate in synchronous or asynchronous mode. Although there are, and will be, a variety of technologies to be used in this layer of the smart card, the most accepted so far allow full / half duplex asynchronous communication with different transmission rates. Therefore, protocol A must also be able to conform to these characteristics. In relation to fragmentation details, protocol A must be able to adapt the MRU (Maximum Receive Unit) to different sizes, including small sizes, usually required on smart cards.

On the other hand, protocol B is a standardized protocol in network systems, which allows the extension of the possibilities of end-to-end authentication in layer 2, both of users and of the smart card, which they use for electronic identification purposes, in front of a remote authentication server. Normally, this type of authentication extension protocols have double functionality: on the one hand they are responsible for transporting authentication messages end to end, and on the other they allow the implementation of specific authentication algorithms and mechanisms, which are usually known as the "authentication methods of protocol B" and of which the same device could implement a set of them. Protocol B must provide tunnel mechanisms so as to encapsulate one authentication method within another. For its part, in this invention the authentication method of protocol B must allow (i) the user's authentication (identification based on their credentials, C.X509.U_AUT), (ii) Ia of the device used (smart card, through its C.elD.AUT certificate) and (iii) the device or equipment that acts as an authentication server (through C_CV.SA.AUT). In this sense, protocol B must allow the establishment of a secure end-to-end initial tunnel (between the smart card and the authentication server), based on the credentials of the devices, and therefore, different from those belonging to the user . Said secure tunnel comes from the successful result of mutual authentication between these devices. Under said tunnel we proceed with the electronic identification of the user based on their credentials.

Therefore, the specifications of protocol B must allow the separation of authentication functionalities as follows:

Authentication applicant (supplicant), S: entity at the end of a point-to-point segment, which is authenticated by an authenticator A at the opposite end of the link. The term supplicant is also known as claimant, peer or authenticating peer.

In the present invention this functionality falls clearly on the ID-NSCard smart card. - Authenticator, A: entity at the end of a point-to-point segment that intermediates (pass-through) in the authentication of an associated entity at the other end of the link. It is, therefore, the entity that guarantees and controls access.

In the present invention this functionality falls to the access point or host H.

Authentication server, SA: entity that provides an authentication service to an authenticator A. This service determines, based on the credentials provided by the authentication requestor

(supplicant), S, whether or not he is authorized to access the services provided by the authenticator A.

In the present case, the authentication server function is implemented in another entity (physically different) that is accessed through a network (for example, of the TCP / IP type), to which the authenticator A has access.

This separation of the functions between authenticator and server of authentication simplifies the management of credentials and the implementation of decision policies; Although this aspect complicates the security analysis and the distribution of keys (if necessary), it facilitates scalability. However, this system allows that in exceptional situations and under control, the authentication server is not physically separated from the Terminal and without this requiring any change in the implementation of the entities, including the ID-NSCard card.

The decision of the authentication server typically considers aspects of authentication, authorization and registration or accounting.

In the present invention this functionality falls to the remote authentication server SA.

As it is not an application data transport protocol, but an architecture to transport authentication protocol packets, protocol B does not require IP layer connectivity. On the other hand, this protocol B is "one step with blocking" (lock-step) so that a single packet can be in transit in either of the two directions of the communication (based on request-response).

Protocol B must be flexible in that it must allow the selection of an authentication method -from a set of them- on the side of the smart card (as applicant, S). At the same time, you must allow the authentication server to implement various authentication methods of protocol B.

That is, it must be possible to agree between the extremes the use of one in particular, without the need to fix in advance one in particular. In the present case, Access Point 20 does not have to understand each authentication method. Protocol B must incorporate the retransmission mechanisms, being in the lower layers (protocol A) where order in the transmission is guaranteed {ordering guarantees), and the detection of duplicate (duplicate elimination).

On the other hand, it does not have to incorporate fragmentation and reassembly mechanisms, and these mechanisms may be incorporated by the authentication methods of protocol B.

As for protocol C, it is a standardized protocol in network systems, which at the application level and over UDP-TCP / IP networks, allows the establishment of authentication and authorization remote access sessions (optionally also accounting ) between two network devices with the corresponding functions of authenticator (client in protocol C) and authentication server (server in protocol C). The protocol C must allow the extension in the authentication possibilities by means of a protocol B, and therefore, of a set of possible authentication methods of the protocol B. Thus, the protocol C must allow the appropriate encapsulation of the protocol B.

In the present invention, Access Point 20 acts as a client in protocol C and the authentication server SA as a server in said protocol, which must also guarantee the establishment of a secure communication between both entities, and independent of other possible secure tunnels between other entities of the scheme.

Other network equipment 25 that intermediate between the authenticator A and the authentication server SA must implement intermediation (proxy) functions of the protocol C, being limited to the retransmission of the messages related to said protocol. Starting from this architecture, the authentication (protocol B) of the identity of the user 11 of the present invention is carried out in two phases, according to Figure 4: 1 ^a ) First, in a first phase a secure tunnel or channel is established 40 between the ID-NSCard smart card and the SA remote authentication server, after the remote and mutual authentication of both parties on the scheme represented in Figure 3. This end-to-end authentication between devices and establishment of a secure channel between them occurs over network technology The card on behalf of the user, authenticates the SA over network technology.

There are several possible ways to establish this end-to-end tunnel: - a form based on the prior distribution of secrets (symmetric cryptography), of which an example is illustrated in Figure 6.

Other forms based on asymmetric cryptography (component certificates), of which an example is illustrated in Figure 5.

In both cases the tunnel is established by a session key K _S χ. derived from the keys K _e ι _D and K _SA ; However, the latter keys are created differently, depending on the case represented in Figure 6 or Figure 5.

In the example of symmetric cryptography (Figure 6) the Kei _D and K _SA keys are generated as a random number of 32 bytes. To communicate to the other end of the corresponding Ia communication, the previously distributed secret keys K _EN c and K _{MAC are used} in the CGA3 and CGA4 cryptograms.

In the case of asymmetric cryptography (Figure 5), it has been assumed that both parts of the communication have, respectively, the 32-byte keys Kei _D and K _SA - To authenticate each other and securely exchange said keys, the keys are used CGA1 and CGA2 cryptograms, which transmit certain elements (including said keys) signed by the private key in each case, and the set of each cryptogram encrypted with the public key of the target device. The ends are authenticated by the corresponding decryption and verification of said signature.

The terms used in Figure 5 (asymmetric scheme) are explained below:

PK.CA _SA -CS_AUT: is the authentication certificate for SA signed by the certification authority; allows validating the certificate C_CV.SA.AUT. K _SA : 32-byte key in SA

PK.CA _and i _D .CS_AUT: authentication certificate for eID signed by the certification authority; allows validating the CeI D. AUT certificate.

Kei _D : 32-byte key available in eiD.

In the [MO] message:: RND.elD. Random number generated by eID.

In the message [M 1]:

: C = (RND. SA || SN. SA). Value generated by SA, with a random value and a serial number.

: C_CV.SA.AUT. SA component certificate. : Ref (PK.CA _SA -CS_AUT). Reference to the certification authority.

: KeylD (SK.elD.AUT). Identifier of the expected signature key.

: KeylD (PK.SA.AUT). Identifier of the public key of SA.

In [M2]:

: C. elD.AUT. EID component certificate. : CGA1. Authentication cryptogram containing the eID public key,

PK.elD.AUT.

PK.elD.AUT: public key of eID, associated with the component certificate C.elD.AUT.

In [M3]: : CGA2. Authentication cryptogram containing the key K _S A-

Clave de sesión K_s« calculada a partir de K_SA y Kei_D : T. Authentication Challenge generated by SA.

Session key K _s «calculated from K _S A and Kei _D

In [M4]:: C.X509.U_AUT. User authentication certificate U.

: DS [T] - Signature (encryption) of challenge T with SK.U.AUT.

SK. U AUT: private key associated with the U authentication certificate (C.X509.U_AUT) for the signature (encryption) of challenge T.

Likewise, the terms used in Figure 6 (symmetric scheme) are briefly explained below:

KENC and K _MA c: are shared secret keys for encryption and decryption in MAC functions, respectively (previously established).

In the [MO] message:

: SN.eID || RND.elD. Serial number and random value provided by eID.

K _SA : 32-byte key generated here as a random number.

In [M1]:

: CGA3. Authentication cryptogram protected with K _E NC and KMAC, transports

Kei _D : 32-byte key generated here as a random number.

K _s «: 32-byte key generated as KSK ⁼ KSAW

SSC eiD: counter of the sequence in sending from eID

In [M2]:

: CGA4. Authentication cryptogram protected with K _E NC and K _M AC, transports

SSCSA: counter of the sequence in the shipment from SA. In [M3]:

: T. Authentication challenge generated by SA. In [M4]:: C.X509.U_AUT. User authentication certificate U.

: DS [T]. Signature (encryption) of challenge T with SK.U.AUT.

SK.U.AUT: private key associated with the U authentication certificate (C.X509.U_AUT) for the signature (encryption) of challenge T.

This invention provides for the encapsulation in protocol B of the messages authentication required for the establishment of this tunnel, and in correspondence with protocols A and C.

2 ^a ) Then, in a second phase, the identification of the user is carried out by means of the authentication of his identity credential based on X.509v3 certificates and through the previous tunnel.

Protocol B must allow a new encapsulation of the messages involved in this second phase, to authenticate the user through their digital certificate.

That is, the present invention considers a remote authentication architecture with the ID-NSCard smart card as the central element, which supplements the deficiencies described in the background, with the following characteristics:

It is an autonomous smart card in the authentication process, which implies:

- The smart card acts as an independent authentication (S) requestor, compared to the current version of split-supplicant.

- The smart card incorporates the authentication protocol and mechanisms atomic form, and therefore, the design of said protocol must be done in an integral way for said device.

The access point of the ID-NSCard smart card adopts the authenticator (A) functionality, separating itself from the authentication and authorization functionalities of the remote authentication server (SA), by means of the implementation of a stack of standardized protocols that make it a network access server. Under this condition, the independence of the smart card - and its associated identity credentials - is guaranteed at the same time in the process, while this access point or Terminal is involved in the authentication scheme, thus minimizing the risks of a A priori terminal unreliable.

End-to-end mutual authentication scheme, in which the smart card participates as one of those ends in front of a remote authentication server, for purposes of identifying users.

* Authentication scheme in layer 2 (or link layer according to the OSI reference model): the integration of the smart card on the basis of a remote authentication in layer 2 implies a new approach to network smart cards (network smart cards ), without the need to implement protocols of upper layers and with the consequent lightening of the computational load, of memory resources and bandwidth, which positively results in the speed and efficiency with which user identification operations are carried out «Using protocols of standardized network environments It allows interoperability and flexibility that is required in this context, which enhances the functionalities of identity management systems.

The invention has been described according to a preferred embodiment thereof, but it will be clear to the person skilled in the art that other variations can be introduced without exceeding the object of the claimed invention.

Claims

1. Remote authentication system of an identity of a user, comprising: - a smart card (10) that provides a certificate of authentication of said user (CX509.U_AUT), an access point (20) or Terminal for said card smart, a remote authentication server (30) to authenticate said smart card, characterized in that: said smart card (10) is configured as an independent authentication requestor and to respond to a network protocol stack on which a mechanism is implemented remote authentication controlled by said smart card; and because - said access point is configured as a network access server and to act as an authentication intermediary (A) between the smart card and the remote authentication server; and because in response to a mutual and remote authentication between said remote authentication server and smart card, an end-to-end secure channel (40) is established by means of a session key (K _sκ , K _{SA / ΘID} ) and defined between said smart card and said remote authentication server, and through said secure channel defined between remote authentication server and smart card, an authentication of the identity of the user is executed by said authentication certificate (CX.509.U_AUT). 2. System according to claim 1, wherein said remote and mutual authentication between the smart card and the remote authentication server is executed by asymmetric cryptography, based on a first and second component certificates (C. eID.AUT, C .CV.SA.AUT) associated with said smart card and said remote authentication server, respectively. 3. System according to claim 1, wherein said remote and mutual authentication between the smart card and the remote authentication server is executed by symmetric cryptography, based on a first and second key shared secrets associated with said smart card and said remote authentication server, respectively. 4. System according to any of claims 1-3, which further includes a mutual network authentication between the access point (20) and the remote authentication server (30). 5. System according to any of claims 1-4, which also includes establishing a session key, different from the session key for the secure channel defined between smart card and remote authentication server, to encrypt traffic between the smart card and the access point 6. System according to any of claims 1-4, which also includes establishing a type of mechanism to access and use a private key associated with the user authentication certificate, stored in the smart card. 7. System according to claim 6, wherein said mechanism is based on biometric techniques. 8. System according to claim 6, wherein said mechanism is based on verification techniques of a user PIN. 9. System according to any of claims 1-8, wherein said user authentication certificate has established a corporate employment domain, said user being a member of a company. 10. System according to any of claims 1-8, wherein said user authentication certificate has established a government employment domain, said user being a citizen.