NextGen (5G) Security and Platform Integrity
Alec Brusilovsky
TCG TMS co-chair
1
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
2
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
3
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)
4
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
5
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.)
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
Virtualization security (ETSI NFV
SEC)
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
• 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).
Security assurance
Energy-efficient security
• Most constrained, and batterydependent 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
•
•
•
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
6
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?)
7
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:
•
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 trust models
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
8
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
–
•
A well-designed, flexible security baseline, and assurance in the implementation of this
baseline will be more important than the number of security requirements
–
–
•
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
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
9
Thank you
alec.brusilovsky@interdigital.com
10
Backups
•
•
•
•
•
•
Need for Platform Integrity Problem Statement
Key Technologies from TCG
TCG Background Information
TCG Work Items
TCG Deliverables
Background Information on EPS Security
11
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)
12
TCG – Key Technologies
Platform security for NFV (boot, crash,
and runtime)
13
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 – 20-24 June 2016
14
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
15
TCG – Other Highlights
TCG Members Meeting in Edinburgh – 16-18 June 2015
• Keynote by Dr. Bilel Jamoussi, ITU-T TSB
• “Vision of Trust, Security, and Privacy in Future ICT”
TCG Members Meeting in Montreal – 19-23 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 – 22-26 February 2016
• TCG Multiple Stakeholder Model – public review ended 15 Feb 2016
• Edit TCG Mobile Specs Implementation Guidance
• Edit TCG Runtime Integrity Maintenance
• Edit TCG Guidance for Securing Network Equipment
• Edit TCG Guidance for Securing Constrained IoT Devices
16
TCG – General Information
Trusted Computing Group (TCG)
http://www.trustedcomputinggroup.org/
• One of the foremost standards bodies focused on trusted computing
TCG Structure and Workgroups
http://www.trustedcomputinggroup.org/developers
TCG Members – 100+ vendors, governments, universities
http://www.trustedcomputinggroup.org/about_tcg/tcg_members
• 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…
17
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
18
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
• Status – work-in-progress – member/public review in Q2/Q3 2016
TMS Use Cases 2.0 – Enterprise, Financial, and NFV
• Scope – end-to-end mobile solutions for telecom / enterprise networks
• Status – work-in-progress – member/public review in Q2/Q3 2016
19
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
• Status – work-in-progress – member/public review in Q1/Q2 2016
20
TCG – Published deliverables
Trusted Platform Module (TPM) 2.0 Library – October 2014
http://www.trustedcomputinggroup.org/resources/tpm_library_specification
• Roots-of-trust, key creation/management, attestation, signatures, multifactor 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 2016
http://www.trustedcomputinggroup.org/resources/errata_for_tpm_library_specifi
cation_20
TCG Algorithm Registry 1.22 – February 2015
http://www.trustedcomputinggroup.org/resources/tcg_algorithm_registry
• RSA, ECC Curves, Hash Algorithms, Symmetric Ciphers, etc.
21
TCG – Published deliverables
A Practical Guide to TPM 2.0 – February 2015
http://www.trustedcomputinggroup.org/resources/a_practical_guide_to_tpm_20
http://www.apress.com/9781430265832
• 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 5793
http://www.trustedcomputinggroup.org/resources/tnc_iftnccs_specification
• Posture Broker – endpoint integrity measurement (IETF NEA PB-TNC)
TNC IF-M TLV Binding 1.0 – May 2014 – also RFC 5792
http://www.trustedcomputinggroup.org/resources/tnc_ifm_tlv_binding_specification
• Posture Attribute – endpoint standard attributes (IETF NEA PA-TNC)
TNC IT-T TLS Binding 2.0 – February 2013 – also RFC 6876
http://www.trustedcomputinggroup.org/resources/tnc_ift_binding_to_tls
• Posture Transport – endpoint attribute transport (IETF NEA PT-TLS)
22
TCG – Published deliverables
TPM 2.0 Mobile Common Profile – December 2015
http://www.trustedcomputinggroup.org/resources/tcg_tpm_20_mobile_common_profile
• Profile of TPM 2.0 for smartphones, feature phones, and basic phones
TPM 2.0 Mobile CRB Interface – February 2015
http://www.trustedcomputinggroup.org/resources/tpm_20_mobile_command_response_buf
fer_interface_specification
• OS and hardware independent TPM driver interface
TPM 2.0 Mobile Reference Architecture – December 2014
http://www.trustedcomputinggroup.org/resources/tpm_20_mobile_reference_architecture_s
pecification
• Secure boot, measured boot, protected environment, security
requirements, and implementation examples for all mobile devices
TMS Use Cases – Bring Your Own Device – October 2013
http://www.trustedcomputinggroup.org/resources/tms_use_cases__bring_your_own_device
_byod
• Mobile phone use case input to TPM 2.0 Mobile Reference Architecture
23
TCG – Published deliverables
Storage Architecture Core Spec 2.01 – August 2015
http://www.trustedcomputinggroup.org/resources/tcg_storage_architecture_core_spec
ification
• Comprehensive architecture for putting selected features of Storage
Devices under policy-driven access control
Storage Security Subsystem: Opal 2.01 – August 2015
http://www.trustedcomputinggroup.org/resources/storage_work_group_storage_securi
ty_subsystem_class_opal
• Core specification for Opal self-encrypting drives (desktops/laptops)
Storage Security Subsystem: Enterprise 1.01 – August 2015
http://www.trustedcomputinggroup.org/resources/storage_work_group_storage_securi
ty_subsystem_class_enterprise_specification
• Core specification for enterprise self-encrypting drives (servers)
24
UMTS AKA – foundation of EPS AKA
UE
USIM
VLR/SGSN
(MME)
Register
ME
1
IMSI
2
HLR/AuC
(HSS)
Compute
“quintuplets”
Authentication
data request
Auth. Vectors
1. Check if SQN
is in the range
2. Compute RES,
CK, IK or KASME
RAND, AUTN
RAND, AUTN
5
6
RES, IK, CK
or KASME
RES
7
AuC – Authentication Center
AUTH – Authentication vector (quintuplet)
AUTN – Authentication Token
CK –
Ciphering Key
HLR – Home location Register
IK –
Integrity Key
{RAND, AUTN, XRES, CK, IK}
3 {RAND, AUTN, XRES, K
ASME}
4
Validate
RES = XRES
Select CK, IK
or KASME
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
25
Security Layers in EUTRAN
Security layer
1
Security layer
eNB
2
S 1- C
S 1 -U
Xu
X2
UE
S 1- C
S 1 -U
Xu
MME
SAE GW
Evolved Packet Core
( EPC )
eNB
Security layer
1
E - UTRAN
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).
26
EPS AKA run and key change/derivation
(handover keys are omitted)
Result of
the AKA
run
USIM / AuC
K
K_eNB key is
transported to the
eNB from the EPC
when the UE
transitions to
LTE_ACTIVE
CK, IK
UE / HSS
K_ASME is
derived
from
CK&IK.
It never
leaves the
EPC
KASME
UE
/ ASME
UE/ASME
KNAS enc
KNAS int
eNB derives the
UP and RRC
keys from
K_eNB
KeNB
UE / MME
KeNB-UP-enc
KeNB-RRC- int
KeNB-RRC-enc
UE / eNB
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.
27