Security for Mobile Devices

1. Security for Mobile Devices CS 4720 – Web & Mobile Systems

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

3. 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

4. Defense in Depth • The more layers you can put between you and an attacker, the better • Secure design • Application development • Encryption • Device management 4

5. 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

6. Other “Good Things” • Encryption of data • SSL for connections • Input validation • Power-on password for the device • Everything else we discussed 6

7. Mobile Remote Management • 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 7

8. 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

9. Application Signing • 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 9

10. Mobile Security Policy • 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 10

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

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