1 / 7

Device Security Standards Overview

Device Security Standards Overview. Authors:. Date: 2010-11-08.

gil
Download Presentation

Device Security Standards Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Device Security Standards Overview Authors: Date: 2010-11-08 Notice:This document has been prepared to assist IEEE 802.19. 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. Alex Reznik, et. al. (InterDigital)

  2. November 2010 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 802.19.1 to proceed on this topic Alex Reznik, et. al. (InterDigital)

  3. 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 33.820) and Rel-10 Technical Spec (TS33.320) on H(e)NB Security • 3GPP Rel-8 Technical Report (TR 33.812) 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 Alex Reznik, et. al. (InterDigital)

  4. Example Device-Security Requirements - Adopted • 3GPP Home(e)NB Security spec TS 33.220 (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. Alex Reznik, et. al. (InterDigital)

  5. Example Device-Security Requirements –Adopted • IEEE 802.22 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 802.22 standard or the requirements of the local regulations. Any attempt to load unapproved firmware into an 802.22 device shall render it inoperable. Measures for both local and remote attestation of authorized and approved hardware and software running on an 802.22 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 802.22 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 Alex Reznik, et. al. (InterDigital)

  6. Examples Device-Security Requirements – Studied • 3GPP M2M remote subscription management TR33.812 (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) • 5.1.3.5.8: Platform Validation Authority (PVA) • 5.1.3.6.3: (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 33.820 (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 • 7.5.2.2: Autonomous Validation • 7.5.2.3: Remote Validation • 7.5.2.4: 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 ... Alex Reznik, et. al. (InterDigital)

  7. What Should 802.19.1 Consider? • Consistent with other SDOs, take a minimal approach • Platform requirements • Out of scope for 802.19.1 • May consider an appendix stating potential/recommended secure platform requirements for CM/CE platforms • Minimal interoperability support • In scope for 802.19.1 • 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” Alex Reznik, et. al. (InterDigital)

More Related