Systems and methods for establishing scalable credential creation and access

A client access network includes a cluster of servers. The cluster of servers includes a boot node, an administrator node, a computing node, and a storage node. The client access network further includes a plurality of segregated subnetworks. The plurality of segregated subnetworks includes a boot subnetwork, an administration subnetwork, a public subnetwork, and a private subnetwork. The client access network further includes at least one hardware security module, a dedicated subnet in operable communication with the at least one hardware security module and each of the plurality of segregated subnetworks, and a router in operable communication with the at least one hardware security module and each of the cluster of servers. The router is further configured to route traffic among the plurality of segregated subnetworks and the dedicated subnet.

BACKGROUND

The field of the disclosure relates generally to management of computer networks, and more particularly, to credential creation and access within such networks.

At present, the rapidly-growing complexity of Network Function Virtualization (NFV), particularly within the context of the Internet of Things (IoT), requires an infrastructure scaled to the demand for availability. Conventional NFV infrastructures often employ hardware roots of trust that aim to establish a tamper-resistant “black box” that use built-in cryptographic keys to perform cryptographic operations, such as encryption, decryption, and hashing. Examples of such hardware roots of trust include the Trusted Platform Module (TPM) and the Hardware Security Module (HSM). These trust models/schemes are used for remote attestation, with the attestation being typically performed by a third party and/or a Cloud services user.

Conventional HSMs typically include a physical computing device that safeguards and manages digital keys for authentication and providing cryptoprocessing. Because conventional HSMs often form critical portions of a public key infrastructure (PKI), or other similarly critical applications, the HSMs are frequently clustered to enhance availability and performance. Specifically, in IoT applications, the dynamic nature of the IoT Cloud generally requires that the specific modules/HSMs that perform large cryptographic transactions are located in geographic proximity (i.e., clustered) to the virtual machines (VMs) that use these modules. However, conventional HSM implementations have been unable to sufficiently network separate HSMs together in a scalable manner for the Cloud.

More particularly, even though the use of HSM devices (e.g., SafeNet Luna Network HSM 7, etc.) was initially recommended by the National Institute of Standards and Technology (NIST), HSMs are presently known to “not scale well to the cloud paradigm.” Nevertheless, emerging NFV security standards from the European Telecommunications Standards Institute (ETSI) continue to endorse the use of HSM as the technology of choice for addressing problems due to hypervisor introspection. HSMs, for example, provide a tamper resistant, and in some cases a tamper proof, platform to hold confidential cryptographic information, as well as the performance of cryptographic functions. That is, tampering may occur as a matter of degree: (i) “tamper proof;” (ii) “tamper resistant;” and (iii) “tamper aware.” Accordingly, different threat models may require all copies of a key to be deleted if a given HSM is compromised, or has been subjected to an attempted compromise.

Consensus mechanisms on key “health” and HSM network state relate to tampering degrees, and HSMs may be configured such that unauthorized access to the HSM, whether logically or physically, may trigger alarms and/or result in permanent destruction of keys stored on or in the HSM, while also harming the functionality performed by the HSM. Accordingly, it is desirable to provide systems and methods for networking HSMs in a scalable manner.

BRIEF SUMMARY

In an embodiment, a client access network includes a cluster of servers. The cluster of servers includes a boot node, an administrator node, a computing node, and a storage node. The client access network further includes a plurality of segregated subnetworks. The plurality of segregated subnetworks includes a boot subnetwork, an administration subnetwork, a public subnetwork, and a private subnetwork. The client access network further includes at least one hardware security module, a dedicated subnet in operable communication with the at least one hardware security module and each of the plurality of segregated subnetworks, and a router in operable communication with the at least one hardware security module and each of the cluster of servers. The router is further configured to route traffic among the plurality of segregated subnetworks and the dedicated subnet.

In an embodiment, a method of transferring security data from a first hardware security module (HSM) of a computer network to a second HSM is provided. The method includes a step of determining an association of a virtual machine (VM) with the first HSM. The VM runs on a first host within the computer network. The method further includes steps of triggering a migration operation of the VM at the first host, transferring the security data from the first HSM to the second HSM, initiating the migration operation of the VM concurrently with the step of transferring, and updating the migration status of the VM.

DETAILED DESCRIPTION

In the following specification and claims, reference will be made to a number of terms, which shall be defined to have the following meanings.

The embodiments described herein provide innovative systems and methods for establishing networks of HSMs for computer networks utilizing, for example, the Cloud and NFV environments, and more particularly for the IoT. The present embodiments introduce, among other solutions, mechanisms for enhancing the security capabilities of an HSM such that the HSM is more fully capable of implementing a PKI for the Cloud. The present embodiments are further advantageously applicable in the ETSI NFV Management and Orchestration (MANO) environment and architecture.

The embodiments herein are therefore scalable in accordance with the continually-growing complexity of the NFV, particularly with respect to the IoT context. More specifically, the present systems and methods are capable of advantageously establishing dedicated HSM networks, such that the HSM environment can be moved as close as possible to the entity utilizing the HSM network, such that bandwidth use and response time or minimized. The mechanisms described below further enable a significantly more reliable binding of credential instances to established and/or fully-attested hardware identities, and also establishment of a secure association of an HSM to the VM to which it has been assigned.

As described further below, the embodiments herein represent significant improvements with respect to: (i) HSM distribution, both across the system/network and locally, within a virtualized pod/stack; (ii) hierarchical organization of HSM networks to support various virtualization architectures, including NFV; (iii) HSM virtualization and orchestration; and (iv) key management and cryptographic functionality using a virtual distributed HSM network, including the migration of credentials and other related functionalities.

The systems and methods are of particular applicability in relation to a generic Cloud or a Cloud environment, a software-defined network (SDN), and also within the management framework of the NFV environment standardized by the ETSI NFV Industry Specification Group. The mechanisms described below may be deployed in all major Cloud carriers, and/or by network operators deploying standardized NFV. Except as where described below to the contrary, the following systems and methods may be implemented by dedicated hardware, as an all-software solution, or in hybrid hardware/software combinations.

FIG.1is a schematic illustration of an exemplary multi-tier hardware security module (HSM) system100. In the exemplary embodiment, multi-tier HSM system100includes a first tier102, a second tier104, and a third tier106. In the exemplary embodiment, first tier102represents the Cloud computing environment, second tier104represents the “Fog” computing environment (sometimes referred to as “edge computing”), and third tier106represents the “Mist” computing environment. In some embodiments, the Cloud includes a centralized processor, the Fog includes decentralized processing, and the Mist includes lightweight and/or local computer processing.

In an embodiment, first tier102includes at least one tier-1 HSM-dedicated network108having one or more tier-1 HSMs110, second tier104includes at least one tier-2 HSM-dedicated network112having one or more tier-2 HSMs114, and third tier106includes at least one tier-3 HSM-dedicated network116having one or more tier-3 HSMs118. In the exemplary embodiment each of HSM-dedicated networks108,112,116are in operable communication with a system orchestrator120, which may be a Cloud orchestrator or an NFV orchestrator, and may include an OpenStack Neutron Engine. In this example, Fog tier104and Mist tier106are configured such that the relevant computations are removed physically close to end-point IoT devices (not shown) operable within system100.

In exemplary operation of system100, significant improvements to safe networking among the several HSMs are achieved according to the exemplary system layout illustrated inFIG.1. In the exemplary embodiment illustrated, a physically separated and high-security system network is depicted by way of example for simplicity of explanation, but is not intended to be limiting. The physically-separate, high-security embodiment is selected inFIG.1as an example effective storage access and establishment of command-and-control networking among Cloud orchestration and management principals. Other exemplary embodiments include, without limitation, virtual private networks having multiple layers, and implementation of the present techniques among the multiple layers thereof.

The exemplary embodiment depicted inFIG.1thus represents a clustering effect based on the natural geographic (or similar) relationship of modules to each other, and/or to individual IoT devices. In this example, the separated HSM-dedicated networks108,112,116are depicted among different as a specialized case tailored to a specific situation allowing cost minimization and speed maximization of the particular network of this exemplary embodiment. For example, in this instance, one or more of tier 2 HSM-dedicated network112and tier 3 HSM-dedicated network116may be Local Area Networks (LANs). Nevertheless, the specific hardware architecture of the present systems and methods is not limited to this particular multi-tier specialized network structure to enable the credential migration among different modules.

For example, in an alternative embodiment, a particular HSM-dedicated network may include and utilize a smaller segregated subset of HSMs within a single HSM-dedicated network. In some embodiments, such segregated subsets may be dictated by special security considerations, such as those dictated by law enforcement and/or regulatory agencies. In at least one embodiment, special security considerations may be implemented and managed according to a particular service-level agreement with a Cloud consumer.

Thus, according to the advantageous principles of HSM system100, the present embodiments achieve, both within an individual network/tier, or across the tiers, of the multi-tier architecture: (i) improved capability for high transmission, and commensurate with the performance requirements imposed by the number of HSMs110,112,116operating within system100, as well as the number of transactions performed within a relevant (e.g., predetermined) unit of time; (ii) protection from external interference that can cause degradation of the transmission capabilities of system100; and (iii) protection from eavesdropping.

In some embodiments, eavesdropping protection is achieved by dedicating the respective network for use only by desired entities, operators, or devices. In other embodiments, eavesdropping protection is achieved using (i) communication protocols (e.g., IPSec, TLS, etc.) that guarantee confidentiality, integrity, and protection from replays, and (ii) the introduction of random “noise” by continuous interchanges among randomly selected pairs of individual HSMs that simulate transactions. These techniques represented particular improvements to traffic security by preventing a potential eavesdropper from determining an actual credential distribution of system100by analyzing the traffic therein. In at least one embodiment, the amount of random noise introduced is predetermined, such that the generated noise is in compliance with performance requirements of system100when the performance requirements are being established. In other embodiments, the amount of noise can be dynamically adjusted according to changing performance requirements in real-time, or to scale system100to increasing need. In one embodiment, eavesdropping protection is achieved through the alternative, or supplemental, utilization of full-time dedicated encryption techniques.

That is, because the respective HSMs establish tamper-resistant or tamper-proof platforms, HSMs110,114,118may advantageously store the related PKI keys to implement within the HSM platform itself, the physically-separate and high-security network example depicted inFIG.1. According to this improved architecture, dedicated point-to-point encrypted connections may be established between HSMs, as a layer 1 link, using the keys stored within the respective HSM. In an exemplary embodiment, each such established connection between HSMs uses unique keys or at least one unique keypair. The relatively tamper-proof nature of the respective HSMs is thus sufficient to ensure that any unauthorized effort to access the keys or related links will trigger the relevant tamper-resistant mechanism(s) of the HSM. Through this improved system architecture, system100advantageously realizes the same security for the entirety of the networked HSMs110,114,118as would be realized for an individual HSM.

According to an exemplary embodiment, system100is advantageously capable of successfully enabling the migration of credentials associated with a particular VM such that the migrated credentials reside in the HSMs/modules that are optimal for access from the particular VMs as the VMs themselves are migrated. That is, in system100, credentials are optimally migrated between modules within a particular HSM network, among modules in different networks in the same tier, and/or between modules of networks in different tiers.

The present migration techniques are therefore further advantageously capable of being implemented as an alternative to, or in a complementary manner with, out-of-band, that is, “manual,” migration of credentials. In an exemplary embodiment, migration is managed and/or performed by system orchestrator120, which is the entity tasked with making the relevant decisions and directing the VM placement. In some embodiments, system orchestrator120is further configured to include and implement specific algorithms that further enable the migration of credentials among modules. As described further below with respect toFIGS.2and3, the credential migration may be performed of synchronously and asynchronously with the migration of the virtual machines themselves.

FIG.2is a schematic illustration of an exemplary HSM network200for a synchronous transfer of credentials. In the example depicted inFIG.2, HSM network200implements a migration operation202of a VM204from a first host206to a second host208, and a transfer operation210of VM data212from a first HSM214to a second HSM216. In an exemplary embodiment, transfer operation210is performed in coordination with an HSM administrator218and a system orchestrator220in operable communication with HSM administrator218. In some embodiments, system orchestrator220is a Cloud or NFV orchestrator, and is further in operable communication with a policy engine220and a host map224.

In exemplary operation of network200, transfer operation210is performed synchronously with migration operation202. That is, the synchronous transfer of VM data212(i.e., HSM data belonging to VM204) from first HSM214to second HSM216is initiated synchronously with the decision of system orchestrator220to migrate VM204from first host206to second host208. In this example, it is assumed that system orchestrator220is aware of a first association226of VM204with first HSM214. In some embodiments, system orchestrator220is not aware of first association226, however, in such instances, network200will include some element or functionality of an operating system (not shown) to keep track of such associations. Accordingly, network200would operate similarly in such instances, except with the inclusion of an additional communication step between system orchestrator220and the operating system.

In further operation of network200, upon initiation of migration operation202of the VM204from first host206to second host208, system orchestrator220makes a decision to synchronously transfer VM data212(e.g., secret data) associated with first HSM214to second HSM216. In the exemplary embodiment, programmed algorithms of system orchestrator220are configured to make the relevant migration decision according to considerations including, without limitation: (i) Cloud Operator policies, such as may be instructed by policy engine222; (ii) performance and/or security considerations that may be “hardwired” into host map224, in order to keep associations of the VMs to the relevant host identities; and (iii) performance information that is dynamically received from a performance monitoring operations system (not shown inFIG.2). Again, these examples are provided by way of illustration, and are not intended to be limiting.

In some embodiments, the particular trigger for synchronous transfer/migration may be different, but transfer operation210will be performed synchronously with migration operation202. That is, in an exemplary operation of network200, system orchestrator220may be further configured to effect synchronous transfer of credentials through start-of-transfer instructions to one or more of: (1) HSM administrator218, which is an innovative system component that may communicate with or substitute for that operation system, and includes administrative jurisdiction over all HSMs (this example is depicted inFIG.2); (2) separate HSM Administrators218, such as in the case where first HSM214resides in a separate HSM administrative domain from second HSM216, and each respective HSM administrative domain includes its own HSM administrator218; (3) both first HSM214and second HSM216directly; and (4) either of first HSM214and second HSM216, in the case where the respective HSM “transfer to” or “transfer from” command is supported by the particular module receiving the instruction.

According to the innovative techniques of HSM network200, the actual transfer (e.g., transfer operation210) of credentials (e.g., VM data212) occurs concurrently with the migration (e.g., migration operation202) of VM204. In some embodiments, a copy of the secret data within first HSM214may be held for as long as VM204still operates on first host206, and may be subsequently completely erased thereafter. In other embodiments, VM data212is erased from first HSM214upon completion of transfer operation202.

The innovative techniques herein are also of particular use in the case of a key that is no longer trusted. In such instances the non-trusted key may be destroyed, and when the key is destroyed, the entire hierarchy in which the key interacts may also be destroyed. In some embodiments, network200is further configured to advise or alert participants in the hierarchy of the loss of trust, the destroyed key, and/or other actions related thereto. Such relevant actions may be performed irrespective of whether the key(s) is contained within multiple servers and/or multiple HSMs, whether virtualized or not. The destruction of the key may, for example, prevent unauthorized party from discovering the non-trusted key and using it. In some embodiments, only the encryption key is destroyed, and other data in the HSM remains. In at least one embodiment, the remaining data within a tamper-proof HSM is considered non-trusted, particularly in the event that a “destroyed” key had been replicated prior to the destruction operation.

In some embodiments, depending on the particular threat model chosen, upon destruction of one non-trusted key, an additional instruction is provided to destroy all other keys that are present on a particular HSM at the time the HSM is subject to compromise. In an embodiment, the applied threat model may be configured to respond differently according to a detected threat, and the particular needs of the network. For example, a software attack or a buffer overflow might trigger an alarm according to one model, but might lead to key destruction (and possibly key reissuing) in another model. In some cases, it may be desirable to prevent a key from being destroyed so that unretrieved data may be retrieved at a later time. In most instances, a “tamper proof” model will delete the keys upon detection of actual or attempted tampering. In the exemplary virtualized environment, each HSM is provided with its own unique key.

FIG.3is a schematic illustration of an exemplary HSM network300for an asynchronous transfer of credentials. HSM network300is similar to HSM network200,FIG.2, except that the transfer of credentials in network300is asynchronous. In the example depicted inFIG.3, HSM network300implements a transfer operation302of VM data304from a first HSM306to a second HSM308. In an exemplary embodiment, transfer operation302is performed in coordination with an HSM administrator310and a system orchestrator312in operable communication with HSM administrator310. System orchestrator312may be further in operable communication with a policy engine314and a host map316. Unless otherwise stated, elements of network300having the same labels may be considered to be similar in structure and function to relevant elements of network200.

In the exemplary embodiment, network300further includes a host318having a host monitoring agent320, and host318is associated with a VM322. Host monitoring agent320may be in operable communication with a performance monitoring operating system324. In some embodiments, performance monitoring operating system324is telemetry-based, and network300further includes a network monitoring agent326.

In exemplary operation of network200, transfer operation302of VM data304from first HSM306to second HSM308is performed asynchronously in regard to the disposition of VM322with respect to host318. That is, in this example, VM322does not migrate to a different host, but instead, network300migrates the association of VM322from first HSM306to second HSM308.

More particularly, as illustrated inFIG.3, the transfer of VM data304may be triggered by the telemetry-based determinations of performance monitoring operations system324(e.g., an OpenStack Ceilometer measurement). In other embodiments, a trigger event may be caused by the data supplied by a performance agent at host318, such as monitoring agent320, which may, for example, determine a low CPU utilization of VM322due to an amount of time spent communicating with first HSM306(e.g., a measured above a threshold specified in a Service Level Agreement). In another example, the triggering event may be generated by network monitoring agent326indicating a substantial amount of congestion on a first path328between VM322and first HSM306. In this example, network monitoring agent326may further determine that a second path330, between VM322and second HSM308, indicates a substantially lower amount of congestion than is detected on first path328.

In further operation of network300, upon receipt or detection of the relevant triggering event, system orchestrator312is configured to consult policy engine314and host map316to locate the appropriate HSM (second HSM308, in this example) and initiate transfer operation302in a manner similar to transfer operation210,FIG.2, in the synchronous case. Also similar to the embodiment depicted inFIG.2, the embodiment depicted inFIG.3is provided by way of example, and not in a limiting sense. In some embodiments, the asynchronous triggering events may arise from other sources, such as by a direct request from the Cloud consumer, from VM322itself, from a different operations system (e.g., a relevant security monitoring system, not shown), or by an entity other than system orchestrator312.

FIG.4is a schematic illustration of an exemplary “soft” trusted platform module (TPM) architecture400. TPM architecture400is structured with respect to a VM402, a secured execution environment404, a hypervisor406, and a “hard” TPM408. As illustrated inFIG.4, soft TPM410is generated within overlapping portions of secured execution environment404and hypervisor406.

According to exemplary embodiment depicted inFIG.4, individual HSMs are much more reliably enabled to authenticate VM402. Related applications describe techniques by which a system of Host-IDs may be maintained such that each Host-ID is bound to a particular physical machine at a specific location. Each Host-ID is associated with the TPM of the host, and thereby, a VM running on that host may be partially authenticated (i.e., bound to an authenticated host) by the TPM. Techniques utilizing TPM architecture400improve upon these related techniques by further identifying and authenticating the VM (e.g., VM402) using the Host-ID of a virtual TPM (vTPM), or a similar mechanism.

In the exemplary embodiments depicted inFIG.4, hypervisor406, as part of its service to the relevant operating system (not shown), simulates a hardware platform by creating a data object that behaves, on respective operating system calls, as a TPM. In this example, standard keys may also be created and stored in the relevant structure of the created data object. This relevant structure further provides the “host identifier” (Host-ID) for VM402, which functions to: (i) identify VM402both uniquely and permanently, which may be done by the system orchestrator when VM402is created; or (ii) only uniquely identifies VM402(the illustrative example depicted inFIG.4), but in a way that ties VM402to the hardware host, such as by providing a soft VM-ID that is a function of the hardware Host-ID and the local VM-ID. In one example, this function may represent a return of the concatenation Host-ID|VM-ID of the Host-ID and a string assigned to VM402by hypervisor406. In some such instances, for security purposes a cryptographic function may be implemented instead to more securely prevent an operator's Host-ID from being divulged.

In an embodiment, secured execution environment may be a secure enclave (e.g., provided by an Intel SGX for creating such objects), and functions to significantly improve the security of soft TMP410such that soft TPM410is effectively identical to the security level provided by hard TPM408. In some embodiments, the public key(s) (not shown inFIG.4) of VM402may be trusted by the relevant Cloud Identity Manager (e.g., OpenStack Keystone, not shown inFIG.4). Such trust performance may be achieved using ephemeral or more permanent certificates created by hypervisor406and signed by the TPM EC, or by handing the keys from the system orchestrator (Cloud Orchestrator in this example) to the Cloud Identity Manager. Other mechanisms and/or sub-processes may be implemented to establish trust, but without limiting the innovative capability of architecture400to authenticate VM402using the unique VM-ID, thereby more securely enabling of the authentication of a VM to an HSM assigned to the particular VM.

In some embodiments, it is particularly desirable to perform mutual authentication in order to establish a security association between a VM and the HSM assigned to the VM. Typically, the HSM is authenticated by the VM, using the public key of the HSM. According to the present embodiments though, the reverse authentication is advantageously enabled. In accordance with the present embodiments, the credentials of the VM may be established such that the VM is authenticated by the HSM. In the exemplary embodiment of architecture400, the HSM is able to authenticate VM402using the public key associated with soft TPM410or provisioned with the HSM.

In an alternative embodiment, a mechanism is provided that requires no additional provisioning steps for the HSM, other than what is necessary to establish trust with, for example, the Cloud Identity Manager (which already oversees other authentication and authorization transactions in the Cloud and in environments such as OpenStack). This alternative embodiment is of particular usefulness in that it eliminates particular provisioning and certification requirements, while also combining authentication process with the authorization process. This alternative embodiment further advantageously enables dynamic authentication, and of many different authentication types, including without limitation multi-factor authentication. Such dynamic capabilities allow systems and methods according to the present techniques to change at any time according to particular policies of, for example, the Cloud Operator. These advantageous techniques are further able to incorporate standards protocols, such as OAuth and its variants, as described below with respect toFIG.5, which may include software implementations, including without limitation open source projects.

FIG.5is a sequence diagram for an exemplary authentication and authorization process500for a Cloud identity management, which may be implemented with respect to one or more of the embodiments described herein. In an exemplary embodiment, process500includes a VM502, an assigned HSM504, and a Cloud Identity Manager506, and operates to establish a secure association with HSM504. When implemented, process500may execute the following steps, which are not necessarily required to be in the order listed, except where designated as being dependent on a prior step.

In step S508, VM502presents its identity, namely, its Host-ID, to HSM504. In step S510, HSM504performs a redirect operation to VM502. In an exemplary embodiment of step S510, in order to authenticate VM502and ascertain whether VM502is authorized to use HSM504, HSM504is configured to construct a frame for an authorization token, and then attach the constructed frame to the redirect response to VM502(e.g., by known HTTP redirect processes). In step S512, VM502transmits the Host-ID, along with the constructed frame and authorization token from HSM504, to Cloud Identity Manager506. That is, in step S512, VM502presents itself and passes the token/frame to Cloud Identity Manager506, at which point process500proceeds to step S514, in which the exchange of authentication and authorization between VM502and Cloud Identity Manager506begins.

In step S516, upon confirmation of authorization in step S514, Cloud Identity Manager506signs the authorization token and returns the token to VM502. In an exemplary embodiment of step S516, Cloud Identity Manager506fails in the authorization token frame with specific information (e.g., the start and expiration time of the token) before signing the token and returning the token to VM502. In at least one embodiment of step S516, in the case where a Cloud Operator charges for access to HSM504, process500is further configured to initiate the charging mechanism at the time of transmittal of the signed token from Cloud Identity Manager506to VM502. In step S518, VM502completes the authentication process by returning the signed token to HSM504. In an exemplary embodiment of step S518, upon completing the authentication process, Cloud Identity Manager506may be further configured to check the authorization of VM502(e.g., based on its Host-ID) by consulting a database thereof, and/or by interrogating other management entities.

It should be noted that the particular authentication examples illustrated inFIG.5are provided for simplicity of explanation, and not in a limiting sense. For example, other authentication techniques may be implemented without deviating from the innovative principles of process500, or combination of a plurality of different authentication techniques may be employed, including techniques based on symmetric keys such as Kerberos protocol, which is conventionally used in a number of known operating systems.

The several embodiments described above are of further significance from the client perspective. A network architecture used by clients to access a local HSM instance should be, ideally, both secure and distinct. As described above, most conventional Cloud implementations are known to create clusters, or pods, of servers that support virtualized instances. These clusters/pods are often networked together using switches or routers with dedicated subnets or virtual LANs (VLANs) for various functions (e.g., client level communications, management communications, etc.). As described further below with respect toFIG.6, an improved client access network is created by the inclusion of a dedicated and/or encrypted HSM subnet (or VLAN) to provide a more secure, high performance resource for a local access HSM, such as for key management services and high performance cryptographic functionality.

FIG.6is a schematic illustration of a dedicated local HSM access network600. In an exemplary embodiment, access network600includes a jumpstart or boot server/node602, a controller or administrator server/node604, one or more computing servers/nodes606, one or more storage servers/nodes608, and at least one HSM610. In the exemplary embodiment, access network600further includes a switch or router612configured to manage access to a segregated boot network614, a segregated administration network616, a segregated public network618, a segregated private (e.g., tenant) network620, and a dedicated subnet622. Access network600may be implemented in a hierarchical organization of HSM networks to support various virtualization architectures, including NFV.

More particularly, in an exemplary embodiment ofFIG.6, an NFV infrastructure is implemented using clusters/pods of servers602,604,606,608. In exemplary operation of access network600, the respective servers are interconnected through one or more of the several segregated networks614,616,618,620, which are organized according to respective function desired of the particular segregated network (e.g., boot, administration, public, and private). Access network600improves upon the conventional access network paradigm by adding cryptographic security functions and key protection through the addition of HSM610and dedicated subnet622to overlay the architecture of access network600. Whereas conventional client access networks achieve security and key protection by leveraging segregated administration network616or segregated public network618, enhanced security and performance are achieved in access network600through dedication of a specific security network (i.e., dedicated subnet622) to support connectivity of HSM610to the various servers602,604,606,608implementing the NFV infrastructure.

In this example illustrated inFIG.6, HSM610is depicted to connect only through dedicated subnet622. Computing servers606, storage servers608, and switch/router612though, are depicted to connect with each of the several segregated networks614,616,618,620, as well as dedicated subnet622. Apart from dedicated subnet622, however, boot server602is depicted to only connect with segregated boot network614and segregated administrative network616, and administrative server604is depicted to only connect with segregated public network618and segregated private network620.

In some embodiments, dedicated access network600may be further enhanced by implementing a plurality of HSMs610in a distributed architecture (such as an HSM cloud, described above with respect toFIG.1), which will enable support of multiple clusters or pods. Furthermore, the exemplary embodiment depicted inFIG.6illustrates just one example of a physical implementation of a virtualized network infrastructure. The present inventors envision alternative infrastructure implementations, for example, that implemented by Red Hat to execute an Openstack architecture, that do not departing from the scope of the embodiments described herein. Some of the embodiments described above may implement security features onto the architectures thereof using TPMs, however, in some applications, greater degrees of flexibility may be desired than what can be achieved according to the TPM-based architecture. That is, greater flexibility may be desired to support persistent identity of software modules across different servers in a more secure manner.

According to the advantageous embodiments described herein, the present systems and methods are capable of dynamically addressing the threat level to an HSM both individually, and across multiple tiers and subnetworks of a networked computer system. The threat response may thus be optimally tailored (e.g., tamper proof, tamper resistant, and/or tamper aware) across the system according to the threat level encountered.

The present embodiments are described herein with respect to HSMs, but the person of ordinary skill in the art will understand, after reading and comprehending the present application, that the principles of the present embodiments are additionally applicable to trusted security modules that provide hardware protection of keys in a computer system. The present techniques provide innovative mechanisms for, once a key is placed in a trusted location, creating a network using that trusted key for other devices across the overall infrastructure, such that the other devices are subject to a level of protection substantially equal to the security provided by the original trusted key. This advantageous principle applies to software-based security mechanisms, in addition to hardware-based security modules.

By utilizing a unique key for each HSM, the need to create additional ephemeral keys is avoided, and in the event of a compromise, the single key advantageously allows an easier reverse determination of the impact from the compromise. Accordingly, multiple keys associated with separate modules may be used together, but where each module/unique key has a different functional purpose, thereby containing the risk across the infrastructure. If a particular HSM is determined to be compromised, other HSMs across the infrastructure may be subject to certificate renewal, either by request or automatically.

Exemplary embodiments of systems and methods for HSM credential transfer and VM migration, as well as authentication, attestation, and trust establishment in a computer network environment and for a client access network, are described above in detail. The systems and methods of this disclosure though, are not limited to only the specific embodiments described herein, but rather, the components and/or steps of their implementation may be utilized independently and separately from other components and/or steps described herein.

Although specific features of various embodiments of the disclosure may be shown in some drawings and not in others, this convention is for convenience purposes and ease of description only. In accordance with the principles of the disclosure, a particular feature shown in a drawing may be referenced and/or claimed in combination with features of the other drawings.