Hierarchical key management based on bitwise XOR operations

A computer-implemented method manages cryptographic objects in a hierarchical key management system including a hardware security module (HSM), which institutes a key hierarchy extending from a ground level l0. Clients interact with the HSM to obtain cryptographic objects. A request is received from one of the clients for an object at a given level ln of the hierarchy (above the ground level l0). A binary representation of the object is accessed as a primary bit pattern p0, at the HSM and said pattern is scrambled via a bitwise XOR operation. The latter operates, on the one hand, on the primary bit pattern p0 and, on the other hand, on a control bit pattern pc that is a binary representation of an access code of the same length as said primary bit pattern p0. The pattern pc is obtained based on that given level ln of the hierarchy.

BACKGROUND

The invention relates in general to the field of computer-implemented methods for managing cryptographic objects in a in a hierarchical key management system that comprises one or more hardware security modules (HSMs) interacting with computerized clients, as well as related computerized systems and computer program products.

Key management relates to the management of cryptographic keys in a cryptosystem, which involves operations such as the generation, storage, use, destruction and replacement of keys. Key management requires specific cryptographic protocols, key servers, and other procedures.

Consistently, a key management system (KMS) is a system that generates, distributes and, more generally, manages cryptographic keys for clients (devices, applications). A KMS may handle several aspects of security, these ranging from secure generation of keys up to secure key handling and storage on the clients. A KMS typically includes a backend functionality for key generation, distribution, and replacement. It may further integrate specific client functionalities for injecting keys, storing and managing keys on the client devices.

Key management and key management systems are becoming increasingly important for the security of connected devices and applications with the development of the Internet of Things and cloud computing.

Hardware security modules (HSMs) are physical computing devices that protect and manage keys for performing cryptographic operations (i.e., crypto-processing) and strong authentication. Such modules are physical devices (e.g., plug-in cards) that typically attach directly to a computer (e.g., a network server).

HSMs typically comprise secure crypto-processor chips to prevent tampering and bus probing. In general, HSMs may be designed to provide tamper evidence and tamper resistance (e.g., to delete keys upon tamper detection). HSM systems are sometimes able to securely back up keys they manage. HSMs are typically clustered to provide high availability and, as such, conform to high-availability requirements of modern data center environments. They may notably form part of infrastructures such as online banking applications and public key infrastructures.

Amongst other functions, an HSM may rely on specific hardware, which typically exploits a physical process, to create a sufficient source of randomness (characterized by entropy). The available randomness is, in turn, used to generate random keys.

A hierarchical key management system (HKMS) is a KMS that relies on a key hierarchy extending from a ground level l0(typically corresponding to a master key, residing in plain form only inside an HSM). As per the key hierarchy, a key of a deeper key hierarchy level (assuming the master key on the ground level) is used to encrypt/wrap or decrypt/unwrap a key for an upper key hierarchy level. For example, the master key may be used to wrap/unwrap so-called “tenant” keys on a next level, while the tenant keys are used to wrap/unwrap so-called “project” keys on a further level. Project keys, in turn, are used to encrypt/decrypt data.

An HKMS allows for ‘bulk-deletions’: If the key for a given hierarchy tree branch is deleted or invalidated, all data in that hierarchy branch cannot be decrypted anymore (such data can be said to be pseudo deleted). All the more, an HKMS offers multiplied security, inasmuch as each level of the hierarchy tree is protected with its own (encrypted) key. For N hierarchy levels, N−1 decrypt/unwrap operations are required, which would have to be determined (cracked) to enable (rogue) access to the data.

SUMMARY

According to a first aspect, the present invention is embodied as a computer-implemented method for managing cryptographic objects in a hierarchical key management system. The system comprises a hardware security module (hereafter HSM), which institutes a key hierarchy extending from a ground level l0of this hierarchy. The system enables clients to interact with the HSM in order to obtain cryptographic objects. Basically, the method involves the following steps. Assume that a request is received from one of the clients, according to which request a cryptographic object is to be provided at a given level lnof the hierarchy (above the ground level l0). Then, a binary representation of a cryptographic object is accessed as a primary bit pattern p0, at the HSM and said primary bit pattern is scrambled via a bitwise XOR operation, in order to serve the request received. The latter operates, on the one hand, on the primary bit pattern p0accessed and, on the other hand, on a control bit pattern pcthat is a binary representation of an access code of a same length as said primary bit pattern pc. Said control bit pattern pcis obtained based on that given level lnof the hierarchy.

In embodiments, a scrambled bit pattern psmay similarly need be unscrambled (again via a bitwise XOR operation), to serve a client request.

According to another but related aspect, the invention is embodied as a computerized system for managing cryptographic objects. The system comprises an HSM (at a ground level l0of the hierarchy instituted by the system) and is designed to enable clients to interact with the HSM in order to obtain such cryptographic objects. The system is otherwise configured to perform steps such as described above, i.e., receive a client request, according to which a cryptographic object is to be provided at a given level lnof the hierarchy (above the ground level l0), access a binary representation of a cryptographic object as a primary bit pattern p0, and scramble said primary bit pattern via a bitwise XOR operation to serve the request received.

In embodiments, wherein the system comprises two or more HSMs, each at a ground level l0of respective hierarchies (or hierarchical paths in a hierarchy) of the system. In such cases, the above steps can be performed (e.g., concurrently) for each of said respective hierarchies of the system.

According to a final aspect, the invention is embodied as a computer program product for managing cryptographic objects in a hierarchical key management system such as described above (the system comprises at least one HSM at a ground level l0of its hierarchy and otherwise enables clients to interact with the HSM in order to obtain cryptographic objects). The computer program product comprises a computer readable storage medium having program instructions embodied therewith. Such program instructions are executable by one or more processors, to cause to take steps according to the methods described herein.

Computerized systems, methods, and computer program products embodying the present invention will now be described, by way of non-limiting examples, and in reference to the accompanying drawings.

The accompanying drawings show simplified representations of devices or parts thereof, as involved in embodiments. Similar or functionally similar elements in the figures have been allocated the same numeral references, unless otherwise indicated.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

In a hierarchical system as described in the background section, each time a data encryption key (DEK) is needed for an operation (and hence need be available in plain form), all branch access keys need be unwrapped, which implies multiple unwrap operations. This is a sequential process: the keys of any level can only be processed once the key of the previous level is available in plain form. This implies that the keys of all previous levels need be available in plain, which results in a severe performance penalty (HSMs typically involves long latencies, on the order of the millisecond to perform any wrap/unwrap operation).

Therefore, the present Inventors have devised novel techniques, wherein binary representations of cryptographic objects (COs) are scrambled (or unscrambled) via an efficient operation, which operation yet depends on the hierarchy instituted by the system. Such techniques can be embodied as methods, systems and computer program products, which concern distinct but related aspects of the invention, as described in detail in the following description, which is structured as follows. First, general embodiments and high-level variants are described (sect. 1). The next section addresses more specific embodiments and technical implementation details (sect. 2).

1. General Embodiments and High-Level Variants

In reference toFIGS. 1, 2, a first aspect of the invention is described, which concerns a computer-implemented method for managing COs in a hierarchical key management system1(or HKMS in the following), such as depicted inFIG. 5.

This HKMS notably comprises a hardware security module11(or HSM), which institutes a key hierarchy extending from a ground level l0of this hierarchy. The HSM11(or rather, the master key residing in plain form therein) can be considered to be the unique member at the ground level l0of the key hierarchy it institutes, if higher-level keys are (meant to be) stored (in wrapped form) outside the HSM. I.e., this hierarchy can be regarded as an arborescence, defining a rooted tree that extends from the ground-level (e.g., corresponding to the master key) to higher key levels in the hierarchy, as simply exemplified inFIG. 4, where keys111-113define three hierarchical levels. With this definition, a lower-level key is closer to the master key level than a higher-level key. Of course, a master key may equivalently be regarded as sitting on top of a respective hierarchy, in which case a higher-level key would be considered to be closer to the master key level. That is, the master key may equally well be regarded as the hierarch, i.e., on top of the downward hierarchy it institutes. In the following description, however, a master key is assumed to be the unique member at the ground level of its hierarchy, for the sake of description. Now, we note that the hierarchy may in fact be multidimensional, whereby several hierarchical paths (or hierarchies) may possibly be involved, each extending from master key levels of respective HSMs, as discussed later in detail.

The HKMS is otherwise designed to enable clients31-33to interact with the HSM11in order for the clients to obtain COs, which typically consists of cryptographic keys (e.g., wrapped keys) and/or initialization vectors (IVs). The clients31-33may for instance be implemented in a cloud30, e.g., as containers, virtual machines, or respective computer devices. Such clients may typically interact with HSMs11-13of the system1on behalf of users80that otherwise interact (computationally speaking) with the clients31-33.

Assume that a request is received (step S100,FIG. 1) from one of the clients, according to which request a CO is to be provided at a given level lnof the key hierarchy, above the ground level l0.

Then, a binary representation of this CO is accessed (step S110) at the HSM11. This binary representation is accessed in the form of a bit pattern, which is referred to as a primary bit pattern p0in the following.

Next, this primary bit pattern is scrambled (step S150) via a bitwise XOR operation, which depends on the hierarchical level lnat which the CO is to be provided, in order to serve S160-S170the request received at step S100. In more detail, the bitwise XOR operation operates, on the one hand, on the primary bit pattern p0accessed at step S110and, on the other hand, on a control bit pattern pc, where the control bit pattern pcdepends on the hierarchical level lnat which the CO is to be provided. Several possibilities can be contemplated, which allows the access code pcto be obtained based on that given level ln, as exemplified later.

This control bit pattern pcis, intrinsically, a binary representation of an access code. Importantly, this access code is here determined so as for it to have the same length as the primary bit pattern p0. Thus, the bitwise XOR function (also noted “⊕”, see below) operates on two bit patterns of equal length, to thereby perform the logical exclusive OR operation. I.e., this function operates on each pair of corresponding bits in each of the patterns, as known per se.

The present scheme differs from classical multi-encryption/multi-wrap processes as implemented in usual HKMSs. That is, this process does not require all branch access keys to be unwrapped to perform a requested operation. Still, the chosen approach allows for ‘bulk-deletions’. Namely, if the access code for a given hierarchy tree branch is deleted or invalidated, all data in that hierarchy branch cannot be decrypted anymore. All the more, the present approach allows the number of operations required from the HSM to be reduced.

While, depending on the sophistication of the scheme involved, some operations may still be required at the HSM (e.g., to unwrap a key and/or perform some encryption/decryption process), the scrambling operation S150itself will normally be performed independently from any key residing in plain form in the HSM (at least after the initial object has been accessed at step S110). That is, the process may go through as few encryption/wrap stages along the hierarchy as possible. Meanwhile, scrambled (and possibly encrypted) versions of the COs can be provided to requesting clients, e.g., in view of storing such COs outside of the HSMs11-13, so as to save space on the HSMs.

Note, the XOR operation is easily reversible. For example, given two equal-length bit patterns π1={1, 0, 1, 1, 0} and π2={1, 1, 0, 1, 0}, one obtains π1⊕π2=π2⊕π1=π3={0, 1, 1, 0, 0}, where the bitwise XOR function nicely satisfies the following properties: π1⊕π3=π2and π2⊕π3=π1. I.e., should a client request to store or otherwise provide a scrambled, encrypted object on to the HSM, then a corresponding, primary bit pattern p0can easily be restored by XORing the scrambled bit pattern psprovided. The pattern psis, this time, XORed with a corresponding control bit pattern pc, where the latter again depends on the hierarchical level from which the scrambled bit pattern originates. The bitwise XOR is a fast, simple operation that is typically directly supported by the processor. Normally, this operation is substantially faster than a multiplication/division, and sometimes even faster than an addition/subtraction.

As illustrated inFIG. 2, the control bit pattern pc(used to scramble S150the primary bit pattern p0) is preferably obtained S120-S140by computing an operation S140on a number n of operands p1. . . pn. The number n of operands depends on the level lnof the hierarchy at which the CO is to be provided. More precisely, this number n is determined by the rank of said level ln. In fact, the number n may typically be equal to the rank of the level ln. This, however, depends on how the hierarchy is defined, the actual implementation and what keys are considered to form part of the hierarchy.

The operation performed at step S140may for example be a mere hash function (or any pseudorandom function), designed to map n operands it uses as input to a bit pattern of a same length as said primary bit pattern p0.

Another possibility is to rely again on a bitwise XOR operation, as mostly assumed in the following, without prejudice. The XOR function operates S140this time on n same-length bit patterns p1. . . pn, where each of the patterns p1. . . pnis a binary representation of a respective access code, which has a same length as said primary bit pattern p0.

For example, where the client request is to provide a CO at the first level l1of the hierarchy, i.e., one level above the ground level l0, then the HSM provides a binary representation of a (possibly encrypted/wrapped) CO as a primary bit pattern p0. Next, p0is XORed with the control bit pattern pc. Since here the CO need be provided at the first level l1, a unique operand p1(a unique bit pattern) is involved to determine pcin this example. In fact, pcis equal to p1in that case, since the bitwise XOR operation applied to a unique bit pattern yields that same bit pattern.

As another example, if a request is made to provide a CO at the second level l2of the hierarchy, i.e., two levels above the ground level l0, then the HSM provides a (possibly encrypted/wrapped) CO as a primary bit pattern p0, which pattern p0is XORed with a control bit pattern pcthat is now obtained by XORing two bit patterns, i.e., p1and p2, respectively associated to levels l1and l2. That is, pc=p1⊕p2. And similarly, for a request to provide a CO at the third level, one uses pc=p1⊕p2⊕p3, and so on.

More generally, the operation S140can be performed via any deterministic function of the n operands, which may but does not necessarily need be reversible. As said, a pseudorandom function (e.g., as approved by the NIST) may be used. Another possibility is to use any function pair, where one function of this pair is doing the reverse operation of the other, etc. Preferred however, is to rely on the XOR function, as exemplified above, as the latter need already be implemented for scrambling the primary bit pattern. In all cases, the function used makes sure that the control bit pattern pcas eventually obtained has the same length as the primary bit pattern p0.

As further illustrated inFIG. 2, the control bit pattern pcis preferably obtained by selecting S120the needed n operands p1. . . pnfrom a set of N potential operands, prior to the computation performed at step S140. The N potential operands are termed hierarchical access codes (or HACs). This selection depends on the level lnat which the CO is to be provided. As seen inFIG. 2, the initial set of N HACs from which the n operands are selected corresponds to respective levels lN, lN−1, lN−2, . . . , l1, of the overall hierarchy.

The n operands preferably correspond to n same-length bit patterns p1. . . pn, should a bitwise XOR operation be used at step S140, in which case these operands are selected from a set of N same-length bit patterns corresponding to levels lN, lN−1, lN−2, . . . , l1of the overall hierarchy. As the rank of the level lnis less than or equal to the rank of the hierarch lNof said levels lN, lN−1, lN−2, . . . , l1, i.e., n≤N, a subset of n bit patterns need be identified from the set of N bit patterns.

The system1may for instance comprise a database20, meant to store the set of N HACs, as assumed inFIG. 2. The database20is accordingly termed HAC database in the following. While the N bit patterns may possibly be stored unencrypted thereon, additional security can easily be achieved by storing the HACs in an encrypted form on the HAC database20.

The HACs may for instance correspond to initialization vectors (IVs), toggled according to a bitwise XOR operation. In that respect, the present methods may advantageously be implemented so as to conform to the so-called AES-GCM protocol (where AES and GCM respectively stand for Advanced Encryption Standard and Galois/Counter Mode). E.g., the HACs may be stored in the additional authenticated data (AAD) of the AES-GCM. This has the advantage that, access to the encrypted HAC database20is not required for decryption, while HACs can still be authenticated.

Note, the N bit patterns may possibly be stored (encrypted or not) together with a pointer pointing at the location of a next bit pattern. This way, accessing one of the N bit patterns makes it possible to sequentially access the next bit pattern. Such a solution makes it harder to steal the HACs, while still enabling an easy retrieval thereof from the system.

As evoked earlier, the CO to be provided (as per the request received S100) may for example be a cryptographic key, corresponding to a certain key level (as determined from the client request). In that case, the pattern p0accessed at step S110shall preferably be a binary representation of a wrapped key, as assumed inFIG. 2(padlocked key depictions denote wrapped keys in the accompanying drawings). This representation is accessed S110from the HSM11. The accessed key112may possibly reside in wrapped form in the HSM and thus be directly available. In variants, and as illustrated inFIG. 2, the key112may only be available in plain form in the HSM, which therefore requires to first wrap S108the key112, using a lower-level key111. The key111is assumed to be a master key available in plain form inside the HSM11in the example ofFIG. 2. Note, however, that the lower-level key111may, in variants, first need be unwrapped, using a key further down in the hierarchy. That is, a hierarchical process may be required to wrap the key112, as explained in the background section. Unwrapping/wrapping operations are performed in the HSM11: key wrapping can be regarded as an export function, which allows a plain key112(residing in plain form in the HSM) to be exported from the HSM in a secure (wrapped) form.

While the initial access S110to the primary bit pattern p0may indeed require wrapping/unwrapping operations (as in variants described above), the operation performed at step S150is, itself, independent from any key residing in the HSM. I.e., the primary bit pattern p0is scrambled S150independently from any key residing in plain in the HSM11. That is, after the primary bit pattern p0was accessed S110at the HSM, no additional operation (e.g., key unwraps) is required from the HSM, such that no interaction with the HSM is needed anymore.

Still, the binary representation of the CO accessed at step S110shall preferably be a binary of a wrapped (or otherwise encrypted) version of this CO, such that the binary representation accessed can be safely provided S110from the HSM11to an external entity (yet closely interacting with the HSM), for this entity to scramble S150the primary bit pattern outside the HSM11. In variants, however, the primary bit pattern can be scrambled S150inside the HSM11, using computational resources thereof.

In all cases, the scrambled pattern pscan then be provided S160to, e.g., a requesting client31-33, for it to store the scrambled bit pattern pson an external database50(e.g., a client database, which is outside the HSM11). In variants, the HSM (or, rather, a computerized entity closely interacting therewith) may directly instruct S170to store the scrambled bit pattern pson the external database50(e.g., a client database). Whenever the pattern psis to be stored on an external database50, the primary bit pattern should much preferably correspond to a CO that is initially encrypted (wrapped), for security reasons.

As evoked earlier, the HKMS1may possibly involve a complex hierarchy, involving several hierarchical paths (or sub-hierarchies), each subtended by respective master key levels of the HSMs. I.e., in embodiments, the HKMS1comprises two or more HSMs11-13(as inFIG. 5), where each of the HSMs institutes a key hierarchy extending from a ground level l0of a respective hierarchical path. In that case, steps S100-S150can be concurrently performed for each respective hierarchical path (though the concurrent processes are likely asynchronous). That is, client requests may be concurrently received at a given levels of the respective hierarchical paths, according to which request COs need be provided at corresponding hierarchical levels above the ground levels l0of the various HSMs. Then, binary representations of the COs need be accessed at respective HSMs (as primary bit patterns), which are then scrambled via bitwise XOR operations, as described earlier.

So far, the description merely focused on the production and exportation of a scrambled CO. The following describes (in reference toFIGS. 3, 4) additional steps as performed upon receiving inbound scrambled objects (as in embodiments).

Assume that a request is received (at step S200,FIG. 3) from one of the clients (and at a given hierarchical level lmabove the ground level l0), which request involves S201-S204a scrambled bit pattern ps. Just like before, this scrambled bit pattern psis a binary representation of a CO. Because this object has circulated outside of the HSM11, it is preferably a binary representation of an encrypted version of this CO, for security reasons.

In that case, an inverse operation need be performed, which requires accessing a control bit pattern pc. Again, the control bit pattern pchas the same length as the received pattern psand is a binary representation of a given access code, which depends on the hierarchy. That is, the control bit pattern pcis obtained S220, S240based on said given level lmof the hierarchy.

Having accessed the control bit pattern pc, the scrambled pattern pscan be unscrambled S250via a bitwise XOR operation, which like before, operates on both patterns psand pc. This way, an unscrambled bit pattern p0is obtained. If unscrambled outside the HSM11, the unscrambled pattern p0is provided S260to the HSM11, for it to, e.g., store the pattern p0or somehow serve S270the request received at step S200.

Various types of requests may be accordingly served. For example, a cryptographic operation may be performed S270(as per the request received at step S200) at the HSM11, whereby the unscrambled bit pattern p0is used as input to a cryptographic primitive (e.g., for a data encryption or decryption process).

As explicitly depicted inFIG. 4, the operation S270may first require a hierarchical key process S211-S212. For example, a low-level key111is used to unwrap S211a wrapped key112w, in order to obtain a plain key112, which is in turn used to unwrap S212the object113wcorresponding to the unscrambled bit pattern p0provided at step S260. This way, a plain key113is restored, in the HSM11, which can then be used to serve S270the initial client request S200.

As said above, the control bit pattern pcused at step S250depends on the hierarchy. And as explained earlier in reference toFIGS. 1, 2, the control bit pattern pcmay advantageously be computed S220, S240using a deterministic, reversible function of a number n of operands p1. . . pnthat depends on the hierarchical level lmat which the request was received S200. In particular, the control bit pattern may be obtained S240via a bitwise XOR operation operating on m same-length bit patterns p1. . . pm(each being a binary representation of a respective access code of a same length as the second control bit pattern pcto be obtained). The number m of said bit patterns p1. . . pmdepends on said level lm, e.g., on the rank of this level. And again, the m same-length bit patterns p1. . . pmare preferably assigned to respective levels lm, lm-1, lm-2, . . . , l1of the hierarchy.

The initial steps S201-S204shown inFIGS. 3, 4, whereby wrapped key data are fetched or pulled, correspond to a scenario, wherein, upon receiving the request S200, the database50is queried to provide S203a CO stored thereon in a scrambled form, which is used S204to the operation S250, while the HAC database20is concurrently queried S202to perform a selection S220of the n operands used as input to the operation S240, hence yielding the control pattern pcused as the other input to the operation S250.

Referring toFIG. 5, another aspect of the invention is now described, which concerns a computerized system1for managing COs. The system1shall typically be, e.g., a HKMS or a subsystem of a HKMS. Main aspects of such systems have already been discussed earlier, with reference to the present methods. Therefore, such systems are only briefly described in the following.

The system1comprises one or more HSMs11-13(preferably several HSMs), as well as clients31-33configured to interact with the set of HSMs11-13, on behalf of users80, as discussed earlier. Preferably, there is a one-to-one mapping between clients31-33and HSMs11-13. I.e., one client31-33preferably interacts with one HSM at a time, be it to ease implementation and resource management. Other architectures can, however, be contemplated.

Each HSM11can again be regarded as instituting a respective key hierarchy that extends from a ground level l0of this hierarchy. The system1is generally configured to enable clients to interact with the HSM11in order to obtain such COs. The system1is otherwise equipped with suitable interfaces to receive client requests, according to which COs are to be provided at given levels lnof the hierarchy (above l0). In turn, binary representations of the requested COs are accessed (as primary bit patterns p0at the HSMs11-13, for computerized entities (which are not necessarily the HSMs themselves) of the system1to scramble the primary bit patterns accessed. Such entities must accordingly be configured to perform bitwise XOR operations as described earlier in reference toFIGS. 1-4. InFIGS. 2 and 4, the (un)scrambling operations S150, S250are assumed to be performed outside the HSM11.

The computerized clients31-33may for instance have access to respective external storage media41-43. The external storage media41-43are, e.g., attached to or in close data communication with the clients31-33. Such media41-43still reside in the client space (and not in the users' space), where COs can still be relatively safely stored, as assumed inFIG. 5. The external storage media41-43may for instance include, each, a database (as denoted by numeral reference50inFIGS. 2 and 4). Again, other architectures can be contemplated.

Still referring toFIGS. 2, 4, the system1may further comprise a HAC database20, storing a set of N same-length bit patterns corresponding to respective levels lN, lN−1, lN−2, . . . , l1of the hierarchy. This way, a control bit pattern pcmay be obtained via an operation (e.g., a bitwise XOR operation) operating on a number n of bit patterns selected from the N bit patterns based on the hierarchical level lncorresponding to the request, as explained earlier. I.e., the n selected bit patterns correspond to respective levels ln, ln−1, ln−2, . . . , l1of the hierarchy. Similarly, where multiple hierarchical paths are involved, the database20may store respective sets of same-length bit patterns, from which selections of subsets of bit patterns can be performed.

The storage of the various (wrapped) keys112w,113w, as obtained in embodiments (e.g., at steps S211, S212) may possibly be outsourced (by each HSM concerned) to external storage media41-43. E.g., the wrapped keys may be directly supplied upon wrapping or temporarily retained in the cache of the HSMs, prior to being supplied to requesting users/clients, e.g., to accommodate current network traffic conditions. In all cases, the clients31-33preferably replicate the wrapped keys, or maintain identifiers thereof. Yet, the corresponding (unwrapped) keys can later be identified, if necessary, e.g., using a local mapping to key handles stored on the HSMs. Incidentally, we note that the terminology “unwrapped” is here used to denote keys that are in unwrapped or non-wrapped form.

Next, according to a final aspect, the invention can be embodied as a computer program product for managing COs in a HKMS1such as described above. This computer program product comprises a computer readable storage medium having program instructions embodied therewith, where the program instructions are executable by one or more processors, to cause the latter to take steps according to the present methods. Aspects of the present computer programs are discussed in detail in sect. 2.2.

This program may for instance be run at the clients and the HSMs (in a delocalized fashion), or at specific nodes (e.g., the HSMs). In addition, this program may possibly involve a controller authorized to interact with the HSMs or with both the clients and HSMs. Many possible architectures can be contemplated, as the person skilled in the art will appreciate.

The above embodiments have been succinctly described in reference to the accompanying drawings and may accommodate a number of variants. Several combinations of the above features may be contemplated. For example, in embodiments, a key hierarchy is relied on, which use hierarchy access codes (HACs) to replace the traditional sequential key hierarchy by parallel implementation of the hierarchy, orthogonally to keys. Such HACs are further used to scramble wrapped keys via bitwise XOR operation exoring binary representations of such keys with the HACs to create arbitrarily deep hierarchies, yet without touching the principle of having “tenant” keys (to ensure compatibility with so-called “bring your own encryption”, BYOE, or “Bring your own key”, BYOK). The HACs are optionally encrypted. The key material can possibly be scrambled outside the HSM or inside the HSM.

2. Specific Embodiments—Technical implementation details

It is to be understood that although this disclosure refers to embodiments involving cloud computing, implementation of the teachings recited herein are not limited to a cloud computing environment. Rather, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment now known or later developed. Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

2.2 Systems, methods and computer program products

While the present invention has been described with reference to a limited number of embodiments, variants and the accompanying drawings, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the present invention. In particular, a feature (device-like or method-like) recited in a given embodiment, variant or shown in a drawing may be combined with or replace another feature in another embodiment, variant or drawing, without departing from the scope of the present invention. Various combinations of the features described in respect of any of the above embodiments or variants may accordingly be contemplated, that remain within the scope of the appended claims. In addition, many minor modifications may be made to adapt a particular situation or material to the teachings of the present invention without departing from its scope. Therefore, it is intended that the present invention not be limited to the particular embodiments disclosed, but that the present invention will include all embodiments falling within the scope of the appended claims. In addition, many other variants than explicitly touched above can be contemplated.