Private Key Management

Abstract

Context information for a handshake between a source entity and a target entity is obtained. The context information is sent from the security proxy to a key manager. The key manager maintains a first private key for the security proxy. A first handshake message is received from the key manager. The first handshake message is generated based on at least the context information and signed with the first private key. The first handshake message is sent to the target entity.

Description

[Technical field]

[0001] The present invention relates to data encryption, and more particularly to methods, systems, and computer program products for private key management. [Background technology]

[0002] Applications are now being containerized and deployed in cloud environments, bringing with it security requirements, and encryption is a common strategy: for example, network traffic between the client for an application and the server for the application is commonly encrypted. Summary of the Invention

[0003] Some embodiments of the present disclosure may be exemplified as a method. According to the method, context information of a handshake between a source entity and a target entity is obtained at a security proxy. The context information is transmitted from the security proxy to a key manager, where the key manager maintains a first private key of the security proxy. And a first handshake message is received from the key manager, where the first handshake message is generated based on at least the context information and signed with the first private key. And the first handshake message is transmitted to the target entity.

[0004] Some embodiments of the present disclosure may be exemplified as a second method. According to the second method, context information of a handshake between a source entity and a target entity is received from a security proxy at a key manager, where the key manager maintains a first private key of the security proxy. Then, a first handshake message directed to the target entity is generated at the key manager based on at least the context information, where the first handshake message is signed with the first private key of the security proxy. Then, the first handshake message is sent to the security proxy.

[0005] Some embodiments of the present disclosure may be exemplified as a system. The system includes a processing unit and a memory coupled to the processing unit. The memory stores instructions that, when executed by the processing unit, perform operations. The operations include obtaining, at a security proxy, context information of a handshake between a source entity and a target entity. The operations also include transmitting the context information from the security proxy to a key manager, where the key manager maintains a first private key of the security proxy. The operations also include receiving a first handshake message from the key manager, where the first handshake message is generated based on at least the context information and is signed with the first private key. The operations further include transmitting the first handshake message to the target entity.

[0006] Some embodiments of the present disclosure may be exemplified as a computer program product. The computer program product is stored on a non-transitory machine-readable medium and includes machine-executable instructions. When executed on a device, the machine-executable instructions cause the device to perform an operation. The operation includes obtaining, at a security proxy, context information of a handshake between a source entity and a target entity. The operation also includes transmitting the context information from the security proxy to a key manager, where the key manager maintains a first private key of the security proxy. The operation also includes receiving a first handshake message from the key manager, where the first handshake message is generated based on at least the context information and is signed with the first private key. The operation further includes transmitting the first handshake message to the target entity.

[0007] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure.

[0008] The drawings contained herein are incorporated in and constitute a part of this specification. They illustrate embodiments of the disclosure and, together with the description, serve to explain the principles of the disclosure. The drawings are merely illustrative of particular embodiments and are not intended to limit the disclosure. Features and advantages of various embodiments of the claimed subject matter will become apparent as the following detailed description proceeds and by reference to the drawings in which like numerals indicate like parts. [Brief description of the drawings]

[0009] [Figure 1] FIG. 2 illustrates a cloud computing node according to an embodiment of the present invention. [Diagram 2] FIG. 1 illustrates a cloud computing environment in accordance with an embodiment of the present invention. [Diagram 3] FIG. 2 illustrates abstraction model layers according to one embodiment of the present invention. [Figure 4] FIG. 1 illustrates an environment in which embodiments of the present disclosure may be implemented. [Diagram 5] FIG. 2 illustrates an example process for private key management according to some embodiments of the present disclosure. [Figure 6] FIG. 2 illustrates an example process for private key management according to some embodiments of the present disclosure. [Figure 7] FIG. 2 illustrates an example process for private key management according to some embodiments of the present disclosure. [Figure 8] FIG. 1 illustrates a flowchart of an exemplary method according to some embodiments of the present disclosure. [Figure 9] FIG. 1 illustrates a flowchart of an exemplary method according to some embodiments of the present disclosure. [Figure 10] FIG. 1 illustrates a high-level block diagram of an exemplary computer system that can be used in implementing embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] While the invention is susceptible to various modifications and alternative forms, specific features thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit the invention to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the invention.

[0011] Some embodiments will be described in more detail with reference to the accompanying drawings in which embodiments of the present disclosure are illustrated. However, the present disclosure may be embodied in various forms and therefore should not be construed as being limited to the embodiments disclosed herein.

[0012] Although this disclosure includes detailed descriptions of cloud computing, implementation of the teachings described herein is not limited to a cloud computing environment. Rather, embodiments of the invention may be practiced in conjunction with any other type of computing environment now known or developed in the future.

[0013] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with a service provider. The cloud model may include at least five characteristics, at least three service models, and at least four implementation models.

[0014] The characteristics are as follows:

[0015] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time or network storage, automatically as needed, without the need for human interaction with the service provider.

[0016] Broad network access: Computing power is available over the network and can be accessed through standard mechanisms, facilitating use by heterogeneous thin- and thick-client platforms (e.g., cell phones, laptops, PDAs).

[0017] Resource Pooling: Computing resources from a provider are pooled and offered to multiple consumers using a multi-tenant model. Different physical and virtual resources are dynamically allocated and reallocated depending on demand. Consumers generally have no control or knowledge of the exact location of the resources provided to them, so there is a sense of location independence, although consumers may be able to determine location at a higher level of abstraction (e.g. country, state, data center).

[0018] Rapid elasticity: Computing capacity can be provisioned quickly and elastically, in some cases automatically, to scale out immediately and to be released quickly to scale in immediately. To the consumer, the computing capacity available for provisioning often appears unlimited and can be purchased at any time and in any quantity.

[0019] Metered Services: Cloud systems leverage metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user count) to automatically control and optimize resource usage. Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of the services utilized.

[0020] The service model is as follows:

[0021] Software as a Service (SaaS): The functionality offered to the consumer is the availability of a provider's applications running on a cloud infrastructure that can be accessed from a variety of client devices through a thin-client interface such as a web browser (e.g., webmail). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even the individual application functions, except for limited user-specific application configuration settings.

[0022] Platform as a Service (PaaS): The capability offered to the consumer is to deploy applications that the consumer creates or acquires using programming languages ​​and tools supported by the provider onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of the hosting environment.

[0023] Infrastructure as a Service (IaaS): The functionality offered to the consumer is the provision of processors, storage, networking, and other basic computing resources onto which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, and deployed applications, and may have partial control over some network components (e.g., host firewalls).

[0024] The deployment model is as follows:

[0025] Private Cloud: The cloud infrastructure is dedicated to a specific organization. It can be managed by that organization or a third party and can exist on-premise or off-premise.

[0026] Community Cloud: The cloud infrastructure is shared by multiple organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, and compliance). The cloud infrastructure can be managed by the organizations or a third party and can exist on-premise or off-premise.

[0027] Public cloud: The cloud infrastructure is available to the general public or large industry organizations and is owned by an organization that sells cloud services.

[0028] Hybrid Cloud: This cloud infrastructure combines two or more cloud models (private, community or public), each of which retains its inherent semantics but is bound together by standards or specific technologies that enable data and application portability (e.g. cloud bursting for load balancing between clouds).

[0029] A cloud computing environment is a service-oriented environment with an emphasis on statelessness, low coupling, modularity and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0030] 1, a schematic diagram of an example cloud computing node is shown. Cloud computing node 10 is merely one example of a suitable cloud computing node and is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the invention described herein. Nevertheless, cloud computing node 10 is capable of implementing and / or executing any of the functionality defined herein.

[0031] In cloud computing node 10, there are portable electronic devices such as computer systems / servers 12 or communication devices operating in numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use with computer system / server 12 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 appliances, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0032] The computer system / server 12 may be described in the general context of computer system executable instructions, such as program modules, being executed by a computer system. 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 12 may also be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices that are 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.

[0033] 1, computer system / server 12 in cloud computing node 10 is shown in the form of a general-purpose computing device. Components of computer system / server 12 may include, but are not limited to, a set of one or more processors or processing units 16, a system memory 28, and a bus 18 that couples various system components including system memory 28 to processor 16.

[0034] Bus 18 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, such architectures include the Industry Standard Architecture (ISA) bus, the MicroChannel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0035] Computer system / server 12 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system / server 12 and can include both volatile and nonvolatile media, removable and non-removable media.

[0036] The system memory 28 may include computer system readable media as volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. The computer system / server 12 may further include other removable / non-removable and volatile / non-volatile computer system storage media. As an example, the storage system 34 may be provided for reading and writing to a non-removable non-volatile magnetic medium (not shown, commonly referred to as a "hard drive"). Although not shown, a magnetic disk drive for reading and writing to a removable non-volatile magnetic disk (e.g., a floppy disk) and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM or other optical media) may be provided. In these examples, each may be connected to the bus 18 by one or more data media interfaces. As further shown and described below, the memory 28 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.

[0037] As an example, a program / utility 40 having a set (at least one) of program modules 42 can be stored in memory 28, as can 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 some combination thereof, can include an implementation of a network environment. The program modules 42 generally perform the functions and / or methods of embodiments of the invention described herein.

[0038] The computer system / server 12 may also communicate with one or more external devices 14, such as a keyboard, a pointing device, a display 24, one or more devices that allow a user to interact with the computer system / server 12, or any device (e.g., a network card, a modem, etc.) that allows the computer system / server 12 to communicate with one or more other computer devices, or a combination thereof. Such communication may occur via an input / output (I / O) interface 22. The computer system / server 12 may also communicate with one or more networks (e.g., a local area network (LAN), a general-purpose wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof) via a network adapter 20. As shown, the network adapter 20 may communicate with other components of the computer system / server 12 via a bus 18. It should be noted that other hardware and / or software components, not shown, may be used with the computer system / server 12. Examples of such components include microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data archive storage systems, etc.

[0039] Referring now to FIG. 2, an exemplary cloud computing environment 50 is depicted. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, to which local computing devices used by cloud consumers (e.g., PDA or cell phone 54A, desktop computer 54B, laptop computer 54C, or automobile computer system 54N, or combinations thereof, etc.) can communicate. The nodes 10 can communicate with each other. The nodes 10 can be physically or virtually grouped (not shown) in one or more networks, such as, for example, a private, community, public, or hybrid cloud, or combinations thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, or software, or combinations thereof, as a service, for which the cloud consumer does not need to maintain resources on the local computing device. It should be understood that the types of computing devices 54A-N shown in FIG. 2 are merely exemplary, and that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of electronic device over any type of network or network addressable connection (e.g., using a web browser), or both.

[0040] Referring now to Figure 3, a series of functional abstraction layers provided by cloud computing environment 50 (Figure 2) are shown. It should be understood in advance that the components, layers and functions shown in Figure 3 are merely exemplary and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0041] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, reduced instruction set computer (RISC) architecture based servers 62, servers 63, blade servers 64, storage devices 65, and networks and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0042] The virtualization layer 70 provides an abstraction layer from which the following virtual entities can be provided, for example: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0043] By way of example, the management layer 80 may provide the following functions: Resource provisioning 81 allows dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 allows cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. By way of example, these resources may include application software licenses. Security allows for identification and verification of cloud consumers and tasks as well as protection for data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 allows for allocation and management of cloud computing resources such that requested service levels are met. Service level agreement (SLA) planning and fulfillment 85 allows for pre-arranging and procurement of anticipated future needs for cloud computing resources according to SLAs.

[0044] The workload layer 90 provides examples of functionality available to a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and private key management 96.

[0045] In cloud environments, traffic is typically encrypted. However, this brings its own security concerns, as malicious traffic is often also encrypted and can attack servers unobserved. To mitigate such security threats, cloud security proxies are sometimes deployed. A cloud security proxy may be a container-type proxy product that sits between the client and the server. The cloud security proxy can observe and monitor the encrypted traffic to detect malicious behavior and content. For this purpose, and to be transparent to the client, the cloud security proxy's public key needs to be trusted by the client, and the cloud security proxy may be required to use a pairing private key to authenticate itself to the client.

[0046] On the other hand, in a cloud environment, the cloud security proxy may be implemented by one or more container instances. However, maintaining the private key on the container instance may increase the risk of the private key being leaked. Moreover, in a cloud environment, container instances may be frequently changed to accommodate ever-changing workloads, so distributing the private key to the container instances may be relatively complicated.

[0047] Embodiments of the present disclosure provide a solution for private key management. In general, according to embodiments of the present disclosure, a key manager on behalf of a security proxy maintains a private key for the security proxy and processes handshake messages that require the private key. Context information of a handshake between a source entity and a target entity is obtained at the security proxy and sent to the key manager. A handshake message is generated by the key manager based on at least the context information and signed with the private key of the security proxy. The handshake message is then sent to the security proxy and forwarded by the security proxy to the target entity.

[0048] In an embodiment of the present disclosure, a centralized system with enhanced security is proposed. In this way, there is no need for the security proxy to store, manage and protect the private key. The private key of the security proxy can be stored centrally, without being distributed to the container instances. This advantageously reduces the risk of the private key being leaked. In this way, the proposed solution allows for a safer cloud environment. Furthermore, the centralization eliminates the need for individual configuration of the private key of the security proxy, and configuration changes of the security proxy can also be handled by the key manager. In this way, updating and management of the private key of the security proxy is facilitated.

[0049] In some embodiments, information regarding handshake messages may be prepared in advance at the security proxy and the key manager. Historical context information of historical handshakes involving the source entity may be obtained in advance. When a handshake is initiated by the target entity, the key manager may generate the handshake messages without waiting for a response from the source entity. In such embodiments, the time required for the handshake may be reduced, which may result in improved transaction flow between the source entity and the target entity. In this manner, a more efficient handshake may be achieved.

[0050] Even if the security proxy is not deployed in the cloud environment, the above advantages of the present disclosure can be realized. Other advantages of the present disclosure will be described with reference to the following exemplary embodiments and the accompanying drawings.

[0051] 4 illustrates an environment 400 in which embodiments of the present disclosure may be implemented. It is understood that the structure and functionality of the environment 400 are described for illustrative purposes only, without implying any limitation on the scope of the present disclosure. In general, the environment 400 includes a target entity 410, a source entity 420, a security proxy 430, and a key manager 440.

[0052] As shown in FIG. 4, the security proxy 430 is disposed between the target entity 410 and the source entity 420. Specifically, the security proxy 430 may act as an authorized entity to establish a first secure connection between the target entity 410 and the security proxy 430, and a second secure connection between the security proxy 430 and the source entity 420. With these two secure connections, the security proxy 430 may receive encrypted communications from the target entity 410 via the first secure connection. If the encrypted communications are destined for the source entity 420, the security proxy 430 may forward the communications to the source entity 420 via the second secure connection. The reverse process may be performed if the encrypted communications are received from the source entity 420 via the second secure connection. As an example, the security proxy 430 may be configured to provide Transport Layer Security (TLS). In such an example, the security proxy 430 may be a TLS proxy.

[0053] In some embodiments, security proxy 430 may be implemented in a cloud environment. For example, security proxy 430 may be implemented by one or more container instances. In some embodiments, security proxy 430 may be implemented on one or more local devices.

[0054] Target entity 410 and source entity 420 may be any suitable entities that communicate with each other via security proxy 430. In some embodiments, one of target entity 410 and source entity 420 may be a client, and the other of target entity 410 and source entity 420 may be a server. By way of example, and without any limitation on the scope of the present disclosure, target entity 410 may be a TLS client, and source entity 420 may be a TLS server.

[0055] A handshake is required between the target entity 410 and the source entity 420 to communicate with each other, e.g., to exchange application data. Due to the presence of the security proxy 430, the handshake may include not only a handshake sequence between the target entity 410 and the security proxy 430, but also another handshake sequence between the source entity 420 and the security proxy 430. One or more handshake messages communicated between the target entity 410, the security proxy 430, and the source entity 420 may need to be signed with the private key of the sender of the handshake message. For example, handshake messages for certificate validation are required to be signed with the private key of the sender.

[0056] As used herein, the term "source" is used with respect to the originator of a message (e.g., a handshake message) and the term "target" is used with respect to the destination of the message. In the following, target entity 410 and source entity 420 may be referred to collectively as "entities" or individually as "entities."

[0057] 4, key manager 440 may communicate with security proxy 430 over a secure connection. Key manager 440 maintains a private key 450 for security proxy 430 and is configured to process messages requiring private key 450 on behalf of security proxy 430. Key manager 440 may be implemented in any suitable manner. For example, key manager 440 may be implemented by a component in a cloud environment. Alternatively, key manager 440 may be implemented by one or more devices, such as servers.

[0058] Key manager 440 is configured to receive context information of a handshake between source entity 420 and target entity 410 from security proxy 430, and generate handshake messages based on at least the context information and private key 450. As used herein, the term "context information" of a handshake refers to at least a portion of the information exchanged during the handshake, e.g., messages communicated between target entity 410, security proxy 430, and source entity 420.

[0059] In some embodiments, key manager 440 may store historical context information 460 of historical handshakes involving source entity 420. Specifically, the historical context information may be associated with source entity 420. Key manager 440 may further generate handshake messages based on the historical context information. Although not shown, in some embodiments, security proxy 430 may store historical context information 460.

[0060] 4 is provided for illustrative purposes only, and any suitable number of elements may be present. For example, there may be additional entities provided by security proxy 430. Key manager 440 may maintain private keys for multiple security proxies.

[0061] 5 illustrates an example process 500 for private key management according to some embodiments of the present disclosure. As shown in FIG. 5, process 500 may include a target entity 511, a security proxy 531, a key manager 541, and a source entity 521. These components may correspond to target entity 410, security proxy 430, key manager 440, and source entity 420, respectively, as shown in FIG.

[0062] A handshake between target entity 511 and source entity 521 may be initiated for mutual authentication. Handshake messages are communicated between target entity 511 and source entity 521 via security proxy 531. The handshake message (also referred to as a "first handshake message"), e.g., a message for certificate validation, may require the private key (also referred to as a "first private key") of security proxy 531.

[0063] The security proxy 531 obtains context information 510 of the handshake between the source entity 521 and the target entity 511 and sends 515 the context information to the key manager 541. The context information may include some or all of the information exchanged during the handshake. For example, the context information may include messages 505, 506 communicated between the target entity 511, the security proxy 531, and the source entity 521 during the handshake.

[0064] In some embodiments, the security proxy 531 may receive a handshake message (also referred to as a "second handshake message") from the source entity 521 as at least a part of the context information. The second handshake message is directed to the target entity 511 and is signed with the private key (also referred to as a "second private key") of the source entity 521. As an example, the second handshake message may be a certificate verification (CV) message for verifying the certificate. The CV message may include the signature of the source entity 521 generated based on the private key of the source entity 521.

[0065] Upon receiving the second handshake message, the security proxy 531 may send the second handshake message to the key manager 541. Additionally, in some embodiments, the security proxy 531 may also send to the key manager 541 a handshake key to be used between the target entity 511 and the security proxy 531. The handshake key may be determined based on key exchange information from the target entity 511. In this manner, the key manager 541 may encrypt the first handshake message with the handshake key. An example of these embodiments is described below with reference to FIG. 6.

[0066] In some embodiments, the security proxy 531 may receive a "Hello" message (also referred to as a "First Hello message") from the target entity 511 as at least part of the context information. The First Hello message may be directed to the source entity 521 to initiate a handshake. If the target entity 511 is a client, the First Hello message may be a Client Hello message. The First Hello message may include key exchange information for encrypting the handshake sequence between the target entity 511 and the security proxy 531. For example, the First Hello message may include at least a key agreement entry indicating parameters for a key exchange with the security proxy 531.

[0067] Upon receiving the first Hello message from the target entity 511, the security proxy 531 may send the first Hello message to the key manager 541. In some embodiments, the security proxy 531 may also prepare some of the information required to generate the first handshake message in advance. The security proxy 531 may obtain historical context information (e.g., historical context information 460 as shown in FIG. 4) of a historical handshake involving the source entity 521 before receiving the first Hello message. The historical context information may include the Hello message from the source entity 521, the certificate of the source entity 521, and any related handshake messages from the source entity 521.

[0068] The historical context information may be obtained during any suitable historical handshake involving source entity 521. As one example, the historical context information may be obtained the first time security proxy 531 provides a handshake involving source entity 521. As another example, the historical context information may be obtained during the most recent handshake involving source entity 521.

[0069] In some embodiments, the historical context information may be sent to key manager 541 once the historical context information is obtained. In some embodiments, the historical context information may be sent along with the first hello message to key manager 541. An example of these embodiments is described below with reference to FIG.

[0070] Upon receiving 515 the context information from security proxy 531, key manager 541 generates 520 a first handshake message based at least on the context information. The first handshake message is signed with a first private key (not shown) of security proxy 531. The private key may correspond, for example, to private key 450 as depicted in FIG. 4. For example, key manager 541 can generate a signature for security proxy 531 based on the first private key and include the signature in the first handshake message.

[0071] In the above embodiment in which the second handshake message is received from the source entity 521 as the context information, the key manager 541 may generate 520 a first handshake message based on the second handshake message and the first private key. For example, the key manager 541 may replace the signature of the source entity 521 in the second handshake message with the signature of the security proxy 531.

[0072] Additionally, if the handshake key used between the target entity 511 and the security proxy 531 is sent to the key manager 541, the key manager 541 may encrypt the first handshake message with the handshake key.

[0073] In the above embodiments in which the first Hello message was received 515 from the target entity 511 as the context information, the key manager 541 may generate 520 a first handshake message based on the first Hello message and the historical context information. The key manager 541 may also generate a signature for the security proxy 531 based on the first private key and include such signature in the first handshake message. In these embodiments, the first Hello message may provide information about the target entity 511, while the historical context information may provide information about the source entity 521.

[0074] Also, when a set of parameters for determining a handshake key to be used between the target entity 511 and the security proxy 531 is sent from the security proxy 531 to the key manager 541, the key manager 541 may determine a handshake key based on the set of parameters and the first hello message. For example, the set of parameters may include a key agreement entry determined by the security proxy 531, and the first hello message may include another key agreement entry determined by the target entity 511. The handshake key may be determined based on these key agreement entries. Then, the key manager 541 may encrypt the first handshake message with the handshake key.

[0075] After the key manager 541 generates 520 the first handshake message, it sends 525 the first handshake message to the security proxy 531. The security proxy 531 then sends 530 the first handshake message to the target entity 511. If the first handshake message received from the key manager 541 is encrypted with a handshake key, the security proxy 531 may forward 530 the first handshake message directly to the target entity 511. If the first handshake message received from the key manager 541 is not encrypted with a handshake key, the security proxy 531 may first encrypt the first handshake message with the handshake key and may send 530 the encrypted first handshake message to the target entity 511.

[0076] 5, the handshake between the source entity 521 and the target entity 511 continues in subsequent steps. For example, a handshake sequence between the target entity 511 and a security proxy 531 may be performed 535. A handshake sequence between the source entity 521 and a security proxy 531 may be performed 540.

[0077] In the embodiments of the present disclosure, the security proxies do not need to store, manage, and protect the private keys. The private keys of the security proxies can be stored centrally without being distributed to the container instances. Thus, the risk of the private keys being leaked can be reduced or even avoided. Thus, a more secure cloud environment can be realized. Furthermore, the centralized management allows the key manager to update and manage the security proxies. In this way, the private keys of the security proxies can be easily updated and managed.

[0078] As mentioned above, in some embodiments, the second handshake message from the source entity 521 may be used as context information. Reference is now made to FIG. 6. FIG. 6 illustrates an example process 600 for private key management according to some embodiments of the present disclosure. The process 600 may be considered as one possible implementation of the process 500. As shown in FIG. 6, the process 600 may include a target entity 611, a security proxy 631, a key manager 641, and a source entity 621. These components may correspond to the target entity 410, the security proxy 430, the key manager 440, and the source entity 420, respectively, as shown in FIG. 4. For discussion purposes only and without limitation with respect to the scope of the present disclosure, in the process 600, the source entity 621 is a server, the target entity 611 is a client, and the first and second handshake messages are CV messages.

[0079] 6, the target entity 611 may send 605 a Client Hello message (also referred to as a "first Client Hello message") to the security proxy 631 to initiate a handshake between the target entity 611 and the source entity 621. The first Client Hello message may include at least a key agreement entry (also referred to as a "first key agreement entry") indicating parameters for a key exchange with the security proxy 631. The first Client Hello message may further include other key exchange information, e.g., protocol version, cryptographic algorithms, etc.

[0080] The security proxy 631 may determine 610 another key agreement entry (also referred to as a “second key agreement entry”) that indicates parameters for a key exchange with the source entity 621. The security proxy 631 may generate an updated Client Hello message (also referred to as a “second Client Hello message”) by replacing the first key agreement entry with the second key agreement entry, and may send 615 the second Client Hello message to the source entity 621.

[0081] Upon receiving the second Client Hello message, the source entity 621 may send 620 a Server Hello message (also referred to as the “first Server Hello message”) in response to the security proxy 631. The first Server Hello message may include at least a key agreement entry (also referred to as the “third key agreement entry”) that indicates parameters for a key exchange with the security proxy 631.

[0082] The security proxy 631 may determine 625 another key agreement entry (also referred to as a "fourth key agreement entry") indicating parameters for a key exchange with the target entity 611. The security proxy 631 may determine 630 a first handshake key to be used between the target entity 611 and the security proxy 631 based on the first and fourth key agreement entries, and a second handshake key to be used between the source entity 621 and the security proxy 631 based on the second and third key agreement entries. The security proxy 631 may send 635 another Server Hello message (also referred to as a "second Server Hello message") to the target entity 611. The second Hello message may include at least the fourth key agreement entry.

[0083] After the source entity 621 sends 620 the first Server Hello message to the security proxy 631, it may send 640 the certificate of the source entity 621 (in this example, the server certificate) to the security proxy 631. The security proxy 631 may then forward 645 the server certificate to the target entity 611.

[0084] The source entity 621 may further send 650 a message for verifying the server certificate (also referred to as an "original CV message") to the security proxy 631. The security proxy 631 may send 655 at least the original CV message as context information to the key manager 641. In some embodiments, the security proxy 631 may further send the first handshake key used between the target entity 611 and the security proxy 631 to the key manager 641. The security proxy 631 may also send other relevant context information to the key manager 641.

[0085] The key manager 641 can then generate 660 a new CV message based on the original CV message and a private key (not shown). The private key may correspond, for example, to the private key 450 as depicted in FIG. 4. For example, the new CV message may include a signature generated based on the private key. If the first handshake key is also sent to the key manager 641, the key manager 641 can encrypt the new CV message with the private key.

[0086] The key manager 641 may then send 665 the new CV message to the security proxy 631. The security proxy 631 may forward 670 the new CV message to the target entity 611. As shown in Figure 6, the handshake between the source entity 621 and the target entity 611 continues in subsequent steps. For example, a handshake sequence between the target entity 611 and the security proxy 631 may be performed 675. A handshake sequence between the source entity 621 and the security proxy 631 may be performed 680.

[0087] It has been recognized that the source and target entities, e.g., TLS server and TLS client, may remain essentially unchanged, and thus the only difference between handshakes is the parameters for the key exchange, e.g., key agreement entries. Thus, in some embodiments, some of the information required to generate the first handshake message may be prepared in advance.

[0088] 7 illustrates an example process 700 for private key management according to some embodiments of the present disclosure. Process 700 may be considered as another possible implementation of process 500. As shown in FIG. 7, process 700 may include a target entity 711, a security proxy 731, a key manager 741, and a source entity 721. These components may correspond to target entity 410, security proxy 430, key manager 440, and source entity 420, respectively, as shown in FIG. 4. For the sake of discussion without limiting the scope, in process 700, source entity 721 may be a server, target entity 711 may be a client, and the first and second handshake messages may be CV messages.

[0089] 7, the security proxy 731 may obtain 705 historical context information (such as, for example, historical context information 460 as depicted in FIG. 4) of historical handshakes involving the source entity 721. In this example, the historical context information may include a Server Hello message from the source entity 721 (also referred to as a "previous server hello message") and a server certificate of the source entity 721 (also referred to as a "previous server certificate"). For example, the security proxy 731 may receive the previous server hello message and the previous server certificate from the source entity 721 the first time the security proxy 731 provides a handshake involving the source entity 721 or during the most recent handshake involving the source entity 721.

[0090] The security proxy 731 may send 710 the historical context information to the key manager 741. The key manager 741 may store 715 the historical context information, for example, in a cache or any suitable storage device.

[0091] In some embodiments, security proxy 731 may predetermine key agreement entries indicating parameters for key exchange with source entity 721 and target entity 711. For example, a fifth key agreement entry indicating parameters for key exchange with source entity 721 and a sixth key agreement entry indicating parameters for key exchange with target entity 711 may be prepared in advance by security proxy 731. Furthermore, security proxy 731 may send the prepared key agreement entries to key manager 741.

[0092] In this manner, security proxy 731 and key manager 741 may be prepared for a handshake between target entity 711 and source entity 721. As shown in Figure 7, target entity 711 may send 720 a Client Hello message (also referred to as an "original Client Hello message") to security proxy 731 to initiate a handshake between target entity 711 and source entity 721. The original Client Hello message may include at least a seventh key agreement entry that indicates parameters for a key exchange with security proxy 731.

[0093] Upon receiving 720 the original Client Hello message from the target entity 711, two sub-processes 701 and 702 may be executed. In FIG. 7, the sub-processes 701 and 702 are depicted sequentially, but this is merely for ease of illustration, and 701 and 702 may be executed in parallel. In the sub-process 701, the security proxy 731 may send 725 the original Client Hello message directly to the key manager 741. The key manager 741 may generate 730 a first CV message signed with a private key (not shown). The private key may correspond, for example, to the private key 450 as depicted in FIG. 4. For example, the first CV message may be generated based on the original Client Hello message, the previous Server Hello message, and the previous server certificate. The first CV message may include the signature of the security proxy 731 generated based on the first private key.

[0094] In some embodiments, if a sixth key agreement entry indicating parameters for a key exchange with the target entity 711 is sent to the key manager 741, the key manager 741 may determine a handshake key (also referred to as a "third handshake key") to be used between the target entity 711 and the security proxy 731 based on the sixth key agreement entry and the seventh key agreement entry in the original Client Hello message. The key manager 741 may encrypt the first CV message with the third handshake key. The key manager 741 may then send 735 the first CV message to the security proxy 731.

[0095] As shown in FIG. 7, upon receiving 720 the original Client Hello message from the target entity 711, the security proxy 731 may determine 740 a third handshake key based on the sixth and seventh key agreement entries in the original Client Hello message. In some embodiments, the security proxy 731 may generate a Server Hello message (sometimes referred to as a "second Hello message") in response to the original Client Hello message. This Server Hello message may be generated based on a previous Server Hello message and may include the pre-prepared sixth key agreement entry. The security proxy 731 may then send 745 this Server Hello message to the target entity 711. The security proxy 731 may also send 750 the first CV message and the previous server certificate to the target entity 711.

[0096] Next, sub-process 702 will be described. Upon receiving 720 the original Client Hello message from the target entity 711, the security proxy 731 may generate a new Client Hello message based on the original Client Hello message and the previously prepared fifth key agreement entry. The new Client Hello message may be generated by replacing the seventh key agreement entry in the original Client Hello message with the fifth key agreement entry. The security proxy 731 may then send 755 the new Client Hello message to the source entity 721.

[0097] The source entity 721 may send 760 a Server Hello message to the security proxy 731 in response. This Server Hello message may include an eighth key agreement entry indicating parameters for a key exchange with the security proxy 731. The security proxy 731 may determine 765 a handshake key to be used between the source entity 721 and the security proxy 731 based on the fifth key agreement entry and the eighth key agreement entry. The source entity 721 may then send 770 a new server certificate and send 775 a new CV message to the security proxy 731. In some embodiments, this Server Hello message and the new server certificate may be used to update historical context information. For example, the new server certificate may replace a previous server certificate. Thus, sub-process 702 may be considered complete.

[0098] 7, the handshake between the source entity 721 and the target entity 711 continues in a subsequent step after both sub-processes 701 and 702 are completed. For example, a handshake sequence between the target entity 711 and the security proxy 731 may be performed 780. A handshake sequence between the source entity 721 and the security proxy 731 may be performed 785.

[0099] In such an embodiment, the handshake sequence as shown in sub-process 701 between the target entity 711 and the security proxy 731 can be performed by the previous Server Hello message and the previous server certificate. The security proxy 731 may not need to wait for a new Server Hello message and a new CV message from the source entity 721. In this way, the time required for the handshake can be reduced and the efficiency of the handshake can be improved.

[0100] 8 illustrates a flowchart of an example method 800 according to some embodiments of the present disclosure. For example, the method 800 may be implemented in the security proxy 430, as shown in FIG. 4. It will be understood that the method 800 may also include additional blocks (not shown) or omit illustrated blocks, or both. The scope of the disclosure described herein is not limited in this respect.

[0101] At block 810, the security proxy 430 obtains context information for a handshake between the source entity and the target entity. At block 820, the security proxy sends the context information to the key manager. The key manager holds a first private key of the security proxy. At block 830, the security proxy receives a first handshake message from the key manager. The first handshake message is generated based on at least the context information and is signed with the first private key. At block 840, the security proxy 430 sends the first handshake message to the target entity.

[0102] In some embodiments, the security proxy may receive a second handshake message from the source entity as at least a part of the context information. The second handshake message may be directed to the target entity and may be signed with a second private key of the source entity. For example, a CV message from the source entity may be received as at least a part of the context information. In some embodiments, the security proxy may further send to the key manager a handshake key to be used between the security proxy and the target entity. The first handshake message may be encrypted with the handshake key.

[0103] In some embodiments, the security proxy may receive a first hello message from the target entity as at least a portion of the context information. The first hello message is directed to the source entity to initiate a handshake. In some embodiments, the security proxy may further obtain historical context information of a historical handshake involving the source entity and may send the historical context information to the key manager. For example, the historical context information may include a server hello and a server certificate from the source entity. In these embodiments, the first handshake message may be generated based on the historical context information and the first hello message.

[0104] In some embodiments, the security proxy may further determine a second Hello message as a response to the first Hello message based on the historical context information. The security proxy may send the second Hello message to the target entity.

[0105] In some embodiments, the security proxy may further send to the key manager a set of parameters for determining a handshake key to be used between the security proxy and the target entity, in these embodiments, the first handshake message may be encrypted with the handshake key determined based on the set of parameters and the first hello message.

[0106] 9 illustrates a flowchart of an example method 900 according to some embodiments of the present disclosure. For example, the method 900 may be implemented in a key manager, such as the key manager 440 as shown in FIG. 4. It should be understood that the method 900 may also include additional blocks (not shown) and / or omit illustrated blocks. The scope of the disclosure described herein is not limited in this respect.

[0107] At block 910, the key manager receives context information of a handshake between the source entity and the target entity from the security proxy. At block 920, the key manager generates a first handshake message directed to the target entity based at least on the context information. The first handshake message is signed with a first private key of the security proxy held by the key manager. At block 930, the key manager sends the first handshake message to the security proxy.

[0108] In some embodiments, the key manager may receive a second handshake message from the security proxy as at least a part of the context information. The second handshake message may be directed to the target entity and may be signed with a second private key of the source entity. For example, a CV message may be received as at least a part of the context information. In some embodiments, the key manager may further receive from the security proxy a handshake key used between the security proxy and the target entity. The key manager may encrypt the first handshake message with the handshake key.

[0109] In some embodiments, the key manager may receive a first hello message from the security proxy as at least a portion of the context information. The first hello message may be directed to the source entity for initiating a handshake. In some embodiments, the key manager may further receive historical context information of a historical handshake involving the source entity from the security proxy. For example, the historical context information may include a server hello and a server certificate from the source entity. The key manager may generate the first handshake message based on the historical context information and the first hello message.

[0110] In some embodiments, the key manager may further receive from the security proxy a set of parameters for determining a handshake key to be used between the security proxy and the target entity, and may determine the handshake key based on the set of parameters and the first hello message. The key manager may encrypt the first handshake message with the handshake key.

[0111] The private key management or security proxy / key manager process according to an embodiment of the present disclosure may be implemented by computer system / server 12 of FIG.

[0112] Referring now to FIG. 10, there is shown a high-level block diagram of an exemplary computer system 1000 that may be configured to execute various aspects of the present disclosure, including, for example, processes 800 and 900. The exemplary computer system 1000 may be used (e.g., using one or more processor circuits of a computer or a set of processors including computer processors) in performing one or more of the methods or modules described herein and any associated functions or operations in accordance with embodiments of the present disclosure. The operations performed by the set of processors may be performed by a single processor, one of a group of processors, all of a group of processors, or any amount in between. In some embodiments, the main components of the computer system 1000 may include one or more CPUs 1002, a memory subsystem 1008, a terminal interface 1016, a storage interface 1018, an I / O (input / output) device interface 1020, and a network interface 1022, all of which may be communicatively coupled directly or indirectly between the components via a memory bus 1006, an I / O bus 1014, and an I / O bus interface unit 1012.

[0113] Computer system 1000 may include one or more general purpose programmable central processing units (CPUs) 1002, some or all of which may include one or more cores 1004A, 1004B, 1004C, and 1004D, generally referred to herein as CPUs 1002. In some embodiments, computer system 1000 may include multiple processors typical of relatively large systems, while in other embodiments computer system 1000 may alternatively be a single CPU system. Each CPU 1002 may execute instructions stored in a memory subsystem 1008 on CPU cores 1004, and may include one or more levels of on-board cache.

[0114] In some embodiments, the memory subsystem 1008 may include random access semiconductor memory, storage devices, or storage media (either volatile or non-volatile) for storing data and programs. In some embodiments, the memory subsystem 1008 may represent the entire virtual memory of the computer system 1000, and may also include virtual memory of other computer systems coupled to the computer system 1000 or connected over a network. While the memory subsystem 1008 may conceptually be a single monolithic entity, in some embodiments, the memory subsystem 1008 may be a more complex arrangement, such as a hierarchy of caches and other memory devices. For example, memory may exist in multiple levels of caches, and these caches may be further divided by function, such that one cache holds instructions and another cache holds non-instruction data used by one or more processors. Memory may be further distributed and associated with different CPUs or sets of CPUs, as is known in any of a variety of so-called non-uniform memory access (NUMA) computer architectures. In some embodiments, the main memory or memory subsystem 1008may include elements for control and flow of memory used by CPU 1002. This may include a memory controller 1010.

[0115] 10 as a single bus structure providing a direct communication path between the CPU 1002, the memory subsystem 1008, and the I / O bus interface 1012, the memory bus 1006, in some embodiments, may include a number of different buses or communication paths that may be arranged in any of a variety of configurations, such as point-to-point links in a hierarchical, star, or web configuration, multiple hierarchical buses, parallel and redundant paths, or other suitable types of configurations. Additionally, while the I / O bus interface 1012 and the I / O bus 1014 are shown as single respective units, the computer system 1000, in some embodiments, may include multiple I / O bus interface units 1012, multiple I / O buses 1014, or both. Additionally, although multiple I / O interface units are shown, this separates the I / O bus 1014 from the various communication paths that run to the various I / O devices, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0116] In some embodiments, computer system 1000 may be a multi-user mainframe computer system, a single-user system, or a server computer or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 1000 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a mobile device, or any other suitable type of electronic device.

[0117] It should be noted that Figure 10 is intended to depict representative major components of an exemplary computer system 1000. However, in some embodiments, the individual components may have greater or less complexity than depicted in Figure 10, components other than or in addition to those shown in Figure 10 may be present, and the number, type, and configuration of such components may vary.

[0118] The present invention may be a system, method or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer readable storage medium having stored thereon computer readable program instructions for causing a processor to carry out aspects of the present invention.

[0119] A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. The computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROM, DVD, memory sticks, floppy disks, punch cards or ridges in grooves or other mechanically encoded devices that record instructions, and suitable combinations thereof. As used herein, a computer-readable storage device should not be construed as a transitory signal per se, such as an electric signal transmitted over a wire, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a wave guide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or a radio wave.

[0120] The computer readable program instructions described herein can be downloaded from the computer readable storage medium to each computing / processing device or to an external computer or storage device via a network (e.g., the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof). The network may be comprised of 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 of each computing / processing device receives the computer readable program instructions from the network and forwards the computer readable program instructions for storage in the computer readable storage medium within the respective computing / processing device.

[0121] The computer readable program instructions for carrying out the operations of the present invention may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object oriented programming languages ​​such as Smalltalk, C++, etc., and procedural programming languages ​​such as the "C" programming language and similar programming languages. The computer readable program instructions may be executed entirely on the user's computer, as a stand-alone software package, or partially on the user's computer. Alternatively, they may be executed 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 a 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) can execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the computer readable program instructions to perform aspects of the invention.

[0122] 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.

[0123] These computer readable program instructions can be provided to a processor of a computer or other programmable data processing apparatus to generate a machine, such that the instructions, executed via a processor of the computer or other programmable data processing apparatus, generate means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer readable program instructions can also be stored in a computer readable storage medium connectable to a computer, programmable data processing apparatus, or other device or combination that functions in a particular way, such that the computer readable program instructions stored therein configure one of the products including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0124] Computer readable program instructions, such as instructions to perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams on a computer, other programmable apparatus, or other device, may also be loaded into a computer, other programmable data processing apparatus, or other device to perform a series of operational steps on the computer, other programmable apparatus, or other device to generate a computer-implemented process.

[0125] The flowcharts and block diagrams in the figures illustrate the configuration, functionality, and operation of executable 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 part of an instruction, which constitutes one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions shown in the blocks may differ from the order shown in the figures. For example, two blocks shown in succession may in fact be accomplished as one step and executed simultaneously, substantially simultaneously, partially or fully in a time-overlapping manner, or the blocks may be executed in reverse order depending on the functions involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special purpose hardware-based system that executes the specified functions or operations or executes a combination of special purpose hardware and computer instructions.

[0126] The description of various embodiments of the present disclosure is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. It will be apparent to those skilled in the art that many modifications and variations are possible without departing from the scope and spirit of the disclosed 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 allow those skilled in the art to understand the embodiments disclosed herein.

Claims

1. obtaining, by a set of processors in the security proxy, context information of a handshake between the source entity and the target entity; transmitting, by the set of processors in the security proxy, the context information from the security proxy to a key manager, the key manager maintaining a first private key of the security proxy; receiving, by the set of processors in the security proxy, a first handshake message from the key manager, the first handshake message generated based on at least the context information and signed with the first private key; sending, by the set of processors in the security proxy, the first handshake message to the target entity; A method comprising:

2. Obtaining the context information includes: receiving, by the set of processors in the security proxy, a second handshake message from the source entity as at least a portion of the context information, the second handshake message being directed to the target entity and signed with a second private key of the source entity; The method of claim 1 , comprising:

3. sending, by the set of processors in the security proxy, to the key manager, a handshake key to be used between the security proxy and the target entity, the first handshake message being encrypted with the handshake key. The method of claim 2 , further comprising:

4. Obtaining the context information includes: receiving, by the set of processors in the security proxy, a first Hello message from the target entity as at least a part of the context information, the first Hello message directed to the source entity to initiate the handshake; The method of claim 1 , comprising:

5. obtaining, by the set of processors in the security proxy, historical context information of a historical handshake involving the source entity; transmitting, by the set of processors in the security proxy, the historical context information to the key manager, wherein the first handshake message is generated based on the historical context information and the first hello message; The method of claim 4 further comprising:

6. determining, by the set of processors at the security proxy, a second Hello message in response to the first Hello message based on the historical context information; sending, by the set of processors in the security proxy, the second hello message to the target entity; The method of claim 5 further comprising:

7. sending, by the set of processors in the security proxy, to the key manager a set of parameters for determining a handshake key to be used between the security proxy and the target entity, the first handshake message being encrypted with the handshake key determined based on the set of parameters and the first hello message; The method of claim 4 further comprising:

8. receiving, by a set of processors in the key manager, context information of a handshake between the source entity and the target entity from the security proxy; generating, by the set of processors in the key manager, a first handshake message directed to the target entity based at least on the context information, the first handshake message being signed with a first private key of the security proxy maintained by the key manager; sending, by the set of processors in the key manager, the first handshake message to the security proxy; A method comprising:

9. Receiving the context information comprises: receiving, by the set of processors in the key manager, a second handshake message from the security proxy as at least a part of the context information, the second handshake message being directed to the target entity and signed with a second private key of the source entity; The method of claim 8 , comprising:

10. receiving, by the set of processors in the key manager, from the security proxy, a handshake key for use between the security proxy and the target entity; generating the first handshake message includes encrypting, by the set of processors in the key manager, the first handshake message with the handshake key; 10. The method of claim 9.

11. Receiving the context information comprises: receiving, by the set of processors in the key manager, a first hello message from the security proxy as at least a part of the context information, the first hello message being directed to the source entity to initiate the handshake; The method of claim 8 , comprising:

12. receiving, by the set of processors in the key manager, from the security proxy, historical context information for a historical handshake involving the source entity; generating the first handshake message includes generating, by the set of processors in the key manager, the first handshake message based on the historical context information and the first hello message. The method of claim 11.

13. receiving, by the set of processors in the key manager, from the security proxy, a set of parameters for determining a handshake key to be used between the security proxy and the target entity; determining, by the set of processors in the key manager, the handshake key based on the set of parameters and the first hello message; Further comprising: generating the first handshake message includes encrypting, by the set of processors in the key manager, the first handshake message with the handshake key; The method of claim 11.

14. A processor; and a memory in communication with the processor, the memory, when executed by the processor, causing the processor to: At the security proxy, obtaining context information of a handshake between a source entity and a target entity; transmitting the context information from the security proxy to a key manager, the key manager maintaining a first private key of the security proxy; receiving a first handshake message from the key manager, the first handshake message generated based on at least the context information and signed with the first private key; sending the first handshake message to the target entity; comprising program instructions configured to cause the system.

15. obtaining the context information includes receiving, as at least a part of the context information, a second handshake message from the source entity, the second handshake message being directed to the target entity and signed with a second private key of the source entity; The system of claim 14 , comprising:

16. The processor further transmits to the key manager a handshake key to be used between the security proxy and the target entity, the first handshake message being encrypted with the handshake key. configured to: The system of claim 15.

17. obtaining the context information includes receiving, as at least a part of the context information, a first Hello message from the target entity, the first Hello message being directed to the source entity to initiate the handshake; The system of claim 14 , comprising:

18. The processor further comprises: obtaining historical context information of a historical handshake involving the source entity; sending the historical context information to the key manager, wherein the first handshake message is generated based on the historical context information and the first hello message; configured to:

20. The system of claim 17.

19. The processor further comprises: determining a second Hello message in response to the first Hello message based on the historical context information; sending the second Hello message to the target entity; configured to:

20. The system of claim 18.

20. The processor further comprises: sending to the key manager a set of parameters for determining a handshake key to be used between the security proxy and the target entity, the first handshake message being encrypted with the handshake key determined based on the set of parameters and the first hello message; configured to:

20. The system of claim 17.

21. A processor; and a memory in communication with the processor, the memory, when executed by the processor, causing the processor to: receiving, at the key manager, context information for a handshake between a source entity and a target entity from a security proxy; generating, at the key manager, a first handshake message directed to the target entity based at least on the context information, the first handshake message being signed with a first private key of the security proxy maintained by the key manager; sending, at the key manager, the first handshake message to the security proxy; comprising program instructions configured to cause the system.

22. A computer program comprising program code adapted to carry out the method steps of any one of claims 1 to 7, when the computer program is run on a computer.

23. A computer program comprising program code adapted to carry out the method steps of any one of claims 8 to 13, when the computer program is run on a computer.

Images