Chained manifests for key management and certification

Abstract

A computer-implemented method is disclosed for managing the lifecycle of at least partially interdependent cryptographic keys, each of which is signed and associated with a different one of the artifacts. The method includes creating a key manifest, the key manifest including data regarding determined dependencies of the cryptographic keys at the time one of the artifacts is constructed, and encrypting the key manifest with a manifest key, and when a lifecycle change occurs to one of the groups including one of the artifacts and one of the interdependent cryptographic keys in the key manifest of one of the artifacts, the method includes decrypting the key manifest and invoking an action on the associated one of the groups including one of the artifacts and at least one of the interdependent cryptographic keys according to the key manifest.

Description

[Technical field]

[0001] The present invention relates generally to methods for managing the lifecycle of cryptographic keys, and more particularly to a computer-implemented method for managing the lifecycle of at least partially interdependent cryptographic keys. The present invention further relates to a distributed link manifest system, and a computer program product for managing the lifecycle of interdependent cryptographic keys. [Background technology]

[0002] The continuing trend to protect soft assets leads to the encryption of almost anything stored in electronic form on storage systems such as rotating disks (HD = hard drives) or solid state disks (SSD). Soft assets can therefore be anything that can be stored in electronic form. This can include, for example, software components in source code, object or executable form, digital images, artificial intelligence models, spreadsheets with data, text, voice and sound data, to name a few.

[0003] To increase the level of protection of data or soft assets, data may be protected by cryptographic keys. In other advanced systems, cryptographic keys may be changed from time to time. This may lead to problematic situations such as: A new software component may be built from software sub-components, each of which may be protected by a cryptographic key. The same is true for the newly built software component. In such situations, a key roll, i.e., changing the key of a sub-component, caused by a breach or due to a security policy, may require complex and time-consuming efforts, especially when crossing organizational boundaries. This may be the case, for example, if one of the sub-components may be available from a third party, e.g. an open source software pool or a third-party software developer, e.g. an ISV (Independent Software Vendor).

[0004] In such a situation, all keys of all dependent components, i.e. components whose subcomponents are used for construction, are also required to undergo key rolls, i.e., changes of their respective cryptographic keys.

[0005] A further complication can be that modern systems may have multiple "keys and chains of trust" such that their security proposition is built on underlying cryptographic concepts.

[0006] Currently known ideas used to deal with such situations have a major limitation in that they are manual processes. This may be particularly applicable to procedures such as regularly updated "certificate revocation lists" on public web pages that may be listed in certificates and need to be queried to see if the certificate is still valid. Additionally, regular automatic key rolls based on dates or triggers may be established hierarchically within the key chain.

[0007] In this general technical concept, some published documents have already been made, for example, US Patent Application Publication No. 20190273611(A1) describes a method for partially encrypting a conversation using different encryption keys. Thereby, messages communicated during a conversation session may be encrypted using the encryption key. Other conversation participants may then use the encryption key to decrypt the messages. During a conversation, an event may occur that generates a new encryption key. In that case, the conversation participants may use the new encryption key when communicating. As a result, new members who do not have the old encryption key may not be able to access previously encrypted messages, while previous members who do not have the new encryption key may not be able to access newly created messages. Thus, an independent collection may store messages and associated encryption keys.

[0008] Furthermore, U.S. Patent No. 10,958,424 (B1) describes a system, such as an enhanced service, for receiving a first public key derivable at least in part based on a secret shared between at least a first device and a second device. The system can derive a cryptographic key based at least in part on the first public key and transmit a second public key that enables another system to derive the cryptographic key.

[0009] However, such approaches do not solve the problems mentioned above. Therefore, there may be a need to manage cryptographic key dependencies in an automated and temper-approved manner based on dependent software components. Summary of the Invention

[0010] According to one aspect of the invention, a computer-implemented method for managing the lifecycle of at least partially interdependent cryptographic keys, each of which may be signed and associated with a different one of the artifacts, may include creating a key manifest, the key manifest including data regarding determined dependencies of the cryptographic keys at the time one of the artifacts is constructed, and encrypting and / or signing the key manifest with a manifest key, and when a lifecycle change occurs to one of the groups including one of the artifacts and one of the interdependent cryptographic keys in the key manifest of one of the artifacts, the method may include decrypting the key manifest and invoking an action on the associated one of the groups including one of the artifacts and at least one of the interdependent cryptographic keys according to the key manifest.

[0011] According to another aspect of the present invention, a distributed link manifest system for managing the life cycle of interdependent cryptographic keys may be provided. Each of the cryptographic keys may be signed and associated with a different one of the artifacts. The system includes a processor and a memory communicatively coupled to the processor, the memory storing program code portions that, when executed, enable the processor to create a key manifest, the key manifest including data regarding determined dependencies of the cryptographic keys at the time one of the artifacts is constructed, and to encrypt the key manifest with the manifest key. When a life cycle change occurs to one of the groups including one of the artifacts and one of the interdependent cryptographic keys in the key manifest of one of the artifacts, the processor may also be enabled to decrypt the key manifest and invoke an action on the associated one of the groups including one of the artifacts and at least one of the interdependent cryptographic keys according to the key manifest.

[0012] The proposed computer-implemented method for managing the lifecycle of at least partially interdependent cryptographic keys may provide multiple advantages, technical effects, contributions, and / or improvements.

[0013] A key manifest can be a signed metadata artifact that may describe or configure the cryptographic keys, sources, and secrets used for a given artifact, e.g. software but also any other protectable item (e.g. training data for an AI system, partial images for the composition of a larger image, paragraphs of a large paper, ...). The idea here is to have each subkey manifest or key chain signed by the step owner, and all parties that access the artifact, and end users or processes that represent end user actions, may need to access the key manifest.

[0014] The key manifest may represent a verified source for obtaining the corresponding information of the artifacts, and evidence of the fact that the key chain can still be trusted. Thus, the key manifest may be used to trigger any build or modification activity on the artifact, in the sense that a "previous" step in the artifact's lifecycle may provide a manifest (i.e., by a build or modification activity) and a subsequent step may use this to trigger a build step or modification of the involved step (i.e., roll dependent keys, rebuild artifact, etc.). Thus, assuming that all components, i.e. hash values, are fully validated, any change in the previous or subsequent artifact or key manifest may result in a different new hash, and a different / changed key manifest. Perhaps not on the components listed, but on the UUIDs, identifiers, hashes in the key manifest. As a result, when a software platform vendor changes the cryptographic keys for the base software components, the ISVs (independent software vendors who use the base software components for their own solutions) will automatically respond and change their keys as well. Additionally, the construction step of a software component, i.e., an artifact, will incorporate validation of the key chain whenever the key chain contains or depends on secrets.

[0015] Moreover, the proposed method allows a complete "watertight" and uncompromised set of security measures, where the owner or origin of each change to an artifact will also adapt the key chain, i.e., the key manifest, in parallel. It can therefore always be auditable what kind of construction history an executable software artifact has. This property can be useful, but not only, to ensure reliable execution of interrelated cloud computing services in large and complex heterogeneous cloud computing environments. Changes in the key chain are reflected "downstream" using the key manifest. Key changes can be triggered by any event, e.g., time-based key roll or key compromise or some other event.

[0016] Last but not least, it is noted that the key manifest may also be advantageously used during the artifact deployment step, for example in the form of executable code, and thus used as proof of "authorized" or trusted workload deployment.

[0017] Below, additional embodiments of the inventive concepts applicable to methods and systems are described.

[0018] According to an advantageous embodiment of the method, the artifact may be encrypted, i.e., the artifact may not only be signed but also protected by a cryptographic key. Thus, decryption may require a key that may be generated as follows: If the key manifest of level n+1 may have a secret, the public key from the key manifest of level n may be used, for which the public key encrypts the key manifest generated at level n. Assuming that level n+1 has a secret, it is possible to decrypt the key manifest. Alternatively, if the key manifest of level n may have a secret that may have been used during signing, the key manifest of level n may pass a public key to level n+1, together with the key manifest or through another trusted communication channel. At level n+1, such a public key may be used to verify whether the data is from the expected source (here level n). Combining the above level n and level n+1, a trusted key exchange may be performed. Based on such a process, the level n and level n+1 key manifests can determine a common secret that can be used by both through key derivation. Both levels exchange their public keys and then the key artifacts can be encrypted by the common secret. As a further beneficial consequence, the proposed key manifest concept can also be used in the context of the well-known Diffie-Hellman key exchange.

[0019] According to an interesting embodiment of the method, the manifest key may encrypt only a portion of the key manifest, which may exemplarily be a readable JSON data structure having the encrypted portion, the signature, and some other metadata associated with the artifact.

[0020] According to an acceptable embodiment of the method, the action may include creating a new key. This may be a useful feature when the lifecycle change is, for example, a deployment or instantiation of a software artifact. In this case, a new key may be generated, as also shown in the figure.

[0021] According to another acceptable embodiment of the method, the action on the artifact is to build or modify the artifact (i.e., a build process), or to deploy the artifact. In this way, not only user-initiated modifications (e.g., edits) are reflected, but also machine / system-initiated modifications can lead to an update of the key manifest. According to a preferred embodiment of the method, the action on at least one of the interdependent cryptographic keys can be a change of one of the interdependent cryptographic keys. This can be considered as a logical consequence of building the key manifest. If a key roll can occur for a member of the key chain, this occurrence can have the effect that "downstream" keys may also need to be changed in case of direct or indirect dependency on the related artifact, and thus of the artifact on its related key. There can be several event triggers for this, such as any kind of alert, a periodic key policy check, or a periodic, e.g., time-based, key roll.

[0022] According to an advantageous embodiment of the method, the lifecycle change may be the expiration or revocation of at least one of the dependent cryptographic keys or key manifests, so that any change in the integrity of the key chain may be interpreted as a lifecycle change, which may result in the modification of interdependent keys in the respective key manifests.

[0023] According to a further developed embodiment of the method, the action on at least one interdependent cryptographic key may include encryption or decryption of data, e.g. data provided with a relationship to an artifact, and the resulting key manifest includes a reference to the data, which may be the case, for example, when the artifact can be interpreted as a pointer to the data.

[0024] According to another preferred embodiment of the method, the key manifest may be a combination of multiple, i.e. at least two, key manifests, an example of which is given in the figure as an example of a construction process envisaged to combine at least two artifacts to build a new larger artifact.

[0025] According to one embodiment of the method, the key manifest may include certificates used to validate dependent key manifests. This may also indicate that more than one encryption or decryption key may be part of the key manifest. Other associated security related data may also be incorporated into the key manifest. These may be subject to the same or equivalent actions as the interdependent keys of the related artifact.

[0026] According to a further developed embodiment of the method, each of the interdependent cryptographic keys may be a login credential, an API (Application Programming Interface) token, or a key protected by a hardware security module. However, the list of potential meanings of components of the key manifest may not be limited to this. Security-related components may be used as part of the key manifest. In case of using the option of including API tokens in the key manifest, interfaces between software components, i.e. services, may have associated key manifests.

[0027] Furthermore, embodiments may take the form of an associated computer program product accessible from a computer usable or computer readable medium that provides program code for use by or in connection with a computer or any instruction execution system. For purposes of this description, a computer usable or computer readable medium may be any apparatus that may encompass means for storing, communicating, transmitting, or transferring a program for use by or in connection with an instruction execution system, apparatus, or device.

[0028] It should be noted that embodiments of the present invention are described with reference to different subject matters. In particular, some embodiments are described with reference to method type claims, and other embodiments are described with reference to apparatus type claims. However, a person skilled in the art will infer from the above and following description that, unless otherwise notified, any combination of features belonging to one type of subject matter, as well as any combination between features relating to different subject matters, in particular between features of a method type claim and a feature of an apparatus type claim, is also considered to be disclosed within this document.

[0029] The above-defined and further aspects of the invention are apparent from and will be explained with reference to the example embodiments described hereinafter, to which the invention is not limited.

[0030] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the following drawings: [Brief description of the drawings]

[0031] [Figure 1] FIG. 1 is a block diagram of one embodiment of a computer-implemented method of the present invention for managing the lifecycle of at least partially interdependent cryptographic keys. [Diagram 2] A block diagram showing how a key manifest can be integrated. [Diagram 3] FIG. 1 is a block diagram illustrating the occurrence of lifetime events and how the proposed system responds. [Figure 4] FIG. 1 is a block diagram of one embodiment of a distributed link manifest system of the present invention for managing the lifecycle of interdependent cryptographic keys. [Diagram 5] FIG. 5 illustrates an embodiment of a computing system comprising the system of FIG. 4. [Figure 6] FIG. 1 illustrates a cloud computing environment in which at least some of the inventive concepts may be deployed. [Figure 7] A diagram showing the components of a cloud computing environment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0032] In the context of this description, the following conventions, terms or expressions, or combinations thereof, may be used.

[0033] The term "interdependent cryptographic keys" can refer to a group of encryption / decryption / signature keys used to protect artifacts, e.g., software components, that are related to each other in parallel with the relationships of the artifacts to which the cryptographic keys are related.

[0034] The term "signed" can mean in computer science a mathematical scheme for verifying the authenticity of a digital message or document, or, in general, any data. A valid digital signature, provided that prerequisites are met, gives the recipient a very strong reason to believe that the data was created by a known sender (i.e., authentication) and that the data has not been altered in transit (i.e., integrity proof). Digital signatures are a standard element of most cryptographic protocol suites and are commonly used in software distribution, financial transactions, contract management software, and other cases where it is important to detect forgery or tampering.

[0035] The term "artifact" may mean any data or data item in a computer system that may be signed or protected by encryption. An example may be software code, training data for an AI system, a piece of documentation, or any other data related to the functioning of a computer system or user-generated data. Other examples of artifacts may include, for example, any software component in source code, object, archive, or executable form, digital images, artificial intelligence models, spreadsheets with data, text, voice and sound data, or mathematically derived digital finder prints of such data or artifacts.

[0036] The term "key manifest" may refer to data or a container for data, especially cryptographic keys, associated with artifacts related to each other. However, a key manifest may also include signatures of symmetric key pairs over at least some of the artifacts and components. In this sense, a key manifest may describe a special kind of metadata of an artifact or a digital finder print. The term "lifecycle change" may refer to any event that affects the lifecycle of an artifact, such as a construction process, a deployment step, a modification. Essentially, a lifecycle change may relate to any measurable and recordable change in the status of an artifact.

[0037] The term "action" may refer to any change or modification to an artifact or an associated key manifest at a given point in time, for example due to a given expiration or time frame.

[0038] The term "cloud computing", and similarly the more specific term "cloud service environment", may be interpreted in this context as a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with a service provider. This cloud model promotes availability and consists of at least five fundamental characteristics, three service models, and four deployment models:

[0039] The basic characteristics of cloud computing include: (i) On-Demand Self-Service. Consumers can unilaterally provision computing capacity, such as server time and network storage, automatically as needed, without the need for human interaction with the respective service provider. Pervasive Network Access. Functionality is available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin- or thick-client platforms (e.g., cell phones, laptops, and PDAs). Pooling of resources. A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated in response to consumer demand. There is location independence in that the customer generally has no control or knowledge of the exact location of the provided resources, although it may be possible to specify the location at a higher level of abstraction (e.g., country, state, or data center). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines. Rapid flexibility. Capabilities can be rapidly and flexibly provisioned, sometimes automatically, to rapidly scale out, and rapidly released to rapidly scale in. To the consumer, the capabilities available for provisioning often appear unlimited and can be purchased at any time and in any quantity. Metering of services. Cloud systems automatically control and optimize the resources they use by leveraging metering capabilities at a certain level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services they use.

[0040] Service models for cloud computing usage include: (i) Cloud Software as a Service (SaaS). The functionality provided to the consumer is the use of the provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). With the possible exception of limited user-specific application configuration settings, the consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or individual application functionality. (ii) Cloud Platform as a Service (PaaS): The functionality offered to the consumer is the deployment of applications created or acquired by the consumer, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, such as networks, servers, operating systems, or storage, but does control the deployed applications and, in some cases, the application hosting environment configuration. (iii) Cloud Infrastructure as a Service (IaaS): The functionality provided to the consumer is the provisioning of processing, storage, network, and other basic computing resources on which the consumer may deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does control the operating systems, storage, deployed applications, and in some cases has limited control over selected network components (e.g., host firewalls).

[0041] Deployment models for cloud computing include the following: (i) Private Cloud. The cloud infrastructure is operated solely by an organization. This cloud infrastructure may be managed by the organization or a third party and may reside on-premises or off-premises. (ii) Community Cloud. Cloud infrastructure is shared by multiple organizations to support a particular community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). This cloud infrastructure may be managed by the organizations or a third party and may reside on or off premises. (iii) Public Cloud. Cloud infrastructure is available to the general public or large industry groups and is owned by organizations that sell cloud services. (iv) Hybrid Cloud: A cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are tied together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0042] Note that cloud software takes full advantage of the cloud paradigm by being service-oriented with an emphasis on statelessness (with exceptions), low coupling, modularity, and semantic interoperability.

[0043] In the following, a detailed description of the figures is given. All indications in the figures are schematic. First, a block diagram of one embodiment of the computer-implemented method of the present invention for managing the life cycle of at least partially interdependent cryptographic keys is given. Thereafter, further embodiments are described, as well as an embodiment of a distributed link manifest system for managing the life cycle of interdependent cryptographic keys.

[0044] FIG. 1 shows a block diagram of a preferred embodiment of a computer-implemented method 100 for managing the lifecycle of at least partially interdependent cryptographic keys. Each of the cryptographic keys is signed and associated with a different one of the artifacts. These may be software components, or software artifacts, or keys hosted in a hardware security module. The cryptographic keys depend on each other in a "vertical" relationship. A cryptographic key may also depend on another cryptographic key in a "horizontal" relationship. A cryptographic key may also depend on another cryptographic key in a "horizontal" and "vertical" relationship. The method 100 includes creating 102 a key manifest, which specifically includes data regarding the determined dependencies of one or more of the cryptographic keys at the time one of the artifacts is built (e.g., a build step, or also a deploy step). In this sense, the key manifest is metadata for the artifacts.

[0045] The method 100 also includes encrypting 104 the key manifest with the manifest key. The key manifest should at least be signed, if not always encrypted. When a lifecycle change occurs to one of the groups that includes one of the artifacts and one of the interdependent cryptographic keys in the key manifest of one of the artifacts, the method includes decrypting 106 the key manifest and invoking 108 an action, specifically at least one action, on the associated one of the groups that includes one of the artifacts and at least one of the interdependent cryptographic keys according to the key manifest.

[0046] FIG. 2 shows a block diagram 200 illustrating how a key manifest can be integrated. Each of the artifacts 202, 206, 210 has an associated key manifest 204, 208, 212. The artifacts can also be considered as key chains, since they can be built from different components, each of which can be protected by an individual key. For ease of understanding, the artifacts can be considered as software components that are supposed to build a new software function. This is illustrated by the building block 214, which represents the software building process. The result of the building process is a new software component 216, for example a complete service or application or its pre-product, i.e., a new artifact 216. The associated key manifest 218 now includes the key chains or key manifests 204, 208, and 212 of the source or original software components 202, 206, 210.

[0047] When the protection key for one of the artifacts 202, 206, 210 undergoes a key roll or otherwise initiated rekey, the key manifest 218, or better yet, any or partial key manifests 204, 208, 212 associated with the artifact whose key is being rekeyed, must be modified as well in order to keep the key chain intact.

[0048] 3 shows a block diagram 300 illustrating the occurrence of a lifetime event and how the proposed system (or method) responds. The lifetime event is exemplarily shown here as a deployment 306 of a software component 302 having an associated key manifest 304. Thus, an instantiated or deployed or executed software component 302, e.g., a service or application, gets a modified key manifest 308, e.g., a new key manifest that includes the “old” key manifest 304.

[0049] 4 illustrates a block diagram of an embodiment of a distributed link manifest system 400 for managing the life cycle of interdependent cryptographic keys. Each of the cryptographic keys is signed and associated with a different artifact. The system includes a processor 402 and a memory 404 communicatively coupled to the processor 402, the memory 404 storing program code portions that, when executed, enable the processor 402, specifically by a creation module 406, to create a key manifest, the key manifest including data regarding the determined dependencies of the cryptographic keys at the time one of the artifacts is constructed. The processor is further enabled, specifically by an encryption unit 408, to encrypt the key manifest with a manifest key.

[0050] When a lifecycle change occurs to one of the groups that includes one of the artifacts and one of the interdependent cryptographic keys in the key manifest of one of the artifacts, the processor, or in an alternative embodiment, the hardware security module (HSM), can also decrypt the key manifest, particularly by the decryption unit 410, and invoke an action on the associated one of the groups that includes one of the artifacts and at least one of the interdependent cryptographic keys according to the key manifest, particularly using the action invocation module 412. Here, a manifest key exchange module (not shown in FIG. 4) may be useful.

[0051] It should also be noted that all the functional units, modules, and functional blocks, specifically the processor 402, memory 404, creation module 406, encryption unit 408, decryption unit 410, and invocation module 412, may be communicatively coupled to each other for signal or message exchange in a selected 1:1 manner. Alternatively, the functional units, modules, and functional blocks may be linked to a system internal bus system 414 for selective signal or message exchange. It should also be noted that the encryption unit 408 and the decryption unit 410 may be combined into one joint encryption / decryption unit, e.g., a hardware security module. It should also be noted that the distributed link manifest system 400 may be communicatively coupled in whole or in part to another instance of the distributed link manifest system 400 for signal or message exchange in a selected 1:1 manner.

[0052] Embodiments of the present invention may be implemented with virtually any type of computer, regardless of the platform suitable for storing and / or executing the program code. Figure 5 illustrates, by way of example, a computing system 700 suitable for executing program code associated with the proposed method.

[0053] Computing system 500 is only one example of a suitable computer system, and whether or not computer system 500 is capable of implementing and / or performing any of the functionality described herein is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the invention described herein. There are components of computer system 500 that are operable in numerous other general purpose or special purpose computing system environments or computing system configurations. Examples of well-known computing systems, computing environments, or computing configurations, or combinations thereof, that may be suitable for use with computer system / server 500 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices. The computer system / server 500 may be described in the general context of computer system executable instructions, such as program modules, executed by the computer system 500. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system / server 500 may be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.

[0054] As shown, computer system / server 500 is shown in the form of a general-purpose computing device. Components of computer system / server 500 may include, but are not limited to, one or more processors or processing units 502, a system memory 504, and a bus 506 coupling various system components including system memory 504 to processor 502. Bus 506 represents any one or more of several types of bus structures including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standard Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus. Computer system / server 500 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system / server 500 and includes both volatile and non-volatile media, removable and non-removable media.

[0055] The system memory 504 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 508 and / or cache memory 510. The computer system / server 500 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 512 may be provided for reading from and writing to a non-removable, non-volatile magnetic medium (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive may be provided for reading from and writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical medium. In such a case, each may be connected to the bus 506 by one or more data media interfaces. As further illustrated and described below, the memory 504 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of an embodiment of the present invention.

[0056] A program / utility having a set (at least one) of program modules 516 may be stored in memory 504, as well as, by way of example and not limitation, an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, may include an implementation of a networking environment. The program modules 516 generally perform the functions and / or methodologies of embodiments of the present invention as described herein.

[0057] The computer system / server 500 may also communicate with one or more external devices 518, such as a keyboard, a pointing device, a display 520, one or more devices that allow a user to interact with the computer system / server 500, or any device that allows the computer system / server 500 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.), or a combination thereof. Such communication may occur through an input / output (I / O) interface 514. Additionally, the computer system / server 500 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, through a network adapter 522. As shown, the network adapter 522 may communicate with other components of the computer system / server 500 through a bus 506. Although not shown, it is understood that other hardware and / or software components may be used with the computer system / server 500. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0058] Additionally, a distributed link manifest system 400 for managing the lifecycle of interdependent cryptographic keys may be attached to the bus system 506 .

[0059] FIG. 6 illustrates a cloud computing environment 600 in which at least some of the concepts of the present invention may be deployed. A set of functional abstraction layers provided by the cloud computing environment is illustrated. It should be understood in advance that the components, layers, and functions illustrated in FIG. 6 are for illustrative purposes only, and the embodiments of the present invention are not limited thereto. As illustrated, the following layers and corresponding functions are provided: Hardware and software layer 602 includes hardware components and software components. Examples of hardware components include mainframe 604, server 606, RISC (reduced instruction set computer) architecture-based server 608, blade server 610, storage device 612, network 614, and networking components 614. In some embodiments, the software components include network application server software 616 and / or database software 618.

[0060] The virtualization layer 620 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 622, virtual storage 624, virtual networks including virtual private networks 626, virtual applications and operating systems 628, and virtual clients 630. In one example, the management layer 632 may provide the functionality described below. Resource provisioning 634 provides dynamic procurement of computational and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 636 provides cost tracking as resources are utilized within the cloud computing environment, and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. A user portal 638 provides consumers and system administrators with access to the cloud computing environment. Service level management 640 provides allocation and management of cloud computational resources such that requested service levels are met. Service Level Agreement (SLA) Planning and Fulfillment 642 provides for the pre-allocation and procurement of cloud computing resources anticipated to be required in the future according to the SLA.

[0061] The workload layer 644 provides examples of functions for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this layer include mapping and navigation 646, software development and lifecycle management 648, virtual classroom instructional delivery 650, data analytics processing 652, transaction processing 654, and other endpoint services or systems such as a distributed link manifest system 656 (compare also 400 in FIG. 4).

[0062] FIG. 7 illustrates components 700 of a cloud computing environment 702. As illustrated, the cloud computing environment 702 includes one or more cloud computing nodes 704 with which a local computing device used by a cloud consumer, such as a personal digital assistant (PDA) or mobile phone 706, a desktop computer 708, a laptop computer 710, or an automobile computer system 712, or any combination thereof, can communicate. The nodes 704 can communicate with each other. The nodes 704 can be physically or virtually grouped in one or more networks, such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or any combination thereof, as described above (not shown). This enables the cloud computing environment 702 to provide infrastructure, platform, and / or software as a service without the cloud consumer having to maintain resources on a local computing device. It will be understood that the types of computing devices 704 shown in FIG. 7 are for illustrative purposes only, and that the computing nodes 704 and cloud computing environment 702 can communicate with any type of computerized device over any type of network and / or network addressable connections (e.g., using a web browser).

[0063] The description of various embodiments of the present invention is presented for illustrative purposes and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used in this specification are selected to best explain the principles of the embodiments, practical applications, or technical improvements to the technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed in this specification.

[0064] The present invention may be embodied as a system, method, and / or computer program product, which may include a computer readable storage medium (or multiple computer readable storage media) having computer readable program instructions for causing a processor to perform aspects of the present invention.

[0065] The computer-readable storage medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system for a propagation medium. Examples of computer-readable media may include semiconductor or solid-state memory, magnetic tape, removable computer diskettes, random access memory (RAM), read-only memory (ROM), rigid magnetic disk, and optical disk. Current examples of optical disks include read-only memory compact disks (CD-ROM), read / write compact disks (CD-R / W), DVDs, and Blu-ray disks.

[0066] A computer readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable read-only memory compact disks (CD-ROMs), digital versatile disks (DVDs), memory sticks, floppy disks, punch cards or mechanically encoded devices such as raised structures in grooves with instructions recorded thereon, and any suitable combination of the above. As used herein, a computer-readable storage medium should not be construed as a transitory signal per se, such as electric waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses through a fiber optic cable), or electrical signals transmitted over electrical wires.

[0067] The computer readable program instructions described herein may be downloaded from a computer readable storage medium to the respective computing / processing device or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0068] The computer readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including object oriented programming languages ​​such as Smalltalk, C++, and traditional procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer as a stand-alone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer readable program instructions to perform aspects of the invention by utilizing state information of the computer readable program instructions to personalize the electronic circuitry.

[0069] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0070] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, produce means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer readable program instructions may also be stored on a computer readable medium, such that the computer readable storage medium on which the instructions are stored includes an article of manufacture including instructions implementing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams, and can direct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner.

[0071] The computer readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or another device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to create a computer-implemented process such that the instructions, which execute on the computer, other programmable apparatus, or another device, perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0072] The flowcharts and / or block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously or the blocks may be executed in reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that performs the specified functions or actions or a combination of dedicated hardware and computer instructions.

[0073] The terms used herein are for the purpose of describing particular embodiments only and are not intended to be limiting of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms unless the context clearly dictates otherwise. It will be further understood that the terms "comprises" and / or "comprising", as used herein, indicate the presence of stated features, integers, steps, operations, elements, or components or combinations thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, or combinations thereof.

[0074] The corresponding structures, materials, acts, and equivalents of all means or steps and functional elements within the scope of the appended claims are intended to include any structure, material, or act for performing a function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or to limit the invention to the disclosed form. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the invention. The embodiments have been selected and described in order to best explain the principles and practical applications of the invention, and to enable those skilled in the art to understand the invention in various embodiments with various modifications suitable for the particular use contemplated.

[0075] Briefly, the inventive concept may be summarized by the following clauses. 1. A computer-implemented method for managing the lifecycle of at least partially interdependent cryptographic keys, each of which is signed and associated with a different one of the artifacts, the method comprising: - creating a key manifest, the key manifest including data regarding determined dependencies of cryptographic keys at the time one of the artifacts is constructed; - encrypting the key manifest with a manifest key; - When a lifecycle change occurs in one of the groups that includes one of the artifacts and one of the interdependent cryptographic keys in the key manifest of one of the artifacts, - Decrypting the key manifest; - invoking an action on an associated one of the groups that includes one of the artifacts and at least one of the interdependent cryptographic keys according to the key manifest; 4. A computer-implemented method comprising: 2. The method of clause 1, wherein the artefact is encrypted. 3. The method of claim 1 or 2, wherein the manifest key encrypts only a portion of the key manifest. 4. The action is - A method as described in any of the preceding clauses, including creating a new key. 5. A method according to any of the preceding clauses in which the action on the artefact is constructing or modifying the artefact, or deploying the artefact. 6. The method of any of the preceding clauses, wherein the action on at least one of the interdependent cryptographic keys is a change of one of the interdependent cryptographic keys. 7. The method of any of the preceding clauses, wherein the lifecycle change is the expiration or revocation of one of the dependent cryptographic keys or key manifests. 8. The method of any of the preceding clauses, wherein an action on at least one interdependent cryptographic key includes encrypting or decrypting data, and the resulting key manifest includes a reference to the data. 9. The method according to any of the preceding clauses, wherein the key manifest is a combination of a plurality of key manifests. 10. A method as described in any of the preceding clauses, wherein the key manifest includes a certificate used to validate the relying key manifest. 11. The method of any of the preceding clauses, wherein each of the interdependent cryptographic keys is selected from a group including login credentials, API tokens, and keys protected by a hardware security module. 12. A distributed link manifest system for managing the lifecycle of interdependent cryptographic keys, each of which is signed and associated with a different one of the artifacts, the system comprising: A processor and a memory communicatively coupled to the processor, the memory being configured to cause the processor, when executed, to: creating a key manifest, the key manifest including data regarding determined dependencies of cryptographic keys at the time one of the artifacts is constructed; encrypting the key manifest with a manifest key; When a lifecycle change occurs in a group that includes one of the artifacts and one of the interdependent cryptographic keys in the key manifest of one of the artifacts, Decrypting the key manifest; Invoking an action on an associated one of the groups that includes one of the artifacts and at least one of the interdependent cryptographic keys according to the key manifest; A distributed link manifest system for storing program code portions that enable 13. The system of claim 12, wherein the artifact is encrypted. 14. The system of claim 12 or 13, wherein the manifest key encrypts only a portion of the key manifest. 15. Action, - A system according to any of clauses 12 to 14, comprising generating a new key. 16. A system according to any of clauses 12 to 15, wherein the action on the artefact is constructing or modifying the artefact, or deploying the artefact. 17. A system according to any of clauses 12 to 16, wherein the action on at least one of the interdependent cryptographic keys is a change to one of the interdependent cryptographic keys. 18. The system of any of clauses 12 to 17, wherein the lifecycle change is the expiration or revocation of one of the dependent cryptographic keys or key manifests. 19. The system of any of clauses 12 to 18, wherein an action on at least one interdependent cryptographic key includes encrypting or decrypting data, and the resulting key manifest includes a reference to the data. 20. A computer program product for managing the lifecycle of interdependent cryptographic keys, each of the cryptographic keys being signed and associated with a different one of the artifacts, the computer program product comprising a computer readable storage medium having program instructions embodied therein, the program instructions being executable by one or more computing systems or controllers, the one or more computing systems being configured to: - creating a key manifest, the key manifest including data regarding determined dependencies of cryptographic keys at the time one of the artifacts is constructed; - encrypting the key manifest with a manifest key; - When a lifecycle change occurs in one of the groups that includes one of the artifacts and one of the interdependent cryptographic keys in the key manifest of one of the artifacts, - Decrypting the key manifest; - invoking an action on an associated one of the groups that includes one of the artifacts and at least one of the interdependent cryptographic keys according to the key manifest; A computer program product that causes the

Claims

1. 1. A computer-implemented method for managing a lifecycle of at least partially interdependent cryptographic keys, each of which is signed and associated with a different one of artifacts, the method comprising: creating a key manifest, the key manifest including data regarding determined dependencies of the cryptographic keys at the time one of the artifacts is constructed; encrypting the key manifest with a manifest key; when a lifecycle change occurs to one of a group that includes one of the artifacts and one of the interdependent cryptographic keys in the key manifest of the one of the artifacts; decrypting the key manifest; invoking an action on an associated one of the groups including the one of the artifacts and at least one of the interdependent cryptographic keys according to the key manifest; 4. A computer-implemented method comprising:

2. The method of claim 1 , wherein the artifact is encrypted.

3. The method of claim 1 or 2, wherein the manifest key encrypts only a portion of the key manifest.

4. The action is 4. A method according to any one of claims 1 to 3, comprising creating a new key.

5. The method of claim 1 , wherein the action on the artefact is building or modifying the artefact or evolving the artefact.

6. The method of claim 1 , wherein the action on the at least one of the interdependent cryptographic keys is a change of the one of the interdependent cryptographic keys.

7. The method of claim 1 , wherein the lifecycle change is the expiration or revocation of one of the dependent cryptographic keys or the key manifest.

8. 8. The method of claim 1, wherein the action on the at least one interdependent cryptographic key includes encrypting or decrypting data, and the resulting key manifest includes a reference to the data.

9. The method of claim 1 , wherein the key manifest is a combination of multiple key manifests.

10. 10. The method of claim 9, wherein the key manifest includes certificates used to validate dependent key manifests.

11. 11. The method of claim 1, wherein each of the interdependent cryptographic keys is selected from a group including login credentials, API tokens, and keys protected by a hardware security module.

12. 1. A distributed link manifest system for managing the lifecycle of interdependent cryptographic keys, each of the cryptographic keys being signed and associated with a different one of the artifacts, the system comprising: and a memory communicatively coupled to the processor, the memory being configured to, when executed, cause the processor to: creating a key manifest, the key manifest including data regarding determined dependencies of the cryptographic keys at the time one of the artifacts is constructed; encrypting the key manifest with a manifest key; when a lifecycle change occurs to one of a group that includes one of the artifacts and one of the interdependent cryptographic keys in the key manifest of the one of the artifacts; decrypting the key manifest; invoking an action on an associated one of the groups including the one of the artifacts and at least one of the interdependent cryptographic keys according to the key manifest; A distributed link manifest system that stores program code portions that enable the above.

13. The system of claim 12 , wherein the artifact is encrypted.

14. 14. The system of claim 12 or 13, wherein the manifest key encrypts only a portion of the key manifest.

15. The action is 15. A system as claimed in any one of claims 12 to 14, including generating new keys.

16. The system of claim 12 , wherein the action on the artefact is building or modifying the artefact or deploying the artefact.

17. 17. The system of claim 12, wherein the action on the at least one of the interdependent cryptographic keys is a change of the one of the interdependent cryptographic keys.

18. 18. The system of claim 12, wherein the lifecycle change is the expiration or revocation of one of the dependent cryptographic keys or the key manifest.

19. 19. The system of claim 12, wherein the action on the at least one interdependent cryptographic key includes encrypting or decrypting data, and the resulting key manifest includes a reference to the data.

20. 1. A computer program product for managing a lifecycle of interdependent cryptographic keys, each of the cryptographic keys being signed and associated with a different one of artifacts, the computer program product comprising a computer readable storage medium having program instructions embodied therein, the program instructions being executable by one or more computing systems or controllers, the one or more computing systems being configured to: creating a key manifest, the key manifest including data regarding determined dependencies of the cryptographic keys at the time one of the artifacts is constructed; encrypting the key manifest with a manifest key; when a lifecycle change occurs to one of a group that includes one of the artifacts and one of the interdependent cryptographic keys in the key manifest of the one of the artifacts; decrypting the key manifest; invoking an action on an associated one of the groups including the one of the artifacts and at least one of the interdependent cryptographic keys according to the key manifest; A computer program product that causes a program to execute the above.

Images