5G Secure Access Services Edge - Amazon Web Services

5G Secure Access Services Edge

NETWORK

SECURITY AS-A-

SERVICE Delivered from multi-cloud 5G SASE

ABSTRACT Organizations spend millions each year on VPNs,

security appliances and network firewalls. However,

these decades old network security technologies

weren’t built for today’s workforce and applications

With applications moving to the cloud, IoT becoming

more common, and users connecting from

everywhere, enterprises need agile and scalable

capabilities that legacy appliances were not designed

to deliver. Built in the cloud and delivered as a

service, network security as-a-service delivers infinite

scalability and can be easily deployed in minutes

without any costly appliances to buy, deploy, or

manage.

Exium USA

Network security as-a-service

1 | P a g e E x i u m I n c .

Chip-based Root-of-Trust

A Root of Trust (RoT) is the foundational security component of a connected device. It provides a chain-

of-trust within a cryptographic system. The current security solutions on the market either use passwords

or digital certificates for user or device credentials. The frustrations with passwords are clear. In case of

digital certificates, the private key is generally stored in software that can get leaked or stolen easily.

When this happens, organizations expose themselves to potential security attacks.

Root of Trust (RoT) is a source that can always be trusted within a cryptographic system. Because

cryptographic security is dependent on keys to encrypt and decrypt data and perform functions such as

generating digital signatures and verifying signatures, RoT schemes generally include a hardened

hardware module.

For example, in the financial sector, credit cards are required to use chip-based authentication to prevent

cloning or misuse of credentials to meet the EMV standard. Therefore, almost all credit cards issued today

are equipped with chip-based technology. These credit cards are more secure because they store data on

chips, rather than just magnetic stripes.

Examples of hardware root-of-trust, chip-based credit card and SIM card in a smartphone

Another example of the chip-based or hardware RoT is the ubiquitous SIM (Subscriber Identity Module)

card that has played a fundamental role in securing mobile telecommunications for over 25 years. In the

new eSIM, the SIM may be securely downloaded into a ‘Secure Element’ that can be permanently

embedded inside any type of device. An eSIM is exactly what it sounds like: An electronic, or embedded,

SIM. Instead of a physical card, SIM technology is built right into your device. An eSIM provides an

equivalent level of security as the removable SIM card. This is vital as it is the subscription credentials

stored on the SIM card that enable secure and private access to the network and services.

To provide an extra layer of security, Exium uses chip-based hardware for both the devices as well as the

edge and core infrastructure as depicted in the Table below. The hardware RoT is a tamper-proof trust

anchor that securely stores the user’s authentication credentials, computes cryptographic keys, and

stores the network’s public key and other network data.



Hardware Root-of-Trust Where? HW SW Platform Chip

Devices

IoT Various eSIM

Mobile, & Wearables

Android

eSIM

Qualcomm Secure Zone

Google Titan-M Chip

iOS eSIM

Secure Enclave

Notebook, Laptop & Desktop

Windows/ Linux TPM 2.0

Intel PTT

Mac Secure Enclave

Local 5G SASE Gateway Server,

IoT Gateway, WiFi AP

Linux

TPM 2.0/ Intel PTT/ SGX

ARM Trustzone

eSIM with 5G support

Edge/ Cloud Servers AWS, Azure, GCP,

others Intel SGX Enclave

HSM/KMS

The Secure Enclave from Apple is a hardware feature of certain versions of iPhone, iPad, Mac, Apple TV,

Apple Watch, and HomePod. The Secure Enclave is a secure coprocessor that includes a hardware-based

key manager, which is isolated from the main processor to provide an extra layer of security. The key data

is encrypted in the Secure Enclave system on chip (SoC), which includes a random number generator.

A Trusted Platform Module (TPM) chip is a secure crypto-processor that is designed to carry out

cryptographic operations such as to generate, store, and limit the use of cryptographic keys. The chip

includes multiple physical security mechanisms to make it tamper resistant, and malicious software is

unable to tamper with the security functions of the TPM. Thanks to Microsoft’s early embrace of the TPM,

all Windows laptops, desktops, and servers include a TPM. The TPM is used by Microsoft Windows to

store critical cryptographic keys, generate random numbers, and verify firmware and software integrity.

Currently TPM is used by nearly all PC and notebook manufacturers. The TPM is also supported by the

Linux kernel since version 3.20 A newer version TCP 2.0 is widely used to secure high-risk industrial

devices, automotive and other applications such as network equipment and there is growing interest for

its use in securing IoT, IIoT, Industry 4.0 applications.

Intel’s Platform Trust Technology (PTT) architecture implements TPM in system firmware without

requiring a dedicated processor or memory. Instead it relies on secure access to the system’s host

processor and memory to perform authentication and verification.

All the major Cloud Service Providers (CSPs) offer cloud-hosted Hardware Security Module (HSM) service

that allows you to host encryption keys and perform cryptographic operations. When a KMS (Key

Management System) needs to generate keys and distribute key information, it interacts with its

dedicated HSM to generate, retrieve, encrypt, and share the keys to the authorized target.



Zero-Trust Network Access

Software defined perimeter model with “Never trust, always verify” stops man-in-the-middle attacks over

untrusted networks such as public WiFi hotspots. Under the zero-trust model, all requests are scanned by

default on the presumption that no users or devices can be trusted safely.

In 5G, the user or device identity is referred to as SUPI (Subscriber Permanent identifier) which has two

formats, legacy format from 4G called international mobile subscriber identity (IMSI) and newly adopted

format in 5G called network access identifier (NAI). Furthermore, 5G provides at least two methods of

authentication and key agreement (AKA) for accessing the network, 5G-AKA and Extensible

Authentication Protocol - Transport Layer Security (EAP-TLS). For the EAP-TLS method, we use the latest

version of the TLS protocol namely TLS 1.3.

These protocol and procedures support entity authentication, message integrity, and message

confidentiality, among other security properties. The 5G Authentication and Key Agreement (AKA)

protocol is a challenge-and-response authentication protocol based on a symmetric key shared between

a user/ device and the network. After the mutual authentication between a user/ device and the network,

cryptographic keying materials (session keys) are derived to protect subsequent communications,

including both signaling messages and user plane data.

With key agreement and derivation complete, all signaling, payload traffic and other communications are

encrypted preventing unauthorized entities to decode and read these data flows. Furthermore, traffic has

integrity, which means it is protected by Message Authentication Code (MAC) using derived keys so that

recipients know that it has not been altered or tampered with. Finally, the identity and credentials of the

user/ device and of the network cannot be impersonated or stolen preventing man-in-the-middle attacks.

A SIM or an eSIM contains two key pieces of data – the SUPI (IMSI) and a shared key Ki. This key is used

in the AKA (Authentication and Key Agreement) protocol when the device connects to the network. For

5G devices with a SIM or an embedded SIM (eSIM), Exium uses 5G-AKA for user/ device authentication.

For 5G devices without a SIM/ eSIM, we use EAP-TLS trust model and authentication framework, where

Network Access Identifier (NAI) serves as user identity, Public Key Certificate as trust model and a

hardware RoT as source of trust. The Private Key is generated and stored in the hardware RoT providing

an equivalent level of security as the SIM/ eSIM (5G-AKA).

5G Trust Model and Authentication Framework

AKA EAP-TLS

Identity IMSI Network Access Identifier (NAI)

Trust Model Shared Symmetric Key, Ki Public Key Certificate

Hardware Root-of-Trust eSIM chip TPM, Secure Enclave, HSM etc.

Both 5G-AKA and EAP-TLS trust models provide Perfect Forward Secrecy (PFS) for the session key. TLS 1.3

in EAP-TLS uses the Ephemeral Diffie-Hellman key exchange protocol, which generates a one-time key

that's used only for the current network session. At the end of the session, the key is discarded. Without



PFS, all data transmitted between the network and user/ device could be compromised if the private key

(shared symmetric key in case of 5G-AKA and private key in EAP-TLS) was ever disclosed. In particular, an

attacker could record encrypted traffic for any amount of time and store it until such a time that they had

access to the private key. Once they have access to the private key, they can decrypt all historic data.

The use of ephemeral keys (temporary session keys) in PFS overcome this concern. With the forward

secrecy mandatory in TLS 1.3, there's no longer a single secret value that will decrypt multiple sessions.

By generating a unique session key for every session a user initiates, even the compromise of a single

session key will not affect any data other than that exchanged in the specific session protected by that

particular key. Knowing the private key of the server no longer allows decrypting the session.

A man-in-the-middle attack is a type of cyberattack where a malicious actor inserts him/herself into a

communication between two parties, impersonates both parties and gains access to information that the

two parties were trying to send to each other.

In both the 5G-AKA and EAP-TLS trust models, the session key is derived independently, using

cryptographic calculations, at both the networks side and the user/ device side, and is never

communicated between the parties. Also, the shared symmetric key for the case of 5G-AKA is stored in

the SIM/ eSIM and the private key for the case of EAP-TLS is also stored in the hardware root-of-trust.

Access to these keys is required to derive the session key via cryptographic calculations. Since it is

practically impossible for the man-in-the-middle to have access to the keys stored in the hardware RoT,

the use of 5G-AKA and EAP-TLS with hardware RoT prevents all types of man-in-the-middle attacks. When

the shared secrets and private keys are stored in the software or communicated between the parties

(even through encrypted links), they can be easily leaked or stolen opening door for the man-in-the-

middle attacks.

An attacker could attempt a bidding down attack by making the device and the network entities,

respectively, believe that the other side does not support a security feature, even when both sides do

support a security feature. To prevent bidding down attacks, 5G uses Anti-Bidding down Between



Architectures (ABBA) parameter that provides protection against bidding down of security features from

higher to a lower release of the standard.

One of the key new aspects of the 5G architecture is segmentation through a concept called network

slicing. New trust boundaries are created both in the network and in places where the network touches

businesses and governments served by the 5G network. Slicing plays an important role in separating and

protecting mission-critical systems from non-managed devices and systems. For example, if there is a

DDoS attack on or emanating from non-managed IoT devices, slicing can ensure that only the IoT slice is

impacted, and that others that manage mission-critical network functions are not affected. Importantly,

slices can be customized based on mission needs with different security mechanisms and policies, such as

firewall configurations, access policies, packet inspection and authentication schemes. This could provide

separate slices with specialized or tailored security for critical systems such as smart energy meters at

distribution stations and generation plants, road sensors providing traffic controls at busy intersections,

safety messages from autonomous vehicles, or connected medical devices and equipment in a hospital.

The Software Defined Perimeter (SDP) creates a “zero trust” security layer over a 5G network. Zero trust

is the concept of verifying user and device identity and providing access to the appropriate network slice

based on service category or application.

Network Encryption & Privacy

In 4G wireless systems, the user or device identity referred to as international mobile subscriber identity

(IMSI) is sent in plaintext. This allowed the so called “IMSI catchers” attacks to identify, locate and track

users. 5G security specifications do not allow plaintext transmissions of the user or device ID, referred to

as SUPI (Subscriber Permanent identifier). Instead, an Elliptic Curve Integrated Encryption Scheme (ECIES)-

based privacy-preserving identifier containing the concealed SUPI is transmitted. This provides enhanced

privacy as the eavesdroppers can no longer identify, locate, and track users.

The layered security approach of 5G also encrypts every single bit between user device and the cloud.

Exium’s 5G SASE service assumes all underlying networks, including the carrier 5G networks as untrusted

networks.



The authentication process starts with the device requesting access by sending its SUPI (IMSI or NAI) that

is encrypted using the public key of the network. The network responds to this request by sending a

Authentication Vector (a large random number) to the device. The device must encrypt this using the

shared key Ki and send this as the response. Since the Home Network has a copy of the key it can check

that the decrypted response corresponds to the value that was originally sent. 5G and 4G also provide

mutual authentication allowing the device to authenticate the network using the AUTH (Authentication

Token) returned by the network and the shared key.

Once the device has been authenticated in 5G the protocol goes on to agree how the traffic will be

encrypted and subsequent messages use a SUCI (Subscriber Concealed Identity) to identify the device. In

5G traffic is encrypted throughout the infrastructure whereas in earlier generations it was only encrypted

over the radio link.

Encryption and Integrity Protection Algorithms Supported IKEv2 5G Mandatory Mandatory (shall) Optional (should)

Encryption Algorithms

DES, 3DES, RC5, IDEA, 3IDEA, CAST, BLOWFISH, and

AES

ENCR_AES_CBC with 128-bit key length

ENCR_AES_GCM with a 16 octet ICV with 128-bit key

length

ENCR_AES_GCM with a 16 octet ICV with 256-bit key

length

Pseudo-Random

Functions

HMAC and AES

PRF_HMAC_SHA1 PRF_HMAC_SHA2_256

PRF_HMAC_SHA2_384

Integrity Algorithms

HMAC, DES, KPDK, and

AES

AUTH_HMAC_SHA1_96 AUTH_HMAC_SHA256_128

Any protocol, L2, L3, and L7 Application

data

GRE tunnel IPSec tunnel

IKE EAP-TLS

Chip-based cryptographic root-of-trust

Encrypt/ Decrypt Privacy

Integrity protection

Encrypt/ Decrypt

Privacy

Integrity protection

https://www.vocal.com/cryptography/des.html

https://www.vocal.com/cryptography/tdes.html

https://www.vocal.com/cryptography/cast.html

https://www.vocal.com/cryptography/aes.html

https://www.vocal.com/cryptography/hmac.html


https://www.vocal.com/cryptography/hmac.html

https://www.vocal.com/cryptography/des.html




Diffie-Hellman Groups

Defined Groups are 2, 3, 5, and 14 through 18

14 (2048-bit MODP) 19 (256-bit random ECP

group)

20 (384-bit random ECP group)

A data session in 5G is referred to as Protocol Data Unit (PDU) session. The 5G standard support three

types of PDU Sessions; IP, Ethernet and Unstructured. The packets from these different session types are

carried in the Generic Routing Encapsulation (GRE) tunnel which in turn is carried in an IPSec tunnel. In

addition to carrying different types of PDU sessions, GRE tunnel also carries the QoS information. The

concept of QoS in 5G is flow based. Packets are classified and marked using QFI (QoS Flow Identifier). The

GRE tunnel carries 6-bits QFI field and 1-bit Reflective QoS Indicator (RQI) field to indicate whether the

user plane reflective QoS is to be activated or not

With the introduction of GRE tunnel and the QoS information inside it, the 5G system not only provides

tunnels for security but also for network performance improvements via QoS control.

Next-Gen Cloud Firewall

Within 5G SASE networking model, cloud-based firewalls work in tandem with other security products to

defend the network perimeter from attacks, data breaches, and other cyber threats. The cloud firewall is

application and user aware and elastically scales across all ports and protocols to handle all your cloud

application traffic.

The cloud firewall includes technologies such as Deep packet inspection (DPI), Intrusion prevention system

(IPS), and application control that are not available in traditional firewall products. It inspects data packet

headers and payload, instead of just the headers aiding in detecting malware and other kinds of malicious

data. An intrusion prevention system (IPS) is a tool that is used to sniff out malicious activity occurring

over a network and/or system. Intrusion prevention systems function by finding malicious activity,

recording and reporting information about the malicious activity, and stopping the activity from occurring.



The cloud firewall provides firewall functionality at the cloud edge to ensure user have consistent

protection no matter where, or on what device, they connect—from home, the coffee shop, the branch

office, at headquarters, or on the road. It also provides real-time monitoring, evaluating what information

is traveling between those source domains and data ports, and permit or block data based on a set of

security rules thereby thwarting potential threats.

DNS Security



A Domain Name System (or DNS) helps point web traffic to the right destination by converting human

readable domain names (www.google.com) into Internet Protocol (IP) addresses (172.217.2.238). It is

used by everyone, everywhere and is wide open for attackers. DNS was created in the early years of the

internet, far before anyone ever thought of incorporating security best practices. DNS operates without

authentication or encryption blindly resolving queries for any client that asks. As a result, a large fraction

of malware uses DNS to initiate command-and-control (C2).

Exium uses DNS to our advantage to block malicious and unwanted domains, IP addresses, and cloud

applications before a connection is ever established. All DNS queries are routed securely inside 5G Layered

security tunnels to the Exium DNS resolvers running at the far-edge in each of Exium Edge (xEdge)

locations. This allows us to maintain the overall integrity and availability of your DNS services, provide

better accuracy and detection of compromised systems without impacting user experience while

improving security visibility and network protection. We also monitor DNS activity that may indicate that

a security issue may be occurring elsewhere in your network.

We inspect all traffic going in and out of the DNS resolver to stop threats over all ports and protocols —

even direct-to-IP connections. Stop malware earlier and prevent callbacks to attackers if infected

machines connect to your network. Exium Security Analytics (xScale) platform works with the DNS

resolver to disrupt attacks that use DNS for command-and-control or data theft, while rapidly identifying

threats with shared threat intelligence and machine learning.

In addition to maintaining the overall integrity and availability of your DNS services, three types of DNS

security protections that we specifically focus on include “DNS Security Extensions,” commonly known as

DNSSEC, protection against DNS Tunneling and Domain Generating Algorithms (DGA).

DNSSEC provides a way to authenticate DNS response data. However, it is possible for an attacker to

intercept your DNS queries and provide false information that would cause your browser to connect to a



fake website where you could potentially provide personal information (for example, what you think is a

bank website). DNSSEC provides a level of additional security where the web browser can check to make

sure the DNS information is correct and was not modified. Note, too, that DNSSEC is NOT only for the

Web, but also can be used by any other Internet service or protocol. We’re already seeing interesting uses

of DNSSEC with email (SMTP), instant messaging and voice-over-IP.

If the recursive name server determines that the address record has been sent by the authoritative name

server and has not been altered in transit, it resolves the domain name and the user can access the site.

This process is called validation. If the address record has been modified or is not from the stated source,

the recursive name server does not allow the user to reach the fraudulent address. DNSSEC can also prove

that a domain name does not exist. As a result of this process, DNS queries and responses are protected

from man-in-the-middle (MITM) attacks and the kind of forgeries that could possibly redirect Internet

users to phishing and pharming sites.

DNS Tunneling is a type of cyber attack that encodes and embeds data and protocols like TCP or SSH in

DNS traffic, primarily to achieve command and control inside an organization’s protected network.

Attackers also tunnel through DNS to deliver and distribute malicious payloads, such as remote access

trojans and ransomware, to victim computers inside an organization. We use a number of techniques

powered by our Security Analytics Engine (xScale) to detect and stop DNS tunneling occurring in your

network. Standard DNS queries are usually quite simple – they consist primarily of a domain and

subdomain. When tunneling is used, on the other hand, malicious actors usually attempt to put as much

data into the communication channel as possible. Querying for unusual text records, which are not

commonly used by a typical client, can help identify tunneling activity. Also, records with long strings of

unique characters, long labels, and long hostnames are almost always DNS tunneling. This is because

tunneling often includes a series of queries each one different from the next. The unique nature of these

queries is designed to increase the chances of getting through.

A Domain Generating Algorithm (DGA) is a program or subroutine that provides malware with new

domains on demand or on the fly. Attackers use DGA so that they can quickly switch the domains that

they’re using for the malware attacks. Attackers do this because security software and vendors act quickly

to block and take down malicious domains that malware uses. The DGA technique is in use because

malware that depends on a fixed domain or IP address is quickly blocked, which then hinders operations.

So, rather than bringing out a new version of the malware or setting everything up again at a new server,

the malware switches to a new domain at regular intervals.

An example of DGA in practice is C&C servers for botnets and ransomware. If we were able to block these

or take them down, we would cut the link between the victims and the threat actor. Bots would no longer

be able to fetch new instructions and machines infected with ransomware would be unable to request

encryption keys and send user data.

Exium constantly monitors DNS traffic and uses a set of advanced algorithms based on everything from

lexical to behavioral analysis to processing the DNS traffic by AI-powered DNS resolver to stop DGA-based

attacks.



Cloud Security Gateway

According to Gartner, a secure Web gateway is a solution that filters unwanted software/malware from

user-initiated Web/Internet traffic and enforces corporate and regulatory policy compliance. These

gateways must, at a minimum, include URL filtering, malicious-code detection and filtering, and

application controls for popular Web-based applications. Sitting between users and the Internet, secure

web gateways provide advanced network protection by inspecting web requests against company policy

to ensure malicious applications and websites are blocked and inaccessible.

What makes a cloud security gateway differ from legacy secure web gateways is that the complete

security stack is delivered as a service—all the filtering and inspection and policy enforcement happens in

the cloud, so there is no need for costly physical appliances to buy, deploy, or manage.

Exium’s Cloud Security Gateway (xCSG) identifies over 3000 protocols and applications, block or limit

website access by identifying malicious sites and automatically preventing web-based attacks. Delivery

from the cloud lets you restore your security perimeter by providing always-on security that follows the

user, regardless of location. xCSG provides full visibility into sanctioned and unsanctioned cloud services

in use across the enterprise, so you can uncover new services being used, see who is using them, identify

potential risk, and block specific applications easily.

5G Secure Access Services Edge - Amazon Web Services

Documents

Transcript of 5G Secure Access Services Edge - Amazon Web Services