Android Security for Enterprise App Developers Larry Dykes Mgr, Global Technical Enablement

Agenda for Lightning Talk – Developer View Android Security Model Security and Enterprise-Scale Device Configuration Encryption Options for Data-at-Rest Enterprise Reset: Return to “Known Good” State

Application “Sandboxing” Sandbox Setup (at install time) As each new App is installed from an APK… it gets assigned a new, automatically generated UID and a folder is created in /data, the files from the APK are unpacked there. This folder is… Owned by that UID With “closed” file permissions So only processes owned by the application’s UID can access files in the application’s private folder in /data

Sandboxing Continued Launching an App in a “Sandbox” The master Dalvik process, “zygote”*, creates a new Dalvik Instance in a new Process.. Loads the app into the DVM within the new Process, and Sets the Owner of the Process to the UID associated with the App Note: this is a fast, efficient process. Read more at: So now the App is running as a process owned by it’s own UID, so it (and only it) has complete access within it’s private folder! * - from biology: ‘the first cell of a multi-celled animal’

Sandbox = Isolation Bottom line – whenever it runs, each App gets An inviolate memory space for execution Access to its own, inviolate storage area for files and folders Access to “public” storage, like /scard and /enterprise/usr This protection / isolation is provided by the Linux Kernel and File Sytem Memory isolation is provided by the Process boundary, not the Virtual Machine boundary File storage isolation is provided by file permissions and ownership, which must match the process owner.

the Android Permissions System NOT Linux/Unix – unique to Android Google defines “permissions” in groups the groups are evolving Developers can create their own “custom” permissions groups (and we do) When an app is installed by a user, Android lists all the permissions groups it is requesting. it’s “ grant all or don’t install ”* * changing

Permissions Apps can only communicate via Components Any component can be assigned a permission label Others will need that permission to access this component Same for certain OS components and API calls to them (Phone, WLAN…) Each application explicitly requests permissions via manifest Cannot be changed after install Allows very granular control Only some of it exposed to user List of all Android permissions: rmission.htmlhttp://developer.android.com/reference/android/Manifest.pe rmission.html New custom permissions can be defined. Potential for Enterprise use (software suites, management) Introduction

List of Permissions Permissions defined on a device will depend on.. Version of Android Apps Installed Let’s look at a listing from an “empty” MC40, output by… adb shell pm list permissions –g

Levels of Permissions Permissions must belong to one of the “Protection Levels” Normal (default) Lower-risk permission that gives requesting applications access to isolated application-level features, with minimal risk to other applications, the system, or the user. Granted automatically w/o explicit user's approval (still displayed during installation, of course). Dangerous (introduces potential risk) A higher-risk permission that would give a requesting application access to private user data or control over the device that can negatively impact the user. Not granted automatically. Will require some form of user consent (popup dialog, etc). Signature Granted only if the requesting application is signed with the same certificate as the application that declared the permission. Then granted automatically. Useful for software suites (several apps from the same developer working together). SignatureOrSystem As before, but also allow access to apps that are part of the system image Many OS APIs are protected with this – reason for MDM not working unless agent is part of the firmware (or MDM certificate is part of firmware) ADB shell: pm list permissions -f display permissions with “full information” pm list permissions -g display permissions in groups :0)

Android Security and Enterprise Device Configuration

The Settings App – OK for One Device, but.. There is a Settings app, for configuring the device but.. and it does not lend itself to manual, identical configuration of multiple devices It allows the end user too much control over settings for enterprise deployments It does not allow configuration of Zebra Value Add features Settings made with the Settings App do NOT persist over Enterprise Reset Your app may need certain Settings in order to work well or your customer may ask for some “tweaks” to device behavior Your app(s) may be unable to get the permission needed

Controlled Access to Settings Access to Settings is Controlled by Android Permissions Some settings, an “ordinary” app can reach, it it asks for and is granted “WRITE_SETTINGS” For some settings, permission is only granted to “Privileged Applications” (aka “signed or system” apps) that ask for “WRITE_SECURE_SETTINGS” Then of course, if you want to be able to return a unit to a “known good” condition, those apps must persist across an Enterprise Reset, and Must persist their data reapply the settings after Enterprise Reset

Remember This? Permissions must belong to one of the “Protection Levels” Normal (default) Lower-risk permission that gives requesting applications access to isolated application-level features, with minimal risk to other applications, the system, or the user. Granted automatically w/o explicit user's approval (still displayed during installation, of course). Dangerous (introduces potential risk) A higher-risk permission that would give a requesting application access to private user data or control over the device that can negatively impact the user. Not granted automatically. Will require some form of user consent (popup dialog, etc). Signature Granted only if the requesting application is signed with the same certificate as the application that declared the permission. Then granted automatically. Useful for software suites (several apps from the same developer working together). SignatureOrSystem As before, but also allow access to apps that are part of the system image Many OS APIs are protected with this – reason for MDM not working unless agent is part of the firmware (or MDM certificate is part of firmware)

Application Access to Device Settings

Data at Rest Encryption Options

Encryption Options Encryption How does it work? What does it protect against it? Is it worth the trouble? Three “kinds” Full Device Encryption (only encrypts /data) External Storage Encryption (only encrypt /sdcard) Folder Level Encryption (one or more folders)

Encrypt Full Device Well not full device, really… only encrypts /data Requires entry of passcode on bootup to unlock. Key stored in system (needs passcode on boot) Protects /data until passode is entered After that, transparent access for any running app.. Like it’s not even there !! No protection against any process running on the machine So what does it protect against? Forensic analysis of device chips Process that might run before /data is unlocked.

Encrypt External Storage External Storage Volumes only Reformat from FAT32 to IM-CRYPT Key not stored on card Automatically reconnected (opened) on boot After that, transparent access for any running app.. Like it’s not even there !! No protection against any process running on the machine If you move the SD card to another device Secure File System Must know that password

Encrypt Folder(s) - Zebra MX Feature Choose folder(s) to encrypt with named passcodes Internal or External storage Transparent, “normal” access when open Opened at boot with no user interaction, if passcode is available.. But.. Using MX an admin can revoke a passcode blocks any access by any internal application Protects folders against forensic analysis and on removable drives Data stays on device, but encrypted (no key on device) And later restore a passcode for one or more folders Restores no-hassle access again - no need to reload data

Encryption & Recovery Mode… … yes, you CAN have too much encryption Can Recovery Mode… Read.zip from /data/tmp.. and write to system partitions.. if Full Device Encryption is enabled? Read.zip from /sdcard.. and write to system partitions.. if External Storage Encryption is enabled? Read.zip from /sdcard.. and write to system partitions.. if Folder Level Encryption is enabled on one or more folders on the sdcard? If you encrypt both “full device” and all “external storage”.. There will be no place to put a.zip file that can be used in Recovery mode – so no possibility of remote OS update. Using MX “folder” level encryption may provide “enough encryption” and still leave space for OS update zips.

Encryption Summary - 3 “kinds” of Encryption Full Device Encryption (only encrypts /data) High cost (enter passode, no zips in /data/tmp), limited protection External Storage Encryption (only encrypt /sdcard) Medium cost (no zips on sdcard ), protects storage when removed Folder Level Encryption (one or more folders) -- Zebra MX feature Low cost, protects the parts you want to protect, switch access on and off Internal Storage – revocation provides the only protection against internal attack External storage – also protects when removed Folder encryption – protects against forensic analysis when revoked, and protects folders on removable external storage volume

Enterprise Reset: Return to “Know Good” State

Enterprise Reset – the Concept Cold boot in Windows CE and Clean Boot in WM were what we now call.. “Enterprise Resets” Return unit to “known good” state, Possibly at the expense of losing some app data Apps CAN but don’t have to store their data in a persistent location The idea being, of course.. Delete any changes made since original setup to apps or settings Exception for properly persisted data Restart “Clean” Restart empty and put back what you put in, in the first place But in CE / WM, any process could modify \Application Add apps or.reg files that would persist over Clean/Cold boot Remove apps or.reg files that should persist Copy anything (like WLAN settings in.reg files)

Enterprise Reset in Android So what happens at Enterprise Reset? /data is cleared – all applications and their sandboxes are GONE All the UID’s that were created by installing APKs are GONE All Settings revert to Factory Defaults External storage volumes are are not affected unless emulated from /data File and folders under /enterprise/usr are still there, data intact so as long as they were written with permissions “wide open” as recommended… they can be still be accessed by your app after it’s UID has changed.. because … As device boots up from Enterprise Reset… Properly persisted SETTINGS are re-applied. Properly persisted APKs are re-installed Each gets a NEW UID assigned and a NEW private folder created in /data, belonging to the new UID Each new app may need to access data it stored previously in /enterprise/usr

Programming for Enterprise Reset Persistence Protect any files which may lose content if your app is re-installed Identify which files that need to persist over the ER Have your app put them in a location that will persist over ER (put then in a subfolder of /enterprise/usr) Be sure you will be able to regain access when your Linux UserID has changed ( always set permissions to 777) Be sure your app will not write over them on install or first run. Use EMDK and MX Persist Manager to “restore” your app… Add yourself to the list of applications that will be re-installed after an Enterprise Reset If your app needs to be always-running, add yourself to list of apps to be launched automatically.

Questions?

THANK YOU