1. NextGen (5G) Security and Platform Integrity Alec Brusilovsky TCG TMS co-chair

2. Agenda 5G Capabilities to Drive 5G Security Network Slicing
Current 3GPP security constraints
5G Security - Core Areas
5G Opportunity Areas
5G Security – Design Assumptions
5G Security – Standardization Methodology

3. 5G Capabilities to Drive 5G Security
Supporting not only voice and data communication as we know it today, 5G networks will provide communication capabilities for new use cases and industries as well as a multitude of devices and applications…
Orders of magnitude more entities
Different traffic models (UL comparable or exceeding DL)
Netflix traffic in the US of 60 petabytes per year
Single Boeing 787 aircraft engine generates 0.5 terabytes of data during an average flight
5G will drive new security requirements due to
New business and trust models
New service delivery models (Separation of Control Plane/User Plane -> SDN, Slicing -> SDN and NFV)
Much more complicated and dynamic threat landscape
Greater than ever before concern for privacy
5G Security will be affected throughout in the network
Evolution involves all parts of the network,
Core network and management systems
Protocol layers ranging from radio to applications

4. 5G Network Slicing
Current 3GPP networks do not support a notion of slicing
Slicing: a way to provide isolated sub-networks, each optimized for specific types of traffic characteristics
Support for Network Slicing (NS) is required in 5G mobile networks in both home network and roaming scenarios
Support for 4G UEs is also required in 5G mobile networks. 3GPP defined the following use cases for 5G which each require different types of features and networks in terms of mobility, charging, security, policy control, latency, reliability, etc.
Mission-Critical Communications
Mobile Broadband
Massive IoT
Network Slicing facilitates network optimization for different use cases, reducing Operator’s CAPEX/OPEX
Network Slicing will be achieved by utilizing Virtualization, SDN, and NFV, which reduce dependency on proprietary/secure platform and require trusted computing technologies (root of trust, attestation, and secure storage)

5. Current 3GPP security constraints
Existing trust model does not capture the evolved business and technology capabilities of 5G –
Does not mean completely redesigning security
Crucial to identify any significant challenges while defining the new trust model
Architectural limitations dictated by trust concentrated in the network
Edge and terminals are considered to be untrusted
New trust model will be more flexible (e.g., trust in Endpoints, Cloud, and Fog, availability of trusted platforms, etc.)
Only minimum protection of subscription/UE identities, no authentication of ME (only subscription authentication)
HSS/HLR being a repository of identities and attributes
Will not scale to expected number of identities in 5G
Need for Federated Identity Management (FIdM)
Existing security model is binary
Either on or off, without selective security per flow/service
Need for more flexible and on-demand security

6. 5G Security - Core areas Flexible and scalable security architecture
Presentation Title
5G Security - Core areas
Flexible and scalable security architecture
Virtualization and dynamic configuration for 5G promotes new dynamic and flexible security architecture
Security for RAN signaling could be located close to the access (e.g., virtualization) with a higher degree of independence to the user plane security, allowing more robust security (key distribution, key isolation, etc.)
5G radio network security
Attack resistance of radio networks to threats such as Denial of Service from potentially misbehaving devices
Adding mitigation measures to radio protocol design
Utilize available trusted computing technologies
Virtualization security (ETSI NFV SEC)
Network virtualization with high assurance of VNF isolation to simplify the handling of diverse security requirements in common infrastructure
Use existing trusted computing tools (TCG) and concepts for Virtualized Platform Integrity
root of trust
remote attestation
device integrity monitoring
secure storage
Cloud-friendly data encryption (homomorphic encryption, allowing operations on encrypted data).
Identity management
5G open identity management architecture
Billions of heterogeneous end-devices, sensors, network nodes with variable security capabilities, device attributes, and policies
Allow enterprises with an existing IDM solution to reuse it for 5G access.
New ways to handle device/subscriber identities with network slicing, enabling different IDM solutions per slice
Energy-efficient security
Most constrained, and battery-dependent devices with a long life time might be separated in specialized energy-efficient lightweight network slice
Need to compare energy cost of encrypting one bit vs. transmitting one bit and consider hardware acceleration benefits
Security assurance
Deployment of heterogeneous hardware and software components creates greater need for security certification
System state attestation needs to be communicated between entities to provide assurance in platform integrity
Multi-layer security certification scheme is needed to efficiently create and traverse certification records
© 2015 Trusted Computing Group

7. 5G Opportunity Areas Identity management (SA3, ETSI NFV SEC, SG17)
Changing trust models to ones with trust located at the edge and in terminals as well as in the core (SA3, TCG, ETSI MEC, ETSI NFV SEC, SG17)
Privacy and confidentiality of data and identities (SA3, ETSI NFV SEC, TCG, SG17)
Flexible and scalable security architecture (SA3, ETSI MEC, ETSI NFV SEC, SG17)
Energy-efficient security (SA3, ETSI MEC, ETSI NFV SEC, SG17)
Virtualization security (SA3, ETSI NFV SEC, ETSI MEC, TCG, SG17)
Security assurance (SA3, ETSI NFV SEC, TCG, SG17)
5G radio network security - on-demand security, low latency security (SA3, SG17?)

8. 5G Security – Design Assumptions
The threat landscape has changed since 2G was designed.
Through evolved security solutions, 3GPP mobile networks have remained trustworthy and are a highly secure and convenient way to access services and information.
5G faces far more dramatic cyber-security challenges than 2G/3G/4G,
By using the right design approach, 5G networks will be able to meet growing demands for security and privacy.
Three out of four drivers for 5G security involve new requirements:
New service delivery models
Evolving threat landscape
Increased focus on privacy
The fourth driver requires an analytical approach to identifying the requirements:
New trust models
Are 2/3/4G design approaches still valid?
Some are still valid. E.g., 3GPP’s approaches for 3G and 4G – which brought the industry highly secure radio and core network protocols and subscriber authentication
New considerations for 5G security design:
New trust models
Potentially misbehaving entities and devices
Security assurance (static and dynamic)
Identity management
Radio network security
Flexible and scalable security architecture
Energy efficient security
Virtualization security

9. 5G Security – standardization methodology
5G security is not a quantitative (or incremental to 3/4G) matter. It cannot be primarily propelled by increased bitrates, decreased latency, and other quantitative aspects
The level of 5G security is not defined by the number of specified security mechanisms
Trying to address all possible requirements of every stakeholder in the same network could lead to a reduced security level, or to a solution with convoluted security
A well-designed, flexible security baseline, and assurance in the implementation of this baseline will be more important than the number of security requirements
Network slicing, relying on such baseline, will increase overall 5G security, allowing different slices to implement only security mechanisms that are germane for that particular network slice/service. Network slicing may be practically achieved only by implementing NFV/SDN.
Platform Integrity and Trusted Computing techniques (i.e., Root-of-Trust, Attestation, and Secure Storage are preconditions for Secure Virtualization.)
A multi-stakeholder approach involving operators, vendors, regulators, policy-makers and 5G users (e.g., industry segments) is fundamental to the security baseline of trustworthy, cost-efficient and manageable 5G networks
Pre-standardization consensus building, such as joint research by the different stakeholders, will be essential.
No single SDO (e.g., ETSI, ITU, 3GPP, oneM2M, etc.) will be able to standardize 5G security. Creation of collaborative SDO ecosystem is vital to success of 5G Security:
3GPP – Network security
ETSI NFV – Virtualization security
ITU-T – Comprehensive security studies and standardization
TCG – Trusted computing standards

10. Thank you

11. Backups Need for Platform Integrity Problem Statement
Key Technologies from TCG
TCG Background Information
TCG Work Items
TCG Deliverables
Background Information on EPS Security

12. Problem Statement
Migration of network core functionality to the cloud introduces new security vulnerabilities due to loss of the security provided by the physical protection and isolation of traditional network systems
When moving functionality to the Cloud, scalable security controls and tools to provide MNO/enterprise with trust and assurance that their data and computing will remain private and uncompromised do not exist
There are no explicit and verifiable ways of protecting software components (guest OS, applications/library code and data) that reside in the Cloud (a virtual machine or container)

13. Platform security for NFV (boot, crash, and runtime)
TCG – Key Technologies
Platform security for NFV (boot, crash, and runtime)

14. TCG – Highlights TCG Key Contributor Awards – October 2015
Alec Brusilovsky (InterDigital, TCG TMS WG Co-Chair)
Ira McDonald (High North, TCG TMS WG Co-Chair)
Creation of new TCG groups
Network Equipment Subgroup (NetEq) – chartered May 2015
Root-of-Trust-for-Measurement Subgroup (RTM) – chartered July 2015
Creation of new work items
TNC IF-MAP Concise Binding – CBOR (RFC 7049) – started February 2015
Publication of new or revised deliverables
TPM 2.0 Mobile Common Profile – published December 2015
Guidance for Securing IoT Using TCG Technology – published Sept 2015
Future meetings
TCG Members Meeting in Vienna, Austria – June 2016

15. TCG – Other Highlights TCG / OMA Cooperation Agreement – May 2015
Mobile device management and provisioning
Potential – Provisioning TCG technologies via OMA DM 2.0
TCG / SAE Collaboration – since December 2014 – ongoing
Secure automotive requirements, protocols, and solutions
SAE Vehicle Electrical System Security Committee – TCG members
SAE Vehicle Electrical Hardware Security Task Force – TCG members
Potential – Add TPM 2.0 features to SAE h/w security requirements

16. TCG – Other Highlights
TCG Members Meeting in Edinburgh – June 2015
Keynote by Dr. Bilel Jamoussi, ITU-T TSB
“Vision of Trust, Security, and Privacy in Future ICT”
TCG Members Meeting in Montreal – October 2015
Edit TCG Multiple Stakeholder Model
Edit TCG Runtime Integrity Maintenance
Edit TCG Guidance for Securing Network Equipment
Edit TCG Guidance for Securing Constrained IoT Devices
TCG Members Meeting in San Francisco – February 2016
TCG Multiple Stakeholder Model – public review ended 15 Feb 2016
Edit TCG Mobile Specs Implementation Guidance

17. TCG – General Information
Trusted Computing Group (TCG)
One of the foremost standards bodies focused on trusted computing
TCG Structure and Workgroups
TCG Members – 100+ vendors, governments, universities
Cloud computing, operating systems, aerospace, automotive, SoC, IoT, embedded systems, mobile phones, servers, PCs, laptops, hard drives
TCG Formal Liaisons
ETSI, OMA, Global Platform, Mobey Forum, ISO, IEEE, IETF, OASIS…
Work in Progress – ITU-T (e.g., SG17 and SG13 for platform integrity)
TCG Informal Liaisons
3GPP SA3, Small Cell Forum, Linux Foundation…

18. TCG – General Information
TCG Technical Work Groups – Specifications & Guidelines
Embedded Systems – IoT, Net Equipment, Root-of-Trust for Measurement (RTM), auto, financial, industrial, medical
Infrastructure – integrating TCG technologies into enterprises and the Internet
Mobile – smartphones, feature phones, basic phones, also laptops and tablets
PC Client – desktop/laptop/tablet TPM profiles, interfaces, and drivers
Server – server requirements, guidelines, and specifications
Software Stack – TPM standard APIs and protocol stack
Storage – security standards for dedicated storage systems
Trusted Network Communications – endpoint integrity, access policy, monitoring
Trusted Platform Module – hardware root-of-trust, crypto, key management
Virtualized Platform – virtual TPM, multi-persona, isolation, migration
TCG Solutions Work Groups – Use Cases & Best Practices
Trusted Mobility Solutions – end-to-end mobile ecosystems & solutions
Trusted Multi-tenant Infrastructure – Cloud trust models and best practices

19. TCG – Work Items MPWG Mobile Device Multiple Stakeholder Model
Scope – discrete, firmware, and virtual TPMs for high-value applications
Status – member/public review ended 15 February 2016
MPWG Mobile Device Runtime Integrity Maintenance
Scope – pre-boot integrity, secure boot, integrity checking, remediation
Status – work-in-progress – member/public review in Q2/Q3 2016
MPWG Mobile Specs Implementation Guidance
Scope – use of all TCG Mobile specs and use with Global Platform TEE
TMS Use Cases 2.0 – Enterprise, Financial, and NFV
Scope – end-to-end mobile solutions for telecom / enterprise networks

20. TCG – Work Items TNC IF-MAP Concise Binding
Scope – security automation servers w/ publish/subscribe for IETF SACM
Status – work-in-progress – member/public review in Q2 2016
Goal – IF-MAP 3.0 (TLS/CBOR) to replace IF-MAP 2.2 (SOAP/XML)
TCG Guidance for Securing Network Equipment 1.0
Scope – securing routers, switches, firewalls, access points, etc.
Status – work-in-progress – member/public review in Q1/Q2 2016
TCG Guidance for Securing Constrained IoT Devices
Scope – provisioning, attestation for constrained IoT devices

21. TCG – Published deliverables
Trusted Platform Module (TPM) 2.0 Library – October
Roots-of-trust, key creation/management, attestation, signatures, multi-factor authentication, audit trail, sessions, roll-back protection
TPM 1.2 and TPM 2.0 are ISO 11889:2009/2015 – two billion devices
Servers, PCs, tablets, smartphones, printers, kiosks, industrial systems, embedded systems, and more
TPM 2.0 Library Errata 1.4 – January
TCG Algorithm Registry 1.22 – February
RSA, ECC Curves, Hash Algorithms, Symmetric Ciphers, etc.

22. TCG – Published deliverables
A Practical Guide to TPM 2.0 – February
Will Arthur (Intel) and David Challener (JHU) – eBook download is FREE
TNC SWID Messages for IF-M – August 2015
Posture Attributes – for policy on installed software (SWID Tags)
TNC IF-TNCCS TLV Binding 2.0 – May 2014 – also RFC
Posture Broker – endpoint integrity measurement (IETF NEA PB-TNC)
TNC IF-M TLV Binding 1.0 – May 2014 – also RFC
Posture Attribute – endpoint standard attributes (IETF NEA PA-TNC)
TNC IT-T TLS Binding 2.0 – February 2013 – also RFC
Posture Transport – endpoint attribute transport (IETF NEA PT-TLS)

23. TCG – Published deliverables
TPM 2.0 Mobile Common Profile – December
Profile of TPM 2.0 for smartphones, feature phones, and basic phones
TPM 2.0 Mobile CRB Interface – February
OS and hardware independent TPM driver interface
TPM 2.0 Mobile Reference Architecture – December
Secure boot, measured boot, protected environment, security requirements, and implementation examples for all mobile devices
TMS Use Cases – Bring Your Own Device – October
Mobile phone use case input to TPM 2.0 Mobile Reference Architecture

24. TCG – Published deliverables
Storage Architecture Core Spec 2.01 – August
Comprehensive architecture for putting selected features of Storage Devices under policy-driven access control
Storage Security Subsystem: Opal 2.01 – August
Core specification for Opal self-encrypting drives (desktops/laptops)
Storage Security Subsystem: Enterprise 1.01 – August
Core specification for enterprise self-encrypting drives (servers)

25. UMTS AKA – foundation of EPS AKA
AuC – Authentication Center
AUTH – Authentication vector (quintuplet)
AUTN – Authentication Token
CK – Ciphering Key
HLR – Home location Register
IK – Integrity Key
IMSI – International Mobile Subscriber Identity
KASME – Root key of Access Security Management Entity
ME – Mobile Equipment
RAND – Random challenge
RES – Response to an authentication challenge
VLR – Visited Location Register
XRES – eXpected Response ME
VLR/SGSN
(MME)
HLR/AuC
(HSS)
Register
Authentication
Auth. Vectors
RES, IK, CK or KASME
Compute “quintuplets”
Validate
RES = XRES
Select CK, IK or KASME
1. Check if SQN is in the range
2. Compute RES, CK, IK or KASME
USIM
data request
RAND, AUTN
RES
IMSI 1 2 3 4 5 6 7 UE
{RAND, AUTN, XRES, CK, IK}
{RAND, AUTN, XRES, KASME}

26. Security Layers in EUTRANUE
eNB Xu
MME S 1 - C X 2
Evolved Packet Core (
EPC ) E
UTRAN
SAE GW U
Security layer
The design target for LTE Security is to minimize the effects of the compromised E-UTRAN security layer (1st Layer) to the EPC security layer (2nd Layer).
This principle improves the overall system security and allows placement of eNBs into more vulnerable locations without high risks for the operators. It also makes the overall system security evaluation and analysis easier in case of multiple access technologies connected to the EPC. However, care must be taken when designing the interface between these two security layers, namely the S1-C and S1-U interfaces.
It is important to evaluate how the compromise of the first layer affects the whole SAE/LTE system security.
The goal is to make this effect low and local so that the risk of compromised first layer is as low as possible. As a result, the use case of a home eNB (identified scenario in LTE) becomes more realistic as well.
The S1 interface (consists of S1-C and S1-U), is the point where the two security layers interact. It is imperative to reduce security risks from partially compromised first security layer. Thus, particularly the messages from eNBs towards the EPC network elements should be properly analyzed from security perspective.
In case the attacker is able to compromise the first security layer, the second layer is not compromised.
EPS has two layers of protection instead of one layer perimeter security in the UMTS. First layer is the Evolved UTRAN (EUTRAN) network (RRC security and UP protection) and second layer is the Evolved Packet Core (EPC) network (NAS signalling security).

27. EPS AKA run and key change/derivation (handover keys are omitted)
Result of the AKA run
K_eNB key is transported to the eNB from the EPC when the UE transitions to LTE_ACTIVE
K_ASME is derived from CK&IK.
It never leaves the EPC
UE/ASME
eNB derives the UP and RRC keys from K_eNB
SA3 has identified four independent requirements regarding the change of keys in the eNB for a UE in LTE_ACTIVE:
If the sequence numbers for the UP or RRC ciphering/integrity protection are about to wrap around, it shall be possible to change the respective keys.
If a UE has been in LTE_ACTIVE for a long period of time, it shall be possible to update the keys for UP and RRC ciphering/integrity protection, even though the sequence numbers are not close to wrapping.
The operator shall be able to restrict the lifetime of K_ASME (independently of the key usage in LTE).
If the UE has performed an inter-RAT handover from UTRAN/GERAN to LTE, it shall be possible to update all keys within seconds.
In case of (1) and (2), it is not necessary to run an AKA to get new keys; it is sufficient that the eNB-local UP and RRC keys are changed. This can, e.g., be achieved by deriving new UP and RRC keys from the existing K_eNB in the eNB itself, or by deriving a new K_eNB from K_ASME.
In case of (3) and (4), the whole key hierarchy based on K_ASME must be updated based on a new AKA run. This shall be possible even if the UE has stayed in the same cell for a long time.
SA3 notes that there are two sub-issues:
Firstly, the new keys must be established in the eNB and in the UE (either by an AKA re-run, re-derivations of the eNB-local keys, or re-derivation of the K_eNB).
Secondly, the new keys must be taken into use. In case of (1), the establishment of the new keys, and the activation of these must be performed before the sequence numbers wrap. In case of (2) and (3), SA3 has made a rough estimate that the AKA may have to be run every 5 hours, and that the keys should then be taken into use less than 10 minutes after that. In case of (4), it shall be possible to take new keys into use within seconds after the handover (an AKA run must of course have been performed first).
When the UE goes into LTE_IDLE or LTE_DETACHED, the K_eNB, UP and RRC keys are deleted from the eNB.
* An Access Security Management Entity (ASME) is an entity which receives the top-level keys in an access network from the HSS. Kasme is bound to the serving network.