Mobile Platform Security Architectures a Perspective on Their Evolution

Mobile Platform Security Architectures a Perspective on Their Evolution

Mobile Platform Security Architectures A perspective on their evolution N. Asokan Kari Kostiainen 1 NA, KKo, JEE, Nokia Resarch Center 2011-2012 Introduction Recent interest in smartphone security 2 NA, KKo, JEE, Nokia Resarch Center 2011-2012 Jan 2011? Introduction Recent interest in smartphone security 3 Oct 2012 Introduction Securing smartphone application platforms: challenges Smartphones “Feature phones” PCs Open software platforms Third party software Java ME Internet connectivity Packet data, WiFi Personal data Location, contacts, communication log Risk of monetary loss ? Premium calls Is smartphone platform security different? 4 Outline Outline • A bit of background on requirements for securing mobile phones • Basics on hardware security enablers • Comparison of modern mobile (software) platform security architectures • Discussion: open issues and summary 5 Background 6 Background Platform security requirements for mobile phones Mobile network operators; Regulators; 1. Subsidy locks immutable ID 1. RF type approval secure storage 2. Copy protection device 2. Theft deterrence immutable ID authentication, app. separation 3. … 3. … End users; 1. Reliability app. separation 2. Theft deterrence immutable ID 3. Privacy app. separation Closed Open 4. … Different Expectations compared to the PC world 7 Background Early adoption of hardware and software security GSM 02.09, 1993 3GPP TS 42.009, 2001 Different starting points: widespread use of hardware and software platform security ~2001 ~2002 ~2005 ~2008 8 Hardware security enablers 9 Hardware security Hardware support for platform security E.g., Public key serial hash number Trust root Base identity Crypto Library Start of boot code Boot sequence (ROM) Basic elements in TCB for platform software immutable storage 10 Hardware security Secure bootstrapping Code certificate Boot code hash Validate and Trust root Base identity execute Crypto Library Boot sequence Secure boot (ROM) Ensure only authorized boot TCB for platform software image can be loaded Launch platform boot code 11 Hardware security Identity binding Identity certificate Code certificate Base identity Boot code hash Assigned identity E.g., IMEI, link-layer addresses, … Trust root Base identity Validate and accept Crypto Library assigned ID Boot sequence (ROM) Secure boot Securely assign different TCB for platform software identities to the device Launch platform boot code 12 Hardware security Trusted execution environment (TEE) Identity certificate Code certificate Boot code hash Base identity Validate and execute Assigned identity Code certificate TEE code hash Isolated Why?How? execution Trust root Base identity TEE Basis for secure Crypto Library Device key external storage Boot sequence TEE code Secure boot (ROM) TCB for platform software Launch platform boot code TEE API Authorized13 execution of arbitrary code, isolated from the OS; access to device key Hardware security Secure state Identity certificate Code certificate Base identity Boot code hash Assigned identity Code certificate TEE code hash Authenticated boot Trust root Base identity Configuration TEE register(s) Crypto Library Device key Boot sequence TEE code Secure boot (ROM) TCB for platform software Launch platform boot code TEE API 14 Hardware security Secure boot vs Authenticated boot … … OS Kernel checker pass/fail OS Kernel measurer Boot block checker pass/fail Boot block measurer Boot seq. checker pass/fail Boot seq. measurer state Trust root TCB TCB Root of Trust for measurement 15 Hardware security Secure state Identity certificate Code certificate Base identity Boot code hash Assigned identity Code certificate Authenticated boot, Securing TEE code hash TEE sessions Why?How? Trust root Base identity Configuration TEE register(s) Crypto Library Device key Non-vol. memory TEE code or Boot sequence counter Secure boot (ROM) TCB for platform software Rollback protection for persistent secure storage Launch platform boot code TEE API 16 Integrity-protected state within the TEE Hardware security Device authentication External trust root Identity certificate Code certificate Boot code hash Base identity Device certificate Assigned identity Code certificate Identity TEE code hash Public device key Device authentication, secure provisioning, Trust root Base identity Configuration TEE attestation register(s) Crypto Library Device key Non-vol. memory TEE code or Boot sequence counter Secure boot (ROM) TCB for platform software Launch platform boot code TEE API 17 Prove device identity or properties to external verifier Hardware security Hardware platform security features: summary • Secure boot: Ensure only authorized boot image can be loaded • Authenticated boot: Measure and remember what boot image was loaded • Identity binding: Securely assign different identities to the device • Secure storage: protect confidentiality/integrity of persistent data • Isolated execution: Run authorized code isolated from the device OS • Device authentication: Prove device identity to external verifier • Remote attestation: Prove device configuration/properties to external verifier 18 Hardware security Architectural options for realizing TEEs External External External Memories Memories Memories Crypto On-SoC Crypto On-SoC Crypto On-SoC RAM Accelerators RAM Accelerators RAM Accelerators Processor Processor Processor core(s) core(s) core(s) ROM Peripherals ROM Peripherals ROM Peripherals OTP Fields OTP Fields OTP Fields On-chip Security Subsystem External Security Co-processor External Secure Element Embedded Secure Element Processor Secure Environment TEE component 19 Figures taken from “GlobalPlatform Device Technology, TEE System Architecture”, Version 1.0, December 2011 Hardware security Hardware security architectures (mobile) ARM TrustZone and TI M-Shield • Augments central processing unit: “Secure processor mode” • Isolated execution with on-chip RAM: Very limited (<20kB) • Secure storage: Typically with write-once E-fuses • Usually no counters or non-volatile memory: Cost issue Processor Secure Environment 20 Hardware security Hardware security architectures (TCG) • Trusted Platform Module (TPM) −Standalone processor on PCs −Isolated execution for pre-defined algorithms −Arbitrary isolated execution with DRTM (“late launch”) −Platform Configuration Registers (PCRs) −Monotonic counters External Secure Element • Mobile Trusted Module (MTM) −Mobile variant of TPM −Defines interface −Implementation alternatives: TrustZone, M-Shield, software 21 Hardware security Uses of hardware security • Recap from features −Secure/authenticated boot −Identity binding/device authentication −Secure storage −Remote attestation • Uses of hardware security (device manufacturer) −Device initialization −DRM −Subsidy lock • How can developers make use of hardware security? −an example in the second part of this seminar 22 Software platform security 23 Software Platform security Open mobile platforms • Java ME ~2001 • Android ~2007 −For “feature phones” −Linux-based OS −3 billion devices! −App development in Java −Not supported by most smartphone platforms • MeeGo ~2010 −Linux-based OS • Symbian ~2004 −App development in C++ (Qt) −First “smartphone” OS −MSSF (Intel Tizen) −App development in C++ (Qt) • Windows Phone ~2010 −App development in .NET 24 Software Platform security Mobile platform security model • Common techniques −Application signing −Permission-based access control architecture −Application isolation • Common operations 1. Permission request 2. Application signing 3. Application installation 4. Application loading 5. Run-time access control enforcement 25 Step 1: Developer publishes an application Software Platform security Developer Developer requests permissions for his application Developer submits the application to a centralized marketplace Centralized Auxiliary Some platforms marketplace marketplaces support auxiliary In some platforms the marketplaces application can be directly pushed to the mobile device Mobile device TCB 26 Step 2: Marketplace signs the application Software Platform security Developer In some platforms the developer signs the application Marketplace provider checks the application (and Centralized Auxiliary requested permissions) and marketplace marketplaces signs it Mobile device TCB 27 Step 3: Application installation Software Platform security Installer may request the Developer user to accept some of the requested permissions User Centralized Auxiliary marketplace marketplaces Mobile device receives an application installation package from a marketplace (or developer) Mobile device Installer consults local After these checks, the policy database about installer assigns these TCB requested permissions permissions to the application Application Policy permission Application Installer database database Installer stores Installer checks application application signature and permissions Secure Platform requested storage integrity integrity permissions Permission and policy Application installer databases need integrity component needs integrity 28 protection protection Step 4: Application loading Software Platform security Developer User Centralized Auxiliary marketplace marketplaces Mobile device Loader attaches permissions to the Application started process TCB Application Policy permission Application loader Application Installer database database Loader reads permissions from the permission database Secure Platform storage integrity integrity Also loader component 29 needs integrity protection Step 5: Application execution

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    48 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us