Java & The Android Stack: A Security Analysis Pragati Ogal Rai Mobile Technology Evangelist PayPal, eBay Java Conference, Bangalore, Dec 8, 2012

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

Java 2 Security Model

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

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

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  Array bounds must be checked on all array accesses

Java 2 Platform Security Model Remote Class FilesLocal Class FilesSigned Class Files Bytecode Verifier Class Loader Core API Class Files Core Java API Security Package Key Database Operating System Security Manager Access Controller

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

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"; }; ………….. ……….

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

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

The Android Stack

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

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

Install Time User Consent

Android OS Architecture

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

Linux Kernel (Cont’d) include/linux/android_aid.h AID_NET_BT3002Can create Bluetooth Sockets AID_INET3003Can create IPv4 and IPv6 Sockets

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

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

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)

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

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

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

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

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

Summary

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

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

Signature Identity and Trust Authorship and Persistence

Permissions Enforced by VM Enforced by OS

Protection Domain Code Sources + Permissions Process

Virtual Machine Is a security boundary Is NOT a security boundary

Thank