CS 4720

Security for Mobile Devices

CS 4720 – Web & Mobile Systems

CS 47202

Finishing up Security• Authentication• Authorization• Integrity / Confidentiality• Non-repudiation / Auditing

CS 4720

Security through Obscurity• It used to be that phones had so little

connectivity to devices other than the phone network that security wasn't a huge deal

• Phone number stealing did occur• But nothing compared to what can happen

with today's smartphones!

3

CS 4720

Defense in Depth• The more layers you can put between you and

an attacker, the better• Secure design• Application development• Encryption• Device management

4

CS 4720

Encrypting Credentials• Create a configuration file for use of logging

into a web service or DB or whatever• Then encrypt that file with a

username/password combo that isn't stored anywhere on the device

• For multiple users, add another layer – encrypt a master password with a username/password combo that can unlock the configuration files

5

CS 4720

Other “Good Things”

6

• Encryption of data• SSL for connections• Input validation• Power-on password for the device• Everything else we discussed

CS 4720

Mobile Remote Management

7

• With an “always on” (theoretically) network like a cellular network, remote enterprise management is an option

• Can force:– Policies (power on password, etc)– Password changes– Removal of all data through remote wipe

CS 4720

Application Signing• Under “normal circumstances,” to run code on

a mobile device the following must be true:– The executable files are “signed”– The signature is valid– The signature matches a recognized certificate on

the device• Code signing ensures two things: the code

hasn't been modified and the owner is known

8

CS 4720

Application Signing

9

• Works similarly to public/private key signing– On a compile, the code is hashed and encrypted

with the private key of the author– The author's public key and info is attached to the

code as a resource– At runtime, the mobile device gets the public key

and decrypts the hash– Then it hashes the code and does a comparison– Finally, the public key is verified against the

Execution Trust Authorities certificate store

CS 4720

Mobile Security Policy

10

• Applications can be:– Privileged: signed and verified in the cert store– Unprivileged : verified as unprivileged in the cert

store– Unsigned: app not signed

• And these apps can run:– Trusted: consider this as running as root (almost)– Normal: API and Registry is severely restricted

CS 4720

WinMo Security Policy• The Security Policy is encoded as a set of bits• 4102 – Can unsigned apps run? 0 No, 1 Yes• 4122 – Prompt to run unsigned? 0 Yes, 1 No• 4123 – Two-tier or one-tier security? 0 2, 1 1• 4097 – ActiveSync calls? 0 Dis, 1 Root, 2 Rest• Two-tier vs one-tier?

– In a one-tier, there is no restricted user; everyone runs as root

– Think Windows 95, 98, and most of XP

11

CS 4720

WinMo Security Policy• The combinations of these give us the four

main security configurations for WinMo:• Locked / Third-Party Signed: Can't run

unsigned, AS disabled• Two-Tier Prompt: Can run unsigned, prompt

user, AS restricted• One-Tier Prompt: Same, but everything runs as

root• Security Off: run everything, no prompt, full AS

12

CS 4720

Changing Security Configurations• Microsoft provides a free tool for changing

your security configurations!• … but you can't be Locked to get to it, since

Locked prevents AS calls• This is why you have to call

Verizon/Sprint/AT&T to get an “unlock code” – it moves Locked to Two-Tier

13

CS 4720

Android Security• “No application, by default, has permission to

perform any operations that would adversely impact other applications, the operating system, or the user.”

• “This includes reading or writing the user's private data (such as contacts or e-mails), reading or writing another application's files, performing network access, keeping the device awake, etc.”

14

CS 4720

Android Security• Sandbox model• All apps run in their own sandbox• All potential permissions needed to exit the

sandbox must be statically declared at app install time

15

CS 4720

Android Manifest Permissions• Network communication: view Wi-Fi state,

create Bluetooth connections, fullInternet access, view network state

• Your location: access extra location provider commands, fine (GPS) location,mock location sources for testing, coarse (network-based) location

• Services that cost you money: send SMS messages, directly call phone numbers

16

CS 4720

Android Application Signing• All .apk's (Android packages) must be signed by

the developer's private key stored on the local machine

• A “default” keyset is generated when you install the Android SDK– It can be found in your .android directory– This can be used for development

• When you publish your app, you must create your own public key

17

CS 4720

Android Application Signing• Google provides detailed steps on how to

create your own key• MAJOR POINT – Google / Android does NOT

require that your certificate / private key is verified by a certificate authority

• This is called a “self-signed certificate”

18

CS 4720

Self-Signing• What does it mean to have a self-signed

certificate?• How it affects apache / https• What are the potential risks to having a self-

signed certificate:– For a server?– For an Android application?

• This is very different than Apple's stance

19

CS 4720

iPhone• In general, it is pretty similar, it just involves a

lot more interaction with Apple• Developers get certificates that are certified by

Apple• Test devices are added to the system• App IDs are created and provisioned for

distribution• Although… looking at it makes me cringe…

20

CS 4720

iPhone• Let's take a look at the developer network!

21