Download A Perspective on the Evolution of Mobile Platform Security

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Transcript
A Perspective on the Evolution of Mobile
Platform Security Architectures
Kari Kostiainen
Nokia Research Center, Helsinki
TIW, June 2011
Joint work with N. Asokan, Jan-Erik Ekberg and Elena Reshetova
1
Nokia Research Center 2011
Introduction
Recent interest on “smartphone security”…
Smartphones
“Feature phones”
PCs
Open software platforms
Yes (Java Me)
Yes
Internet connectivity
Yes
Yes
Personal data
Yes
Yes
Risk of monetary loss
Yes
?
Third party software
Packet data, WiFi
Location, contacts, communication log
Premium calls
Is smartphone platform security different?
2
Nokia Research Center 2011
Outline
• Background and requirements for smartphone security
• Basics on hardware security enablers
• Comparison of modern mobile (software) platform
security architectures
• Discussion: open issues, applications and summary
3
Nokia Research Center 2011
Background
4
Nokia Research Center 2011
Security requirements for mobile phones
Mobile network operators
1.
Subsidy locks  immutable ID
2.
Copy protection  device
authentication, app. separation
3.
…
Regulators
1.
RF type approval  secure storage
2.
Theft deterrence  immutable ID
3.
…
End users
1.
Reliability  app. separation
2.
Theft deterrence  immutable ID
3.
Privacy  app. separation
4.
…
5
Nokia Research Center 2011
Different from PC world:
Closed  Open
Early adoption of security mechanisms
Operators
~2002
Hardware-based mechanisms
6
Nokia Research Center 2011
End users
Regulators
~2001
~2005
~2008
Software-based mechanisms
Hardware security enablers
7
Nokia Research Center 2011
Hardware support for platform security
Public key
hash
E.g., serial
number
Trust root
Base identity
Crypto Library
Boot sequence
(ROM)
TCB for platform software
8
Nokia Research Center 2011
Start of
boot code
Basic elements in
immutable storage
Secure bootstrapping
Code certificate
Boot code hash
Trust root
Base identity
Validate and
execute
Crypto Library
Secure boot
Boot sequence
(ROM)
TCB for platform software
Launch platform boot code
9
Nokia Research Center 2011
Ensure only authorized boot
image can be loaded
Identity binding
Identity certificate
Code certificate
Base identity
Boot code hash
Assigned identity
E.g., IMEI, link-layer
addresses, …
Trust root
Base identity
Crypto Library
Secure boot
Boot sequence
(ROM)
TCB for platform software
Launch platform boot code
10
Nokia Research Center 2011
Validate and accept
assigned ID
Securely assign different
identities to the device
Trusted execution
Identity certificate
Code certificate
Base identity
Boot code hash
Assigned identity
Code certificate
Validate and
execute
TrEE code hash
Trust root
TrEE
Base identity
Crypto Library
Secure boot
Isolated
execution
Boot sequence
(ROM)
Device key
Basis for secure
external storage
TrEE code
TCB for platform software
Launch platform boot code
11
Nokia Research Center 2011
TrEE API
Authorized code execution, isolated from the OS
Secure state
Identity certificate
Code certificate
Base identity
Boot code hash
Assigned identity
Code certificate
TrEE code hash
Trust root
Base identity
Crypto Library
Secure boot
Boot sequence
(ROM)
Configuration
register(s)
TrEE
Device key
Non-vol.
memory
or
counter
TrEE code
TCB for platform software
Launch platform boot code
12
Nokia Research Center 2011
Securing TrEE sessions,
authenticated boot
Rollback protection for
persistent secure storage
TrEE API
Integrity-protected state within the TrEE
Device authentication
Identity certificate
Code certificate
Base identity
Boot code hash
Assigned identity
Trust root
Device certificate
Code certificate
Identity
TrEE code hash
Public device key
Base identity
Crypto Library
Secure boot
External trust root
Boot sequence
(ROM)
Configuration
register(s)
Device key
TrEE code
Device authentication,
secure provisioning,
TrEE attestation
Non-vol.
memory
or
counter
TCB for platform software
Launch platform boot code
13
Nokia Research Center 2011
TrEE API
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
14
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
15
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
−Defines interface
−Can be implemented using e.g. TrustZone or M-Shield
16
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?
17
Nokia Research Center 2011
Software platform security
18
Nokia Research Center 2011
Open mobile platforms
• Java ME ~2001
−For “feature phones”
−3 billion devices!
−Not supported by the latest
smartphones
• Symbian ~2004
−First “smartphone” OS
−App development in C++ (Qt)
• Android ~2007
−Linux-based OS
−App development in Java
• MeeGo ~2010
−Linux-based OS
−App development in C (Qt)
−MSSF
• We exclude
−iPhone, Windows Phone,
Blackberry, webOS…
19
Nokia Research Center 2011
Mobile platform security model
• Three phases
1. Distribution
2. Installation
3. Run-time enforcement
• Common techniques
−Code signing
−Permission-based access control architecture
20
Nokia Research Center 2011
Distribution
Software
package
• Developer produces a software
package
− Code
− Manifest
• May submit to a signer for a
trusted signature
• Distributed to device via on-line
stores (typically)
21
Nokia Research Center 2011
Developer
Software
package
Signed
software
package
Installation
Software
package
Signed software
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
• Resource may perform
additional checks
• User may be prompted to
authorize access
23
Nokia Research Center 2011
Monitor
principal
resource
Platform security design choices (TOP 10)
1.
2.
3.
4.
5.
6.
7.
8.
9.
Is hardware security used to secure OS bootstrapping?
How are applications identified at install and runtime?
How is a new version of an existing application verified?
How finely is access control defined?
What is the basis for granting permissions?
What is shown to the user?
When are permissions assigned to a principal?
How is the integrity of installed applications protected?
How does a resource declare the policy for accessing it, and
how is it enforced?
10.How can applications protect the confidentiality and integrity
of their data?
24
Nokia Research Center 2011
1. OS bootstrapping
Is hardware security used to secure OS bootstrapping?
Symbian
Java ME
Android
MSSF
Secure boot
Not applicable
No?
Authenticated boot:
“Normal mode” vs
“Developer mode”
25
Nokia Research Center 2011
2. Application identification
How are applications identified at install and runtime?
Symbian
Java ME
Android
MSSF
Install and run-time:
• Protected range
SID and VID
(managed)
• UID (unmanaged)
Install:
• Signing key
• Midlet attributes
Install:
• Signing key
Install:
• Software source
(signing key)
• Package name
26
Nokia Research Center 2011
Runtime:
• Unix UID
• Package name
(locally unique)
Runtime:
• Software source
• Package name
• Application ID
3. Application update
How is a new version of an existing application verified?
Symbian
Java ME
Protected SID, VID:
• trusted signature
Signed midlets:
“Same origin” policy
• same-origin policy
Rest:
• no controls
Unsigned midlets:
• user prompt
27
Nokia Research Center 2011
Android
MSSF
“Same or higher
origin” policy
4. Permission granularity
How finely is access control defined?
Symbian
Java ME
Android
MSSF
Fixed set of
“capabilities” (21)
Fine-grained
permissions (many)
Fine-grained
permissions (112)
Fine-grained
resource-tokens
Linux access control
Linux access control
Android and MSSF: Each application is
installed under a separate Linux UID
28
Nokia Research Center 2011
5. Permission assignment (basis)
What is the basis for granting permissions?
Symbian
Java ME
Android
MSSF
4 categories
Trusted signatures for
protection domains
4 protection
levels
Trusted signatures
Trusted signature
(also user prompts)
User
System,
Restricted,
Manufacturer
29
Nokia Research Center 2011
4 permission modes
Blanket,
Session,
One-shot,
No
Local policy file
Normal (automatic)
Dangerous (user-granted)
Signature (developer-controlled)
SystemOrSignature (Google-controlled)
6. Permission assignment (user prompting)
Symbian
Java ME
Android
Capability
description
• 21 capabilities
Function group
description
• 15 groups
Permission group
description
• 11 groups
MSSF
E.g., LOCATION,
NETWORK,
E.g., NetAccess
E.g.,Read user data,
Use network, Access
positioning, …
ACCOUNTS, …
PhoneCall
Location, …
What is
shown to
the user?
30
Nokia Research Center 2011
7. Permission assignment (timing)
When are permissions assigned to a principal?
Symbian
Java ME
Android
MSSF
Install-time
assignment
Run-time prompts
Install-time
assignment
Install-time
assignment
Run-time privilege
shedding possible
Symbian and MSSF: Permissions of app loading a DLL is a
subset of permissions of DLL
31
Nokia Research Center 2011
8. Application integrity
How is the integrity of installed applications protected?
Symbian
Java ME
Android
MSSF
Dedicated directory
Java sandboxing
Java sandboxing
IMA, Smack
Linux access control
Offline protection
with EVM and TrEE
Integrity Measurement Architecture (IMA)
• Store hash of file (in extended attribute security.ima) and verify on launch
Extended Validation Module (EVM)
• Store MAC of all extended attributes (in security.evm) and verify on access
32
Nokia Research Center 2011
9. Access control policy
How does a resource declare the policy for accessing it?
How is it enforced?
Symbian
Java ME
Android
MSSF
Declare in code
[System resources]
Enforced by VM
Declare in manifest
Declare in manifest
Enforced by VM
Enforced by Smack
or via libcreds
Enforced by IPC
framework or code
33
Nokia Research Center 2011
10. Application data protection
How can applications protect the confidentiality and
integrity of their data?
Symbian
Java ME
Android
MSSF
Runtime:
• private directory
Runtime:
• private record
stores
Runtime:
• dedicated UID
• file system
Runtime:
• fine-grained data
caging
Off-line:
• private secure
storage
34
Nokia Research Center 2011
Off-line:
• private secure
storage
Discussion
35
Nokia Research Center 2011
Recurring themes (hardware enablers)
• Hardware-support for platform security
−Cambridge CAP etc. (~1970s)
 Extended to Trusted Execution Environments
• Hardware-assisted secure storage
• Secure and authenticated boot
−TCPA and TCG (late 1990s)
−Academic research projects (mid 1990s)
 Extended (private secure storage for applications)
 Adapted (normal vs. developer mode in MSSF)
36
Nokia Research Center 2011
Recurring themes (software platforms)
• Permission-based platform security architectures
−VAX /VMS privileges for user (~1970s)
 Adapted for applications
−Code signing (mid 1990s)
 Borrowed for application installation
37
Nokia Research Center 2011
Open issues
• Permission granularity
−Coarse-grained permissions vs. principle of least privilege
−Fine-grained permissions vs. user/developer confusion
• Permission assignment
−Is it sensible to let end users make policy assignment decisions?
• Centralized vetting for appropriateness
−Can central authority decide what is offensive?
−Can there be crowd-sourced or “clique-sourced”alternatives?
[Chia et al]
• Colluding applications
−How to detect/prevent applications from pooling their privileges?
[Capkun et al]
38
Nokia Research Center 2011
On-board Credentials
39
© 2011 Nokia Research Center
On-board Credentials architecture
Credential
issuer
OS
Credential
issuer
Application
Credentials
Manager
TrEE
Available for
experimentation!
Credential
program
Credential
program
Interpreter
Kostiainen, Asokan, Ekberg and Rantala. “On-board Credentials
with Open Provisioning”. ASIACCS 2009.
40
Nokia Research Center 2011
Summary
• Mobile phone security
−Requirements, regulations, user expectations
−Early adaptation of hardware security mechanisms
• Platform security architecture
−Many features borrow or adapted
−Permission based access control and code signing
• Open issues
−Permission granularity and assignment
Kostiainen, Reshetova, Ekberg and Asokan. “Old, New, Borrowed, Blue: A Perspective
on Evolution of Mobile Platform Security Architectures”. CODASPY 2011.
41
Nokia Research Center 2011