Method and apparatus for migrating private hardware security keys

Abstract

Methods, non-transitory computer-readable media, network traffic manager devices, and systems to assist in migrating keys between a first hardware security system and a second hardware security system include receiving an encrypted symmetric key from the first hardware security system. A symmetric key generated by the first hardware security system is encrypted using a public key generated from a second hardware security system. The generated public key is sent to the first hardware security system before the symmetric key is encrypted. The received encrypted symmetric key is sent to the second hardware security system. An encrypted original key from the first hardware security system is received while sending the encrypted symmetric key to the second hardware security system. And encrypting the original key by using the symmetric key. When the second hardware security system uses the sent encrypted symmetric key to decrypt the sent encrypted original key, the migration is completed.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. patent application No. 18 / 146,082, filed December 23, 2022, which is hereby incorporated by reference in its entirety. Technical Field

[0003] The present technology relates to methods and systems for migrating private hardware security keys from one hardware security system to another. Background Art

[0004] A hardware security system, generally referred to as a hardware security module, is computer hardware and / or software (e.g., a computing device) that is configured to store cryptographic keys, perform cryptographic operations (such as generating keys, encrypting data, and decrypting data), and enforce security policies for using and / or accessing cryptographic keys.

[0005] A problem with hardware security systems is that different vendors or providers have different application programming interfaces (APIs) and methods for storing keys, which can create challenges when migrating secure hardware keys between different hardware security systems. Summary of the Invention

[0006] A method for migrating a private hardware security key from one hardware security system to another hardware security system, implemented in collaboration with a cloud service or a network traffic management system including one or more network traffic management modules, server modules, or client modules, comprises receiving an encrypted symmetric key from a first hardware security system. Encrypting the symmetric key generated by the first hardware security system using a public key generated from a second hardware security system. Sending the generated public key to the first hardware security system before encrypting the symmetric key. Sending the received encrypted symmetric key to the second hardware security system. Receive an encrypted raw key from the first hardware security system while sending the encrypted symmetric key to the second hardware security system. Encrypting the raw key using the symmetric key. The migration is complete when the second hardware security system decrypts the sent encrypted raw key using the sent encrypted symmetric key.

[0007] A network traffic management device includes: a memory including programming instructions stored thereon; and one or more processors configured to execute the stored programming instructions to receive an encrypted symmetric key from a first hardware security system. The device encrypts the symmetric key generated by the first hardware security system using a public key generated by a second hardware security system. The device sends the generated public key to the first hardware security system before encrypting the symmetric key. The device sends the received encrypted symmetric key to the second hardware security system. The device receives an encrypted original key from the first hardware security system while sending the encrypted symmetric key to the second hardware security system. The device encrypts the original key using the symmetric key. The migration is complete when the second hardware security system decrypts the sent encrypted original key using the sent encrypted symmetric key.

[0008] A non-transitory computer-readable medium having instructions stored thereon for performing a migration, the instructions comprising executable code that, when executed by one or more processors, causes the processors to receive an encrypted symmetric key from a first hardware security system. Encrypt the symmetric key generated by the first hardware security system using a public key generated by a second hardware security system. Send the generated public key to the first hardware security system before encrypting the symmetric key. Send the received encrypted symmetric key to the second hardware security system. Receive an encrypted raw key from the first hardware security system while sending the encrypted symmetric key to the second hardware security system. Encrypt the raw key using the symmetric key. Migration is complete when the second hardware security system decrypts the sent encrypted raw key using the sent encrypted symmetric key.

[0009] A network traffic management system includes: one or more network traffic management modules, server modules, or client modules; a memory including programming instructions stored thereon; and one or more processors configured to execute the stored programming instructions to receive an encrypted symmetric key from a first hardware security system. The system encrypts the symmetric key generated by the first hardware security system using a public key generated by a second hardware security system. The system sends the generated public key to the first hardware security system before encrypting the symmetric key. The system sends the received encrypted symmetric key to the second hardware security system. The system receives an encrypted raw key from the first hardware security system while sending the encrypted symmetric key to the second hardware security system. The system encrypts the raw key using the symmetric key. The migration is complete when the second hardware security system decrypts the sent encrypted raw key using the sent encrypted symmetric key.

[0010] The present technology offers numerous advantages, including providing methods, non-transitory computer-readable media, network traffic management devices, and network traffic management systems that facilitate supporting and orchestrating multiple hardware security systems on a backend so that the same keys are stored in different hardware security systems. The technology creates a method for securing communication encryption that can be used to improve the security of client-server architectures. Additionally, the technology advantageously provides for key migration from one hardware security system to another without requiring the private key to be stored in plaintext or unencrypted outside of the multiple hardware security systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1A to Figure 1B is a block diagram of an exemplary network traffic management system having a network traffic management device;

[0012] Figure 2 is a block diagram of an exemplary network traffic manager device;

[0013] Figure 3 is a flow chart of an exemplary method for migrating a hardware security key;

[0014] Figure 4A is an exemplary block diagram of an exemplary network traffic manager apparatus that receives a migration request from a client computing device;

[0015] Figure 4B is an exemplary block diagram of an exemplary network traffic manager device that receives a public hardware security key from a second hardware security system;

[0016] Figure 4C is an exemplary block diagram of an exemplary network traffic manager device that initiates a request to a first hardware security system to generate a symmetric key using a public hardware security key;

[0017] Figure 4D is an exemplary block diagram of an exemplary network traffic manager device that receives an encrypted symmetric key from a first hardware security system;

[0018] Figure 4E is an exemplary block diagram of an exemplary network traffic manager device that transmits a received encrypted symmetric key to a second hardware security system;

[0019] Figure 4F is an exemplary block diagram of an exemplary network traffic manager device sending a request to a first hardware security system to encrypt an original key using a symmetric key;

[0020] Figure 4G is an exemplary block diagram of an exemplary network traffic manager device that receives an encrypted raw key from a first hardware security system;

[0021] Figure 4H is an exemplary block diagram of an exemplary network traffic manager device that sends a received encrypted raw key to a second hardware security system; and

[0022] Figure 4I is an exemplary block diagram of an exemplary network traffic manager device that sends a decryption request to a second hardware security system to decrypt an encrypted original key using an encrypted symmetric key. DETAILED DESCRIPTION

[0023] This technology involves migrating keys from one hardware security system to another without storing private keys in plaintext or unencrypted form outside of the multiple hardware security systems. This technology provides a key migration service that is external to the multiple hardware security systems and can assist with key migration. The key migration service can communicate with all hardware security systems provided by major cloud providers. The key migration service is also secure because it does not have the data required to decrypt the migrated keys, as the key migration service does not have access to the private keys in the multiple hardware security systems.

[0024] Examples of the present technology include a network environment 10 having Figure 1A 、 Figure 1B and Figure 2 1 . The example environment 10 includes a network traffic manager device 20 for migrating private security hardware keys. In this example, the environment 10 includes the network traffic manager device 20, a plurality of client computing devices 40(1)-40(n), and a plurality of hardware security systems 50(1)-50(n) coupled together via a communication network 30, but the environment may include other types and numbers of systems, devices, components, and / or elements and may be in other topologies and deployments. Although not shown, the example environment 10 may include additional network components, such as routers, switches, and other devices, which are well known to those skilled in the art and are therefore not described herein.

[0025] More specifically, refer to Figure 1A and Figure 1B , the network traffic manager device 20 of the network traffic management system is coupled to a plurality of client computing devices 40(1)-40(n) via a communication network 30, but the plurality of client computing devices 40(1)-40(n) and the network traffic manager device 20 may be coupled together via other topologies. Additionally, the network traffic manager device 20 is coupled to a plurality of hardware security systems 50(1)-50(n) via a communication network 30, but the plurality of hardware security systems 50(1)-50(n) and the network traffic manager device 20 may be coupled together via other topologies. The network traffic manager device 20 may use reference Figure 2 The architecture described in more detail is implemented.

[0026] refer to Figure 1B , which depicts a block diagram of an example architecture including a client computing device 40(1) coupled to a network traffic manager appliance 20 via a communications network 30. The client computing device 40(1) may also be coupled to the network traffic manager appliance 20 using other topologies. Figure 1B Further illustrating how the network traffic manager device 20 may perform cryptographic operations by using the traffic management logic 25. In some embodiments, the network traffic manager device 20 may be offloaded to the first hardware security system 50(1) and the second hardware security system 50(2). In some embodiments, the traffic management logic 25 may offload cryptographic operations by sending requests via a multi-threaded real-time software routine that interfaces with the first hardware security system 50(1) and the second hardware security system 50(2). In some non-limiting examples, the real-time software routine may process information with time constraints. The real-time software routine may communicate with the first hardware security system 50(1) and the second hardware security system 50(2) using different HSS sessions. An HSS session may be initiated by a thread by requesting that a session be opened on a specific token of the first hardware security system 50(1) and / or the second hardware security system 50(2). The first hardware security system 50(1) and / or the second hardware security system 50(2) may return a session handle for the session, and the session handle may be used when requesting cryptographic operations to be performed by the first hardware security system 50(1) and / or the second hardware security system 50(2). The session handle and other information about the session may be stored in a data structure. After the session for a thread is opened, the thread may be used to manage cryptographic operations. In some embodiments, multiple threads may be used to concurrently perform multiple cryptographic operations on the first hardware security system 50(1) and / or the second hardware security system 50(2). Cryptographic operations may include generating a key, generating a key pair, encrypting a private key, decrypting an encrypted key, encrypting data using a key, decrypting data using a key, generating random numbers or pseudo-random numbers, and other operations known in the art. In some embodiments, the first hardware security system 50(1) may include a public key 53(1) and a private key 55(1). In other embodiments, the second hardware security system 50(2) may include a public key 53(2) and a private key 55(2). Figure 1B It further illustrates how the network traffic manager device 20 may use the traffic management logic 25 to perform cryptographic operations with the public keys 53(1)-(2) and the private keys 55(1)-(2) of the first hardware security system 50(1) and the second hardware security system 50(2).

[0027] The network traffic manager device 20 may also assist in migrating keys as illustrated and described through the examples herein, although the network traffic manager device 20 may perform other types and / or numbers of functions. Figures 4A to 4I The cryptographic operations performed by the network traffic manager device 20 to migrate the original key 54 from the first hardware security system 50(1) to the second hardware security system 50(2) are illustrated. It is understood that the network traffic manager device 20 may perform cryptographic operations other than Figures 4A to 4I Additional operations beyond those illustrated in FIG, and multiple hardware security systems 50(1)-50(n) may be utilized to perform the same illustrated operations. Figure 2 As illustrated, the network traffic manager device 20 includes a processor 21 or central processing unit (CPU) 18, memory 22, optional configurable hardware logic 26, and a communication system 24 coupled together by a bus arrangement 19, but in other configurations, the network traffic manager device 20 may include other types and numbers of elements. In this example, the bus 19 is a PCI Express bus, but other bus types and links may be used.

[0028] The processor 18 within the network traffic manager device 20 may execute one or more computer-executable instructions stored in the memory 22 for the methods illustrated and described with reference to the examples herein, although the processor may execute other types and numbers of instructions and perform other types and numbers of operations. The processor 21 may include one or more central processing units ("CPUs") or general-purpose processors having one or more processing cores, such as a processor 21. processor, but other types of processors may be used (e.g. ).

[0029] The memory 22 within the network traffic manager device 20 may include one or more tangible storage media, such as RAM, ROM, flash memory, CD-ROM, floppy disk, hard drive, solid-state memory, DVD, or any other memory storage type or device known to those skilled in the art, including combinations thereof. The memory 22 may store one or more non-transitory computer-readable instructions of the present technology as illustrated and described with reference to the examples herein, which instructions may be executed by the processor 21. Figure 3 and Figures 4A to 4I The exemplary flowchart shown in represents example steps or actions of the present technology, which may be embodied or expressed as one or more non-transitory computer or machine-readable instructions stored in memory 22, which may be executed by processor 21 and / or implemented by configured logic in optional configurable logic 26.

[0030] Thus, the memory 22 of the network traffic manager device 20 may store one or more applications that may include computer-executable instructions that, when executed by the network traffic manager device 20, cause the network traffic manager device 20 to perform actions, such as, for example, transmitting, receiving, or otherwise processing messages, and performing the operations described below with reference to Figure 3 and Figures 4A to 4I Other actions described and illustrated. An application may be implemented as a module or component of another application. Furthermore, an application may be implemented as an operating system extension, module, plug-in, etc. An application may be implemented as a module or component of another application. Furthermore, an application may be implemented as an operating system extension, module, plug-in, etc. Still further, an application may operate in a cloud-based computing environment. An application may execute in a virtual machine or virtual server that may be managed in a cloud-based computing environment. Furthermore, applications, including the network traffic manager device 20 itself, may be located in a virtual server that runs in a cloud-based computing environment rather than being tied to one or more specific physical network computing devices. Furthermore, an application may run in one or more virtual machines (VMs) that execute on the network traffic manager device 20. Additionally, in at least one of the various embodiments, the virtual machines running on the network traffic manager device 20 may be managed or supervised by a hypervisor.

[0031] The optional configurable hardware logic device 26 in the network traffic manager device 20 may include dedicated hardware configured to implement one or more steps of the present technology, as illustrated and described with reference to the examples herein. By way of example only, the optional configurable logic hardware device 21 may include one or more field programmable gate arrays ("FPGAs"), field programmable logic devices ("FPLDs"), application specific integrated circuits ("ASICs"), and / or programmable logic units ("PLUs").

[0032] The network traffic manager device 20 is configured to operatively couple and communicate between the network traffic manager device 20, a plurality of client computing devices 40(1)-40(n), and a plurality of hardware security systems 50(1)-50(n), all coupled together via a communication network 30, such as one or more local area networks (LANs) and / or wide area networks (WANs), although other types and numbers of communication networks or systems having other types and numbers of connections and configurations with other devices and elements may be used. Figure 1B and Figures 4A to 4IAs illustrated, the network traffic manager device 20 can be used to operatively couple and communicate between the network traffic manager device 20, the client computing device 40(1), the first hardware security system 50(1), and the second hardware security system 50(2), which are also all coupled together via a communication network 30 (such as one or more LANs and / or WANs). By way of example only, the communication network (such as a local area network (LAN) and a wide area network (WAN)) can use Ethernet to carry TCP / IP and industry standard protocols including NFS, CIFS, SOAP, XML, LDAP, and SNMP, although other types and numbers of communication networks can be used. In this example, the bus 26 is a PCI Express bus in this example, but other bus types and links can be used.

[0033] Each of the plurality of client computing devices 40(1)-40(n) of the network traffic management system 10 includes a central processing unit (CPU) or processor, memory, input / display device interfaces, configurable logic devices, and input / output systems or I / O systems coupled together by a bus or other link. Additionally, the plurality of client computing devices 40(1)-40(n) may include any type of computing device that can receive, render, and facilitate user interactions, such as client computers, network computers, mobile computers, mobile phones, virtual machines (including cloud-based computers), etc. Each of the plurality of client computing devices 40(1)-40(n) utilizes the network traffic manager device 20 to perform one or more operations with the plurality of hardware security systems 50(1)-50(n), such as to obtain or create cryptographic keys (by way of example only), but other functions may also be performed. As Figure 1B and Figure 4A As depicted, the client computing device 40(1) can send one or more operations to the first hardware security system 50(1) and the second hardware security system 50(2) via the communication network 30 through the network traffic manager device 20, but multiple client computing devices 40(1)-40(n) and the network traffic manager device 20 can be coupled together via other topologies.

[0034] In general, a plurality of hardware security systems 50(1)-50(n) may perform various computing tasks implemented using a computing environment. The computing environment may include computer hardware, computer software, and combinations thereof. As a specific example, the computing environment may include general-purpose and / or special-purpose processors, configurable and / or hard-wired electronic circuits, communication interfaces, and computer-readable memory for storing computer-executable instructions to enable the processor to perform a given computing task. The logic for performing a given task may be specified in a single module or may be spread across multiple modules. As used herein, the terms "module" and "component" may refer to an implementation within one or more special-purpose hardware devices or appliances (e.g., computers), and / or an implementation within software hosted by one or more hardware devices or appliances that may host one or more other software applications or implementations. Additionally, the network traffic manager device 20 may include a cryptographic offload module for offloading cryptographic operations to the plurality of hardware security systems 50(1)-50(n). The cryptographic offload module may be a software daemon executed by the processor 21 of the network traffic manager 20. A daemon is a software routine that runs as a background process and can manage the execution of cryptographic operations on multiple hardware security systems 50(1)-50(n) using and scheduling the aforementioned threads.

[0035] The plurality of hardware security systems 50(1)-50(n) may be implemented using a variety of different computer architectures. For example, the plurality of hardware security systems 50(1)-50(n) may be implemented as plug-in circuit cards that interface to an input / output or peripheral interface of a computer, such as a Peripheral Component Interconnect Express (PCIe), and may include connectors for connecting to a backplane or other connector of the computer. As another example, the plurality of hardware security systems 50(1)-50(n) may be implemented as computer appliances connected via a computer network (network-based plurality of hardware security systems 50(1)-50(n)). As another example, the plurality of hardware security systems 50(1)-50(n) may be implemented as virtualized resources within a cloud computing infrastructure (cloud-based plurality of hardware security systems 50(1)-50(n)). The plurality of hardware security systems 50(1)-50(n) may have different storage capacities and / or acceleration capabilities. For example, the physical multiple hardware security systems 50(1)-50(n) can be divided into multiple logical multiple hardware security systems 50(1)-50(n), where each logical multiple hardware security system 50(1)-50(n) can have different capabilities and can be accessed using different account credentials. The logical multiple hardware security systems 50(1)-50(n) can also be referred to as partitions or tokens of the physical multiple hardware security systems 50(1)-50(n). The partitions of the multiple hardware security systems 50(1)-50(n) can be isolated from each other so that keys and data on one partition are not visible from different partitions. Partitions can share hardware and other resources, or partitions can use specific non-shared hardware and resources. The multiple hardware security systems 50(1)-50(n) can use various storage technologies, such as random access memory (RAM), non-volatile RAM, flash memory, hard disk drives, solid-state drives, or other storage implementations. The plurality of hardware security systems 50(1)-50(n) may enable and / or deny access to keys based on a security policy. For example, a security policy may specify that a particular key may only be used and / or accessed when authorized account credentials are presented to the plurality of hardware security systems 50(1)-50(n).

[0036] In one example, the network traffic manager device 20 can be a dedicated computing device including a processor 21 and a computer-readable memory 22. The memory 22 of the network traffic management device 810 can store one or more applications that can include computer-executable instructions that, when executed by the network traffic manager device 20, cause the network traffic manager device 20 to perform actions such as, for example, transmitting, receiving, or otherwise processing messages, and to perform other actions such as offloading cryptographic operations to the plurality of hardware security systems 50(1)-50(n) and accessing cryptographic keys stored on the plurality of hardware security systems 50(1)-50(n). Applications can be implemented as components of other applications. Further, applications can be implemented as operating system extensions, plug-ins, etc.

[0037] Therefore, the technology disclosed herein should not be construed as limited to a single environment, and other configurations and architectures are also contemplated. For example, Figure 1A and Figure 1B The plurality of hardware security systems 50(1)-50(n) depicted in FIG may operate within the network traffic manager device 20, rather than as stand-alone servers that communicate with the network traffic manager device 20 via the communication network 30. In this example, the plurality of hardware security systems 50(1)-50(n) operate within the memory 22 of the network traffic manager device 20.

[0038] Although the network traffic manager device 20 is illustrated in this example as comprising a single device, in other examples, the network traffic manager device 20 may include multiple devices, each having a processor, each having one or more processing cores that implement one or more steps of the present technology. In these examples, one or more of the devices may have a dedicated communication interface or memory. Alternatively, one or more of the devices may utilize memory, a communication interface, or other hardware or software components of one or more other communicatively coupled devices. Additionally, in other examples, one or more of the devices that together comprise the network traffic manager device 20 may be standalone devices, or integrated with, for example, one or more other devices or applications, multiple hardware security systems 50(1)-50(n), or the network traffic manager device 20 or an application coupled to a communication network. Furthermore, in these examples, one or more of the devices of the network traffic manager device 20 may be located in the same or different communication networks 30, including, for example, one or more public, private, or cloud networks.

[0039] Although an exemplary network traffic management system 10 having a plurality of client computing devices 40(1)-40(n), a network traffic manager device 20, and a plurality of hardware security systems 50(1)-50(n), and a communication network 30 is described and illustrated herein, other types and numbers of systems, devices, components, and elements in other topologies may be used. It should be understood that the example systems described herein are for exemplary purposes, as many variations in the specific hardware and software used to implement the examples are possible, as will be understood by those skilled in the relevant art.

[0040] Further, each of the systems of the examples may be conveniently implemented using one or more general purpose computer systems, microprocessors, digital signal processors, and microcontrollers programmed according to the teachings of the examples, as described and illustrated herein, and as will be understood by those of ordinary skill in the art.

[0041] One or more of the components depicted in the network traffic management system (such as, for example, the network traffic manager device 20, the plurality of client computing devices 40(1)-40(n), and the plurality of hardware security systems 50(1)-50(n)) may be configured to operate as virtual instances on the same physical machine. In other words, Figure 1A 、 Figure 1B and Figures 4A to 4I The network traffic manager device 20, the plurality of client computing devices 40(1)-40(n), or one or more of the plurality of hardware security systems 50(1)-50(n) illustrated in FIG. 1 may operate on the same physical device, rather than as a single physical device. Figure 1A and Figure 1B The operation is performed by separate devices communicating via a network as depicted in FIG. Figure 1A and Figure 1B There may be more or fewer client computing devices 40(1)-40(n), network traffic manager device 20, or hardware security systems 50(1)-50(n) than depicted in FIG. The client computing devices 40(1)-40(n), the hardware security systems 50(1)-50(n) may be implemented as applications on the network traffic manager device 20.

[0042] In addition, two or more computing systems or devices may replace any one of the systems or devices in any example. Therefore, the principles and advantages of distributed processing, such as redundancy and replication, may also be implemented as needed to improve the robustness and performance of the devices and systems of the examples. The examples may also be implemented on one or more computer systems extended across any suitable network using any suitable interface mechanism and flow technology, which, by way of example only, include any suitable form of telephone traffic (e.g., voice and modem), wireless traffic media, wireless traffic networks, cellular traffic networks, G3 traffic networks, public switched telephone networks (PSTN), packet data networks (PDN), the Internet, intranets, and combinations thereof.

[0043] The examples may also be embodied as a non-transitory computer-readable medium having stored thereon instructions for one or more aspects of the techniques as described and illustrated by the examples herein, which instructions, when executed by a processor (or configurable hardware), cause the processor to perform the steps necessary to implement the method of the examples, as described and illustrated herein.

[0044] An example of a method for migrating keys will now be described with reference to Figures 1 to 4. First, in step 305, the network traffic manager device 20 receives a key migration request from one of the plurality of client computing devices 40(1)-40(n), such as Figure 4AAs illustrated, the network traffic manager device 20 may receive other types or amounts of requests. A key migration request is a request to migrate an original key 54 from a first hardware security system 50(1) to a second hardware security system 50(2). The original key 54 may be a secret, such as a stored password or other sensitive or secret value. The original key 54 may also be a cryptographic key and may be a secret, such as a stored password or other sensitive value. It will be understood in the art that such migration may be performed using any of a plurality of hardware security systems 50(1)-50(n) and may be implemented using other methods. The plurality of hardware security systems 50(1)-50(n) may include a plurality of hardware security modules. The plurality of hardware security systems 50(1)-50(n) may be computer hardware and / or software (e.g., a computing device) configured to store cryptographic keys, perform cryptographic operations (such as generating keys, encrypting data, and decrypting data), and enforce security policies for using and / or accessing cryptographic keys. The plurality of hardware security systems 50(1)-50(n) may include a physical enclosure that reduces the likelihood of observation and / or tampering with sensitive data, such as private keys of the plurality of hardware security systems 50(1)-50(n). The enclosure may cover potential electrical probe points and display visible damage if tampered with. For example, the network traffic manager device 20 may initiate a migration request to migrate the original key 54 from the first hardware security system 50(1) to the second hardware security system 50(2) by first sending a request to generate a key protection key pair in the second hardware security system 50(2). For example, the key protection key pair may include a private key 53(2) and a public key 55(2). Information encrypted using the private key 53(2) may be decrypted using the corresponding public key 55(2). Information encrypted using the public key 55(2) may be decrypted using the corresponding private key 53(2). For example, the key may be a cryptographic key. The cryptographic key may be a value selected based on its cryptographic properties (e.g., a 128 or 256 byte number).

[0045] In step 310, the network traffic manager device 20 receives the public key 53(2) from the second hardware security system 50(2), such as Figure 4BAs illustrated. The public key 53(2) may be generated as a result of sending a request to the second hardware security system 50(2) to generate a key pair, the key pair comprising the public key 53(2) and the private key 55(2) in the second hardware security system 50(2). The received public key 53(2) from the second hardware security system 50(2) may be sent to the first hardware security system 50(1). It will be understood in the art that such sending and receiving may be performed using any one of the plurality of hardware security systems 50(1)-50(n) and may be implemented using other methods. Any of the plurality of hardware security systems 50(1)-50(n) may have different APIs having different functions for performing key-related tasks. In addition to generating key pairs, as described above, the plurality of hardware security systems 50(1)-50(2) may send keys to the traffic manager device 20 and receive keys to the traffic manager device in response to requests from the network traffic manager device 20. The plurality of hardware security systems 50(1)-50(n) may also comply with Public Key Cryptography Standards (PKCS). PKCS may be a class of public key cryptography standards. PKCS#11 (also known as Cryptoki) may be a specific platform-independent API for interfacing with the plurality of hardware security systems 50(1)-50(n), which may define data types, functions, and other components available to applications that implement the PKCS#11 standard. The data types may represent items stored on the plurality of hardware security systems 50(1)-50(n), such as cryptographic keys. In some examples, the specific platform-independent API may implement different methods and functions for importing, exporting, encrypting, and decrypting cryptographic keys.

[0046] In step 315, the network traffic manager device 20 sends a request to the first hardware security system 50(1) to generate a symmetric key 56(1) using the public key 53(2) generated by the second hardware security system 50(2), such as Figure 4CAs illustrated. As a result of receiving a request from the network traffic manager device 20, the first hardware security system 50(1) creates a symmetric key 56(1) in the first hardware security system 50(1) using the public key 53(2). For example, a cryptographic key can be a symmetric key or an asymmetric key. An asymmetric key can include a set of private keys and public keys. In this example, the symmetric key 56(1) can be a type of encryption in which only one key is used to both encrypt and decrypt information. When a symmetric key is used to encrypt information, the same symmetric key can be used to decrypt the information. Encryption can be the reversible conversion of clear or unencrypted information (e.g., text, plain text, or data) into data that is computationally incomprehensible except to the sender or intended recipient of the information. Decryption can be the reversal of the encryption process in which encrypted information is converted into unencrypted information. Encryption and decryption can be performed using one or more cryptographic algorithms, which can include one or more cryptographic operations. Cryptographic operations can include encoding information using a cryptographic key, decoding information using a cryptographic key, and generating a cryptographic key.

[0047] In step 320, the network traffic manager device 20 receives the encrypted symmetric key 56(2) of the first hardware security system 50(1), such as Figure 4D As illustrated, the encrypted symmetric key 56(2) can be created by encrypting the symmetric key 56(1) using the public key 53(2) from the second hardware security system 50(2). In this example, the public key 53(2) is used to encrypt the symmetric key 56(1) so that the encrypted symmetric key 56(2) is computationally incomprehensible in plain text format outside of the plurality of hardware security systems 50(1)-50(n).

[0048] In step 325, the network traffic manager device 20 sends the received encrypted symmetric key 56(2) to the second hardware security system 50(2), as shown in FIG. Figure 4E As illustrated. To decrypt the encrypted symmetric key 56(2), the private key 55(2) may be used to reverse the encryption process. For example, the private key and the public key may be mathematically bound together such that the corresponding private key can only decrypt information encrypted using the public key. In this example, because the symmetric key 56(1) in the first hardware security system 50(1) is encrypted using the public key 53(2) from the second hardware security system 50(2), the private key 55(2) in the second hardware security system 50(2) may decrypt the encrypted symmetric key. It should be understood that the symmetric key 56(1) does not need to be decrypted immediately after the network traffic manager device 20 sends the received encrypted symmetric key 56(2) to the second hardware security system 50(2). The encrypted symmetric key 56(2) may be decrypted at any time and need not occur immediately after step 325. Figure 4FThe symmetric key 56(1) is illustrated after decryption using the private key 55(2).

[0049] In step 330, the network traffic manager device 20 sends a request to the first hardware security system 50(1) to encrypt the original key 54 using the symmetric key 56(1) of the public key 53(2) from the second hardware security system 50(2), as shown in FIG. Figure 4F As illustrated. For example, the original key 54 can be a key that is operatively migrated from the first hardware security system 50(1) to the second hardware security system 50(2). The original key can include clear or unencrypted information (e.g., text, plain text, or data). In some embodiments, the original key 54 can be a key in a key pair. The original key 54(2) can be encrypted using the symmetric key 56(1) or the public key 53(2) from the second hardware security system 50(2).

[0050] In step 335, the network traffic manager device 20 receives the encrypted symmetric key 54(2) from the first hardware security system 50(1), such as Figure 4G In step 340, the network traffic manager device 20 sends the received encrypted raw key 54(2) to the second hardware security system 50(2), as shown in FIG. Figure 4H By using this method, the original key 54 has been migrated to the second security server 50(2) in encrypted form without exposing the original key 54 in plain text format outside the multiple hardware security systems 50(1)-50(n).

[0051] Then, in step 345, the network traffic manager device 20 sends a decryption request to the second hardware security system 50(2) to decrypt the sent encrypted original key 54(2) using the sent encrypted symmetric key 56(2), and the exemplary process ends at step 350. As illustrated, the network traffic manager device 20 provides a key migration service while executing requests and actions external to multiple hardware security systems 50(1)-50(n). The key migration service provided by the network traffic manager 20 or comparable technology can communicate with all hardware security systems 50(1)-50(n) provided by major cloud providers. The key migration service is also secure because the service does not have the data required to decrypt the original key because key migration does not have access to the private keys in the multiple hardware security systems 50(1)-50(n).

[0052] Having thus described the basic concepts of the present technology, it will be readily apparent to those skilled in the art that the foregoing detailed disclosure is intended to be presented by way of example only and not by way of limitation. Although not expressly set forth herein, various changes, improvements, and modifications will occur to and are intended by those skilled in the art. Such changes, improvements, and modifications are hereby proposed and are within the spirit and scope of the present technology. Additionally, except as may be specified in the claims, the enumerated order of processing elements or sequences, or the use of numbers, letters, or other designations is not intended to limit the claimed processes to any order. Therefore, the present technology is limited only by the following claims and their equivalents.

Claims

1. A method for migrating a key, the method being implemented by one or more network traffic management devices, server devices, or client devices, the method comprising: receiving an encrypted symmetric key from a first hardware security system, wherein the encrypted symmetric key is encrypted by the first hardware security system using a public key generated from a second hardware security system, and the generated public key is transmitted to the first hardware security system prior to the encryption; sending the received encrypted symmetric key to the second hardware security system; receiving an encrypted raw key from the first hardware security system after sending the encrypted symmetric key to the second hardware security system, wherein the raw key is encrypted using the symmetric key; sending the received encrypted original key to the second hardware security system; as well as When the second hardware security system decrypts the sent encrypted original key using the sent encrypted symmetric key, the migration of the original key from the first hardware security system to the second hardware security system is completed.

2. The method of claim 1, further comprising: Before decrypting the sent encrypted original key, a decryption request is sent to the second hardware security system to decrypt the encrypted symmetric key sent to the second hardware security system using a private key corresponding to the generated public key. 3 . The method of claim 2 , wherein the public key and the private key are generated by the second hardware security system to migrate the original key from the first hardware security system to the second hardware security system. 4 . The method of claim 2 , wherein the private key is not sent to the first hardware security system to migrate the original key from the first hardware security system to the second hardware security system.

5. The method of claim 1, wherein the original key is a cryptographic key, a stored password, or a secret value.

6. A non-transitory computer-readable medium having stored thereon instructions for migrating a key, the instructions comprising executable code that, when executed by a processor, causes the processor to: receiving an encrypted symmetric key from a first hardware security system, wherein the encrypted symmetric key is encrypted by the first hardware security system using a public key generated from a second hardware security system, and the generated public key is transmitted to the first hardware security system prior to the encryption; sending the received encrypted symmetric key to the second hardware security system; receiving an encrypted raw key from the first hardware security system after sending the encrypted symmetric key to the second hardware security system, wherein the raw key is encrypted using the symmetric key; sending the received encrypted original key to the second hardware security system; as well as When the second hardware security system decrypts the sent encrypted original key using the sent encrypted symmetric key, the migration of the original key from the first hardware security system to the second hardware security system is completed.

7. The medium of claim 6, wherein the one or more processors are further configured to execute programmed instructions stored in the memory to, before decrypting the sent encrypted original key, send a decryption request to the second hardware security system to decrypt the encrypted symmetric key sent to the second hardware security system using a private key corresponding to the generated public key.

8. The medium of claim 7, wherein the public key and the private key are generated by the second hardware security system to migrate the original key from the first hardware security system to the second hardware security system.

9. The medium of claim 7, wherein the private key is not sent to the first hardware security system to migrate the original key from the first hardware security system to the second hardware security system.

10. The medium of claim 6, wherein the original key is a cryptographic key, a stored password, or a secret value.

11. A network traffic manager device comprising: Memory, said memory including programming instructions stored in said memory; and a processor configured to execute the programming instructions stored in the memory to: receiving an encrypted symmetric key from a first hardware security system, wherein the encrypted symmetric key is encrypted by the first hardware security system using a public key generated from a second hardware security system, and the generated public key is transmitted to the first hardware security system prior to the encryption; sending the received encrypted symmetric key to the second hardware security system; receiving an encrypted raw key from the first hardware security system after sending the encrypted symmetric key to the second hardware security system, wherein the raw key is encrypted using the symmetric key; sending the received encrypted original key to the second hardware security system; as well as When the second hardware security system decrypts the sent encrypted original key using the sent encrypted symmetric key, the migration of the original key from the first hardware security system to the second hardware security system is completed.

12. The apparatus of claim 11 , wherein the one or more processors are further configured to execute the programming instructions stored in the memory to, before decrypting the sent encrypted original key, send a decryption request to the second hardware security system to decrypt the encrypted symmetric key sent to the second hardware security system using a private key corresponding to the generated public key. 13 . The apparatus of claim 12 , wherein the public key and the private key are generated by the second hardware security system to migrate the original key from the first hardware security system to the second hardware security system.

14. The apparatus of claim 12, wherein the private key is not sent to the first hardware security system to migrate the original key from the first hardware security system to the second hardware security system.

15. The apparatus of claim 11, wherein the original key is a cryptographic key, a stored password, or a secret value.

16. A network traffic management system comprising: Traffic management equipment; server device; or a client device, the network traffic management system comprising: a memory including programming instructions stored thereon; and a processor configured to execute the stored programming instructions to: receiving an encrypted symmetric key from a first hardware security system, wherein the encrypted symmetric key is encrypted by the first hardware security system using a public key generated from a second hardware security system, and the generated public key is transmitted to the first hardware security system prior to the encryption; sending the received encrypted symmetric key to the second hardware security system; receiving an encrypted raw key from the first hardware security system after sending the encrypted symmetric key to the second hardware security system, wherein the raw key is encrypted using the symmetric key; sending the received encrypted original key to the second hardware security system; and When the second hardware security system decrypts the sent encrypted original key using the sent encrypted symmetric key, the migration of the original key from the first hardware security system to the second hardware security system is completed.

17. The network traffic management system of claim 16, wherein the one or more processors are further configured to execute the programming instructions stored in the memory to send a decryption request to the second hardware security system to decrypt the encrypted symmetric key sent to the second hardware security system using a private key corresponding to the generated public key before decrypting the sent encrypted original key.

18. The network traffic management system of claim 17, wherein the public key and the private key are generated by the second hardware security system to migrate the original key from the first hardware security system to the second hardware security system.

19. The network traffic management system of claim 17, wherein the private key is not sent to the first hardware security system to migrate the original key from the first hardware security system to the second hardware security system.

20. The network traffic management system of claim 16, wherein the original key is a cryptographic key, a stored password, or a secret value.

Images