Android Security CS 4720 – Mobile Application Development 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! CS 4720 2
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 CS 4720 3
Other “ Good Things ” • Encryption of data • SSL for connections • Input validation • Power-on password for the device • Everything else we discussed CS 4720 4
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 CS 4720 5
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 CS 4720 6
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 trust authorities certificate store CS 4720 7
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 CS 4720 8
Changing Security Configurations • This is why you have to call Verizon/Sprint/AT&T to get an “ unlock code ” for some phones • Some aspects are locked to the provider, even if you own the phone! CS 4720 9
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. ” CS 4720 10
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 CS 4720 11
Android Manifest Permissions • Network communication: view Wi-Fi state, create Bluetooth connections, full Internet 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 CS 4720 12
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 CS 4720 13
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 ” CS 4720 14
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 CS 4720 15
Recommend
More recommend
