Security of Mobile Operating Systems Muneeb Alvi

Windows Phone RIP: 2010-2015/2017

end of slide show. click to exit…

Android and iOS

Android 2 Billion Monthly Active Android devices 82 billion (yes billion with a b) app downloads in just 2016 65 billion in 2015 (significant increase) On phones, tablets, TVs, smart watches, cameras, … Most popular smartphone OS sources: https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users https://en.wikipedia.org/wiki/Usage_share_of_operating_systems

iOS 1.2 billion iPhones sold App Store as 2 million apps 130 billion downloads (yes with a b again) 50 billion dollars paid to app developers from successful apps On tablets, phones, tvs (shares similar apps and ecosytems with tvOS) sources: techcrunch, https://www.forbes.com/sites/niallmccarthy/2017/06/29/apple-has-sold-1-2-billion- iphones-over-the-past-10-years-infographic/#27f3d1ab42f8

Problems Lots of apps, lots of security concerns Devices are very personal Hold lots of personal data (pictures, contacts, etc…) Can get lost (should still be secure)

Solutions Application Provenance Inspecting apps Updating OS to handle new vulnerabilities

iOS Provenance Provenance: determining ownership or assigning some responsibility/origin One way to distribute apps (Apple App Store) Developer must register with Apple (Requires identity of developer) Licensing agreement App must be tested for privacy and security violations (could take days to weeks) If everything passes, app is signed digitally Digital signature Certificate from Apple linked to the developer Embedded directly into the app before being published Responsibility on developer, deters hackers from attacking published apps (must break digital seal)

Not Perfect Apple doesn’t reveal automated process for checking app How good is it? We don’t know Some bad apps do make it 2009. All apps from Storm8 removed. Were trying to collect personal information.

Android Provenance Digitally signed apps (like iOS) However, does not require developers to register with Google and have Google signed certificates Developers can create as many personal certificates without being monitored by Google $25 fee to distribute from Google’s Play Store Can install apps from APKs without using Google’s Play Store Can be downloaded from any website without monitoring from Google Now hackers can attack website to distribute malicious apps Hackers can create fake digital certificate and put fake company name in certificate (M!CRO$OFT) -> (Microsoft)

Android Provenance (Cont) Hackers can modify trustworthy apps, create fake certificate, distribute elsewhere (Trojan horse) Tradeoff More usability for less security More customizable User should know most of the risks. Responsibility shifts from supplier to user.

App on the Phone Provenance: First stage. Tries to prevent bad apps from being available Permissions: Second Stage. Prevent bad apps from affecting device if app has been installed

iOS Permissions Permissions: What the app can and cannot do/access Apple decides which limited set of permissions App can have (closed system, walled garden) User not told/asked about app permissions unless it is absolutely necessary or related to privacy Accessing location, camera, making a phone call, etc… App must ask every time if it can access those personal features

Android Permissions User is told what permissions the app will have once it is installed Once app has permissions, it does not need to ask user again until deleted Responsibility moved to user once again Developer just has to convince users to download apps Some apps don’t install until users give full permissions Outcome depends on how aware the user is 100 built in permissions CAMERA, INTERNET With the right permissions, a hacker can do wrong things Data Loss Attacks, obtaining user’s phone number

Isolation Each app is protected from other apps

iOS Isolation Each app protected from one another (Sandboxing) Sometimes don’t even know other apps are installed on the device No app can escalate privilege level or affect the kernel Malware attacks can be minimal and only affect app data and some other minor data Apps have access to some system information, can gain other valuable information if app is malicious (email, devices unique ID)

Android Isolation Similar to iOS (Sandboxing) Cannot access kernel or other apps A malicious app cannot affect/hack other apps Using some permissions App can get list of other apps App can launch other apps (such as Maps)

Encryption Solution for if device is stolen Process of transforming data into being unusable unless it is transformed back using a key (typically a long number) Encrypt data on device and data being sent/received by device Passwords (what if they are stored insecurely on otherwise encrypted device) Fingerprints (easy to use and you always have it with you, not difficult to create false fingerprint)

iOS Encryption Use of hardware and software Hardware AES (Advanced Encryption Standard) Encrypt all data stored on device flash memory (Device Unique ID: UID) Each device has unique UID AES keys used to encrypt file system metadata, files, etc… If memory chips are moved to another device, they can’t be decrypted without UID GID (Device Group ID key) Same across all processors in device Used for installing new system software (verify iOS updates)

iOS Encryption Data Protection Operating System (Software) provided level protection All files encrypted with unique File Key Protects data across communication with other devices and internet Prevents decrypting important data while device is locked Rapid Remote wipe Wipe a single encryption key, all data is useless

Doesn’t always work Background applications can access system storage iOS always keeps necessary decryption keys for background apps that need them Malicious app can try to gain access to key and then have access to other sensitive information. Passwords: can be guessed by experienced hacker within 20 minutes Using jailbreak tool (requires physical access)

Android Encryption File System based encryption All user data is encrypted in the kernel (requires user to set password) Uses part of password to perform encryption Encryption has to be explicitly asked by the user (depends on settings of OS) KeyChain Used to securely store user passwords/certificates from installed apps Backed by hardware support Depends on user and applications that decide whether it is used Application should not store a password itself (especially if it is not encrypted)

Closing points Security should be considered from the moment an app wants to be hosted on an app store, website, server, etc… Both iOS and Android offer many security systems Difference is who decides when these systems should be activated iOS puts most of the responsibility on Apple Android puts most of the responsibility on user Even with all the systems in place, clever hackers can still get through

References Android vs iOS Security: A Comparative Study Authors: Ibtisam Mohamed, Dhiren Patel An Analysis of Vulnerabilities Presented by Android Malware and iOS jailbreaks Author: Charles Jones