Patent Description:
Furthermore, the invention also pertains to an authentication device.

The authentication device includes a Hardware Security Module (or HSM) type device, as a first device.

Moreover, the invention concerns a chip for authenticating to a (first) device.

The present invention is notably applicable to a chip that is included in a Secure Element (or SE), as a second device.

Within the present description, an SE is a smart object that includes a chip(s) that protect(s), as a tamper resistant component(s), access to stored data and that is intended to communicate data with an external device(s), like e.g., an SE host device, such as a mobile (tele)phone or a Personal Computer (or PC).

Finally, the invention covers an authentication system. The authentication system includes one or several devices and one or several chips.

As known per se, an HSM generates a credential for a given user role that the HSM manages. The HSM sends the credential to a chip card, as an SE. The chip card is used by a user. The chip encrypts the credential and registers the encrypted credential. Thus, the HSM registers the chip for the concerned user role. To authenticate, the HSM requests, from the registered chip, a credential. The chip decrypts the registered encrypted credential. Then, the chip sends the credential to the HSM. The HSM does or does not authenticate, based on the received credential, the chip.

However, when a user who owns a plurality of roles, such an authentication process becomes a cumbersome and tedious operation for the user to switch from a role to (an)other role(s) by swapping possibly from a chip to (an)other chip(s).

Document <CIT> describes a server for authenticating a smart chip, which is connected to a terminal transmitting and receiving data to and from the smart chip through a network. The server includes a server transceiving unit that receives a card identifier identifying a user from the terminal; and an authentication unit that generates an authentication key from the card identifier and authenticating the smart chip from the authentication key, in which the smart chip receives the encrypted text to generate the decrypted text from a private key, and the card identifier is a public key corresponding to the private key.

Document <CIT> describes a method for provisioning payment credentials usable by a mobile device in conducting a payment. The method is conducted at a provisioning system and comprises the steps of: receiving payment credentials from a receiving device, the payment credentials having been obtained from a portable payment device presented by a consumer at the receiving device; receiving, from the receiving device, an identifier entered by the consumer; identifying a mobile device or a secure element corresponding to the identifier; and communicating the payment credentials or a derivation of the payment credentials to the identified mobile device or the secure element to be securely stored in association with the mobile device.

Document <CIT> describes a system for performing client-server authentication using a device authentication and optional user authentication approach. In a device authentication stage, the client is unlocked to provide access to a cryptographic key used for authentication. In a user authentication stage, the user provides a personal data credential used to generate an additional cryptographic key.

There is a need of an alternative solution that allows authenticating, in a more secure manner, a chip.

The invention proposes a solution for satisfying the just herein above specified need by providing a method for authenticating to a device.

According to the invention, the method comprises:.

The principle of the invention consists in identifying, by a device, based on data received from a chip, an associated encrypted credential. Then, the device requests the chip to decrypt the encrypted credential while sending, to the chip, the encrypted credential to be decrypted. The chip gets a secret (cryptographic) key and decrypts the (received) encrypted credential by using the secret key. The chip sends the (resulting) credential in plain text (i.e. in a non-encrypted manner) to the (requesting) device. The device checks whether the (received) credential is (or not) a right one. In the positive case, the device authenticates successfully the chip.

Thus, the device accesses the encrypted credential in association with data that depends on data to be received from an associated chip to be authenticated.

The data that the device receives from a chip allows an association, at the device side, between the chip and the encrypted credential to be decrypted and sent to the chip. The data to be received from a chip plays therefore a role of a correlation IDentifier (or ID). Such data may include an ID(s) relating to the chip, a unique ID, such as a Unique Universal ID (or UUID), a (digital) token and/or any data that has been directly or indirectly registered to identify the associated encrypted credential to be used for authenticating the associated chip.

It is to be noted that the chip to be authenticated only stores the secret key, as sensitive data. The chip stores neither any credential nor any encrypted credential, as sensitive data. The chip memory footprint is therefore limited, minimum and efficient at the chip side.

The chip has just to carry out an on-the-fly decryption of the encrypted credential received from a requester, and a transmission of the (resulting) credential to the requester, in order to authenticate to the device.

A single chip may have an unlimited number of requesters, i.e. devices, which request individually to authenticate to the concerned requester by having simply to decrypt received encrypted credential by using the registered secret key and send back the (resulting) credential.

It is noteworthy that the chip does not need to know neither the requester, i.e. from whom the chip has to receive data and to whom the chip has to transmit data, nor the credential (i.e. its content value), i.e. what to decrypt, to authenticate to the device.

The invention solution is simple at a chip side, since a chip that registers merely a secret key has to decrypt data to be received by using the secret key and has to send back the (resulting) decrypted data to authenticate to a requesting device.

The invention solution is simple at a device side, since a device that registers merely an encrypted credential in association with data depending on data to be received from an identified chip has to send, to the chip, a corresponding decryption request with the encrypted credential and has to receive the corresponding credential to authenticate the chip.

The invention solution is efficient at a chip side, as the chip registers only the secret key and is able to authenticate to one or several devices without having much data to register.

The invention solution is also efficient at a device side, as the device registers only an encrypted credential in association with data allowing to retrieve the encrypted credential and the associated chip to authenticate.

The invention solution is secure at a chip side, as the chip keeps secret the secret key by not sending the secret key to any external device.

The invention solution is secure at a device side, as the device does not know any secret key to be used by a chip to authenticate and the device therefore has to involve each concerned chip to authenticate by using the secret key that is stored only by the chip.

According to an additional aspect, the invention is an authentication device. According to the invention, the authentication device is configured to:.

According to a further aspect, the invention is a chip for authenticating to a device.

According to the invention, the chip is configured to:.

According to still a further aspect, the invention is an authentication system.

According to the invention, the system includes at least one device and at least one chip. The at least one device includes the authentication device as previously defined and the at least one chip includes the chip as previously defined.

When the invention solution is used in the context of the aforementioned prior art system solution in which a device(s) is(are) constituted by an HSM(s) and a chip(s) is(are) constituted by an SE chip(s), a chip authentication is easier, more traceable and more scalable by limiting the number of chips that are needed for the chip authentication with respect to the prior art solution. For instance, a single SE chip may be associated with an unlimited number of user roles with one or several HSMs.

The invention system may include a Terminal Equipment (or TE) including a (mobile) phone and one or several chips. The phone includes the above defined authentication device and the chips include the above defined chip for authenticating to the authentication device.

Additional features and advantages of the invention will be apparent from a detailed description of one preferred embodiment of the invention, given as an indicative and non-limitative example, in conjunction with the following drawings:.

Herein under is considered a case in which the invention method for authenticating to a device is implemented by, locally at a server side, an HSM, as a standalone and authentication device, and an SE chip, as a device to be authenticated. The authentication device does not need to cooperate with another device, at the server side, like e.g., an SE, so as to carry out the functions that are described infra and that are carried out by the HSM.

According to another embodiment (not represented), the invention method for authenticating to a device is implemented by a PC, as a first and an SE host device, and an SE chip, as a second device. According to such an embodiment, the PC cooperates with a Trusted Executed Environment (or TEE) that is adapted to carry out the functions that are carried out by the HSM and that are described infra by adding a secure execution environment in the TEE.

According to another embodiment (not represented), the invention method for authenticating to a device is implemented by a (mobile) phone, as a first and an SE host device, and a first SE chip, as a second device. According to such an embodiment, the phone cooperates with a second SE chip that is adapted to carry out the functions that are carried out by the HSM and that are described infra by adding, in the second SE chip, a secure data storage and a secure data processing. The first and/or the second SE chip may include an incorporated chip, like e.g., an embedded Universal Integrated Circuit Card (or eUICC) or an integrated Universal Integrated Circuit Card (or iUICC), in a terminal, as an SE host device, or a chip that is communicatively coupled to the terminal, as an SE host device, and included in a smart card (or another medium). The first and/or the second SE chip may be fixed to or removable from its host device. As removable SE, it may be a Subscriber Identity Module (or SIM) type card, a Secure Removable Module (or SRM), a smart dongle of the USB (acronym for "Universal Serial Bus") type, a (micro-) Secure Digital (or SD) type card or a Multi-Media type Card (or MMC) or any format card to be coupled to a host device. The second SE chip may include a TEE.

The invention does not impose any constraint as to a kind of the SE type.

Naturally, the herein below described embodiment is only for exemplifying purposes and is not considered to reduce the scope of the invention.

<FIG> shows schematically an authentication system <NUM> including e.g., an HSM <NUM>, as an authentication device, and e.g., a chip <NUM> to be authenticated to the HSM <NUM>.

Instead of an HSM, the authentication device may include a user terminal, a PC, a desktop computer, a mobile phone, a tablet, a laptop computer, a media-player, a game console, a netbook, a smart watch, a smart jewel (or jewelry), a handset, a Personal Digital Assistance (or PDA) and/or any stationary or mobile (electronic) device. The authentication device may be any other computing device including means for processing data, comprising or being connected to communication means for exchanging data with outside, and comprising or being connected to means for storing data.

The HSM <NUM> includes one or several (micro)processors (and/or a (micro)controller(s)) <NUM>, as data processing means, comprising and/or being connected to one or several memories <NUM>, as data storing means, comprising or being connected to means for interfacing with a user <NUM>, such as a Man Machine Interface (or MMI), and comprising or being connected to an Input/Output (or I/O) interface(s) <NUM> that are internally all connected, through an internal bidirectional data bus <NUM>.

The I/O interface(s) <NUM> may include a wired and/or a wireless interface, to exchange, over a contact and/or ContacT-Less (or CTL) link(s) <NUM>, with the chip <NUM>.

Within the present description, the adjective "CTL" denotes notably that the communication means communicates via one or several Short Range (or SR) type RadioFrequency (or RF) links.

The SR type RF link(s) may be related to any CTL technology that allows the HSM <NUM> to exchange locally data, through a CTL type link(s) <NUM>, with the chip <NUM>.

The CTL link(s) <NUM>, when present, may include a BluetooTH (or BTH), a Bluetooth Low Energy (or BLE), a Wi-Fi, a ZigBee, a Near Field Communication (or NFC) type link(s) and/or any other SR type RF communication technology link(s).

Alternatively, instead of a CTL link(s), or additionally, the HSM <NUM> is connected, through a wire(s) or a cable(s) (not represented), to the chip <NUM>.

The HSM <NUM> MMI may include a display screen(s) (not represented), a keyboard(s) (not represented), a loudspeaker(s) (not represented) and/or a camera(s) (not represented).

The HSM <NUM> MMI allows the user <NUM> to interact with the HSM <NUM>.

The HSM <NUM> MMI may be used for getting data entered and/or provided by the user <NUM>, such as user authentication data, like e.g., a PIN and/or user biometric data (like e.g., a fingerprint(s), a facial print(s) and/or an iris print(s)).

The HSM memory(ies) <NUM> may include one or several volatile memories and/or one or several non-volatile memories.

The HSM memory(ies) <NUM> may store a first and/or a last name(s) relating to the user <NUM>, as a user ID(s)), an International Mobile Equipment Identity (or IMEI), a Mobile Subscriber Integrated Services Digital Network number (or MSISDN), an Internet Protocol (or IP) address, an International Mobile Subscriber Identity (or IMSI), a Media Access Control (or MAC) address, an email address(es) and/or the like, as an ID(s) relating to each chip (or device) to be authenticated.

The HSM memory(ies) <NUM> chip ID(s) may store data, such as an ID(s) relating to the HSM <NUM>, that allows identifying uniquely and addressing the HSM <NUM>. The HSM ID(s) may include a unique ID <NUM>, such as a UUID <NUM>, a Uniform Resource Locator (or URL) <NUM>, a Uniform Resource ID (or URI) <NUM>, and/or other data that allows identifying uniquely and addressing the HSM <NUM>.

The HSM memory(ies) <NUM> stores, for each chip to be authenticated possibly for a specific user role, preferably a UID, a token and/or data that depends on data to be received from a (thus identified) chip in association with a predefined encrypted credential and associated (resource access) rights (or permission(s)). The encrypted credential is preferably loaded during a phase of registering (or enrolling) a chip (or a device) to be authenticated.

A user role(s) may include, as different specific user role(s), e.g., a (key) ceremony administrator, a system administrator, a witness, a cryptographic officer and/or (an)other specific role(s) which may depend on the concerned ceremony or act or the like.

The rights allows defining one or several resources which the user <NUM>, possibly for the specific (user) role, has, when successfully authenticated, access to.

The concerned resource(s), as protected data, may include (non-executable) data, such as one or several data files or private data, and/or executable data, such as one or several application programs (i.e. code(s)) that, once executed, allow providing a corresponding service(s). The HSM <NUM> allows managing a storage of encrypted credential, as encrypted reference authentication data, per chip (or device), possibly per user role, and per (thus protected) resource.

When a user role is to be authenticated, a corresponding user role authentication is carried out by using an associated (user) chip (or device) that has to provide an associated credential, as authentication data, to submit to the HSM <NUM>, so as to be successfully authenticated.

During a registration phase, the HSM <NUM> registers, i.e. stores or lets a cooperating device (not represented) that is connected or coupled to the HSM <NUM> store, for each chip to be authenticated within a chip (or device) set, specific data in association with an encrypted credential and one or several IDs relating to the chip (or device) to authenticate. The specific data depends on data to be received, from a chip (or device) to be authenticated, so that the HSM <NUM> retrieves the registered encrypted credential to be decrypted by the concerned chip (or device) to authenticate.

Alternately, an SE chip (not represented) that is connected or communicatively coupled to the HSM <NUM> stores at least a part of data registered for each chip to be authenticated, such as a chip ID(s) allowing the HSM <NUM> to identify an associated encrypted credential to be sent to the identified chip.

To register each chip (or device) to be authenticated at the HSM <NUM> side, the HSM <NUM> generates (or lets another cooperating device connected or coupled hereto generate) a credential. The HSM <NUM> and its interlocutor use preferably a secure channel, such as e.g., a HyperText Transfer Protocol Secure (or HTTPS) type channel or any other secure data communication channel, in order to securely exchange data. Once the HSM <NUM> has generated the credential, the HSM <NUM> sends (or lets another cooperating device connected or coupled hereto send) the credential to the concerned chip (or device). The chip (or device) encrypts the (received) credential by using a secret key (or SK) that is stored only by the chip (or device). Once encrypted, the chip (or device) sends the encrypted credential to the HSM <NUM>. The HSM <NUM> stores (or lets another cooperating device connected or coupled hereto store) the (received) encrypted credential in association with chip (or device) data, such as a UID, and associated rights. Once the encrypted credential is registered, the HSM <NUM> deletes (or lets another cooperating device connected or coupled hereto delete) the corresponding (generated) credential, in order to not expose the credential and keep the credential confidential.

To authenticate an interlocutor, the HSM <NUM> (or a second cooperating chip) is arranged to receive, from a chip (or device), like e.g., the chip <NUM>, as an HSM interlocutor, data, as an authentication request, such as a UID.

The HSM <NUM> is adapted to get, based on the data received from the chip (or device), a corresponding (registered) encrypted credential. The data received from the chip (or device) may be registered, either as such, or, after a data processing(s), such as e.g., a decryption of the data received from the chip (or device), in association with a corresponding encrypted credential. The encrypted credential may be registered in association with one or several IDs relating, each, to a user role. The encrypted credential is registered in association with one or several IDs relating to the chip (or device) to be identified and authenticated. The chip ID(s) allows identifying uniquely and addressing the chip (or device) to be authenticated. The chip ID(s) may include a unique ID <NUM>, such as a UUID <NUM>, a URL <NUM>, a URI <NUM> and/or other data that allows identifying uniquely and addressing the chip (or device) to be authenticated.

The HSM <NUM> is configured to send, to the chip (or device), a decryption request along with the corresponding (registered) encrypted credential.

The HSM <NUM> is arranged to receive, from the chip (or device), the credential, as a decryption request response, as a result of a decryption of the (sent) encrypted credential.

According to an essential invention feature, the HSM <NUM> is adapted to verify, whether the (received) credential is or is not valid.

If the credential is not valid, then the HSM <NUM> fails to authenticate the chip (or device).

Otherwise, i.e. if the credential is valid, the HSM <NUM> authenticates successfully the chip (or device).

To ascertain that the credential is valid, the HSM <NUM> is arranged to get or retrieve a (previously stored) encrypted key (or Kenc). The HSM <NUM> is configured to decrypt successfully the (retrieved) Kenc by using the (received) credential. The key (or K) in plain text, i.e. a non-encrypted key, has been used for encrypting one or several resources that are authorized to be accessed. The resource(s) belong(s) to either a chip user who is authorized to access the concerned resource(s) or a role which a chip user has and authorizes to access the concerned resource(s). Only when the credential is successfully validated or authenticated by the HSM <NUM>, the HSM <NUM> decrypts the encrypted resource(s) by using K, as a decrypted Kenc, in order to access the concerned resource(s).

The HSM <NUM> carries out preferably one or several security functions.

The security function(s) include(s) preferably a credential deletion (or erasure) operation that is executed, once the HSM <NUM> has or has not validated the received credential. Such an HSM credential deletion operation allows reducing the risk that a hacker or a malicious software retrieves the credential. The HSM credential deletion operation therefore increases the protection of the concerned credential.

The security function(s) include(s) preferably a data encryption process, by using, as a sender of data, such as e.g., the encrypted credential, a public key relating to a chip (or device) to be authenticated, as an HSM interlocutor, so as to generate encrypted data, prior to its sending, in a protected manner, to the HSM interlocutor.

The security function(s) include(s) preferably a data decryption process by using a private key related to the HSM <NUM>, so as to decrypt data that is received in an encrypted manner, after its receipt from the HSM interlocutor.

The chip <NUM> includes one or several (micro)processors (and/or a (micro)controller(s)) <NUM>, as data processing means, comprising and/or being connected to one or several memories <NUM>, as data storing means, comprising or being connected to means for interfacing with a user <NUM>, such as an MMI, and comprising or being connected to an I/O interface(s) <NUM> that are internally all connected, through an internal bidirectional data bus <NUM>.

The I/O interface(s) <NUM> may include a wired and/or a wireless interface, to exchange, over a contact and/or CTL link(s) <NUM>, with the HSM <NUM>, as the chip <NUM> interlocutor.

During a registration phase, the chip <NUM> registers a Secret Key (or SK). To register the SK, once the chip <NUM> has registered preferably reference user authentication data, the chip <NUM> generates preferably the SK, e.g. when the chip <NUM> is powered for the first time, i.e. the chip <NUM> is initialized, by using e.g., a RaNDom (or RND), as a seed, and a predetermined and stored key generation algorithm that uses the seed, as input data.

According to an essential invention feature, the chip (or a chip or a device cooperating with the chip <NUM>) memory(ies) <NUM>, such as a non-volatile memory, store(s) the SK. The SK is preferably kept secret and is stored only within the chip <NUM>, i.e. is not exposed to outside and is not shared with any other device. The SK is therefore kept internally and is not intended to be sent to any external device. The SK is used for encrypting data to be received from outside and decrypting data to be received from outside.

The chip (or a chip or an SE cooperating with the chip <NUM>) memory(ies) <NUM> store(s) preferably, in a secure manner, reference user authentication data, such as a reference Personal Identity Number (or PIN) and/or a reference biometric print(s) (like e.g., a reference fingerprint(s), a reference facial print(s) and/or a reference iris print(s)). The reference user authentication data allows authenticating the user <NUM>.

The chip memory(ies) <NUM> stores an Operating System (or OS) and an application for authenticating to an authentication device, like e.g., the HSM <NUM> and/or other HSM(s).

To authenticate the user <NUM>, the chip <NUM> is able to request (or let the authentication device request) the user <NUM> to provide user authentication credentials. The chip <NUM> is able to receive provided user authentication credentials and compare the provided user authentication credentials to a predetermined (i.e. the registered) reference user authentication credentials. If the provided user authentication credentials does not match the reference user authentication credentials, then the chip <NUM> fails to authenticate the user <NUM>. Otherwise, i.e. if the provided user authentication credentials matches the reference user authentication credentials, the chip <NUM> succeeds in authenticating the user <NUM>, i.e. the chip <NUM> ascertains that the provided user authentication credentials matches the reference user authentication credentials.

The chip <NUM> (or the cooperating chip or SE) memory(ies) store(s) preferably one or several IDs relating to the chip <NUM>. The chip ID(s) may include a unique ID <NUM>, such as a UUID <NUM>, a URL <NUM>, a URI <NUM> and/or other data that allows identifying uniquely and addressing the chip <NUM>.

The chip <NUM> may be incorporated or included, possibly in a removable manner, in a Printed Circuit Board (or PCB) of the HSM <NUM>, as a chip host device.

The chip <NUM> may also incorporate at least part of the host component(s), like e.g., a baseband processor, an application processor(s) and/or other electronic component(s).

In a particular embodiment, the chip <NUM> includes a TEE, as a secure area of a host device processor and a secured runtime environment.

Alternately, the chip <NUM> may be included in or removable from an SE (not represented). The SE is used by or belong(s) to the user <NUM>, possibly as a user who owns one or several roles. The SE includes one or several chips.

The chip medium may include, instead of the HSM <NUM>, a watch, a headset or the like, as an accessory of the HSM <NUM> that is able to exchange with the HSM <NUM>. The chip medium may include any other wearable device, like e.g., a camera, a clothing, a jewel (or jewelry), a phone of the user <NUM> or any (electronic) device that may accommodate or integrate the SE chip, which the user <NUM> wears or accesses.

To authenticate to an authentication device, such as an HSM, the chip <NUM> is arranged to send, to an interlocutor, data, like e.g., a UID, that allows the chip <NUM> interlocutor to uniquely identify the chip <NUM>.

The chip <NUM> is adapted to receive, from its interlocutor, a decryption request for decrypting an encrypted credential that includes or is accompanied with an encrypted credential to be decrypted.

The chip <NUM> is arranged to get or retrieve the (registered) SK.

According to an essential invention feature, the chip <NUM> is configured to decrypt the (received) encrypted credential by using the (retrieved) SK. Once the chip <NUM> has carried out such a decryption operation, the chip <NUM> gets the credential, as a result of the decrypted encrypted credential.

The chip <NUM> is adapted to send, to its interlocutor, as a decryption request response, the credential.

The chip <NUM> carries out preferably one or several security functions.

The security function(s) include(s) preferably a credential deletion (or erasure) operation that is executed, once the chip <NUM> has sent the result of the decryption operation. Such a chip credential deletion operation allows reducing the risk that a hacker or a malicious software retrieves the credential. The chip credential deletion operation therefore increases the protection of the concerned credential.

The security function(s) include(s) preferably a data decryption process by using a private key related to the chip <NUM>, so as to decrypt data that is received in an encrypted manner, after its receipt from the chip <NUM> interlocutor.

The security function(s) include(s) preferably a data encryption process by using a public key relating to the interlocutor, as a sender of data, such as e.g., the credential, so as to generate encrypted data, prior to its sending, in a protected manner, to the chip <NUM> interlocutor.

<FIG> depicts an exemplary embodiment of a message flow <NUM> that involves the user <NUM>, the HSM <NUM>, as an authentication device, and the chip <NUM>, as a device to be locally authenticated before (or to) the HSM <NUM>.

Alternately, i.e. instead of being locally situated, the chip to be authenticated is remotely located and accessible from the authentication device, possibly through a network(s), such as Internet, and possibly a chip host computing device, like e.g., a PC.

In the described example, it is assumed that the user <NUM> has launched a (web) browser supported by the HSM <NUM>, in order to access one or several resources.

It is further assumed that the user <NUM> is registered, at the HSM <NUM> side, with an ID(s) relating to her/his chip <NUM>, in a corresponding chip account among a set of chip accounts.

In a preferred embodiment, the HSM <NUM> is the sole server to know the chip account set and to authenticate any thus registered chip, as an HSM interlocutor.

According to another embodiment, alternatively, i.e. instead of a single server, two or more servers (not represented) are used.

Optionally, the chip <NUM> requests (not represented), preferably through the HSM <NUM> browser, the user <NUM> to provide user authentication credentials. The user <NUM> provides <NUM> a PIN and/or user biometric data (such as a fingerprint(s), a facial print(s) and/or an iris print(s)) and/or the like), as user authentication credentials. The HSM <NUM> forwards <NUM> to the chip <NUM> the provided user authentication credentials. The chip <NUM> verifies <NUM> whether the user <NUM> is or is not authenticated.

To verify whether the user <NUM> is or is not authenticated, the chip <NUM> compares the provided user authentication credentials to the (registered) reference user authentication credentials. If the provided user authentication credentials does not match the reference user authentication credentials, then the chip <NUM> terminates <NUM> the launched chip <NUM> authentication process. Otherwise, i.e. if the provided user authentication credentials matches the reference user authentication credentials, the chip authenticates successfully the user <NUM>. Once the chip <NUM> has successfully authenticated the user <NUM>, the chip <NUM> sends <NUM> to the HSM <NUM> a message, such as "the user authentication credentials is validated" including a user authentication result that proves that the chip <NUM> has successfully authenticated the user <NUM>. Such a successful user authentication, when present, allows unlocking the chip <NUM> and thus accessing the data stored in the chip <NUM>.

It is still further assumed that the chip <NUM> has preferably established, further to a preferable successful user authentication, a secure communication with the HSM <NUM>, to exchange data in a secure manner, by using e.g., a Public Key Cryptographic Standard (or PKCS). Once the secure communication is established, all of the data exchanges between the chip <NUM> and the HSM <NUM> is encrypted prior to its sending. The encrypted data sent by the chip <NUM> or the HSM <NUM> has to be decrypted by the HSM <NUM> or the chip <NUM> that receives the thus encrypted data respectively.

In a preferred embodiment (but not mandatorily), the HSM <NUM> requests <NUM> the chip <NUM> to receive data allowing to uniquely identify the chip <NUM>.

The chip <NUM> does not need to know the HSM <NUM>, as a chip interlocutor, prior to receiving data originating from the HSM <NUM>.

The chip <NUM> gets or retrieves <NUM> e.g., a unique serial number, such as a UID, as data allowing to uniquely identify to the HSM <NUM> or any other interlocutor(s).

Then, the chip <NUM> sends <NUM> to the HSM <NUM> the UID, as the retrieved data allowing to uniquely identify the chip <NUM>.

The HSM <NUM> gets or retrieves <NUM>, based on the UID received from the chip <NUM>, the (registered) encrypted credential.

Once the HSM <NUM> has retrieved the encrypted credential, the HSM <NUM> sends <NUM> to the chip <NUM> a decryption request for decrypting the encrypted credential. The decryption request includes or is accompanied with the encrypted credential.

The chip <NUM> does not need to know neither about the ID of the sender of the encrypted credential nor the encrypted credential per se.

Once the chip <NUM> has received the encrypted credential that the chip <NUM> sees preferably as a blob of data, the chip <NUM> gets or retrieves <NUM> the (stored) SK. The SK has been preferably on-board generated, i.e. within the chip <NUM>. The SK never leaves the chip <NUM>, to be kept secret.

Once the chip <NUM> has retrieved the secret key, the chip <NUM> decrypts <NUM> (on-the-fly) the (received) encrypted credential by using the secret key.

Then, once the chip <NUM> has got a result of a decryption of the encrypted credential, the chip <NUM> sends <NUM> to the HSM <NUM> the decryption resulting data, as decrypted encrypted credential, i.e. the credential in plain text. Prior to sending the credential, the chip <NUM> may concatenate to the credential, user information, such as e.g., the user <NUM> first name and the user <NUM> last name, that is preferably stored in the chip <NUM>. Once the chip <NUM> has sent the credential possibly with the user information, the chip <NUM> deletes (not represented) preferably the resulting credential.

The HSM <NUM> verifies <NUM> whether the (received) credential is or is not valid.

To verify whether the credential is or is not valid, the HSM <NUM> uses (not represented) the (received) credential. More exactly, the HSM <NUM> gets or retrieves the (stored) Kenc. The HSM <NUM> decrypts the (retrieved) Kenc by using the (received) credential. The K, as the non-encrypted Kenc, has been used for encrypting one or several resources that are authorized to be accessed. The resource(s) belong(s) to either a chip user who is authorized to access or a role that a chip user who is authorized to access. The HSM <NUM> decrypts the encrypted resource(s) by using the (resulting) K, as a decrypted Kenc, in order to access the resource(s).

If the HSM <NUM> does not succeed in decrypting the encrypted resource(s) by using the (resulting) K, then the HSM <NUM> ascertains that the (received) credential is not valid. In other words, the HSM <NUM> does not authenticate the credential. If the HSM <NUM> does not authenticate the credential, then the HSM <NUM> terminates <NUM> the launched chip <NUM> authentication process.

Otherwise, i.e. if the HSM <NUM> succeeds in decrypting the encrypted resource(s) by using the (resulting) K, the HSM <NUM> ascertains that the (received) credential is valid, i.e. if the HSM <NUM> authenticates the credential, the HSM <NUM> authenticates <NUM> successfully the chip <NUM> and therefore the user <NUM>, and possibly for his/her role, when applicable.

Once the HSM <NUM> has successfully authenticated the chip <NUM>, the HSM <NUM> may display (not represented), possibly through the HSM <NUM> browser, to the user <NUM> a message, such as "the credential is authenticated" including either a successful user authentication result or a successful user role authentication result that proves that the HSM <NUM> has successfully authenticated the chip <NUM>. Such a successful chip authentication allows the HSM <NUM> to authorize the chip <NUM> to gain access to one or several requested (registered) resources that have been successfully decrypted by using the received credential.

Once the HSM <NUM> has either succeeded in authenticating the credential or failed to authenticate the credential, the HSM <NUM> deletes (not represented) preferably the received credential.

When authenticated, the chip <NUM> is authorized to gain access to one or several associated resources.

The chip <NUM> does not need to store neither a credential nor an encrypted credential nor a user role ID, when applicable.

The invention solution allows each chip to be authenticated to store only its own secret key.

The invention solution allows authenticating, simply, securely and efficiently, a chip (or a device) that does not need to be provisioned with neither a credential nor an encrypted credential.

The invention solution allows a chip user to use a single chip to authenticate to one or several authentication devices, to switch from a role to another role without needing to swap from the chip to another chip, when applicable.

Claim 1:
A method (<NUM>) for authenticating to a device (<NUM>), comprising:
- receiving (<NUM>), by the device, from a chip (<NUM>), data;
- retrieving (<NUM>), by the device, based on the received data, a predetermined encrypted credential;
- sending (<NUM>), by the device, to the chip, a decryption request for decrypting the encrypted credential including or being accompanied with the encrypted credential to be decrypted;
- retrieving (<NUM>), by the chip, a secret key;
- decrypting (<NUM>), by the chip, the encrypted credential by using the secret key;
- sending (<NUM>), by the chip, to the device, as a decryption request response, the credential;
- verifying (<NUM>), by the device, whether the credential is or is not valid; and
- authenticating (<NUM>), by the device, only if the credential is valid, the chip. characterized in that, to ascertain that the credential is valid, the device decrypts successfully a predetermined encrypted key by using the credential, the key, as a decrypted encrypted key, being used for encrypting at least one resource that belongs to either a chip user who is authorized to access the at least one resource or a role which a chip user has and authorizes to access the at least one resource, the device decrypts at least one encrypted resource by using the key, in order to access the at least one resource.