Hardware-Rooted Security in Mobile Devices

1. Hardware-Rooted Security in Mobile Devices Andrew Regenscheid Lead, Hardware-Rooted Security Computer Security Division

2. About NIST • NIST's Mission Statement:To promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life. • Information Technology Laboratory Mission Statement:To promote US innovation and industrial competitiveness by advancing measurement science, standards, and technology through research and development in information technology, mathematics, and statistics. • CSD Mission Statement:Conduct research, development and outreach necessary to provide standards and guidelines, mechanisms, tools, metrics and practices to protect our nation’s information and information systems. ● Computer Security Division ●

3. Disclaimer Certain commercial entities, equipment, or materials may be identified in this presentation in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. ● Computer Security Division ●

4. Mobility • Mobile technologies have potential to: • Improve productivity • Facilitate teleworking • Provide mobile workforce access to data anytime/anywhere • Digital Government Strategy recognizes this potential and the unique security and privacy challenges ● Computer Security Division ●

5. NIST Standards and Guidelines Key NIST standards and guidelines relevant to mobile security: • SP800-53, Recommended Security Controls for Federal Information Systems and Organizations • Cryptographic Modules and Algorithms • SP800-124rev1, Guidelines for Managing and Securing Mobile Devices in the Enterprise • FIPS 201-2, Personal Identity Verification of Federal Employees and Contractors • NIST SP800-157, Guidelines on Derived PIV Credentials • Upcoming Mobile App Vetting Guidelines ● Computer Security Division ●

6. Technology Gaps • Key security functions were not rooted in trustworthy, well-protected components • Data protection capabilities varied greatly by platform • Need stronger mechanisms for maintaining data and application separation • Current MDM solutions provide limited insight into security state of a device ● Computer Security Division ●

7. BYOD ● Computer Security Division ●

8. Information Owners & Contexts ● Computer Security Division ●

9. Mobile Device Security • NIST SP800-164, Guidelines on Hardware-Rooted Security In Mobile Devices • Focus on three key capabilities: • Device Integrity: Software, firmware, and hardware configurations are in a trusted state • Isolation:Sandbox apps and separate data to control information and confine vulnerabilities • Protected Storage: Protect confidentiality and integrity of sensitive data on the device ● Computer Security Division ●

10. What is a Root of Trust? • A root of trust (RoT) is a set of hardware, firmware, and/or software that is inherently trusted to perform a vital security function. • Key Storage  RoT for Storage • Health Assertions  RoT for Integrity • Digital Signing  RoT for Reporting • Signature Verification  RoT for Verification • Hashing Code  RoT for Measurement • RoTs are closely tied to the logic and environment on which it performs its trusted actions. ● Computer Security Division ●

11. Trust Chains Verify Verify • A RoT may directly provide a function, or verifiably and reliably spawn agents that provide that function. • The RoT is (generally) the smallest distinguishable component that must be inherently trusted. • Complicates discussions over RoT definitions • Discussions over the “fundamental” RoTs quickly devolve to metaphysics. • For clarify, we’ll identify RoTs based on the security function they provide with no implications on implementation. Component-2 Component-1 Root of Trust Execute Execute ● Computer Security Division ●

12. Properties of Roots of Trust • By definition, misbehavior of a RoTcannot be detected, so it must be secure by design • Desirable properties: • Resistance to software-based and physical tampering • Isolated and trusted operating environment • Small, simple implementation • Limited interface with small attack surface • Hardware support can help provide these properties ● Computer Security Division ●

13. Examples of RoTs • Trusted Platform Modules (TPM) • RoT for Storage • RoT for Integrity • RoT for Reporting • System BIOS/boot firmware • RoT for Measurement • RoT for Verification • Hardware AES engine in Chipsets • RoT for Storage ● Computer Security Division ●

14. Foundation for Security • App App App App Operating System Isolation Device Integrity Protected Storage Security Capabilities RoT forReporting RoT for Integrity Roots of Trust RoT for Measurement RoT for Verification RoT for Storage ● Computer Security Division ●

15. Device Integrity • Devices must provide information regarding source, authenticity, and version of firmware and OS. • Verified boot required through OS and PEnE • Support for device integrity policies • Apps verified at install, and should be verified at launch • Assertions • Recommended, but not required • Highly-flexible, robust model for device integrity • May appear in future revisions ● Computer Security Division ●

16. Protected Storage • Keys (and credentials, etc.) stored in RTS or protected by key hierarchies rooted in RTS • Section provides basic requirements for generating, storing, and using keys • Must support authentication factors to govern release/use of a key • Must allow IOs to creates policies governing release/use of a key ● Computer Security Division ●

17. Isolation • Data isolation at rest expected to accomplished through protected storage services • Emphasis is on runtime application/process isolation • Based on best commercial practices • Section provides a low bar that we hope will be exceeded ● Computer Security Division ●

18. Policy Enforcement • Supports organizations’ security policy requirements • The “device-side” of MDM • PEnE broken into 3 logical components: • Policy Delivery Mechanism • Policy Management Mechanism • Policy Enforcement Mechanism • Policies must be: • Protected in transit, storage • Verified and associated with an IO • Enforced according to the most restrictive policy • Device Owner retains control ● Computer Security Division ●

19. Notional Architecture ● Computer Security Division ●

20. RoT as Enabling Technologies • Roots of Trust can enable new security capabilities and use cases • Examples: • BYOD • Comply-to-Connect • Data Protection • Derived Credentials ● Computer Security Division ●

21. Data Protection • An organization must encrypt sensitive data stored on a mobile device. • Data at Rest: An application could use Root of Trust for Storage to securely store the encryption key. To use the key: • The device could be required to be in a known-good state. • Root of Trust for Storage could require a passcode/PIN. • Data in Transit: RTS could also store VPN credentials. • Selective Wipe: If a device is lost, an MDM could instruct the RTS to delete the encryption key. ● Computer Security Division ●

22. Derived Credentials • Use PIV to authorize a derived credential for mobile devices. • Protect and use credential using RoTs Mobile Device • Provisioning Actions • Protocol App Mobile Device Manager PIV Card • API RoT Reporting RoT Storage Derived Credential ● Computer Security Division ●

23. Adoption • Roots of Trust are being deployed in mobile devices • R&D activities on-going in some technologies: • TPMs in current/upcoming mobile phones/tablets • GlobalPlatform Trusted Execution Environment • Secure Element • ARM TrustZone • More granular policy enforcement in MDMs ● Computer Security Division ●

24. Next Steps • We received ~200 comments from ~30 commenters • Recurrent themes • Concerns over architectural specificity • Questions on its relationship to GP TEE and TrustZone • Concerns over remote attestation • Updated draft in coming weeks ● Computer Security Division ●

25. More Information Contact Information Andrew Regenscheid Andrew.Regenscheid@nist.gov Andrew.R@nist.gov Draft SP800-164 and other NIST security publications available at: csrc.nist.gov

26. ● Computer Security Division ●