270 likes | 291 Views
NextGen (5G) Security and Platform Integrity Alec Brusilovsky TCG TMS co-chair. Agenda. 5G Capabilities to Drive 5G Security Network Slicing Current 3GPP security constraints 5G Security - Core A reas 5G Opportunity Areas 5G Security – Design Assumptions
E N D
NextGen (5G) Security and Platform IntegrityAlec BrusilovskyTCG TMS co-chair
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
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
5G Network Slicing • 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) • 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
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
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
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?)
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
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 • Awell-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
Thank you alec.brusilovsky@interdigital.com
Backups Need for Platform Integrity Problem Statement Key Technologies from TCG TCG Background Information TCG Work Items TCG Deliverables Background Information on EPS Security
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)
TCG – Key Technologies Platform security for NFV (boot, crash, and runtime)
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 • Futuremeetings • TCG Members Meeting in Vienna, Austria – 20-24 June 2016
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
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
TCG – General Information • Trusted Computing Group (TCG)http://www.trustedcomputinggroup.org/ • One of the foremost standards bodies focused on trusted computing • TCG Structure and Workgroupshttp://www.trustedcomputinggroup.org/developers • TCG Members – 100+ vendors, governments, universitieshttp://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…
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
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
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
TCG – Published deliverables • Trusted Platform Module (TPM) 2.0 Library – October 2014http://www.trustedcomputinggroup.org/resources/tpm_library_specification • 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 2016http://www.trustedcomputinggroup.org/resources/errata_for_tpm_library_specification_20 • TCG Algorithm Registry 1.22 – February 2015http://www.trustedcomputinggroup.org/resources/tcg_algorithm_registry • RSA, ECC Curves, Hash Algorithms, Symmetric Ciphers, etc.
TCG – Published deliverables • A Practical Guide to TPM 2.0 – February 2015http://www.trustedcomputinggroup.org/resources/a_practical_guide_to_tpm_20http://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 5793http://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 5792http://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 6876http://www.trustedcomputinggroup.org/resources/tnc_ift_binding_to_tls • Posture Transport – endpoint attribute transport (IETF NEA PT-TLS)
TCG – Published deliverables • TPM 2.0 Mobile Common Profile – December 2015http://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 2015http://www.trustedcomputinggroup.org/resources/tpm_20_mobile_command_response_buffer_interface_specification • OS and hardware independent TPM driver interface • TPM 2.0 Mobile Reference Architecture – December 2014http://www.trustedcomputinggroup.org/resources/tpm_20_mobile_reference_architecture_specification • 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
TCG – Published deliverables • Storage Architecture Core Spec 2.01 – August 2015http://www.trustedcomputinggroup.org/resources/tcg_storage_architecture_core_specification • Comprehensive architecture for putting selected features of Storage Devices under policy-driven access control • Storage Security Subsystem: Opal 2.01 – August 2015http://www.trustedcomputinggroup.org/resources/storage_work_group_storage_security_subsystem_class_opal • Core specification for Opal self-encrypting drives (desktops/laptops) • Storage Security Subsystem: Enterprise 1.01 – August 2015http://www.trustedcomputinggroup.org/resources/storage_work_group_storage_security_subsystem_class_enterprise_specification • Core specification for enterprise self-encrypting drives (servers)
6 • 2 • 7 • 3 • 4 • 5 • 1 UMTS AKA – foundation of EPS AKA • UE • USIM • ME • VLR/SGSN • (MME) • HLR/AuC • (HSS) • Compute “quintuplets” • Register • Authentication • IMSI • data request • Auth. Vectors • {RAND, AUTN, XRES, CK, IK} • {RAND, AUTN, XRES, KASME} • RAND, AUTN • 1. Check if SQN is in the range • 2. Compute RES, CK, IK or KASME • RAND, AUTN • Validate • RES = XRES • Select CK, IK or KASME • RES, IK, CK or KASME • RES • 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 • AuC – Authentication Center • AUTH – Authentication vector (quintuplet) • AUTN – Authentication Token • CK – Ciphering Key • HLR – Home location Register • IK – Integrity Key
Security layer 1 Security layer 2 eNB S 1 - C MME S 1 - U Xu SAE GW X 2 UE S 1 - C S 1 - U Evolved Packet Core Xu ( EPC ) eNB Security layer 1 E - UTRAN Security Layers in EUTRAN 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).
EPS AKA run and key change/derivation (handover keys are omitted) K_eNB key is transported to the eNB from the EPC when the UE transitions to LTE_ACTIVE Result of the AKA run K_ASME is derived from CK&IK. It never leaves the EPC UE/ASME eNB derives the UP and RRC keys from K_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.