Hardware-Rooted Security in Mobile Devices
Andrew Regenscheid
Lead, Hardware-Rooted Security
Computer Security Division
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 ●
6/3/2013
Slide 2
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 ●
6/3/2013
Slide 3
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 ●
6/3/2013
Slide 4
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/3/2013
Slide 5
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 ●
6/3/2013
Slide 6
BYOD
● Computer Security Division ●
6/3/2013
Slide 7
Information Owners & Contexts
● Computer Security Division ●
6/3/2013
Slide 8
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 ●
6/3/2013
Slide 9
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 ●
6/3/2013
Slide 10
Trust Chains
Verify
Verify
Root of
Trust
Component-2
Component-1
Execut
e
Execut
e
• 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.
● Computer Security Division ●
6/3/2013
Slide 11
Properties of Roots of Trust
• By definition, misbehavior of a RoT cannot 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 ●
6/3/2013
Slide 12
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 ●
6/3/2013
Slide 13
Foundation for Security
App
App
App
App
Operating System
Security
Capabilities
Roots of
Trust
Protected
Storage
Isolation
Device
Integrity
RoT for
RoT for
Reporting
Integrity
RoT for
RoT for
RoT for
Storage
Verification
Measurement
● Computer Security Division ●
6/3/2013
Slide 14
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 ●
6/3/2013
Slide 15
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 ●
6/3/2013
Slide 16
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 ●
6/3/2013
Slide 17
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 ●
6/3/2013
Slide 18
Notional Architecture
● Computer Security Division ●
6/3/2013
Slide 19
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 ●
6/3/2013
Slide 20
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 ●
6/3/2013
Slide 21
Derived Credentials
• Use PIV to authorize a derived credential for mobile
devices.
• Protect and use credential using RoTs
Mobile Device
Provisioning Actions
Protocol
App
API
RoT
Reporting
Mobile
Device
Manager
PIV
Card
RoT
Storage
Derived Credential
● Computer Security Division ●
6/3/2013
Slide 22
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 ●
6/3/2013
Slide 23
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 ●
6/3/2013
Slide 24
More Information
Draft SP800-164 and other NIST security
publications available at:
csrc.nist.gov
Contact Information
Andrew Regenscheid
Andrew.Regenscheid@nist.gov
Andrew.R@nist.gov
● Computer Security Division ●
10/15/2012
Slide 26