Private key management

Abstract

Context information for a handshake between a source entity and a target entity is obtained at a security agent. The context information is transmitted from the security agent to a key manager. The key manager maintains a first private key for the security agent. 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 then transmitted to the target entity.

Description

Background Technology

[0001] This invention relates to data encryption, and more specifically, to methods, systems, and computer program products for private key management.

[0002] Currently, applications are being containerized and deployed in cloud environments, which brings security requirements. Encryption is a common strategy. For example, network traffic between an application's client and its server is typically encrypted. Summary of the Invention

[0003] Some embodiments of this disclosure can be shown as a method. The method obtains context information about a handshake between a source entity and a target entity at a security broker. The context information is transmitted from the security broker to a key manager. Here, the key manager maintains a first private key of the security broker. A first handshake message is then received from the key manager. Here, the first handshake message is generated at least based on the context information and signed with the first private key. The first handshake message is then transmitted to the target entity.

[0004] Some embodiments of this disclosure can be shown as a second method. According to the second method, context information about a handshake between a source entity and a target entity is received from a security agent at a key manager. Here, the key manager maintains a first private key of the security agent. Then, a first handshake message pointing to the target entity is generated, at least based on the context information at the key manager. Here, the first handshake message is signed with the first private key of the security agent. Next, the first handshake message is transmitted to the security agent.

[0005] Some embodiments of this disclosure can be shown as a system. The system includes a processing unit and a memory coupled to the processing unit. The memory stores instructions for performing actions when executed by the processing unit. The actions include obtaining context information of a handshake between a source entity and a target entity at a security agent. The actions also include transmitting the context information from the security agent to a key manager. Here, the key manager maintains a first private key for the security agent. The actions also include receiving a first handshake message from the key manager. Here, the first handshake message is generated at least based on the context information and signed with the first private key. The actions also include transmitting the first handshake message to the target entity.

[0006] Some embodiments of this disclosure can be shown as a computer program product. This computer program product is tangibly stored on a non-transient machine-readable medium and includes machine-executable instructions. When executed on a device, the machine-executable instructions cause the device to perform actions. These actions include obtaining context information of a handshake between a source entity and a target entity at a security agent. The actions also include transmitting the context information from the security agent to a key manager. Here, the key manager maintains a first private key for the security agent. The actions also include receiving a first handshake message from the key manager. Here, the first handshake message is generated at least based on the context information and signed with the first private key. The actions also include transmitting the first handshake message to the target entity.

[0007] The above overview is not intended to describe every illustrated embodiment or implementation of this disclosure. Attached Figure Description

[0008] The accompanying drawings included in this application are incorporated in and form a part of the specification. They illustrate embodiments of the present disclosure and, together with the specification, serve to explain the principles of the disclosure. The drawings are merely illustrative of certain embodiments and do not limit the scope of the disclosure. The features and advantages of various embodiments of the claimed subject matter will become clear as we proceed with the following detailed description, and upon reference to the accompanying drawings, in which like reference numerals denote like parts, and wherein:

[0009] Figure 1 A cloud computing node according to an embodiment of the present invention is shown.

[0010] Figure 2 A cloud computing environment according to an embodiment of the present invention is shown.

[0011] Figure 3 An abstract model layer according to an embodiment of the present invention is shown.

[0012] Figure 4 An environment in which embodiments of this disclosure can be implemented is shown.

[0013] Figure 5 A diagram illustrating an example process for private key management according to some embodiments of this disclosure is shown.

[0014] Figure 6 A diagram illustrating an example process for private key management according to some embodiments of this disclosure is shown.

[0015] Figure 7 A diagram illustrating an example process for private key management according to some embodiments of this disclosure is shown.

[0016] Figure 8 A flowchart of an exemplary method according to some embodiments of the present disclosure is shown.

[0017] Figure 9 A flowchart of an exemplary method according to some embodiments of the present disclosure is shown.

[0018] Figure 10 A high-level block diagram of an exemplary computer system that can be used to implement embodiments of the present disclosure is shown.

[0019] While the invention may be adapted to various modifications and alternatives, its details have been illustrated by way of example in the accompanying drawings and will be described in detail. However, it should be understood that the invention is not limited to the specific embodiments described. Rather, the invention is intended to cover all modifications, equivalents, and substitutions that fall within its scope. Detailed Implementation

[0020] 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 implemented in various ways and should therefore not be construed as limiting oneself to the embodiments disclosed herein.

[0021] It should be understood that while this disclosure includes a detailed description of cloud computing, the implementation of the teachings cited herein is not limited to cloud computing environments. Rather, embodiments of the invention can be implemented in conjunction with any other type of computing environment now known or developed hereafter.

[0022] Cloud computing is a service delivery model that enables convenient, on-demand access to a shared pool of configurable computing resources (e.g., a shared pool of configurable computing resources). These resources include networks, network bandwidth, servers, processing power, storage, applications, virtual machines, and services, which can be rapidly provisioned and released with minimal management effort or interaction with the service provider. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0023] The features are as follows:

[0024] On-demand self-service: Cloud consumers can unilaterally and automatically provide computing power, such as server time and network storage, as needed, without requiring human interaction with the service provider.

[0025] Extensive network access: Capabilities are available through networks and accessed via standard mechanisms that facilitate the use of heterogeneous thin client or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0026] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a sense of location independence because consumers typically do not have control or knowledge of the exact location of the resources provided, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0027] Rapid flexibility: The ability to provide capacity quickly and flexibly, automatically scaling down and up rapidly in some situations to scale up rapidly. For consumers, the available supply capacity often appears unlimited and can be purchased in any quantity at any time.

[0028] Measuring services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the service type (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both service providers and consumers.

[0029] The service model is as follows:

[0030] Software as a Service (SaaS): This provides consumers with the ability to use the provider's applications running on cloud infrastructure. Applications can be accessed from different client devices via thin client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application capabilities, with possible exceptions such as limited user-specific application configuration settings.

[0031] Platform as a Service (PaaS): This provides consumers with the ability to deploy applications created or acquired by the consumer using programming languages ​​and tools supported by the provider onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they have control over the deployed applications and the configuration of any application hosting environment.

[0032] Infrastructure as a Service (IaaS): This provides consumers with the capability to deliver processing, storage, networking, and other basic computing resources that enable them to deploy and run arbitrary software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but rather have control over the operating system, storage, deployed applications, and potentially limited control over selected networking components (e.g., host firewalls).

[0033] The deployment model is as follows:

[0034] Private cloud: A cloud infrastructure that operates solely for an organization. It can be managed by the organization or a third party and can exist on-site or off-site.

[0035] Community cloud: A cloud infrastructure shared by several organizations and supporting a specific community with shared concerns (e.g., tasks, security requirements, policies, and compliance considerations). It can be managed by an organization or a third party and can exist on-site or off-site.

[0036] Public cloud: Makes cloud infrastructure available to the public or large industry groups and is owned by an organization that sells cloud services.

[0037] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain a single entity but are bound together by standardized or proprietary technologies that enable data and applications to be ported (e.g., cloud bursting for load balancing between clouds).

[0038] Cloud computing environments are service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure comprising a network of interconnected nodes.

[0039] See now Figure 1 The diagram illustrates an example of a cloud computing node. Cloud computing node 10 is merely one example of a suitable cloud computing node and is not intended to impose any limitation on the scope of use or functionality of the embodiments of the invention described herein. In any case, cloud computing node 10 can be implemented and / or perform any of the functions set forth above.

[0040] Within cloud computing node 10, there exists a computer system / server 12 or a portable electronic device such as a communication device, which can operate alongside many other general-purpose or special-purpose computing system environments or configurations. Examples of known computing systems, environments, and / or configurations that may be suitable for 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 consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the aforementioned systems or devices.

[0041] Computer system / server 12 can be described in the general context of computer system executable instructions (e.g., program modules) executed by the computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer system / server 12 can be implemented in a distributed cloud computing environment, where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules can reside in local and remote computer system storage media, including memory storage devices.

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

[0043] Bus 18 represents any one or more of several types of bus architectures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses using any of the various bus architectures. By way of example and not limitation, such architectures include Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses.

[0044] Computer system / server 12 typically includes various computer system readable media. Such media can be any available media that can be accessed by computer system / server 12, and includes volatile and non-volatile media, removable and non-removable media.

[0045] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Computer system / server 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown, and generally referred to as "hard disk drives"). Although not shown, disk drives for reading from or writing to removable non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable non-volatile optical disks (such as CD-ROMs, DVD-ROMs, or other optical media) may be provided. In such cases, each may be connected to bus 18 via one or more data media interfaces. As will be further described and illustrated below, memory 28 may include at least one program product having at least one set of program modules configured to perform embodiments of the invention.

[0046] By way of example and not limitation, a program / utility 40 having a set (at least one) of program modules 42, along with an operating system, one or more applications, other program modules, and program data, may be stored in memory 28. Each or some combination of the operating system, one or more applications, other program modules, and program data may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods of embodiments of the invention as described herein.

[0047] Computer system / server 12 may also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.); one or more devices that enable users to interact with computer system / server 12; and / or any device that enables computer system / server 12 to communicate with one or more other computing devices (e.g., network interface card, modem, etc.). This communication may be performed via input / output (I / O) interface 22. Furthermore, computer system / server 12 may communicate with one or more networks, such as local area networks (LANs), general-purpose wide area networks (WANs), and / or public networks (e.g., the Internet), via network adapter 20. As shown, network adapter 20 communicates with other components of computer system / server 12 via bus 18. It should be understood that, although not shown, other hardware and / or software components may be used in conjunction with computer system / server 12. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archiving storage systems.

[0048] See now Figure 2 This describes an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 to which local computing devices used by cloud consumers can communicate. These local computing devices include, for example, personal digital assistants (PDAs) or cellular phones 54A, desktop computers 54B, laptop computers 54C, and / or automotive computer systems 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platforms, and / or software as services that cloud consumers do not need to maintain on their local computing devices. It should be understood that... Figure 2 The types of computing devices 54A-N shown are intended to be illustrative only, and computing node 10 and cloud computing environment 50 can communicate with any type of computerized device via any type of network and / or network-addressable connectivity (e.g., using a web browser).

[0049] See now Figure 3 This demonstrates a cloud computing environment of 50 ( Figure 2 This provides a set of functional abstractions. It should be understood beforehand. Figure 3 The components, layers, and functions shown are intended to be illustrative only, and embodiments of the invention are not limited thereto. As described, the following layers and corresponding functions are provided:

[0050] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: a mainframe 61; a RISC (Reduced Instruction Set Computer) based server 62; a server 63; a blade server 64; a storage device 65; and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0051] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 71; virtual storage 72; virtual network 73, including virtual private network; virtual application and operating system 74; and virtual client 75.

[0052] In one example, management layer 80 may provide the following functionalities: Resource Provisioning 81 provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and Pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User Portal 83 provides access to the cloud computing environment for consumers and system administrators. Service Level Management 84 provides cloud resource allocation and management to ensure that required service levels are met. Service Level Agreement (SLA) Planning and Fulfillment 85 provides pre-scheduling and procurement of cloud resources based on anticipated future needs according to the SLA.

[0053] Workload layer 90 provides examples of functionalities that can be leveraged in a cloud computing environment. Examples of workloads and functionalities that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics and processing 94; transaction processing 95; and private key management 96.

[0054] In cloud environments, traffic is typically encrypted. However, this introduces its own security risks: malicious traffic is often also encrypted and can potentially attack servers unnoticed. Cloud security agents can be introduced to mitigate such security threats. A cloud security agent can be a containerized proxy product situated between the client and the server. The cloud security agent can observe and detect encrypted traffic to identify malicious behavior and content. To do this, and transparently to the client, the cloud security agent's public key may need to be trusted by the client, and the cloud security agent needs to use a paired private key to authenticate itself to the client.

[0055] Meanwhile, in a cloud environment, a cloud security agent can be implemented using one or more container instances. However, storing private keys within container instances can increase the risk of private key leakage. Furthermore, assigning private keys to container instances can be relatively complex, as container instances may change frequently in a cloud environment to meet varying workloads.

[0056] This invention provides a private key management scheme. Generally, according to embodiments of this disclosure, a key manager, rather than a security agent, maintains the private key of the security agent and processes handshake messages requiring that private key. The security agent obtains the context information of the handshake between the source and target entities and transmits it to the key manager. The handshake message is generated by the key manager based on the context information and signed with the private key of the security agent. The handshake message is then transmitted to the security agent and forwarded by the security agent to the target entity.

[0057] In this embodiment of the invention, a centralized system with enhanced security is proposed. In this way, the security agent does not need to store, manage, or protect its private key. The security agent's private key can be stored centrally instead of being distributed to container instances. This can advantageously reduce the risk of private key leakage. A more secure cloud environment can be achieved through the proposed solution. Furthermore, using a centralized system, there is no need for separate configuration of the security agent's private key, and changes to the security agent's configuration can be handled at the key manager. This makes it easier to update and manage the security agent's private key.

[0058] In some embodiments, information about the handshake message can be prepared in advance at the security broker and key manager. Historical context information about previous handshakes involving the source entity can be obtained in advance. Once the handshake is initiated by the target entity, the key manager can generate the handshake message without waiting for a response from the source entity. In such embodiments, the time required for the handshake can be reduced, and the transaction flow between the source and target entities can be improved. In this way, a more efficient handshake can be achieved.

[0059] The advantages described above can be achieved even if the security agent is not deployed in a cloud environment. Further advantages of this disclosure will now be described with reference to exemplary embodiments and accompanying drawings.

[0060] Figure 4 An environment 400 that can implement embodiments of the present disclosure is shown. It should be understood that the structure and function of environment 400 are described for illustrative purposes only and do not imply any limitation on the scope of the present disclosure. Generally, environment 400 includes target entity 410, source entity 420, security agent 430, and key manager 440.

[0061] like Figure 4 As shown, security proxy 430 is located between target entity 410 and source entity 420. Specifically, security proxy 430 can act as an authorized entity that establishes a first secure connection between target entity 410 and security proxy 430, and a second secure connection between security proxy 430 and source entity 420. Using these two secure connections, security proxy 430 can receive encrypted communication from target entity 410 through the first secure connection. If the encrypted communication is directed to source entity 420, security proxy 430 can forward the communication to source entity 420 through the second secure connection. When receiving encrypted communication from source entity 420 through the second secure connection, the reverse process can be performed. As an example, security proxy 430 can be configured to provide Transport Layer Security (TLS). In such an example, security proxy 430 can be a TLS proxy.

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

[0063] The target entity 410 and the source entity 420 can be any suitable entity that communicates with each other via the security broker 430. In some embodiments, one of the target entity 410 and the source entity 420 can be a client, while the other of the target entity 410 and the source entity 420 can be a server. As an example, without any limitation on the scope of this disclosure, the target entity 410 can be a TLS client, and the source entity 420 can be a TLS server.

[0064] For communication between them, such as for exchanging application data, a handshake is required between target entity 410 and source entity 420. Due to the presence of security broker 430, the handshake may include a handshake sequence between target entity 410 and security broker 430, and another handshake sequence between source entity 420 and security broker 430. One or more handshake messages transmitted between target entity 410, security broker 430, and source entity 420 may need to be signed with the sender's private key. For example, handshake messages used for certificate verification may need to be signed with the sender's private key.

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

[0066] like Figure 4As shown, the key manager 440 can communicate with the security agent 430 via a secure connection. The key manager 440 is configured to maintain the private key 450 of the security agent 430 and process messages requesting the private key 450 on behalf of the security agent 430. The key manager 440 can be implemented in any suitable manner. For example, the key manager 440 can be implemented by a component in a cloud environment. Alternatively, the key manager 440 can be implemented by one or more devices (e.g., servers).

[0067] Key manager 440 is configured to receive context information of the handshake between source entity 420 and target entity 410 from security agent 430, and to generate a handshake message based at least on the context information and private key 450. As used herein, the term "context information" in the handshake refers to at least a portion of the information that has been exchanged during the handshake, such as messages that have already been communicated between target entity 410, security agent 430, and source entity 420.

[0068] In some embodiments, key manager 440 may store historical context information 460 relating to 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 agent 430 may also store historical context information 460.

[0069] Figure 4 The number of elements shown is for illustrative purposes only; any suitable number of elements may exist. For example, there may be more entities served by security agent 430. Key manager 440 may maintain private keys for more than one security agent.

[0070] Figure 5 A diagram illustrating an example process 500 for private key management according to some embodiments of this disclosure is shown. Figure 5 As shown, process 500 may involve target entity 511, security agent 531, key manager 541, and source entity 521. For example... Figure 4 As shown, these components can correspond to target entity 410, security agent 430, key manager 440 and source entity 420, respectively.

[0071] For mutual authentication, a handshake can be initiated between target entity 511 and source entity 521. The handshake message is transmitted between target entity 511 and source entity 521 via security broker 531. The handshake message (also known as the "first handshake message"), such as the message used for certificate verification, may require the private key of security broker 531 (also known as the "first private key").

[0072] Security agent 531 obtains (510) the context information of the handshake between source entity 521 and target entity 511, and then transmits (515) the context information to 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 transmitted between target entity 511, security agent 531 and source entity 521 during the handshake.

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

[0074] Upon receiving the second handshake message, the security agent 531 may transmit the second handshake message to the key manager 541. Additionally, in some embodiments, the security agent 531 may further transmit the handshake key used between the target entity 511 and the security agent 531 to the key manager 541. The handshake key can be determined based on key exchange information from the target entity 511. Thus, the key manager 541 can use the handshake key to encrypt the first handshake message. The following will refer to... Figure 6 Examples describing these implementation methods.

[0075] In some embodiments, the security agent 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 agent 531. For example, the first hello message may include at least a key-sharing entry indicating parameters for key exchange with the security agent 531.

[0076] Once the first greeting message is received from the target entity 511, the security agent 531 can send the first greeting message to the key manager 541. Furthermore, in some embodiments, the security agent 531 may have pre-prepared some information needed to generate the first handshake message. The security agent 531 may obtain historical context information (e.g., such as historical handshakes involving the source entity 521) before receiving the first greeting message. Figure 4The historical context information shown is 460. The historical context information may include greeting messages from source entity 521, certificates of source entity 521, and any relevant handshake messages from source entity 521.

[0077] Historical context information can be obtained during any appropriate historical handshake involving source entity 521. As an example, historical context information can be obtained when security broker 531 first serves a handshake involving source entity 521. As another example, historical context information can be obtained during the most recent handshake involving source entity 521.

[0078] In some embodiments, once the historical context information is obtained, it can be transmitted to the key manager 541. In some embodiments, the historical context information can be transmitted to the key manager 541 along with the first greeting message. The following will refer to... Figure 7 Examples describing these implementation methods.

[0079] Upon receiving (515) context information from security agent 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 agent 531. The private key may, for example, correspond to... Figure 4 The private key 450 is shown. For example, the key manager 541 can generate a signature for the security agent 531 based on the first private key and include that signature in the first handshake message.

[0080] In the above embodiments where the second handshake message is received as context information from the source entity 521, the key manager 541 may generate (520) the 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 agent 531.

[0081] Furthermore, if the handshake key used between the target entity 511 and the security agent 531 is sent to the key manager 541, the key manager 541 can use the handshake key to encrypt the first handshake message.

[0082] In the above embodiments, upon receiving (515) a first greeting message from target entity 511 as context information, key manager 541 can generate (520) a first handshake message based on the first greeting message and historical context information. Key manager 541 can generate a signature of security agent 531 based on the first private key and include the signature in the first handshake message. In these embodiments, the first greeting message can provide information about target entity 511, while the historical context information can provide information about source entity 521.

[0083] Furthermore, if a set of parameters for determining the handshake key used between the target entity 511 and the security agent 531 is sent from the security agent 531 to the key manager 541, the key manager 541 can determine the handshake key based on the parameter set and the first greeting message. For example, the set of parameters may include key-sharing entries determined by the security agent 531, and the first greeting message may include another key-sharing entry determined by the target entity 511. The handshake key can be determined based on these key-sharing entries. The key manager 541 can then encrypt the first handshake message using the handshake key.

[0084] After generating (520) the first handshake message, the key manager 541 transmits (525) the first handshake message to the security agent 531. Then, the security agent 531 transmits (530) the first handshake message to the target entity 511. If the first handshake message received from the key manager 541 has been encrypted with the handshake key, the security agent 531 can directly forward (530) the first handshake message to the target entity 511. If the first handshake message received from the key manager 541 has not been encrypted with the handshake key, the security agent 531 can first encrypt the first handshake message with the handshake key and transmit (530) the encrypted first handshake message to the target entity 511.

[0085] like Figure 5 As shown, the handshake between source entity 521 and target entity 511 continues the subsequent process. For example, a handshake sequence between target entity 511 and security agent 531 can be executed (535). A handshake sequence between source entity 521 and security agent 531 can be executed (540).

[0086] In this embodiment of the invention, the security agent is not required to store, manage, and protect the private key. The security agent's private key can be stored centrally instead of being distributed to container instances. This reduces or even eliminates the risk of private key leakage, thus achieving a more secure cloud environment. Furthermore, using a centralized system, updates and management of the security agent can be handled at the key manager. This makes updating and managing the security agent's private key easier.

[0087] As described above, in some embodiments, the second handshake message from source entity 521 can be used as context information. Now refer to... Figure 6 . Figure 6 A diagram illustrating an example process 600 for private key management according to some embodiments of this disclosure is shown. Process 600 can be considered as a possible implementation of process 500. Figure 6 As shown, process 600 may involve target entity 611, security agent 631, key manager 641, and source entity 621. For example... Figure 4As shown, these components may correspond to target entity 410, security agent 430, key manager 440, and source entity 420, respectively. For discussion purposes only and without limiting the scope of this disclosure, in process 600, source entity 621 is a server, target entity 611 is a client, and the first and second handshake messages are CV messages.

[0088] like Figure 6 As shown, target entity 611 may transmit a (605) client greeting message (also referred to as the "first client greeting message") to security agent 631 to initiate a handshake between target entity 611 and source entity 621. The first client greeting message may include at least a key-sharing entry (also referred to as the "first key-sharing entry") indicating parameters used for key exchange with security agent 631. The first client greeting message may further include other key exchange information, such as protocol version and encryption algorithm.

[0089] Security agent 631 can determine (610) another key-sharing entry (also referred to as a "second key-sharing entry") that indicates the parameters used for key exchange with source entity 621. Security agent 631 can generate an updated client greeting message (also referred to as a "second client greeting message") by replacing the first key-sharing entry with the second key-sharing entry, and then transmit the second client greeting message (615) to source entity 621.

[0090] Upon receiving the second client greeting message, source entity 621 may transmit (620) a server greeting message (also referred to as the "first server greeting message") to security agent 631 in response. The first server greeting message may include at least a key-sharing entry (also referred to as the "third key-sharing entry") indicating the parameters used for key exchange with security agent 631.

[0091] Security agent 631 may determine (625) another key-sharing entry (also referred to as a "fourth key-sharing entry") that indicates parameters used for key exchange with target entity 611. Security agent 631 may determine (630) a first handshake key used between target entity 611 and security agent 631 based on the first and fourth key-sharing entries, and a second handshake key used between source entity 621 and security agent 631 based on the second and third key-sharing entries. Security agent 631 may transmit (635) another server greeting message (referred to as a "second server greeting message") to target entity 611. The second greeting message may include at least the fourth key-sharing entry.

[0092] After transmitting (620) the first server greeting message to security agent 631, source entity 621 may transmit (640) its certificate, which in this example is a server certificate, to security agent 631. Security agent 631 may then forward (645) the server certificate to target entity 611.

[0093] Source entity 621 may further transmit a message 650 for verifying the server certificate (also referred to as the “raw CV message”) to security agent 631. Security agent 631 may send the raw CV message (655) to key manager 641 as context information. In some embodiments, security agent 631 may further transmit the first handshake key used between target entity 611 and security agent 631 to key manager 641. Security agent 631 may transmit other relevant context information to key manager 641.

[0094] Then, key manager 641 can generate (660) a new CV message based on the original CV message and a private key (not shown). The private key may correspond to, for example, a message such as... Figure 4 The private key 450 is shown. 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 using the private key.

[0095] Then, key manager 641 can transmit (665) the new CV message to security agent 631. Security agent 631 can forward (670) the new CV message to target entity 611. Figure 6 As shown, the handshake between source entity 621 and target entity 611 continues the subsequent process. For example, a handshake sequence between target entity 611 and security agent 631 can be performed (675). A handshake sequence between source entity 621 and security agent 631 can be performed (680).

[0096] It has been recognized that the source and target entities (e.g., TLS server and TLS client) can remain substantially unchanged, so the only difference between handshakes is the parameters used for key exchange, such as key-sharing entries. Therefore, in some embodiments, some information needed to generate the first handshake message can be prepared in advance.

[0097] Figure 7 A diagram illustrating an example process 700 for private key management according to some embodiments of this disclosure is provided. Process 700 can be considered as another possible implementation of process 500. Figure 7 As shown, process 700 may involve target entity 711, security agent 731, key manager 741, and source entity 721. For example... Figure 4As shown, these components may correspond to target entity 410, security agent 430, key manager 440, and source entity 420, respectively. For the purpose of discussion only and without any limitation on 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.

[0098] like Figure 7 As shown, security agent 731 can obtain (705) historical context information of the historical handshake involving source entity 721 (e.g., such as...). Figure 4 The historical context information 460 is shown. In this example, the historical context information may include a server greeting message (also referred to as a "previous server greeting message") from source entity 721 and a server certificate (also referred to as a "previous server certificate") from source entity 721. For example, when security agent 731 first serves a handshake involving source entity 721 or during a recent handshake involving source entity 721, security agent 731 may receive a previous server greeting message and a previous server certificate from source entity 721.

[0099] The security agent 731 can transmit (710) historical context information to the key manager 741. The key manager 741 can store (715) the historical context information in, for example, a cache or any suitable storage device.

[0100] In some embodiments, the security agent 731 may predetermine key-sharing entries indicating parameters for key exchange with the source entity 721 and the target entity 711. For example, the security agent 731 may prepare in advance a fifth key-sharing entry indicating parameters for key exchange with the source entity 721 and a sixth key-sharing entry indicating parameters for key exchange with the target entity 711. Furthermore, the security agent 731 may transmit the prepared key-sharing entries to the key manager 741.

[0101] Thus, the security agent 731 and key manager 741 can prepare for the handshake between the target entity 711 and the source entity 721. Figure 7 As shown, target entity 711 may transmit a (720) client greeting message (also referred to as the “original client greeting message”) to security agent 731 to initiate a handshake between target entity 711 and source entity 721. The original client greeting message may include at least a seventh key-sharing entry, which indicates the parameters used for key exchange with security agent 731.

[0102] Upon receiving the original client greeting message (720) from the target entity 711, two sub-procedures 701 and 702 can be executed. Although in Figure 7Subprocesses 701 and 702 are described sequentially, but this is merely for illustrative purposes; 701 and 702 can be executed in parallel. In subprocess 701, the security agent 731 can directly transmit (725) the original client greeting message to the key manager 741. The key manager 741 can generate (730) a first CV message signed with a private key (not shown). The private key may correspond, for example, to... Figure 4 The private key 450 is shown. For example, a first CV message can be generated based on the original client greeting message, a previous server greeting message, and a previous server certificate. The first CV message may include a signature of the security agent 731 generated based on the first private key.

[0103] In some embodiments, if a sixth key-sharing entry indicating parameters for key exchange with target entity 711 is transmitted to key manager 741, key manager 741 can determine the handshake key (also referred to as the "third handshake key") used between target entity 711 and security agent 731 based on the sixth and seventh key-sharing entries in the original client greeting message. Key manager 741 can encrypt the first CV message with the third handshake key. Next, key manager 741 can transmit (735) the first CV message to security agent 731.

[0104] like Figure 7 As shown, upon receiving (720) the original client greeting message from target entity 711, security agent 731 may determine (740) the third handshake key based on the sixth and seventh key sharing entries in the original client greeting message. In some embodiments, security agent 731 may generate a server greeting message (which may be referred to as a "second greeting message") as a response to the original client greeting message. This server greeting message may be generated based on a previous server greeting message and includes a pre-prepared sixth key sharing entry. Security agent 731 may then transmit (745) the server greeting message to target entity 711. Security agent 731 may also transmit (750) the first CV message and the previous server certificate to target entity 711.

[0105] Subprocess 702 is now described. After receiving the original client greeting message (720) from the target entity 711, the security agent 731 can generate a new client greeting message based on the original client greeting message and a pre-prepared fifth key-sharing entry. This new client greeting message can be generated by replacing the seventh key-sharing entry in the original client greeting message with the fifth key-sharing entry. The security agent 731 can then transmit the new client greeting message (755) to the source entity 721.

[0106] In response, source entity 721 may transmit a server greeting message (760) to security agent 731. This server greeting message may include an eighth key-sharing entry indicating parameters for key exchange with security agent 731. Security agent 731 may determine (765) the handshake key used between source entity 721 and security agent 731 based on the fifth and eighth key-sharing entries. Subsequently, source entity 721 may transmit (770) a new server certificate and (775) a new CV message to security agent 731. In some embodiments, the server greeting message and the new server certificate may be used to update historical context information. For example, the new server certificate may replace the previous server certificate. Thus, subprocess 702 can be considered complete.

[0107] like Figure 7 As shown, after completing sub-procedures 701 and 702, the handshake between the source entity 721 and the target entity 711 continues with subsequent processes. For example, a handshake sequence between the target entity 711 and the security agent 731 can be executed (780). A handshake sequence between the source entity 721 and the security agent 731 can be executed (785).

[0108] In such an embodiment, the handshake sequence between the target entity 711 and the security agent 731, as shown in subprocess 701, can be performed using the previous server greeting message and the previous server certificate. The security agent 731 does not need to wait for new server greeting messages and new CV messages from the source entity 721. This reduces the time required for the handshake and improves its efficiency.

[0109] Figure 8 A flowchart depicts an exemplary method 800 according to some embodiments of the present disclosure. For example, method 800 can be implemented as follows: Figure 4 The security agent 430 shown is implemented. It should be understood that method 800 may also include additional boxes (not shown) and / or the boxes shown may be omitted. The scope of this disclosure described herein is not limited to this aspect.

[0110] In box 810, security agent 430 obtains the context information of the handshake between the source entity and the target entity. In box 820, the security agent transmits the context information to the key manager. The key manager maintains the security agent's first private key. In box 830, the security agent receives the first handshake message from the key manager. The first handshake message is generated based at least on the context information and signed with the first private key. In box 840, security agent 430 transmits the first handshake message to the target entity.

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

[0112] In some embodiments, the security agent may receive a first greeting message from the target entity as at least part of the context information. The first greeting message is directed to the source entity for initiating a handshake. In some embodiments, the security agent may further obtain historical context information involving previous handshakes of the source entity and transmit this historical context information to the key manager. For example, the historical context information may include a server greeting and 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 greeting message.

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

[0114] In some embodiments, the security agent may further transmit a set of parameters to the key manager for determining the handshake key to be used between the security agent and the target entity. In these embodiments, the first handshake message may be encrypted using the handshake key determined based on this set of parameters and the first greeting message.

[0115] Figure 9 A flowchart illustrating an exemplary method 900 according to some embodiments of the present disclosure is provided. For example, method 900 can be implemented in a key manager (such as...) Figure 4 The method is implemented at the key manager 440 shown. It should be understood that method 900 may also include additional boxes (not shown) and / or the boxes shown may be omitted. The scope of this disclosure described herein is not limited to this aspect.

[0116] At box 910, the key manager receives context information about the handshake between the source and target entities from the security broker. At box 920, the key manager generates a first handshake message pointing to the target entity, based at least on the context information. The first handshake message is signed using the first private key of the security broker maintained by the key manager. At box 930, the key manager transmits the first handshake message to the security broker.

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

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

[0119] In some embodiments, the key manager may also receive a set of parameters from the security agent to determine the handshake key to be used between the security agent and the target entity, and determine the handshake key based on the parameter set and the first greeting message. The key manager may use the handshake key to encrypt the first handshake message.

[0120] The processing of private key management or security agent / key manager according to embodiments of this disclosure can be performed by... Figure 1 The computer system / server 12 is implemented.

[0121] Now for reference Figure 10 This illustration shows a high-level block diagram of an exemplary computer system 1000 that can be configured to perform various aspects of this disclosure (e.g., including processes 800 and 900). According to embodiments of this disclosure, the example computer system 1000 can be used to implement one or more of the methods or modules described herein, and any associated functions or operations (e.g., using one or more processor circuits including a computer or a collection of processors including computer processors). Actions performed by a set of processors can be performed by a single processor, one of a set of processors, all processors in a set 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 directly or indirectly communicatively coupled to enable inter-component communication via a memory bus 1006, an I / O bus 1014, and an I / O bus interface unit 1012.

[0122] 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, collectively referred to herein as CPU 1002. In some embodiments, computer system 1000 may include multiple processors typical of a relatively large system; however, 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 core 1004 and may include one or more levels of on-board cache.

[0123] In some embodiments, memory subsystem 1008 may include random access semiconductor memory, storage devices, or storage media (volatile or non-volatile) for storing data and programs. In some embodiments, memory subsystem 1008 may represent the entire virtual memory of computer system 1000 and may also include virtual memory coupled to computer system 1000 or other computer systems connected via a network. Memory subsystem 1008 may conceptually be a single monolithic entity, but in some embodiments, memory subsystem 1008 may be a more complex arrangement, such as a hierarchy of caches and other memory devices. For example, memory may reside in multi-level caches, and these caches may be further functionally partitioned such that one cache holds instructions while another cache holds non-instruction data used by one or more processors. As known in any of the various computer architectures known as Non-Unified Memory Access (NUMA), memory may be further distributed and associated with different CPUs or sets of CPUs. In some embodiments, main memory or memory subsystem 804 may include elements for control and flow of memory used by CPU 1002. This may include memory controller 1010.

[0124] Although the memory bus 1006 is Figure 10While shown as a single bus structure providing a direct communication path between CPU 1002, memory subsystem 1008, and I / O bus interface 1012, in some embodiments, memory bus 1006 may include multiple different buses or communication paths that can be arranged in any of a variety of forms, such as point-to-point links in a hierarchical, star, or network configuration, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. Furthermore, although I / O bus interface 1012 and I / O bus 1014 are shown as a single corresponding unit, in some embodiments, computer system 1000 may include multiple I / O bus interface units 1012, multiple I / O buses 1014, or both. Further, although multiple I / O interface units separating I / O bus 1014 from different communication paths running to different I / O devices are shown, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0125] In some embodiments, computer system 1000 may be a multi-user mainframe computer system, a single-user system, a server computer, or a 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, portable computer, laptop or notebook computer, tablet computer, pocket computer, telephone, smartphone, mobile device, or any other suitable type of electronic device.

[0126] It is important to note that Figure 10 This description aims to depict representative major components of an exemplary computer system 1000. However, in some embodiments, a single component may have more than Figure 10 The greater or lesser complexity represented therein can exist differently from... Figure 10 The components shown or excluding Figure 10 Components other than those shown, and the number, type, and configuration of such components can vary.

[0127] This invention can be a system, method, and / or computer program product with any possible level of technical detail integration. The computer program product may include a computer-readable storage medium having computer-readable program instructions thereon for causing a processor to execute aspects of the invention.

[0128] Computer-readable storage media can be tangible means for retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital universal disc (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or protrusions in slots having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0129] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the suitable computing / processing device.

[0130] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as a standalone software package, partially on a user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, 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, programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may execute computer-readable program instructions by utilizing state information from the computer-readable program instructions to personalize the electronic circuitry in order to perform aspects of this invention.

[0131] The present invention will now be described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should 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.

[0132] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner, such that the computer-readable storage medium storing the instructions includes an article of manufacture containing instructions that implement aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0133] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, such that the instructions executed on the computer, other programmable apparatus, or other device perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0134] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than indicated in the figures. For example, two blocks shown consecutively may actually be completed as a single step, executed simultaneously, substantially simultaneously, or with partial or complete temporal overlap, or the blocks may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0135] Various embodiments of this disclosure have been described for illustrative purposes, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to explain the principles of the embodiments, their practical application, or technical improvements to technologies found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for private key management, comprising: In the first message from the source entity and the second message from the target entity, a set of processors at the security broker obtains the context information of the handshake between the source entity and the target entity; A set of processors at the security agent transmits the context information from the security agent to a key manager, the key manager maintaining the first private key of the security agent; A set of processors at the security broker transmits historical context information concerning the historical handshakes of the source entity to the key manager; A set of processors at the security broker receives a first handshake message from the key manager, the first handshake message being generated based at least on the context information and the historical context information and signed with the first private key; as well as The first handshake message is transmitted to the target entity by a set of processors at the security broker.

2. The method according to claim 1, wherein, Obtaining the context information includes: A set of processors at the security broker receives a second handshake message from the source entity as at least part of the context information. The second handshake message is directed to the target entity and signed with the source entity's second private key.

3. The method according to claim 2, further comprising: A set of processors at the security agent transmits the handshake key used between the security agent and the target entity to the key manager, wherein the first handshake message is encrypted with the handshake key.

4. The method according to claim 1, wherein, Obtaining the context information includes: A set of processors at the security broker receives a first greeting message from the target entity as at least part of the context information, the first greeting message being directed to the source entity for initiating the handshake.

5. The method according to claim 4, wherein the first handshake message is also generated based on the first greeting message.

6. The method of claim 5, further comprising: A set of processors at the security agent determines a second greeting message as a response to the first greeting message based on the historical context information; as well as The second greeting message is transmitted to the target entity by a set of processors at the security agent.

7. The method of claim 4, further comprising: A set of processors at the security agent transmits a set of parameters to the key manager for determining a handshake key to be used between the security agent and the target entity, wherein the first handshake message is encrypted with the handshake key determined based on the set of parameters and the first greeting message.

8. A method for private key management, comprising: A set of processors at the key manager receives context information of the handshake between the source entity and the target entity from the security broker, wherein the context information is a set of two or more messages between the source entity and the target entity; A set of processors at the key manager receives historical context information about the historical handshakes of the source entity from the security broker. A set of processors at the key manager generates a first handshake message pointing to the target entity based at least on the context information and the historical context information. The first handshake message is signed using a first private key of the security agent maintained by the key manager. as well as The first handshake message is transmitted to the security agent by a set of processors at the key manager.

9. The method according to claim 8, wherein, Receiving the context information includes: A set of processors at the key manager receives a second handshake message from the security agent as at least part of the context information. The second handshake message is directed to the target entity and signed with the source entity's second private key.

10. The method of claim 9, further comprising: A set of processors at the key manager receives from the security agent the handshake key used between the security agent and the target entity; Generating the first handshake message includes encrypting the first handshake message using the handshake key by a set of processors at the key manager.

11. The method according to claim 8, wherein, Receiving the context information includes: A set of processors at the key manager receives a first greeting message from the security agent as at least part of the context information, the first greeting message being directed to the source entity for initiating the handshake.

12. The method according to claim 11, The first handshake message is also generated based on the first greeting message.

13. The method of claim 11, further comprising: A set of processors at the key manager receives from the security agent a set of parameters for determining the handshake key used between the security agent and the target entity; as well as The handshake key is determined by a set of processors at the key manager based on the set of parameters and the first greeting message; Generating the first handshake message includes encrypting the first handshake message using the handshake key by a set of processors at the key manager.

14. A system for private key management, comprising: processor; as well as Memory, communicating with the processor, the memory containing program instructions that, when executed by the processor, are configured to cause the processor to: In the first message from the source entity and the second message from the target entity, the security broker obtains the context information of the handshake between the source entity and the target entity; The context information is transmitted from the security agent to the key manager, which maintains the first private key of the security agent. Transmit historical context information relating to the historical handshakes of the source entity to the key manager; Receive a first handshake message from the key manager, the first handshake message being generated based at least on the context information and the historical context information and signed with the first private key; as well as The first handshake message is transmitted to the target entity.

15. The system according to claim 14, wherein, Obtaining the context information includes receiving a second handshake message from the source entity as at least a part of the context information, the second handshake message being directed to the target entity and signed with the source entity's second private key.

16. The system according to claim 15, wherein, The processor is also configured to transmit a handshake key used between the security agent and the target entity to the key manager, wherein the first handshake message is encrypted with the handshake key.

17. The system according to claim 14, wherein, Obtaining the context information includes receiving a first greeting message from the target entity as at least a part of the context information, the first greeting message being directed to the source entity for initiating the handshake.

18. The system of claim 17, wherein the first handshake message is also generated based on the first greeting message.

19. The system according to claim 18, wherein, The processor is also configured to: Based on the historical context information, a second greeting message is determined as a response to the first greeting message; and The second greeting message is transmitted to the target entity.

20. The system according to claim 17, wherein, The processor is also configured to: A set of parameters for determining a handshake key to be used between the security agent and the target entity is transmitted to the key manager, the first handshake message being encrypted with the handshake key determined based on the set of parameters and the first greeting message.

21. A system for private key management, comprising: processor; as well as Memory, communicating with the processor, the memory containing program instructions that, when executed by the processor, are configured to cause the processor to: At the key manager, context information of the handshake between the source entity and the target entity is received from the security agent, wherein the context information is a set of two or more messages between the source entity and the target entity; At the key manager, historical context information relating to the historical handshakes of the source entity is received from the security agent; At the key manager, a first handshake message pointing to the target entity is generated based at least on the context information and the historical context information. The first handshake message is signed using the first private key of the security agent maintained by the key manager. as well as At the key manager, the first handshake message is transmitted to the security agent.

22. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7.

23. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 8 to 13.

Images