Mobile Trusted Computing
Total Page:16
File Type:pdf, Size:1020Kb
Mobile Trusted Computing Fruct 2011 7.11 2011 Jan-Erik Ekberg Partly joint work with N.Asokan, K Kostiainen, E Reshtova Platform Security applications • To achieve secure processing in heterogenous environments, trust roots are needed • Without enforcement, guarantees are hard to give • A good security infrastructure leaves room for Open OS with un-trusted components without sacrificing OS MAC overall security • Compared to perimeter security, the trusted computing base is minimized Secure execution • Software vulnerability analysis is still an environment for integral part of the system, but not at run-time, credentials security is achieved by “updates only”. • Privacy needs to be also guaranteed by policy, not just by mechanism. This is common-place, e.g. in HW support communication networks. - integrity - secure storage - secure processing - isolated memories? 4 © 2010 Nokia ETISS 2010.ppt / J-EE Enforcement mechanisms have a history • Hardware-support for platform security −Cambridge CAP etc. (~1970s) / Multics Extended to Trusted Execution Environments HW • Hardware-assisted secure storage • Secure and authenticated boot −TCPA and TCG (late 1990s) HW +OS −Academic research projects (mid 1990s) Extended (private secure storage for applications) Adapted (normal vs. developer mode in MSSF) • Permission-based platform security architectures −VAX /VMS privileges for user (~1970s) OS Adapted for applications −Code signing (mid 1990s) Borrowed for application installation 5 © 2010 Nokia ETISS 2010.ppt / J-EE HW Enablers / ASIC support (high-level view) Hardware support for platform security Public key E.g., 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 7 Nokia Research Center 2011 Secure bootstrapping Code certificate Boot code hash Validate and Trust root execute Crypto Library Boot sequence Secure boot (ROM) Ensure only authorized boot TCB for platform software image can be loaded Launch platform boot code 8 Nokia Research Center 2011 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 9 Nokia Research Center 2011 Trusted execution Identity certificate Code certificate Boot code hash Base identity Validate and execute Assigned identity Code certificate TrEE code hash Isolated execution Trust root Base identity TrEE Basis for secure Crypto Library Device key external storage Boot sequence TrEE code Secure boot (ROM) TCB for platform software Launch platform boot code TrEE API 10 Nokia Research Center 2011 Authorized code execution, isolated from the OS Secure state Identity certificate Code certificate Base identity Boot code hash Assigned identity Code certificate Securing TrEE sessions, TrEE code hash authenticated boot Trust root Base identity Configuration TrEE register(s) Crypto Library Device key Non-vol. memory TrEE code or Boot sequence counter Secure boot (ROM) TCB for platform software Rollback protection for persistent secure storage Launch platform boot code TrEE API 11 Nokia Research Center 2011 Integrity-protected state within the TrEE Device authentication, secure provisioning, Device authentication attestation External trust root Identity certificate Code certificate Boot code hash Base identity Device certificate Assigned identity Code certificate Identity TrEE code hash Public device key Trust root Base identity Configuration TrEE register(s) Crypto Library Device key Non-vol. memory TrEE code or Boot sequence counter Secure boot (ROM) TCB for platform software Launch platform boot code TrEE API 12 Nokia Research Center 2011 Prove device identity or properties to external verifier Summary of hardware mechanisms • Secure boot: Ensure only authorized boot image can be loaded • Authenticated boot: Measure and remember loaded image • Identity binding: Securely assign identities to the device • Secure storage: Protect confidentiality and integrity of data • Isolated execution: Run authorized code isolated from OS • Device authentication: Prove device identity to external verifier • Remote attestation: Prove device configuration to verifier 13 Nokia Research Center 2011 Hardware security architectures (mobile) • TI M-Shield and ARM TrustZone • Augments central processing unit −“Secure processor mode” • Isolated execution with on-chip RAM −Very limited (<10kB) • Secure storage −Typically with write-once E-fuses • Usually no counters or non-volatile memory −Cost issue 14 Nokia Research Center 2011 Hardware security architectures (TCG) • Trusted Platform Module (TPM) −Standalone processor on PCs −Isolated execution for pre-defined algorithms −Arbitrary isolated execution with DRTM −Platform Configuration Registers (PCRs) −Monotonic counters • Mobile Trusted Module (MTM) −Mobile variant of TPM −Can be implemented using e.g. TrustZone or M-Shield −Discussed further… 15 Nokia Research Center 2011 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? 16 Nokia Research Center 2011 SW/OS support Adoption of security mechanisms Operators Regulators End users ~2002 Hardware-based mechanisms ~2001 ~2005 ~2008 ~2010 ~2011 18 Nokia Research Center 2011 Software-based mechanisms Open mobile platforms • Java ME ~2001 • Android ~2007 −For “feature phones” −Linux-based OS −3 billion devices! −App development in Java −Not any more supported by the latest smartphones • MeeGo ~2010 −Linux-based OS • Symbian ~2004 −App development in C (Qt) −First “smartphone” OS −MSSF −App development in C++ (Qt) • Windows Phone ~2010 −Windows (CE) based kernel − End-user app development in Silverlight / .NET 19 Nokia Research Center 2011 Mobile platform security model • 3.5 phases 1. Distribution 2. Installation 3. Run-time enforcement 4. ++ off-line enforcement • Common techniques −Code signing −Permission-based access control architecture − (User involvement in assigning permissions) − App R&D by local “installation” / “opened device” 20 Nokia Research Center 2011 Distribution Software package • Developer produces a software package −Code −Manifest • May submit to a signer for a Developer trusted signature Signed • Distributed to device via on-line software stores (typically) package Software package 21 Nokia Research Center 2011 Installation Software Signed software package package • Installer consults local policy and trusted signature − Identify application − Grant requested privileges • Installer may prompt user Installer Policy 22 Nokia Research Center 2011 Run-time enforcement • Monitor checks if subject has privileges for requested access Monitor resource • Resource may perform principal additional checks • User may be prompted to authorize access 23 Nokia Research Center 2011 1. OS bootstrapping Is hardware security used to secure OS bootstrapping? Symbian Java ME Android MSSF Windows Phone Secure Not No? Authenticated boot: “Normal No? boot applicable mode” vs “Developer mode” 24 Nokia Research Center 2011 2. Application identification How are applications identified at install and runtime? Symbian Java ME Android MSSF Windows Phone Install and run- Install: Install: Install: Install: time: • Signing key • Signing key • Software • Software • Protected • Midlet source source range SID and attributes Runtime: (signing key) VID • Unix UID • Package No IPC between (managed) • Package name installed • UID name (locally applications (unmanaged) unique) Runtime: • Software source • Package name 25 Nokia Research Center 2011 • Application ID 3. Application update How is a new version of an existing application verified? Symbian Java ME Android MSSF Protected SID, VID: Signed midlets: “Same origin” policy “Same or higher • trusted signature • same-origin policy origin” policy Rest: Unsigned midlets: • no controls • user prompt 26 Nokia Research Center 2011 4. Permission granularity How finely is access control defined? Symbian Java ME Android MSSF Windows Phone Fixed set of Fine-grained Fine-grained Fine-grained Fixed set “capabilities” permissions permissions resource-tokens of capabilities (21) (many) (112) (8++) Linux access Four Linux access control “chambers” control Android and MSSF: Each application is installed under a separate Linux UID 27 Nokia Research Center 2011 5. Permission assignment (basis) Least Privilege Chamber Standard Rights Basis for granting permissions? Elevated Rights Trusted Computing Base Symbian Java ME Android MSSF Windows Phone 4 categories Trusted 4 Trusted signatures Chambers map signatures for protection to stakeholders Trusted protection levels Local policy file (MS / OEM / signature (also domains operator / user) user prompts) 4 permission Capabilities defined modes by developer (least- privilege prot.) User Blanket, System, Session, Normal (automatic) Restricted, One-shot, Dangerous (user-granted) Manufacturer No Signature (developer-controlled) 28 Nokia Research Center 2011 SystemOrSignature (Google-controlled) 6. Permission assignment (user prompting) Symbian Java ME Android Windows Phone Capability Function group Permission group Capability description description