Deployment of Components of a Distributed Application to Runtime Environments

Abstract

There is provided mechanisms for deployment of components of a distributed application on destination runtime environments. A method is performed by a source runtime environment. The method comprises providing, with the components residing on the source runtime environment, public key fingerprints between the components, such that each component has its own public key and its own private key and is provided with a public key fingerprint of at least one other of the components. The method comprises providing migrating each of the components from the source runtime environment to its destination runtime environment for deployment of each component on its destination runtime environment.

Description

TECHNICAL FIELD

Embodiments presented herein relate to a method, a runtime environment, a computer program, and a computer program product for deployment of components of a distributed application on destination runtime environments. Embodiments presented herein further relate to a method, a system, a computer program, and a computer program product for facilitating exchange of public key fingerprints between the components.

BACKGROUND

In communications networks, there could be a challenge to obtain good performance and capacity for a given communications protocol, its parameters and the physical environment in which the communications network is deployed.

A runtime environment can allow application components to be deployed distributed over several devices, where each device comprises a runtime environment. Examples of devices range from network equipment, such as radio access network nodes, core network nodes, service network nodes, to machine-type communication (MTC) devices or Internet-of-Thing (IoT) devices.

In general terms, the components can be regarded as parts of a distributed application that communicate with messages. Each component might have conditions to guide placement of the component on a runtime environment. Runtime environments have attributes that describe the runtime environment functionality as well as other information.

When deploying the components of the distributed application to runtime environments, there are three dominant common practices, or protocols for establishing network security trust among the components.

According to a first example, Pre Shared Key (PSK) Secret(s) for encryption and validation are provided to, and shared among, all the components of the distributed application.

According to a second example, a Certificate Authority (CA) document containing the certificate authority names and keys that authorizes component identities is pre-provisioned to the components.

According to a third example the components trust their peers on first connection and store the key finger print after first use. This practice is commonly referred to as Trust on First Use (TOFU) and might be used to create bootstrap security from factory installed devices.

The above mentioned practices for deploying the components of the distributed application to runtime environments are either tied to one single network domain or make naive assumptions when establishing the network security trust.

The shared keys allow any holder of the shared keys to manipulate data from any other member (in the present case: component) of the network.

Further, TOFU in itself depends on trusting the network on the first connection between two components. Deployment based on TOFU only protocols are thus prone to man in the middle attacks on the first connection.

CA only protocols create networks that are prone to attacks where one CA is compromised by an attacker and where the compromised CA starts signing overlapping or false certificates.

PSK based protocols tend to be promiscuous and non-distinguishing between identities as all components share the same secrets. Therefore, networks built on PSK based protocols cannot defend themselves from inside attacks.

Hence, there is still a need for improved mechanisms for establishing network security trust among components when deploying the components of a distributed application to runtime environments.

SUMMARY

An object of embodiments herein is to provide efficient deployment of components of a distributed application to runtime environments.

According to a first aspect there is presented a method for deployment of components of a distributed application on destination runtime environments. The method is performed by a source runtime environment. The method comprises providing, with the components residing on the source runtime environment, public key fingerprints between the components, such that each component has its own public key and its own private key and is provided with a public key fingerprint of at least one other of the components. The method comprises providing migrating each of the components from the source runtime environment to its destination runtime environment for deployment of each component on its destination runtime environment.

According to a second aspect there is presented a runtime environment for deployment of components of a distributed application on destination runtime environments. The runtime environment comprises processing circuitry. The processing circuitry is configured to cause the runtime environment to provide, with the components residing on the runtime environment, public key fingerprints between the components, such that each component has its own public key and its own private key and is provided with a public key fingerprint of at least one other of the components. The processing circuitry is configured to cause the runtime environment to migrate each of the components from the runtime environment to its destination runtime environment for deployment of each component on its destination runtime environment.

According to a third aspect there is presented a runtime environment for deployment of components of a distributed application on destination runtime environments. The runtime environment comprises a provide module configured to provide, with the components residing on the runtime environment, public key fingerprints between the components, such that each component has its own public key and its own private key and is provided with a public key fingerprint of at least one other of the components. The runtime environment comprises a migrate module configured to migrate each of the components from the runtime environment to its destination runtime environment for deployment of each component on its destination runtime environment.

According to a fourth aspect there is presented a computer program for deployment of components of a distributed application on destination runtime environments, the computer program comprising computer program code which, when run on processing circuitry of a runtime environment, causes the runtime environment to perform a method according to the first aspect.

According to a fifth aspect there is presented a method for facilitating exchange of public key fingerprints between components of a distributed application, each component having its own public key and its own private key. The method is performed by one of the components. The method comprises obtaining, when being in the same trusted network environment as the other components, a public key fingerprint of at least one of the other components before being migrated to a destination runtime environment for deployment of the component on the destination runtime environment.

According to a sixth aspect there is presented a system for facilitating exchange of public key fingerprints between components of a distributed application, each component having its own public key and its own private key. The system comprises processing circuitry. The processing circuitry is configured to cause one of the components to obtain, when the component is in the same trusted network environment as the other components, a public key fingerprint of at least one of the other components before being migrated to a destination runtime environment for deployment of the component on the destination runtime environment.

According to a seventh aspect there is presented a system for facilitating exchange of public key fingerprints between components of a distributed application, each component having its own public key and its own private key. The system comprises an obtain module configured to cause one of the components to obtain, when the component is in the same trusted network environment as the other components, a public key fingerprint of at least one of the other components before being migrated to a destination runtime environment for deployment of the component on the destination runtime environment.

According to an embodiment the system according to the sixth aspect and/or the sevenths aspect is part of the runtime environment according to the second aspect and/or the third aspect.

According to an eight aspect there is presented a computer program for facilitating exchange of public key fingerprints between components of a distributed application, the computer program comprising computer program code which, when run on processing circuitry of a system, causes one of the components to obtain, when the component is in the same trusted network environment as the other components, a public key fingerprint of at least one of the other components before being migrated to a destination runtime environment for deployment of the component on the destination runtime environment.

According to a ninth aspect there is presented a computer program product comprising a computer program according to at least one of the fourth aspect and the eight aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium could be a non-transitory computer readable storage medium.

Advantageously these methods, these runtime environments, these systems, and these computer programs provide efficient deployment of the components of the distributed application to the destination runtime environments.

Advantageously these methods, these runtime environments, these systems, and these computer programs establish network security trust among the components in an efficient manner when deploying the components of the distributed application to the destination runtime environments.

Advantageously these methods, these runtime environments, these systems, and these computer programs combine the strengths for CA, PSK and TOFU based protocols without attaching its weaknesses.

Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings.

Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to “a/an/the element, apparatus, component, means, module, step, etc.” are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, module, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which:

FIG. 1 is a schematic diagram illustrating a communication network according to embodiments;

FIGS. 2 and 3 are flowcharts of methods according to embodiments;

FIG. 4 is a schematic illustration of runtime environments according to an embodiment;

FIG. 5 is a schematic diagram showing functional units of a runtime environment according to an embodiment;

FIG. 6 is a schematic diagram showing functional modules of a runtime environment according to an embodiment;

FIG. 7 is a schematic diagram showing functional units of a system according to an embodiment;

FIG. 8 is a schematic diagram showing functional modules of a system according to an embodiment; and

FIG. 9 shows one example of a computer program product comprising computer readable means according to an embodiment.

DETAILED DESCRIPTION

The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown. This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any step or feature illustrated by dashed lines should be regarded as optional.

FIG. 1 schematically illustrates a communications network 100. The communications network 100 comprises three entities (Entity 1, Entity 2, Entity 3) 110a, 110b, 110c, representing any combination of devices, compute nodes, and storage nodes. Each entity 110a, 110b, 110c may have its own hardware (HW) and may have its own operating system (OS). Alternatively, hardware and/or operating system is shared among at least two of the entities 110a, 110b, 110c.

The entities 110a, 110b, 110c host at least one application 120 distributed among the entities 110a, 110b, 110c. The application 120 is transparently distributed across the communications network 100 and comprises components 130a, 130b, 130c. In some aspects the components 130a, 130b, 130c are actors. The components 130a, 130b, 130c may access a resource object 140 by means of at least one of the runtime environments 200a, 200b, 200c. Each resource object 160 could be a file system, a sensor, an actuator, a network interface, etc., that access is provided to by the runtime environments 200a, 200b, 200c The communications network 100 further comprises a distributed execution environment 140 formed by a set of networks of runtime environments 200a, 200b, 200c, seen by the application 120 as a single platform. There is not a one-to-one mapping between components 130a, 130b, 130c and entities 110a, 110b, 110c although it is hereinafter assumed for simplicity that one component 130a, 130b, 130c is run on each runtime environment 200a, 200b, 200c.

Issues with common practices for deploying the components 130a, 130b, 130c of the distributed application 120 to its runtime environment 200a, 200b, 200c have been disclosed above. The herein disclosed embodiments address these issues by being related to mechanisms for deployment of components 130a, 130b, 130c of a distributed application 120 on destination runtime environments 200b, 200c and facilitating exchange of public key fingerprints between the components 130a, 130b, 130c. In order to obtain such mechanisms there is provided a runtime environment 200a, a method performed by the runtime environment 200a, a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the runtime environment 200a, causes the runtime environment 200a to perform the method. In order to obtain such mechanisms there is further provided a system 300, a method performed by the system 300, and a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the system 300, causes one of the components 130a, 130b, 130v to perform the method.

Reference is now made to FIG. 2 illustrating a method for deployment of components 130a, 130b, 130c of a distributed application 120 on runtime environments 200b, 200c hereinafter denoted destination runtime environments 200b, 200c. The method is performed by the runtime environment 200a. The runtime environment 200a will hereinafter be denoted a source runtime environment 200a so as to logically separate runtime environment 200a from runtime environments 200b, 200c.

When deploying components 130a, 130b, 130c of a distributed application 120, all components 130a, 130b, 130c are initially deployed to the same, trusted, runtime environment, i.e. the source runtime environment 200a. Here, the components 130a, 130b, 130c might exchange keys, sensitive data, etc., as necessary. Particularly, the source runtime environment 200a is configured to perform step S102:

S102: The source runtime environment 200a provides, with the components 130a, 130b, 130c residing on the source runtime environment 200a, public key fingerprints between the components 130a, 130b, 130c. Each component 130a, 130b, 130c has its own public key and its own private key and is provided with a public key fingerprint of at least one other of the components 130a, 130b, 130c.

The components 130a, 130b, 130c might then be migrated to their respective places, with the secrets in their internal state. Particularly, the source runtime environment 200a is configured to perform step S104:

S104: The source runtime environment 200a migrates each of the components 130a, 130b, 130c from the source runtime environment 200a to its destination runtime environment 200b, 200c for deployment of each component 130a, 130b, 130c on its destination runtime environment 200b, 200c.

Once the components 130a, 130b, 130c have reached their final destination i.e. its respective destination runtime environment 200b, 200c, the components 130a, 130b, 130c resume operation, using the exchanged information. It is noted that it is possible that, at a later stage, one or more of the components 130a, 130b, 130c are migrated from the destination runtime environments 200b, 200c they were migrated to in step S104 to respective other destination runtime environments.

All components 130a, 130b, 130c are thus first deployed to the same source runtime environment 200a, where they are provided with public key fingerprints. The components 130a, 130b, 130c are then migrated to their destination runtime environments 200b, 200c, bringing the keys and fingerprints with them.

As disclosed above, the proposed method combines the strengths for CA, PSK and TOFU based protocols without attaching its weaknesses. In more detail, the pre-distribution of public key fingerprints on multiple components (as in step S102) give the possibility of only allowing connections between intended endpoints in a distributed environment. While PSK based protocols lack granularity, the proposed method specifically distributes the public key fingerprints to components 130a, 130b, 130c intended to communicate with each other. While CA based protocols provide dynamic assignments of new certificates for alteration of a network, the proposed method provides a static security where a compromised CA cannot interrupt communication or insert false components in the network during its execution. As the public key fingerprint identifying each endpoint of this network of components are pre-distributed in a trusted environment, any initial exchange of keys, fingerprints, configurations and secrets between the components 130a, 130b, 130c does not cause vulnerability to man in the middle attacks.

Embodiments relating to further details of deployment of components 130a, 130b, 130c of a distributed application 120 on destination runtime environments 200b, 200c as performed by the runtime environment 200a will now be disclosed.

There could be different ways for the private keys, the public keys, and the public key fingerprints to be generated.

In some aspects, the keys and fingerprints are generated outside the components 130a, 130b, 130c and injected into the components 130a, 130b, 130c by the source runtime environment 200a. Particularly, according to an embodiment the private keys, the public keys, and the public key fingerprints are generated outside the components 130a, 130b, 130c, and the source runtime environment 200a is configured to perform (optional) step S102a:

S102a: The source runtime environment 200a injects the private keys, the public keys, and the public key fingerprints into the components 130a, 130b, 130c.

Step S102a is in some aspects performed as part of step S102.

There could be different points in time the lifespan of the components 130a, 130b, 130c as to when the private keys, the public keys, and the public key fingerprints are injected into the components 130a, 130b, 130c. In some aspects the private keys, the public keys, and the public key fingerprints are injected into the components 130a, 130b, 130c as part of compilation of the distributed application 120 and/or the components 130a, 130b, 130c themselves. In other aspects the public keys, and the public key fingerprints are injected into the components 130a, 130b, 130c after such compilation.

When the keys and fingerprints are generated outside the components 130a, 130b, 130c, the keys and fingerprints might be generated by the source runtime environment 200a itself or outside the source runtime environment 200a. That is, according to an embodiment the private keys, the public keys, and the public key fingerprints are generated either by the source runtime environment 200a or outside the source runtime environment 200a and obtained by the source runtime environment 200a.

In some aspects, the keys and fingerprints are generated by the components 130a, 130b, 130c themselves and distributed by the source runtime environment 200a. Particularly, according to an embodiment the private keys, the public keys, and the public key fingerprints are generated by the components 130a, 130b, 130c, and the source runtime environment 200a is configured to perform (optional) step S102b:

S102b: The source runtime environment 200a distributes the public key fingerprint of each of the components 130a, 130b, 130c to at least one other of the components 130a, 130b, 130c.

Step S102b is in some aspects performed as part of step S102.

In some aspects, the components 130a, 130b, 130c are to, according to the application 120, communicate with each other over connection paths. In some aspects the source runtime environment 200a therefore identifies all connection paths between the components 130a, 130b, 130c for the given application 120. Particularly, according to an embodiment the components 130a, 130b, 130c are configured (e.g. by the application 120) to communicate with each other according to at least one connection path, where the at least one connection path defines a network topology.

For each connection path the source and destination public key fingerprints might then be provisioned, by means of the source runtime environment 200a, from the source component 130a, 130b, 130c to the destination component 130a, 130b, 130c and vice versa. Particularly, according to an embodiment the public key fingerprints are distributed in accordance with the network topology such that there are two public key fingerprints per connection path.

The components 130a, 130b, 130c might, by means of the source runtime environment 200a, be equipped with the key fingerprint of all intended connections. Particularly, according to an embodiment the public key fingerprints are distributed such that there is one public key fingerprint at each end of each connection path, with each public key fingerprint of the component 130a, 130b, 130c at one end of a given connection path corresponding to the public key of the component 130a, 130b, 130c at the opposite end of the given connection path.

In some aspects, the public keys are signed before the components 130a, 130b, 130c are migrated. Particularly, according to an embodiment each of the public keys is signed by a trusted agent before each of the components 130a, 130b, 130c is migrated to its destination runtime environment 200b, 200c. Non-limiting examples of trust agents include, but are not limited to, certificate authorities (CAs), block chains, etc.

In some aspects, the components 130a, 130b, 130c exchange configurations, and/or secrets while residing on the source runtime environment 200a. Therefore, according to an embodiment the source runtime environment 200a is configured to perform (optional) step S102c:

S102c: The source runtime environment 200a manages, with the components 130a, 130b, 130c residing on the source runtime environment 200a, exchange of at least one of configuration information and data between the components 130a, 130b, 130c.

Step S102c is in some aspects performed as part of step S102.

In some aspects, the procedure of provisioning public key fingerprints to the components 130a, 130b, 130c is repeated.

There could be different ways to repeat the provisioning public key fingerprints to the components 130a, 130b, 130c.

In some aspects, the procedure is repeated for the same fingerprints. Particularly, according to an embodiment each of the components 130a, 130b, 130c is re-migrated back to the source runtime environment 200a for re-provisioning of the public key fingerprints before being migrated to a set of destination runtime environments (200b, 200c).

In some aspects, the procedure is repeated for new fingerprints. Particularly, according to an embodiment each of the components 130a, 130b, 130c is re-migrated back to the source runtime environment 200a for provisioning of new public key fingerprints before being migrated to a set of destination runtime environments 200b, 200c.

In this respect, all or some of the components 130a, 130b, 130c might be migrated back to the same destination runtime environments 200b, 200c as they were migrated to in step S104. Further, all or some of the components 130a, 130b, 130c might be migrated to different destination runtime environments 200b, 200c than those they were migrated to in step S104.

In some aspects the procedure is repeated periodically. Particularly, according to an embodiment each of the components 130a, 130b, 130c is periodically re-migrated back to the source runtime environment 200a.

In some aspects, the procedure is repeated upon need. That is, in some aspects an event issued by one of the components 130a, 130b, 130c triggers the components 130a, 130b, 130c to be re-migrated back to the source runtime environment 200a.

Reference is now made to FIG. 3 illustrating a method for facilitating exchange of public key fingerprints between components 130a, 130b, 130c of a distributed application 120. Each component 130a, 130b, 130c has its own public key and its own private key. In some aspects, the system 300 is configured to cause one of the components 130a to perform the method.

S204a: The component 130a obtains, when being in the same trusted network environment as the other components 130b, 130c, a public key fingerprint of at least one of the other components 130b, 130c before being migrated to a destination runtime environment 200b, 200c for deployment of the component 130a on the destination runtime environment 200b, 200c.

Embodiments relating to further details of facilitating exchange of public key fingerprints between components 130a, 130b, 130c of a distributed application 120 will now be disclosed.

As disclosed above, there could be different ways for the private keys, the public keys, and the public key fingerprints to be generated.

As further disclosed above, in some aspects, the keys and fingerprints are generated outside the components 130a, 130b, 130c and injected into the components 130a, 130b, 130c by the source runtime environment 200a (acting as trusted network environment). Particularly, according to an embodiment the system 300 is configured to cause the component 130a to perform (optional) step S202:

S202: The component 130a obtains the private key, the public key, and the public key fingerprint from the trusted network environment.

As further disclosed above, in some aspects, the keys and fingerprints are generated by the components 130a, 130b, 130c themselves and distributed by the source runtime environment 200a (acting as trusted network environment). Particularly, according to an embodiment the system 300 is configured to cause the component 130a to perform (optional) step S204c:

S204c: The component 130a provides at least the public key fingerprint to the trusted network environment for distribution to at least one other of the components 130b, 130c.

In some aspects, the component 130a provides its own public key fingerprint to at least one of the other components 130b, 130c. Particularly, according to an embodiment the system 300 is configured to cause the component 130a to perform (optional) step S204b:

S204b: The component 130a provides, when being in the same trusted network environment as the other components 130b, 130c, the public key fingerprint of the components 130a to the at least one of the other components 130b, 130c before being migrated to the destination runtime environment 200b, 200c.

There could be different examples of trusted network environments. According to an embodiment the trusted network environment is the source runtime environment 200a. According to another embodiment the trusted network environment consists of a subset of runtime environments that are securely linked together through secure communication channels using Transport Layer Security (TLS), Internet Protocol security (IPsec) or other secure communication protocols.

The component 130a, 130b, 130c might, as part of establishing trusted endpoint connections, verify the public key fingerprints. Thus, in some aspects, the public key fingerprint is used by the component 130a when establishing a trusted connection to another component 130b, 130c. Particularly, according to an embodiment the system 300 is configured to cause the component 130a to perform (optional) step S206 when the component 130a is deployed on its destination runtime environment 200b, 200c:

S206: The component 130a establishes a trusted connection to at least one of the other components 130b, 130c by receiving the public key of each of the at least one of the other components 130b, 130c and verifying the received public key to its corresponding public key fingerprint.

It is here thus implicitly assumed that the component 130a has obtained, as in step S202a, the public key fingerprint of each component 130b, 130c the trusted connection is to be established to.

As disclosed above, in some aspects, the procedure of provisioning public key fingerprints to the components 130a, 130b, 130c is repeated.

There could be different ways to repeat the provisioning public key fingerprints to the components 130a, 130b, 130c

In some aspects, the procedure is repeated for the same public key fingerprint and the same trusted network environment. Particularly, according to an embodiment the component 130a is re-migrated back to the trusted network environment for again obtaining the public key fingerprint of the at least one of the other components 130b, 130c before being migrated to a destination runtime environment 200b, 200c.

In some aspects, the procedure is repeated for a new public key fingerprint and the same trusted network environment. Particularly, according to an embodiment the component 130a is re-migrated back to the trusted network environment for obtaining a new public key fingerprint of the at least one of the other components 130b, 130c before being migrated to a destination runtime environment 200b, 200c.

In some aspects, the procedure is repeated for the same public key fingerprint and another trusted network environment. Particularly, according to an embodiment the component 130a is migrated to another trusted network environment for again obtaining the public key fingerprint of the at least one of the other components 130b, 130c before being migrated to a destination runtime environment 200b, 200c.

In some aspects the procedure is repeated for a new public key fingerprint and another trusted network environment. Particularly, according to an embodiment the component 130a is migrated to another trusted network environment for obtaining a new public key fingerprint of the at least one of the other components 130b, 130c before being migrated to a destination runtime environment 200b, 200c.

In this respect the component 130a might be migrated back to the same destination runtime environment 200b, 200c as it was initially migrated to. Alternatively, the components 130a might be migrated to a different destination runtime environment 200b, 200c than that it was initially migrated to.

Although the above embodiments have, for illustrative purposes, differentiated between source runtime environment 200a and destination runtime environment 200b, 200c, each of the runtime environments 200a, 200b, 200b might simultaneously act as both a source runtime environment and destination runtime environment and one of the components might thus be migrated from a given runtime environment to the same given runtime environment. In other words, in some aspects, one of the components stays on one of the runtime environments. The term migrated should thus be interpreted broadly in this respect. In other words, the destination runtime environment 200b, 200c for one of the components could be identical to the source runtime environment 200a for that component.

One particular embodiment for deployment of components 130a, 130b, 130c of a distributed application 120 on destination runtime environments 200b, 200c based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to FIG. 4.

As in FIG. 4(a), all components 130a, 130b, 130c are initially deployed to the same, trusted, source runtime environment 200a. The source runtime environment 200a identifies all known connection paths 410a, 410b for the given distributed application 120 between all the components 130a, 130b, 130c. In the illustrative example of FIG. 4(a) there is one connection path 410a from component 130a to component 130b, and one connection path 410b from component 130b to component 130c.

As in FIG. 4(b), for each component 130a, 130b, 130c, a public key 420a, 420b, 420c and private key 430a, 430b, 430c is generated and provided to the respective component 130a, 130b, 130c. Examples of where the keys might be generated have been provided above. As disclosed above, the public keys might be signed by a trusted agent.

As in FIG. 4(c), the components 130a, 130b, 130c, by means of the source runtime environment 200a, exchange keys, fingerprints, configurations and secrets for each connection path. Particularly, with respect to the connection paths 410a, 410b, the public key fingerprints 440a, 440b, 440c are provisioned from the source components to the destination components and vice versa. In the illustrative example of FIG. 4(c) the public key fingerprint 440a of component 130a is provided to component 130b, the public key fingerprint 440b of component 130b is provided to components 130a and 130b, and the public key fingerprint 440c of component 130c is provided to component 130b, see also FIG. 4(d). The components 130a, 130b, 130c are thereby equipped with the key fingerprints of all intended connections. This will allow the component 130a, 130b, 130c to verify its connections without using a trusted agent and thus can be established beyond one single trusted network domain.

As in FIG. 4(d), the components 130b, 130c are migrated to their destination runtime environment 200b, 200c, bringing the keys and fingerprints with them. A component 130a, 130b, 130b can now reside inside or outside of the trusted network domain and establish trusted connections to its endpoints (i.e., other components 130a, 130b, 130c) by verifying the fingerprints.

In summary, the herein disclosed embodiments might be regarded as combining a certificate authority methodology with a Trust On First Use methodology in a single entity (i.e. the trusted network environment; the source runtime environment 200a) before the components 130a, 130b, 130c are migrated. Cryptographic fingerprints (i.e. the public key fingerprints) are stored in components 130a, 130b, 130c based on intended communication patterns of the components 130a, 130b, 130c in a distributed application 120.

FIG. 5 schematically illustrates, in terms of a number of functional units, the components of a runtime environment 200a according to an embodiment. Processing circuitry 210 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 910a (as in FIG. 9), e.g. in the form of a storage medium 230. The processing circuitry 210 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

Particularly, the processing circuitry 210 is configured to cause the runtime environment 200a to perform a set of operations, or steps, S102-S104, as disclosed above. For example, the storage medium 230 may store the set of operations, and the processing circuitry 210 may be configured to retrieve the set of operations from the storage medium 230 to cause the runtime environment 200a to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus the processing circuitry 210 is thereby arranged to execute methods as herein disclosed. The storage medium 230 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

The runtime environment 200a may further comprise a communications interface 220 for communications with other runtime environments 200b, 200c as well as other components, applications, entities, functions, nodes, and devices of the communications network 100. As such the communications interface 220 may comprise one or more transmitters and receivers, comprising analogue and digital components.

The processing circuitry 210 controls the general operation of the runtime environment 200a e.g. by sending data and control signals to the communications interface 220 and the storage medium 230, by receiving data and reports from the communications interface 220, and by retrieving data and instructions from the storage medium 230. Other components, as well as the related functionality, of the runtime environment 200a are omitted in order not to obscure the concepts presented herein.

FIG. 6 schematically illustrates, in terms of a number of functional modules, the components of a runtime environment 200a according to an embodiment. The runtime environment 200a of FIG. 6 comprises a number of functional modules; a provide module 210a configured to perform step S102 and a migrate module 210e configured to perform step S104. The runtime environment 200a of FIG. 6 may further comprise a number of optional functional modules, such as any of an inject module 210b configured to perform step S102a, a distribute module 210c configured to perform step S102b, and a manage module 210d configured to perform step S102c. In general terms, each functional module 210a-210e may be implemented in hardware or in software. Preferably, one or more or all functional modules 210a-210e may be implemented by the processing circuitry 210, possibly in cooperation with the communications interface 220 and/or the storage medium 230. The processing circuitry 210 may thus be arranged to from the storage medium 230 fetch instructions as provided by a functional module 210a-210e and to execute these instructions, thereby performing any steps of the runtime environment 200a as disclosed herein.

The runtime environment 200a may be provided as a standalone device or as a part of at least one further device. Alternatively, functionality of the runtime environment 200a may be distributed between at least two devices, or nodes. Thus, a first portion of the instructions performed by the runtime environment 200a may be executed in a first device, and a second portion of the of the instructions performed by the runtime environment 200a may be executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the runtime environment 200a may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a runtime environment 200a residing in a cloud computational environment. Therefore, although a single processing circuitry 210 is illustrated in FIG. 5 the processing circuitry 210 may be distributed among a plurality of devices, or nodes. The same applies to the functional modules 210a-210e of FIG. 6 and the computer program 920a of FIG. 9 (see below).

FIG. 7 schematically illustrates, in terms of a number of functional units, the components of a system 300 according to an embodiment. Processing circuitry 310 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 910b (as in FIG. 9), e.g. in the form of a storage medium 330. The processing circuitry 310 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

Particularly, the processing circuitry 310 is configured to cause one of the components 130a to perform a set of operations, or steps, S202-S206, as disclosed above. For example, the storage medium 330 may store the set of operations, and the processing circuitry 310 may be configured to retrieve the set of operations from the storage medium 330 to cause one of the components 130a to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus the processing circuitry 310 is thereby arranged to execute methods as herein disclosed.

The storage medium 330 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

The system 300 may further comprise a communications interface 320 for communications with components, runtime environments 200a, 200b, 200c, applications, entities, functions, nodes, and devices of the communications network 100. As such the communications interface 320 may comprise one or more transmitters and receivers, comprising analogue and digital components.

The processing circuitry 310 controls the general operation of the system 300 e.g. by sending data and control signals to the communications interface 320 and the storage medium 330, by receiving data and reports from the communications interface 320, and by retrieving data and instructions from the storage medium 330. Other components, as well as the related functionality, of the system 300 are omitted in order not to obscure the concepts presented herein.

FIG. 8 schematically illustrates, in terms of a number of functional modules, the components of a system 300 according to an embodiment. The system 300 of FIG. 8 comprises an obtain module 310b configured to perform step S204a. The system 300 of FIG. 8 may further comprise a number of optional functional modules, such as any of an obtain module 310a configured to perform step S202, a provide module 310c configured to perform step S204b, a provide module 310d configured to perform step S204c, and an establish module 310e configured to perform step S2o6. In general terms, each functional module 310a-310e may be implemented in hardware or in software. Preferably, one or more or all functional modules 310a-310e may be implemented by the processing circuitry 310, possibly in cooperation with the communications interface 320 and/or the storage medium 330. The processing circuitry 310 may thus be arranged to from the storage medium 330 fetch instructions as provided by a functional module 310a-310e and to execute these instructions, thereby performing any steps of the component 130a as disclosed herein.

In some aspects the system 300 is part of the runtime environment 200a.

FIG. 9 shows one example of a computer program product 910a, 910b comprising computer readable means 930. On this computer readable means 930, a computer program 920a can be stored, which computer program 920a can cause the processing circuitry 210 and thereto operatively coupled entities and devices, such as the communications interface 220 and the storage medium 230, to execute methods according to embodiments described herein. The computer program 920a and/or computer program product 910a may thus provide means for performing any steps of the runtime environment 200a as herein disclosed. On this computer readable means 930, a computer program 920b can be stored, which computer program 920b can cause the processing circuitry 310 and thereto operatively coupled entities and devices, such as the communications interface 320 and the storage medium 330, to execute methods according to embodiments described herein. The computer program 920b and/or computer program product 910b may thus provide means for performing any steps of the system 300 as herein disclosed.

In the example of FIG. 9, the computer program product 910a, 910b is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 910a, 910b could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 920a, 920b is here schematically shown as a track on the depicted optical disk, the computer program 920a, 920b can be stored in any way which is suitable for the computer program product 910a, 910b.

The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept, as defined by the appended patent claims.

Claims

1-30. (canceled)

31. A method for deployment of components of a distributed application on destination runtime environments, the method being performed by a source runtime environment, the method comprising: providing, with the components residing on the source runtime environment, public key fingerprints between the components, such that each component has its own public key and its own private key and is provided with a public key fingerprint of at least one other of the components; andmigrating each of the components from the source runtime environment to its destination runtime environment for deployment of each component on its destination runtime environment.

32. The method of claim 31, wherein the private keys, the public keys, and the public key fingerprints are generated outside the components, the providing further comprising: injecting the private keys, the public keys, and the public key fingerprints into the components.

33. The method of claim 32, wherein the private keys, the public keys, and the public key fingerprints are generated either by the source runtime environment or outside the source runtime environment and obtained by the source runtime environment.

34. The method of claim 31, wherein the private keys, the public keys, and the public key fingerprints are generated by the components, the providing further comprising: distributing the public key fingerprint of each of the components to at least one other of the components.

35. The method of claim 31, wherein the components are configured to communicate with each other according to at least one connection path, the at least one connection path defining a network topology.

36. The method of claim 34, wherein the public key fingerprints are distributed in accordance with the network topology such that there are two public key fingerprints per connection path.

37. The method of claim 36, wherein the public key fingerprints are distributed such that there is one public key fingerprint at each end of each connection path, with each public key fingerprint of the component at one end of a given connection path corresponding to the public key of the component at opposite end of the given connection path.

38. The method of claim 31, wherein each of the public keys is signed by a trusted agent before each of the components is migrated to its destination runtime environment.

39. The method of claim 31, further comprising: managing, with the components residing on the source runtime environment, exchange of at least one of configuration information and data between the components.

40. The method of claim 31, wherein each of the components is re-migrated back to the source runtime environment for re-provisioning of the public key fingerprints before being migrated to a set of destination runtime environments.

41. The method of claim 31, wherein each of the components is re-migrated back to the source runtime environment for provisioning of new public key fingerprints before being migrated to a set of destination runtime environments.

42. The method of claim 40, wherein each of the components is periodically re-migrated back to the source runtime environment.

43. A method for facilitating exchange of public key fingerprints between components of a distributed application, each component having its own public key and its own private key, the method being performed by one of the components, the method comprising: obtaining, when in the same trusted network environment as the other components, a public key fingerprint of at least one of the other components before being migrated to a destination runtime environment for deployment of the component on the destination runtime environment.

44. The method of claim 43, further comprising: providing, when in the same trusted network environment as the other components, the public key fingerprint of the components to the at least one of the other components before being migrated to the destination runtime environment.

45. The method of claim 43, wherein the trusted network environment is a source runtime environment.

46. The method of claim 43, further comprising, when being deployed on the destination runtime environment: establishing a trusted connection to at least one of the other components by receiving the public key of each of the at least one of the other components and verifying the received public key to its corresponding public key fingerprint.

47. The method of claim 43, wherein the private key, the public key, and the public key fingerprint are generated outside the component, the method further comprising: obtaining the private key, the public key, and the public key fingerprint from the trusted network environment.

48. The method of claim 43, wherein the private key, the public key, and the public key fingerprint are generated by the component, the method further comprising: providing at least the public key fingerprint to the trusted network environment for distribution to at least one other of the components.

49. The method of claim 43, wherein the component is re-migrated back to the trusted network environment for again obtaining the public key fingerprint of the at least one of the other components before being migrated back to the destination runtime environment.

50. The method of claim 43, wherein the component is re-migrated back to the trusted network environment for obtaining a new public key fingerprint of the at least one of the other components before being migrated back to the destination runtime environment.

51. The method of claim 43, wherein the component is migrated to another trusted network environment for again obtaining the public key fingerprint of the at least one of the other components before being migrated back to the destination runtime environment.

52. The method of claim 43, wherein the component is migrated to another trusted network environment for obtaining a new public key fingerprint of the at least one of the other components before being migrated back to the destination runtime environment.

53. A runtime environment for deployment of components of a distributed application on destination runtime environments, the runtime environment comprising processing circuitry, the processing circuitry being configured to cause the runtime environment to: provide, with the components residing on the runtime environment, public key fingerprints between the components, such that each component has its own public key and its own private key and is provided with a public key fingerprint of at least one other of the components; andmigrate each of the components from the runtime environment to its destination runtime environment for deployment of each component on its destination runtime environment.

54. A system for facilitating exchange of public key fingerprints between components of a distributed application, each component having its own public key and its own private key, the system comprising processing circuitry, the processing circuitry being configured to cause one of the components to: obtain, when the component is in the same trusted network environment as the other components, a public key fingerprint of at least one of the other components before being migrated to a destination runtime environment for deployment of the component on the destination runtime environment.

55. The system of claim 54, wherein the system is part of the runtime environment of claim 53.