HSM-based Zero Trust Service Mesh Communication

The demand for cloud-native architecture is rising as CoSPs work on multiple 5G offerings with container-based microservices solutions. It offers flexible and scalable solutions to deliver services quickly and meet time-to-market expectations. This ability to reconfigure the network on demand gives the agility to rapidly bring new services into the market as the changes are delivered in modular microservices. Changes can be rolled back with minimal disruption to increase resilience.

Cloud-Native Approach and Its Security Challenges

As cloud-native solution enables service-based architecture, vendors can implement the network functions and provide a service-based interface to combine with network functions from multiple vendors. Also, the 5G network functions are highly distributed now compared to previous generations from the network core to the edge and across multiple clouds. 

The transition towards edge and cloud dramatically changes the security landscape for cloud-native solutions as there are more security concerns over deploying services in edge/public cloud. This concern led to zero trust architecture, where each service must establish a trust to communicate, called mutual TLS communication.

Service Mesh for Zero Trust and vulnerabilities with Edge/Cloud solution:

 

 

Service mesh enables mTLS by default, with Istio acting as root Certificate Authority (CA) and provides an option to integrate external CA. So, the question arises, “Isn’t it already safe to use service mesh?”.  
When the workload pod runs in the Istio-enabled namespace, Istio-agent will generate a keypair and certificate signing request (CSR) and send it to Istio-agent to get it signed by CA. Once CSR is signed, Istiod will return the signed certificate to Istio-agent, which will be sent to the envoy and stored in the envoy’s memory. 

 

For signing certificate requests, Istio will use a self-signed root certificate and a private key which is stored in base64 encoded format in Kubernetes secret. 

It is okay if the services are running on the premises as those are managed in-house by vendors with restricted access. But on edge/public cloud, users with root privileges can decode the root CA secrets and sign CSR for introducing any malicious service, which can compromise the entire cluster.

Another such vulnerability can be with an envoy proxy. As the envoy stores private keys used to generate a CSR in memory, the privileged user can get private keys and certificates exported from memory by attaching emptyDir volumes and using annotations to export certificates. The attacker can exploit this private key to sniff traffic between microservices.

 

The rising importance of confidential computing in a cloud-native world

The zero trust with Service Mesh solved the issue with security up to some extent, but as we see, there are vulnerabilities when the platform is compromised. mTLS solved security concerns over trusted workload identities and secured data in transit. But as we evolve to edge/cloud, the traditional network perimeter has vanished, and data must be protected while in use at the level of the individual network function. Confidential computing protects data exposed in RAM while a workload operates, complementing data protection at rest and in transit provided by data and transport-channel encryption.

Intel Software Guard Extensions (SGX) 

Intel SGX offers a trusted execution environment (TEE) that provides hardware-based memory encryption that isolates specific application code and data in memory. It gives libraries that applications can be used to allocate private regions of memory, called enclaves, designed to be protected from processes running at higher privilege levels. It ensures that data is protected while it is in use.

As the most critical aspect of confidential computing is to secure the minor attack surface, it is easier to use the Intel Service Mesh solution with SGX for essential private protection without changing any application code.

Intel SGX as HSM For Private Key Protection in Service Mesh 

Hardware Security Module (HSM) is an exceptional “trusted” environment that performs cryptographic operations: key management, exchange, encryption, etc. It is also common to utilize HSM to enhance the security level of the software.

Intel offers a Service Mesh solution with SGX Private Key Provider support in Envoy. It includes PKCS#11 standard-based Crypto API toolkit for Intel SGX to protect private keys used in Envoy. With this feature, all private keys used in the Envoy data plane are stored in the enclaves. SGX Private Key Provider will perform cryptology operations in TLS handshake inside SGX enclaves to protect all these operations from being hacked throughout their lifecycle.

ACL Digital, Intel, Casa Systems Proof Point for Secure Cloud Native 5G Control Plane

As a solution integration partner with Intel and Casa Systems, ACL Digital demonstrated hardening security to 5G Core deployment using Intel SGX.

 

• As Intel SGX focuses on securing the minor attack surface, the focus is on security mTLS communication between different microservices in the 5G control plane stack.
• The solution consists of tools, including a Key Management Reference Application, enhanced Secure Service Mesh with Intel SGX support, Trusted Certificate Issuer, and Trusted Attestation Services on top of the Red Hat Openshift Platform and container bare-metal reference platform.
• With these tools, critical 5G Core and Edge and other telecom applications that run on network cloud are secured with hardware-based security.

• This solution solves the issue of having clear keys, e.g., from Kubernetes secret for service mesh (Figure 2). Trusted Certificate Issuer, cert-manager based external certificate issuer uses Intel SGX to store CA private key and performs certificate signing inside enclave using Intel CryptoAPI toolkit. Since the CA key is stored in the SGX enclave, it won’t be shown in the Kubernetes secret (Figure 4). It is impossible to decrypt data in enclaves even with privileged access, making the solution more secure when running on public cloud or edge locations.
• It also solves the issue with an exploit to envoy proxy as private key generation and CSR request creation are done in the SGX enclave. So even if the secrets are exported, it won’t be the same private key used for mTLS communication.

 

• Third parties can perform remote/local attestation using a trusted attestation service to ensure they run on the trusted platform using Intel provisioning service before running the applications.
• At Mobile World Congress 2022 in Las Vegas and India Mobile Congress 2022 in New Delhi, India, ACL Digital and Intel demonstrated a commercial 5G control plane on OpenShift that uses Intel SGX enclaves to store the private key used for their service mesh communication.
• Though this POC was targeted to CoSPs, it can be applied to any service on a cloud-native platform that leverages a Service Mesh solution for security.
• ACL Digital, in partnership with Intel Technologies, is well-poised to understand and address customer 5GC security requirements and is the preferred choice for building SGX-based security within a short timeline.

Register for this webinar to understand the role of service mesh in cloud-native 5G network cores and discuss the benefits of using Intel SGX to enhance 5G security: Diving into Zero Trust and Building Secure 5G Networks

References:

https://istio.io/latest/docs/concepts/security/
https://www.intel.in/content/www/in/en/architecture-and-technology/software-guard-extensions.html
https://www.intel.ca/content/www/ca/en/architecture-and-technology/software-guard-extensions/hardware-security-sgx-infographic.html
Secure the Future of 5G Networks with Zero Trust for Cloud Native Architectures | Intel® Network Builders
https://www.intel.com/content/www/us/en/developer/articles/technical/secure-service-mesh-communication-hardware-sgx.html
Securing Workloads on OpenShift Container Platform (intel.com)
https://www.intel.ca/content/www/ca/en/architecture-and-technology/software-guard-extensions.html
https://idstch.com/cyber/industry-developing-security-solutions-like-hardware-security-module-hsm-for-secure-military-unmanned-platforms-sensors-and-communication-devices/
https://community.surfboard.com/sb6190-58/why-would-sb6190-fail-to-aquire-bonded-upstream-channels-1094
https://www.intel.com/content/www/us/en/developer/articles/technical/securing-workloads-on-openshift-container-platform.html