Talk presented

1. Java & The Android Stack:
A Security Analysis
Pragati Ogal Rai
Mobile Technology Evangelist
PayPal, eBay Inc.
pragati.rai@paypal.com
Java Conference, Bangalore, Dec 8, 2012 @pragatiogal

2. Agenda
 Java 2 Security Model
 Android Security Model
 Summarize

3. Java 2 Security Model

4. Java
 Developed by Sun Microsystems in the early
1990s
 Platform Independent
 Compiled to bytecode that runs on a Virtual
Machine
 “Java is Secure”

5. Java 2 Security Model
 Platform Security
 Crypto APIs
 Authentication & Access Control
APIs
 Secure Communication APIs
 Key Management APIs

6. Java Language Security
 Programs cannot access arbitrary memory
locations
 Variables cannot be used before initialization
 Access methods are strictly adhered to
 Entities declared final must not be changed
 Objects cannot be arbitrarily cast into other
objects

7. Java 2 Platform Security Model
Remote Class Files Signed Class Files Local Class Files
Bytecode Verifier
Core API Class Files Class Loader
Core Java API
Security Package
Security Manager
Key Database
Access Controller
Operating System

8. Java 2 Sandbox Model
• Fine grained access control
• Configurable Security Policy
• No built-in concept of trusted
local code

9. Security Policy File Example
// If the code is signed by ”Pragati", grant it read/write access to all
//files in /tmp/pragati
grant signedBy ”Pragati" {
permission java.io.FilePermission "/tmp/pragati/*", "read,write";
};
// If the code is signed by ”John", grant it read/write access to all
//files in /tmp/john
grant signedBy ”John" {
permission java.io.FilePermission "/tmp/john/*", "read,write”;
};
// Grant everyone the following permission:
grant {
permission java.io.FilePermission "/tmp/pragati/*", "read";
};
…………..
……….

10. Protection Domain
Domain name “Pragati”
Pragati’s certificate
Read/write access to /temp/pragati/*
Domain name “John”
John’s certificate
Read/write access to /temp/john/*
Read access to /temp/pragati/*
…………..
……….
Protection Domain = Code Source + Permission

11. Java 2 Security Model
 All code runs in a sandbox
 All classes are loaded with full bytecode verification
 All classes are loaded with Java language features
 Signed classes verify the integrity and origination of
Java classes
 Security policy provides fine-grained access
 Crypto APIs

12. The Android Stack

13. Android
 Open Platform
 First phone based on Android came out in
2009
 75% smartphone market share as of October1
1: idc.com

14. Android Security Model
 Platform Security
 Crypto APIs
 Secure Communication APIs
 Key Management APIs

15. Install Time User Consent

16. Android OS Architecture
http://developer.android.com

17. Linux Kernel
 Unique UID and GID for each application at install time
 Sharing can occur through component interactions
 Linux Process Sandbox

18. Linux Kernel (Cont’d)
include/linux/android_aid.h
AID_NET_BT 3002 Can create Bluetooth Sockets
AID_INET 3003 Can create IPv4 and IPv6 Sockets

19. Middleware
 Libraries for code execution
 Libraries for services
 Take care of device specific issues
 Compiled to machine language
 Native and Java code

20. Java Virtual Machine?
 There is no JVM in Android platform
 No bytecode is executed
 JAR file will not run on Android platform

21. Dalvik Virtual Machine
 Dalvik does not align to Java SE or Java ME
 Library built on a subset of the Apache Harmony Java
 Highly optimized VM to support multiple VM instances
 Register based architecture
 Shared constant pool
 Executes Dalvik executables (.dex)

22. Dalvik Virtual Machine
 No security manager
 Permissions are enforced in OS and not in VM
 As of Android 2.2 Dalvik has a JIT compiler
 Dalvik Bytecode verification mainly for
optimization
 GC for each VM instance

23. Android Application Structure
 Application is made of components
 Activity: Define screens
 Service: Background processing
 Broadcast Receiver: Mailbox for messages from other
applications
 Content Provider: Relational database for sharing information
 Applications communicate through Intents
 Secure RPC using Binder
 AndroidManifest.xml defines policy for application

24. Permission Protection Levels
 Normal
android.permission.VIBRATE
com.android.alarm.permission.SET_ALARM
 Dangerous
android.permission.SEND_SMS
android.permission.CALL_PHONE
 Signature
android.permission.FORCE_STOP_PACKAGES
android.permission.INJECT_EVENTS
 SignatureOrSystem
android.permission.ACCESS_USB
android.permission.SET_TIME
All components are secured by permissions
Developers can define their own permissions as well

25. Application Layer Security
 Permissions restrict component interaction
 Permission labels defined in AndroidManifest.xml
 Applications are self-signed; no CA required
 Signatures define persistence and authorship

26. Android Security Model
 Linux process sandbox
 Permission based component interaction
 Dalvik is not a security boundary
 All applications need to be signed
 Signature define persistence and authorship
 Install time security decisions
 Crypto APIs

27. Summary

28. Install Time Check
Who are you?
What do you want to do?

29. Sandbox
Based on permissions, code sources,
policy, keystore, protection domains
Process Sandbox

30. Signature
Identity and Trust
Authorship and Persistence

31. Permissions
Enforced by VM
Enforced by OS

32. Protection Domain
Code Sources + Permissions
Process

33. Virtual Machine
Is a security boundary
Is NOT a security boundary

34. Thank you!
pragati.rai@paypal.com
@pragatiogal
http://www.slideshare.net/pragatiogal