METHOD FOR AUTHENTICATING AN END-USER ACCOUNT, METHOD FOR SINGLE AUTHENTICATING WITHIN A CLUSTER OF HSM, AND METHOD FOR IMPLEMENTING ACCESS CONTROL

Abstract

The present invention provides a method for authenticating an end-user account associated with at least one cryptographic key stored in the form of a PKA object within a HSM, wherein the method comprises the following steps: creating a PKA object comprising authentication data, PKA-based user object, this authentication data at least comprising the log-in credentials of the end-user account, receiving, by the HSM, log-in credentials of the end-user account for retrieving and instantiating the PKA-based user object at session level, and authenticating, by the HSM, the PKA-based user object using a PKCS #11.

Claims

1. A method for authenticating an end-user account associated with at least one cryptographic key stored in the form of a Per-Key Authorization, PKA, object within a Hardware Security Module, HSM, wherein the method comprises the following steps: creating a PKA object comprising authentication data, PKA-based user object, this authentication data at least comprising the log-in credentials of the end-user account, receiving, by the HSM, log-in credentials of the end-user account for retrieving and instantiating the PKA-based user object at session level, and authenticating, by the HSM, the PKA-based user object using a Public-Key Cryptographic Standard #11.

2. The method according to claim 1, wherein at least one cryptographic is created in an assigned association state with the end-user account, and/or at least one cryptographic key is created in unassigned association state with the end-user account being late assigned thereto.

3. The method according to claim 1, wherein the PKA-based user object or a modified form thereof is stored encrypted in a database outside of the HSM accessible via API, so that initiation of the associated end-user account retrieves this encrypted form from the database and inserts it into the HSM for its decryption and authentication based on requesting the log-in credentials.

4. The method according to claim 3, wherein the encryption and decryption of the PKA-based user object or a modified form thereof is performed by the HSM computing a first symmetric key.

5. The method according to claim 1, wherein the PKA-based user object is created by a Crypto Officer.

6. The method according to claim 1, wherein either a posterior setting in the log-in credentials of the end-user account or a log-out thereof revokes everything in cache of the HSM generated during the session about said PKA-based user object.

7. A method for a single authenticating an end-user account within a cluster of Hardware Security Modules, HSMs, connected to each other through a secure communication channel, wherein the end-user account is represented by a PKA-based user object, the method comprising the following steps: i. authenticating, by a first HSM of the cluster, the PKA-based user object by: creating a PKA object comprising authentication data, PKA-based user object, this authentication data at least comprising the log-in credentials of the end-user account, receiving, by the HSM, log-in credentials of the end-user account for retrieving and instantiating the PKA-based user object at session level, and authenticating, by the HSM, the PKA-based user object using a Public-Key Cryptographic Standard #11, ii. serializing, by the first HSM, the PKA-based user object with the authenticated state, iii. encrypting said serial, by the first HSM, with a symmetric key or a derived form thereof shared among the HSMs forming the cluster, iv. propagating, by the first HSM, this encrypted serial through the secure communication channel, v. receiving, by at least a second HSM of the cluster, this serial, vi. decrypting the serial, by at least the second HSM, with the symmetric key, vii. authenticating, by at least the second HSM, the PKA-based user object by: creating a PKA object comprising authentication data, PKA-based user object, this authentication data at least comprising the log-in credentials of the end-user account, receiving, by the HSM, log-in credentials of the end-user account for retrieving and instantiating the PKA-based user object at session level, and authenticating, by the HSM, the PKA-based user object using a Public-Key Cryptographic Standard #11.

8. The method according to claim 7, wherein the secure communication channel implements a cryptographic protocols of the type of a Transport Layer Security.

9. The method according to claim 7, wherein the first HSM of the cluster propagates the encrypted serial through the secure communication channel only to one or more HSMs storing at least one cryptographic key associated to the end-user account.

10. A method for implementing access control to at least one cryptographic key stored within a HSM by an end-user account, wherein the method comprises: a. creating a PKA-based user object by: a. creating a PKA object comprising authentication data, PKA-based user object, this authentication data at least comprising the log-in credentials of the end-user account, b. receiving, by the HSM, log-in credentials of the end-user account for retrieving and instantiating the PKA-based user object at session level, and c. authenticating, by the HSM, the PKA-based user object using a Public-Key Cryptographic Standard #11, b. wherein the PKA-based user object further comprising a dedicated symmetric key associated with the end-user account, c. creating at least one PKA object comprising the cryptographic key, PKA-based resource object, this PKA-based resource object being authenticable through an identifier encrypted with the symmetric key of the PKA-based user object, and d. setting up the access permissions for each PKA-based resource object by means of its attributes.

11. The method according to claim 10, wherein the PKA-based resource object comprises sensitive and non-sensitive attributes wherein, the non-sensitive attributes comprise the encrypted identifier, and the sensitive attributes comprise at least the cryptographic key.

12. The method according to claim 10, wherein the identifier is a random string.

13. The method according to claim 10, wherein the PKA-based resource is assigned to the PKA-based user by setting its read-only parenting attributes.

14. The method according to claim 13, wherein the permissions are set up for each PKA-based resource object by means of its supported functions of PKCS #11

15. The method according to claim 14, wherein the permissions are at least one of the following: allow encryption, allow decryption, allow wrap, allow unwrap, allow signing, allow verifying.

Description

DESCRIPTION OF THE DRAWINGS

[0087] These and other characteristics and advantages of the invention will become clearly understood in view of the detailed description of the invention which becomes apparent from a preferred embodiment of the invention, given just as an example and not being limited thereto, with reference to the drawings.

[0088] FIG. 1 This figure shows an embodiment of an HSM and a user.

[0089] FIG. 2 This figure shows a schematic diagram of an HSM storing a plurality of objects.

[0090] FIGS. 3a, 3b These figures show a schematic diagram of Per-Key Authentication-based Object, as well as a PKA-based user object according to the invention.

[0091] FIGS. 4a to 4c These figures show a schematic workflow of (a) a method to assign a PKA-base resource object to a PKA-based user object, (b) the resulting assignment, and (c) an authorization to use the PKA-base resource object.

[0092] FIGS. 5a, 5b These figures show (a) a schematic workflow for extracting the PKA-based object out of the HSM, and (b) a schematic single sign-on of an end-user account within a cluster of HSMs.

[0093] FIGS. 6a to 6c These figures show a detailed view of (a) an initial login for SSO, (b) a single logout via changed credential, and (c) a logout with continuous authentication.

[0094] FIG. 7 This figure shows a schematic diagram of an RBA framework according to the invention.

[0095] FIG. 8 This figure shows a detailed view of a session creation within a cluster of HSMs.

DETAILED DESCRIPTION OF THE INVENTION

[0096] As it will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a method or a system.

[0097] Herein below, it is considered a case in which the method according to the invention for authenticating an end-user account is implemented by, locally at a server side, an HSM, as a standalone and authentication device that does not need to cooperate with another device so as to carry out the functions that are described infra and that are carried out by the HSM.

[0098] According to another embodiment (not represented), the method for authenticating end-user account is implemented by a PC, as a Secure Element (SE) host device that 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.

[0099] According to another embodiment (not represented), the invention method for authenticating end-user account is implemented by a (mobile) phone as an SE host device that cooperates with a 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 this SE chip, a secure data storage and a secure data processing. This 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). In addition, this 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.

[0100] The invention does not impose any constraint as to a kind of the HSM type.

[0101] FIG. 1 depicts schematically an authentication system or device such as a conventional HSM 1 storing a plurality of objects 2′ to 2″″″. The HSM 1 is configured to receive, from a user 100 at least his/her login credentials for at least one of his/her end-user account(s) (A, B), verify them and let said user to access objects or resources within it.

[0102] The same user 100 may have one or several accounts (i.e., end-user accounts A, B), each with its own credentials. In order to avoid configuring the HSM to allow direct communication for each end-user account, an “agent 11” can be implemented. Throughout this document, an “agent 11” is a software entity that acts on the behalf of the running application to communicate with the HSM via PKCS #11 functions (e.g., typically through API calls). Thus, typically, it is featured by the personal device or terminal that the user 100 is using to interact the HSM 1 through the application.

[0103] As known, the figure of the agent 11 is a preferred feature but still optional as the user can always communicate with the HSM 1 through a dedicated interface of the HSM 1.

[0104] FIG. 1 also depicts an external database or storage means 10 where PKA-based objects or a modified form thereof can be stored encrypted in order to save HSM's memory resources and/or allow load-balancing features within a group of HSMs (so-called HSM cluster). Although only one is shown, more than one external databases 10 can be envisaged within this invention. This database is accessible by the agent 11 via, e.g., API.

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

[0106] The I/O interface(s) 1.3 may include a wired and/or a wireless interface, to exchange, over a contact and/or Contactless (or CTL) link(s), with the user 100. Within the present description, the adjective “CTL” denotes notably that the communication means communicates via one or several Short Range (or SR) type Radio Frequency (or RF) links.

[0107] The SR type RF link(s) may be related to any CTL technology that allows the HSM 1 to exchange locally data, through a CTL type link(s), with the user 100. The CTL link(s), 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).

[0108] Alternatively, instead of a CTL link(s), or additionally, the HSM 1 is connected, through a wire(s) or a cable(s) (not represented), to an end-user terminal or device (not represented) operated by the user 100.

[0109] The HSM MMI may include a display screen(s), a keyboard(s), a loudspeaker(s) and/or a camera(s) (not represented). The HSM MMI allows the user 100 to interact with the HSM 1. The HSM MMI may be used for getting data entered and/or provided by the user 100, such as user authentication data or login credentials, 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)).

[0110] The HSM memory(ies) 1.2 may include one or several volatile memories and/or one or several non-volatile memories. The HSM memory(ies) 1.2 may store e.g. a first and/or a last name(s) relating to the user 100, 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 I MSI), a Media Access Control (or MAC) address, an email address(es) and/or the like, as an ID(s) relating to each user (or device) to be authenticated.

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

[0112] The HSM memory(ies) 1.2 stores, for a specific user, preferably a UID, a token and/or authentication data 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 user 100 (or his/her device) to be authenticated.

[0113] 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).

[0114] When a user 100 is to be authenticated, a corresponding user authentication is carried out by submitting to the HSM 1 an associated credential, as authentication data so as to be successfully authenticated. This authentication may additionally need of a physical token belonging to the user.

[0115] During a registration phase, the HSM 1 registers, i.e. stores or lets a cooperating device (not represented) that is connected or coupled to the HSM 1 store, for each user or a device thereof, specific data in association with an encrypted credential and one or several IDs for authentication. The specific data depends on data to be received, from the auxiliary device to be authenticated, so that the HSM retrieves the registered encrypted credential to be decrypted by the concerned device to authenticate.

[0116] The HSM 1 is configured to send data to or receive data from its interlocutor using 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.

[0117] The HSM 1 is configured to verify, whether a (received) credential from the user is or is not valid. If the credential is not valid, then the HSM fails to authenticate the user or his/her device. Otherwise, i.e. if the credential is valid, the HSM authenticates successfully the user or device.

[0118] To ascertain that the credential is valid, the HSM is configured to retrieve a (previously stored) encrypted key (or Kenc). The HSM 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 stored in form of objects that are authorized to be accessed.

[0119] Only when the credential is successfully validated or authenticated by the HSM, the HSM decrypts the encrypted resource(s) by using K, as a decrypted Kenc, in order to access the concerned resource(s) or objects.

[0120] In FIG. 2, it is schematically depicted an HSM (1) storing a plurality of objects (2′ to 2″″″) of one or more classes: “data object” (2″), “certificate object” (2′″), or “key objects” such as “public key object” (2″″), “private key object” (2″″′), “symmetry key object” (2″″″).

[0121] In addition, objects comprises different attributes such as: “class”, “token”, “label”, “value”, “object ID”, or “serial number”. The functions or operations to be performed with a particular object can be: “encrypt”, “decrypt”, “sign”, “verify”, among others.

[0122] Therefore, conventionally, when the user is authenticated to the HSM, he/she has access to all objects within it. The access includes reading/writing the value of the attributes as well as perform all operations (e.g., signing).

[0123] FIG. 3a depicts a schematic diagram of Per-Key Authentication or Authorization (PKA)-based object 5 used in the present invention. As it can be seen, PKA feature adds an additional attribute 5.1 regarding the authentication data 5.1.1 that must be introduced by the key owner before being able to use the cryptographic material. That is, it is not enough to log-in into the HSM but each time the user 100 wants to use the key, the user requires additional authorization (through API) in order to perform operations 5.2 on the key object. Advantageously, it provides access control on the operations as per object.

[0124] FIG. 3b depicts PKA-based user object 6 created according to the invention. As seen, the PKA-based user object is of the class of a symmetry key (S-Key) object and represents an end-user or end-user account by registering his/her login credentials within the attributes.

[0125] The log-in credentials are a credential, user ID, password, PIN and/or user biometric data.

[0126] Accordingly, creating or registering an end-user within the HSM 1 is similar to the creation of PKA key object with the exception that authenticating the end-user is now performed by authenticating the PKA-based user object with his/her log-in credentials. From the HSM point of view, the authentication workflow does not deviate from the standard PKCS #11 flow.

[0127] Therefore, the invention provides a method for authenticating an end-user account associated with at least one cryptographic key 7, 8 stored in the form of a PKA object within a HSM, wherein the method comprises the following steps: [0128] creating a PKA object comprising authentication data, PKA-based user object 6, this authentication data at least comprising the log-in credentials of the end-user account, [0129] receiving, by the HSM, log-in credentials of the end-user account for retrieving and instantiating the PKA-based user object at session level, and [0130] authenticating, by the HSM, the PKA-based user object using a Public-Key Cryptographic Standard #11.

[0131] The symmetry key S-Key of the PKA-based user object is used to link or associate cryptographically the resources or keys within the HSM or cluster of HSMs usable by that end-user account.

[0132] Moreover, a better track of the usage of this PKA-based user object can be assured since its instantiation by the HSM set its attributes to reflect this session initiation.

[0133] Thus, the end-user 100 opens a session in the service and logins in the HSM 1. The application or API, through PKCS #11, retrieves this PKA-based user object enforcing its authentication through the HSM thanks to the log-in credentials.

[0134] FIG. 4a depicts a schematic workflow of a method 20 for assigning two PKA-based resource objects 7, 8 to a PKA-based user object 6.

[0135] First, it is generated 21 a different random string per PKA-based resource objects “1A$GT3”, “D74&2K” and use them as the credentials or authentication data of these resources. Second, the PKA-based user object, namely, the symmetric key S-Key is used to encrypt 22 the just created credentials. Third, storing 23 the encrypted random strings in the non-sensitive attribute of the resources, thus creating the cryptographic links. In particular, the encrypted string “C1DA632 . . . ” is stored in the non-sensitive attribute: encryptedCredential (see FIG. 4b).

[0136] Accordingly, the PKA-based resource objects 7, 8 can be authenticated to the HSM 1 through an identifier or a random string encrypted with the S-Key of the PKA-based user object 6. Furthermore, the attributes of each PKA-based resource objects 7, 8 refer to the PKA-based user object 6 as their parent.

[0137] FIG. 4b depicts the resulting assignment. As it can be seen, after the user logins with his/her credential “abc”, he/she is allowed to perform encryption/decryption operations. Then, the end-user creates the ownership of the PKA-based resource object 7 (only one PKA-based resource object for exemplary purposes) by setting the “Parent” attribute to the Object ID=“1234”, which is the PKA-based user object 6. Finally, the S-Key encrypts the generated random string “1A$GT3” to yield the encrypted string “C1DA632 . . . ” which is afterwards stored it in the attribute: encryptedCredential, as mentioned.

[0138] It is to be noted that the PKA-based user objects does not need to specify their encryptedCredential attribute, this is only done by the PKA-based resource objects in order to create the cryptographic link with the assigned PKA-based user objects.

[0139] Therefore, it is created the cryptographic link between the PKA-based user object 6 and the PKA-based resource object 7 by setting the “authenticationData” attribute of the PKA-based resource object 7 to the value that can only be decrypted by “Object ID 1234”. In other words, the AuthenticationData attribute of the PKA-based resource object is hidden and only accessible internally to the HSM 1.

[0140] FIG. 4c depicts a workflow for the authorization 30 to use the assigned PKA-base resource objects 7, 8 by PKA-based user object 6. First, the end-user must authenticate 31 to obtain the right to use the S-key for decryption. Second, the end-user uses 32 the S-Key for decryption and decrypts 33 the non-sensitive attributes that comprises the encrypted credentials. Finally, the PKA-based resource objects 7, 8 are authenticated to the HSM to obtain the right for accessing and managing these resources according to his/her permissions.

[0141] FIG. 5a depicts a schematic workflow 40 for extracting the PKA-based user object 6 out of the HSM.sub.1. After authenticating 41 the PKA-based user object 6 at the HSM.sub.1, the PKA-based user object is serialized 42 (i.e., producing a “blob”) with its authenticated state. Then, the resulting serial 6.1 is encrypted 44 by the HSM.sub.1 with a retrieved 43 symmetric key that can be an ID key (different for each PKA-based user object) or the same symmetric key (symmetry master key, “SMK”) for all PKA-based user objects. The encrypted serial 6.2 is then propagated 45 (see FIG. 4b), by the HSM.sub.1, through a secure communication channel such as a Transport Layer Security 9.

[0142] Therefore, the invention also provides a method for single authenticating an end-user account within a cluster of HSMs (i.e., HSM.sub.1 and HSM.sub.2) connected to each other through the secure communication channel. As shown in FIG. 5b, the encrypted serial 6.2 can be received, 46 by at least a second HSM (e.g., HSM.sub.2) of the cluster.

[0143] Accordingly, this HSM.sub.2 will decrypt the serial with the symmetric key and automatically authenticate the PKA-based user object. From an end-user point of view, it is a SSO because he or she is not requested to submit his/her credentials again in order to access to resources from different HSMs.

[0144] The representation of only HSM.sub.1 and HSM.sub.2 is for exemplary purposes, and the skilled person knows that more than two HSMs can be networked together to form a cluster such as the commercial Luna Network HSM products (e.g., version 7.7). In addition, HSM.sub.1 and HSM.sub.2 may represent partitions of another HSM. Alternatively or additionally, one HSM can be a back-up HSM.

[0145] Advantageously, with the present invention it is possible to transfer the authenticated state of that end-user account around different HSMs without relying in a centralized entity. Conventionally, it was necessary to centralize it by registering the user's state in an external entity like the Identity Management server. The blob is associated with accessing, so it is deleted as soon as the end-user account logout.

[0146] This PKA-based user object in the HSM.sub.2 may exist already, or may not. Because of the stateless of the cluster, after being authenticated, it can be propagated to the HSM.sub.2 and deleted from the HSM.sub.1.

[0147] This is further advantageously for workload balancing in HSM clusters, because it is not possible to foresee in which HSM or partition the next operation will take place. Thus, when an new HSM join the cluster, that SMK will travel thereto. Accordingly, when the blob lands to the new HSM, it has already the secret key to decrypt it.

[0148] FIG. 6a depicts a detailed view of an initial login for Single Sign On (50).

[0149] The PKA-based user object 6 or a modified form (e.g., the serial or blob 6.1) thereof is stored encrypted 6.2 in a database 10 outside or inside the HSM accessible via API, so that initiation of the associated end-user account retrieves this encrypted form from this RAM disk database and inserts it into the HSM for its decryption and authentication based on requesting the log-in credentials.

[0150] FIGS. 6a to 6c, and FIG. 8 depicts an “agent 11” which is a software entity that acts on the behalf of the application.

[0151] Therefore, method 50 is summarized as follows. A user 100 or end-user account opens session and logins 51 in the cluster via application or API. Then, the agent retrieves 52 the associated PKA-based user object (O.sub.PKA-USER) encrypted from the database and instantiate it 54 in the HSM.sub.1 1. At this point, the O.sub.PKA-USER is inside the HSM but not authorized to use it yet. It will become authorized once the end-user account provides his credentials 55 (it may also be a challenge responder).

[0152] If authenticated, the O.sub.PKA-USER is cached 56 at session level in the HSM, and it is reverted to the agent 57 the authenticated state of the O.sub.PKA-USER.

[0153] In step 58, it is created/cached a new session in the external database 10.

[0154] Then, as mentioned, the authenticated O.sub.PKA-USER is extracted out the HSM and propagated 59 towards other HSMs within the cluster. When the encrypted blob of the authenticated O.sub.PKA-USER reaches the second HSM.sub.2, it is retrieved again 60 the associated O.sub.PKA-USER from an external RAM disk database (in-memory cache). Then, it is opened a new session with the O.sub.PKA-USER 61, instantiated 62 again in the HSM.sub.2, automatically authorized 63 thanks to its already authorized state, and cache 64 in the HSM.sub.2 at application level.

[0155] FIG. 6b depicts a single logout 70 via changed credential. Once the end-user ends session, the O.sub.PKA-USER is still stored in the database but its state has changed. As known, all the changes has to go through the HSM (i.e., has to be enforced by the HSM).

[0156] If the session expires, or the user logs-out, the O.sub.PKA-USER is again retrieved from the database and insert it into the HSM, modify its state in the attributes and track it out. Since the HSM does not trust “anybody” (“route of trust”), the state of the O.sub.PKA-USER cannot be modified externally. In other words, for any modification in its attributes or functions it must be inserted back into the HSM.

[0157] In other words, anytime the end-user logs-in, logs-out, modifies its state, or anything else, it has to go through the HSM (any HSM), because any HSM comprises the SMK already. Accordingly, there is no need to use the original HSM which is advantageously from the point of view of workload balance.

[0158] In this particular example, the user 100 wishes to change 71 his or her password. Therefore, the agent 11 requests to the HSM to set or modify 72 the O.sub.PKA-USER. In the HSM, the password (attribute “authenticationData”) is changed and it is revoked 73 everything in the session O.sub.PKA-USER context. Note that the O.sub.PKA-USER was cached at session level in the HSM.

[0159] In step 74, it is reverted back to the agent that the password has been changed. In step 75, ongoing session in the external database 10 is updated.

[0160] Then, this session removal of the O.sub.PKA-USER is propagated 76 to the other HSMs within the cluster.

[0161] When this command 76 reaches the second HSM.sub.2, the associated O.sub.PKA-USER is retrieved from the external database removing its session 77 and reverting this information back to the agent 11. In step 78, the agent sends an instruction to the HSM.sub.2 to update its internal cache with the changes, alike step 73 for the HSM.sub.1. In this particular example, that update is a log-out of the session and finally, alike step 73 for the HSM.sub.1, in the HSM.sub.2 it is revoked 79 also everything in the session O.sub.PKA-USER context.

[0162] FIG. 6c depicts a logout with continuous authentication 80. Advantageously, it can be tracked the “IP address”, “Time-of-day”, “Past behavior”, “Usage pattern”, “invalid No. of logins” surpassing an established threshold in case a suspicious use is detected triggering a “Kill Switch” protocol. It further allows to use more trials on providing the right credentials in case someone uses the old cast version of the O.sub.PKA-USER.

[0163] This “kill switch” protocol automatically prompts the agent 81 that a suspicious behavior has been detected and, accordingly, user 100 will be logout from any ongoing session.

[0164] As can be seen in FIG. 6c, the same steps as in FIG. 6b have been taken. Therefore, the same units have been kept in the reference numbers only changing the tens from 7× to 8×.

[0165] FIG. 7 depicts a schematic diagram of an RBA framework for implementing access control to at least one cryptographic key stored within a HSM by an end-user account according to the invention.

[0166] The assignation of PKA-based resource objects (i.e., the keys) to specific PKA-based user objects is according to FIGS. 4a to 4c. In addition, to make this permission setting as complex as needed, further intermediate PKA-based objects with symmetry keys can be created to model the “roles”. The creation and assignation is similar to the one explained for PKA-based resource objects and PKA-based user objects.

[0167] Finally, FIG. 8 depicts a detailed view of a session creation 90 within a cluster of HSMs using different resources.

[0168] As mentioned before, the user 100 logs in and open session 91 in the HSM. The agent 11 forwards 92 the user's credentials to the HSM.sub.1. Then, the HSM.sub.1 caches 93 an authentication PKA-based object (henceforth O.sub.PKA-AUTH) at session level and reverts 94 to the agent the authenticated state.

[0169] Then, the agent requests 95 to open a resource session (i.e., a PKA-based object resource key, O.sub.PKA-RESOURCE) with the S-key (symmetry key) of the O.sub.PKA-AUTH. Next, the HSM.sub.1 caches 96 the S-key, in case the O.sub.PKA-RESOURCE be cryptographically linked to the O.sub.PKA-AUTH and the latter could access it, the HSM.sub.1 reverts 97 to the agent that the user is authorized to use the O.sub.PKA-RESOURCE.

[0170] In step 98, it is created/cached a new session in the external database 10 for the following relationship: OUID.sub.Auth.-SessionID.sub.Auth.-SessionID.sub.Resource.

[0171] Then, as mentioned, the new session (“OUID.sub.Auth.-SessionID.sub.Auth.-SessionID.sub.Resource.”) is propagated 99 towards other HSMs within the cluster. When the encrypted blob of this session reaches the second HSM.sub.2, it is retrieved the associated session from the external database (in-memory cache) and, if found, the database informs 101 to the agent that the new session has been opened. The agent proceeds to the login 102 and the HSM.sub.2 automatically caches 103 the O.sub.PKA-AUTH at session level.

[0172] After, the authenticated state is reverted back 104 to the agent, which requests 105 to open the resource session (O.sub.PKA-RESOURCE) with the S-key of the O.sub.PKA-AUTH. Then, the HSM.sub.2 caches 106 the S-key at access/application level and reverts back 107 to the agent that the user can now use the O.sub.PKA-RESOURCE.