Provider proxy for controlling network slice access by user equipment

Systems and methods described herein enforce access controls for network slices via proxy in a secure enclave of a user equipment (UE) device. A UE device executes, in a rich execution environment (REE), a function or application designated for using one or more secure network slices of a telecommunications network. The UE device executes, in a trusted execution environment (TEE), a slice admission control proxy (SACP) to perform admission control for the one or more secure network slices, and forces network traffic for the function or application through the SACP.

BACKGROUND

Advanced mobile networks (i.e., Fifth Generation (5G) and Sixth Generation (6G) networks) are being implemented as the next stage networks in the evolution of mobile wireless networks. These networks incorporate many new advances in technology. For example, these networks will have the capability to perform network slicing to increase network efficiency and performance. Network slicing is a form of virtual network architecture that enables multiple logical networks to be implemented on top of a common shared physical infrastructure using software defined networking (SDN) and/or network function virtualization (NFV). Each logical network, referred to as a “network slice,” may encompass an end-to-end virtual network with dedicated storage and/or computation resources and may be configured to implement a different set of requirements. Providers of networks may implement network slices with value added network features including differentiated routing of traffic onto one of many slices from user equipment to user equipment.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Due to network slicing technology and increasing bandwidth capability of advanced mobile networks, mobile network operators may soon be managing hundreds or thousands of network slices. Each network slice can have its own architecture, management, and security requirements to support a specific use case. Therefore, controlled access for at least some of these network slices will become a critical aspect. Furthermore, future networks may seek capabilities of a zero-trust slice, implying strong send-side policy enforcement to keep unauthorized traffic off the zero-trust slice. As used herein, a network slice that requires controlled access may be referred to as a “secure network slice.”

Systems and methods described herein may apply slice access controls via a programmable software agent that is deployed on user equipment (UE) devices within a mobile network operator's (MNO's) telecommunications network to manage end-to-end services. The programmable software agent may effectively move the subscriber/provider demarcation from a provider's network edge (e.g., a Radio Access Network (RAN) edge) to the subscriber-provided UE device. According to implementations described herein, software defined packet processing features for a MNO may be extended to execute on a UE device owned and operated by a mobile network subscriber.

FIG.1is a diagram of an example environment100in which the systems and/or methods described herein may be implemented. As shown inFIG.1, environment100may include a UE device110, a RAN120including access devices125, a core network130with core devices135, a data network140with application functions145, a proxy image manager150, and an application provider network160. According to other embodiments, environment100may include additional networks, fewer networks, and/or different types of networks than those illustrated and described herein.

Environment100includes links between the networks and between the devices. Environment100may be implemented to include wired, optical, and/or wireless links among the devices and the networks illustrated. A communication connection via a link may be direct or indirect. For example, an indirect communication connection may involve an intermediary device and/or an intermediary network not illustrated inFIG.1. Additionally, the number and the arrangement of links illustrated in environment100are exemplary.

UE device110may include a device with long-range (e.g., cellular or mobile wireless network) wireless communication functionality. UE device110may include, for example, a cellular radiotelephone, a smart phone, a tablet, any type of internet protocol (IP) communications device, a Voice over Internet Protocol (VoIP) device, a laptop computer, a wearable computer, a gaming device, a media player device, or another device that includes cellular communication capabilities. In other implementations, UE device110may be implemented as a machine-type communications (MTC) device, an Internet of Things (IoT) device, a machine-to-machine (M2M) device, etc. According to implementations described herein, UE device110may be provisioned (e.g., via a subscriber identity module (SIM) card or another secure enclave) to recognize particular network identifiers (e.g., associated with RAN120) and to support particular RF spectrum ranges.

UE device110may include one or more applications (e.g., client applications117) or functions that are associated with Subscribed-Network Slice Selection Assistance Information (S-NSSAI). The S-NSSAI may indicate, for example, a particular network slice that is optimally configured for a type of traffic required by an application/function executed on UE device110(e.g., traffic such as massive IoT data, video streaming, designated emergency data, etc.). When a UE device attaches to RAN120to receive the service on the network slice, the UE device110typically provides the S-NSSAI to the access device125.

According to implementations described herein, UE device110may be configured with a Slice Admission Control Proxy (SACP)115to perform admission control for secure network slices based on policies applied to strongly authenticated traffic flows. In one aspect, SACP115may be implemented via a sidecar injected into a confidential computing enclave of UE device110. As used herein, the term “sidecar” may refer to a utility container or code in a device that adds functionality to support the device. For example, a sidecar may be a software module that provides UE device110with a specific functionality for policy-based slice admission control. As described further herein, SACP115may be positioned as a “bump-in-the-wire” (e.g., requiring no additional network addressing or routing configuring) in network environment100, located between applications executed on UE device110(e.g., client application117) and RAN120.

In an exemplary implementation, as shown inFIG.1, SACP115may demarcate the boundary between the service provider's administrative domain or network and the subscriber or customer. In such an implementation, SACP115may mark the handoff point from the service provider to the customer and vice versa. SACP115may be provided for each subscriber UE device110in a MNO's network to provide a distributed service platform that allows for diverse quality-of-service (QoS), security, routing, and additional features. SACP115thus may allow policy enforcement at the device level to enable providers to provide end-to-end security (including isolation, segmentation) for traffic entering and exiting a modem of UE device110.

RAN120may include one or multiple networks of one or multiple types and technologies that support network slicing. For example, RAN120may be implemented to include a 5G New Radio (NR) RAN or a future generation RAN (e.g., a 6G-RAN or subsequent generation RAN). RAN120may also include a legacy RAN (e.g., a Third Generation (3G) RAN, a 4G or 4.5 RAN, etc.). RAN120may communicate with and/or include other types of access networks, such as, for example, a WiFi network, a Worldwide Interoperability for Microwave Access (WiMAX) network, a local area network (LAN), a Citizens Broadband Radio System (CBRS) network, a cloud RAN, an open RAN (O-RAN) network, a virtualized RAN (vRAN), a self-organizing network (SON), a wired network (e.g., optical, cable, etc.), an optical network, or another type of network that provides access to or can be used as an on-ramp to RAN120, core network130, and/or data network140.

Depending on the implementation, RAN120may include one or multiple types of network devices, such as access devices125. For example, an access device125may include a next generation Node B (gNB), an evolved Long Term Evolution (eLTE) eNB, an eNB, a radio network controller (RNC), a remote radio head (RRH), a baseband unit (BBU), a radio unit (RU), a centralized unit (CU), a CU control plane (CU CP), a CU user plane (CU UP), a Distributed Unit (DU), a small cell node (e.g., a picocell device, a femtocell device, a microcell device, a home eNB, etc.), 5G ultra-wide band (UWB) nodes, a future generation wireless access device (e.g., a 6G wireless station, etc.), another type of wireless node (e.g., a WiFi device, a WiMax device, a hotspot device, etc.) that provides a wireless access service, or another type of network device that provides a transport service (e.g., routing and forwarding). Additionally, or alternatively, access device125may include a wired and/or optical device (e.g., modem, wired access point, optical access point, Ethernet device, etc.) that provides network access. According to some implementations, access device125may include a combined functionality of multiple RATs (e.g., 4G and 5G functionality, 5G and 5.5G functionality, etc.) based on demands and needs.

Core network130may include one or multiple networks of one or multiple types. For example, core network130may be implemented to include a terrestrial network and/or a satellite network. According to an exemplary implementation, core network130includes a network that may interact with multiple types of RANs120. For example, core network130may include the core part of a 5G network, a 6G network, an LTE network, an LTE-A network, a legacy network, and so forth.

Depending on the implementation, core network130may include various network elements that may be implemented in core devices135. Core devices135may include physical function nodes, virtual network functions (VNFs), or containerized network functions (CNF). Thus, the components of core network130may be implemented as dedicated hardware components and/or as virtual functions implemented on top of a commonly shared physical infrastructure using, for example, Software Defined Networking (SDN). Such network elements may include a user plane function (UPF), a session management function (SMF), a core access and mobility management function (AMF), a unified data management (UDM), a packet data network gateway (PGW), a serving gateway (SGW), a policy control function (PCF), an authentication server function (AUSF), a home subscriber server (HSS), as well other network elements pertaining to various network-related functions, such as billing, security, authentication and authorization, network polices, subscriber profiles, network slicing, and/or other network elements that facilitate the operation of core network130. In some implementations, one or more core devices135may provide information to access devices125to facilitate network slicing.

Data network140may include one or multiple networks. For example, data network140may be implemented to provide a service or include an application-layer network, the Internet, an Internet Protocol Multimedia Subsystem (IMS) network, a Rich Communication Service (RCS) network, a cloud network, a packet-switched network, or other type of network that hosts a user device application or service. Depending on the implementation, data network140may include various network devices that provide various applications, services, or other type of UE device assets (e.g., servers (e.g., web, application, cloud, etc.), mass storage devices, data center devices), and/or other types of network services pertaining to various network-related functions. According to an implementation described herein, data network140may include one or more application functions145that provide application services to UE devices110. Core network130may associate an application function145with a network slice, such as a secure network slice, to service a corresponding application (e.g., client application117) on UE devices110.

Proxy image manager150may include a network device to perform life cycle management for SACP115in UE devices110. Proxy image manager150may ensure that an executable trusted proxy is maintained in UE device110. For example, proxy image manager150may remotely download a trusted proxy image (e.g., for SACP115) during every boot operation for UE device110. In one implementation, as shown inFIG.1, proxy image manager150may be included within core network140. In other implementations, proxy image manager150may be included within another area of a MNO's network.

Application provider network160may include a server that acts as a repository for applications, such as client applications117, that may be downloaded and executed by UE device110. Although shown separately inFIG.1, application provider network160may be one of data networks140. While only one application provider network160is shown inFIG.1, in various embodiments, multiple application provider networks160may be associated with different entities and used within environment100.

AlthoughFIG.1shows example components of environment100, in other implementations, environment100may include fewer components, different components, differently arranged components, or additional components than depicted inFIG.1. Additionally, or alternatively, one or more components of environment100may perform functions described as being performed by one or more other components of environment100.

FIG.2is a block diagram of a UE device110configured for slice-specific security resource orchestration, according to an implementation described herein. As shown inFIG.2, UE device110may include components for SACP115to provide slice-specific access controls divided between a rich execution environment202and a trusted execution environment (TEE)204operating on platform hardware206.

Rich execution environment (REE)202may be a “normal” or less secure environment for UE device110. REE202may include normal operating system (OS) components212, slice-specific security profiles214, and a variety of functions/applications216-1through216-4that are configured to operate on secure network slices that require confidentiality. REE202may also include open applications or services (not shown) that do not use restricted slices and, thus, do not require any interface with TEE204. These open applications may be accessed using normal OS components212, which similarly do not require any interface with TEE204.

Slice-specific security profiles214may include network slice requirements for applications stored in UE device110. Slice-specific security profiles214may define security parameters, such as encryption requirements, isolation requirements, and other protocols that a network slice must have to support a particular application or function. According to an implementation, slice-specific security profiles214may be defined for each OEM application/function and subsequently added client applications for UE device110. In one aspect, security requirements for applications in slice-specific security profiles214may be defined in generic terms, such as “low,” “medium,” and “high,” without reciting specific protocols or security functions.

Functions/applications216may include functions and/or applications with designated secure network slice requirements. In some instances, functions/applications216may correspond to subscribed services for UE device110, such as enhanced Mobile Broadband (eMBB) or IoT services. In other implementations, functions/applications216may correspond to client applications117. For example, function216-1may identify a default slice designated for eMBB control plane (CP) communications, and function216-2may identify a default slice designated for an eMBB user plane (UP) communications. Application216-3may be, for example, a client application requiring eMBB services using Transport Layer Security (TLS). Application216-4may be, for example, another client application requiring eMBB services using Datagram TLS (DTLS). In other implementations, function/applications216may be designated for different service levels and/or protocols. The particular designated network slice requirements for each of functions/applications216may be provided, for example, by a service provider, an application vendor, an app store, a network operator, etc. The slice security requirements may be stored in SE208(e.g., for subscribed/default functions) and/or slice-specific security profiles214(e.g., for client applications117).

TEE204may provide a secure environment within, for example, a segmented portion of UE device100to implement SACP115. TEE204may run isolated from the main system (e.g., REE204) using a parallel operating system and specific drivers. TEE204may include a variety of security resources226-1through226-4, a Slice-specific Security Resource Orchestrator230, a Secure Assurance Mapping Table232, and trusted OS components234.

Each of security resources226may include software code to implement a particular security level or microservice that may be applied to a function/application216. For example, security resource226-1and security resource226-2may be a package to implement certain confidentiality and integrity algorithms (e.g., NR Encryption Algorithm 128-NEA and NR Integrity Algorithm 128-NIA), which typically terminate at RAN120. Security resource226-3and security resource226-4may include application layer security protocols for end-to-end slice security. For example, security resource226-3may include a package to implement a Transport Layer Security (TLS) algorithm. Security resource226-4may include a package to implement a Datagram TLS (DTLS). In other implementations, security resources226may include different or additional protocols, such as IP Security (IPSec), Secure Socket Layer (SSL), etc. As described further herein, depending on the security requirements of a network slice, a security resource226may be instantiated for a single slice or shared among multiple slices based on the security profile associated with the slice(s). Once linked to one or more security resources226, traffic between function/application216and RAN120is routed through the linked security resources226.

Security resource orchestrator230may manage the life cycles of security resources226in TEE204. According to an embodiment, orchestrator230may determine whether a security resource is instantiated, terminated, or is in another state based on usage data of functions/applications216. According to one implementation, orchestrator230may obtain from SE208(via reader252) slice identifiers for default/subscribed slices during a UE device start-up (e.g., upon a system re-boot, etc.), determine the corresponding security profile associated with each of the slice identifiers and corresponding security resource requirements (e.g., from secure assurance mapping table232), and instantiate and/or pair a default function216with appropriate security resources226. According to another implementation, when one of functions/applications216is initiated after UE device start-up (e.g., upon a user launch, etc.), orchestrator230may obtain the slice profile from slice-specific security profiles214and instantiate and/or pair the function/application216with appropriate security resources226. Orchestrator230may also perform other types of operations, such as management of memory and processors to support security resources226and/or other management functions pertaining to UE device100.

Secure assurance mapping table232may include a data structure to map security requirements from secure enclave (SE)208and slice-specific security profiles214to particular security resources needed to implement one of functions/applications216. For example, secure assurance mapping table232may include specific security protocols, isolation requirements, and other security features that map to particular requirements for an application (e.g., as obtained from slice-specific security profiles214).

Trusted OS components234may provide an isolated operating system to run TEE204. Trusted OS components234may include a TEE communication agent238, a trusted core framework240, trusted device drivers242, and a trusted kernel244. TEE communication agent238may provide a communication interface between REE202and TEE204. For example, when an application216is launched and or installed in REE202, TEE communication agent238may receive from the corresponding application/slice-specific security profiles from slice-specific security profiles store214. Trusted core framework240may, for example, be partitioned to execute multiple virtual entities that can be assigned different normal worlds (e.g., REE202) and secure worlds (e.g., TEE204). Trusted device drivers242may include software to access resources in TEE204via confidential application programming interfaces (APIs) and/or cryptographic libraries. Similarly, trusted kernel244may include a segmented kernel that is accessible from trusted OS components234and not accessible from normal OS components212.

Platform hardware206may include physical memory and processing components of UE device110that can be configured to spin-up or tear-down secure resources (e.g., for TEE204). According to implementations described herein, platform hardware206may include a trusted SE reader252. Trusted SE reader252may be configured to read/extract from SE208information related to a slice admission control proxy (e.g., user subscription information, a trusted proxy image, etc.).

SE208may be configured to include, among other features, logic for managing SACP115. SE208may include a Subscriber Identification Module (SIM) card, an embedded SIM (eSIM), a Universal SIM (USIM), a 5G USIM (or other generation SIM), a Universal Integrated Circuit Card (UICC), an embedded UICC (eUICC), or a similar type of component. In some embodiments, SE208may include its own secure processor, I/O circuits, and secure storage (e.g., non-volatile, solid state memory such as RAM and/or ROM, volatile RAM, electrically erasable programmable ROM (EEPROM), etc.) to hold a trusted proxy image for SACP115. SE208may be provisioned with a trusted proxy image (e.g., from proxy image manager150) for SACP115to manage access controls for the listed network slices.SE208may also include a listing of network slices a UE device110is permitted to access (e.g., special access slices, such as eMBB slices, IoT slices, ultra-reliable low latency communication (URLLC) slices, vehicle to everything (V2X) slices, high-performance machine-type communications (HMTC), etc.), which may correspond to one or more of functions/applications216.

Functions/applications216may have a security profile for which security resources226are used to implement required security levels. Security resources226for slices that support subscribed (or default) services (e.g., as indicated in SE208) may be instantiated in TEE204during boot operations for UE device110. For example, as part of a boot/re-boot process, orchestrator230may identify, from SE208, subscription requirements for eMBB function (CP)216-1and eMBB function (UP)216-2. Orchestrator230may obtain slice security requirements from mapping table232and may instantiate security resource226-1and security resources226-2to provide the required security for eMBB function (CP)216-1and eMBB function (UP)216-2. The security profile may indicate the level of security needed, which may be qualitative (e.g., low, medium or high) or may be quantitative (e.g., scale of 1 to 10; with1being low and10being high). A mapping of the security profile to the security features and corresponding granular security properties (e.g., security configuration, data-at-rest protection, data-in-transit protection, algorithms—AES/SHA-256, RSA, ECC, protocols—TLS/IPSec, key lengths—256 bits, key rotation etc.) is performed by the orchestrator230using the information available from the secure assurance mapping table232. In some cases, the security profile associated with an application (e.g., one of function/applications216) may explicitly indicate the security properties and thereby a mapping may be avoided. Security resources226that are orchestrated by the orchestrator230may include unique instances of mutual TLS function, random number generator function, AES encryption function that may correspond to each slice or client applications (e.g., function/applications216-1,216-2,216-3,216-4, etc.) or shared by the slice or client applications based on the security profile associated with the slice or client applications.

Still referring toFIG.2, applications216(e.g., application216-3and216-4) are given a security profile (e.g., provided by a third party application provider, etc.) which is stored in security profiles214. When a user opens applications216-3or216-4, for example, a network slice is assigned to support the application. Based on the security profile for the application slice, orchestrator230may create dedicated resources (e.g., security resources226-3and226-4) in TEE204to support applications216-3and216-4. In some cases, security resources226(e.g., security resources226-2) may be shared among different applications216, depending on the requirements of the security profiles214(e.g., as interpreted by mapping table232). For example, as illustrated inFIG.2, eMBB client application216-3and eMBB client application216-4may be linked to use a shared security resource226-2for user plane security. A dedicated security resource226-3for TLS may be orchestrated to be used only for eMBB application216-3, and a separate dedicated security resource226-4may be orchestrated to be used only for eMBB application216-4. Thus, applications216and security resources226may not have one-to-one mapping.

In the example ofFIG.2, the eMBB slice control plane216-1and an associated security resource226-1is orchestrated by orchestrator230, that is used for securing the 3GPP control plane (e.g. RRC, NAS signaling) using, for example, NIA and/or NEA algorithms. The security resources226-1may be a common security resource for securing all eMBB slice control plane communications, including for eMBB client applications216-3and216-4. Based on a risk profile, separate eMBB control plane security resources may be orchestrated for each slice application. According to an implementation, each slice type (e.g., eMBB, MIoT, URLLC, V2X, HMTC, etc.) for which UE device110is subscribed may have a dedicated security resource226for securing the control plane (e.g., secure communications for data-in-transit security). Applications of the same slice type (e.g., eMBB) may share a common control plane security resource (e.g., security resource226-1), as depicted inFIG.2.

The number and arrangement of components illustrated inFIG.2is provided for explanatory purposes. In practice, additional components, fewer components, different components, or differently-arranged components than those illustrated inFIG.2may be used. For example, while an orchestrator230is shown within TEE204, in another implementation, another orchestrator may be included in REE202to instantiate resources for normal (e.g., less secure) network slices. Also, in some implementations, one or more of the illustrated components may perform one or more functions described as being performed by another one or more of the other components.

FIG.3is a diagram illustrating example components of a device300according to an implementation described herein. UE device110, access device125, core devices135, application functions145, proxy manager150, and/or other components of network environment100may each include one or more devices300. As illustrated inFIG.3, device300includes a bus305, a processor310, a memory/storage315that stores software320, a communication interface325, an input330, and an output335. According to other embodiments, device300may include fewer components, additional components, different components, and/or a different arrangement of components than those illustrated inFIG.3and described herein.

Bus305includes a path that permits communication among the components of device300. For example, bus305may include a system bus, an address bus, a data bus, and/or a control bus. Bus305may also include bus drivers, bus arbiters, bus interfaces, clocks, and so forth.

Processor310may control the overall operation, or a portion of operation(s) performed by device300. Processor310may perform one or multiple operations based on an operating system and/or various applications or computer programs (e.g., software320). Processor310may access instructions from memory/storage315, from other components of device300, and/or from a source external to device300(e.g., a network, another device, etc.). Processor310may perform an operation and/or a process based on various techniques including, for example, multithreading, parallel processing, pipelining, interleaving, learning, model-based, etc.

Memory/storage315includes one or multiple memories and/or one or multiple other types of storage mediums. For example, memory/storage315may include one or multiple types of memories, such as, a random access memory (RAM), a dynamic random access memory (DRAM), a static random access memory (SRAM), a cache, a read only memory (ROM), a programmable read only memory (PROM), an erasable PROM (EPROM), an electrically EPROM (EEPROM), a single in-line memory module (SIMM), a dual in-line memory module (DIMM), a flash memory (e.g., 2D, 3D, NOR, NAND, etc.), a solid state memory, and/or some other type of memory. Memory/storage315may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.), a Micro-Electromechanical System (MEMS)-based storage medium, and/or a nanotechnology-based storage medium. Memory/storage315may include drives for reading from and writing to the storage medium.

Memory/storage315may be external to and/or removable from device300, such as, for example, a Universal Serial Bus (USB) memory stick, a dongle, a hard disk, mass storage, off-line storage, or some other type of storing medium (e.g., a compact disk (CD), a digital versatile disk (DVD), a Blu-Ray disk (BD), etc.). Memory/storage315may store data, software, and/or instructions related to the operation of device300.

Software320includes an application or a program that provides a function and/or a process. As an example, software320may include an application that, when executed by processor310, provides a function and/or a process to provide updated proxy images for the Slice Admission Control Proxy of UE device110, as described herein. Software320may also include firmware, middleware, microcode, hardware description language (HDL), and/or other form of instruction. Software320may also be virtualized. Software320may further include an operating system (OS) (e.g., Windows, Linux, Android, proprietary, etc.).

Communication interface325permits device300to communicate with other devices, networks, systems, and/or the like. Communication interface325includes one or multiple wireless interfaces and/or wired interfaces. For example, communication interface325may include one or multiple transmitters and receivers, or transceivers. Communication interface325may operate according to a protocol stack and a communication standard. Communication interface325may include an antenna. Communication interface325may include various processing logic or circuitry (e.g., multiplexing/de-multiplexing, filtering, amplifying, converting, error correction, application programming interface (API), etc.). Communication interface325may be implemented as a point-to-point interface, a service-based interface, or a reference interface, for example.

Input330permits an input into device300. For example, input330may include a keyboard, a mouse, a display, a touchscreen, a touchless screen, a button, a switch, an input port, a joystick, speech recognition logic, and/or some other type of visual, auditory, tactile, affective, olfactory, etc., input component. Output335permits an output from device300. For example, output335may include a speaker, a display, a touchscreen, a touchless screen, a light, an output port, and/or some other type of visual, auditory, tactile, etc., output component.

As previously described, a network device may be implemented according to various computing architectures (e.g., in a cloud, etc.) and according to various network architectures (e.g., a virtualized function, etc.). Device300may be implemented in an appropriate manner to support the architectures. For example, software components may be instantiated, created, deleted on device300, or be placed in some operational state during its life-cycle (e.g., refreshed, paused, suspended, rebooting, or another type of state or status), using well-known virtualization technologies (e.g., hypervisor, container engine, virtual container, virtual machine, etc.) in an application service layer of a network (e.g., access network130) and/or another type of network (e.g., core network130, data network140, etc.). Thus, network devices described herein may be implemented as device300.

Device300may perform a process and/or a function, as described herein, in response to processor310executing software320stored by memory/storage315. By way of example, instructions may be read into memory/storage315from another memory/storage315(not shown) or read from another device (not shown) via communication interface325. The instructions stored by memory/storage315may cause processor310to perform a function or a process described herein. Alternatively, for example, according to other implementations, device300performs a function or a process described herein based on the execution of hardware (processor310, etc.).

FIG.4is a diagram illustrating communications for enforcing access control for network slices via proxy in a secure enclave of a UE device. More particularly, communications isFIG.4illustrate an embodiment of how SACP115can be provided and consistently updated by a trusted source to implement policy based slice admission controls at UE device110. Network portion400may include UE device110with REE202and TEE204, proxy manager150, and RAN120.FIG.4provides simplified illustrations of communications in network portion400and is not intended to reflect every signal or communication exchanged between devices/functions.

As shown at reference402, proxy image manager150may receive and store a latest proxy image for SACP115. According to an implementation, updates to SACP115may be provided to proxy image manager150on a continuous basis. For example, proxy manager150may receive updates from a network administrator or a network function in core network130to reflect new application requirements, services, slice parameters, network changes, etc.

UE device110may perform boot operations404, and in response SE208may reach out to proxy manager150, via request406, to remotely download a trusted proxy image for SACP115. The current proxy image stored by proxy image manager150may be considered the “golden” image that is most recent and most correct. In response to request406, proxy image manager150may download408the latest software image for SACP115to SE208.

As part of the UE device boot process, or in response to a user input, a function/application216in REE202may submit a request410to access a secure network slice (e.g., a network slice with restricted access). Request410may occur before or after TEE204is updated with the latest version of SACP115, and request410may not be granted, for example, until after the latest version of SACP115is confirmed and running in TEE204.

After update412is complete, and in response to request410, TEE204may apply slice admission policies and begin to admit traffic from the particular function/application216in REE202on a restricted network slice. Application traffic416from REE202may be forwarded418to RAN120using security protocols for a designated network slice. For example, application traffic (e.g., TCP/IP packets) from a function/application216may be routed through security resources236and forwarded to RAN120via a wireless cellular connection. Similarly, application traffic420from RAN120may be forwarded to TEE204over the network slice and passed on to the respective application in REE202.

FIG.4illustrates communications for enforcing access control for network slices via proxy in a secure enclave in conjunction with life cycle management provided via a proxy image manager150. In other implementations, an app store (e.g., application provider network160) may provide a separate application (e.g., one of client applications117) for UE device110to provide life cycle management for SACP115.

FIG.5is a flow diagram illustrating an example process500for enforcing access control for network slices via proxy in a secure enclave of a UE device. In the example ofFIG.5, life cycle management of a trusted proxy is performed in conjunction with a mobile network provider service (e.g., proxy image manager150) to remotely download a trusted proxy image. In one implementation, process500may performed by UE device110. In another implementation, process500may be implemented by UE device110in conjunction with one or more other devices in network environment100.

Process500may include performing a UE device reset (block510) and creating a trusted sidecar in a secure enclave (block520). For example, a user may initiate a restart of UE device110, causing UE device110to reboot. As part of the reboot process, SE208may retrieve the latest available proxy image for SACP115from proxy image manager150and conduct an image update over any previous pre-loaded instance of SACP115in TEE204. SACP115may, thus, include the most recent slice access policies for the mobile network provider.

Process500may further include starting the secure enclave with the trusted sidecar (block530), instantiating security resources for default slices (block540), and confirming that the slice admission control proxy is active (block550). For example, components of SACP115may be instantiated and activated in TEE204to apply slice access controls. For default slices, as part of a boot/re-boot process, orchestrator230may instantiate security resources (e.g., security resources226-1and226-2) to provide required security. The security resources226-1and226-2that have been instantiated will be used to protect 3GPP control plane (e.g., RRC, NAS messages) and user plane respectively. The security resources would support NIA and NEA algorithms as specified by 3GPP and other security functionalities (e.g., random number generator) required to provide data-in-transit and data-at-rest security.

Process500may additionally include enforcing slice policies for UE device traffic (block560). For example, UE device110may force (or route) traffic for functions216through the instantiated security resources226of SACP115. The security resources (e.g., security resources226-1and226-2) may enforce network slice policies for packets flowing to and from special slices in network environment100. Security resources226for applications that require special treatment in addition to the generic security resources that have been instantiated for control and user plane protection (e.g., such as for client applications216-3and216-4) may be instantiated when the application is launched, as described further in connection withFIG.7.

FIG.6is a flow diagram illustrating another example process600for enforcing access control for network slices via proxy in a secure enclave of a UE device. In the example ofFIG.6, life cycle management of a trusted proxy is performed in conjunction with an app store (e.g., application provider network160) that may be managed by a third party provider. In one implementation, process600may performed by UE device110. In another implementation, process600may be implemented by UE device110in conjunction with one or more other devices in network environment100.

Process600may include loading a trusted slice management application from an application provider (block610) and obtain user permission to install a SACP in a secure enclave of the UE device (block620). For example, using an app store or other application source (e.g., application provider150) UE device110may download a trusted slice management application for a particular mobile network provider. The trusted slice management application may be programmed to configure a sidecar enclave for UE device110and may query the user of UE device110for permission to install the sidecar.

Process600may also include installing an SACP and confirming the SACP is active (block630), instantiating security resources for default slices (block640), and enforcing slice policy for UE device traffic (block650). For example, components of SACP115may be instantiated and activated in TEE204to apply slice access controls. For default slices, as part of a boot/re-boot process, orchestrator230may instantiate security resources (e.g., security resources226-1and226-2) to provide required security. Using the most recent available policies for the mobile network provider, SACP115may force network slice traffic through the instantiate security resources226and enforce network slice policies for packets flowing to and from special slices in network environment100. Security resources for enforcement of network slice polices for client applications (e.g., applications216-3and216-4) that are launched after a UE device boot process may be instantiated as described further in connection withFIG.7.

Process600may further include determining if updates to the SACP are needed (block660). For example, the mobile network provider may provide SACP115updates to application provider150, and application provider150may signal the trusted slice management application on UE device110to retrieve an updated proxy image.

If the trusted slice management application of UE device110does not receive an update signal from application provider150(e.g., process block660—No), SACP115will continue to enforce existing slice access policies for special slices. If the trusted slice management application of UE device110receives an update signal from application provider150(e.g., process block660—Yes), UE device110may download the updated SACP (block670) and process600may return to process block630to install the update.

Process blocks560and/or650may include blocks described inFIG.7to enforce slice policies for applications launched after a device boot process. As shown inFIG.7, process blocks550/640may include executing, in a REE of a UE device, a client application designated for using one or more secure network slices (block710); executing, in a TEE of the UE device, a SACP to provide security resources for the secure network slices (block720); and forcing, by the UE device, network traffic for the client application through the SACP (block730). For example, as described above in connection withFIG.2, eMBB client application216-3and/or eMBB client application216-4may be launched in REE202. Based on the security profiles (e.g., security profiles214) for applications216-3and216-4, orchestrator230may create one or more security resources226in TEE204to support admission control for applications216-3and216-4. For example, a dedicated security resource226-3for TLS may be instantiated for eMBB application216-3, and a separate dedicated security resource226-4may be instantiated for eMBB application216-4, while both applications216-3/216-4may use a shared security resource226-2for 3GPP user plane security and security resource226-1for 3GPP control plane security. Security resources226may provide policy enforcement at the UE device level to enable providers to provide end-to-end security for traffic from applications216-3/216-4that enters and exits the modem (e.g., communication interface325) of UE device110. In some scenarios, the security resources226-1,226-2for protecting 3GPP control plane and user plane may be instantiated and deployed within the TEE204, REE202, or within the UE device's modem based the security profile associated with the default slice as determined by the NSSAI. Similarly, the security resources226-3,226-4for protecting the applications216-3,216-4may be instantiated and deployed within the TEE204, REE202, or the within the UE device's modem based on the security profile associated with the application. An application's traffic may be protected using the security resource226-3or226-4at the application layer and using user-plane security resource226-2at the 3GPP layer. In some cases, based on the security profile associated with the application, the application layer security protection may be performed at TEE204using the security resource236-3or236-4, and based on the overall security profile associated with the slice, the 3GPP layer user plane security using the security resource236-2may be performed at the UE's modem. Any message or data that is used or generated by an application is initially protected using the application layer security resource226-3or226-4, and then the slice security protection is applied using the security resource226-2before sending the message or storing the data. While in some other cases, all the protection may occur within TEE204, and in still some other cases the application security may be performed within REE202while the slice security may be applied in TEE204or within the modem.

Systems and methods described herein enforce access controls for network slices via proxy in a secure enclave of a UE device. A UE device executes, in a REE, a client application designated for using one or more secure network slices of a telecommunications network. The UE device executes, in a TEE, a slice admission control proxy (SACP) to perform admission control for the one or more secure network slices, and forces network traffic for the client application through the SACP. Life cycle management of the SACP can be managed by providing a trusted proxy image to the UE device at every reboot or as managed by a third-party app store.

The foregoing description of implementations provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while a series of messages and/or blocks have been described with regard toFIGS.4-6, the order of the blocks and message/operation flows may be modified in other embodiments. Further, non-dependent blocks may be performed in parallel.