Security for Mobile Devices
description
Transcript of Security for Mobile Devices
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