Patent Description:
Network operators and service providers typically rely on various network virtualization technologies to manage complex, large-scale computing environments, such as high-performance computing (HPC) and cloud computing environments. For example, network operators and service provider networks may rely on network function virtualization (NFV) deployments to deploy network services (e.g., firewall services, network address translation (NAT) services, load-balancing services, deep packet inspection (DPI) services, transmission control protocol (TCP) optimization services, etc.). Such NFV deployments typically use an NFV infrastructure to orchestrate various virtual machines (VMs) and/or containers (e.g., in a commodity server) to perform virtualized network services, commonly referred to as virtualized network functions (VNFs), on network traffic and to manage the network traffic across the various VMs and/or containers.

Unlike traditional, non-virtualized deployments, virtualized deployments decouple network functions from underlying hardware, which results in network functions and services that are highly dynamic and generally capable of being executed on off-the-shelf servers with general purpose processors. As such, the VNFs can be scaled-in/out as necessary based on particular functions or network services to be performed on the network traffic. Further, the VNFs can be deployed across geographies, on hosted infrastructure, etc., as a per subscriber demand.

The document "<NPL>describes the management and orchestration framework required for the provisioning of virtualized network functions (VNF), their operations, the configuration of the virtualized networking functions and the infrastructure these functions run on. The document "<NPL> aims at identifying and proposing solutions to any new vulnerabilities that result from the introduction of NFV. In the document "<NPL>an implementation of trusted execution environment based on the combination of trusted computing and virtualization technology is proposed. On the service provider's platform, from the very beginning of Virtual Machine Monitor (VMM) was booted to the execution environment was set up, all of the platform status changes are recorded into Platform Configuration Register (PCR) and reported to remote service requester, which make it sure about the trustworthy of the result.

The invention provides subject-matter as defined in the independent claims, preferred embodiments thereof defined in the dependent claims.

While the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will be described herein in detail.

Additionally, it should be appreciated that items included in a list in the form of "at least one of A, B, and C" can mean (A); (B); (C): (A and B); (A and C); (B and C); or (A, B, and C). Similarly, items listed in the form of "at least one of A, B, or C" can mean (A); (B); (C): (A and B); (A and C); (B and C); or (A, B, and C).

The disclosed embodiments may be implemented, in some cases, in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on one or more transitory or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. A machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device).

Referring now to <FIG>, in an illustrative embodiment, a system <NUM> for processing network traffic at a network functions virtualization (NFV) network architecture <NUM> includes a number of network processing components, including an NFV orchestrator <NUM>, a virtual infrastructure manager (VIM) <NUM>, and an NFV infrastructure <NUM>. Additionally, the NFV network architecture <NUM> includes an NFV security services controller <NUM> for managing and enforcing security monitoring and secure message transmission (e.g., setting up secure communication channels, authenticating messages transmitted across the secure communication channels, maintaining security of the secure communication channels, etc.) over the NFV network architecture <NUM>. As part of the initialization process of a virtual network function (VNF) instance of the NFV network architecture <NUM>, the NFV security services controller <NUM> provides a secure message to a previously instantiated VNF instance of the NFV infrastructure <NUM> that indicates to the VNF instance to perform a secure bootstrap. To do so, the NFV security services controller <NUM> includes a VNF bootstrap service (see <FIG>) and the VNF instance includes a VNF bootstrap service (VBS) agent (see <FIG>), which is responsible for performing the secure bootstrap and transmitting/receiving messages. Accordingly, the VNF instance can use the VBS agent to register with the NFV security services controller <NUM> as an operational VNF instance and receive VNF bootstrap information, such as start-up policies, configuration information, and securely register as an operational VNF instance. Additionally, in some embodiments, the VBS agent can enable VNF instance licensing and enforcement.

The network processing and security monitoring components of the NFV network architecture <NUM> can be deployed in various virtualization network architectures, such as a virtual Evolved Packet Core (vEPC) infrastructure, a virtualized Customer Premise Equipment (vCPE) infrastructure, or any other type of operator visualized infrastructures. It should be appreciated that, depending on the network architecture in which the NFV network architecture <NUM> is deployed, the NFV network architecture <NUM> may include one or more NFV security services controllers <NUM>, one or more NFV orchestrators <NUM>, one or more VIMs <NUM>, and/or one or more NFV infrastructures <NUM>. It should be further appreciated that, in some embodiments, the NFV security services controller <NUM> may be co-located with the NFV orchestrator <NUM> and/or the VIM <NUM>, such as in an NFV management and orchestration (MANO) architectural framework.

The NFV infrastructure <NUM> includes one or more computing nodes <NUM> capable of managing (e.g., creating, moving, destroying, etc.) a number of VMs and/or containers (e.g., in a commodity server) that are configured to run as VNF instances. Each VNF instance typically relies on one or more VMs, which may be running different software and/or processes to perform network services on network traffic (e.g., firewall services, network address translation (NAT) services, load-balancing services, deep packet inspection (DPI) services, transmission control protocol (TCP) optimization services, etc.). Further, to provide certain network services, multiple VNF instances may be created as a service function chain, or a VNF forwarding graph (i.e., a series of VNF instances performed in an ordered sequence to implement the desired network service).

The NFV security services controller <NUM> may be embodied as, or otherwise include, any type of hardware, software, and/or firmware capable of performing the functions described herein. As will be described in further detail below, the NFV security services controller <NUM> is configured to function as a security monitoring orchestrator. To do so, the NFV security services controller <NUM> is configured to transmit a security monitoring policy that includes various monitoring rules, which include secure communication path policies, configuration parameters, and function descriptors to components throughout the NFV network architecture <NUM> (e.g., the VNF instances located in the NFV network architecture <NUM>). The various security functions may include, but are not limited to, securing service function chaining (SFC) provisioning, enforcing SFC security configuration and monitoring, providing confidentiality protected tokens, managing protected policy transmission, and providing inter-VNF SFC path protection.

To retrieve and/or update the security monitoring policies, the NFV security services controller <NUM> may be configured to interface with one or more external security systems (e.g., an Intel® Security Controller), security databases, and/or security policy engines. To communicate with the external security systems, the NFV security services controller <NUM> may deliver an application programming interface (API) and/or the security policy to the external security services orchestration systems. In some embodiments, the NFV security services controller <NUM> may act as a trusted third party to authenticate messages across the various network and security monitoring components of the NFV network architecture <NUM>. It should be appreciated that, in some embodiments, the NFV security services controller <NUM> may have a higher security privilege than the other network and security monitoring components of the NFV network architecture <NUM> to ensure the integrity and security of the NFV security services controller <NUM>.

The NFV orchestrator <NUM> may be embodied as, or otherwise include, any type of hardware, software, and/or firmware capable of performing the functions described herein, such as managing the lifecycle of the VNF instances (e.g., instantiation, scale-out/in, performance measurements, event correlation, termination, etc.) via a VNF manager (see <FIG>), managing global resources, validating and authorizing resource requests of the NFV infrastructure <NUM>, on-boarding of new VNF instances, and/or managing various policies and packages for the VNF instances. For example, the NFV orchestrator <NUM> may be configured to receive resource requests from a network operator that impacts a particular VNF. In use, the NFV orchestrator <NUM> manages any applicable processing, storage, and/or network configuration adjustments, based on the operator requests, to bring the VNF into operation or into compliance with the resource requests. Once in operation, the NFV orchestrator <NUM> may monitor the VNF for capacity and utilization, which may be adjusted by the NFV orchestrator <NUM>, as necessary.

The VIM <NUM> may be embodied as, or otherwise include, any type of hardware, software, and/or firmware capable of performing the functions described herein. The VIM <NUM> is configured to control and manage compute, storage, and network resources (e.g., physical and virtual) of the NFV infrastructure <NUM>, such as within one operator's infrastructure sub-domain. Additionally, the VIM <NUM> is configured to collect and forward various information related to the VIM <NUM>, such as performance measurements and events.

The NFV infrastructure <NUM> may be embodied as, or otherwise include, any type of virtual and/or physical processing and storage resources, such as one or more servers or other computing nodes, as well as virtualization software. For example, the illustrative NFV infrastructure <NUM> includes one or more computing nodes <NUM>. The illustrative computing nodes <NUM> include a first computing node, which is designated as computing node (<NUM>) <NUM>, and a second computing node, which is designated as computing node (N) <NUM> (i.e., the "Nth" computing node of the computing nodes <NUM>, wherein "N" is a positive integer and designates one or more additional computing nodes <NUM>).

Each of the computing nodes <NUM> may be embodied as any type of computation or computer device capable of performing the functions described herein, including, without limitation, a server (e.g., stand-alone, rack-mounted, blade, etc.), a network appliance (e.g., physical or virtual), a high-performance computing device, a web appliance, a distributed computing system, a computer, a processor-based system, a multiprocessor system, a smartphone, a tablet computer, a laptop computer, a notebook computer, and/or a mobile computing device. As shown in <FIG>, in an embodiment, each of the computing nodes <NUM> illustratively includes a processor <NUM>, an input/output (I/O) subsystem <NUM>, a memory <NUM>, a data storage device <NUM>, a secure clock <NUM>, and communication circuitry <NUM>. Of course, the computing node <NUM> may include other or additional components, such as those commonly found in a server (e.g., various input/output devices), in other embodiments. Additionally, in some embodiments, one or more of the illustrative components may be incorporated in, or otherwise form a portion of, another component. For example, the memory <NUM>, or portions thereof, may be incorporated in the processor <NUM> in some embodiments.

The processor <NUM> may be embodied as any type of processor capable of performing the functions described herein. For example, the processor <NUM> may be embodied as a single or multi-core processor(s), digital signal processor, microcontroller, or other processor or processing/controlling circuit. The illustrative processor <NUM> includes one or more trusted execution environment (TEE) supports <NUM>, or secure enclave supports, which may be utilized by the computing node <NUM> in establishing a trusted execution environment. It should be appreciated that, in some embodiments, the TEE supports <NUM> provide hardware-reinforced security for the trusted execution environment in which executing code may be measured, verified, or otherwise determined to be authentic. For example, the TEE supports <NUM> may be embodied as Intel® Software Guard Extensions (SGX) technology. Although the TEE supports <NUM> are illustratively shown in the processor <NUM>, it should be appreciated that, in some embodiments, one or more of the other components of the computing node <NUM> may include the TEE supports <NUM>. Further, in some embodiments, processor <NUM> of the computing node <NUM> may include a security engine (e.g., security engine <NUM> discussed below), a manageability engine, or a security co-processor configured to utilize the TEE supports <NUM> to establish a trusted execution environment.

The memory <NUM> may be embodied as any type of volatile or non-volatile memory or data storage capable of performing the functions described herein. In operation, the memory <NUM> may store various data and software used during operation of the computing node <NUM> such as operating systems, applications, programs, libraries, and drivers. The memory <NUM> is communicatively coupled to the processor <NUM> via the I/O subsystem <NUM>, which may be embodied as circuitry and/or components to facilitate input/output operations with the processor <NUM>, the memory <NUM>, and other components of the computing node <NUM>. For example, the I/O subsystem <NUM> may be embodied as, or otherwise include, memory controller hubs, input/output control hubs, firmware devices, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.) and/or other components and subsystems to facilitate the input/output operations.

The illustrative memory <NUM> includes a secure memory <NUM>. In some embodiments, the secure memory <NUM> may be embodied as a secure partition of the memory <NUM>; whereas, in other embodiments, the secure memory <NUM> may be embodied or included on a separate hardware component of the computing node <NUM>. As described herein, the secure memory <NUM> may store various data provisioned to the computing node <NUM>. For example, the secure memory <NUM> may store a secure key (e.g., an attestation key, a private direct anonymous attestation (DAA) key, an Enhanced Privacy Identification (EPID) key, or any other type of secure/cryptographic key) of the computing node <NUM> that may be provisioned by a manufacturer of the chipset and/or of a trusted execution environment. The secure memory <NUM> may also store a password, PIN, or other unique identifier of the computing node <NUM> provisioned therein, for example, by an original equipment manufacturer (OEM) of the computing node <NUM>. Of course, it should be appreciated that the secure memory <NUM> may store various other data depending on the particular embodiment (e.g., group names, device identifiers, whitelists, expected PIN values, etc.). In some embodiments, the provisioned data may be stored in read-only memory of the secure memory <NUM>.

The illustrative memory <NUM> additionally includes a basic input/output system (BIOS) <NUM>. The BIOS <NUM> includes instructions (e.g., a BIOS driver used during booting of the computing node <NUM>) to initialize the computing node <NUM> during the boot process. In some embodiments, the computing node <NUM> may facilitate the orchestration of the VNF instances through a main platform firmware, or pre-boot firmware, such as an extension of the Intel® platform chipset or the platform BIOS <NUM> based on the Unified Extensible Firmware Interface ("UEFI") specification, which has several versions published by the Unified EFI Forum.

The data storage device <NUM> may be embodied as any type of device or devices configured for short-term or long-term storage of data such as, for example, memory devices and circuits, memory cards, hard disk drives, solid-state drives, or other data storage devices. In use, as described below, the data storage device <NUM> and/or the memory <NUM> may store security monitoring policies, configuration policies, or other, similar data.

The secure clock <NUM> may be embodied as any hardware component(s) or circuitry capable of providing a secure timing signal and otherwise performing the functions described herein. For example, in the illustrative embodiment, the secure clock <NUM> may generate a timing signal that is separate and functionally independent from other clock sources of the computing node <NUM>. Accordingly, in such embodiments, the secure clock <NUM> may be immune or resistant to alteration by other entities such as, for example, software executing on the computing node <NUM>. It should be appreciated that, in some embodiments, the secure clock <NUM> may be embodied as standalone component(s) or circuitry, whereas in other embodiments the secure clock <NUM> may be integrated with or form a secure portion of another component (e.g., the processor <NUM>). For example, in some embodiments, the secure clock <NUM> may be implemented via an on-chip oscillator and/or embodied as a secure clock of a manageability engine (ME). It should further be appreciated that the secure clock <NUM> may be synchronized to the secure clocks of the other computing nodes <NUM> and granularity may be of the order that can distinguish distinct message timings.

The communication circuitry <NUM> of the computing node <NUM> may be embodied as any communication circuit, device, or collection thereof, capable of enabling communications between the computing node <NUM> and another computing node <NUM>, the NFV orchestrator <NUM>, the VIM <NUM>, the endpoint devices <NUM>, <NUM>, and/or other connected network enabled computing node. The communication circuitry <NUM> may be configured to use any one or more communication technology (e.g., wired or wireless communications) and associated protocols (e.g., Ethernet, Bluetooth®, Wi-Fi®, WiMAX, GSM, LTE, etc.) to effect such communication. The illustrative communication circuitry <NUM> includes a network interface card (NIC) <NUM> and a switch <NUM>. The NIC <NUM> may be embodied as one or more add-in-boards, daughtercards, network interface cards, controller chips, chipsets, or other devices that may be used by the computing node <NUM>. For example, the NIC <NUM> may be embodied as an expansion card coupled to the I/O subsystem <NUM> over an expansion bus, such as PCI Express. The switch <NUM> may be embodied as any hardware component(s) or circuitry capable of performing network switch operations and otherwise performing the functions described herein, such as an Ethernet switch chip, a PCI Express switching chip, etc..

As discussed above, the computing node <NUM> may also include a security engine <NUM>, which may be embodied as any hardware component(s) or circuitry capable of establishing a trusted execution environment (TEE) on the computing node <NUM>. In particular, the security engine <NUM> may support executing code and/or accessing data that is independent and secure from other code executed by the computing node <NUM>. The security engine <NUM> may be embodied as a Trusted Platform Module (TPM), a manageability engine (ME), an out-of-band processor, or other security engine device or collection of devices (e.g., a trusted zone (TZ) of an an ARM® processor). In some embodiments the security engine <NUM> may be embodied as a converged security and manageability engine (CSME) incorporated in a system-on-a-chip (SoC) of the computing node <NUM>.

Referring again to <FIG>, the illustrative NFV network architecture <NUM> is communicatively coupled between the two endpoint devices <NUM>, <NUM>. In the illustrative system <NUM>, the first endpoint device is designated as endpoint device (<NUM>) <NUM> and the second endpoint device is designated as endpoint device (<NUM>) <NUM>. However, it should be appreciated that any number of endpoint devices may be connected through the NFV network architecture <NUM>. The endpoint devices <NUM>, <NUM> are communicatively coupled with the NFV network architecture <NUM> via a network (not shown), using wired or wireless technology, to form an end-to-end communication system in which the endpoint device (<NUM>) can communicate with the endpoint device (<NUM>), and vice versa. Accordingly, the NFV network architecture <NUM> can monitor and process the network communication traffic (i.e., network packets) transmitted between the endpoint devices <NUM>, <NUM>.

The network, via which the endpoint devices <NUM>, <NUM> communicate, may be embodied as any type of wired or wireless communication network, including cellular networks, such as Global System for Mobile Communications (GSM) or Long-Term Evolution (LTE), telephony networks, digital subscriber line (DSL) networks, cable networks, local or wide area networks, global networks (e.g., the Internet), or any combination thereof. For example, in some embodiments, the network may be embodied as an NFV-based Long-Term Evolution (LTE) network having a vEPC architecture. It should be appreciated that the network may serve as a centralized network and, in some embodiments, may be communicatively coupled to another network (e.g., the Internet). Accordingly, the network may include a variety of network devices, virtual and physical, such as routers, switches, network hubs, servers, storage devices, compute devices, etc., as needed to facilitate communication between the endpoint devices <NUM>, <NUM> and the NFV network architecture <NUM>.

The endpoint devices <NUM>, <NUM> may be embodied as any type of computation or computer device capable of performing the functions described herein, including, without limitation, a smartphone, a mobile computing device, a tablet computer, a laptop computer, a notebook computer, a computer, a server (e.g., stand-alone, rack-mounted, blade, etc.), a network appliance (e.g., physical or virtual), a web appliance, a distributed computing system, a processor-based system, and/or a multiprocessor system. As shown in <FIG>, similar to the computing node <NUM> of <FIG>, the illustrative endpoint device (e.g., one of the endpoint devices <NUM>, <NUM> of <FIG>) includes a processor <NUM>, an input/output (I/O) subsystem <NUM>, a memory <NUM>, a data storage device <NUM>, one or more peripheral devices <NUM>, and communication circuitry <NUM>. As such, further descriptions of the like components are not repeated herein for clarity of the description with the understanding that the description of the corresponding components provided above in regard to the computing node <NUM> applies equally to the corresponding components of the endpoint devices <NUM>, <NUM>.

Of course, the endpoint devices <NUM>, <NUM> may include other or additional components, such as those commonly found in a mobile computing device capable of operating in a telecommunications infrastructure in other embodiments (e.g., various input/output devices). Additionally, in some embodiments, one or more of the illustrative components may be incorporated in, or otherwise form a portion of, another component. The peripheral devices <NUM> may include any number of input/output devices, interface devices, and/or other peripheral devices. For example, in some embodiments, the peripheral devices <NUM> may include a display, touch screen, graphics circuitry, keyboard, mouse, speaker system, and/or other input/output devices, interface devices, and/or peripheral devices.

Referring now to <FIG>, an illustrative embodiment of the NFV network architecture <NUM> of <FIG> for securely bootstrapping a VNF of the NFV network architecture <NUM> includes the NFV security services controller <NUM>, the NFV orchestrator <NUM>, the VIM <NUM>, and the NFV infrastructure <NUM> of <FIG>, as well as a VNF manager <NUM>. As described previously, in use, the NFV orchestrator <NUM> manages the lifecycle of the VNF instances in the NFV infrastructure <NUM>, including instantiation, scaling-out/in, measuring performance, correlating events, termination, etc. To do so, the NFV orchestrator <NUM> is configured to provide instructions to the VNF manager <NUM> via a secure communication channel <NUM> to manage the initialization and configuration (i.e., scaling and deployment) of the VNF instances of the NFV infrastructure <NUM> (see the VNF instances <NUM>) based on resources of the NFV infrastructure <NUM>.

The VNF manager <NUM> is further configured to perform overall coordination and adaptation for configuration and event reporting for the NFV infrastructure <NUM>. The VNF manager <NUM> is additionally configured to update and ensure the integrity of the VNF instances. To do so, the VNF manager <NUM> is configured to communicate with the VIM <NUM> via a secure communication channel <NUM> to determine the available physical resources on which to instantiate particular VNF instances. It should be appreciated that the VIM <NUM> may make such a determination using any suitable techniques, algorithms, and/or mechanisms. It should be further appreciated that, in some embodiments a single VNF manger <NUM> may be responsible for managing one or more VNF instances. In other words, in some embodiments, a VNF manager <NUM> may be instantiated for each of the VNF instances.

The NFV network architecture <NUM> additionally includes an operations support systems and business support systems (OSS/BSS) <NUM> that is communicatively coupled to the NFV orchestrator <NUM> via a communication channel <NUM>. The OSS/BSS <NUM> may be embodied as any type of computation or computing node capable of performing the functions described herein, such as supporting various end-to-end telecommunication services in a telephone network. In some embodiments, the OSS/BSS <NUM> may be configured to support management functions such as network inventory, service provisioning, network configuration, and fault management, as well as various business functions to support end-to-end telecommunication services that may be supported by the OSS/BSS <NUM>, such as product management, customer management, revenue management, order management, etc..

The NFV security services controller <NUM> is communicatively coupled to the NFV orchestrator <NUM> via a secure communication channel <NUM>. It should be appreciated that, in some embodiments, the NFV security services controller <NUM> and the NFV orchestrator <NUM> may be co-located, such as in the MANO architectural framework. Further, the NFV security services controller <NUM> is communicatively coupled to the VIM <NUM> via a secure communication channel <NUM> and the NFV orchestrator <NUM> is communicatively coupled to the VIM <NUM> via a secure communication channel <NUM>. The secure communication channels of the NFV network architecture <NUM> (e.g., the secure communication channel <NUM>, the secure communication channel <NUM>, etc.) may be protected with secure keys (e.g., session keys and/or other cryptographic keys) used by the NFV security services controller <NUM> to establish a root of trust (RoT) to establish the communication channels. In some embodiments, the secure keys may be embodied as pairwise session keys that may be refreshed periodically. As such, the NFV security services controller <NUM> can be configured to act as an authentication server.

The NFV security services controller <NUM> includes the VNF bootstrap service (VBS) <NUM> that is configured to manage the VBS agents, described further below, of the VNF instances in the NFV infrastructure <NUM>. In use, the VBS <NUM> manages the secure bootstrap process (i.e., execution of the secure VNF bootstrap capture protocol of <FIG> and <FIG>) from a trust anchor perspective. Accordingly, in some embodiments, the NFV security services controller <NUM> may additionally include a trusted execution environment (TEE) <NUM> in which the VBS <NUM> may reside. It should be appreciated, however, that in some embodiments, the VBS <NUM> may reside outside of the NFV security services controller <NUM>, such as on a dedicated VBS server. In such embodiments, the VBS <NUM> may still be run in a TEE.

Additionally, the illustrative NFV security services controller <NUM> interfaces with a security audit and forensic database <NUM>. The security audit and forensic database <NUM> is embodied as a secure database that includes security audit information relative to the various security monitoring components of the NFV network architecture <NUM>. The security audit information may include any information related to the security of the NFV network architecture <NUM> including, for example, configuration change logs, network traces, debug traces, application traces, etc. In the illustrative NFV network architecture <NUM>, the security audit and forensic database <NUM> is additionally configured to interface with other network and security monitoring components of the NFV network architecture <NUM>, such as the VIM <NUM> and the various NFV security services agents distributed across the NFV network architecture <NUM>, which will be discussed in further detail below. In some embodiments, the various security monitoring components of the illustrative NFV network architecture <NUM> that interface with the security audit and forensic database <NUM> may use a secure clock (e.g., the secure clock <NUM> of <FIG>) to timestamp the logs received at the security audit and forensic database <NUM> for secure storage.

As described previously, in use, the VIM <NUM> controls and manages the allocation of virtual and physical (i.e., hardware) compute, storage, and network resources of the NFV infrastructure <NUM> through messages securely transmitted via a secure communication channel <NUM>. Additionally, in some embodiments, the VIM <NUM> may be configured to collect and securely forward performance measurements and events of the NFV infrastructure <NUM> compute, storage, and network resources (e.g., physical and virtual) to the security audit and forensic database <NUM>. The illustrative VIM <NUM> includes a VIM controller <NUM>. The VIM controller <NUM> is configured to function as a cloud operating system VNF install and activate service. For example, in some embodiments, the VIM controller may be embodied as a network policy controller, or a networking service controller (e.g., a software defined networking (SDN) controller or an OpenStack Neutron), or as a compute service controller (e.g., Openstack Nova). Additionally or alternatively, in some embodiments, the VIM controller <NUM> may be embodied as an image service controller, an identity service controller, etc..

The NFV infrastructure <NUM> includes all of the hardware and software components (i.e., virtual compute, storage, and network resources, virtualization software, hardware compute, storage, and network resources, etc.) of the computing nodes <NUM> from which the VNF instances may be deployed. It should be appreciated that the physical and/or virtual components of the NFV infrastructure <NUM> may span across different locations, data centers, geographies, providers, etc. Additionally, it should be further appreciated that the network through which the components of the NFV infrastructure <NUM> use to communicate and interface through may be considered to be included in the NFV infrastructure <NUM>.

The illustrative NFV infrastructure <NUM> includes a number of VNF instances <NUM> and an operator infrastructure <NUM>. The operator infrastructure <NUM> includes one or more platforms <NUM>, the BIOS <NUM> of <FIG>, and a hypervisor <NUM>. The operator infrastructure <NUM> may include multiple different network infrastructures for deploying the VNF instances <NUM>. Accordingly, an operator can use the multiple different network infrastructures to deploy on the NFV infrastructure <NUM> (i.e., a physical infrastructure) or on another operators physical infrastructure, as well as on a third party cloud hosting infrastructure and/or at a customer's premises on customer equipment, etc. For example, deployment scenarios may include a monolithic operator operating in a private cloud model, a network operator hosting virtual network operators in a hybrid cloud, a hosted network operator, hosted communications and application providers in a public cloud model, managed network services on customer premises/equipment, etc..

The illustrative platforms <NUM> include a first platform, which is designated as platform (<NUM>) <NUM>, and a second platform, which is designated as platform (N) <NUM> (i.e., the "Nth" platform, wherein "N" is a positive integer and designates one or more additional platforms). Each of the platforms <NUM> includes the I/O subsystem <NUM>, the NIC <NUM> (or the switch <NUM>), and the data storage of <FIG>. Each of the platforms <NUM> additionally includes an identifier (e.g., a BIOS <NUM> (UEFI) identifier) unique to that platform, which can be stored in a secure location (e.g., the secure memory <NUM>). The unique platform identifier may be a combination hash, or globally unique identifier (GUID), of a hardware identifier, an original equipment manufacturer (OEM) board identifier, a BIOS /UEFI stock keeping unit (SKU) identifier, a field replaceable unit (FRU) identifier, an operating system version identifier, etc..

The illustrative platform (<NUM>) <NUM> additionally includes a TEE <NUM>. The TEE <NUM> may be established by a CSME, an SGX, an IE, an ME, or a physical, virtual (i.e., software-based), or firmware TPM (e.g., a firmware TPM on the security engine <NUM> that consists of a secure partition, a security co-processor or separate processor core, etc.) in a secure environment (e.g., the TEE supports <NUM> of the processor <NUM>). Additionally, the TEE <NUM> can be securely provisioned in the platform (<NUM>) <NUM> through a secure provisioning procedure with the NFV security services controller <NUM>. In some embodiments, the secure provisioning procedure may be performed via a bootstrap with the NFV security services controller <NUM>. Additionally or alternatively, in some embodiments, the secure provisioning procedure may be performed offline.

The hypervisor <NUM>, or virtual machine monitor (VMM), is configured to establish and/or utilize various virtualized hardware resources (e.g., virtual memory, virtual operating systems, virtual networking components, etc.) of the NFV infrastructure <NUM>. Additionally, the hypervisor <NUM> may facilitate communication across the VNF instances <NUM>. The illustrative hypervisor <NUM> includes one or more cloud operating system agents <NUM> that may be configured to bolster cloud service discovery, service negotiation, and/or service composition. In some embodiments, the hypervisor <NUM> may additionally include a TEE <NUM> that is configured to function similar to the TEE <NUM>, but at the virtual, or hypervisor, level of the NFV infrastructure <NUM>.

The hypervisor <NUM>, in use, runs the VNF instances <NUM>, generally via one or more VMs and/or containers for running each of the VNF instances <NUM>. In some embodiments, the VNF instances <NUM> may include a billing function, a virtual switch (vSwitch), a virtual router (vRouter), a firewall, a network address translation (NAT), a DPI, an evolved packet core (EPC), a mobility management entity (MME), a packet data network gateway (PGW), a serving gateway (SGW), and/or other virtual network function. In some embodiments, a particular VNF instance <NUM> may have multiple sub-instances, which could be executing on a single platform (e.g., the platform <NUM>) or across different platforms (e.g., the platform <NUM> and the platform <NUM>). In other words, when virtualized, network functions traditionally handled by physical hardware co-located with a particular platform may be distributed as a number of VNF instances <NUM> across one or more of the platforms <NUM>.

Each of the VNF instances <NUM> may include one or more VNF instances. For example, in some embodiments, any of the VNF instances <NUM> may bundle multiple VNF instances of a service function chain. Further, each of the VNF instances may include one or more VNF components (VNFCs) (not shown). It should be appreciated that the VNF instances <NUM> may be embodied as any suitable virtual network functions; similarly, the VNFCs may be embodied as any suitable VNF components. The VNFCs are processes and/or instances that cooperate to deliver the functionality of one or more VNF instances <NUM>. For example, in some embodiments, the VNFCs may be sub-modules of the VNF instances <NUM>. Similar to the VNF instances <NUM>, it should be appreciated that the VNFCs may be distributed across one or more platforms <NUM>. It should be further appreciated that a particular VNF instance <NUM> may be distributed across multiple platforms <NUM> and still form a part of a VNF instance <NUM> established on a one of the platforms <NUM>. In such embodiments, the VNF instances <NUM> and/or the VNFCs may be executing on the same platform (e.g., the platform <NUM> or the platform <NUM>) or within the same data center but on different platforms <NUM>. Further, in some embodiments, the VNF instances <NUM> and/or the VNFCs may be executing across different data centers. Similar to the hypervisor <NUM> facilitating communication across the VNF instances <NUM>, the hypervisor <NUM> may additionally facilitate communications across the VNFCs.

The illustrative VNF instances <NUM> include a first VNF instance, which is designated as VNF (<NUM>) <NUM>, a second VNF instance, which is designated as VNF (<NUM>) <NUM>, and a third VNF instance, which is designated as VNF (N) <NUM> (i.e., the "Nth" VNF, wherein "N" is a positive integer and designates one or more additional VNF instances). Each of the VNF instances <NUM> are configured to perform as a virtual networking device (e.g., a vSwitch, a vRouter, a firewall, a NAT, a DPI, an EPC, an MME, a PGW, a SGW, etc.). In some embodiments, one or more VNF instances <NUM> may comprise a service function chain that is capable of performing a particular virtual function or service. One or more of the VNF instances <NUM> may include a packet processor (not shown) to process the network traffic at the user data plane, such as the Intel® Data Plane Development Kit (Intel® DPDK).

Similar to the identifier unique to each of the platforms <NUM>, each of the VNF instances <NUM> includes a unique identifier. The unique VNF instance identifier of the VNF instance <NUM> may be a combination hash, or a GUID, of an image of the VNF instance <NUM>, a VNF descriptor identifier, a VNF command line identifier, a VNF OEM identifier, a VNF vendor identifier, and/or VNFC identifiers. Accordingly, the unique VNF instance identifier may be used by the NFV security services controller <NUM>, the VIM <NUM>, and/or the VNF manager <NUM> when securely communicating with the VNF instances <NUM>. For example, the VIM <NUM> may initiate the spinning up a VNF instance at the NFV infrastructure <NUM> via a secure communication channel <NUM> using the unique VNF instance identifier. Similarly, the VNF manager <NUM> may use the unique VNF instance identifier when setting up a management session with a particular VNF instance <NUM> via a secure communication channel <NUM>.

Each of the illustrative VNF instances <NUM> includes a VBS agent (i.e., a VBS agent <NUM> of the VNF (<NUM>) <NUM>, a VBS agent <NUM> of the VNF (<NUM>) <NUM>, and a VBS agent <NUM> of the VNF (N) <NUM>) to securely bootstrap each of the VNF instances <NUM> to enable the VNF instances <NUM> to be provisioned securely, such as with a root credential. Further, each of the illustrative VNF instances is in secure network communication with the VBS <NUM> of the NFV security services controller <NUM> via a secure communication channel <NUM>, as well as the operator infrastructure <NUM> (i.e., via secure communication channels <NUM>, <NUM>, <NUM>).

As will be described in further detail below, each VBS agent <NUM>, <NUM>, <NUM> is configured to perform a secure bootstrap process (i.e., the execution of the secure VNF bootstrap capture protocol of <FIG> and <FIG>). To do so, each VBS agent <NUM>, <NUM>, <NUM> is configured to instantiate a previously spun-up VNF instance, create a public/private key pair (i.e., a public key and a private key) to be used for security in communicating with the NFV security services controller <NUM> when running the secure bootstrap process, and run the secure bootstrap process. It should be appreciated that, in some embodiments, the NFV infrastructure <NUM> may additionally include other VNF instances that do not include a VBS agent.

As described previously, the VNF instances <NUM> may bundle more than one VNF, such as may be required in a service function chain. In such embodiments, the secure bootstrap process can be used to bootstrap the entire service function chain. Additionally, in embodiments wherein the VNF instances <NUM> are factored along the control plane and the data plane, the secure bootstrap process can be utilized in a one to one, one to many, or many to many control plane and data plane VNF instances.

Referring now to <FIG>, in use, the NFV security services controller <NUM> establishes an environment <NUM> during operation. The illustrative environment <NUM> of the NFV security services controller <NUM> includes a secure communication module <NUM> and the VNF bootstrapping service <NUM> of <FIG>. Additionally, the VNF bootstrapping service <NUM> includes a VBS agent communication module <NUM>, a VBS agent registration module <NUM>.

The various modules of the environment <NUM> may be embodied as hardware, firmware, software, or a combination thereof. For example, the various modules, logic, and other components of the environment <NUM> may form a portion of, or otherwise be established by hardware components of the NFV security services controller <NUM>. As such, in some embodiments, any one or more of the modules of the environment <NUM> may be embodied as a circuit or collection of electrical devices (e.g., a secure communication circuit, a VBS agent communication circuit, and a VBS agent registration circuit, etc.). Additionally or alternatively, in some embodiments, one or more of the illustrative modules may form a portion of another module and/or one or more of the illustrative modules and/or submodules, which may be embodied as standalone or independent modules.

The secure communication module <NUM> is configured to facilitate secure communications (i.e., messages) between the NFV security services controller <NUM> and the various network processing components of the NFV network architecture <NUM>. To do so, the secure communication module <NUM> is configured to secure communication paths between the NFV security services controller <NUM> and the various network processing components of the NFV network architecture <NUM> (e.g., the VIM <NUM>, the VNF manager <NUM>, etc.). Accordingly, in some embodiments, the secure communication module <NUM> may perform various key management functions, cryptographic functions, secure communication channel management, and/or other security functions. For example, the secure communication module <NUM> can be configured to secure the communication channel between the NFV security services controller <NUM> and the VNF manager <NUM> of <FIG> (e.g., the secure communication channel <NUM>) using pairwise session keys that are refreshed periodically to ensure the security of communications between the NFV security services controller <NUM> and the VNF manager <NUM>.

The VBS agent communication module <NUM>, similar to the secure communication module <NUM>, is configured to facilitate and manage secure communications (i.e., messages) between the VBS <NUM> and the VBS agents of the VNF instances <NUM> of the NFV infrastructure <NUM>. The VBS agent registration module <NUM> is configured to register the VBS agents upon execution of the secure bootstrap process. To do so, the VBS agent registration module <NUM> includes a VBS agent verification module <NUM> and a VBS agent security credential module <NUM>.

The VBS agent verification module <NUM> is configured to verify secure bootstrap parameters of the VBS agent (e.g., values and hashes). To do so, the VBS agent verification module <NUM> is be configured to verify an authenticity of a security quote received from a VBS agent during execution of the VBS capture protocol, which is described in further detail below. Additionally or alternatively, in some embodiments, the VBS agent verification module <NUM> may be configured to perform a whitelist check to verify a configuration of the VBS <NUM> based on one or more provisioning parameters received by the VBS <NUM>, or the security controller <NUM>, during a secure provisioning of the VBS <NUM>. In some embodiments, the VBS agent verification module <NUM> may be additionally or alternatively configured to detect a liveness of the messages (i.e., that the messages have not expired, such as in a replay attack) between the VBS agent and the VBS <NUM> using a nonce session, which is also described further below. Additionally or alternatively, in some embodiments, the VBS agent verification module <NUM> may be configured to verify an authenticity of a public key of the VNF instance of the VBS agent, received from the VBS agent during execution of the VBS capture protocol.

The VBS agent security credential module <NUM> is configured to provide a valid security credential (e.g., a certificate, a signed hash result, etc.) for the VBS agent being registered during execution of the VBS capture protocol. To do so, the VBS agent security credential module <NUM> may be configured to create or retrieve a valid security credential in response to the VBS agent verification module <NUM> having verified the authenticity of the security quote and the public key of the VNF instance, as well as having validated the liveness of the messages (i.e., that the messages are not dead, such as in a replay attack).

Referring now to <FIG>, in use, each VNF instance (e.g., VNF instances <NUM>, <NUM>, <NUM> of <FIG>) establishes an environment <NUM> during operation. The illustrative environment <NUM> of the corresponding VNF instance includes a secure communication module <NUM> and a VBS agent (e.g., one of the VBS agents <NUM>, <NUM>, <NUM> of <FIG>). The illustrative VBS agent includes a VBS communication module <NUM> and a VBS capture protocol execution module <NUM> of the VBS agent. The various modules of the environment <NUM> may be embodied as hardware, firmware, software, or a combination thereof. For example, the various modules, logic, and other components of the environment <NUM> may form a portion of, or otherwise be established by hardware components of the NFV security services agent. As such, in some embodiments, any one or more of the modules of the environment <NUM> may be embodied as a circuit or collection of electrical devices (e.g., a secure communication circuit, VBS communication circuit, and a VBS capture protocol execution circuit, etc.). Additionally or alternatively, in some embodiments, one or more of the illustrative modules may form a portion of another module and/or one or more of the illustrative modules and/or submodules may be embodied as a standalone or independent module.

The secure communication module <NUM> is configured to facilitate the secure transmission of data (i.e., messages) to and from the VBS agent. The VBS communication module <NUM>, similar to the secure communication module <NUM>, is configured to facilitate and manage secure communications (e.g., registration data, verification data, configuration data, etc.) between the VBS agent and the VBS <NUM> of the NFV security services controller <NUM>, such as during the secure bootstrap process. The VBS capture protocol execution module <NUM> is configured to execute the secure VNF bootstrap capture protocol, which is described in <FIG> and <FIG>. To do so, the VBS capture protocol execution module <NUM> is configured to create a public/private key pair (i.e., a public key and a private key) and request a security quote (e.g., an attestation quote, or a digitally signed value from which a TEE can be verified or authenticated), from a TEE of a platform on which the VNF instance is instantiated (e.g., the TEE <NUM> of the platform <NUM> of <FIG>). Accordingly, the TEE can attest to the identity and configuration of the VBS agent (e.g., running correct VBS agent, configured by the correct launch parameters, the VBS agent generated the public key being requested. Additionally, remote attestation can be implemented to detect possible security threats, such as network packet tampering, network packet corruption, malicious content within network packets, etc..

Referring now to <FIG>, in use, a VNF instance (e.g., one of the VNF instances <NUM> of <FIG>) may execute a method <NUM> for initializing a secure VNF bootstrap. The method <NUM> begins at block <NUM>, in which the VNF instance determines whether an instantiation trigger was received, such as from the OSS/BSS <NUM> of <FIG>. It should be appreciated that, in some embodiments, the instantiation may be automatically performed subsequent to the VNF instance being created. If not, the method <NUM> loops back to block <NUM> to continue to wait for the instantiation trigger to be received. If the instantiation trigger was received, the method advances to block <NUM>. At block <NUM>, the VNF instance instantiates based on a set of startup parameters (i.e., startup requirements). It should be appreciated that the instantiated VNF instance is not active (i.e., the VNF instance is not processing network traffic).

At block <NUM>, the VNF instance runs the secure VNF bootstrap capture protocol, which is described in further detail in <FIG> and <FIG>. At block <NUM>, the VNF instance determines whether an activation signal was received, such as from the NFV security services controller <NUM> or the VNF manager <NUM>, that indicates to activate the VNF instance (i.e., to start processing network traffic). If not, the method <NUM> loops back to block <NUM> to continue to wait for the activation signal to be received. If the activation signal was received, the method <NUM> advances to block <NUM>. At block <NUM>, the VNF instance retrieves startup policies and configuration information specific to the operation to be performed by the VNF instance.

At block <NUM>, the VNF instance securely registers as an operational VNF instance. To do so, the VNF instance securely transmits a registration request message to the VBS <NUM>. At block <NUM>, the VNF instance determines whether a registration confirmation was received in response to the registration request message transmitted at block <NUM>. If not, the method <NUM> loops back to block <NUM> to continue to wait for the registration confirmation. If the registration confirmation was received, the method <NUM> advances to block <NUM>. At block <NUM>, the VNF instance identifies a corresponding VNF manager (e.g., the VNF manager <NUM>), such as by an IP address of the VNF manager, which may be received with the registration confirmation. It should be appreciated that, in some embodiments, multiple VNF managers may be present in the NFV network architecture <NUM>. Accordingly, in such embodiments, the VNF manager that corresponds to the VNF instance may be identified by a unique identifier associated with that VNF manager, which may be provided to the VNF instance by the NFV security services controller <NUM>. As such, in such embodiments, the VNF instance may request the unique identifier from the NFV security services controller <NUM> before advancing.

At block <NUM>, the VNF instance connects to the identified VNF manager. Accordingly, the identified VNF manager can manage the lifecycle of the VNF instance (e.g., instantiate, update, query, scale, terminate, etc.). In some embodiments, at block <NUM>, the VNF instance enables VNF licensing and enforcement. Accordingly, the licenses assigned to each of the VNF instances <NUM> can be tracked and enforced (e.g., by VNF vendors concerned with revenues generated by the VNF instances <NUM>). To do so, in some embodiments, VNF license information (e.g., a license number, the unique VNF instance identifier, etc.) may be transmitted to the VNF manager, the NFV security services controller <NUM>, and/or a dedicated license management server. At block <NUM>, the VNF instance performs the operation (i.e., service or function) to which the VNF instance has been instantiated for.

Referring now to <FIG>, an embodiment of a communication flow <NUM> for securely bootstrapping a VNF instance (e.g., one of the VNF instances <NUM> of <FIG>) of the NFV network architecture <NUM>. The illustrative communication flow <NUM> includes the NFV orchestrator <NUM>, the VIM controller <NUM> of the VIM <NUM>, the cloud operating system agent <NUM> of the hypervisor <NUM>, the hypervisor <NUM> of NFV infrastructure <NUM>, one of the VBS agents of one of the VNF instances <NUM> (e.g., the VBS agent <NUM>, the VBS agent <NUM>, or the VBS agent <NUM>), the TEE <NUM> of the platform <NUM>, the VBS <NUM> of the NFV security services controller <NUM>, and the VNF manager <NUM>. The illustrative communication flow <NUM> additionally includes a number of message flows, some of which may be executed separately or together, depending on the embodiment.

At message flow <NUM>, the NFV orchestrator <NUM> securely transmits a VNF instantiation trigger, received from the OSS/BSS <NUM>, to the VIM controller <NUM>. The VNF instantiation trigger can include signatures of a signed VNF image and a signed VNF descriptor. The signed VNF descriptor is a data structure that describes requirements and/or necessary elements of the VNF image, including startup parameters (i.e., startup requirements). At message flow <NUM>, the TEE <NUM> securely provisions the VBS <NUM>. To do so, the TEE <NUM> provides provisioning parameters and an identifier that is unique to the platform on which the VNF is to be instantiated (i.e., the unique platform identifier) to the security controller <NUM> on which the VBS resides. Accordingly, in some embodiments, the TEE <NUM> may be used to securely provision the VBS <NUM>. The provisioning parameters include a public key of the VBS <NUM> and an identifier of the VBS <NUM>, such as an IP address, a DNS, etc. As described previously, the unique platform identifier may be a combination hash, or GUID, of a hardware identifier, an OEM board identifier, a BIOS /UEFI SKU identifier, a FRU identifier, an operating system version identifier, etc. In some embodiments, the TEE <NUM> may securely provision the VBS <NUM> using out of band (OOB) communication technologies to transmit the public key of the VBS <NUM> and the VBS <NUM> identifier, as well as any other provisioning items that may be needed to securely provision the VBS <NUM>.

At message flow <NUM>, the VIM controller <NUM> verifies signatures of the information received with the VNF instantiation trigger, such as the signed VNF descriptor and the signed VNF image. In some embodiments, the signed VNF image may include more than one signed VNF images. In such embodiments, the more than one signed VNF images may be stitched and signed again as a group of VNF images, or delivered as separate, signed VNF images. Accordingly, each signature associated with the signed VNF image is verified at the VIM controller <NUM>.

At message flow <NUM>, the VIM controller <NUM> securely transmits a command to spin-up a VNF instance based on the VNF image and descriptor. The spin-up command additionally includes a set of VBS parameters (i.e., details of the VBS <NUM>), which may include the public key of the VBS <NUM>, the IP address of the VBS <NUM>, a domain name server (DNS) of the VBS <NUM>, a fully qualified domain name (FQDN) of the VBS <NUM>, a uniform resource locator (URL) of the VBS <NUM>, and/or the like.

At message flow <NUM> the hypervisor <NUM> spins up a VNF instance (e.g., one of the VNF instances <NUM>) based on the signed VNF image and the signed VNF descriptor. To do so, the hypervisor <NUM> verifies the VNF signatures (e.g., signatures of the signed VNF image, the signed VNF descriptor, etc.) at message flow <NUM> and creates a VNF instance at message flow <NUM>. At message flow <NUM>, the hypervisor <NUM> registers with the TEE <NUM>. To do so, the hypervisor <NUM> securely transmits an identifier unique to the created VNF instance. The unique VNF instance identifier may be a combination hash, or a GUID, of a VNF image instance identifier, a VNF descriptor identifier, a composition of VNFC identifiers, a VNF command line identifier, and VNF OEM identifier, a VNF vendor identifier, etc. Additionally, the hypervisor <NUM> may securely transmit configuration information of the VNF instance.

At message flow <NUM>, the VBS agent creates a public/private key pair (i.e., a public key and a private key) for the VNF instance. At message flow <NUM>, the VBS agent retrieves a security quote from the TEE <NUM>. Accordingly, remote attestation can be implemented to detect possible security threats, such as network packet tampering, network packet corruption, malicious content within network packets, etc. To do so, the VBS agent may securely transmit VNF identification information, such as the unique platform identifier, the unique VNF instance identifier, etc., to the TEE <NUM>.

At message flow <NUM>, the VBS <NUM> performs a secure whitelisting with the VNF manager <NUM>. In other words, the VBS <NUM> adds the VNF instance to the list or register of recognized (i.e., privileged or otherwise approved) VBS agents to be managed by the VNF manager <NUM>. To do so, the VBS <NUM> may securely transmit VNF identification information (e.g., the unique VNF instance identifier) to the VNF manager <NUM> and one or more VBS parameters (e.g., the IP address of the VBS <NUM>, the DNS of the VBS <NUM>, etc.).

At message flow <NUM>, the VBS agent executes the secure VNF bootstrap capture protocol, which is shown in <FIG> and <FIG>. At message flow <NUM>, the VBS agent activates the VNF instance. In other words, network traffic processing is enabled at the VNF instance. At message flow <NUM>, the VBS <NUM> securely transmits a VNF activated message, including the unique VNF instance identifier, to the VNF manager <NUM> to indicate that the VNF instance is now active. Similarly, at message flow <NUM>, the VBS agent securely transmits a VNF activated message to the VNF manager <NUM> to indicate that the VNF instance has been activated. Accordingly, the VNF activated message includes the unique VNF instance identifier.

Referring now to <FIG>, in use, a VBS agent (e.g., the VBS agent <NUM>, the VBS agent <NUM>, or the VBS agent <NUM> of <FIG>) may execute a method <NUM> for executing a secure VNF bootstrap capture protocol. The method <NUM> begins at block <NUM>, in which the VBS agent securely transmits a start message to the VBS <NUM>. The start message may be embodied as any type of message that informs the VBS <NUM> that the respective VBS agent has initiated. At block <NUM>, the VBS agent securely transmits the start message with a nonce (e.g., a random challenge issued by the VBS agent to detect replays at the VBS <NUM>) generated by the VBS agent to be used for secure authentication. At block <NUM>, the VBS agent securely receives a start response message from the VBS <NUM>. At block <NUM>, the VBS agent receives the nonce transmitted with the start message at block <NUM> as part of the start response message. Additionally, at block <NUM>, the VBS agent receives a nonce generated by the VBS <NUM> as part of the start response message. Accordingly, a liveness detection may be performed on the start response message to prove liveness of the response. Further, at block <NUM>, the VBS agent receives the start response message signed by the VBS <NUM> using a private key of the VBS <NUM>.

At block <NUM>, the VBS agent securely transmits a registration request message to the VBS <NUM>. To do so, at block <NUM>, the VBS agent securely transmits a security quote signed by the TEE <NUM>, using a private key of the TEE <NUM>, as part of the registration request message. The security quote, the calculation of which is described in further detail below, is a digitally signed value from which a receiver of the security quote can authenticate the transmitter of the digitally signed value. Accordingly, remote attestation can be implemented to detect possible security threats, such as network packet tampering, network packet corruption, malicious content within network packets, etc. Additionally, at block <NUM>, the VBS agent securely transmits a security credential request, signed by the VBS agent using a private key of the VNF, to request a security credential (e.g., a certificate, a signed hash result, etc.) as part of the registration request message. In some embodiments, the security credential request may include each of the nonces generated at the VBS <NUM> and the VBS agent, and a public key of the VNF instance. Additionally or alternatively, in some embodiments, the certification request may also include a quote signed by the TEE <NUM> using the private key of the TEE <NUM>.

At block <NUM>, the VBS agent securely receives a registration request message response from the VBS <NUM>. At block <NUM>, the registration request message response received by the VBS agent includes a valid security credential. Additionally, at block <NUM>, the registration request message response received by the VBS agent includes an IP address of a corresponding VNF manager (e.g., the VNF manager <NUM> of <FIG>). At block <NUM>, the registration request message response received by the VBS agent is signed by the VBS <NUM> using the private key of the VBS <NUM>.

Referring now to <FIG>, an embodiment of a communication flow <NUM> for executing a secure VNF bootstrap capture protocol by a VBS agent (e.g., the VBS agent <NUM>, the VBS agent <NUM>, or the VBS agent <NUM> of <FIG>). The illustrative communication flow <NUM> includes one of the VBS agents of one of the VNF instances <NUM> (e.g.,), the TEE <NUM> of the platform <NUM>, and the VBS <NUM> of the NFV security services controller <NUM>. The illustrative communication flow <NUM> additionally includes a number of message flows, some of which may be executed separately or together, depending on the embodiment.

At message flow <NUM>, the VBS agent securely transmits a start message that includes a nonce (e.g., an arbitrary number for authentication) to the VBS <NUM>. At message flow <NUM>, the VBS <NUM> securely transmits a start response message to the VBS agent that includes the nonce from the VBS agent and another nonce (e.g., another arbitrary number for authentication). Further, the start response message is signed by the VBS <NUM> using a private key of the VBS <NUM>. At message flow <NUM>, the VBS agent securely transmits a registration request message to the VBS <NUM>. The registration request message includes a security quote (see <FIG>) signed by the TEE <NUM> using the private key signed by the TEE <NUM>. The registration request message additionally includes a security credential request that includes the both the nonce from the VBS agent and the nonce from the VBS <NUM>, as well as the public key of the VNF instance on which the VBS agent is initialized. Further, the security credential request is signed by the VBS agent using the private key of the VNF instance. The security quote, calculated and signed by the TEE <NUM>, is the result of a TEE quoting operation, which is described in further detail in <FIG>.

At message flow <NUM>, the VBS <NUM> verifies the security quote signed by the TEE <NUM> that was received from the VBS agent. At message flow <NUM>, the VBS <NUM> performs a series of whitelist checks to verify that the VBS <NUM> is configured correctly. Accordingly, in some embodiments, the VBS <NUM> may perform the whitelist checks by verifying the provisioning parameters sent by the TEE <NUM> that were used to securely provision the VBS <NUM> (see message flow <NUM>). Additionally or alternatively, in some embodiments, the VBS <NUM> may perform the whitelist checks by verifying that the unique platform identifier received is valid with respect to a security policy (e.g., a secure boot policy, a TPM policy, a versioning policy, etc.) of the platform on which the TEE that provisioned the VBS <NUM> was instantiated. Additionally, in some embodiments, VBS <NUM> may perform the whitelist checks b checking the validity of additional policies, such as for license validity checks (e.g., based on the unique VNF instance identifier). Further, in some embodiments, the VBS <NUM> may additionally or alternatively verify whether the VBS agent is approved to communicate with the VBS <NUM> as part of the whitelist checks, such as by verifying that the VBS agent has been registered with the VBS <NUM>.

At message flow <NUM>, the VBS <NUM> verifies the security credential request by verifying the nonce session and the public key of the VNF instance received from the VBS agent. To do so, the VBS <NUM> performs a liveness check to detect any delayed or replay attacks using session nonces (i.e., the nonce generated by the VBS agent and the nonce generated by the VBS <NUM>). The session nonces can be random numbers used to detect attacks, the values of which are stored associated with the flow corresponding to the messages transmitted therebetween. Accordingly, the session nonces can be check for each flow to detect a liveness (i.e., that the session has not expired) of the communicated messages, as well as to distinguish between multiple flows that the VBS <NUM> may be executing.

At message flow <NUM>, the VBS <NUM> creates or retrieves a valid security credential (e.g., a security certificate, a signed hash result, etc.) upon verification of the security credential request. It should be appreciated that the message flows <NUM> through <NUM> may be performed in any order, however, in some embodiments, a local security policy may be used by the VBS <NUM> that provides a timeline for session expiration. Accordingly, the order of the performance of the message flows <NUM> through <NUM> may be based on the number of sessions currently active, or being buffered, by the VBS <NUM>, computing resources available to the VBS, session time expiration constraints, etc..

At message flow <NUM>, the VBS <NUM> securely transmits a registration response message to the VBS agent. The registration response message includes the nonce generated by the VBS agent, the nonce generated by the VBS <NUM>, a valid security credential, an identifier of the VNF manager <NUM> (e.g., an IP address, a DNS, a FQDN, a URL, etc.) responsible for managing the VBS agent, a set of whitelisted VNF managers, a set of authorized VNFCs (if applicable), the unique VNF instance identifier, and one or more policies. The one or more policies may include any type of policy that provides direction, or instruction, to the VBS agent on how to perform a particular service or function, such as a security monitoring policy, a networking policy, a network packet processing policy, etc. Additionally, the registration request message response is signed by the VBS using the private key of the VBS <NUM>. It should be appreciated that, in some embodiments, the registration response message may include additional and/or alternative parameters.

It should be appreciated that, in some embodiments, the security quote may be extensible, for instance to include additional and/or alternative information to support additional components of the platform on which the VNF instance is instantiated. For example, the additional information may include a platform capabilities mask, a platform NIC and/or switch mask, service function chaining (SFC) policies for a platform, a list of security credential identifiers, etc. Accordingly, unlike traditional operator cloud networks using static images in unsecure and non-scalable environments, the dynamic nature of the secure VNF bootstrap capture protocol may reduce the amount of, or need for, static configuration and security options, which may allow for more dynamic scaling out/in of virtualized operator cloud networks.

Referring now to <FIG>, in use, a trusted execution environment (e.g., the TEE <NUM> of <FIG>) may execute a method <NUM> for performing a TEE quoting operation for a VBS agent (e.g., the VBS agent <NUM>, the VBS agent <NUM>, or the VBS agent <NUM> of <FIG>). The method <NUM> begins at block <NUM>, in which the TEE applies a hash function to a set of launch parameters of the VBS agent to generate a hash result. The launch parameters may include any parameters that may be used to launch an instance of the VNF and/or the VBS agent. To do so, at block <NUM>, the TEE applies the hash function to an image of a VNF instance, a descriptor of the VNF instance, an identifier unique to the VNF instance (i.e., a unique VNF instance identifier), and/or an identifier that is unique to a platform (i.e., a unique platform identifier) on which the VNF instance is instantiated to generate a hash result. Accordingly, the TEE can apply the first hash function when it loads the VNF, since all of the VNF launch parameters are known by the TEE in order to launch the VNF. In other words, the TEE can apply the first hash function without receiving any inputs from the VBS agent.

At block <NUM>, the TEE applies a hash function to a set of VBS identifiers of the VBS <NUM> and one or more of the VBS agent launch parameters to generate a second hash result. The set of VBS identifiers may include any information that may be used to identify the VBS <NUM>, such as a public key of the VBS <NUM>, an IP address of the VBS <NUM>, a DNS of the VBS <NUM>, a FQDN of the VBS <NUM>, a URL of the VBS <NUM>, and/or the like. To do so, at block <NUM>, the TEE applies the hash function to the public key of the VBS <NUM>, the IP address of the VBS <NUM>, the unique VNF instance identifier, the unique platform identifier. In some embodiments, another hash function may be applied to the set of VBS identifiers of the VBS <NUM> prior to applying the hash function at block <NUM>. Additionally or alternatively, in some embodiments, the hash result of the hash function applied at block <NUM> may additionally be included as an input in the hash function applied at block <NUM>.

Claim 1:
A network functions virtualization, NFV, network system (<NUM>) for securely bootstrapping a virtual network function, VNF, the NFV network system comprising:
a hardware processor;
a VNF bootstrap service, VBS (<NUM>);
a VBS agent (<NUM>, <NUM>, <NUM>) associated with a VNF instance (<NUM>, <NUM>, <NUM>); and
wherein a hypervisor (<NUM>) is to:
(i) receive (<NUM>) a command to spin-up the VNF instance (<NUM>, <NUM>, <NUM>) based on a signed VNF image and a signed VNF descriptor, the command including a set of VBS startup parameters,
(ii) verify (<NUM>) an authenticity of the received command,
(iii) instantiate (<NUM>) the VNF instance (<NUM>, <NUM>, <NUM>) based on the set of VBS startup parameters, and
(iv) register (<NUM>) the instantiated VNF instance (<NUM>, <NUM>, <NUM>) with a Trusted Execution Environment, TEE (<NUM>), and
wherein the VBS agent (<NUM>, <NUM>, <NUM>) is initiated responsive to instantiation of the VNF instance (<NUM>, <NUM>, <NUM>), the VBS agent (<NUM>, <NUM>, <NUM>) to:
(i) generate (<NUM>) a public/private key pair for the VNF instance (<NUM>, <NUM>, <NUM>),
(ii) request (<NUM>) a security quote from the TEE (<NUM>) using the public key of the public/private key pair for the VNF instance (<NUM>, <NUM>, <NUM>), wherein the request is used to calculate a quote hash and sign the quote hash using a private key of the TEE (<NUM>),
(iii) execute (<NUM>), after having received the signed quote hash from the TEE (<NUM>), a VBS capture protocol with the VBS to enable secure communication of the VBS agent with the VBS, wherein the VBS capture protocol is to verify (<NUM>) the signed quote hash,
(iv) activate (<NUM>) the VNF instance (<NUM>, <NUM>, <NUM>), and
(v) transmit (<NUM>) an indication to a VNF manager (<NUM>) of the NFV network system (<NUM>) that indicates the VNF instance (<NUM>, <NUM>, <NUM>) has been activated.