WO2022266490A1 - Systems and methods for virtual network function platform security solutions - Google Patents

Abstract

Systems and methods for virtual network function platform security solutions are provided. In one embodiment, a VNF hosting platform for one or more virtualized entities of a wireless communications base station comprises: a processor coupled to a memory; a BIOS flash memory comprising a system BIOS; one or more field programmable fuses; a certificate store; and a trusted platform module chip. Upon a bootup the processor is configured to execute a plurality of security checking processes that include: a BIOS security startup, a booting security startup, an OS security startup to collect configuration registers virtualization environment operation measurements for one or more VNF supporting modules associated with virtualized entities of a wireless network base station, and an application security startup to execute a wireless base station startup gating application and invoke an operation measurement. The gating application unseals an application security key for executing wireless base station startup gated applications.

Description

SYSTEMS AND METHODS FOR VIRTUAL NETWORK FUNCTION PLATFORM

SECURITY SOLUTIONS

CROSS-REFERENCE TO RELATED APPLICATIONS [0001] This application claims the benefit of U.S. Provisional Application Serial No.

63/211,935, filed June 17, 2021, and titled “SYSTEMS AND METHODS FOR VIRTUAL NETWORK FUNCTION PLATFORM SECURITY SOLUTIONS,” which is hereby incorporated herein by reference.

BACKGROUND

[0002] Cloud-based virtualization of Fifth Generation (5G) base stations (also referred to as “g NodeBs” or “gNBs”) is widely promoted by standards organizations, wireless network operators, and wireless equipment vendors. Such an approach can help provide better high- availability and scalability solutions as well as addressing other issues in the network.

[0003] In general, a distributed 5G gNodeB can be partitioned into different entities, each of which can be implemented in different ways. For example, each entity can be implemented as a physical network function (PNF) or a virtual network function (VNF) and in different locations within an operator’s network (for example, in the operator’s “edge cloud” or “central cloud”). A distributed 5G gNodeB can be partitioned into one or more central units (CUs), one or more distributed units (DUs), and one or more radio units (RUs). Each CU can be further partitioned into a central unit control-plane (CU-CP) and one or more central unit user-plane (CU-UPs) dealing with the gNodeB Packet Data Convergence Protocol (PDCP) and above layers of functions of the respective planes, and each DU configured to implement the upper part of physical layer through radio link control (RLC) layer of both control -plane and user-plane of gNodeB. In this example, each RU 106 is configured to implement the radio frequency (RF) interface and lower physical layer control-plane and user-plane functions of the gNodeB. Each RU is typically implemented as a physical network function (PNF) and is deployed in a physical location where radio coverage is to be provided. Each DU is typically implemented as a virtual network function (VNF) and, as the name implies, is typically distributed and deployed in a distributed manner in the operator’s edge cloud. Each CU-CP and CU-UP are typically implemented as virtual network functions (VNFs) and, as the name implies, are typically centralized and deployed in the operator’s central cloud.

[0004] Orchestrating gNodeB virtualized network functions (VNFs) and configuring them into service ready network elements involves mainly three major stages: 1) virtualization infrastructure orchestration/management (referred as VIM in relevant industry standards) stage in which bare metal hardware elements are orchestrated by the infrastructure orchestration framework to build up the virtualization environment for the next stage of service orchestration; 2) virtual network functions (VNFs) service orchestration/management (referred as VNFM in relevant industry standards) stage in which gNodeB VNFs are orchestrated over the virtualization environment established in previous stage; 3) virtual network functions (VNFs) service configuration and activation stage in which the operator of gNodeBs configures and activates them via OAM to bring them into services. Cloudification and virtualization of network elements for a 5G gNodeB brings in a lot of benefits, but it also imposes more and more challenges to the security solutions that protect the VNF hosting platform from being compromised by unauthenticated booting modules and unauthorized applications.

SUMMARY

[0005] The Embodiments of the present disclosure provide methods and systems for a virtual network function platform security solution and will be understood by reading and studying the following specification.

[0006] In one embodiment, a Virtual Network Function (VNF) hosting platform for one or more virtualized entities of a wireless communications base station, the VNF hosting platform comprising: a processor coupled to a memory; a BIOS flash memory comprising a system BIOS; one or more field programmable fuses; a certificate store firmware; and a trusted platform module chip comprising a plurality of platform configuration registers; wherein, upon a bootup of the VNF hosting platform, the processor is configured to execute a plurality of security checking processes that include: a BIOS security startup configured to read the BIOS flash memory and validate an integrity of a key manifest (KM), a boot policy manifest (BPM) using the KM, and an initial boot block (IBB) using the BPM; a booting security startup that is executed only when the KM, BPM and IBB are validated by the BIOS security startup, wherein utilizing the IBB, the booting security startup invokes a plurality of operation measurements and saves measurement results into the plurality of platform configuration registers and validates option ROM, EFI binaries and EFI bootloaders based on the certificate store firmware; an OS security startup configured to collect, and store to the plurality of platform configuration registers, virtualization environment operation measurements for one or more VNF supporting modules associated with virtualized entities of a wireless network base station; and an application security startup configured to execute a wireless base station startup gating application and invoke an operation measurement, wherein the wireless base station startup gating application is configured to unseal an application security key for executing one or more wireless base station startup gated applications.

DRAWINGS

[0007] Embodiments of the present disclosure can be more easily understood and further advantages and uses thereof more readily apparent, when considered in view of the description of the preferred embodiments and the following figures in which:

[0008] Figures 1 and 1 A are block diagrams illustrating examples of a virtualized 5G gNodeB on a VNF hosting platform embodiment on which the platform security solutions described herein are provided.

[0009] Figure 2 is a block diagram illustrating an example VNF hosting platform embodiment.

[0010] Figures 3 and 3 A-3E provides an overview of system and example processes utilized in the preparation of an example VNF hosting platform embodiment.

[0011] Figure 4 is a block diagram illustrating an example VNF hosting platform embodiment configured with platform security mechanisms.

[0012] Figures 5 and 5A-5D provides an overview of system and example processes utilized in a platform security process that provides for secure loading and execution of gated applications that will load and configure the various VNFs of a gNodeB.

[0013] In accordance with common practice, the various described features are not drawn to scale but are drawn to emphasize features relevant to the present disclosure. Reference characters denote like elements throughout figures and text.

DETAILED DESCRIPTION

[0014] In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of specific illustrative embodiments in which the embodiments may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the embodiments, and it is to be understood that other embodiments may be utilized and that logical, mechanical and electrical changes may be made without departing from the scope of the present disclosure. The following detailed description is, therefore, not to be taken in a limiting sense.

[0015] Embodiments of the present disclosure can be divided into two distinct stages. A first stage involves the preparation of a bare metal computer server system with the foundation of security elements to support a platform security solution for executing virtual network functions for a gNodeB on a VNF hosting platform. As the term is used herein, a “bare metal” computer server system refers to a physical single tenant server. A second stage involves an execution of the platform security process that provides a trusted environment for the secure loading and execution of gated applications that will load and configure the various VNFs of the gNodeB. This disclosure presents solutions that aim to protect the VNF hosting platform from being compromised by unauthenticated booting modules all the way from system power-on through various Basic Input/Output System (BIOS), firmware, bootloaders and OS to proprietary applications. With this end-to-end protection, modules running on the hardware platform are authenticated, and proprietary applications are “locked down” to designated platforms with a trusted operation environment preventing them from running on unauthorized platforms and environments.

[0016] Figures 1 and 1 A are block diagrams illustrating examples of a virtualized wireless base station 100 on a VNF hosting platform on which the platform security solutions described herein are provided. In the context of a fourth generation (4G) Long Term Evolution (LTE) system, a base station 100 may also be referred to as an “evolved NodeB” or “eNodeB”, and in the context of a fifth generation (5G) New Radio (NR) system, may also be referred to as a “gNodeB.” Base station 100 may be referred to as something else in the context of other wireless interfaces.

[0017] In the particular examples shown in Figures 1 and 1 A, the virtualized wireless base station 100 comprises a 5G gNodeB 100 partitioned into one or more central units (CUs) 102, which include a central unit control -plane (CU-CP) 116 and one or more central unit user- planes (CU-UPs) 118. The gNodeB 100 is further partitioned into one or more distributed units (DUs) 104, which are composed of one or more DU virtual network functions 105, and one or more radio units (RUs) 106. In this example the virtualized 5G gNodeB 100 is configured so that each CU 102 is configured to serve one or more DU VNFs 105 and each DU VNF 105 is configured to serve one or more RUs 106. In the particular configuration shown in Figures 1 and 1 A, a single CU 102 serves a single DU VNF 105, and the DU VNF 105 serves three RUs 106. However, the particular configurations shown in Figures 1 and 1 A are only examples. In other embodiments, other numbers of CUs 102, DUs 104, and RUs 106 can be used. Also, the number of DUs 104 served by each CU 102 can vary from CU 102 to CU 102. Likewise, the number of RUs 106 served by each DU can vary from DU VNF 105 to DU VNF 105.

[0018] Moreover, although the following embodiments are primarily described as being implemented for use to provide 5GNR service, it is to be understood the techniques described here can be used with other wireless interfaces (for example, fourth generation (4G) Long-Term Evolution (LTE) service) and references to “gNodeB” used in this disclosure can be replaced with the more general term “base station” or “base station entity” and/or a term particular to the alternative wireless interfaces (for example, “enhanced NodeB” or “eNB”). Furthermore, it is also to be understood that 5G NR embodiments can be used in both standalone and non-standalone modes (or other modes developed in the future) and the following description is not intended to be limited to any particular mode. Also, unless explicitly indicated to the contrary, references to “layers” or a “layer” (for example, Layer 1, Layer 2, Layer 3, the Physical Layer, the MAC Layer, etc.) set forth herein refer to layers of the wireless interface (for example, 5G NR or 4G LTE) used for wireless communication between a base station and user equipment).

[0019] In general, the virtualized gNodeB 100 is configured to provide wireless service to various numbers of user equipment (UEs) 108 using one or more cells 110 (only one of which is shown in Figures 1 and 1A for ease of illustration). Each RU 106 includes or is coupled to a respective set of one or more antennas 112 via which downlink RF signals are radiated to UEs 108 and via which uplink RF signals transmitted by UEs 108 are received.

[0020] In one configuration (used, for example, in indoor deployments), each RU 106 is co located with its respective set of antennas 112 and is remotely located from the DU VNF 105 and CU 102 serving it as well as the other RUs 106. In another configuration (used, for example, in outdoor deployments), the respective sets of antennas 112 for multiple RUs 106 are deployed together in a sectorized configuration (for example, mounted at the top of a tower or mast), with each set of antennas 112 serving a different sector. In such a sectorized configuration, the RUs 106 need not be co-located with the respective sets of antennas 112 and, for example, can be co-located together (for example, at the base of the tower or mast structure) and, possibly, co-located with its serving DUs 104. Other configurations can be used. [0021] The virtualized gNodeB 100 is implemented using a scalable cloud environment 120 in which resources used to instantiate each type of entity can be scaled horizontally (that is, by increasing or decreasing the number of physical computers or other physical devices) and vertically (that is, by increasing or decreasing the “power” (for example, by increasing the amount of processing and/or memory resources) of a given physical computer or other physical device). The scalable cloud environment 120 can be implemented in various ways.

[0022] For example, the scalable cloud environment 120 can be implemented using hardware virtualization, operating system virtualization, and application virtualization (also referred to as containerization) as well as various combinations of two or more of the preceding. The scalable cloud environment 120 can be implemented in other ways. For example, as shown in Figures 1 and 1 A, the scalable cloud environment 120 is implemented in a distributed manner. That is, the scalable cloud environment 120 is implemented as a distributed scalable cloud environment 120 comprising at least one central cloud 114 and at least one edge cloud 115.

[0023] In the examples shown in Figures 1 and 1 A, each RU 106 is implemented as a physical network function (PNF) and is deployed in or near a physical location where radio coverage is to be provided. In this example, each DU 104 is implemented with one or more DU virtual network functions (VNFs) 105 and may be distributed and deployed in a distributed manner in the edge cloud 115. Each CU-CP 116 and CU-UP 118 is implemented as a virtual network function (VNF). The CU-CP 116 and CU-UP 118 may be centralized and deployed in the central cloud 114 as shown in Figure 1. Figure 1A illustrates an alternative implementation to Figure 1 where the CU-CP 116 and CU-UP 118 are instead deployed in the edge cloud 115. In the examples shown in these Figures 1 and 1 A, the CU 102 (including the CU-CP VNF 116 and CU-UP VNF 118) and the entities used to implement it are communicatively coupled to each DU VNF 105 served by the CU 102 (and the DU VNF(s) 105 used to implement each such DU 104). In some embodiments, the CU 102 and DU 104 are communicatively coupled over a midhaul network 128 (for example, a network that supports the Internet Protocol (IP)). In the examples shown in Figures 1 and 1 A, each of the DU VNF(s) 105 used to implement a DU 104 are communicatively coupled to each RU 106 served by the DU VNF 105 using a fronthaul network 125 (for example, a switched Ethernet network that supports the IP).

[0024] The scalable cloud environment 120 comprises one or more cloud worker nodes 122 that are configured to execute cloud native software 124 that, in turn, is configured to instantiate, delete, communicate with, and manage one or more virtualized entities 126 of a base station (for example, a CU-CP VNF 116, CU-UP VNF 118 and DU VNF 105 for a gNodeB). The cloud worker nodes 122 may comprise respective clusters of physical worker nodes (or virtualized worker nodes if implemented in combination with hardware virtualization), the cloud native software 124 may comprise a shared host operating system, and the virtualized entities 126 comprise containers. In another example, the cloud worker nodes 122 comprise respective clusters of physical worker nodes, the cloud native software 124 comprises a hypervisor (or similar software), and the virtualized entities 126 comprise virtual machines.

[0025] In the example shown in Figures 1 and 1 A, the scalable cloud environment 120 includes a cloud “master” node 130. There are certain responsibilities that the cloud “master” node 130 has as far as instantiation of cloud worker nodes 122 and clustering them together. The cloud master node 130 is configured to implement management and control plane processes for the worker nodes 122 in a cluster. In some examples, the cloud master node 130 is configured to determine what runs on each of the cloud worker nodes 122, which can include scheduling, resource allocation, state maintenance, and monitoring. In some examples, the cloud master node 130 is configured to manage the lifecycle, scaling, and upgrades of workloads (such as containerized applications) on the cloud worker nodes 122.

[0026] Each of the virtual network functions, DU VNF 105, CU-CP VNF 116, and CU-UP VNF 118 is implemented as a software virtualized entity 126 that is executed in the scalable cloud environment 120 on a cloud worker node 122 under the control of the cloud native software 124 executing on that cloud worker node 122. In the following description, a cloud worker node 122 that implements at least a part of a CU 102 (for example, a CU-CP VNF 116 and/or a CU-UP VNF 118) is also referred to here as a “CU cloud worker node” 122, and a cloud worker node 122 that implements at least a part of a DU VNF 105 is also referred to here as a “DU cloud worker node” 122.

[0027] In the example embodiment of a gNodeB 100 base station, the CU-CP VNF 116 and the CU-UP VNF 118 are each implemented as a respective virtualized entity 126 executing on the same cloud worker node 122. The DU VNF 105 may be implemented as a virtualized entity 126 executing on the same cloud worker node 122 or a different cloud worker node 122. In other configurations and examples, the CU 102 can be implemented using multiple CU-UP VNFs 118 using multiple virtualized entities 126 executing on one or more cloud worker nodes 122. In another example, multiple DU VNFs 105 (using multiple virtualized entities 126 executing on one or more cloud worker nodes 122) can be used to serve a cell, where each of the multiple DU VNFs 105 serves a different set of RUs 106. Moreover, it is to be understood that the CU 102 and DU VNF 105 can be implemented in the same cloud (for example, together in an edge cloud 115). Other configurations and examples can be implemented in other ways.

[0028] Bringing a virtualized gNodeB (such as virtualized gNodeB 100) up to service is generally performed in multiple stages by a variety of entities. The virtualization infrastructure/ environment required for gNodeB VNFs is brought up from a bare metal servers and relevant network and storage equipment (for example, using platform orchestration through an edge cloud node management network or controller). The gNodeB VNFs are then deployed and orchestrated into service providing entities (for example, using service orchestration through a virtual network function manager (VNFM)). The gNodeB VNFs are also configured and activated to make them service ready (for example, using service configuration with an Operations and Maintenance (OAM) entity or Device Management System (DMS)).

[0029] As discussed above, a first stage of the embodiments involves the preparation of a bare metal computer server system with the foundation of security elements to support a platform security solution for executing virtual network functions for a gNodeB on a VNF hosting platform. This stage of the embodiments is illustrated by example in the block diagrams of Figures 2 and 3, and the methods illustrated in Figures 3A-3E. Figure 2 illustrates a VNF hosting platform 205, which comprises hardware server equipment on which one or more of the CU-CP VNF 116, the CU-UP VNF 118, the DU VNF 105, and any supporting VNFs, are ultimately loaded and executed to realize the 5G gNodeB 100. The VNF hosting platform 205 comprises a processor 206 (i.e., a central processing unit (CPU)) and a memory 207, which together store and execute code to realize aspects of the gNodeB 100 in operation. Memory module 207 also stores Integrity Measurement Architecture (IMA) policies 213 (such as Linux Integrity Measurement Architecture (IMA) policies). VNF hosting platform 205 further includes a BIOS flash memory 208, a plurality of field programmable fuses 209, a certificate store firmware 210, and a trusted platform module (TPM) chip 211 that comprises a plurality of platform configuration registers (PCRs) 212. Also shown in Figure 2 are platform security mechanisms 220, which include BIOS security 222, booting security 224, operating system (OS) security 226, and application security 228. Each of the platform security mechanisms 220 are pre-programed into the target VNF hosting platform 205 as illustrated by Figures 3 and 3 A-3E, and discussed below.

[0030] Figure 3 provides an overview of the process and system elements utilized in the preparation of VNF hosting platform 205 from the point of initial fabrication to having installed thereon the foundation of security elements to support executing virtual network functions for the 5G gNodeB 100. The platform security mechanisms 220 described herein would typically be installed by the original equipment manufacturer (OEM) as a factory production procedure. However, these embodiments are not so limited and the platform security mechanisms 220 may instead be performed in some embodiments after the delivery of the VNF Hosting Platform 205 hardware to another party, such as a network operator.

[0031] Implementation of the platform security mechanisms 220 begins as shown in Figure 3 A where the BIOS security 222 is installed on the VNF hosting platform 205. The process begins at 302 where the system BIOS is created by writing the system BIOS into BIOS flash memory 208 and calculating an initial boot block (IBB) hash value for the system BIOS. At 304, a boot policy manifest (BPM) is built with a BPM signature and a signed section including the IBB base, an indication of the IBB size, the IBB hash value, and a public part of a BPM signing key. For example, the BPM signing key may be an OEM key. At 306, the BPM is signed using a private part of the BPM signing key and the signed BPM together with the signature are written into the BIOS flash memory 208.

[0032] The process next proceeds to 308 with building a key manifest (KM) that comprises a signed section that includes a key manifest identification (KM ID), a hash value of the public part of the BPM signing key, and a public part of a KM signing key. At 310, the KM is signed using a private part of the KM signing key and the signed KM together with the signature are written into the BIOS flash memory 208. At 312, the process proceeds to building one or more boot policies and setting the KM ID. Boot policies may be used, for example, to override a boot order specified in a BIOS setup menu and direct the selection of boot devices, the location from which the server hardware will boot, and/or the order in which boot devices are invoked. At 314, the one or more boot policies, the KM ID, and a hash value of a public part of the KM signing key, are burned into field programmable fuses 209. As the term is used here, a field programmable fuse is a field programmable register into which a valued may be written (“burned”) a single time, and from that point forward is a read-only register. From here, the execution of BIOS security 222 is complete and may be enabled at 316. In some embodiments, the installation of BIOS security 222 may be achieved at least in part by utilizing the Intel Boot Guard authenticated code module (ACM).

[0033] Implementation of booting security 224 onto the VNF hosting platform 205 begins as shown in Figures 3B and 3C. It should be understood that the order of signings and collection of boot phase measurement values shown in Figures 3B and 3C is given as a non-limiting example and that other order sequences can be performed to obtain the same affect.

[0034] The process begins at 320 with, using a key issued by a trusted certificate authority (CA), signing an option ROM (OROM) and drivers, and saving a public part of an OROM signing key into the certificate store firmware 210. The OROM may comprise a firmware element that resides in the system BIOS or other hardware component, and gets shadowed into memory 207 and executed by processor 206 to initialize a device and register it with the system BIOS.

[0035] In some embodiments, the trusted CA may comprise an OEM CA or a proprietary CA of the network operator for the gNodeB 100. In some embodiments, the certificate store firmware 210 may comprise a Unified Extensible Firmware Interface (UEFI) firmware with a certificate store. The certificate store firmware 210 may comprise a Platform Key (PK), a Key Exchange Key (KEK), a key (or signature) database (db) and a forbidden signatures database (dbx). The PK is stored as a PK variable and functions control access to the PK variable and the KEK variable. The KEK is stored in a KEK variable and is utilized to update the signature database (db) and the forbidden signatures database (dbx). The KEK may be used either to update the db or to sign binaries for valid execution. The db is stored in the DB variable and may be set to validate signed extensible firmware interface (EFI) binaries and other loadable modules (such a ROMs). The db variable may include a mixed set of keys, signatures or hashes. The dbx is stored in the DBX variable and may be utilized to explicitly invalidate EFI binaries and other loadable modules. The dbx variable may contain either keys, signatures or hashes.

[0036] The process proceeds to 322 with, using a key issued by the trusted CA, signing one or more EFI binaries, and saving a public part of an EFI binaries signing key into the certificate store firmware 210. The process proceeds to 324 with, using a key issued by the trusted CA, signing one or more EFI bootloaders, and saving a public part of an EFI bootloaders signing key into the certificate store firmware 210. The process proceeds to 326 with, using a key issued by the trusted CA, signing one or more operating system (OS) kernel modules, and saving a public part of an OS Kernel modules signing key into the certificate store firmware 210.

[0037] Implementation of booting security 224 then proceeds to Figure 3C to collect all good measurement values of the following boot phases. At 328 a security (SEC) boot phase measurement value is collected into one or more SEC boot phase data files, and the SEC boot phase data files, are sealed into the trusted platform module chip 211 using expected operation environment states capture in one or more PCRs 212 (such as PCR0) of the TPM chip 211 and the private part of a sealing security key. In a measured boot chain, prior to launching the next object, the currently-running object “measures” or computes a value for the hash of the next object(s) in the chain, and stores the hashes in a way that they can be securely retrieved later to find out what objects were encountered. PCRs 212 are registers in the trusted platform module chip 211 that are not directly written and can be cleared only at hardware reset. However, the values in PCRs 212 can be extended to hash a new value into whatever was previously in the PCR. Thus, as the platform boots, each boot phase measurement value can be accumulated in the PCRs 212 in a way that unambiguously demonstrates which modules were loaded.

[0038] At 330 the process includes collecting a Pre-EFI (PEI) boot phase measurement value into one or more PEI boot phase data files, and sealing the PEI boot phase data files into the trusted platform module chip 211 using expected operation environment states captured in one or more PCRs 212 (such as PCR0, 1 and 7) of the TPM chip 211 and the private part of a sealing security key. At 332 the process includes collecting a Drive execution environment (DXE) boot phase measurement value into one or more DXE boot phase data files, and sealing the DXE boot phase data files into the trusted platform module chip 211 using expected operation environment states captured in the one or more PCRs 212 (such as PCR 2 and 3) of the TPM chip 211 and the private part of a sealing security key. At 334 the process includes collecting a Boot device selector (BDS) boot phase measurement value into one or more BDS boot phase data files, and sealing the BDS boot phase data files into the trusted platform module chip 211 using expected operation environment states captured in the one or more PCRs 212 (such as PCR 4) of the TPM chip 211 and the private part of a sealing security key. At 336 the process includes collecting an EFI boot phase measurement value into one or more EFI boot phase data files, and sealing the EFI boot phase data files into the TPM chip 211 using expected operation environment states captured in the one or more PCRs 212 (such as PCR5) of the TPM chip 211 and the private part of a sealing security key. At 338 the process includes collecting an OS boot phase measurement value into one or more OS boot phase data files, and sealing the OS boot phase data files into the trusted platform module chip 211 using expected operation environment states captured into the one or more PCRs 212 (such as PCR8-15 and/or PCR 17-22) of the TPM chip 211 and the private part of a sealing security key. From here, the execution of booting security 224 is complete and may be enabled at 340.

[0039] Implementation of OS security 226 onto the VNF hosting platform 205 begins as shown in Figure 3D. In some embodiments, installing the OS security 226 may utilize the Linux Integrity Measurement Architecture (IMA). The process begins at 350 with, setting a first Integrity Measurement Architecture (IMA) policy specifying which of one or more Operating System (OS) kernel modules are to be measured during the OS booting operation. As shown in Figure 2, IMA policies 213 may be stored in memory 207. An IMA policy is responsible for specifying which OS kernel modules are to be measured during their operations. At 352, a second IMA policy is set specifying which of one or more VNF supporting framework modules are to be measured during their operations. The VNF supporting framework modules may include one or more of a gNodeB virtualization environment module (for example Kubermetes, Docker, or other virtualization environment modules), an edge cloud management module (for example, for a gNodeB edge cloud), and a wireless base station startup gating application module (for example, a gNodeB gating application module). The process proceeds to 354 with, collecting the OS and VNF supporting framework environment operation state measurement values into one or more data files, and sealing the data file into the TPM chip 211 using the expected operation environment states captured in one or more PCRs 212 (such as PCR 23) of the TPM chip 211 and the private part of a security key.

[0040] Implementation of application security 228 onto the VNF hosting platform 205 begins as shown in Figure 3E. At 360, an obfuscated gating application security key and certificate is sealed into the TPM chip 211 using the current healthy operation state measurement captured in one or more PCRs (e.g., the current set of PCR 212 values) and the private part of a security key. At 362, one or more gated wireless base station startup applications may optionally be prepared by either: encrypting the one or more gated wireless base station startup applications using a public part of the gating application security key, or by pre calculating one or more hash values of the gated wireless base station startup application and compiling the hash values into the wireless network base station startup gating application module. Alternatively, installation of gated wireless base station startup applications may be deferred and instead installed via run-time deployment though a secure access VNF orchestration service.

[0041] As discussed above, a second stage of the embodiments involves a secure execution process that provides for the secure loading and execution of gated applications that will load and configure the various VNFs of the gNodeB. One example of this embodiment is illustrated by example in the block diagrams of Figures 4 and 5, and the methods illustrated in Figures 5A-5D.

[0042] Figure 4 illustrates the VNF hosting platform 205 of Figure 2, now configured with the platform security mechanisms 220. At this stage, the VNF hosting platform 205 now further comprises one or more OS Kernels 430, VNF supporting modules 432, a wireless base station startup gating application module 434 and one or more wireless base station startup gated applications 436. In the case of a gNodeB 100, the wireless base station startup gating application module 434 comprises a gNodeB gating application module 434, and the one or more wireless base station startup gated applications 436 comprises gNodeB gated applications.

[0043] Following the installation onto the VNF hosting platform 205 of the foundation of security mechanisms 220, the VNF hosting platform 205 is powered up and put into operation where security checking processes 420 are executed that protect the VNF hosting platform 205 from power on until the trusted gNodeB gated applications 436 are run.

Security checking processes 420 include: BIOS security startup 422, booting security startup 424, OS security startup 426 and application security startup 428. In some embodiments, the OS and application security checking in processes 420 are each executed as described herein by the processor 206 upon power-up of the VNF hosting platform 205.

[0044] Figure 5 provides at 500 an overview of the security checking processes 420 and hardware elements from the bootup of VNF hosting platform 205 to the trusted gNodeB gated applications 436 that will install, orchestrate and execute one or more of the virtual network functions (i.e., the Virtualized Entities 126) of gNodeB 100.

[0045] The process for BIOS security startup 422 begins as shown in Figure 5A at 502 where on power up, the VNF hosting platform 205 (for example, processor 206) loads and executes a secured micro code that authenticates and runs a BIOS authenticated code module (ACM). At 504, the BIOS ACM reads the BIOS flash memory and validates the integrity of the KM, verifies the BPM using the verified KM, and verifies the IBB using the BPM. Should any of the KM, BPM or IBB fail validation, then startup of the VNF hosting platform 205 is halted (at 506). When the KM, BPM or IBB all pass validation, then the process proceeds to 508 with executing the IBB.

[0046] The process for IBB security startup 424 begins as shown in Figure 5B at 512 where the verified IBB executes a BIOS SEC phase operation. A BIOS SEC phase operation measurement is invoked and saved in a PCR 212 (such as PCR0) in the TPM chip 211. At 514, the process proceeds with executing a Pre-EFI (PEI) phase and initializing a secure boot, wherein an PEI operation measurement is invoked and saved in one or more PCR 212 (such as PCR0, 1, or 7) in the TPM chip 211. At 516, the DXE phase is executed wherein the secure boot validates the OROM and drivers against the db and the dbx databases of the certificate store firmware 210. Those with hashes or keys in the db database, but not in the dbx database, are authorized to run. A DXE boot phase measurement value is collected and saved into one or more PCR 212 (such as PCR 2 and 3) in the TPM chip 211. At 518, the BDS phase is executed wherein the secure boot validates EFI binaries against the db and the dbx databases of the certificate store firmware 210. Those with hashes or keys in the db database, but not in the dbx database, are authorized to run. An EFI binaries boot phase measurement value is collected and saved into one or more PCR 212 (such as PCR 4) in the TPM chip 211. At 520, the EFI bootloader phase is executed wherein the secure boot validates EFI bootloaders against the db and the dbx databases of the certificate store firmware 210. Those with hashes or keys in the db database, but not in the dbx database, are authorized to run. A EFI bootloader phase measurement value is collected and saved into one or more PCR 212 (such as PCR 5) in the TPM chip 211. At 522, the OS phase is executed wherein the secure boot validates the OS kernels 430 against the db and the dbx databases of the certificate store firmware 210. Those with hashes or keys in the db database, but not in the dbx database, are authorized to run. An OS phase measurement value is collected and saved into one or more PCR 212 (such as PCR 8-15) in the TPM chip 211.

[0047] The process for OS security startup 426 begins as shown in Figure 5C at 530 where IMA protection is invoked. Virtualization environment (such as Kubernetes, Docker, edge cloud management etc.) operation measurements for the VNF supporting modules 432 are invoked per an IMA policy specification and the measurement results are saved into one or more PCR 212 (such as PCR 17-22) in the TPM chip 211. [0048] The process for application security startup 428 begins as shown in Figure 5D at 542 where the wireless base station startup gating application 434 is executed and an operation measurement is invoked per an IMA policy specification and the measurement results are saved into one or more PCR 212 (such as PCR 17-23) in the TPM chip 211. At 544, the wireless base station startup gating application unseals the previously collected good measurement values of the system using the current system operation states captured in the current TPM 211 PCRs 212 and the public part of the sealing security key. The execution of one or more wireless base station startup gated applications is also gated by a comparison of the current system measurement values captured in the plurality of platform configuration registers with the expected measurement values unsealed from TPM 211. The current system states which are reflected in the current PCR values and the public part of the sealing security key. If system states do not match or the public part of the sealing security key is not right, unsealing will fail and the wireless base station startup gating application 434 will exit. At 546, the wireless base station startup gating application unseals the application security key and certificate using the current system operation states captured in the current TPM 211 PCRs 212 and the public part of the sealing security key. Here, the wireless base station startup gating application also unseals the various good measurement data files that are used for the attestation by comparing the sealed values with the current operation measurement values captured in the PCRs. If current system operation states do not match the ones used at the sealing time, unsealing will fail and the wireless base station startup gating application 434 will exit.

[0049] At 548, the wireless base station startup gating application 434 compares the unsealed good measurement values with the current measurements during the whole operation (as saved in the PCRs 212) via an attestation mechanism. The attestation mechanism may comprise either a local attestation mechanism or a remote attestation service. The wireless base station startup gating application 434 will exit if any mismatches are found.

[0050] At 550, the gNodeB gated applications 436 are started and run through the wireless base station startup gating application 434. This may be performed utilizing any one of the following mechanisms:

[0051] 1) An orchestration service may be accessed using an unsealed application security key, and the orchestration services permitted to deploy, manage and run the gNodeB gated network function applications 435. 2) The gNodeB gated network function applications 435 are decrypted using the private part of the gNodeB application security key (unsealed from the TPM chip 211) and then executed. 3) The hash values of the gated applications are calculated and compared with the values compiled into the wireless base station startup gating application 434 the time the platform security mechanisms 220 are being applied (for example, at the OEM). The gNodeB gated applications 436 are only permitted to run when the hash values match.

EXAMPLE EMBODIMENTS

[0052] Example 1 includes a Virtual Network Function (VNF) hosting platform for one or more virtualized entities of a wireless communications base station, the VNF hosting platform comprising: a processor coupled to a memory; a BIOS flash memory comprising a system BIOS; one or more field programmable fuses; a certificate store firmware; and a trusted platform module chip comprising a plurality of platform configuration registers; wherein, upon a bootup of the VNF hosting platform, the processor is configured to execute a plurality of security checking processes that include: a BIOS security startup configured to read the BIOS flash memory and validate an integrity of a key manifest (KM), a boot policy manifest (BPM) using the KM, and an initial boot block (IBB) using the BPM; a booting security startup that is executed only when the KM, BPM and IBB are validated by the BIOS security startup, wherein utilizing the IBB, the booting security startup invokes a plurality of operation measurements and saves measurement results into the plurality of platform configuration registers and validates option ROM, EFI binaries and EFI bootloaders based on the certificate store firmware; an OS security startup configured to collect, and store to the plurality of platform configuration registers, virtualization environment operation measurements for one or more VNF supporting modules associated with virtualized entities of a wireless network base station; and an application security startup configured to execute a wireless base station startup gating application and invoke an operation measurement, wherein the wireless base station startup gating application is configured to unseal an application security key for executing one or more wireless base station startup gated applications.

[0053] Example 2 includes the VNF hosting platform of Example 1, wherein the BPM comprises a BPM signature and a signed section including an IBB base, an initial boot block (IBB) hash value, an indication of a size of the IBB, and a public part of a BPM signing key. [0054] Example 3 includes the VNF hosting platform of Example 2, wherein the KM comprises a signed section that includes a key manifest identification (KM ID), a hash value of the public part of the BPM signing key, and a public part of a KM signing key.

[0055] Example 4 includes the VNF hosting platform of Example 3, wherein a hash value of the public part of the KM signing key is burned into the one or more field programmable fuses.

[0056] Example 5 includes the VNF hosting platform of any of Examples 1-4, wherein the booting security startup is configured to execute: a BIOS security phase operation wherein an BIOS security phase operation measurement is invoked and saved in the plurality of platform configuration registers; a Pre-EFI (PEI) phase that initializes a secure boot, wherein a PEI boot phase operation measurement is invoked and saved in the plurality of platform configuration registers; a drive execution environment (DXE) phase wherein the secure boot validates option ROM and drivers against databases of the certificate store firmware, and wherein a DXE boot phase operation measurement is invoked and saved in the plurality of platform configuration registers; a boot device selector (BDS) phase wherein the secure boot validates Extensible Firmware Interface (EFI) binaries against databases of the certificate store firmware, and wherein a EFI binaries boot phase operation measurement is invoked and saved in the plurality of platform configuration registers; an EFI bootloader phase wherein the secure boot validates EFI bootloader against databases of the certificate store firmware, and wherein a EFI bootloader phase operation measurement is invoked and saved in the plurality of platform configuration registers; and an operating system OS phase wherein the secure boot validates one or more OS kernels against databases of the certificate store firmware, and wherein a OS phase operation measurement is invoked and saved in the plurality of platform configuration registers.

[0057] Example 6 includes the VNF hosting platform of any of Examples 1-5, wherein the one or more VNF supporting modules comprise at least one of: a gNodeB virtualization environment module; a gNodeB edge cloud cluster management module; and a gNodeB gating application module.

[0058] Example 7 includes the VNF hosting platform of any of Examples 1-6, wherein execution of one or more wireless base station startup gated applications is also gated by a comparison of current system measurement values captured in the plurality of platform configuration registers with expected measurement values unsealed from the trusted platform module chip, wherein the comparison of measurement values is performed by an attestation mechanism.

[0059] Example 8 includes the VNF hosting platform of Example 7, wherein the attestation mechanism is either a local attestation mechanism of the VNF hosting platform, or a remote attestation service accessed by the VNF hosting platform.

[0060] Example 9 includes the VNF hosting platform of any of Examples 1-8, wherein gNodeB gated applications are started and run through a gNodeB gating application.

[0061] Example 10 includes a virtualized wireless network base station comprising at least one VNF hosting platform of any of Examples 1-9, the virtualized wireless network base station comprising: one or more virtualized entities implemented on a cloud worker node.

[0062] Example 11 includes the virtualized wireless network base station of Example 10, wherein the one or more virtualized entities comprise at least one of a central unit control- plane (CU-CP) VNF, a central unit user-plane (CU-CP) VNF, and at least one distributed unit (DU) VNF.

[0063] Example 12 includes the virtualized wireless network base station of Example 11, further comprising one or more radio units (RUs) coupled to the at least one DU VNF, the one or more RUs configured to implement a radio frequency (RF) interface and deployed in a physical location where radio coverage is to be provided.

[0064] Example 13 includes the virtualized wireless network base station of any of Examples 10-12, wherein the one or more virtualized entities are implemented on a cloud worker node of a central cloud or a cloud worker node of an edge cloud.

[0065] Example 14 includes the virtualized wireless network base station of any of Examples 10-13, wherein the wireless base station startup gating application is further configured to unseal one or more good measurement data files and utilize them for attestation by comparing unsealed good measurement values with current operation measurement values captured in the plurality of platform configuration registers.

[0066] Example 15 includes a process for securing a Virtual Network Function (VNF) hosting platform for implementing one or more virtualized entities of a wireless communications base station, the process comprising: applying a plurality of platform security mechanisms to a computer server system, that includes: a processor coupled to a memory; a BIOS flash memory comprising a system BIOS; one or more field programmable fuses; a certificate store firmware; and a trusted platform module chip comprising a plurality of platform configuration registers; the plurality of platform security mechanisms including: a BIOS security mechanism configured to write to the BIOS flash memory a key manifest (KM), a boot policy manifest (BPM), and an initial boot block (IBB), and calculate an initial boot block (IBB) hash value for a system BIOS, a booting security mechanism, configured to utilize a certificate authority (CA) to sign one or more of option ROM and drivers, EFI binaries, EFI bootloaders and operating system (OS) kernels and save corresponding signing keys in the certificate store firmware; wherein the booting security mechanism is further configured to collect a plurality of boot phase measurement values into the plurality of platform configuration registers; an OS security mechanism configured to set one or more integrity measurement architecture policies for virtualization environment operation measurements for one or more VNF supporting modules associated with virtualized entities of a wireless network base station, and operation measurements for one or more OS kernels; and an application security mechanism configured to unseal a wireless base station startup gating application security key and certificate for a wireless network base station startup gated application to the trusted platform module chip using a current healthy operation state measurement captured in one or more of the plurality of platform configuration registers and a private part of a security key.

[0067] Example 16 includes the process of Example 15, wherein the application security mechanism is further configured to prepare one or more gated gNodeB startup applications by: encrypting the one or more gated gNodeB startup applications using a public part of the wireless base station startup gating application security key, or

[0068] pre-calculating one or more hash values of the one or more gated gNodeB startup applications and compiling the one or more hash values into the wireless network base station startup gated application.

[0069] Example 17 includes the process of any of Examples 15-16, wherein the BPM comprises a signed section including the IBB, the IBB hash value for the system BIOS, an indication of a size of the IBB, and a public part of a BPM signing key.

[0070] Example 18 includes the process of Example 17, wherein the KM comprises a signed section that includes a KM identification (ID), a hash value of the public part of the BPM signing key, and a public part of a KM signing key. [0071] Example 19 includes the process of Example 18, wherein a hash value of the public part of the KM signing key is burned into the one or more field programmable fuses.

[0072] Example 20 includes the process of any of Examples 15-19, wherein the one or more virtualized entities comprise at least one of a central unit control-plane (CU-CP) VNF, a central unit user-plane (CU-CP) VNF, and at least one distributed unit (DU) VNF.

[0073] Example 21 includes the process of any of Examples 15-20, wherein the computer server system comprises a bare metal computer server system.

[0074] Example 22 includes the process of any of Examples 15-21, wherein the BIOS security mechanism comprises: building the system BIOS, writing the system BIOS into the BIOS flash memory and calculating the IBB hash value; building the BPM with a signed section including the IBB, an IBB hash value for the system BIOS, an indication of a size of the IBB, and a public part of a BPM signing key; signing the BPM using a private part of the BPM signing key and writing the signed BPM into the BIOS flash memory; building the KM with a signed section that includes a KM identification (ID), a hash value of the public part of BPM signing key, and a public part of a KM signing key; signing the KM using a private part of the KM signing key and writing the signed KM into the BIOS flash memory; building one or more boot policies and setting the KM ID; burning the one or more boot policies, the KM ID, and a hash value of a public part of the KM signing key into field programmable fuses; and enabling BIOS security.

[0075] Example 23 includes the process of any of Examples 15-22, wherein the Booting security mechanism comprises one or more of: using a key issued by a trusted CA, signing an option ROM (OROM) and drivers, and saving a public part of an OROM signing key into a certificate store firmware; using a key issued by the trusted CA, signing one or more EFI binaries, and saving a public part of an EFI binaries signing key into the certificate store firmware; using a key issued by the trusted CA, signing one or more EFI bootloaders, and saving a public part of an EFI bootloaders signing key into the certificate store firmware; and using a key issued by the trusted CA, signing one or more operating system (OS) kernels, and saving a public part of an OS Kernel signing key into the certificate store firmware.

[0076] Example 24 includes the process of Example 23, wherein the Booting security mechanism further comprises one or more of: collecting a security (SEC) boot phase measurement value into one or more SEC boot phase data files, and sealing the one or more SEC boot phase data files into the trusted platform module chip using expected operation environment states captured in the plurality of platform configuration registers and the private part of a sealing security key; collecting a Pre-EFI (PEI) boot phase measurement value into one or more PEI boot phase data files, and sealing the one or more PEI boot phase data files into the trusted platform module chip using expected operation environment states captured in the plurality of platform configuration registers and the private part of a sealing security key; collecting a Drive execution environment (DXE) boot phase measurement value into one or more DXE boot phase data files, and sealing the one or more DXE boot phase data files into the trusted platform module chip using expected operation environment states captured in the plurality of platform configuration registers and the private part of a sealing security key; collecting a Boot device selector (BDS) boot phase measurement value into one or more BDS boot phase data files, and sealing the one or more BDS boot phase data files into the trusted platform module chip using expected operation environment states captured in the plurality of platform configuration registers and the private part of a sealing security key; collecting an EFI boot phase measurement value into one or more EFI boot phase data files, and sealing the one or more EFI boot phase data files into the trusted platform module chip using expected operation environment states captured in the plurality of platform configuration registers and the private part of a sealing security key; collecting an OS boot phase measurement value into one or more OS boot phase data files, and sealing the one or more OS boot phase data files into the trusted platform module chip using expected operation environment states captured in the plurality of platform configuration registers and the private part of a sealing security key; and enabling the booting security.

[0077] Example 25 includes the process of any of Examples 15-24, wherein the OS security mechanism comprises one or more of: setting a first Integrity Measurement Architecture (IMA) policy specifying which of one or more OS kernel modules are to be measured during an OS booting operation; setting a second IMA policy specifying which of one or more VNF supporting framework modules are to be measured during VNF platform operation, the VNF supporting framework module including one or more of a gNodeB virtualization environment module, a gNodeB edge could management module, and a gNodeB gating application module; and collecting the OS and VNF supporting framework environment operation state measurement values into one or more DXE boot phase data files, and sealing the one or more DXE boot phase data files into the trusted platform module chip using expected environment operation state measurement values captured in the plurality of platform configuration registers and the private part of a security key. [0078] In various alternative embodiments, system and/or device elements, method steps, or example implementations described throughout this disclosure (such as any of the Central Cloud. Edge Cloud, Cloud Master Node, Cloud Worker Node, virtual network function, central unit control-plane (CU-CP) VNF, central unit user-plane (CU-CP) VNF, and distributed unit (DU) VNF, radio units, VNF hosting platform, processor, memory, flash memory, field programmable fuses, certificate store firmware, trusted platform module chip, or sub-parts thereof, for example) may be implemented at least in part using one or more computer systems, field programmable gate arrays (FPGAs), or similar devices comprising a processor coupled to a memory and executing code to realize those elements, processes, or examples, said code stored on a non-transient hardware data storage device. Therefore, other embodiments of the present disclosure may include elements comprising program instructions resident on computer readable media which when implemented by such computer systems, enable them to implement the embodiments described herein. As used herein, the term “computer readable media” refers to tangible memory storage devices having non-transient physical forms. Such non-transient physical forms may include computer memory devices, such as but not limited to punch cards, magnetic disk or tape, any optical data storage system, flash read only memory (ROM), non-volatile ROM, programmable ROM (PROM), erasable-programmable ROM (E-PROM), random access memory (RAM), or any other form of permanent, semi-permanent, or temporary memory storage system or device having a physical, tangible form. Program instructions include, but are not limited to computer-executable instructions executed by computer system processors and hardware description languages such as Very High Speed Integrated Circuit (VHSIC) Hardware Description Language (VHDL).

[0079] As used herein, cloud-based virtualized wireless base station related terms such as Central Cloud. Edge Cloud, Cloud Master Node, Cloud Worker Node, virtual network function, central unit control-plane (CU-CP) VNF, central unit user-plane (CU-CP) VNF, and distributed unit (DU) VNF, radio units, VNF hosting platform, processor, memory, flash memory, field programmable fuses, certificate store firmware, trusted platform module chip, or sub-parts thereof, refer to non-generic elements as would recognized and understood by those of skill in the art of telecommunications and networks and are not used herein as nonce words or nonce terms for the purpose of invoking 35 USC 112(f).

[0080] Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that any arrangement, which is calculated to achieve the same purpose, may be substituted for the specific embodiment shown. This application is intended to cover any adaptations or variations of the presented embodiments. Therefore, it is manifestly intended that embodiments be limited only by the claims and the equivalents thereof.

Claims

CLAIMS What is claimed is:

1. A Virtual Network Function (VNF) hosting platform for one or more virtualized entities of a wireless communications base station, the VNF hosting platform comprising: a processor coupled to a memory; a BIOS flash memory comprising a system BIOS; one or more field programmable fuses; a certificate store firmware; and a trusted platform module chip comprising a plurality of platform configuration registers; wherein, upon a bootup of the VNF hosting platform, the processor is configured to execute a plurality of security checking processes that include: a BIOS security startup configured to read the BIOS flash memory and validate an integrity of a key manifest (KM), a boot policy manifest (BPM) using the KM, and an initial boot block (IBB) using the BPM; a booting security startup that is executed only when the KM, BPM and IBB are validated by the BIOS security startup, wherein utilizing the IBB, the booting security startup invokes a plurality of operation measurements and saves measurement results into the plurality of platform configuration registers and validates option ROM, EFI binaries and EFI bootloaders based on the certificate store firmware; an OS security startup configured to collect, and store to the plurality of platform configuration registers, virtualization environment operation measurements for one or more VNF supporting modules associated with virtualized entities of a wireless network base station; and an application security startup configured to execute a wireless base station startup gating application and invoke an operation measurement, wherein the wireless base station startup gating application is configured to unseal an application security key for executing one or more wireless base station startup gated applications.

2. The VNF hosting platform of claim 1, wherein the BPM comprises a BPM signature and a signed section including an IBB base, an initial boot block (IBB) hash value, an indication of a size of the IBB, and a public part of a BPM signing key.

3. The VNF hosting platform of claim 2, wherein the KM comprises a signed section that includes a key manifest identification (KM ID), a hash value of the public part of the BPM signing key, and a public part of a KM signing key.

4. The VNF hosting platform of claim 3, wherein a hash value of the public part of the KM signing key is burned into the one or more field programmable fuses.

5. The VNF hosting platform of claim 1, wherein the booting security startup is configured to execute: a BIOS security phase operation wherein an BIOS security phase operation measurement is invoked and saved in the plurality of platform configuration registers; a Pre-EFI (PEI) phase that initializes a secure boot, wherein a PEI boot phase operation measurement is invoked and saved in the plurality of platform configuration registers; a drive execution environment (DXE) phase wherein the secure boot validates option ROM and drivers against databases of the certificate store firmware, and wherein a DXE boot phase operation measurement is invoked and saved in the plurality of platform configuration registers; a boot device selector (BDS) phase wherein the secure boot validates Extensible Firmware Interface (EFI) binaries against databases of the certificate store firmware, and wherein a EFI binaries boot phase operation measurement is invoked and saved in the plurality of platform configuration registers; an EFI bootloader phase wherein the secure boot validates EFI bootloader against databases of the certificate store firmware, and wherein a EFI bootloader phase operation measurement is invoked and saved in the plurality of platform configuration registers; and an operating system OS phase wherein the secure boot validates one or more OS kernels against databases of the certificate store firmware, and wherein a OS phase operation measurement is invoked and saved in the plurality of platform configuration registers.

6. The VNF hosting platform of claim 1, wherein the one or more VNF supporting modules comprise at least one of: a gNodeB virtualization environment module; a gNodeB edge cloud cluster management module; and a gNodeB gating application module.

7. The VNF hosting platform of claim 1, wherein execution of one or more wireless base station startup gated applications is also gated by a comparison of current system measurement values captured in the plurality of platform configuration registers with expected measurement values unsealed from the trusted platform module chip, wherein the comparison of measurement values is performed by an attestation mechanism.

8. The VNF hosting platform of claim 7, wherein the attestation mechanism is either a local attestation mechanism of the VNF hosting platform, or a remote attestation service accessed by the VNF hosting platform.

9. The VNF hosting platform of claim 1, wherein gNodeB gated applications are started and run through a gNodeB gating application.

10. A virtualized wireless network base station comprising at least one VNF hosting platform of any of claims 1-9, the virtualized wireless network base station comprising: one or more virtualized entities implemented on a cloud worker node.

11. The virtualized wireless network base station of claim 10, wherein the one or more virtualized entities comprise at least one of a central unit control-plane (CU-CP) VNF, a central unit user-plane (CU-CP) VNF, and at least one distributed unit (DU) VNF.

12. The virtualized wireless network base station of claim 11, further comprising one or more radio units (RUs) coupled to the at least one DU VNF, the one or more RUs configured to implement a radio frequency (RF) interface and deployed in a physical location where radio coverage is to be provided.

13. The virtualized wireless network base station of claim 10, wherein the one or more virtualized entities are implemented on a cloud worker node of a central cloud or a cloud worker node of an edge cloud.

14. The virtualized wireless network base station of claim 10, wherein the wireless base station startup gating application is further configured to unseal one or more good measurement data files and utilize them for attestation by comparing unsealed good measurement values with current operation measurement values captured in the plurality of platform configuration registers.

15. A process for securing a Virtual Network Function (VNF) hosting platform for implementing one or more virtualized entities of a wireless communications base station, the process comprising: applying a plurality of platform security mechanisms to a computer server system, that includes: a processor coupled to a memory; a BIOS flash memory comprising a system BIOS; one or more field programmable fuses; a certificate store firmware; and a trusted platform module chip comprising a plurality of platform configuration registers; the plurality of platform security mechanisms including: a BIOS security mechanism configured to write to the BIOS flash memory a key manifest (KM), a boot policy manifest (BPM), and an initial boot block (IBB), and calculate an initial boot block (IBB) hash value for a system BIOS, a booting security mechanism, configured to utilize a certificate authority (CA) to sign one or more of option ROM and drivers, EFI binaries, EFI bootloaders and operating system (OS) kernels and save corresponding signing keys in the certificate store firmware; wherein the booting security mechanism is further configured to collect a plurality of boot phase measurement values into the plurality of platform configuration registers; an OS security mechanism configured to set one or more integrity measurement architecture policies for virtualization environment operation measurements for one or more VNF supporting modules associated with virtualized entities of a wireless network base station, and operation measurements for one or more OS kernels; and an application security mechanism configured to unseal a wireless base station startup gating application security key and certificate for a wireless network base station startup gated application to the trusted platform module chip using a current healthy operation state measurement captured in one or more of the plurality of platform configuration registers and a private part of a security key.

16. The process of claim 15, wherein the application security mechanism is further configured to prepare one or more gated gNodeB startup applications by: encrypting the one or more gated gNodeB startup applications using a public part of the wireless base station startup gating application security key, or pre-calculating one or more hash values of the one or more gated gNodeB startup applications and compiling the one or more hash values into the wireless network base station startup gated application.

17. The process of claim 15, wherein the BPM comprises a signed section including the IBB, the IBB hash value for the system BIOS, an indication of a size of the IBB, and a public part of a BPM signing key.

18. The process of claim 17, wherein the KM comprises a signed section that includes a KM identification (ID), a hash value of the public part of the BPM signing key, and a public part of a KM signing key.

19. The process of claim 18, wherein a hash value of the public part of the KM signing key is burned into the one or more field programmable fuses.

20. The process of claim 15, wherein the one or more virtualized entities comprise at least one of a central unit control-plane (CU-CP) VNF, a central unit user-plane (CU-CP) VNF, and at least one distributed unit (DU) VNF.

21. The process of claim 15, wherein the computer server system comprises a bare metal computer server system.

22. The process of claim 15, wherein the BIOS security mechanism comprises: building the system BIOS, writing the system BIOS into the BIOS flash memory and calculating the IBB hash value; building the BPM with a signed section including the IBB, an IBB hash value for the system BIOS, an indication of a size of the IBB, and a public part of a BPM signing key; signing the BPM using a private part of the BPM signing key and writing the signed BPM into the BIOS flash memory; building the KM with a signed section that includes a KM identification (ID), a hash value of the public part of BPM signing key, and a public part of a KM signing key; signing the KM using a private part of the KM signing key and writing the signed KM into the BIOS flash memory; building one or more boot policies and setting the KM ID; burning the one or more boot policies, the KM ID, and a hash value of a public part of the KM signing key into field programmable fuses; and enabling BIOS security.

23. The process of claim 15, wherein the Booting security mechanism comprises one or more of: using a key issued by a trusted CA, signing an option ROM (OROM) and drivers, and saving a public part of an OROM signing key into a certificate store firmware; using a key issued by the trusted CA, signing one or more EFI binaries, and saving a public part of an EFI binaries signing key into the certificate store firmware; using a key issued by the trusted CA, signing one or more EFI bootloaders, and saving a public part of an EFI bootloaders signing key into the certificate store firmware; and using a key issued by the trusted CA, signing one or more operating system (OS) kernels, and saving a public part of an OS Kernel signing key into the certificate store firmware.

24. The process of claim 23, wherein the Booting security mechanism further comprises one or more of: collecting a security (SEC) boot phase measurement value into one or more SEC boot phase data files, and sealing the one or more SEC boot phase data files into the trusted platform module chip using expected operation environment states captured in the plurality of platform configuration registers and the private part of a sealing security key; collecting a Pre-EFI (PEI) boot phase measurement value into one or more PEI boot phase data files, and sealing the one or more PEI boot phase data files into the trusted platform module chip using expected operation environment states captured in the plurality of platform configuration registers and the private part of a sealing security key; collecting a Drive execution environment (DXE) boot phase measurement value into one or more DXE boot phase data files, and sealing the one or more DXE boot phase data files into the trusted platform module chip using expected operation environment states captured in the plurality of platform configuration registers and the private part of a sealing security key; collecting a Boot device selector (BDS) boot phase measurement value into one or more BDS boot phase data files, and sealing the one or more BDS boot phase data files into the trusted platform module chip using expected operation environment states captured in the plurality of platform configuration registers and the private part of a sealing security key; collecting an EFI boot phase measurement value into one or more EFI boot phase data files, and sealing the one or more EFI boot phase data files into the trusted platform module chip using expected operation environment states captured in the plurality of platform configuration registers and the private part of a sealing security key; collecting an OS boot phase measurement value into one or more OS boot phase data files, and sealing the one or more OS boot phase data files into the trusted platform module chip using expected operation environment states captured in the plurality of platform configuration registers and the private part of a sealing security key; and enabling the booting security.

25. The process of claim 15, wherein the OS security mechanism comprises one or more of: setting a first Integrity Measurement Architecture (IMA) policy specifying which of one or more OS kernel modules are to be measured during an OS booting operation; setting a second IMA policy specifying which of one or more VNF supporting framework modules are to be measured during VNF platform operation, the VNF supporting framework module including one or more of a gNodeB virtualization environment module, a gNodeB edge could management module, and a gNodeB gating application module; and collecting the OS and VNF supporting framework environment operation state measurement values into one or more DXE boot phase data files, and sealing the one or more DXE boot phase data files into the trusted platform module chip using expected environment operation state measurement values captured in the plurality of platform configuration registers and the private part of a security key.