doc.: IEEE /0152r0 Submission November 2010 Alex Reznik, et. al. (InterDigital)Slide 1 Device Security Standards Overview Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Date: Authors:

doc.: IEEE /0152r0 Submission Abstract Follow-up to presentation at the last meeting Provide an overview of what other SDOs are doing in this area Propose a way for to proceed on this topic Alex Reznik, et. al. (InterDigital)Slide 2 November 2010

doc.: IEEE /0152r0 Submission General Standardization Approach Early ‘solution’ specifications are emerging –Trusted Computing Group (TCG) Recognized leader SDO in defining device security solutions (for all of the computing market, not just the mobile market) –Trusted Mobile Phone (MPWG) Specs –Trusted Network Connect (TNC) Specs. –3GPP Rel-9 Technical Report (TR ) and Rel-10 Technical Spec (TS33.320) on H(e)NB Security 3GPP Rel-8 Technical Report (TR ) on M2M Remote Subscription Management. –OMTP (Open Mobile Terminal Platform) Industry-leading SDO defining specification for secure mobile terminals (but not interoperability) Trusted Environment: TR 0 (approved 2008) –Requirements for Debug-port protection, Mobile Device ID, SIMLock and ME personalization, DRM requirements, Secure Boot requirements, Secure binding (between USIM and ME), Secure FLASH update mechanisms Advanced Trusted Environment: TR1 Recommendations (approved 2010) –Identifies 7 “threat groups”: HW modules used for accessing memories, threats on displaying memories and displayed data, Bypassing of security by removal of battery power or external memory card, Attack by replacement of Flash when power is off (pre-boot), Extract secret by bus monitoring (HW probes), Mod chip attacks on data in external RAM, attack by replacement of FLASH when power is on (post-boot) –New, requirements Secure storage, Flexible Secure Boot, Generic Bootstrap Architecture, Runtime Integrity Checking (RTIC), Secure access to User Input/Output, Secure interaction between UICC and ME However, device security is proprietary in implementation and new from a standardization requirements perspective –Most existing SDO focus on ‘platform requirements’ rather than specific solutions –Minimal interoperability requirements are captured Support existing solutions Make sure the standard can evolve in the future –Manufacturers can implement proprietary solutions as long as they can Prove to users/operators that their solutions meet the standardized platform requirements Support the standardized interoperability protocols, including device security support November 2010 Alex Reznik, et. al. (InterDigital)Slide 3

doc.: IEEE /0152r0 Submission Example Device-Security Requirements - Adopted 3GPP Home(e)NB Security spec TS (approved 2009) –Specified device-security requirements –Section 5.1: Secure storage and execution; 5.1.2: Trusted Environment (TrE) The Trusted Environment (TrE) shall be a logical entity which provides a trustworthy environment for the execution of sensitive functions and the storage of sensitive data. All data produced through execution of functions within the TrE shall be unknowable to unauthorized external entities –Section 5.2: Device Mutual Authentication Device mutual authentication shall be performed using certificates. The H(e)NB’s credentials and critical security functions for device authentication shall be protected inside a TrE... –Section 6.1: (Boot-time) Device Integrity Check The H(e)NB and TrE shall perform a device integrity check upon booting and before connecting to the core network and/or to the H(e)MS. The device integrity check shall be based on one or more trusted reference value(s) and the TrE... –Section 7.1: (Implicit) Device Validation The H(e)NB shall support a device validation method where the device implicitly indicates its validity to the SeGW or H(e)MS by successful execution of device authentication..... If the device integrity check according to clause 6.1 failed, the TrE shall not give access to the sensitive functions using the private key needed for H(e)NB device authentication with the SeGW. November 2010 Alex Reznik, et. al. (InterDigital)Slide 4

doc.: IEEE /0152r0 Submission Example Device-Security Requirements –Adopted IEEE Draft 5.0 (… ok – almost adopted) –Enables the use of device security to enhance operation –Specifies how device security is to be used –Section 10: Configuration Tamper-proof mechanisms shall be implemented to prevent unauthorized modification to firmware and/or functionalities (e.g., MAC address, SM/SSA functionality, database service communication, RF sensing, DFS, TPC, tuning) that would allow device or network operation to violate either the specifications of the standard or the requirements of the local regulations. Any attempt to load unapproved firmware into an device shall render it inoperable. Measures for both local and remote attestation of authorized and approved hardware and software running on an device shall be implemented. Implementation of the Trusting Computing Group's Trusted Platform Module (TPM) Main Specification Level 2 Version 1.2 (Revision 103) [see TPM references in clause 2] shall be used to bind the hardware and software running on devices to a cryptographic key. –Annex F: Network Security Aspects –F.3: Authorization Only the authorized parties shall be allowed to configure the spectrum manager at the BS and the 1 spectrum automaton at the CPE Configuration information shall be identified and protected November 2010 Alex Reznik, et. al. (InterDigital)Slide 5

doc.: IEEE /0152r0 Submission Examples Device-Security Requirements – Studied 3GPP M2M remote subscription management TR (2009) –Device-security solutions Section 5.1: Candidate solution Alternative 1A using TRE-based remote subscription provisioning and change –5.1.2: Trusted Environment (TrE) – : Platform Validation Authority (PVA) – : (Network Interactions for MCIM provisioning in case of 3GPP access) Steps 12/13. platform validation of M2M equipment by PVA. –The PVA locally validates the authenticity and integrity of the M2ME, according to the requirements of the SHO… 3GPP H(e)NB security tech. report TR (approved 2009) –Studied device-security solutions Section 7.2.2: Trusted Environment Section 7.5: Device Integrity Check –7.5.2: H(e)NB Validation : Autonomous Validation : Remote Validation : Semi-autonomous Validation Section 7.12: H(e)NB Distress Indication The H(e)NB should be equipped with a distress communication function, the principal purpose of which is to facilitate transmission of a distress indication message to the network, in case the H(e)NB fails device integrity verification... November 2010 Alex Reznik, et. al. (InterDigital)Slide 6

doc.: IEEE /0152r0 Submission What Should Consider? Consistent with other SDOs, take a minimal approach –Platform requirements Out of scope for May consider an appendix stating potential/recommended secure platform requirements for CM/CE platforms –Minimal interoperability support In scope for Potential interoperability support –Device security capability Indicated as part of CE subscription with CM –Device Integrity Check result Explicit via signaling Implicit in certain operations (e.g. successful integrity check allows authentication to proceed) –Command compliance certification Explicit via signaling of certificates or tokens Implicit in the command acknowledgement whenever device is “device security capable” November 2010 Alex Reznik, et. al. (InterDigital)Slide 7